@podcat asked me to prepare a Dev Diary from a Project Lead perspective...
Quick background on me: I came on as Project Lead for HOI4 shortly after the game was released, last summer. That’s my perspective. I speak from a expansion-development point of view, and our work going forward.
The purpose of today’s Dev Diary is to give you a little insight into our development process.
Why we fix some bugs and leave others... How we decide what goes into the next expansion... and more.
Imagine, if you will, a crowded bar
Imagine all the customers screaming out their orders at once, to a single hard-working bartender.
How many words do you think the bartender will be able to make out, over the collected noise of the crowd?
How many drink orders do you think he will he be able to get right?
If you answered “none”, you’d probably be close to the truth.
My job, if I’d been working in that bar, would be to to organize a queue-system that works.
To move things along and make sure that people get what they want, as quickly as possible.
As project lead at Paradox; it’s my job to make sure that our players get what they want.
Best possible value in the game, within the shortest possible amount of time.
Here is a super condensed version of how the team and I go about making this happen.
The Design Process
First, within the team; the designer speaks for the players. They’re the one that decide what the team should do.
(Game director @podcat and game designer @Pallidum , in our case.
Continuing with the bar analogy; they’re the people who have a feel for the market and decide what goes on the drinks menu.)
New content to keep players engaged and happy... Weaknesses in the game that needs to be addressed... A balanced mix of all that good stuff is collected together in a “design document”.
The document explains the vision for each new feature, or fix, that goes with a new expansion. It essentially serves as a specification, or commission for work to be done, for the team.
How do we decide what new features and fixes go into an expansion?
The designers base their decisions on what goes into the design document, on, for example:
(For the love of God, YES! We saw the forum bug report.)
How do we choose which bugs to fix? (A bug’s journey from the bug forum to being fixed)
As I mentioned; we have a big database with bugs, improvement ideas and feature-suggestions.
(Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to our database.)
A lot of entries in this database, however, are related to the same underlying system. Doing an overhaul on that system will get rid of a whole bunch of bugs. These are things we prioritize.
A bug often starts out coming onto our radar by being reported, here, in our bug forum.
(I really want to stress this point, because we occasionally see people posting bug reports on reddit or other places. The odds of someone from Paradox stumbling over those reports and carrying them forward into our database are slim.)
The bug is transferred from here into our database. And we start looking into it, by analyzing it.
We need to know how frequent the problem is. How serious, and how quick it is to fix.
The more frequent or serious it is increases its chances of getting fixed. Soon.
If it also happens to be quick to fix… well, that’s just a win-win.
If a bug is serious, frequent and quick to fix and it’s still not being fixed… The most likely explanation to why we’re not fixing it ; is because we simply couldn’t fit it into our schedule.
It might help to understand this, if you…
Think of the development process as a single work day...
Serious things you hear about, before lunch, will get fixed before the day is done. For sure.
Then you might work on something else, with lower priority, for a while.
Until the next big problem pops up.
But, by then, you can’t start on it. Because you can’t get it all the way done, before you have to go home. It’ll have to wait until the next day.
So, in order to not waste precious time, you squeeze in something else that will fit.
This is how our development cycles work. Sometimes we simply can’t start on something and get it fixed, or improved, before the expansion has to ship.
(This also illustrates how sometimes things with lower priority get done when some higher prio stuff are left for later.)
Difficult judgement calls
Other bugs or suggestions are more up for debate.
Doing something that will make one group of people leap for joy - might seriously anger another group. We have to stay on top of that.
The big time-stealers
Not to mention that some requests, like improving AI, is a perpetual job that can’t be rushed.
As obvious as it is that an area needs work; some things are like hatching an egg. It takes the time it takes. No matter how many bodies you throw on the problem.
(Btw, this is how I imagine a Steam Summer Sale going. If Steam was a physical store.)
The Breakdown & Estimation process
Moving on: Once the design doc is complete… The team takes the design and breaks it down into bite-size tasks for coders, content designers, art, UX-design, sound etc.
When we have everything broken down into a list of tasks; we sit down together and “estimate” each task. Giving us an idea of how long the full feature will take to develop, once you add it all together.
How are deadlines and release-dates determined?
Paradox has a plan for how many expansions/DLCs we should release per year.
HOI4 release dates are determined based on: 1. that plan, 2. how quickly we can reach the desired sell-value of the release, and lastly 3. coordinated with specific dates that our marketing team have selected.
(More on this subject in next week’s Dev Diary.)
Can we make the expansion-design happen within the deadline?
After all features have been estimated; I can figure out if what we want to do is possible within the deadline. With the people at our disposal.
If yes: Huzzah!
If not: This is where I have to crush the designer’s hopes and dreams.
Splat!
We need to cut something in order to be able to finish on time.
This is something we discuss and agree on, together. While I gently pat their backs and hand them tissues.
What gets cut?
When cutting something I have to consider, for example:
In closing
Speaking of the nature of development work… While the example above mostly serves illustrate problems with communication, which is always a factor when people with different perspectives discuss something… I think it says something about how frequent certain development problems are; that a site exists where you can create your own project cartoon, like this one.
The issues that Paradox and HOI4 struggle with are the same problems that all IT projects, everywhere, grind their teeth over. It’s terribly complex work. Which is why, although the problems and risks are well known and can be anticipated and planned around, to a degree… they remain.
The silver lining, I think, is that while our problems are the same… we at Paradox have a hell of a lot of fun while working on them.
Next week, our Brand Manager will write a Dev Diary. Before handing the baton back to podcat.
Don't forget to tune into World War Wednesday today at 16:00CEST on https://www.twitch.tv/paradoxinteractive! To see podcat run Germany in massive co-op, with the other devs as generals.
Quick background on me: I came on as Project Lead for HOI4 shortly after the game was released, last summer. That’s my perspective. I speak from a expansion-development point of view, and our work going forward.
The purpose of today’s Dev Diary is to give you a little insight into our development process.
Why we fix some bugs and leave others... How we decide what goes into the next expansion... and more.
Imagine, if you will, a crowded bar
Imagine all the customers screaming out their orders at once, to a single hard-working bartender.
How many words do you think the bartender will be able to make out, over the collected noise of the crowd?
How many drink orders do you think he will he be able to get right?
If you answered “none”, you’d probably be close to the truth.
My job, if I’d been working in that bar, would be to to organize a queue-system that works.
To move things along and make sure that people get what they want, as quickly as possible.
As project lead at Paradox; it’s my job to make sure that our players get what they want.
Best possible value in the game, within the shortest possible amount of time.
Here is a super condensed version of how the team and I go about making this happen.
The Design Process
First, within the team; the designer speaks for the players. They’re the one that decide what the team should do.
(Game director @podcat and game designer @Pallidum , in our case.
Continuing with the bar analogy; they’re the people who have a feel for the market and decide what goes on the drinks menu.)
New content to keep players engaged and happy... Weaknesses in the game that needs to be addressed... A balanced mix of all that good stuff is collected together in a “design document”.
The document explains the vision for each new feature, or fix, that goes with a new expansion. It essentially serves as a specification, or commission for work to be done, for the team.
How do we decide what new features and fixes go into an expansion?
The designers base their decisions on what goes into the design document, on, for example:
- Do the features fit into the overall theme of the expansion?
(This also goes for bugfixes where we prefer to work by theme. For example Air or Naval). - Do we hit a good mix of paid features and free features?
(A lot of this is decided on how difficult things are to implement and their impact on the game’s balance.) - Data we collect on player behavior.
That data is analyzed and lead to new features or fixes. - We have a database full of suggested improvements.
- Not to mention bugs that we prioritize and work off, in priority order.
- We also closely monitor mainly this forum, and (to a lesser degree) other HOI-communities, in case something pops up. Both bugs or inspired posts in the suggestion forum.
(For the love of God, YES! We saw the forum bug report.)
How do we choose which bugs to fix? (A bug’s journey from the bug forum to being fixed)
As I mentioned; we have a big database with bugs, improvement ideas and feature-suggestions.
(Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to our database.)
A lot of entries in this database, however, are related to the same underlying system. Doing an overhaul on that system will get rid of a whole bunch of bugs. These are things we prioritize.
A bug often starts out coming onto our radar by being reported, here, in our bug forum.
(I really want to stress this point, because we occasionally see people posting bug reports on reddit or other places. The odds of someone from Paradox stumbling over those reports and carrying them forward into our database are slim.)
The bug is transferred from here into our database. And we start looking into it, by analyzing it.
We need to know how frequent the problem is. How serious, and how quick it is to fix.
The more frequent or serious it is increases its chances of getting fixed. Soon.
If it also happens to be quick to fix… well, that’s just a win-win.
If a bug is serious, frequent and quick to fix and it’s still not being fixed… The most likely explanation to why we’re not fixing it ; is because we simply couldn’t fit it into our schedule.
It might help to understand this, if you…
Think of the development process as a single work day...
Serious things you hear about, before lunch, will get fixed before the day is done. For sure.
Then you might work on something else, with lower priority, for a while.
Until the next big problem pops up.
But, by then, you can’t start on it. Because you can’t get it all the way done, before you have to go home. It’ll have to wait until the next day.
So, in order to not waste precious time, you squeeze in something else that will fit.
This is how our development cycles work. Sometimes we simply can’t start on something and get it fixed, or improved, before the expansion has to ship.
(This also illustrates how sometimes things with lower priority get done when some higher prio stuff are left for later.)
Difficult judgement calls
Other bugs or suggestions are more up for debate.
Doing something that will make one group of people leap for joy - might seriously anger another group. We have to stay on top of that.
The big time-stealers
Not to mention that some requests, like improving AI, is a perpetual job that can’t be rushed.
As obvious as it is that an area needs work; some things are like hatching an egg. It takes the time it takes. No matter how many bodies you throw on the problem.
(Btw, this is how I imagine a Steam Summer Sale going. If Steam was a physical store.)
The Breakdown & Estimation process
Moving on: Once the design doc is complete… The team takes the design and breaks it down into bite-size tasks for coders, content designers, art, UX-design, sound etc.
When we have everything broken down into a list of tasks; we sit down together and “estimate” each task. Giving us an idea of how long the full feature will take to develop, once you add it all together.
How are deadlines and release-dates determined?
Paradox has a plan for how many expansions/DLCs we should release per year.
HOI4 release dates are determined based on: 1. that plan, 2. how quickly we can reach the desired sell-value of the release, and lastly 3. coordinated with specific dates that our marketing team have selected.
(More on this subject in next week’s Dev Diary.)
Can we make the expansion-design happen within the deadline?
After all features have been estimated; I can figure out if what we want to do is possible within the deadline. With the people at our disposal.
If yes: Huzzah!
If not: This is where I have to crush the designer’s hopes and dreams.
Splat!
We need to cut something in order to be able to finish on time.
This is something we discuss and agree on, together. While I gently pat their backs and hand them tissues.
What gets cut?
When cutting something I have to consider, for example:
- The desirability and priority of the feature.
- What people we have available.
- How much, and what, each person can work on.
- While not being blocked, or blocking, someone else.
- What features tie into other features.
(If there is anything independent enough to cut cleanly.)
In closing
Speaking of the nature of development work… While the example above mostly serves illustrate problems with communication, which is always a factor when people with different perspectives discuss something… I think it says something about how frequent certain development problems are; that a site exists where you can create your own project cartoon, like this one.
The issues that Paradox and HOI4 struggle with are the same problems that all IT projects, everywhere, grind their teeth over. It’s terribly complex work. Which is why, although the problems and risks are well known and can be anticipated and planned around, to a degree… they remain.
The silver lining, I think, is that while our problems are the same… we at Paradox have a hell of a lot of fun while working on them.
Next week, our Brand Manager will write a Dev Diary. Before handing the baton back to podcat.
Don't forget to tune into World War Wednesday today at 16:00CEST on https://www.twitch.tv/paradoxinteractive! To see podcat run Germany in massive co-op, with the other devs as generals.
Last edited by a moderator:
