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.
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.
Well then, since last Monday, the Frozen Fractal website is unofficially up. And since today, it’s official, because now there’s a blog post announcing it!
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.
Beavers live on wood, bark and aquatic plants. I would have guessed that they ate fish, but they don’t.
Beavers can hold their breath for up to 15 minutes.
No truism is always true, not even this one. I recently clashed with two common conceptions in software engineering:
“All problems in computer science can be solved by another level of indirection.