Aerobatic Judging Game Implementation
by Timothy May · in General Discussion · 01/06/2005 (1:53 pm) · 12 replies
I am seeking advice on the best implementation approach for a "game" that I am building using my copy of the Torque engine. After extensive review of the engine and working through the 3D Game Programming All in One book I finally feel like I can ask a few intellegent questions. It turns out that my game requirements are strange enough to not be addressed directly by anything discussed in these forums or any Torque related book I have been able to find. Let me briefly describe the game and then the specific implementation questions I have.
Aerobatic competition is a healthy sport around the world for both full size aircraft and the Radio Control community. In both cases, judges sit and watch an aircraft fly a "sequence" of 10 to 13 complex manuevers. Each manuever is given a score from 0 to 10. Each manuever has a "K" (dificulty) factor that. The flights score is simply the sum of the K factor * score for each manuever.
Judging aerobatics is a complex job as it is fairly technical. As each manuever is flown, half points are deducted for little mistakes made by the pilot - it is easy to miss the little mistakes and end up doing "subjective" judging instead of the quantitative judging actually required. Compounding the problem is the fact that judges don't get a whole lot of practice between competitions. The point of the game, working name "AeroJudge", is to provide "practice" for judges and allow them to improve their skill level.
The game has the following, somewhat simple by other game standards, layout:
1. A single simple terrain and skybox.
2. A model of an aerobatic aircraft that can be programatically "flown" through the sequence.
3. A single camera, at a fixed location, that tracks the aircraft through it's flight.
4. A simple GUI for selecting the "sequence" to be flown from a database I supply.
5. A simple set of keyboard handlers to "register" the score of each manuever as the flight is presented.
Game play: Game play is very simple. The player will select the sequences that the plane is to fly. The sequence will be flown and the judge will enter a score using the tilde through 0 keys for each manuever in the sequence. The sequence will then be flown a second time wth the game showing the correct score for each manuever, the judge's score and a description of what actual "downgrades" should have been applied.
So far, I have built the terrain and skybox. I have built the aerobatic aircraft, using Truespace 6.6, and have a working .dts file for it. I have a database of the sequences that may flown and a language for interpeting these sequences as movements of the aircraft in roll, pitch, yaw and path.
I have reviewed the AIPlayer examples in the FPS and the simpler ones in the forums. I have also read the little bit of information available on the RTS pack recently released by GG.
BTW:
1. THIS IS NOT A FLIGHT SIM AND IT IS NOT NECESSARY TO DELVE INTO FLIGHT PHYSICS.
2. The aircrafts movements will be completely specified, including mistakes ;)..., by the sequence language I have developed. For instance, the language specfies the path in terms of lines and curves and optional rolls, pitch and yaw along those paths.
If you are still with me, after that fairly long winded intro, my implementation questions are:
1. Is there available a pack or partial game example that would illustrate the C++ and Script coding necessary to implement a fixed location camera that would follow the aircraft as it is flown through the sequence?
2. Is there available a pack or partial game example that would illustrate automation of the "flight" of a shape. This of course without regard to physics? I assume that this would be similar to the paths followed by AIPlayers?
Clearly, the engine can be hammered into shape to accomplish these tasks. I am looking for the shortest path to a working game.
Any ideas are appreciated and I appoligize in advance if I have missed some obvious resource in the fourms that would have addressed my questions.
Thanks,
Tim
Aerobatic competition is a healthy sport around the world for both full size aircraft and the Radio Control community. In both cases, judges sit and watch an aircraft fly a "sequence" of 10 to 13 complex manuevers. Each manuever is given a score from 0 to 10. Each manuever has a "K" (dificulty) factor that. The flights score is simply the sum of the K factor * score for each manuever.
Judging aerobatics is a complex job as it is fairly technical. As each manuever is flown, half points are deducted for little mistakes made by the pilot - it is easy to miss the little mistakes and end up doing "subjective" judging instead of the quantitative judging actually required. Compounding the problem is the fact that judges don't get a whole lot of practice between competitions. The point of the game, working name "AeroJudge", is to provide "practice" for judges and allow them to improve their skill level.
The game has the following, somewhat simple by other game standards, layout:
1. A single simple terrain and skybox.
2. A model of an aerobatic aircraft that can be programatically "flown" through the sequence.
3. A single camera, at a fixed location, that tracks the aircraft through it's flight.
4. A simple GUI for selecting the "sequence" to be flown from a database I supply.
5. A simple set of keyboard handlers to "register" the score of each manuever as the flight is presented.
Game play: Game play is very simple. The player will select the sequences that the plane is to fly. The sequence will be flown and the judge will enter a score using the tilde through 0 keys for each manuever in the sequence. The sequence will then be flown a second time wth the game showing the correct score for each manuever, the judge's score and a description of what actual "downgrades" should have been applied.
So far, I have built the terrain and skybox. I have built the aerobatic aircraft, using Truespace 6.6, and have a working .dts file for it. I have a database of the sequences that may flown and a language for interpeting these sequences as movements of the aircraft in roll, pitch, yaw and path.
I have reviewed the AIPlayer examples in the FPS and the simpler ones in the forums. I have also read the little bit of information available on the RTS pack recently released by GG.
BTW:
1. THIS IS NOT A FLIGHT SIM AND IT IS NOT NECESSARY TO DELVE INTO FLIGHT PHYSICS.
2. The aircrafts movements will be completely specified, including mistakes ;)..., by the sequence language I have developed. For instance, the language specfies the path in terms of lines and curves and optional rolls, pitch and yaw along those paths.
If you are still with me, after that fairly long winded intro, my implementation questions are:
1. Is there available a pack or partial game example that would illustrate the C++ and Script coding necessary to implement a fixed location camera that would follow the aircraft as it is flown through the sequence?
2. Is there available a pack or partial game example that would illustrate automation of the "flight" of a shape. This of course without regard to physics? I assume that this would be similar to the paths followed by AIPlayers?
Clearly, the engine can be hammered into shape to accomplish these tasks. I am looking for the shortest path to a working game.
Any ideas are appreciated and I appoligize in advance if I have missed some obvious resource in the fourms that would have addressed my questions.
Thanks,
Tim
About the author
#2
For your specific requirements, I think that your best option is going to simply be some massive scripting of each and every 'tick' (and I don't mean that in the "normal" TGE way) of the aircraft's flight path. Since you are intentionally avoiding flight physics simulation (probably a good call for this scope of project), you are tying yourself directly to fully scripted positional and rotational changes of your planes.
Simple aerobatic example: An Immleman:
1) Manuever entry is straight and level flight, at a certain speed (specific to the aircraft obviously). This would be scripted by a for loop that increments (make it easy) one axis of movement, and calls a setTransform for every iteration of the loop.
(psuedo code here, it won't work drop in and run)
--you would have to really lay this out well, since you are modelling 3-d positional changes based on airspeed, as well as rotational changes in one axis, not to mention any 'pilot' errors you may want to introduce here, like wing dips or minor banks
---while you want to not actually code in physics (per your requirements), you still need to -model- the physics yourself as you define the new transform values, both positional and rotational. This is going to be a hell of a lot of work.
3) 180 degree pull up performance.
--you'll need to step through each and every positional change of your aircraft, again keeping track of how far the model should move in each axis, as well as rotational modifications.
4) turnover.
--same here, but mostly rotational at this phase in the manuever, since the airspeed is so low--the plane won't be moving positionally near as much as it will be rotating.
5) level flight establishment
--again, lots of 'ticks' here, mostly to show the plane establishing flight straight and level (at reduced airspeed).
NOTE: I'm an aero qualfilied pilot myself, and as I typed this writeup I started thinking about more complex manuevers, and the amount of brute force work that will be required to model the flight paths manually without physics. As much as you aren't going to like this, it is most likely in the long run going to require less work to research and implement a true flight physics model of some (limited is fine) form than it will be to script each and every one of these manuevers in the manner I described.
I wouldn't even want to think about how tedious it would be to script out positional/rotational flight paths for a cuban 8 or a bowtie loop, each of which would involve literally thousands of script lines. And those are the basic acro manuevers--for the market you are looking at, there are some amazingly complex aero manuevers to model.
01/08/2005 (12:22 pm)
I was about to mention the advanced Camera resource, but it looks like you've found it!For your specific requirements, I think that your best option is going to simply be some massive scripting of each and every 'tick' (and I don't mean that in the "normal" TGE way) of the aircraft's flight path. Since you are intentionally avoiding flight physics simulation (probably a good call for this scope of project), you are tying yourself directly to fully scripted positional and rotational changes of your planes.
Simple aerobatic example: An Immleman:
1) Manuever entry is straight and level flight, at a certain speed (specific to the aircraft obviously). This would be scripted by a for loop that increments (make it easy) one axis of movement, and calls a setTransform for every iteration of the loop.
(psuedo code here, it won't work drop in and run)
for (%xAxisPosition = %start_position; %xAxisPosition <= %manueverStep2XAxisPosition; %xAxisPosition += <value for how far plane moves in one 'tick'> )
{
%plane.setTransform (%xAxisPosition, 0,0,0,0);
}2) Initial pull-up.--you would have to really lay this out well, since you are modelling 3-d positional changes based on airspeed, as well as rotational changes in one axis, not to mention any 'pilot' errors you may want to introduce here, like wing dips or minor banks
---while you want to not actually code in physics (per your requirements), you still need to -model- the physics yourself as you define the new transform values, both positional and rotational. This is going to be a hell of a lot of work.
3) 180 degree pull up performance.
--you'll need to step through each and every positional change of your aircraft, again keeping track of how far the model should move in each axis, as well as rotational modifications.
4) turnover.
--same here, but mostly rotational at this phase in the manuever, since the airspeed is so low--the plane won't be moving positionally near as much as it will be rotating.
5) level flight establishment
--again, lots of 'ticks' here, mostly to show the plane establishing flight straight and level (at reduced airspeed).
NOTE: I'm an aero qualfilied pilot myself, and as I typed this writeup I started thinking about more complex manuevers, and the amount of brute force work that will be required to model the flight paths manually without physics. As much as you aren't going to like this, it is most likely in the long run going to require less work to research and implement a true flight physics model of some (limited is fine) form than it will be to script each and every one of these manuevers in the manner I described.
I wouldn't even want to think about how tedious it would be to script out positional/rotational flight paths for a cuban 8 or a bowtie loop, each of which would involve literally thousands of script lines. And those are the basic acro manuevers--for the market you are looking at, there are some amazingly complex aero manuevers to model.
#3
Are you familiar with the Aresti catalog that IAC uses to define legal maneuvers in aerobatic competition? I have coded this catalog into a database in a little declarative language that I can translate into a set of function calls that perform the various components of a sequence. Basically, I read in a sequence as a series of specified catalog entries and then that translates into a series of functions calls. There is more to it than that of course, but the basic idea is pretty simple and not too difficult to implement.
I tried a scripting approach using schedule but that was way to slow. Looking at your code I see my mistake I'll try this approach out and let you know how it goes.
01/08/2005 (1:55 pm)
Stephen,Are you familiar with the Aresti catalog that IAC uses to define legal maneuvers in aerobatic competition? I have coded this catalog into a database in a little declarative language that I can translate into a set of function calls that perform the various components of a sequence. Basically, I read in a sequence as a series of specified catalog entries and then that translates into a series of functions calls. There is more to it than that of course, but the basic idea is pretty simple and not too difficult to implement.
I tried a scripting approach using schedule but that was way to slow. Looking at your code I see my mistake I'll try this approach out and let you know how it goes.
#4
Are you familiar with the Aresti catalog that IAC uses to define legal maneuvers in aerobatic competition? I have coded this catalog into a database in a little declarative language that I can translate into a set of function calls that perform the various components of a sequence. Basically, I read in a sequence as a series of specified catalog entries and then that translates into a series of functions calls. There is more to it than that of course, but the basic idea is pretty simple and not too difficult to implement.
I tried a scripting approach using schedule but that was way to slow. Looking at your code I see my mistake I'll try this approach out and let you know how it goes.
01/08/2005 (1:59 pm)
Stephen,Are you familiar with the Aresti catalog that IAC uses to define legal maneuvers in aerobatic competition? I have coded this catalog into a database in a little declarative language that I can translate into a set of function calls that perform the various components of a sequence. Basically, I read in a sequence as a series of specified catalog entries and then that translates into a series of functions calls. There is more to it than that of course, but the basic idea is pretty simple and not too difficult to implement.
I tried a scripting approach using schedule but that was way to slow. Looking at your code I see my mistake I'll try this approach out and let you know how it goes.
#5
What might make sense is to figure out a decent algorithm for having movement "primitives" of some sort, which is sounds like you are close to doing. In that way, you could implement these movement primitives once, and then string them together into sequences that complete a full manuever.
Again, while you don't want to implement accurate physics, you'll still need to have some basic "physics" variables such as x-axis move rate, y-axis move rate, x-axis rotation rate (most likely roll), z-axis rotation rate (yaw), etc. If you can find a good mix of scripting requirements and performance/implementation difficulty, the rest should be a matter of tying the primitives together.
P.S: Keep in mind that code is not in any way accurate--it was meant to point at a techinque, not an implementation. For example, I don't even have enough paramaters there to the setTransform function!
01/08/2005 (2:19 pm)
Not specifically, no (I was a military instructor pilot, so we had very basic aero manuevers we taught to students), but if you've been able to encapsulate specific set of calls then you may be well on your way to lowering the amount of scripting I was envisioning.What might make sense is to figure out a decent algorithm for having movement "primitives" of some sort, which is sounds like you are close to doing. In that way, you could implement these movement primitives once, and then string them together into sequences that complete a full manuever.
Again, while you don't want to implement accurate physics, you'll still need to have some basic "physics" variables such as x-axis move rate, y-axis move rate, x-axis rotation rate (most likely roll), z-axis rotation rate (yaw), etc. If you can find a good mix of scripting requirements and performance/implementation difficulty, the rest should be a matter of tying the primitives together.
P.S: Keep in mind that code is not in any way accurate--it was meant to point at a techinque, not an implementation. For example, I don't even have enough paramaters there to the setTransform function!
#6
01/08/2005 (3:44 pm)
I can't add anything here to help with your technical questions, but I wanted to just say that this sounds like an AWESOME idea for a game. Aircraft seem like a good subject for a judging game. I think a basketball referee game would be fun too, but at this point even the best basketball games don't have detailed enough animations (or too specific) where you could make good calls. But it seems like following the path of an aircraft would lend itself well to judging. Best of luck with this!
#7
It would be tricky getting them lined up so the transitions are smooth, but I think it would be much easier than hand scripting each and every frame of animation.
01/08/2005 (5:48 pm)
Just my 2c, I dont know anything about aerobatics, but I was thinking if one maneuver is a string of smaller components then couldnt you animate the model doing each of the components in your modelling package, then just call the different animations from script (after a suitable wait with schedule based on the length of the animation)?It would be tricky getting them lined up so the transitions are smooth, but I think it would be much easier than hand scripting each and every frame of animation.
#8
- Go into the TGE FPS Demo and press F11 (Editor mode).
- Find the scripted player/orc that's running around on a scripted path.
- Select one of the path points to see the dotted line forming the spline path. (see image below)
- Try moving the path points around to create different "flight paths."
- Now replace the player.dts file (the orc) with the airplane you've modeled.
Problems:
- I don't know how you can make new path points, as I've never looked into it that far.
- Gravity... you have to "turn off" gravity on the player so that the plane isn't constantly pulled downwards. Not sure how you do that.
So, overall, do you think this would work for your game?
01/08/2005 (10:30 pm)
Quote:
Is there available a pack or partial game example that would illustrate automation of the "flight" of a shape. This of course without regard to physics?
...I am looking for the shortest path to a working game.
- Go into the TGE FPS Demo and press F11 (Editor mode).
- Find the scripted player/orc that's running around on a scripted path.
- Select one of the path points to see the dotted line forming the spline path. (see image below)
- Try moving the path points around to create different "flight paths."
- Now replace the player.dts file (the orc) with the airplane you've modeled.
Problems:
- I don't know how you can make new path points, as I've never looked into it that far.
- Gravity... you have to "turn off" gravity on the player so that the plane isn't constantly pulled downwards. Not sure how you do that.
So, overall, do you think this would work for your game?
#9
BFN
Tim
01/09/2005 (6:09 pm)
Thanks for the encouragment and good ideas. I'll be trying a few ideas out over the next couple of days and will post an update on my progress.BFN
Tim
#10
1. I've got a highly modified version of starter.racing hammered into shape as the basis for the game.
2. I've created a clone of the Item class called Aircraft that I'm working in. At this point the only difference is that mGravity=0.
3. I've got a server side script solution for moving the plane that uses the schedule function. (This works on the server side but is too slow on the client side).
So far I've can drop into a mission and fly the plane across the sky without any shudder. I have a stationary camera that tracks the aircraft wherever it goes.
If necessary I can replace my server side script solution (for moving the aircraft) with code in the new Aircraft class processTick member function.
So far so good. I'll post another update once I get the next couple of steps out of the way:
1. Implement a simple library of maneuver elements instead of the current hard coded script parameters that were used for testing.
2. Read in a flight description (the sequence in aresti terms) and call the simple library functions to drive the aircraft through the sequence.
BFN
Tim
01/13/2005 (11:15 pm)
AeroJudge Progress Update:1. I've got a highly modified version of starter.racing hammered into shape as the basis for the game.
2. I've created a clone of the Item class called Aircraft that I'm working in. At this point the only difference is that mGravity=0.
3. I've got a server side script solution for moving the plane that uses the schedule function. (This works on the server side but is too slow on the client side).
So far I've can drop into a mission and fly the plane across the sky without any shudder. I have a stationary camera that tracks the aircraft wherever it goes.
If necessary I can replace my server side script solution (for moving the aircraft) with code in the new Aircraft class processTick member function.
So far so good. I'll post another update once I get the next couple of steps out of the way:
1. Implement a simple library of maneuver elements instead of the current hard coded script parameters that were used for testing.
2. Read in a flight description (the sequence in aresti terms) and call the simple library functions to drive the aircraft through the sequence.
BFN
Tim
#11
Are you planning on this being a multi-player type of thing, or single player only?
Either way, you'll want to look at pack/unpack data as well as the processTick/interpolateTick for client side display of the movement of your planes. In a single player mode, this will not have any network latency, so it shouldn't have any lag induced time problems. I'm betting that since you used the Item class instead of vehicle class (or even player), that the pack/unpack updates don't send the same data that the first two would. Figuring out the best way to have that data sent across your server/client boundary (remember, even in a single player mode, you do still have both a server and a client process so to speak), and should clean up your client side rendering delays.
01/13/2005 (11:28 pm)
Sounds very nice!Are you planning on this being a multi-player type of thing, or single player only?
Either way, you'll want to look at pack/unpack data as well as the processTick/interpolateTick for client side display of the movement of your planes. In a single player mode, this will not have any network latency, so it shouldn't have any lag induced time problems. I'm betting that since you used the Item class instead of vehicle class (or even player), that the pack/unpack updates don't send the same data that the first two would. Figuring out the best way to have that data sent across your server/client boundary (remember, even in a single player mode, you do still have both a server and a client process so to speak), and should clean up your client side rendering delays.
#12
This will be a single player game (training tool). FWIW, the Aircraft class is identical to the Item class and shares all the same processing as the Item class. The only difference is the mGravity value is set to 0 so that the engine doesn't try to send the aircraft into the ground. When I used the Item class the background, not the aircraft, would jump up and down as the aircraft was flown in level flight. Kind of weird - I figured the camera was keeping the plane centered on the screen so this created the illusion of the world jumping up and down.
I looked at the player and vechicle classes at length and decided they would not buy me anything but more stuff I didn't need. I'm totally circumventing the engine's physics implementation on purpose. FWIW, I think you are right and I will have to delve into the processTick/InterpolateTick member functions before I get much farther - just because I need this puppy to be super smooth. I'm actually thinking of having the "aircraft path" in the object so there will be almost no data traffic as the server and client side objects would only have to know where the other was in "time" - they would both know the path the aircraft will have taken. I thought I might have gotten away with just moving the aircraft on the client side but I'm afraid (but not yet sure) that this might screw up the camera object tracking.
FWIW, I'm developing this on a 3.4GHz XPS. For giggles, I copied the game onto an old 800Mhz PIII and ran it there. There was no descernable difference in the performance of the aircraft flight. There was a huge difference in load times etc. This says a lot for the efficiency of the script compiler in Torque.
History:
On the client/server aspect. I tried a client side script that used schedule to "loop" through a set of coordinates, calling setTransform at each iteration. The screen response was very "jerky". This same technique on the server side is "smooth". I gave up delving into the engine specifics but assumed that the client side implementation was causing a message to be sent to the server and then the server would send the message back to the client. I surmised the server side implementation cut out half of the traffic. Thread contention may have also played a part. Sorry, I can't be more specific on this but I'm still hacking my way through the underbrush of the C++ implementation and once I decided to implement my own object the point became moot.
Future:
Every hour I spend on this engine sees one or two lights flickering on. Eventually, I'll get the meme figured out and get reasonably productive. The Torque code base seems pretty stable and while the C++ code is not "overly documented" I can figure out what is going on if I spend a lot of time walking through it in debug mode.
My biggest problem is that the game is full of "multiplayer" architecture that is just getting in the way. However, the engine has enough redeeming features to make it worth the effort.
BFN
Tim
01/14/2005 (12:17 am)
Stephen,This will be a single player game (training tool). FWIW, the Aircraft class is identical to the Item class and shares all the same processing as the Item class. The only difference is the mGravity value is set to 0 so that the engine doesn't try to send the aircraft into the ground. When I used the Item class the background, not the aircraft, would jump up and down as the aircraft was flown in level flight. Kind of weird - I figured the camera was keeping the plane centered on the screen so this created the illusion of the world jumping up and down.
I looked at the player and vechicle classes at length and decided they would not buy me anything but more stuff I didn't need. I'm totally circumventing the engine's physics implementation on purpose. FWIW, I think you are right and I will have to delve into the processTick/InterpolateTick member functions before I get much farther - just because I need this puppy to be super smooth. I'm actually thinking of having the "aircraft path" in the object so there will be almost no data traffic as the server and client side objects would only have to know where the other was in "time" - they would both know the path the aircraft will have taken. I thought I might have gotten away with just moving the aircraft on the client side but I'm afraid (but not yet sure) that this might screw up the camera object tracking.
FWIW, I'm developing this on a 3.4GHz XPS. For giggles, I copied the game onto an old 800Mhz PIII and ran it there. There was no descernable difference in the performance of the aircraft flight. There was a huge difference in load times etc. This says a lot for the efficiency of the script compiler in Torque.
History:
On the client/server aspect. I tried a client side script that used schedule to "loop" through a set of coordinates, calling setTransform at each iteration. The screen response was very "jerky". This same technique on the server side is "smooth". I gave up delving into the engine specifics but assumed that the client side implementation was causing a message to be sent to the server and then the server would send the message back to the client. I surmised the server side implementation cut out half of the traffic. Thread contention may have also played a part. Sorry, I can't be more specific on this but I'm still hacking my way through the underbrush of the C++ implementation and once I decided to implement my own object the point became moot.
Future:
Every hour I spend on this engine sees one or two lights flickering on. Eventually, I'll get the meme figured out and get reasonably productive. The Torque code base seems pretty stable and while the C++ code is not "overly documented" I can figure out what is going on if I spend a lot of time walking through it in debug mode.
My biggest problem is that the game is full of "multiplayer" architecture that is just getting in the way. However, the engine has enough redeeming features to make it worth the effort.
BFN
Tim
Torque Owner Timothy May
Tim