« Newer 1 2 3 4 5 6 7 8 Older »
The first real money I ever made from game development was on Android. It was in 2013, when Android was still the underdog compared to the iPhone, and was being touted as a great platform for developers.
I’m having a bit of an “off” day today, so let’s do something fun, even if it’s rather low priority for the game: generating foreign languages.
Maps will be an important part of the game. Let’s take a look at how we can draw those!
The code repository in which I’m developing Around The World is called aroundtheworld4. That might make you wonder: what happened to the first three? Today, let’s take a look at aroundtheworld2.
All else being equal, I prefer games (and books, and movies) to be realistic, rather than making things up on the spot. But of course, all else is rarely equal. Today, I’ll be taking away some of the realism of my procedural world generator to accommodate gameplay.
I’ve been investing a lot of effort in the generation of plausible land. But the game is all about sailing, so most of the screen will be filled with water, not land. It’s time to take that smooth blue plane that served as the sea, and make it look better!
In the previous post, we got to see our generated world at close range. This revealed some precision problems that I knew I’d need to deal with eventually, but had been putting off for a rainy day. Now I could ignore them no longer.
As mentioned in the previous post, the player will never see our procedurally generated world all at a glance. They’ll be much closer to it, and seeing only a small part at any given time. Let’s see how we can go from coarse, global world maps to something that will actually look good at close range!
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?
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!
We now have prevailing wind patterns going, so it’s time to turn to the other two important parameters that define the weather: rain and temperature.
In the previous post, I described a failed attempt to solve this problem of converging winds:
Last time, we got some basic wind patterns going. However, there’s still a problem.
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.
In the last post, we added the effects caused by tectonic plates:
In the previous post, we tackled generation of continent shapes using Voronoi cells and set some base heights using curves and simplex noise: