일지 HOI4 개발일지: 우리의 개발 과정 (미번역)

[고독한게이머]

https://forum.paradoxplaza.com/forum/index.php?threads/hoi4-dev-diary-our-development-process.1041735/

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

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

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.

 

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.

이번에 왜 개발일지 번역이 없을까 하고 한 번 찾아봤습니다. 혹시 보지 못한 분도 계실까봐 그냥 미번역으로 올립니다. 다른 분이 번역해서 올린다면 그 때 이 게시물을 내리도록 하겠습니다. 그런데 이걸 굳이 번역할 필요가 있는지부터 의문..

간단하게 축약하자면 DLC 언제언제 낼 건지, 버그 처리는 어떻게 할 건지 그런 식의 이야기들 뿐인 것 같습니다. 결론부터 말하자면 다음 패치 관련 내용은 없어요 ㅇㅇ 아마 다음 주부터 제대로 나오지 않을까 싶습니다.

이번 개발일지의 댓글들도 비아냥대거나 부정적인 의견이 많은 편이네요. 이번 개발일지에 대한 판단은 여러분이 하시길.

[엔리코 단돌로]

결론:이 새X들 진짜 일안함
2연속으로 주저리만 하지 다른팀처럼 뭘 만들겠다고 구상한거 결과물을 보여준적 한번도없음

이로서 호4의 문제점이 캐주얼화?코어 게이머 포용실패?이런 문제가 아니라는게 밝혀짐.

......그냥 개발자들이 천하의 개XX들인것일뿐

[네트]

뭐.. 일단은 저번 개발일지의 첫 문단에서 2주 동안 이런저런 썰 풀고 재정비 시간 갖춘다고 했었다네요.
저도 첨에 충격 먹고 이 무슨 짓이야 했는데. 음. 흠. 험.. ㄴㅁㅇㄹㄹㄴㅁ

[고독한게이머]

네, 그런 이야기가 있었습니다. 그래도 막상 개발일지가 진짜 그렇게 나오니까 슬프네요..

[고독한게이머]

네, 그냥 팀이 어떻게 일하는지 간단하게 쓰고 끝나는 일지도 몇 개 있더라고요. 그런데 뭔가 보여줄 것처럼 대대적인 예고하다가 이렇게 넘어가는 건 처음인지라 ㄷ

[무영]

에휴 재미라도있으면 피식이라도 할텐데 이건뭐 감동도없고 재미도없고..

[괴도p]

호이4 개발자들만 유독 일을 안하는 느낌...

[루니메이 뇨왓]

번역...번역이 필요하당!!!!

[홀리 머커랠]

이게 개발자 일지인지 신변잡기인지... =_=;

[C_sTylE_M]

아직 미완성이지만 발전가능성이 무궁무진한 호4인데.. 좀 일좀하자

[Malach]

휴가 갔다와놓고 또 몇 주를 밍기적거리네요. 지난 1년 간 내놓은 결과물이 좋았다면 모를까 이런 상황에 지네들 개발철학 운운하는 걸 보니 그저 실소만 나올 뿐..

[칼슘]

빼애애애액?

[푸른늑대어윈]

게임으로부터 막대한 수익을 얻어내려고 빨대 꼽지 않는 이상 느긋하게 일하는 것도 이해는 되네요.

[책읽는달팽]

아... 다음주에도 이런거 나옵니다.