[OT] aspiring game developers

[Geoff Canyon]

On Thursday, October 2, 2003, at 01:24  AM, Scott Rossi wrote:

> Geoff Canyon has also done some phenomenal (and I do mean phenomenal) 
> game
> stuff with vectors.  I'm hoping he'll post his experiments and formulas
> sometime.

With a plug like that, how can I resist? I've posted the stack "Star 
Battle." Type this in the message box and press return to try it out:

go stack url "http://www.inspiredlogic.com/rev/starbattle.rev"

Star Battle is a thought experiment that I might want to do something 
with. As such, feel free to poke around in the script (everything 
useful is in the card script) offer critiques, suggestions, and even 
borrow if you like. Please don't redistribute the stack or claim it as 
your own.

Okay, I've kicked the lawyers out.

I used to be a big Asteroids player back in the early 80's. It was a 
vector video game from Atari.

Revolution graphic objects have a points property that can be set. If 
you leave a blank line in the points, you get a blank line segment in 
the graphic -- it appears as more than one graphic, in essence.

This is the point where I said to myself, "Revolution can't possibly 
set the points of a graphic fast enough to be useful in making a 
game...can it?" 600 lines of code later, it turns out it can. Be sure 
to check out the "Really nice technical details" at the bottom.

WHAT IT IS

Star Battle is a variation on the Asteroids theme. You have a bunch of 
rocks floating across the screen, and a little ship. You can rotate 
left and right, thrust and fire bullets.

There the similarities end.

In Star Battle, the rocks are impervious. Instead there are enemy ships 
that move much like yours, shooting at you just as you shoot at them.

The game keeps score, awards extra ships, has individual rounds, and 
can restart the game. No high score list, though.

TECHNICAL DETAILS

The rocks exert gravitational attraction on all the ships. This is done 
mathematically correctly, I believe (feel free to check and correct me 
if I've taken an inadvertent short cut). I don't do gravity on the 
bullets.

The game performs collision detection on all the bullets, ships, and 
rocks, each time through. It's a simple proximity test, not an actual 
overlap test. In practice it seems to work pretty well.

When placing a new ship, the game checks for other ships and rocks (but 
not bullets).

The game tracks levels and your score.

THE REALLY NICE TECHNICAL DETAILS

Everything drawn on screen except for the score and player's lives is a 
single graphic object. That includes all the rocks, your ship, the 
enemy's ships, and all the bullets. The game calculates and sets the 
points of the graphic repeatedly. The beautiful aspect of this is that 
no screen locking is required. Since the one graphic draws everything, 
and setting the points of the graphic is an atomic operation, there is 
no need.

Levels run a minute in length. A few months back I would have handled 
that by checking periodically whether it was time to update the level. 
Since then, I've learned the wonders of wait...with messages. The game 
logic is in a straight repeat loop. It just cranks and cranks and 
cranks. The loop has a timing governor -- even on the fastest machine 
the game will never go faster than twenty frames per second because it 
checks each time through the loop how long it has spent, and if it's 
running fast, it waits. To do that, I put the ticks() into a variable 
at the start of the loop, and at the end of the loop I do something 
like this:

put tStartTicks + 3 - ticks() into tWaitTicks

At this point, tWaitTicks is how long I need to wait to delay the game 
appropriately. On a really fast machine it might be as much as 3 ticks. 
On a slower machine it will be 0 ticks, or even negative.

To enforce the wait period, I use this:

wait tWaitTicks ticks with messages

It doesn't matter if tWaitTicks goes negative, the command above works.

Now the "with messages" part deserves special mention. Because of that, 
changing levels is easy (remember, this start out about how to update 
the level each minute).

To update the level, I use:

send "updateLevel" to me in 60 seconds

Because of the "with messages" part of the command above, the 
"updateLevel" message gets delivered just fine, and without an apparent 
hitch in the game. I don't have to keep track of time, I let Rev do it 
for me.

Anyway, it's late. Let me know what you think.

regards,

Geoff Canyon
gcanyon at inspiredlogic.com