• 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.
@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:
  • 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.

lumbergh-hawaiian-shirt.gif

(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.

yes_data.gif


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.

vtSueQywDwn2U.gif

(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.

DHzBZxSU0AAQzXL.jpg

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.)
Sometimes laying this complex puzzle, trying to fit high priority pieces together, is trickier than trying to nail jello to a wall. Things slip and change constantly. This is the very essence and nature of development work.

projectcartoon.gif


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:
I was expecting DD about upcoming game features and changes...
If you'd read last week's DD, you would have seen the following note from podcat at the top (emphasis mine):
As for exactly what these will contain you will need to bear with us a bit. As I said with us getting started on it now we need some time to actually make and test stuff before we start showing it off to you. This will mean that the next two diaries (if all goes according to plan) are going to be covering other stuff while we get ready. My plan there is to get some guest writing in from people who can talk about the business and process side of the company and team.
I personally find things like this quite interesting. Not working in development myself, it's nice to hear about what goes on behind the scenes.
 
I excepted the features and changes for next update..This is ok too but i dont think this is what community wants to see

"Hey guys, here is a concept of how we want this feature to work, it's going to be great!"
"Here's an early draft of how it works now!"
"We shelved it for now"

Is this really what you want?
Last time they did this (e.g. Air Resupply) there was a lot of bitterness.
Better wait a bit until they have something solid ready.
These kind of diaries are interesting as well imo.
 
Good show. That middle top swing seems legit. Happy the designers fixed it but less than impressed about how the devs wrote it. Feel a bit like how subs work in-game atm (tied to a tree).
 
Last edited:
All these diaries about devs journey,how do we work, promises, plans. Etc.. all getting tiresome. At least to me.
Well it's a Dev-Diary in all honesty. The team basically said it's too early to show something new (as there's not been enough time to actually flesh something out and show it yet) and that the next upcoming ones would be more along these lines. It's not as if it was unadvertised and it's not like anyone is forced to read it.
 
I personally find things like this quite interesting. Not working in development myself, it's nice to hear about what goes on behind the scenes.

I prefer not to have more breaks than we have to with diaries. I get that ppl preferably would want to get details on features etc, but rather than a break I hope people will find some *actual* development diaries interesting to read too.
 
'You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time'
 
I find this interesting, and a good read. It's always nice to know the process you guys go through. But one thing that needs improved in this is the justification for the costs of your DLC's. The general reaction to Death and Dishonor wasn't the best- due to the price for such a small amount of content.
 
I find this interesting, and a good read. It's always nice to know the process you guys go through. But one thing that needs improved in this is the justification for the costs of your DLC's. The general reaction to Death and Dishonor wasn't the best- due to the price for such a small amount of content.
If you have questions on this subject; I suggest you note them down for next week. That's when our Brand manager will write a DD and be available to answer questions.
(Pricing is not mine, or the rest of the dev team's, area of expertise.)