Starting a new game is exciting, the ideas are flowing and the possibilities are endless. You have a great idea and ready to get to work. Soon you may find yourself facing a lot of questions that need to be answered. Maybe you’ve made a game or two before but some questions still remain. It can be overwhelming for anyone. In this post I’m going to walk you through some of the questions I had when starting Builderment and my thought process in finding the answers. The tldr of this is to make a decision and move forward!
I’d also like to preface this with these questions are best answered after you have a game idea in mind. No sense in working out multithreading logic before you know if the game is turn based or real time.
Target Platform 📱
I’m a big fan of PC games and love the idea of mobile games but most fail to grab my attention for very long. That said, I think there is a big market for base building and automation games on mobile. Currently there are a handful available but most are ports from a desktop version. I think it shows, they often have uncomfortable UI or design elements that aren’t friendly to short gaming sessions. Mobile gaming is relatively still newish compared to PC and is exciting to work in. It also doesn’t hurt that I’m an iOS developer and this is the path of least resistance to get started with.
Game Engine 💪
I looked at a few different game engines when deciding what to use for Builderment. A couple key requirements I had was that it should be fast, easy to use, and capable of what I needed. Unity was the clear winner in the easy to use and capable category, followed closely by unreal engine. However for what I want to do with this game and researching a lot of performance and optimization blogs / videos it wasn’t obvious that either of these could deliver the efficiency I wanted. With the right optimizations they may or may not be able to get there, but it’s not a risk I want to take right now.
Another thing to keep in mind is my productivity, I should be optimizing my time for developing the game and making it better every day, not fighting with a game engine that I probably only use 5% of the features. It would also be easy to spend multiple months trying out each engine and prototyping on them, but you have to move forward. So I decided on going native and writing the game in Swift for iOS.
Swift is what I’m most familiar with but unfortunately locks this game to iOS (maybe mac too but that’s another topic). Not being on Android is significant but I will use this opportunity to focus on making the best possible experience for iPhone and iPad.
Art Style - 2D vs 3D 🎨
Early on I started with 2D for prototypes and wanted to stick with it. I thought to get the best performance 2D would be absolutely necessary. However when trying to decide on an art style I really liked something with a more cartoon fantasy 3D look (read Clash of Clans). It can deliver a more immersive experience with the right lighting and graphical effects. Only time will tell if the performance becomes a bottleneck, if it does I’ll revisit this decision then. But again I decided to pick one and move forward.
Code Architecture 🏠
There are a lot of topics on the web covering game programming already so I won’t go into much detail right now but a great place to start if you’re interested is gameprogrammingpatterns.com.
One of my primary requirements for development is to be data driven. Meaning changing the content in the game should be fast and easy without needing to update code. To allow that flexibility I started using a very pure entity component system. Quickly I ran into problems needing to write hacky work arounds just to get simple things to work. Mining stone with a drill entity and placing it on a belt entity became a huge multi component/systems mess with multiple components very tightly coupled together. Maybe I did something wrong but it wasn’t working out.
After a week or two struggling with that I switched to a hybrid approach that is very loose with “structure”. Entities have duplicate behavior but makes them easier to work with. Systems do a lot more but can optimize behavior having more information available to them. I like to think of it as the “do what you want where you want to” approach. This is working out ok for me as a single developer, in a larger company the more pure ECS might be better.
I watched a talk a while ago that might have been from Jonathan Blow, I can’t remember, but it was basically about forgetting everything you knew about programming and imagine back to what it was like when you were starting out. When you wanted to have some behavior in the game you did anything at all to make it work, it didn’t have to be “the right way”. I think this is good advice, to a point. You probably shouldn’t forget everything and should keep design principles in mind while coding. But it’s ok if the code doesn’t perfectly fit some design pattern. I’m kind of rambling here but lets bring it back to Builderment. The point is, it’s often better to pick a path and start heading down it rather than stand at the crossroads or even take a few steps and turn around.
Follow and Subscribe 👍
This journey is just beginning. If you like what you read I’ll be posting more of it, hopefully weekly. Currently on twitter and instagram sharing images and videos from development. Reach out via email or come join discord!
Twitter @builderment
Instagram @builderment
Discord https://discord.gg/VkH4Nq3
Email contact@builderment.com