Back to work after a much-needed break, I have gained a better perspective on the current state of the game. I concluded that, if I am to finish this game on time, I’ll have to reduce it in scope significantly.
Game development can be a pain sometimes. Remember my writings on threading last week? This week has been more of the same kind of stuff: engine improvements, code cleanups, bugfixes, and only some small new features that are actually visible.
More work on performance this week. Things were getting a bit too slow for my tastes, meaning that they would likely be unplayable on medium-end phones.
As announced, I made a large sprint this week to bring the artwork closer to completion. I think it’s about halfway done now, but I’m getting more and more experience with this, so the second half should go a lot faster.
Like I announced, lots of work on graphics. In-game graphics are beginning to come together, but are only halfway done, so the overall result still doesn’t look too good.
I’ve been looking at my crappy placeholder graphics for too long. Every time I launch the game, a tiny voice at the back of my mind tells me how shitty it still looks.
I more or less finished one of the first powerups that you’ll encounter in the game: the toaster. When you pick it up, it appears in the item box at the top right.
Although games vary wildly in appearance and mechanics, the structure of the underlying classes and objects is often similar. There is a “world” object, which contains everything else; there are multiple “entities” representing stuff in the world, there’s a “renderer” which tells each object to draw itself, etcetera.
After a week partly filled with lots of food and other Christmas celebrations, I’m back on track. I’ve done some polishing to make the game more game-like.
In Android, generally speaking, each different screen presented to the user is called an ‘activity’. Until recently, the only activity in the game has been the game itself.
Like last week’s, this post is a day behind schedule as well. Since I’m working on my part-time side job on Tuesdays and Wednesdays, it was a silly schedule anyway – changing to Thursdays to accommodate.
Sorry, no screenshots or videos this time. Instead, I’ve worked on the overarching structure of the game, the bits that should make you keep coming back.
Recently, I’ve become mildly addicted to the old-school top-down combat racing game Death Rally. Now, I’m not really prone to addiction, nor am I particularly good at racing games, so I found this quite interesting.
The manager is the third and final part of the game’s AI. He is responsible for the high-level strategic decisions.
The core of the manager is very simple.
The Navigator is the part of the AI that is responsible for pathfinding. Actually, his algorithm is fairly straightforward. Given an objective by the Manager, the Navigator determines the shortest path through a series of waypoints that are defined in the level file, then hands each waypoint in turn to the Driver.
The new AI is making good progress; I’d say it’s about 90% finished. (The other 90% remains to be done.) After writing the code, it cleanly fell apart into three largely independent modules.
It’s difficult to do a screen-cast of an Android game. You have to root the device to even take a screenshot, and with the game taking up most of the CPU, a live video is out of the question.
After deciding in which direction to take the game, the last few days have been a matter of implementing this. Due to various circumstances I haven’t been able to get as much done as I would’ve liked to, which is why this post is relatively short and fragmented.
Due to other activities, I haven’t gotten round to much coding in the last few days. However, a lot of thinking happened that is equally, if not more important.
After seeing the last few posts, someone asked me why I’d gone from the original item-gathering concept to a more customary around-the-track racing game with more customary controls.
Last time, I wrote:
My brother probably expected the cart to make a turn if it was pushed on one side. Instead, it would spin around its axis, but keep moving in more or less the same direction!
Although I’d previously determined that the controls of the cart worked nicely on a touch screen, they were nowhere near perfect yet. This is one of these aspects that can make or break a game, so it’s important to address it as early as possible.
After the model compiler comes the texture compiler. Decompressing a PNG file on Android is possible, but the loading code is simpler if the texture is already available in a format that we can feed directly to OpenGL.
Having a level editor is a good start, but it’s not all. We need some kind of workflow to create models and textures and eventually get these to show up in the game.
Does a carpenter create his own hammers? Does a painter make his own brushes? Usually not, but a game developer often needs to build his own tools to get a particular job done.
I’ve decided to change course. Drastically. The fluid engine works nicely, and although it’s fun to play with, it’s not exactly a game just yet. I had this idea, which I alluded to in my previous post, of making it into a creative construction game.