Category: Design Ramblings

Arctangent noiseIf you recall that fluid dynamics shader I posted last week, I’ve written an article about how to write one. Check it out!

Currently I’m working on an article about using fractal noise to pick things like terrain types for procedural world generation. It turns out that getting uniformly-distributed fractal noise is a bit tricky. Usually when you add multiple independent noise sources together as you do in fractal noise synthesis, you get values that are Gaussian-distributed (in fractal noise you can get other things because of the fractal nature). If you’re using those noise values to pick from a weighted list, the weights will get all messed up because of the shape of the noise distribution. The trick is to use a continuous function to map the Gaussian-distributed noise to a uniformly-distributed range.

In practice this is tricky to do without creating undesirable shapes in the noise – for example, if you use modulo to wrap the noise to the [0,1] interval you get high-frequency bands. The solution I’ve found so far is to use two noise samples and use the arctangent to generate an angle using those samples. This will still have certain unpleasant features – ‘vortices’ where both noise functions approach zero – but they are greatly reduced compared to the modulo approach (see the picture on this post).

shaderpicI was messing around with shaders for the ‘space game’, trying to figure out how to do a nice background shader for nebulae and the like. My attempts at a hydrodynamics shader weren’t working, so I just started messing around. The result is this (uses WebGL).

Each pixel of the shader simulates the equations of motion of a tumbling object. When you have an object whose moments of inertia along its three principle axes aren’t balanced, then it does all sorts of crazy spinning and tumbling. This is something you’ve seen if you’ve played realistic flight simulators or Kerbal Space Program – if you’ve got something and it starts to spin, it doesn’t just spin around one axis, it wanders all over the place (or think of how a frisbee wobbles in flight). I then put a blur on top of the whole thing and used the results to make a bump map.

I don’t think this will end up in game, its too dizzying and doesn’t look ‘like anything’, but its neat how you can get spiral waves, ‘up’ and ‘down’ regions (the green/yellow ones are spinning around one pole of the object and the red/blue ones are just the flipped version of that), etc, all from the tumbling of an irregular object.

Since I had a bit of a hard time figuring out how to do all this, I’ve decided to make a short tutorial about it.

(more…)

almost_everything

An abridged map of scales. My hand got tired so I skipped all that squishy stuff in the middle called ‘life’.

I’ve been fascinated with the idea of ‘scale games’ of late. I blame ‘Cookie Clicker’, which I will not link to here in order to save you from its addictive properties. The basic idea is, its cool to compress lots of orders of magnitude of something into a single game, be it going from one cookie per click to time portals churning out millions per second, building a space-ship in Kerbal Space Program that finds the first 50km as hard as the next 50 million, or starting by rolling up paperclips in Katamari Damacy and finally rolling up continents and planets.

There’s kind of a magic to taking something huge – so huge that we don’t think of its size in terms of one number, but in terms of all of the smaller worlds it contains –  and fitting it into an experience that we can understand in a single sitting.

Anyhow, this is all going somewhere, and that is that this weekend I’ll be working on something we’ve been calling ‘the space game’ with Jeff Berry. Despite its rather nondescript codename, it’s all about the scales of the universe. This will be my first experience working with a professional artist (as well as my first foray into WebGL) so I look forward to seeing what we can create.

Incidentally, I’m pleased to announce that Cascade was picked as the winner of last week’s Fight Magic Run!

SpeedlinesI got a lot of helpful reviews over the last week, and this has helped me focus on a few elements of polish that are pretty lacking. The big comment I’ve been trying to address tonight has been about the sameness of battle actions – they’re mechanically different, but they aren’t visually different.

So I’ve been playing around with battle effects. Of course I can make lots of little ‘slash’ animations from different angles, but these aren’t necessarily distinctive on their own. To help with that I’ve been messing around with full screen battle effects, and I realized that some of these things could be useful tricks for other Javascript/Canvas developers. Its kind of long, so I made a separate page for it: Speed lines tutorial.

 

When working on Travelogue, at some point I crossed a threshold where it became hard to come up with new ways to reward the player. The more items I created, the less space there was for interesting, distinctive item properties and effects. This all boils down to an idea I call ‘mechanical hooks’.

A game will end up having some basic set of mechanics – you can move your character, perform an attack, deal damage, get hit, take damage, etc. Each of these basic mechanics gives you a hook that you can use to modify the gameplay later on with items, experience levels, special abilities, and so on. The number of distinctive ways you can hook into these basic mechanics determines the maximum amount of variation you can have in your gameplay – variation you can use to distinguish character classes, reward the player, allow for growth and customization, etc.

In the above example, you could have effects that change movement. If you have an overhead game like Legend of Zelda, then the character’s movement speed is probably the only real hook you have so far. But if you introduce terrain that blocks your movement, each such terrain gives you a new mechanical hook to create an ability to bypass that limit. If you have a side-scroller with jumping, now you can independently modify movement speed, jump height, and even hover time (e.g. the differences between Mario, Luigi, and Princess Peach in Mario 2). If there are other consequences of movement, such as D&D’s threatened squares and Attacks of Opportunity, then these provide another hook.

With ‘perform an attack’, if you just queue up a strike and the game computes the result, you pretty much just have ‘does it hit or not?’ as your hook. If enemies can defend, then you can now have hooks that tie into disabling enemy defenses. And so on.

Its not necessarily the case you want to maximize the number of such hooks you have – you could easily get to a situation where the game becomes too complex for the player to follow if you just indiscriminately create subsystems in order to be able to modify those subsystems later. But I think it is useful when designing the base underlying mechanics of the game to ask ‘what are the hooks that I can modify later, and do I need something richer to support a game of the length and complexity that I’m trying to create?’

I’ve been thinking about the pacing of games, particularly simulation games. These games have a tendency to have a ‘desperately trying to survive’ phase and a phase in which you’ve basically caught your breath and are on top of things. I’m going to call these ‘non-equilibrium’ and ‘equilibrium’ respectively.

The equilibrium part is the easiest to understand – this is when whatever you’ve got built up is enough to keep you going. This is when you can go and build crazy stuff, because you aren’t restricted to do what you need to do to survive the game and keep playing. Its equilibrium in the sense that you could in principle set up some kind of routine and just iterate that routine forever, and nothing would change about the situation in the game. In SimCity this would be some point where growth is zero but you’re making a profit on taxes – if you walked away and let the game run overnight, the only thing that would change would be your bank balance.

The non-equilibrium parts are the ones where, if you did nothing special, you’d lose – your dwarves would starve, your ship wouldn’t make orbit, your city’s coffers would drain out. Usually the model for this is that you start with some initial boost above and beyond what you can yourself generate, and you’re trying to reach break-even before that boost runs out. These are the moments of the game that have you on the edge of your seat, wondering if you’re going to make it (well the first few times you do it, anyhow). Its not just tension though – when you’re in the non-equilibrium parts of the game, there’s a pressure to keep playing because you feel like there are things left to do to get into equilibrium. Its that feeling that you can eventually reach equilibrium if you just do this one more thing that keeps you hooked.

For something like Minecraft or Dwarf Fortress, actually reaching equilibrium is important, since the ability to build crazy stuff is kind of central to the experience. But for something like SimCity, especially in the older ones, equilibrium means that the game is basically over at that point. You can sit there and grow whatever resources are good to have for an arbitrary length of time before embarking on any risky endeavor. Once you hit equilibrium, the only limit to your resources is your patience.

Now, the ‘initial boost, try to break even’ model does leave you with the feeling of having to do things to reach equilibrium, but it only lasts as long as that initial boost lasts, which can be quite short. In Dwarf Fortress this is the first year basically – if you don’t have food production by then, you’re going to start to lose people to starvation. After that, you can basically wall yourself off and survive indefinitely if you want. Random disasters that require specific reactions is another model, but usually there’s very little you can do about it, so it doesn’t really hit that ‘feeling of more work to be done’, its more like ‘oh crap I have to react!’.

One model that I think works is finite resource depletion, where there’s only so much stuff in your immediate environment and you have to expand to survive (and at the same time increase your needs). By controlling the amounts of resources available in each area of the game, you can control the time the player has to complete that segment, and you can hold out the carrot of things that resolve the player’s dependency on resources or provide ways for the player to renew them in order to have something to work towards. There are surely other models that would work for this kind of extended play as well.

So for simulation-ey games, its important to keep this in mind and try to extend the non-equilibrium phase as much as possible while holding that carrot of eventual stability out in front of the player. Keeping the player out of equilibrium is really critical for giving them the feeling that there’s more stuff to do and more game ahead of them.