Realistic Space Game

From Wikiid
Revision as of 13:11, 23 March 2010 by SteveBaker (Talk | contribs) (Building a Fluid Asteroid Belt)

Jump to: navigation, search

This is the portal for a newly conceived "realistic" space game.

Networked Gameplay

The most important first step in development.

Procedural Environment

Relatively Small Environment

The game initially starts off in an asteroid belt, as it's the realistic equivalent to having many teeny planets like in Freelancer type games.

If ever more systems are added, then instead of faster than light (FTL) capability, a deep sleep should take it's place.

Filling the Sector with Stuff

Each sector of space is given a number, and everything within is seeded by that unique number, creating a random universe that remains the same between all copies of the game.

Building a Fluid Asteroid Belt

Procedural generation of 'stuff' works best if you have the random number generator 'seeded' with some number that relates to one's location in the universe. However, we want the asteroid belt to be more dynamic - with things moving around within it. The idea is to have fairly large 'blobs' of asteroids that move as a group. Let's suppose each blob is a roughly spherical group of maybe 100 rocks - and maybe it's 1,000km across. We're going to have the entire blob orbit at some speed and distance from the star that's a little bit different from the other blobs...maybe it's slowly spinning too. Suppose the entire asteroid belt is made of a million blobs.

Each blob would be numbered uniquely from 1 to 1,000,000. It wouldn't take more than a few seconds to loop through all million blobs - and to generate a set of orbital parameters for each one using a random number generator 'seeded' from the blob's number. At the start of the game, each player's computer would take a few seconds to check all of those million sets of orbital parameters to decide which (say) thousand blobs are close enough to the player to be worth worrying about during (say) the next 20 minutes of top-speed travel through the game. We remember their numbers and forget the other 999,000 of them - so 1,000 blobs of 100 asteroids is 100,000 asteroids - which ought to be enough for 20 minutes of interesting game-play. But all we're storing at this point is a list of 1,000 blob numbers plus their orbital parameters.

Now, we look through those 1,000 blobs to find out which ones we can actually see (either on-screen or with radar or something). Maybe there are a few dozen blobs like that. Once we know where they are (and when they are - because they are moving), we can continually test just a few of the list of the million blobs each frame of the game to see if they are starting to get close enough to be worth paying attention to - and we can also continually monitor the few dozen "close enough" blobs to see if they are no longer close enough to be worth bothering with - and then we can delete all of their data except for the blob number and stop drawing them.

As we find blobs that enter our area of interest, we use the random seed approach again to generate how many asteroids there are, what their coordinates are relative to the center of the blob - then the shape, color, texture, etc of each asteroid - and the data for anything else within that blob that matters (wrecked warships full of useful supplies, alien artifacts with weird properties, rare metal deposits, etc).

This gives us a VAST space to explore. 100,000,000 asteroids is more than anyone could explore in a literal lifetime. It's "enough" - by any useful measure!

There are two tricky parts to this. One is that we can modify the world within the game. If there is a valuable alien artifact that happens to appear (at random) in blob #12,345 and we grab it and take it away...what's to stop it being generated again the next time? The trick here is to realize that over the (possibly) millions of random numbers that we generated to build our blob, very few of them are changed by doing this. Moreover, over a million blobs - the percentage that are modified is very tiny. We could have the server create a file on disk for every blob that's been modified.

Now, our client computers generate the list of blob numbers that it cares about - and sends that list to the server - which replies with a much smaller list of modified blobs...and when those blobs come close enough to the player to matter, the client can ask the server for a list of modified, missing and extra "objects" that relate to that blob. So the client computer generates the blob's contents normally at long range asks the server for the "mod-list" for that blob - and when the mod-list arrives, we modify the contents of the blob accordingly. Hopefully, the server responds fast enough that we get the modifications done before the player notices!

As events of the game unfold, the server needs to be told to create these mod-lists for modified blobs - and to periodically save them to disk in case the server crashes or something.

Obviously, in a "persistant world", the number and size of these mod-lists grows - which slowly eats up disk space on the server - but that's the only bad effect - for the players, the number of mod-lists that they care about is limited to the distance they can see in the game. Admittedly, when a heavy amount of game activity has gone on - the local neighbourhood may be seriously trashed with dozens, perhaps hundreds of mod-lists being created there. But because the blobs are orbitting at different speeds - those mod-lists will gradually spread out and distribute themselves throughout the asteroid belt such that they don't stay bunched up for more than (let's say) a day or two.

If the server starts to run short of disk space - we can simply delete the oldest mod-lists using their time-stamps and quite automatically, those least-recently-modified blobs will magically 'repair' themselves. We may want to be a little more subtle about that though to prevent players from gaming the system. If a blob has a rare artifact in it - we don't want the player to realize that he can come back to that location a year from now and grab the exact same artifact again. So we might label blobs that were once found to have something super-significant in them so that we NEVER delete them...or perhaps, in general, simply apply an "importance" factor to each modification to a blob so that unimportant changes get erased very quickly and game-changing mods are never forgotten.

The second big problem with this scheme is that the blobs don't know about each other - so they will often move through each other (that's actually a desirable feature here because it makes for a more dynamic and interesting environment). So we'd need to do collision detection between the asteroids and figure out what happens between them. If the consequences are just modifications to the blobs containing those asteroids - then a mod-file change will do the job - but what we can't to is to make them spin off at different speeds and such because that would soon push them far out of the blob's radius. So probably:

  • When two colliding asteroids are very different in size, we should destroy the smaller of the two (updating the mod file) - fire off some inconsequential debris (which would simply cease to exist once it's outside of the current play area) and maybe start the larger one spinning or something (which could be handled in the mod-file).
  • With two small asteroids, we can just smash them both into debris and delete both of them.
  • But for two large asteroids, I think we have a problem. One possible solution for that is to calculate when they are going to collide when a new blob is added into the scene (we know their orbital parameters - so it's a foregone conclusion) - and subtly nudge their coordinates such that they just miss each other - or perhaps just clip each other, if they just clip then you can set them spinning, smash up their surfaces and throw off inconsequential debris. Of course doing this means that when you come back to that blob sometime later, the position of the asteroid is back where it would have been if it had never been collided with - but the error will be at most the radius of the asteroid. This situation will of course be rare.

One horrible error with this (and one we certainly can't address) is that when nobody is near a colliding blobfull of asteroids, they'll pass harmlessly through each other - because until someone flies close enough for a computer to generate the contents, nobody can possibly know that a collision occurred. Kinda like "If a tree falls in a forest and nobody is there to hear it - does it make a sound?"...in this case "No!".

Scripting Engine

Ship Design

Players have a "Ship Creator" tool to customize the look and functionality of their ships.

Modular Design

Modules makes the ship creator tool much simpler to use, and gives the game a need for some kind of currency.

Salvageable modules and parts mean that provoking engagements and pirating become an aspect of gameplay.

Weapons

Not necessarily a separate module, but the locations of hard points of the guns should be variable.

Mining lasers are the primary tool of the space pilot, for use as weapons, for mining, and scavenging. Lasers are not slow, like Star Wars "laser bolts" but more instantaneous.

Other weapons like rockets, mines, and EMP's can be bought and scavenged for use.

Required Modules

Engine and Cockpit modules are required for the smallest ship, and as the ships grow, the need for crew quarters and storage holds becomes necessary.

Perhaps a bonus for having spinning sections that give centrifugal artificial gravity.

Ship Control

Both "manual" and "scripted" options allow for a full variety of gameplay, with manual flight mode used for battles and for players that prefer a more hands-on approach.

Manual Flight Mode

Controls allow for full heading, pitch, roll?, and lift/strafe control.

Scripted Flight Mode

For scripting details, see the Scripting section.

For people in the 24th century, computers are the easiest way to go about precise piloting. Sample programs like "Geo-synchronis orbit", "Plot a course", and a mining program to give sample code for combat scripting.

For players with multiple ships, scripts for wingmen, search parties, or escorts could be made.

Flight Physics

Basic Newtonian laws, of course without too much friction.

Perhaps in proximity with a very large asteroid, moon, or planet, gravity should effect the trajectory in manual mode.