« Newer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Older »
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. I have coded some menu screens too, but they don’t yet show the correct data and most of them don’t even fully work yet.
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. What is it that makes Death Rally so compelling? What got me hooked, and kept me hooked? Most importantly: which of these elements can I use in my own game? Here’s a somewhat nostalgic, entirely subjective, and utterly unscientific analysis.
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. He searches the surroundings for potential objectives, divides the benefit of each objective by the cost, then instructs the Navigator to head for the best objective.
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. I like to name my classes after corresponding real-world things, so these are called the Driver, the Navigator and the Manager.
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. The emulator that ships with the SDK is too slow to make the game run smoothly, and multitouch cannot be used on an emulated device. It would be possible to record a game session, then play it back at a slower speed while recording, but it would be hard to get sound, and it’s a lot of work anyway. It seems that the only viable option is to point a camera at the phone and live with the bad video quality. Oh well. Here it is.
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.
There was a permission problem that sometimes caused comments to be refused with a 500 Internal Server Error. This has now (hopefully) been resolved.
I also added clickable links to the Atom feed for the blog, because some browsers (Chrome, and Firefox 4 beta, but strangely not Firefox 3) do not show the feed icon in the address bar.
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. This is a very good question, so in this post I’ll address some of the design decisions I made along the way.