Light Cycles 3D- Progress Update 1
Okay, I’ve started work on a first iteration of LC3D; and I’m working on the domain portion now; plotting to do graphics last. My current plan is to implement the game in single player form to get it working, and play arround with some cools things that can be done with the graphics/interface. Specifically, I’d like to try implementing a real time glow effect (http://http.developer.nvidia.com/GPUGems/gpugems_ch21.html for reference); and something slightly more interesting for the folk that die early: maybe a simple fly through the course option, or a circling outside camera; either would work, and a ‘fly through camera’ would allow me to play arround with multiple degrees of freedom movement, something I would need to do for some of my other games.
So, to recap, I’m implementing it in single player form for now so that I can play around with getting bits of it right. When I finally finish that, I’m going to figure out the best structure for sharing state between multiple clients, and eventually fix almost everything. And it will be glorious.
On a related note; I had a thought on networking and death: what to do in the case of a player that dies (or doesn’t die) because of network latency in getting a change direction command across has been a major issue for me. Right now, my line of thinking is this: if a Player sees himself crash into a wall, then the player failed, and his client should send out the ‘I am dead’ signal. If a change direction on the part of the person he crashed into would have saved him; it doesn’t quite matter: he died living a full 20 second life. If a change direction does result in his death when he didn’t see it happen… well, thats unfortunate; but kill him anyway; and have his client report the death. (the ideal would actually be to slightly ignore it, but because of the game state implementation, that would be much more difficult then it sounds). Sadly, this is more vulnerable to cheating (player reports his own death, and only his own death), and may also be more vulnerable to the ‘what did I hit’ question; but I think the case will be rare enough that it won’t be a problem.
Hopefully.
Further completely unrelated sidenote: I now have an avatar… A gnome playing with the GTK symbol, originally put together in 1998 by someone at TAMU (http://www.isc.tamu.edu/~lewing/gallery/gnome/). I have stolen and slightly altered it, though am hopefully attributing it with this post.
Light Cycles 3D- Concept
Until a better non copyright infringing name comes along, we’re going to call this ‘Light Cycles 3D’, or LC3D.
History
As I said in the list of projects post, this has in fact been implemented once before: it was an (unsuccessful) entry into a TAGD one week game competition. Humerous fact: I went through and built it, got it finished, and everything partially working except for the jitter with network game play under C# (.NET 2.0) with Managed DirectX. Go to show it off at the one week get together, to find that the library computers are using .NET 1.1; and probably don’t have the specific Managed DirectX library needed for it. Sadly, didn’t get it converted in time for the presentation, so now one of the goals of the project is to write it using standard C++ and OpenGL.
Concept
The basic concept behind this game is to take the classic Tron/Light Cycle game on a 2D discrete grid surface, and allow movement in a confined 3D discrete grid space. Discrete grid means the space can be broken into individual squares/cubes: it is not a continuous space (as Armaegtron uses). This has a very different game play feel in that it goes from a fast-paced strategic ‘block off the enemy into a tiny box’ game play, to a slower ‘avoid death as long as possible’ style. A slightly less arcade feel, though I prefer the visuals while playing through it: sort of like flying through the Windows Pipes screen saver. Fun and enjoyable? Probably not. But interesting and visually appealing for me.
Game Play
The game takes place in a closed cube, by default a 10×10x10 shell. A player is able to see the cube through the ‘eye’ of his… ship; as opposed to the overhead view used in traditional Tron games. 6 Players start each on one side of the cube, facing the opposite side. Time then begins and each player moves at one square per time increment. The players leave an impenetrible trail behind them, and they are able to either: change direction (up, down, left, right) once per time increment, or simply go forward. If they smack into another players trail, they die, and are out of the game; their trail staying present. Last player alive wins.
An obvious multiplayer element exists: the 5 other players could be network players, AI, or (an odd and humerous side effect from testing), a clone of the single human player. Obstacles or uniquely shaped arena’s (nearly flat rectangle, donut, barbell) could be added to make game play slightly more interesting. It’s also been pointed out that this wouldn’t be too far removed from a ‘worms in 3space’ type game.
Implementation Thoughts
Because implementation is never far from my mind.
The problem with network game play in the first iteration of the game was ‘jitter’: in original game play, the game world had discrete (and visually jarring) steps: you would advance 1 unit of space every quarter or half second; to offset this eye bleeding problem, a smooth transition was added from one discrete step of the universe to the next. Whenever an update was received from the server, this was treated as ‘reseting time’; so, if the update came 100msec later then expected, the transition would move you backwards by 100msec*speed; and similar would happen on the next update (might have been 100msec early this time, etc). It was entertaining to watch, but also quite sad. This could have been fixed by varying the speed of the cycle based on updates (time dilation, woohoo), or a few other odd methods. I suspect fixing this satisfactorly is going to be a bit of a painful process, but we’ll see when we get there.
Changing subjects, one of the first things I did when I decided to do this for a one week game was figure out how facing worked with respect to changing direction of the ship: The ships facing is defined with a forward vector, and up vector, and I went through a very ungreat set of if statements to figure out the changes to these two vectors based on commands made. For example, selecting up means setting the up vector to the negative forward vector, and forward vector to the up vector. Working out the changes for turning left and right wasn’t exactly clean. I’d like to figure out how to translate that into simple matrix math; though until I have the time to work that out, I can probably just copy over the original code for it.
