Things To Model
SDxWiki

What kind of things would you model in a persistent space simulation? (Assuming that's what we want to build...)

Istvan (5/20/02) Trying to pull comments by me and others that properly discuss specific features out of this list page and into categorized Game Feature Ideas pages.

Things what fly

First of all we have to decide on a Flight Model (Assuming it's some sort of space game) There are at least three distinct Flight models...

*Pure Newtonian *Newtonian with drag (ala JumpGate) *Forget Newton. I just want to make it easy.

Dan Muller:

<soapbox> full Newtonian model != difficult to fly </soapbox>

Since I really like the flight model in Independence War, I've created a separate page where I can blather about it, so you can more easily ignore me should you so choose. :)

A full Newtonian model might be hard to work with in an on-line game because of the large relative velocities that can occur. But I think that distributed modelling and dead reckoning techniques might be able to cope, since the player's computer will actually be able to simulate the complete, assumed path for any object of interest.

Istvan: Full Newtonian could be most easily used if other design aspects (read: "main travel mechanics") limit the encounter velocities. Alternatively, If combat does not rely on human reaction speed (as it does in JumpGate) the computer can handle high velocity encounters. A push-button or script-driven combat system might be created as a cross between strategic and tactical decisions - more like fencing with only one opportunity to interact than the back-and-forth bludgeoning type of combat we see in most space sims and other games.

Further thought on Newtonian flight - what if the relative velocity is such that the detection radius is compromised? Say Ship A accelerates in a straight line to 100,000 km/s (about .3 c - entirely possible if the fuel tank allows), while the arbitrary detection radius for Ship B is 100,000 km? If the processing of detects is fast enough, the player in ship B would perhaps get a "phantom" contact as ship A whizzes by. Short answer: don't allow the players sufficient fuel to attain velocities that high. Ion, NERVA, or fictional reaction-drive models are thus predicated - and fuels provide a recurring maintenance expense.

Istvan (5/20/02) I'd like to advocate a fully Newtonian flight model as our starting condition, and to plan to use both fuel and acceleration limits to curb problems with relative velocities. Other travel modes (gates, skipping) will allow us to resolve travel time problems. The flight interface will have to aid the player in performing basic functions like executing "turnaround" for deceleration, and for matching orbits, at the very least giving warnings, countdowns, and ETA information if the player chooses a manual flight mode. (5/22/02) Additionally, one of the most significant obstacles to use of a Newtonian flight model for players is choice of interface. Pointing out stuff Dan hinted at in his essay on the Independence War flight model, if you simply give a player a thrust control and expect him to manually control his speed and match courses with things, he's going to consider the flight model practially impossible to work with. Give him a velocity control instead, along with computer-assisted functions to "match courses" or "approach to docking range", and though the flight model remains Newtonian, the tools the player has to work with are much simpler to use. I very much like Dan's description of the combo interface in IWar: throttle is used for velocity settings under "computer-control", but is a true throttle with acceleration control on "manual". With Newtonian flight characteristics, doing anything complicated without computer support will generally result in loss of control of the vehicle. So we provide lots of computer support, along with ability to climb outside the box for the adventurous, the stupid, or the amazingly competent.

Things what orbit

Systems, Literal and Abstract