At the end of the summer I've decided to start a small game project which I had hoped would help me to grasp some of the main concepts of game programming. I figured I would make a kinetic/visual novel type of 'game', with minimal interactivity. However, I didn't want to settle with a barebones project with static graphics that would simply show up on the screen when the game advances. The quality bar which I choose is not really from classic visual novel genre, it is Supergiant Games' Pyre (pictured below). This is a hybrid game which combines narrative parts, done in a form of visual novel, and 'fantasy football' gameplay. The visual novel part of the gameplay is what interests me in this particular case. Setting aside the aesthetics (which are great), the aspect which I would ideally like to try to reproduce is the amount of 'dynamics' of the art elements on the screen - interaction responsiveness, transitions, animations, sound fx etc. They have certainly managed to create a very rich experience with static art elements, which I have rarely seen in classic visual novels (I don't really play visual novel games but have done some research in preparation for the project).
I have decided from the start that I wouldn't use an established game engine for this project. I've done some experiments in Unity prior to this, and have become aware after a while that Unity does things a certain way which abstracts away aspects of game programming a little bit too much. Other than that, it caters to wide range of game genres and has a huge API as a consequence. That is ok in general, that's the purpose of a game engine after all, to make things easier for as many people as possible. If I opted to make a project which is more complicated, or which uses 3D graphics (an entirely different matter when it comes to complexity), I would probably choose Unity or Unreal, because I don't want to spend years on a single test project.
For this particular game I choose to use C++ and some basic libraries to get me going. This is hopefully going to allow me to get a firmer grasp of what is going on with the game on the frame level and what it takes to get the image rendered on the screen. After a few months of working on it in my spare time, I can definitely say that it has been a learning experience, but also that the amount of things which need to be taken into consideration is larger than anticipated. Not by a lot, but every time I hit a certain milestone, i realize that it opens up a new plane of problems to be solved. It was especially hard to predict the amount of work in the auxiliary parts of the codebase, such as data loading, asset management, entity system, scripting setup etc. In other words I am learning about the scope of the work while I am doing it.
When it comes to art assets, that is the most underdeveloped part probably. The art shown in this post represents mockup assets just to have something with which I can test out code. Everything regarding the art part of the project is subject to possible change, including the theme (which is an afterthought anyway).
When it comes to code, these are the features which are currently implemented (in varying states of completion):
The implemented features seem like there is a lot there already, but the game is still very much barebones. I still haven't left the woods when it comes to basic architecture underlying things in order to start scripting gameplay events properly. But the progress has been constant and steady so far. The project suffers from all kinds of child diseases for sure, because almost everything is completely new to me. The only hard rule I have so far is to avoid dynamic allocations during gameplay, to separate input, update and rendering sections of the game, and to try to update and render only the entities which need to be updated and rendered at any given frame. And that is about it. Any form of sophisticated tuning of the game is probably going to be outside of the scope of this project or maybe addressed once the structure is there and if there are some obvious bottlenecks.
I will post some individual articles on various aspects of the project on the blog, about certain problems which I found particularly interesting along the way. I wouldn't use them as a guide of any sorts, just as a journal of making a bunch of mistakes en route to building something which will hopefully be functional in the end.