I’ve decided to kick off this devlog with some retrospective posts about when I first picked up game dev and to create Martian Medical. Cast your mind back to 2015…
I had decided to learn C++ and games programming from moderately low level, so with a little searching around I decided to do my early learning and Martian Medical prototypes with SDL2. It was around the same time that a friend of mine was learning Unity, and we often argued about which was better. In reflection my interests skewed towards programming and his toward game design, so I think we were both on the right track with our choices. Unity is a fantastic tool and he now has a bunch of games under his belt, but I was keen on how things worked under the hood first.
Between studying full time, working part time, and expecting my first kid, I would spend an hour or 2 most evenings learning and writing terrible code. The first goal I achieved was to create an isometric world that I could interact with by building some floors and walls, as well as an interface to support it.
I was super proud of this when it finally worked! Compiling some code and seeing it work remains an extremely rewarding experience. It’s as simple as it looks: an isometric grid with tile-picking, and sprite swap on the picked tile based on the active button. This version also had some zooming and panning of the world.
Creating this with SDL while learning C++ was fantastic because it taught me some of the key basics of games programming including:
- Game loops and frames per second
- Input processing from mouse and keyboard
- Texture loading and the graphics pipeline
At the time, armed with this knowledge I felt like I could create anything! But I quickly hit new hurdles and discovered how naive I had been.
- The project was not built to be scalable. My classes were written to achieve the above goal, and they did, but they couldn’t do any more than that. It’s not feasible to update your whole engine each time you need a new feature, I would have to plan ahead.
- My UI was very basic – a simple button class with 1 texture, no free text or font rendering, scrolling boxes or overlays hard coded to a set resolution.
- There was no sprite batching – each tile was a draw call to the gpu, not something to see until you add more textures on a huge maps and your game grinds to a halt.
- I’m not actually building walls! Videogames are great at creating these illusions and I really fooled myself on this one. All I am doing here is changing the tile graphic, not actually building a wall object. This build had no real game objects at all, so real meat of the game was still grazing in the paddock.
I definitely had some naïvety about game development when I first started, and wasn’t truly expecting just how much time and effort it takes to create some of the amazing games we see today. This is part of the reason why I eventually shifted from SDL to SFML, where I could create my own engine using their base classes that saved me a lot of time that I could then spend on game design.