Jump to content
  • Advertisement
Sign in to follow this  
  • entry
  • comments
  • views

SIMSpace 8.0 dev journal entry #1

Sign in to follow this  
Norman Barrows


SIMSpace 8.0 dev journal entry #1

SIMSpace 8.0 dev journal entry #1

figuring out the basics.

this will be the 8th major version of the game that got me into game
development. In the past the game was a top 10 download on AOL,
with over 10,000 downloads the first week - and this was BEFORE
the internet existed! Its sold as many 250+ units per month, not bad
for an indie title. you also have to remember the market was much
smaller then. its traditionally enjoyed a 2% or better demo to sales
conversion rate, which is considered quite good in most marketing
circles. Its also the first Star Trek starship flight and combat
simlator ever made. When Gene died, paramount's lawyers called me
and asked me to stop making Star Trek games as they now had the
rights to Star Trek and wanted to make them themselves. As a
developer i'm somewhat pleased, and as a Star trek fan and gamer
i'm very disappointed that the few starship flight sims paramount
did do were never quite as good as SIMTrek/SIMSpace. The game also
got some good free press coverage. Electronic gaming magazine named
it one of its six best of shareware for 1990 (or was it 1989?),
alongside five other popular shareware games of the time, including
a game called "castle wolfenstein 3d" by a company called Id software.
thats right - it got side by side reviews in a gaming mag alongside
the original wolf3d as one of the best shareware games of the year.

the last version was released in 1997 or so. I had entered into a
deal with a publisher, but we cancelled the deal by mutual agreement
after a year due to differences of artistic vision. they wanted to
turn a hard core starship flight sim into an arcade game. After
breaking free from the publisher, i cleaned up the code as best i
could and shoved it out the door. in the end it cost me one year
of dev time and about $1000 dollars, and all i had to show for it
was one rendered bridge screen done by an outside artist recommended
by the publisher where the control screens were too small to display
info and use as action areas.

so now its time to do it right.

step one:
how to store large distances.

like the previous versions of the game, i want to have 1000 star
systems in the game world. so i began by determining the approximate
stellar density of the galaxy, to determine how much space on average
would hold 1000 stars. i came up with a world size of a cube 2E17
meters across.

so, how to store such large distances? i considered int64 in
decimeters and int64 in light-years, which is good up to about 2.5
galaxies in size. i experimented with int64 decimeters. but overflow
during AI calculations was a potential concern. also, if i store
x,y,z as floats, it makes conversion to camera relative coordinates
trivial for short ranges. i finally settled on x,y,z in floats from
0 to 1 million meters. a sector is 1 million meters across. a
quadrant is 1 million sectors across. and the game world is 200
quadrants across. so a location is given by a quadrant (qx,qy,qz),
a sector in the quadrant (sx,sy,sz), and a location in the sector
(x,y,z in meters). since i don't use int64's i can use my standard
routines such as get_heading_to_location, get_angle_to_location, etc.

the next step was to setup a player ship and make it move. basic input
was implemented, letting the player set desired heading, angle, and
speed. a show_tgt_info routine was written to display the player's
ship info. a basic update routine was written to turn and move the
ship based on desired heading, angle and speed. this got the guts of
input and update up and running.

the next step was to implement a target list, make the update routine
generic for all targets, and add AI to control a ship. all this has
been done. the AI can fly to a location. in fact, with this the
hardest part of the entire game has been done. turns out the hardest
part of writing a starship flight sim is getting the AI to drop out
of warp and stop on a dime as quickly as possible without
overshooting its target (and without cheating). think of a rail
dragster: it goes REALLY fast, and turns REALLY slow. so unless you
slow WAY down, you can't turn fast enough to make course corrections.
imagine trying to make the turn off of the track at the end of a run
at 300+mph. it just ain't happening!

so the next step is to make it draw targets. i already have all the
"shell" code done. IE the title screen, main menu, basic game loop etc.
but all it does is clear the screen, display target info, and draw a
ship directly ahead at the orientation of the target being flown by
the AI in order to better visualize how the AI is steering the ship.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!