The point of 2D

The debate of doing 2D or 3D has been a long discussion internally. What turned the tides was the Game Camp: we showed the game to a few publishers who almost unanimously criticized the fact that the game was in 3D. One question that really struck with me was: what value is 3D bringing to the game? We honestly struggled to answer that question, and so went back to the drawing board, wondering what it would take to switch the game to a 2D rendering engine, how long it would take, and what long terms benefits it would bring.

There were 3 main reasons why we decided to do 2D. First, over the course of the rest of the game, it would cost us less to get to the level of quality we wanted to reach. It is easier to do pretty assets in 2D than it is in 3D: in 2D, most of the rendering is done outside of the game, whereas in 3D the game itself has to do a lot of work to render pretty things. Doing 2D removes a lot of programming work, from complex rendering pipelines to optimizations.

The second reason is that doing 2D is intrinsically less uncertain. Rendering things in two dimensions is a lot easier than it is in three, and programming is also a lot simpler. Doing 2D reduces the potential for bugs, inconsistencies between different computers, operating systems, etc.

The last reason is that we intend to release Dawnmaker on mobile phones. And phones are a lot less powerful than PCs. Doing 3D on a phone requires another level of optimizations, especially regarding graphics rendering. We'll have different problems for mobile platforms with our 2D rendering (I'll get back to that), but we expect they will be a lot easier to manage than having to deal with advanced 3D rendering techniques for smaller devices.

Rebuilding the board

So we moved our game to a 2D rendering system. What did it mean? First, a lot of re-programming features of the game: showing the board, animating things like the creation of a building, redoing the Smog entirely (but in a better way, so that's good). It also means re-thinking our assets production pipeline. With 3D rendering, Alexis could work on a building in 3D, export it with its animations, and we could quite simply import it into the game and render it. With a 2D rendering system, it gets a bit more complex. Animations require using a large number of sprites (or images, it's the same thing), that you show one after the other to create movement, just like a movie. But loading many images can take a lot of memory really fast. So, we have to be smart about how we do animations: we cannot have 200 sprites for each building of the game — we intend to have about 150 buildings in the final game, meaning about 30,000 images to load. That would be too much for many devices, including computers. Instead, we are going to split the buildings into separate elements: the base of the building, and a few animations that we'll reuse on several different buildings. This way, we intend to have one unique sprite for each building, and a few dozens of animations, vastly reducing the size of the game and the memory load.

OK, that was a bit technical, my apologies to those of you who don't care much about that level of details. Here's a treat for you to thank you for reading our newsletter: a glimpse into the new 2D board! We've changed the artistic direction a bit, using this opportunity to improve some textures and decorations, like grass and trees.

---

This piece was initially sent out to the readers of our newsletter! Wanna join in on the fun? Head out to Dawnmaker's presentation page and fill the form. You'll receive monthly stories about how we're making this game, and the latest news of its development.

Join our community!