Category: Minigames

It was a bit of a slow week for game development for me with having to get some papers polished up for my physics day job, but this weekend Jeff and I have been working on the space game (now tentatively titled ‘One With Everything’). Mostly the focus has been, how do we do ‘stage transitions’ between scales that are smooth?

The game is supposed to cover about 15 orders of magnitude in scale when all is said and done. Thats enough that floating point problems could raise their ugly head. We could just cut things off every 3-4 orders of magnitude and make a new stage, but that feels artificial and abrupt. So instead the idea is to ‘curate’ position and scale every so often, re-centering the game on the player and rescaling everything to keep it in a numerically stable zone. That should take care of things up until about the planetary scale.

The problem at the planetary scale is, we want to have the player start zoomed in among a debris field and then eventually get big enough that they can start noticing their ‘orbit’. Once the player is big enough, they can either reach escape velocity (in which case the game zooms out, everything vanishes, and then it zooms in placing them in orbit around a different randomly generated object appropriate to their size) or absorb the thing they’re orbitting around, in which case they start to orbit around a new object one ‘tier’ higher (absorb a moon, you’re now orbiting a planet; absorb a planet, you’re now orbiting the sun, etc).

That means spawning an object that might be 100-10000 times bigger than the player in order to have it there (so if you go inwards in the orbit far enough you encounter it and get gobbled up). For example, in the current demo when the player is 10 meters in size, we place a planetoid 3km away that is itself maybe 1km in radius. However there’s a noticeable amount of glitching when you’re close to the planetoid – objects tend to graphically jump around on the sub-meter scale during their orbits, like they’re suffering noticeable round-off errors. The actual velocities involved aren’t that large and the orbits appear stable, so I don’t think its the numerical integrator, and it looks like the objects actually do change position when they ‘jump’, so its not just lag bursts from generating new chunks. At this point I’m not really sure what it is.

The game is playable with it though, so I’m going to give it a rest and move on to another element of the game – the progression system. The way One With Everything is set up is that you have a certain amount of time to absorb things and grow before everything disintegrates around you. This time is going to be fairly easy to maintain at the early levels, but it will get very rough at later levels. However, as you do crazy things like bounce off of objects at half the speed of light, do tight gravity assists around heavy objects, etc, you unlock achievements. These aren’t just for show – they’re the ‘currency’ for the game’s upgrade shop. Every (couple) achievements, you can buy an upgrade to your speed, maneuverability, ability to break objects, etc. You can then choose to leave these upgrades on and get their benefits, or turn them off to get a bonus to your score multiplier.

The idea is that as you play the game, yes you have to repeat the early stages, but at the same time there will still be new things you can earn during those early stages so you aren’t just retreading old ground. Hopefully that will make for a fresh and interesting take on this kind of repeated-play/progression game.

 

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!

cascade_shot4After a sleepness night, Keanen Wendler-Shaw and I have finished our FightMagicRun entry for the brutal ’2-player’ topic. We went right at it and implemented a multiplayer game, server, lobby, the works in a 48 hour competition. I will probably be horrified when I read this post later, since I’m writing it on so little sleep. In fact, looking at the screenshot I think it was creeping into my constant slew of test user names.

Cascade is a simple little strategy board-game. You can place tiles that convert ‘downstream’ tiles to your type. The scoring is done not based on your tiles at the end of the game, but on having as many tiles active at one time as you can. This plays in with the conversion mechanics of the game to make the last move less important than it otherwise would be.

Anyhow, I’m off to bed, but you might give it a try. It does require 2 players however, so bring a friend. Here is the link.

 

I really do hope the server doesn’t crash within the next 8 hours…

Expanded Rebound ReconI posted an update to Rebound Recon (new directory because I had to retain the old version for Ludum Dare judging). Here are the changes:

  • Higher resolution and viewscreen, so you can see more of the level
  • Controls for fine-tuning trajectories
  • Right click to remove nodes
  • 9 new levels

The new first level is an auto-win just to give an idea of the goal and how the game works. I may change that later if people have strong feelings about it.

rebound_shot4Rebound Recon is done and submitted with about an hour left on the clock. It took a bit longer than I’d hoped to make the levels look pretty rather than sparse, and I would have liked to do custom graphics for the three endings, but all in all I’m pretty satisfied with this. The game is playable on the web (no specific plugins needed, and tested in Chrome and Opera so far), and should also run on mobile browsers, though I’d recommend a decent screen size – it will be really awkward on a tiny cellphone.

Now for dinner and to maybe play some games instead of coding them.

Link to the Rebound Recon page on Ludum Dare

Heatsink update

Screenshot of air currents in Heat SinkI’ve updated Heat Sink to fix some bug reports about its performance on Firefox, as well as to implement some suggestions from helpful reviews on Newgrounds.

Changelog:

  • Performance optimizations for Firefox (and possibly IE). Dust and obstacles now use arrays rather than canvas buffers to do pixel-level collision.
  • Airflows are now visualized in the circuit designer
  • Compressed air now has an cursor icon that tells you how large of an area it will clear
  • Temperature graph, dust accumulation, and particles should now be reset when leaving the simulation and returning.
  • Background ‘dusty motherboard’ image now gradually fades in rather than being revealed by dust tracks (I’m sad about this, but it was a huge performance hog)

Future plans include a series of popups/milestones as you pass 50, 100, etc days. Another idea is to record the ‘best times’ on the server and do something like ‘your design is better than X% of all designs’.

I’ve decided to participate in the game contest FightMagicRun this weekend, a weekly 48 hour game development contest whose topic this week is ‘Dirt’. I’m going to be making a quick game called ‘Heat Sink’, where you’re trying to build a heat sink around a CPU that survives dust buildup for as long as possible. Although the game itself is pretty simple in design, there’s going to be a few tricky things inside of it, mostly dealing with the computational limits of browser-based games.

Basically, what we’d ideally want to do is solve the diffusion equation or even Navier-Stokes to figure out the distribution of heat inside the device as the dust builds up. That’d be moderately computationally taxing for a native application, since you’re solving a PDE every second or so. For a browser-based game we’re going to have to do something different.

Instead, I’m going to take a page from importance-sampling based raytracing programs like LuxRender. Every second the game will generate a single ‘heat’ particle, weighted based on the relative temperatures of objects in the game; it will then cast that heat particle in a random direction, compute the interaction of the particle with whatever it first makes contact with, and add that information to the state of the components. The game will remember old trajectories from out-of-date dust distributions, but over time it can build up an accurate heat map without completely re-doing the solution every timestep. We’ll see how it works or if I have to do an even harsher approximation to fit this into the computational budget.