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 [EMAIL PROTECTED]
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
