• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Showing developer posts only. Show all posts in this thread.
+1 for Gifs from another lurker. I came for the info and stayed for the humor :p
Appreciate that. As a former forum admin/mod, since the mid 90's and onwards, it always tickles me to get a lurker to post. Welcome! :)

Could you explain a bit how you define "balance" in terms of this game and how it's getting tested?
I hope the answers that podcat provided for your questions helped to clear things up a bit.

Do you not use JIRA's time management or maybe a plugin? There's quite a few though at the moment our development team isn't mature enough to start doing this with the time estimates due to various contract issues. (most are contractors)
I've tried a number of different resource managament tools and haven't come across one that can handle our complexity in a way that actually helps and saves me time.

To give everyone an idea of the complexity we keep mentioning:
The main complication that we face, which is a well known issue in the games industry... is that there are so many different professions involved in getting one feature done.
A common scenario is (simplified, believe it or not):
  1. A new feature starts out with a designer.
  2. Then it's taken over by a coder.
  3. Then handed off to a UX Designer.
  4. Then back to a coder. (preferably the same one)
  5. And art (Which in this example could be started at the same time.)
  6. Then AI.
  7. Then Content Design.
  8. One final pass for a coder.
  9. Then QA
  10. Who most likely hands it back to the coder.
  11. QA again
  12. And so on.
Now imagine that we a dozen new features, in various stages of development, being worked on at the same time.
And only a limited amount of people in each profession.
Making sure that nobody is blocked from doing their part by someone else is a... (biting back from not using foul language here) ...challenge.

There are certain tools and data that I don't have access to here at Paradox that would help. https://www.gooddata.com, to mention one. (You can use this to produce various reports, burndowns etc, that are far superior to JIRAs build-in ones.)
As our teams and projects grow; I see us exploring this area more in the future.

Also, @KimchiViking , if you guys are using JIRA and trying to determine new features et al. Would it be helpful to put issues out to us to vote on?
This would be opening a Pandora's box, I'm affraid.
 
They promised that this DD and the next were going to be like this. As they got back up to speed after everyone was on vacation. So why anyone who is even semi-active on the forums is surprised is hard to understand.
Wait... wait... I think you're on to something here. It's almost as if people only read and retain the information that is relevant to their interests. Huh. Imagine that.
;)
 
I missed this dev diary :( Are you still online to answer any questions ?
Hi Neigel,

We monitor the forums continuously, so shoot away and we will hopefully be able to respond to your question(s)!
 
Last edited:
I missed this dev diary :( Are you still online to answer any questions ?
I thought the thread died, so I let it go. But yeah. Shoot away.

It's interesting to see they use Agile. I wonder if Scrum works for them. We started off with Scrum but swapped to Kanban as it suited our development process better.
Before I started; HOI4 development was basically waterfall. About as agile as Niagra bloody falls.


When I came in; I transitioned us into ScrumBan. As a way to introduce the team to agile methologies. It worked well for us.

Right now, we are running our own Paradox-version of Scrum. Which is what all the other development projects here at Paradox are using.

I'm partial to Scrumban and Kanban though. So we might go back to it once this expansion is done. Take what we learned from both methods and fuse it into something that works best for HOI.

everyone switches to Kanban in the end to spare themselves all the meetings and overhead
(just my experience after 10+years in SW development/product ownership)
It completely depends on the project, I would say. (Not to get into a pissing contest here, but I'm speaking from my 20 years of experience in development both as dev and project manager.)

For example; for a project with tight time- and budget constraints, as well as frequent deliveries/releases; Scrum might be the only way to go. It gives you a lot of control.
 
Hmm... how to answer this without giving you a hideously long wall of text?

Put simply:
We have two embedded QA in our team. They are an integral part of our daily work.
We also have a larger group of QA that give us extra muscle power whenever there is a release.


What QA spend their time on is determined via:
  • For day-to-day activities: What is in the JIRA-ticket (we use “acceptance criteria/definition of done” as a way to let QA know what’s new and what they need to test)
  • For longer-term planning: What has popped up during the design process or during the development process as extra risks to keep our eyes on
For extra tricky new features; scenarios/test cases are created.

They are typically created when each feature is nearing completion. Or even towards the end of the entire project, as features tend to tie into each other. For example: one new feature’s impact on the game can’t be fully tested before another new thing is also in there.

The tests themselves often take the form of huge old-school spreadsheets.

Some scenarios are formulated as a simple yes/no question. “Does country X invade country Y before year 19XX?” (Type A)
Other things require the QA to evaluate the feel or fun-factor of a certain feature. (Type B)

For Type B tests... we prefer to get those done early. That way we can make adjustments early and test again.
(We work with "Minimum Viable Product" in mind. Which means developing something small that works in a first step. Then adjust and make it better in iterations. Here's a fun video on the MVP-concept, from Extra credits. In case someone reading is unfamiliar with the term.)
For Type A; we can do that closer to release. As it's often a case of simpler bug fixing rather than having to redesign an entire feature.

As for the methodologies/tools you asked about... and if they’re applicable in game design:
The quickest reply I can give you is that game design is no different than any other complex software project.
Paradox is an ambitious, modern and mid-sized company. We follow the same standards as any other company of the same type would. The challenges we face are very similar, so the tools we use to tackle the situation are the same.

Hope this helps.
 
They have launched smaller DLC's because they have spent a large amount of time fixing the underlying issues with the game (AI, bugs etc that the community was screaming to be fixed). I believe the next DLC is going to be bigger, which is where the Paradox claim of more value comes from. This will result in more 'stuff' in the expansion but probably less time to develop the nuts and bolts of the game.
This is worth repeating. Tough decisions had to be made. Fixing AI, and other base game-related stuff, meant less time to spend on anything else.

Quick recap on what's been said in previous DDs about things that were cut:
Bulgaria was cut due to the fact that we had trouble finding enough information in English at every turn.

What about asking the forums for help then?
What people tend to forget is that we need someone on our end collecting that info. Go through it and make sure we get enough quality info in time to do something with it.
It may sound like a minor thing. But in a project where timing is crucial; it's really not. Fearing not being able to get enough info on Bulgaria, in time, was the straw that broke the camel's back, in this case. It was too big a risk and we had to go for something more safe.

We knew that we would disappoint people by cutting Bulgaria. We also knew that spending more time than normal on Bulgaria research would have meant even less time to develop focuses and events. That would have made even more people disappointed. Between a rock and a hard place; that was the only way to go.
 
I suspect the game manager will not give an answer to that because it will feed into the critic`s arguments, but Archangel85 explanation was they need a Scandinavian DLC.

I said that it made more sense in a Scandianavia DLC since one of the goals was to have the focus trees interact with each other more. Adding Finland to DoD would have repeated the issue of TfV, with countries stuck in different parts of the world not doing much with each other.