Marbleous Blocks Retrospect

Developing Marbleous Blocks and the Pixleon Engine has been a long but rewarding journey. Unfortunately, I have not been keeping track of the number of hours I have put into this project, but a wild guess would be somewhere between six to twelve months of full-time work. That is a lot of time, so a valid question is of course if it was worth it? Before I try to answer that question, I should probably outline the goals of the project:

  1. Create a game with at least one new/interesting mechanic.
  2. Create a game without the use of an existing game engine.
  3. Learn as much as possible about developing and releasing games.
  4. Release the game.

The first and second goal have already been reached. The third goal is a bit hard to measure but I have learnt a lot of new concepts, both technical and non-technical. Concerning the fourth goal I expect to reach that in eleven days. So just by looking at these goals I think this adventure has been a great success. Could some things have gone better and faster? Definitely. Would I have done things differently starting out today? Absolutely. But to me answering yes to these questions also means that:

  1. The project was non-trivial (for me).
  2. The project improved my knowledge of the problem domain.

So, what went good and what could have gone better? I like lists so here we go.

The Good:

  • Looking back, I think that deciding to write my own engine helped me stay motivated.
    • It was an interesting technical challenge.
    • I could focus on programming and finding flow instead of reading manuals.
    • I was constantly learning new things and thereby improving my skillset.
    • I created a clear separation between the engine and the game. This means that in the end I did not only get a game I could release I also got a slim and capable game engine. The separation also helped with build times, debugging etc.
  • I wrote the build system (basically how to produce the executable game file) myself which did not only give me a better understanding of this, but it also made it very easy to integrate new libraries. On top of that I could tweak the build system to do minimal rebuild which saved me a lot of time and improved my “quality of life”.
  • I wrote a “graphical debugger” early on. What I mean by that is that I made it trivial to add bounding boxes with wireframes, creating lines, spheres and so on. This is extremely useful when developing a game, especially a 3D-game.
  • I talked early about releasing Marbleous Blocks which gave me some positive external pressure. During a period of six months, I even took one day a week off to work on the game, adding some more external pressure.
  • I shared progress early with friends and got some valuable feedback. This also boosted my motivation to keep going.
  • Early on I decided to keep things simple. That meant:
    • No huge worlds.
    • No fancy character animations.
    • Minimalistic graphics.
  • I finished the game. Completing projects is harder than one might expect. I claim that completing projects is a skill. Just like any skill it can be improved through training. From my perspective the key is to cut corners without sacrificing something you know you will need. Making the right decisions here comes from experience and experience is something you gain by failing, reflecting, and improving.
  • I bought a new computer which greatly boosted my productivity (thanks Goran Esmail for the build). My old Intel i7-4770K served me well for years but my new AMD Ryzen 3700 is a monster compared to it.
  • I wrote a diary of accomplishments I did while working. I also planned each “work session” beforehand which meant that many times I had a good understanding the problem I was going to work on before I started typing.
  • I used milestones which I revised on a regular basis. This helped me to stay focused on the most important aspect of finishing the game.
  • I started communicating about the game on this webpage which naturally forced me to reflect on the development process. It is also fun to have some documented steps of to look back at.
  • I have learnt a lot about the Steam platform. I am still far from an expert, but I know the fundamental things.
  • I postponed optimization until late which pushed me into attacking the parts that mattered, like 3D-model loading for instance.
  • Used Bullet for physics. Writing my own physics engine would have taken alot of time. I have gone down that route before…
  • Used FMOD for sound. It is an easy-to-use API that had all I needed and much more.
  • Instead of relying entirely on the STL vocabulary I ended up wrapping the STL classes in my own containers. This allowed me to use more concise naming. I am not too fond of push_back etc.

The Bad:

  • I thought I was going to release this game in March 2020. Creating the level editor took longer than I expected and even though I decided to keep things simple I still grew the scope a bit to make the game a bit more interesting.
  • I integrated Lua as a scripting language but ended up never using it. It was a nice learning experience but once I had the level editor, I no longer needed Lua to create levels.
  • I had no “test farm” of computers. Late in the project I learnt that I had some problems with AMD GPUs and OpenGL. It would have been nice to discover something like this much earlier, but it would also require me to invest more time into testing earlier. As usual there is a sweet spot but I think I was pretty far off when it comes to testing on various machines. This is a nice argument for developing a game targeting a console with very specific hardware. Chasing driver/hardware bugs is not fun business.
  • I did not think about the story element of Marbleous Blocks until very late in the development process. When I think about games I really enjoyed playing, and why I liked playing them, story is not the first thing that come to mind. I prefer a very polished interaction model, where you really feel you are in control, along with great graphics and sound. However, during this project I have learnt that story should not be overlooked. I think that having a solid story can lead to a clearer design and deliver an experience with more layers. I will keep this in mind for future game projects.
  • I did lose some license information about some of the sound assets I am using. It was tedious to track these down again.
  • It was hard to find good hours to focus on the game while working full time and taking care of kids. Do not get me wrong, having kids is great and it gives me a lot of positive energy but there is only 24 hours each day.
  • Around two years ago I learnt about a neat library called Live++. It allows you to edit C++ programs while they are running - a great productivity boost. For some reason I never started using it for real. I think I should have.
  • I did not show the game externally until very late. I have learnt that for your game to stand a chance to become a commercial success you really need a strong community around it.
  • Maybe, just maybe, I should have tried to deliver a game in another genre. Do not get me wrong. I really like the result of Marbleous Block but there are a lot of puzzle games out there. It can be very hard to stand out from the crowd even if you have an interesting game mechanic. Thinking about marketing very early is something I will bring with me for future game projects.
  • PC might not be the ideal platform for a point & click game like Marbleous Blocks. A tablet would probably have been a wiser choice. I wanted to finish a game and doing it for PC was the fastest way to achieve that goal.
  • Did not use SDL or the like. Sure, I got a better understanding of the win32 API but if I would have used SDL I would have gotten Linux/Mac OS support with less effort. I may still go down that route.
  • I wanted to release early but releasing a puzzle game early can be hard. The replayability aspect is limited. For the next project I probably want to release an initial version much earlier, but this means I need to design a game that deliver a new experience for each session.
  • Postponed tracking allocations until very late. Once I got a nice hash map tracking allocations together with file and line number it was fairly easy to find all the leaks. I could have done this much earlier.
  • Should have written a small script for generating classes. Even though Marbleous Blocks may seem like a small game I wrote 100+ classes for it. There are a lot of tedious work when creating a new class in C++.

So again, was it worth it?

I definitely thinks so. From a economic stand point Marbleous Blocks will most likely not change my life, but from an experience point of view this journey has been very rewarding. I really love imagining something and entering what sometimes seems to be an endless loop of thinking, typing and testing. Well, the loop is finally finding its break point, at least for this time.