Posts tagged “Cart Frenzy”
◂ Back to all postsBack 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.
Continue readingGame 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.
Continue readingMore 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.
Continue readingAs 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.
Continue readingLike 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.
Continue readingI’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.
Continue readingI 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.
Continue readingAlthough 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.
Continue readingAfter 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.
Continue readingIn 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.
Continue readingLike 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.
Continue readingSorry, 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.
Continue readingRecently, 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.
Continue readingThe 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.
Continue readingThe 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.
Continue readingThe 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.
Continue readingIt’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.
Continue readingAfter 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.
Continue readingDue 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.
Continue readingAfter 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.
Continue readingThere 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.
Continue readingLast 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!
Continue readingAlthough 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.
Continue readingAfter 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.
Continue readingHaving 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.
Continue readingDoes 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.
Continue readingI’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.
Continue readingMy 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.