Okay, let's conclude this with a super quick&dirty post mortem!
The game has been released for a couple of weeks on PC, Mac, Linux, PS4 and Xbox One now. We've shipped the first patches and received a number of reviews. While we of course aren't too happy with the low metacritics value (60-70) the sales have been pretty good. We're going to reach break-even before entering into the "Sales" part of the product lifecycle. That's especially great because the game has only partially been funded with publisher money so some considerable part of the profit will end up with the developer. (which sounds like it should be the normal way of things but really is not)
So, in two ways this has been a stepping stone for us: We've made a successful debut in a much more difficult genre (RPG, instead of point&click adventures or turn-based strategy as our previous titles) and the returns will help us develop an even more ambitious game next.
The approach to develop a custom physics & combat simulation in vanilla C# outside of Unity and to use that as the basis for the ingame combat encounters paid of. Of course it takes a lot of time. But the biggest plus is that this approach eliminates risk and puts you in control as the code is not a blackbox but well understood. If you rely on Unity native functionality and plugins you're effectively working with blackboxes and if something doesn't work out as planned (or is plain buggy) it's often not clear how to "fix" it. You're also more limitted by techonological constraints in your gamedesign if you don't control all the details.
An area where that kind of control isn't so critical is the presentation/visualization. This is the first game where we didn't spend a lot of programmer time on writing shaders or custom rendering code and instead looked for 3rd party solutions wherever possible.
While we will stick with that general strategy for our next title the approach as executed in DWARVES wasn't without fault: Developing HORDE (the combat simulation engine) parallel to making the game meant that we had to wait for the systems to arrive before we could really finalize the gamedesign. "How does the game play and will it be fun?" is a question you should be able to answer as early as possible. But our focus on technical features ("fight with a small group against large amount of foes in melee combat") that would make the game unique and true to the book meant that we took a bet on this approach to also yield a fun game.
If you look at the meta-critics that didn't work out too well. But to be honest it's more complex then that: Reading the actual comments and reviews to find out what players liked and what they disliked you'll find a lot of contradictions. Some liked the combat some didn't. Some liked the turn-based strategy parts (played out on the boardgame like world map) some found it superfluous. The same goes for the story-telling, the control-scheme etc... by making a game that was part point&click adventure, part action RPG with twist (control 4 characters simultanously instead of only one) and part turn based strategy with the additional goal to faithfully tell the story of popular fantasy book (that was written without a videogame in mind) we made a game where it was very hard for players to like all elements of. Especially as the combination also meant that non of the individual parts reached the depth that it could have if this part would have been the core focus of the game. I think in the end we raised expectations (some intentionally some not) that we then didn't really meet. At least not for all players alike. For us making something unique felt important but for the metacritics sticking to an established formula would have been better.
In addition to all this the technical execution wasn't flawless. We gave the different locations (the game is split into a couple of dozens unity scenes) into the hand of individual artist that would create a scene in Unity based on a general description. At that point the combat/gameplay that would happen in these scenes was roughly planned but not prototyped and tested. So we would first finalize a location and then implement the gameplay and because the scene couln't be changed anymore without incurring extra development cost the gameplay suffered. So the locations have oftentimes a cool atomosphere - more like places and less like disguised playgrounds as the levels in other games often feel to me - but at the cost of the gameplay not being as fun and smooth as it could be.
To make matters worse when locations where put together we didn't monitor the impact on performance enough. If it was running smooth on the artists computer he felt like everything was fine - even if it wasn't smooth the expectation was that engineers would be able to optimize that later. Well, turns out that some of the optimizations necessary to get close to the target framerate of 30 fps (which isn't what many games would call smooth in the first place) we had to cut down on the simulation elements and sometimes reduce the scenes visual quality at the same time.
This was a reminder of something that we should have known in the first place: It's a good idea to grey-box levels and focus on the gameplay first. It's also important to monitor resource and performance budgets throughout the development process and not consider it as something that can be done as part of the "polishing" phase in the end.
If you got questions, let me know. I can go into more detail if requested but for now I think the post has grown long enough allready.
Community
