It's startign to look like a game...
by Kirby Webber · 01/17/2006 (4:27 pm) · 6 comments
I realized over the holidays that my last few .plans have promised screenshots, but never delivered. That's something I fully intend to rectify this time around.
I am one of a fortunate few who works for a company that actually gives their employees the entire week between Christmas and New Years' off.
Guess what I did...
If you guessed "busted @ss on your game project for approximately 16 hours a day for seven straight days" then you'd be dead on. That's exactly what I did and boy howdy has it paid off... in spades!
I started out, over a month ago, by porting my project over to TGE 1.4. It seemed a perfect opportunity to cleanup a great deal of code and scripts in an effort to really get a solid and stable baseline to build on top of.
To this end, I proceeded step by painstaking step, porting -literally- one script at a time whenever possible. This proved to be both a valuable and educational move on my part.
Turned out, there were numerous errors in those scripts that didn't generate error messages in the console, but did result in certain undesirable behaviors. I'm talking silly oversights like having removed an IF() statement from the ::damage() function that allowed that function to be reentered even moments after the vehicles were declared "destroyed".
I reformatted everything for uniformity. I added path/filename.cs comments in the header of every script to eliminate those "am I in client/game.cs, or server/game.cs?" moments. I could give a list of simple, yet effective changes to my scripts, but suffice it to say - I got anal about my code and scripts and it has paid off. =)
On the coding front, I've added a number of sorely needed resources to my project, some of which felt very much like a plug and play device - drop in, add to project, recompile, done! Others, however, were not so accomodating.
The most significant addition, from a sheer "volume of changes affected" standpoint (as well as an "impact on gameplay" perspective), would be the turret/ aiTurret resource from Paul Dana. While it is an excellent resource that has already benefitted (is that a word?) my project in numerous ways, integration with 1.4 wasn't exactly the easiest of tasks.
There are many areas this resource affects that have seen significant changes to the source code since its' original release, and other areas are wholly absent at this time. Not being native to C++, it was truly a mental excercise in logic for me, an excercise I did eventually come out on top of. Thank God for those Object Oriented primer classes in college. =)
Now, for anyone familiar with my project and it's general premise, turrets might sound like an odd resource to include - after all we're talkin "jet cycles -n- guns" right? Not "tanks -r- us!"... Humor me for a moment, it will all become clear. =)
I had talked, in a couple of previous .plans about the overall difficulty of targetting enemies at high speeds and the subsequent need for some form of targetting assistance.
To this end, I had devised, (in my head at least), a system wherein the player would be provided with a large, circular targeting reticle. Whenever an enemy, or group of enemies was found to be within the reticle, and within range of the currently selected weapon system, the closest target would be selected and the vector(s) of the weapon(s) altered to match that of the target.
Clear as mud?
I did manage, quite some time back, to kludge together a working prototype in script only, with somewhat dubious results. In the end, the fact was that it was far less stellar than I had originally envisioned.
Enter Paul's turret resource.
Turrets have provided nearly all of the functionality I ever wanted from my targetting schema and then some. Currently, I am mounting two aiTurrets to the vehicles when they are added to the simulation, with heavily modified script functions. I basically stripped them (the aiTurrets) entirely of their ability to fire autonomously on their selected targets, and am providing the player with direct control over the weaponImage trigger(s).
What this means is that, as one races about the arena, the turrets select their own targets, allowing you, the player, to focus on when to fire and how to manuever.

Now, obviously this is still in need of refinement, but as a rough prototype it has gone a long way towards illustrating the overall feel of the gameplay and is looking extremely promising.
Currently, the turrets are bound only by minimum/ maximum yaw/ pitch values and are using separate triggers (referring to a trigger entity, not weapon triggers) to select targets and so forth. When I'm done, I'd like to have them share the same trigger, which should mean that both turrets will always select the same target, as well as add the criteria of the screen radius.
When it comes to the screen radius, I'll have to differentiate between players and bots (as bots obviously won't have the luxury of even having a screen, let alone a radius ON a screen) for target selection. I have a feeling that during this period, I'll be getting very cozy with dglPointToScreen(). =)
On another front, I've had quite a bit of fun with the playGui lately.

Obviously, there's now a digital speedometer, working radar and a horizontal compass. For those of you who are wondering, the numbered circular image to the left is a placeholder, but will be part of a weapon/ ammunition indicator schema I have worked out.
In the center of the screen, you'll notice a very "busy", if not a bit strange, gui apparatus. This is my all-in-wonderful dojumawhatsisthingamajig!
The inner radius of the outer ring (did that make sense?) will hopefully mark the range of valid target selection when the targeting routine is finished, while the outside edges of this area mark the health meter (right) and energy meter (left) respectively. Those are courtesy of the health bitmap resource here on the garage games site - though I had to add support for energy myself - not that that was difficult or anything.
In the center I've added a customized artificail horizon/ attitude control.
I decided to add this to the player HUD because people (okay, mainly my father) had a tendancy to nose their vehicles into the ground with surprising frequency. It seems that attitude and pitch are difficult to gage from third person perspective, well at least it is when you're not operating these things every single day for hours on end while modifying behaviors and testing them in-game.
Some preliminary testing has yeilded an overall positive response from those who've tried it out (which includes a few more people than just my Dad). Nothing is really final of course, but so far this handy little gem seems to help people keep their noses out of the dirt. Literally. =)
On my final front - well, there's a great deal more I could get into to, but this is as far as I'm going with this .plan - you might have noticed that there is another player in one of those previous screen shots...

Meet Road Rash, my testing buddy.
Road Rash is... well... Road Rash is dumb as a freakin' brick! He doesn't drive worth a d@mn, has no idea where he's going half the time, and has yet to fire a single d@mn shot at me. I'm telling you, he's just plain stoooopid!~
Of course, I can say all of this without fear of reprisal because Road Rash is my first 'bot'... well, my first vehicle bot anyway.
Originally, I added him in to test out my targetting solutions, so his haphazard piloting didn't matter much. Once I had the turrets in and the targeting roughed out, I decided to give him a solid path, after all everyone needs some direction in their life, even if that lifle consists of 2- 5 minute testing intervals!
All in all, he's currently pretty basic, but it's a start. He doesn't know how to die (yet), how to attack, or any of the other spiffy things he'll eventually be able to do, but he'll get there and when he does, he'll provide the foundation for the entirety of the single player game. Maybe I'll get more into that statement next time around.
One last thing... really: I've finally started down the road towards porting some decent artwork intom my game. Josh has not only finished the concpet, but the model as well:





Obviously, it's not skinned yet, but once it is, I plan to get some animation & LOD magic going on and getting that baby in game! I'll be sure to post a screen or two when I do...
In the meantime, thanks for reading all of this. I hope the holidays were kind and that the new year is looking bright for everyone... it is for Afterburn! (C:
~ Cheers
I am one of a fortunate few who works for a company that actually gives their employees the entire week between Christmas and New Years' off.
Guess what I did...
If you guessed "busted @ss on your game project for approximately 16 hours a day for seven straight days" then you'd be dead on. That's exactly what I did and boy howdy has it paid off... in spades!
I started out, over a month ago, by porting my project over to TGE 1.4. It seemed a perfect opportunity to cleanup a great deal of code and scripts in an effort to really get a solid and stable baseline to build on top of.
To this end, I proceeded step by painstaking step, porting -literally- one script at a time whenever possible. This proved to be both a valuable and educational move on my part.
Turned out, there were numerous errors in those scripts that didn't generate error messages in the console, but did result in certain undesirable behaviors. I'm talking silly oversights like having removed an IF() statement from the ::damage() function that allowed that function to be reentered even moments after the vehicles were declared "destroyed".
I reformatted everything for uniformity. I added path/filename.cs comments in the header of every script to eliminate those "am I in client/game.cs, or server/game.cs?" moments. I could give a list of simple, yet effective changes to my scripts, but suffice it to say - I got anal about my code and scripts and it has paid off. =)
On the coding front, I've added a number of sorely needed resources to my project, some of which felt very much like a plug and play device - drop in, add to project, recompile, done! Others, however, were not so accomodating.
The most significant addition, from a sheer "volume of changes affected" standpoint (as well as an "impact on gameplay" perspective), would be the turret/ aiTurret resource from Paul Dana. While it is an excellent resource that has already benefitted (is that a word?) my project in numerous ways, integration with 1.4 wasn't exactly the easiest of tasks.
There are many areas this resource affects that have seen significant changes to the source code since its' original release, and other areas are wholly absent at this time. Not being native to C++, it was truly a mental excercise in logic for me, an excercise I did eventually come out on top of. Thank God for those Object Oriented primer classes in college. =)
Now, for anyone familiar with my project and it's general premise, turrets might sound like an odd resource to include - after all we're talkin "jet cycles -n- guns" right? Not "tanks -r- us!"... Humor me for a moment, it will all become clear. =)
I had talked, in a couple of previous .plans about the overall difficulty of targetting enemies at high speeds and the subsequent need for some form of targetting assistance.
To this end, I had devised, (in my head at least), a system wherein the player would be provided with a large, circular targeting reticle. Whenever an enemy, or group of enemies was found to be within the reticle, and within range of the currently selected weapon system, the closest target would be selected and the vector(s) of the weapon(s) altered to match that of the target.
Clear as mud?
I did manage, quite some time back, to kludge together a working prototype in script only, with somewhat dubious results. In the end, the fact was that it was far less stellar than I had originally envisioned.
Enter Paul's turret resource.
Turrets have provided nearly all of the functionality I ever wanted from my targetting schema and then some. Currently, I am mounting two aiTurrets to the vehicles when they are added to the simulation, with heavily modified script functions. I basically stripped them (the aiTurrets) entirely of their ability to fire autonomously on their selected targets, and am providing the player with direct control over the weaponImage trigger(s).
What this means is that, as one races about the arena, the turrets select their own targets, allowing you, the player, to focus on when to fire and how to manuever.

Now, obviously this is still in need of refinement, but as a rough prototype it has gone a long way towards illustrating the overall feel of the gameplay and is looking extremely promising.
Currently, the turrets are bound only by minimum/ maximum yaw/ pitch values and are using separate triggers (referring to a trigger entity, not weapon triggers) to select targets and so forth. When I'm done, I'd like to have them share the same trigger, which should mean that both turrets will always select the same target, as well as add the criteria of the screen radius.
When it comes to the screen radius, I'll have to differentiate between players and bots (as bots obviously won't have the luxury of even having a screen, let alone a radius ON a screen) for target selection. I have a feeling that during this period, I'll be getting very cozy with dglPointToScreen(). =)
On another front, I've had quite a bit of fun with the playGui lately.

Obviously, there's now a digital speedometer, working radar and a horizontal compass. For those of you who are wondering, the numbered circular image to the left is a placeholder, but will be part of a weapon/ ammunition indicator schema I have worked out.
In the center of the screen, you'll notice a very "busy", if not a bit strange, gui apparatus. This is my all-in-wonderful dojumawhatsisthingamajig!
The inner radius of the outer ring (did that make sense?) will hopefully mark the range of valid target selection when the targeting routine is finished, while the outside edges of this area mark the health meter (right) and energy meter (left) respectively. Those are courtesy of the health bitmap resource here on the garage games site - though I had to add support for energy myself - not that that was difficult or anything.
In the center I've added a customized artificail horizon/ attitude control.
I decided to add this to the player HUD because people (okay, mainly my father) had a tendancy to nose their vehicles into the ground with surprising frequency. It seems that attitude and pitch are difficult to gage from third person perspective, well at least it is when you're not operating these things every single day for hours on end while modifying behaviors and testing them in-game.
Some preliminary testing has yeilded an overall positive response from those who've tried it out (which includes a few more people than just my Dad). Nothing is really final of course, but so far this handy little gem seems to help people keep their noses out of the dirt. Literally. =)
On my final front - well, there's a great deal more I could get into to, but this is as far as I'm going with this .plan - you might have noticed that there is another player in one of those previous screen shots...

Meet Road Rash, my testing buddy.
Road Rash is... well... Road Rash is dumb as a freakin' brick! He doesn't drive worth a d@mn, has no idea where he's going half the time, and has yet to fire a single d@mn shot at me. I'm telling you, he's just plain stoooopid!~
Of course, I can say all of this without fear of reprisal because Road Rash is my first 'bot'... well, my first vehicle bot anyway.
Originally, I added him in to test out my targetting solutions, so his haphazard piloting didn't matter much. Once I had the turrets in and the targeting roughed out, I decided to give him a solid path, after all everyone needs some direction in their life, even if that lifle consists of 2- 5 minute testing intervals!
All in all, he's currently pretty basic, but it's a start. He doesn't know how to die (yet), how to attack, or any of the other spiffy things he'll eventually be able to do, but he'll get there and when he does, he'll provide the foundation for the entirety of the single player game. Maybe I'll get more into that statement next time around.
One last thing... really: I've finally started down the road towards porting some decent artwork intom my game. Josh has not only finished the concpet, but the model as well:





Obviously, it's not skinned yet, but once it is, I plan to get some animation & LOD magic going on and getting that baby in game! I'll be sure to post a screen or two when I do...
In the meantime, thanks for reading all of this. I hope the holidays were kind and that the new year is looking bright for everyone... it is for Afterburn! (C:
~ Cheers
About the author
Recent Blogs
• Prepping for the grind again.• Production Quality Art... At Last =)
• Plugging away
• Holding pattern
• Still here...
#2
01/17/2006 (5:59 pm)
I agree. One of the best .plan's I have read in a while :)
#3
01/18/2006 (1:35 am)
I like that model. Great proportions and lines on it. Big open areas contrasted with nice areas of finer detail. Very appealing. :)
#4
01/18/2006 (2:02 pm)
Another thing that helps with 3rd person altitude perception is a shadow. In Marble Blast, we found it very confusing before we had the shadow on the marble in.
#5
Oddly enough, there seems to be some "oddness" with shadows on hovers... at least, they don't seem to work "out of the box" the way wheeled vehicle shadows do.
In all honesty, I just shoved it to the bottom of the "todo" list as purely aesthetic, but now that you bring this up, I may have to fish around for some info on how to get it working. (C;
01/18/2006 (2:59 pm)
You know Pat, I hadn't thought about that, but you're right. It would definitely provide the player with a definitive visual cue.Oddly enough, there seems to be some "oddness" with shadows on hovers... at least, they don't seem to work "out of the box" the way wheeled vehicle shadows do.
In all honesty, I just shoved it to the bottom of the "todo" list as purely aesthetic, but now that you bring this up, I may have to fish around for some info on how to get it working. (C;
#6
01/18/2006 (9:55 pm)
Nice plan... and cool screenies 
Torque Owner Anders Norén