So far, I’ve been talking about generating a world at a very large scale for the game. But the aim of the game is exploration, so the player will rarely, if ever, get to see the entire planet at once. Which raises the question: what will the player see?
Here’s a thing I’ve been working on since January: Blokjes!
In case you can’t tell from the video, the idea is very simple: you get a sequence of blocks (polyominoes) that you have to place on the board. Each of them has to fit entirely on black, or entirely on white squares, and the squares that you place it on will change colour. As the game progresses, the blocks increase in size, so you have to look and plan ahead to make room for the bigger ones.
Alakajam is a relatively new game jam based on the Ludum Dare formula. You get one weekend to build a game from scratch, without using any premade assets. The theme of the 6th edition was “Duel”, and I teamed up with my pal Marten to make something. That something became Code of Honour:
This is the second part of this postmortem. Catch up on the first part here.
We have fire, we have buckets of water, we can get the buckets to the fire… now what? Throw ’em, of course! So if a peep in state PASSING sees that its destination cell is not manned, but rather flammable, it will throw the water onto the fire. (It will also do this if there is no fire. I played with the thought of keeping houses wet to prevent them from catching fire, but didn’t get round to implementing this.)
This weekend was the third instalment of the Alakajam! game jam. I was really happy about the shortlist of potential themes, so I knew this was going to be a fun one. The winning theme, “Always growing”, was my second choice.
Just a short post to share something I’ve been working on that mightily pleases the Kerbal Space Program player in me. In testing Orbital Express, it became clear that having three controls (compass direction, inclination, and launch speed) is too much for beginning players. So I decided to simplify the first two levels:
Virtual reality seems to be all the rage in gaming these days. Everyone seems to be buying into it. Big corporations like Facebook (Oculus Rift), Sony (PlayStation VR) and Microsoft (HoloLens) are pouring money into VR as if it’ll be the biggest thing since sliced bread. But right now, few people who aren’t game developers actually own the necessary hardware. Will it all be worth it in the end? I think not.
For my game Orbital Express, I need a list of cities that can serve as targets for the player to aim at. We’re trying to select cities that…
After Ludum Dare, it’s back to working on the game I blogged about last week. Name clashes notwithstanding, I’ve decided to call it Orbital Express after all. As I mentioned, there is work to be done on progression, balancing and scoring.
I’m proud to announce that Frozen Fractal’s first Android release, Patchy, will soon be featured in the Google Play Store! I guess that means it’ll get a big banner at the top of this page, which is sure to drive some eyeballs my way. I don’t know what it is exactly that I did to make this happen, so I’m going to document what I did, in the hope that it’s useful for other developers out there.
A good selection of words is essential for a fun drawing-and-guessing game; they must neither be too easy nor too difficult. However, I’m thoroughly lazy, so I was not going to compile a word list by hand.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I’ve been doing more experimenting with the engine, trying to come up with a workable puzzle concept. Below are some videos and reasonings.
First off, the game objective. Assuming that it’ll have something to do with the fluid, one possibility is that the player has to make the fluid flow in a particular way or direction. We could represent this as having to “paint” particular objects with colours that are injected into the fluid. For example, in the video below, the player would have to paint the top box red and the bottom box green. (The opposite would make for a rather more difficult puzzle!) The boxes don’t yet react to paint in any way.
This week has been one of mostly refactoring. I’ve been streamlining the code to make it easier to add new objects and features later on. This will prove useful, because the gameplay clearly needs a lot more experimenting to get it right.
In the days of MS-DOS, things were simple. If you developed a game, you usually wrote it for one specific VGA or SVGA resolution, such as 320x200 or 640x480. If someone’s video card did not support this resolution: tough luck.
From my previous posts, it must now be clear that free-surface fluid dynamics is hard. This is mainly caused by the free surface. Without that, it is possible to write a fluid-in-a-box in a little over 100 lines of C code, as Jos Stam did in his paper Real-Time Fluid Dynamics for Games. However, I could not go down that road. I needed the free surface. I wanted my game to have waves, droplets, splashes, sprays, fountains! How these would make a game, I would figure out after I got the simulation to work.