Around The World, Part 19: Constructing languages
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.
Feeds
Browse by tag
- Game Development (48)
- Programming (38)
- Cart Frenzy (28)
- Game Design (27)
- Algorithms (22)
- Around the World (19)
- Archimedes (18)
- Business (14)
- Graphics (10)
- Experiments (9)
- Planning (9)
- Rocket Mail (9)
- Website (9)
- Artificial Intelligence (8)
- Dragon Attack (7)
- Bigcanvas (6)
- Twistago (6)
- Alakajam (5)
- Ludum Dare (5)
- Patchy (4)
- Turtle Paint (4)
- LibGDX (3)
- Audio (2)
- Godot (2)
- Blokjes (1)
Posts tagged “game development”
Around The World, Part 18: Charting the seas
Maps will be an important part of the game. Let’s take a look at how we can draw those!
Around The World, Part 17: World generation in the prototype
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.
Around The World, Part 16: A matter of scale
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.
Around The World, Part 15: Making waves
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!
Around The World, Part 14: Floating the origin
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.
Around The World, Part 13: Zooming in
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!
Around The World, Part 11: Everything is harder on a sphere
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.
Around The World, Part 10: Fixing the climate
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.
Around The World, Part 9: Climate
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.
Around The World, Part 8: Seasons
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!
Around The World, Part 7: Temperature and rain
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.
Around The World, Part 6: Wind hacks
In the previous post, I described a failed attempt to solve this problem of converging winds:
Around The World, Part 5: Wind pressure
Last time, we got some basic wind patterns going. However, there’s still a problem.
Around The World, Part 4: Basic wind
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.
Around The World, Part 3: Hotspots and erosion
In the last post, we added the effects caused by tectonic plates:
Around The World, Part 2: Plate tectonics
In the previous post, we tackled generation of continent shapes using Voronoi cells and set some base heights using curves and simplex noise:
Around The World, Part 1: Continents
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.
The Great Fire postmortem, part 2/2
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? 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.)
The Great Fire postmortem, part 1/2
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.
Jumping aboard the Godot train
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. This is often at odds with the urge to try something new and different, which will set your productivity back to square one. But with the eagerly awaited release of Godot 3.0, I felt that the day had come to check this thing out, and see if it could be of future use to me.
Mixium postmortem
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.
Discrete physics on a 2D grid: back to basics
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.
Discrete physics on a 2D grid: a dissatisfying solution
In last week’s post, I discussed my first two failed attempts at creating something like physics on a 2D grid. It gathered a good deal of attention on Reddit, with several replies from people claiming to have solved it, only to introduce new problems. As I already knew, this problem is surprisingly tricky!
Discrete physics on a 2D grid: how hard can it be?
In the last post, I described my requirements for a 2D discrete physics system I’m working on. Now that I’ve laid out what the system should do, let’s turn to the implementation.
Discrete physics on a 2D grid: setting the stage
For a new game I’m working on, I need some 2D “physics” that work in discrete time and discrete space. In other words: every object consists of one or more blocks aligned to a square grid, and time advances in turn-based steps. If you’re thinking of Sokoban, you’ve got the idea:
Texture compression on mobile demystified
If you’re developing a game for mobile devices, chances are you have run into the words “texture compression”. Texture compression helps to keep video memory usage down, reduce download sizes and loading times, and may even reduce power consumption. In this article, I take a comprehensive look at what the options are.
Choosing an HTML5 2D engine
Because Dragon Attack’s performance on Crafty.js was disappointing, and the libGDX port also had problems running smoothly when compiled to JavaScript (plus some unfortunate technical decisions I made along the way), I’ve decided to go for a third rewrite, using better tech. (“Rewrite” sounds worse than it really is – we’re talking about a two-day Ludum Dare project, after all.)
Facebook integration in Dragon Attack
Always new things to learn! This week, I integrated Facebook highscores into Dragon Attack, so you’ll be able to see your friends’ scores and challenge them to beat yours. I’m hoping this will give the game more lasting appeal, not to mention some ‘virality’.
A week of dragon stuff
With Mystery Game No. 1 in private beta, while I’m waiting for feedback, I’ve had all week to dedicate to Dragon Attack. A lot remains to be done, especially in the tweaking and balancing department, but there has been a lot of progress.
Flight of the dragon
Yesterday I worked on the control scheme for Dragon Attack. In its original version, Glauron, the mechanics are very simple:
- Horizontal speed is constant.
- Vertical speed is affected by gravity as usual.
- When you tap, a fixed amount of speed is added to the vertical speed over the next half second or so.
Porting libGDX games to iOS, for Apple dummies (part 2/2)
Update (14 September 2016): A month after I wrote this, RoboVM announced that they were winding down. I already had a (free) license, which is good until April 2017, but if you need a new one, you’re out of luck.
Porting libGDX games to iOS, for Apple dummies (part 1/2)
Update (14 September 2016): A month after I wrote this, RoboVM announced that they were winding down. I already had a (free) license, which is good until April 2017, but if you need a new one, you’re out of luck.
More farming fun
It’s Fun Time Friday again! And a good thing too, because I’ve been busy with Mystery Game No. 1 all week, which I can’t blog about yet. So apart from the welcome break, the Friday farming prototype also gives me something to write about.
Farming Friday
While Mystery Game No. 1 is making nice progress, in the spirit of “throw stuff at the wall, see what sticks”, I’ve decided to introduce what I call “Fun Time Fridays”. On Friday, assuming the rest of the week has gone according to plan, I get to work on whatever I like, as long as it’s feasible that a game or useful product will come out of it.
Localizing libGDX games via a spreadsheet
LibGDX has decent localization support
via a bundle of .properties files, for example:
== strings.properties ==
app_name=Confirmation App
confirmation=Are you sure?
== strings_en_UK.properties ==
confirmation=I'm terribly sorry to bother you, but would you please be so kind to confirm your certainty on this matter?
== strings_nl.properties ==
confirmation=Weet u het zeker?
Continue reading
Models, views, controllers, presenters, oh my!
Unfortunately, I can’t reveal too much about the game I’m currently working on, but I can say that it’s like a board game. For the sake of this post, let’s assume that the game is chess: there is a game board, there are some players, and each player has a bunch of pieces that either have a position on the game board, or have been captured. In this post, I’ll talk a bit about how to architecture such a game in software.
Things that take time
At the core, Rocket Mail is a very simple game. I made the early prototype (Doomsray) in less than a day. There are no complicated physics, no advanced graphics, and very little in the way of performance requirements. Of course there’s a long way to go from a prototype to a finished game, but even after the game looked, felt and sounded polished, I still found that I needed several weeks to get it ready for beta testing.
Doomsray
I’ve been working on and off on this project for almost two months now, so it’s time I blogged something about it. Here’s the elevator pitch:
Three challenges in game programming
Each field of programming presents its own challenges, and game programming is no exception. In fact, I would say that a game is among the hardest things you can program in general. Why? I can think of three main reasons, which are closely related, as we will see.
Released: Patchy!
Yes indeed, Frozen Fractal’s first officially released game is there! It’s called Patchy, and it’s a retro arcade-style land-grabbing game for Android. This post is about its inception and also describes some bits of the technical implementation.
Game architecture
Although 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. My game is no different, but still contains some interesting aspects that I would like to highlight.
Performance measurements
After 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.
Level editor
Does 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. One of the most important tools to have is a level editor – you really don’t want to put all objects into a level by typing long lists of coordinates. Building the editor has kept me busy for the past few days.
Change of direction
I’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. You’d be a beaver, and you’d have to use twigs and branches, floating in the water, to build a dam.
Pressure, polygons and eddies
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.
First gameplay
I had hoped that the editor would allow me to quickly test gameplay concepts by using “soft rules”: rules that are communicated to the tester verbally by me, instead of being enforced by the program. For example, I could say “Now try moving the orange ball into the blue rectangle, but only moving the green blocks.”
Sandbox editor
To be able to test different configurations, I had a rudimentary text-based file format to describe levels in. It was fairly simple and easy to edit, but still, hand-typing coordinates is not my idea of fun. It was time to build a graphical editor.