Here’s a thing I’ve been working on since January: Blokjes!
Sorry, your browser does not support embedded videos. 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.
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.
This is the second part of this postmortem. Catch up on the first part here.
Sunday morning: controls and gameplay We have fire, we have buckets of water, we can get the buckets to the fire… now what?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.