Simple AI Tutorial in the works
by Richard Ranft · in Torque 3D Beginner · 01/09/2013 (7:05 am) · 25 replies
I'm working on a simple AI tutorial for T3D because the server/aiPlayer.cs script has really bothered me for a long time. At the moment I'm working in what is essentially a completed RTS Prototype project, so if you have followed that tutorial this will be a continuation of it.
When I say "simple," I mean simple. The most advanced thing I'm really doing is converting the AIManager into an actual AIManager. Not in the RTS "commander" sense, but in the sense that it will keep track of AI units that are near the players vs those that are farther away and adjust their "think ticks" so that near AI get more think time (are more responsive) than distant units.
I've also discovered that the callbacks that register on the datablock have an extra parameter for a reason: Since the callback is registered on the datablock, %this refers to the datablock. The %obj parameter in the examples is actually the %this for the AIPlayer that the callback is being triggered for.
Another thing to keep in mind when fiddling with this in general is that all of the AIPlayer-scoped functions are just that; functions scoped to that namespace. They are not actually members of a script-side class - we know from experience that names conflict between engine and script objects so this would not work. However, since they are scoped to AIPlayer you can call them on any AIPlayer object!
Ok, enough rambling. I really just wanted to sort of "announce" this and find out how much interest there is.
When I say "simple," I mean simple. The most advanced thing I'm really doing is converting the AIManager into an actual AIManager. Not in the RTS "commander" sense, but in the sense that it will keep track of AI units that are near the players vs those that are farther away and adjust their "think ticks" so that near AI get more think time (are more responsive) than distant units.
I've also discovered that the callbacks that register on the datablock have an extra parameter for a reason: Since the callback is registered on the datablock, %this refers to the datablock. The %obj parameter in the examples is actually the %this for the AIPlayer that the callback is being triggered for.
Another thing to keep in mind when fiddling with this in general is that all of the AIPlayer-scoped functions are just that; functions scoped to that namespace. They are not actually members of a script-side class - we know from experience that names conflict between engine and script objects so this would not work. However, since they are scoped to AIPlayer you can call them on any AIPlayer object!
Ok, enough rambling. I really just wanted to sort of "announce" this and find out how much interest there is.
About the author
I was a soldier, then a computer technician, an electrician, a technical writer, game programmer, and now software test/tools developer. I've been a hobbyist programmer since the age of 13.
#2
01/09/2013 (8:44 am)
I've decided to set up a public Git repo and work on it live there. It's just scripts and should work with any version of T3D after commercial 1.2. I'll post a link to it when it's ready. 
#4
A note - it's really only scripts, and not all scripts either. So you should make a new project, complete the RTS Prototype tutorial and then pull down the repo somewhere, then copy the scripts into the project (or I suppose you could check them out directly into the new project). It is assumed that you have completed that tutorial so I assume you have the relevant art assets.
Let me know if there are issues and I'll try to adjust things to fit.
[EDIT]
Changed my user name on GitHub when I left GG so as not to confuse people, so the link broke. Fixed now!
01/09/2013 (9:59 am)
Ok, the repo is up.A note - it's really only scripts, and not all scripts either. So you should make a new project, complete the RTS Prototype tutorial and then pull down the repo somewhere, then copy the scripts into the project (or I suppose you could check them out directly into the new project). It is assumed that you have completed that tutorial so I assume you have the relevant art assets.
Let me know if there are issues and I'll try to adjust things to fit.
[EDIT]
Changed my user name on GitHub when I left GG so as not to confuse people, so the link broke. Fixed now!
#5
01/09/2013 (10:01 am)
A note - the AI is not quite smart enough to use a grenade launcher yet.... 
#6
01/09/2013 (10:32 am)
I like this Richard. 
#7
I applaud this effort.
01/09/2013 (10:57 am)
Heh, you guys writing Tutorials, guides, and other Resources are really going to hate me once the new Templates go live ;) I'm actually looking at removing the ai scripts altogether... since they don't currently do anything.I applaud this effort.
#8
01/09/2013 (10:59 am)
Actually Richard, would you be interested in eventually being contacted for a series of tutorials that would build upon the concept of our Basic Template and show how to introduce players, ai, weapons, items, etc., into a basically empty project?
#9
01/09/2013 (10:59 am)
EDIT: silly double post!
#10
Besides, it's not wasted effort - some people are still using commercial licenses for whatever reason. And I don't really believe in "useless knowledge" (Ok, I do, but it's really about context).
01/09/2013 (12:44 pm)
Yeah, sure - I'll just have to see how long it takes me to figure it out again.... lolBesides, it's not wasted effort - some people are still using commercial licenses for whatever reason. And I don't really believe in "useless knowledge" (Ok, I do, but it's really about context).
#11
01/09/2013 (1:50 pm)
Hopefully it won't seem too unfamiliar, but much more logical and intuitive in structure. I'm sort of working backwards from a FPS Template (which is basically a reorganized and tweaked Full Template) in order to get to the Basic Template, and I hope to have the 2nd pass of FPS Template done soon. Once I do have it finished I'll share it with you and a few others who may be interested in (re)building some tutorials with the knowledge that the Basic Template (somewhere between the functionality of the current Empty and Full templates) should be the launching point for creating new templates and tutorials in the future.
#12
Some progress - the bots now let go of the trigger when their target dies. They don't seem to like the Ryder very much, though - I'll have to tweak their firing a bit on a per-weapon basis. The Ryder is a semi-automatic weapon and won't just spray bullets; you actually have to pulse the trigger. Planned on it, just haven't gotten to it yet. Also, the Grenadier bot will attempt to close to range before opening fire and wasting more grenades than absolutely necessary (still can't hit the side of a barn, though).
01/09/2013 (4:09 pm)
Another note - I created my project by copying the Full template to My Projects by hand and adjusting the project generation scripts to accommodate my project. Just so I'm clear on the environment here....Some progress - the bots now let go of the trigger when their target dies. They don't seem to like the Ryder very much, though - I'll have to tweak their firing a bit on a per-weapon basis. The Ryder is a semi-automatic weapon and won't just spray bullets; you actually have to pulse the trigger. Planned on it, just haven't gotten to it yet. Also, the Grenadier bot will attempt to close to range before opening fire and wasting more grenades than absolutely necessary (still can't hit the side of a barn, though).
#14
01/10/2013 (11:34 am)
Helpful, minor tweaks to get it to fit what I'm doing here and it seems to aim a little high so perhaps gravity in T3D is not what I think it is....
#15
01/10/2013 (3:54 pm)
Did a quickie test to see how well multiplayer is working and it appears to be pretty decent. I discovered that my starter project was actually the Adventure Prototype prototype (redundant, I know) and my camera start location doesn't work in multiplayer, but hey. You can each build barracks and spawn units that can attack the other teams. I'm wondering how the AI prioritization is working out, looks like it's doing what it's supposed to but it's a little hard to tell. I can't help but worry that I'm burning way too many cycles fiddling with who belongs in what lists....
#16
01/11/2013 (11:04 pm)
More multiplayer tests today and some stress testing. The AI "LOD" system seems to be helping a lot, and we had about a hundred "thinking" units on the screen (doing full-scene unit-to-unit range testing), but the frame rate was around 10~15. Had over 400 on screen with only about 30 "thinking" units with about 5~10 fps. Still tweaking, but it's coming along.
#17
Tried three different methods of having units call for support, the most recent uses the EventManager object and is by far the most efficient (guessing from response times and overall frame rates).
01/16/2013 (10:07 am)
Added more "think", reduced frame rate. on my rig at work I get about 12 FPS with 20~30 fighting units on screen, but explosions cause things to hitch something fierce if more than 2~3 units take damage from them and sometimes hang the game.Tried three different methods of having units call for support, the most recent uses the EventManager object and is by far the most efficient (guessing from response times and overall frame rates).
#18
It's going to be a "simple" AI tutorial, but I've discovered that adding Bryce's ballistics calculator in source is way faster than in script (no kidding, right) - to the point that it's painful in script with more than a few units firing grenade launchers. And that's on top of the particle frame rate hit on explosion.
So the question is; Would you still consider it "simple" if there were a function or two to add to the engine? It works in script, so I'm wondering where the "comfort zone" is on this.
01/17/2013 (3:06 pm)
I have a question -It's going to be a "simple" AI tutorial, but I've discovered that adding Bryce's ballistics calculator in source is way faster than in script (no kidding, right) - to the point that it's painful in script with more than a few units firing grenade launchers. And that's on top of the particle frame rate hit on explosion.
So the question is; Would you still consider it "simple" if there were a function or two to add to the engine? It works in script, so I'm wondering where the "comfort zone" is on this.
#19
Personally I say go code since it's a performance issue and there is no reason for anyone who wants to call themselves a game developer to not know how to add a bit of code and recompile. Oh yeah, sorry about the overkill with those grenade and rocket explosions -- I'm to blame for that :)
01/17/2013 (3:23 pm)
Since it's an aspect that could also demonstrate when/how to optimize by moving some code into C++ you might offer an optional branching point in your Tutorial at this point and leave it up to the user to use the method that is most comfortable for their coding or development skill.Personally I say go code since it's a performance issue and there is no reason for anyone who wants to call themselves a game developer to not know how to add a bit of code and recompile. Oh yeah, sorry about the overkill with those grenade and rocket explosions -- I'm to blame for that :)
#20
Do this in steps to make the lesson more valuable:
01/18/2013 (1:19 am)
@Richard,Do this in steps to make the lesson more valuable:
- Code in script first. Show limitations of script only method.
- Show how to enable metrics like FPS here to determine there is an issue.
- Put forward the idea of speeding up that one piece in order to overcome speed limitations.
- Contrast both solutions and do step by step conversion as necessary to show how the script was converted to C++.
Torque 3D Owner Scott Warren