« Newer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Older »
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. Every time I show it to someone else, they comment how they initially only saw the red handle, not noticing that a shopping cart was attached. Clearly, it’s time to add some artwork.
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. You can then tap a point on the screen, and your cart will fire two rapidly spinning slices of crispy brown toast in that direction. If a slice hits an opponent, they’ll drop $1 worth of items (currently, one orange). But if both slices hit the same opponent, the second one will do triple damage, for a total of $4. Therefore, good aim and timing are beneficial (though not essential).
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. My game is no different, but still contains some interesting aspects that I would like to highlight.
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. I’d already added a few menu screens this week, like you saw before, and have now been working on putting it all together.
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. 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.