I didn’t have time during the holidays to implement any new features, so enjoy this filler post that I prepared earlier! In the very first post in this series, I wrote:
The prototype took place on a rectangular map, with the left side wrapping around to the right to form a cylinder. […] Many games do this and get away with it, but because I’m a perfectionist, I want my game to take place on an actual sphere.
Today I’m going to write up in some detail why spheres are harder to work with.
The previous post ended with a cliffhanger: how would we get rid of all the arid zones (pink) in the Köppen climate classification? An alternating game of spot-the-difference and whack-a-mole ensues.
Last time, I described how I’m generating different weather patterns based on the season. That data is already useful for the game, to decide the weather at one particular place and time, but it’s also essential when figuring out the local biome, which is what we’re doing today.
In the last post, we developed some basic but useful algorithms to generate temperature and rain maps for an entire year. However, these assumed that the weather is constant throughout the year. As any citizen of Earth knows, that is not quite true, so let’s fix it!
Now that we have a finalized height map of our generated world, it’s time to put something on the surface. But to know what to put there – forest, desert, grassland, ice – we have to know something about the local conditions. And to know those, we have to know about wind patterns.
There’s this game concept that has been on my mind for years, and I can’t seem to let it go. You step into the wet, salt-crusted shoes of the naval explorers of old: Columbus, Da Gama, Magellan, Cook. Most of the world is still a big unknown question mark: here be dragons. There are no satellites, no GPS, not even maps. The only way to find out what’s out there is to actually go there – which is a risky venture. Your navigational tools: a compass, the sun, moon and stars, and any information you might learn from the locals along the way. Your goal: to find a route around the world and end up where you started.
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.
As an indie game developer, I find that it’s important to invest time to get to know your tools really well, so you can make the most out of them with the least amount of time.
Mixium is a puzzle game in which you mix liquids to achieve a particular ratio. The trouble is: your beakers don’t have any scale on them, so you can only fill them to the brim or empty them into a larger beaker.
Last week, I talked about a fairly sophisticated attempt at solving my 2D discrete physics problem, which ultimately turned out to have unfixable flaws. But I need this problem solved for my game, so I decided to relax my requirements for the time being.
As I previously wrote, I recently fell in love with the Kotlin language. It’s been over four months since that post, and my enthusiasm has not diminished.