I am not qualified to talk about this stuff, but I will anyway.

How do you store all the data needed to contain an infinite map? Well that's not too difficult for an experienced programmer - but what if the map changes over time?

I had to solve this challenge as part of my current project, and to do it I sought inspiration from clever science boffins who think the universe looks like a plate of spaghetti.

Even in games whose creators have spent months hankering over fine details of the map much of the final polish is added by fractals. A designer might place hills and roads and walls and obstacles for the player, but they're not going to place each individual blade of grass and small shrub, this stuff is created randomly using rulesets to make things appear intelligently placed. This is known as fractals.

It would be confusing to the player if those shrubs had moved when a player later returned to a scene. We could do it, but 10 million kids with glasses would have aneurisms and die of confusion and/or temper tantrums when their game revealed the sinister truth of teleporting trees being our alien overlords, to solve this programmers don't use truly random numbers - we use a sequence of assorted numbers in a fixed order so that we always create the same sequence of details from the same sequence of numbers. The is called fractal seeding.

In my latest project the map is extremely simple because, to cut a long story short, it's little more than a handful of planets rotating around a sun. Randomly generated 'planets' created according to a fairly rudimentary ruleset, but sufficiently detailed and varied to provide me with all the gameplay elements that I need.

By using the fractal seed method I am able to create an infinite number of solar systems for the players to explore, to create a different system I just change the seed... This is ideal for my purposes.

The important thing is that it meens I don't have to store a single byte of information about the entire galaxy in the game. There is no database or stored information relating to the contents of the map anywhere. This completely negates the massive data storage I would otherwise require for a persistent game with unlimited online players.

I simply use fractals to create each solar system when a player looks at it or I need to calculate the movement of a space ship, and provided I use the same seed each time a given system is entered then i'll get the same planets, in the same orbit, at the right range, the right size, the right type of planet etc etc. In short, i'll have saved the lives of a million short tempered ADHD children and reduced the NHS' treatment costs by reduing the number of paranoid schitzophrenics hiding from teleporting trees.

Perfect, but... I want my planets to orbit their sun, this meens my map is moving over time. It's "dynamic". If I am not storing any data how can I keep track of planetary orbits?

That's the challenge I found myself facing as I set about writing my latest project. The solution lay in the field of n Dimensional Physics, also known as 10th Dimension Theory. Unfortunately this is not a simple theory to explain, but thankfully it's not necessary to it because that's just jumped up science language that intelligent people use to make themselves feel bigger than common muppets like us.

I simply treated time as a point in space. If you cast your mind back to maths class in school when you had that graph paper? I used to use it to design graphics for ZX Spectrum games personally, but i'm mentioning it now because most of us at some point will have had a maths teacher making us draw a grid with x and y plots on it. If you where lucky you had a drop dead gorgeous maths teacher like I did, and if you had "just my luck" you'd no doubt have been promoted to the top set with the minging teacher, like I did too.

Well I simply added another axis to my graph paper: Time, and I can move along it from one end of time to another quicker than any of Doctor Who's assistants are ever going to get their clothes off.

Now the really useful thing about this approach is it has allowed me to apply the same logic to the ships that fly around too. The ships do require some basic data because they are interactive gameplay elements, and I dont store that data indefinately so I can only travel so far back in time without running out of data and I can't move accurately into the future because I don't know what the user will do, but everything between those two points in time can be derived from knowing information about the object at just one point in time - and knowing where on it's timeline it is.

The key thing here is that when I store the data I store it at it's own point in time, specifically the moment when I stored it.

I can then leave that space ship in the database and totally ignore it, because it'll turn up by itself when it's the right time to turn up. Now imagine if the game became very popular (one can hope!) and I have 20,000 players online, if I was processing all the ships owned by 20000 players every second I would need a computer larger than my own already generously endowed ego.

But because elements can exist in the database at their own moment in time I can simply ignore stuff that isn't being looked at for extended periods of time.

The CPU savings go somewhat further too, because the game is a web game and so the server core is written in PHP, meenwhile the end users with their browsers run a client application written in Javascript. The Javascript client handles real time processing to the end user of what they are looking at. Periodically it will get an update from the server just to check that everything is in sync and that it has not calculated anything wrong. Currently I have this set to every 90 seconds.

Compared to most multiplayer games which send packets of data several times a second, and even tick based web strategy games which can have vast amounts of information moving about, some even send the entire page every time you click the mouse and often "in battles" that can be multiple times a second... Well, if the page would load multiple times a second anyway, mostly us end users sit there waiting for the programmer to get a clue whilst we unwittingly blame our ISP.

I'm using ajax to deliver concise updates to each client, and because the client is handling the realtime updates that are presented to the player, the data payload is tiny. In terms of gameplay my "ticks" are at 1 second intervals, in terms of data transmission and server CPU load, my ticks are 90 seconds appart, and they send less data than a game which refreshes the whole page. Come to think of it, there's only 5 lines of HTML in the entire game...

Treating time as a co-ordinate in this way is allowing me to build a realtime game out of the state based technology that is the web, and i'm quite pleased with my progress figuring this all out so far. The only snag I can see on the horizon is how I will solve interactions between multiple entities which are stored at different points in time - that could be a project killer.

So if you ever wondered how the universe was created and how it can be so infinitely big, maybe now you see... It was made by some scatty dyke for a computer game, and she's prone to typos.

Recent Articles

Whatever Happened to Good Old Fashioned Sex on a First Date?
Is Pride a Sin?
Are you a non-wanker?
Why Should I Buy From You?
Its Not About You, Its About YOU!