Feature cuts
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.
Feeds
Browse by tag
- Game Development (48)
- Programming (38)
- Cart Frenzy (28)
- Game Design (27)
- Algorithms (22)
- Around the World (19)
- Archimedes (18)
- Business (14)
- Graphics (10)
- Experiments (9)
- Planning (9)
- Rocket Mail (9)
- Website (9)
- Artificial Intelligence (8)
- Dragon Attack (7)
- Bigcanvas (6)
- Twistago (6)
- Alakajam (5)
- Ludum Dare (5)
- Patchy (4)
- Turtle Paint (4)
- LibGDX (3)
- Audio (2)
- Godot (2)
- Blokjes (1)
Posts tagged “Cart Frenzy”
Bits and pieces
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.
Threading
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. This work involved quite a bit of refactoring (which is jargon for “creating new problems to replace your old ones”), so I now have a bunch of screenshots of things… not working the way they should. Because this is a long and technical post, I will intersperse them for comic relief.
In-game graphics
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.
Title screen
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.
Let chaos reign!
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.
Toast!
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).
Game architecture
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.
Performance measurements
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.
Activity flow
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.
Menu layout
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.
Game structure
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.
Death Rally: an analysis
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
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
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 driver, the navigator and the manager
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.
Moving pictures
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.
Fragments
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.
Back to roots
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.
Intelligent design evolution
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.
Driver code
There are a handful of racing games that let you race purely against your own best time, but the majority of them let you race against others. It adds an element of competition that you don’t get when racing alone. The solitary racer is someone who spends hours trying to figure out the optimal way to tackle that sharp corner, just to shave a tenth of a second off his best time. Not the kind of audience I’m targeting with a somewhat (albeit not completely) casual mobile racing game. Long story short, I need opponents.
More 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! […] I will need to consider carefully whether this is going to be a real problem, though.
Controls
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.
Texture compiler
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. So I devised the GLT (GL Texture) format, and wrote a program called gltc to convert PNG files to GLT.
Model compiler
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. I started with the models.
Level editor
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. One of the most important tools to have is a level editor – you really don’t want to put all objects into a level by typing long lists of coordinates. Building the editor has kept me busy for the past few days.
Change of direction
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. You’d be a beaver, and you’d have to use twigs and branches, floating in the water, to build a dam.
A little experiment
My mind is always full of ideas that I’ll never have time for. But occasionally, one of them does get executed. This is one of those times.