Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: ares on January 04, 2007, 06:37:41 pm
-
Hi everyone!
This is my first post here, so bear with me a little. I am slasher from the game-warden forums.
I am a quite experienced c/c++ coder and I'm currently studying for a PhD in Robotics/AI in Germany. I got here via the Battlestar Galactica mod hosted on game-warden and I am very interested in doing things with the AI. Now, I have heard there are weird things going on when you edit parts of the AI code... there were some forum messages to that effect.
Anyway, I've been reading up on game-oriented AI (which is quite different from academic AI research) and FS2_open in general, which makes me have some questions to you guys.
1) Would it be useful to add Lua scripting hooks to the AI code to add new behaviors that way? I'm not so sure of the details here, but after a brief look at the wiki, that should be possible and maybe a bit more appropriate than another .tbl file?
2) To avoid the whole backwards compatibility discussion, could there be one big setting saying "use AI implementation X" with a default pointing to the current one? I've already gone through the code to identify the "interface", i.e. the ai_* functions called from outside the AI module, which has to stay the same. So, with this global setting, it should be fairly easy (famous last words) to reimplement the AI in some other way. Once I find my way around completely, modularization of the AI code would be my first priority.
3) Any questions/comments/requests/hints from your side are very much appreciated. I've only been reading into this for a couple of days, so I might be completely wrong with my assessment of the situation.
For now, I am still working on getting my development build from the HEAD to run, so it will be a little while until my contributions come in. However, game development (especially AI) has always fascinated me, so I am very motivated. Let me know what you think.
Bye!
-
I'd like a more dynamic AI system personally. The current AI is a bit plain and quite frankly doesn't fight like a human would. I'd like the game to automatically randomize AI flight characteristics at the beginning of the mission, which could be done in the modular fasion you described. I don't know what the SCP coders say, but I say go for it.
Also, I think the game already allows you to select a different AI version but I've only been able to select the retail version. Correct me if I'm wrong but a modified AI version was used but people didn't like it?
I'd like the AI to dogfight better instead of leading you in circles and also it needs to learn how to fly capships and bombers properly. I was actually thinking that it'd be nice to see an AI take control of a capship and figure out where it should position itself to to maximum damage. It would make capship fights MUCH better.
Again, I haven't touched the SCP code so I'm not sure what those guys will say.
-
My turn! :D
:welcome:
Welcome to Hard Light Productions! Here are the minor offenses, and their corresponding punishments! Never comined "F", "S", or "3" in a thread! This minor offense is usually combated by the use of our standardized Flame-throwers! But, due to budget problems and a few legal concerns (lawyers don't like clients charred to their bones), there is no longer napal in the flame thrower, but rather holy water! Another major offense is disturbing our little buddy (hey! That was my lunch!) called Carl, the resident Shivan who has taken a fancy to living in our walls! Throw him your lunch, and you should be fine... But if you happen to be caught in the wall with Carl, simply take the emergancy saw, and cut off a few limbs! Carl should stop persuit, but if he doesnt... you're on your own! If you wish to leave HLP, simply walk to the back of the ship, and operate the airlocks! The only problem with that choices is the airlocks no longer work! You may check-out any time you wish, but you many not leave HLP! If you should have any concerns, simply walk to the bridge and open up the weapons locker. Inside is your standard AK-47 and Plasma Rifle! However, most of us have a bit of a hard time getting in, as only moderators, the hyper-intelligent shade of blue, and :v: have keys in! If you are a bit weary of staying on HLP, simply blow through the airlock and try to make your way over to the Game-Warden sister-station. Be careful, though! We are out of space suits, and I hear space doesn't have much oxygen... or much of anything! Good luck and enjoy your stay!
I guess too many of us are afraid to use new tactics... most people's style in this game is very practiced; most of us have played the main campaign many times as well as many mods.
I'd be happy to get some new higher AI-class levels... perhaps a learning-style for higher AI classes? Make engaging them gain at a certain rate, and nonengaging a quarter as fast learning? So if a enemy watches you dogfight for two minutes, it the equivelant of thirty-seconds in combat with you?
-
Stronger AI has always been something I've been looking forward to. I have no clue what you are talking about in your first post, but whatever you can do to make the enemy fighters fight smarter would be a boon to FS2, IMHO.
-
:welcome:
Sounds great. :) Do you have any code samples you could show us?
-
Ah. Welcome aboard slasher. I was wondering where you'd gotten to :)
-
some kind of scripting hook (i don't know lua, but i'm sure it would be useful to learn) into the AI would be fantastic, with a launcher option of enabling or disabling them. would also make debugging much easier with good code module management. I have a strong interest in game AI myself, and giving a scripting interface would make it a lot more accessable to people like me who don't have the skills to deal with the source code but want to contribute something.
GL and welcome to HLP!
-
The AI should NEVER be affected by a launcher flag.
Launcher flags should only really affect visuals, loading speed or be there for troubleshooting. They shouldn't ever be required for a mod or mission to work as designed. That's just ****ing stuipid cause it's so easy for someone to come along and just accidentally turn them off.
-
Can you rename some of the difficulty classes? Perhaps instead of the basic Very Easy, Easy, Medium, Hard, and Insane, add a class above Insane like Lunatic... make it so the enemy will learn your tactics to kill you faster; only way to win is to change your tactics every few minutes?
-
Thanks everyone for the interest!
What kind of code samples do you want? ;7
I'm not sure to what extend learning is really possible in real-time with the whole game going on simultaneously. However, we often let AI play against itself to train it offline, so that might be an option. Also, we might just "limit" AI to planning (without learning), like they did in FEAR. There are some nice articles about that on http://www.jorkin.com/.
Actually, things might be a bit challenging because its a space sim.. almost 6 degrees of freedom (maybe 5, not quite sure how those things like strafing and stuff change this). I've read stuff about path planning with dynamic constraints, as in flight dynamics: http://msl.cs.uiuc.edu/rrt/, mostly http://msl.cs.uiuc.edu/~lavalle/papers/LavKuf01b.pdf. So it should be possible, however, some optimizations might be necessary to make it perform in the game.
So, my idea for now is to kind of copy what they did for FEAR. We already have goals that get defined in FRED (correct me if I'm wrong) and might be added dynamically by the player when he/she commands allies. Then, it is "just" a matter of defining actions, with pre- and postconditions, maybe in Lua, which get chained by the planner for each AI controlled entity to achieve its goals. There might be wing (squad) actions as well to coordinate teams, I have to think about this a little longer. Learning could later be used to identify new actions or meta-actions (i.e. sequences of actions or maneuvers, like mentioned in previous threads).
Actually, is there a tutorial or something which I can follow to run the development build from MS visual studio? Or do I just have to build and run from the IDE?
BTW: great talk about managing software development: http://video.google.com/videoplay?docid=-5105910452864283694
Bye!
-
Some suggestions of things you might want to take into account:
If you're thinking of using lua for making AI decisions there's probably an overhead in doing that which might multiply up into quite a big overhead with hundreds of ships making hundreds of decisions very frequently.
Proper weapon firing accuracy? Volition's interpretation of accuracy is how fast the AI fires it's weapons. Presumably their thinking was "if you're a good shot you can shoot more often". Of course it's quite possible to think you're on target and not be, and fire. :rolleyes:
Collision avoidance. You. Huge capital ships. It doesn't matter what it is or how fast it's moving. The AI will crash into it. This should also take into account the size of both ships (bounding boxes?). For instance we have a big ship called the Whitestar which flies like a fighter but doesn't realise it's actually 125m long. It makes for some rubbish flying.
You also have the AI table to take into account and how that affects decisions made by the AI. Thought it was worth mentioning even though it's obvious. Since it sounds like you're considering something akin to a complete rewrite. Which incidentally I don't think is a bad idea.
I help teach AI at a uni. So if you get bored feel free to ICQ me :).
-
My vote for least realistic part of FreeSpace that should be fixed first:
The AI will crash into it.
I swear it's like outer space bumper cars, COMPLETELY unrealistic. Who would take a chance of sucking vacuum by running into something in outer space?
PS. Does anyone know Dr. Jan Plath from Germany?
-
Good luck. I'd like to see some of the code...
-
Lua stuff is pretty easy, once you get the hang of it.
For implementing Lua hooks, see: SetHookVar, SetHookObject, RemHookVar, RunCondition(?) and IsConditionOverride. These handle setting hook variables (SetHookVar), or object handles (SetHookObject), and removing them after the hook has executed (RemHookVar).
RunCondition is a bit more complex. It takes one argument, an object pointer. This is used to evaluate the preceding 'conditional' fields in scripting. The "condition" variable is used for a CHA_ define from scripting.h, which determines which action this is. You will need to define an action; do a global search for one of the CHA_ defines and it should be pretty clear, you will probably want to familiarize yourself with the conditional scripting .tbl syntax. I made a general overview of it in my pre-commit build thread, in the Recent Builds forum.
IsConditionOverride is for determining whether the original code functionality will be preserved. There is an order note here - things should always be defined in the order
1) if(!IsConditionOverride)
2) do_regular_stuff();
3) else RunCondition();
This allows for the override condition to do any setup for the RunCondition function, as well as evaluate things in their pre- state to toggle the regular stuff. Having RunCondition() (or any other scripting hook) after the default behavior allows the modder to selectively override the parts of the behavior that they want, if they don't want to rewrite that entire chunk of code. They can also use the override hook to gather any data required for that.
For implementing new Lua functions and libraries, see: ade_lib, ade_obj, ADE_FUNC, ADE_VIRTVAR, and ADE_INDEXER. ade_lib defines a new library, or, if the parent field is specified, a sub-library. An example of this is the Ships array in the Mission library. ade_obj defines a new object type, it is a template that takes the data storage type for the object in question (For example, an image handle would be <int>). You may want to use your own helper structs to allow you to check if the passed handle or object is valid; I've tried to keep Lua as safe as possible, so that only critical errors will cause it to completely crash.
ADE_FUNC defines a basic function, and uses the ade_get_args and ade_set_args to parse and return arguments, respectively. I recommend you take a look at existing functions to get the hang of using these. You can also use it to define operators, there is an array at the top of lua.cpp that lists all the operators. Please do not specify __index or __newindex unless you know exactly what you are doing; teh ADE_INDEXER define will probably do what you want.
ADE_INDEXER is essentially identical to ADE_FUNC, and is generally used for array usage ([]). See existing examples. ADE_SETTING_VAR is true when the form is Object[key] = something, ie the array index is being set rather than read.
ADE_VIRTVAR defines a function that will appear as a variable from within Lua. It's much like ADE_INDEXER, in that it uses ADE_SETTING_VAR and the basic function _get and _set functions. Note that both ADE_VIRTVAR and ADE_INDEXER should always return the appropriate value, even when the variable is set to.
Conventions: All Lua libraries and objects are l_<NAME> in lua.cpp. All Lua functions use Java-style naming, so getThis() or setThat() or doThis(). All functions that return handles, should always return handles. If there's a chance of failure, it should return an invalid handle, so that the Lua interpreter doesn't explode when a boolean or nil value is indexed. In addition, handles should define an isValid() function that checks whether the handle is both valid, and if the object is still alive (if applicable). Basically, this is so that a modder has a fast easy way of checking whether they can safely do something with a handle. All Lua variables (and libraries) use the general C++-style naming conventions, Variable, OtherVariable, MyArray, and so on. And all shorthand library names are two lower-case letters, preferably close together on a QWERTY keyboard and that are relatively easy to remember. (Basically: use common sense. :p)
References: Nothing official and up-to-date, unfortunately. -output_scripting will output all declared Lua functions, libraries, objects, and so on. This is generated from the description fields of the macros/functions.
Disclaimer: All this is generally based on What Made The Most Sense To Me The Last Time I Worked On It. Some of it may be inconsistent, owing to the gradual year-plus development of everything. There's also quite a bit of stuff I haven't mentioned because I hope that it's pretty self-explanatory from the way it's used in the code, if you have questions, go ahead and ask, I'd just rather not spend a couple hours writing everything up for a forum post that will more than likely be forgotten & ignored once this thread drops off the first page. :-/ And I've tried to comment things decently, but there are some sections that can just be pretty damn confusing, even if you know exactly what's going on. I've tried to keep their sections in their own little world, that nobody needs to mess with, except to make serious lowlevel changes to the system. You shouldn't _ever_ need to change a function with more than 3 "lua_" functions grouped together, unless you're fixing a bug with the scripting system itself.
-
Great! Thank you all for your help and advice!
It would be nice to keep this thread alive for a while, cause as much as I have played space sims, I could use some out-of-the-box advice on maneuvers and so on. So, if you have any more ideas as to what the AI could do, let me know.
I'll be working on it hopefully this week. I have a little plan, which goes like this:
0. Get my own fs2_open build to run and play a simple test mission (is there one? otherwise I make one, cant be that hard to place me and one fighter in space)
1. further hide/modularize the AI code, so it can be easily replaced
2. implement better collision avoidance in a separate version of the current code (possible because of modularization)
3. fix accuracy issue, this is maybe possible with some sort of "distance" threshold when the AI thinks its on target, in degrees or so
4. add a way to script new AI behaviors (right now, depending on the goal an AI is pursuing, it executes behavior to reach it, like "dock" or "chase", if we keep the scripts lightweight, overhead should be small)
5. implement FEAR-like action planner to have more dynamic behavior (needs reactive component to avoid collisions, etc)
Choosing one AI implementation will be done as a configuration in one of the table files. 5. will be most work of course, but I hope that by that time, I'll have gotten to know the code enough so it would be easier than starting now. Also, smaller steps of improvements would maybe benefit you guys more as well and let me make baby-steps into the code.
I'll let you know when I'm done with 1.
-
Sounds like a good plan. You'll have no trouble making the mission for step 0. Just follow the basic walkthrough in the FS2 help and it teaches you how to build a 1 on 1 between the player and a Mara. :)
-
Is it possible to be an observer, like in Unreal Tournament? I.e. just look at whats happening but not be a player in the game?
-
you've made me want to install FEAR again damn you.
*goes to find his DVD*
-
Is it possible to be an observer, like in Unreal Tournament? I.e. just look at whats happening but not be a player in the game?
In FS2, yes, the default controls are / (on the numpad) to view from selected ship, and . (also on the numpad) to 3rd person view selected ship. When in third person, you use the joystick to move the camera, so you can't move your ship. Also, each of those commands can be used separately. If you use the third person view with nothing selected, you will view your fighter.
Unfortunately, no, you can't actually go "ethereal" as an observer, you can only witness stuff from the third person view of a ship. However, if you're viewing third person from a capship, your perspective is a little larger, so it's easier to see what's going on...
-
Is it possible to be an observer, like in Unreal Tournament? I.e. just look at whats happening but not be a player in the game?
Make two ships (on friendly, one hostile) and then make an event in the Events Editor that does a (protect-ship Alpha 1). The two AI ships will battle it out while ignoring you completely. You can then fly about where ever you like to see the combat or use Spartan's suggestion to view everything externally.
-
a more suicidal ai and a ai that can survive longer than the average 1 minute life time.
these 2 at the very least would be good.
-
Hmm, after finally being able to compile and play my very own compiled version (YEAY!), I can see where you are coming from. I played it on the standard setting before, not big effort there. However, on the harder levels, they come at you like kamikazes, guns blazing. And I, still thinking bumping into them won't hurt, get taken out with this suicide attack. Damn. They are good at playing chicken though.
-
Chicken is fun to play when you have superior firepower (i.e. more powerful missiles, or just more missiles and stronger guns).
-
Guess what would IMO be much more realistic for capship AI and would improve some things a lot?
Make the cap ships move so that when they change direction, they begin the turn slowly, then gain angular velocity until they reach their maximum turn rate, then slow down the turn until they point to the direction they want to go.
That would be way more realistic than the way they currently turn. Currently they reach full turn rate immediately from the start of the turn and when they stop the turn they seem to suddenly throw their angular momentum to the same place that inertia in FreeSpace games in general is. It has always buggered me the most in these games.
It is, by the way, one of the reasons why the Colossus behaves like a baseball bat. Even though its CoG is set a bit behing, it wouldn't look so ridiculous if it actually behaved like it actually would. Of course it would need additional programming to make sure that the ship didn't overshoots it's desired direction, which would cause oscillation if the AI would continuously overshoot it's target.
Funny thing is that if a player controls a capital ship, they automatically do behave like this. Which means that it is indeed AI-specific.
The AI would need to consider howe long does it take to get the ship into maximum allowed turn rate. It could, for example, demand a 10 degree turn to accelerate the rotation to maximum. That would mean that the AI should first calculate how much it needs to turn the ship (in degrees), and then define how it should turn the ship to that direction.
If the angle of turn is exactly 20 degrees, the ship would start turning to desired direction, accelerate the turning speed until it reached the halfway and maximum turning speed, and immediately start decreasing the angular velocity so that the ship would in the end point at the desired direction.
If the angle is less than 20 degrees, the ship AI would accelerate the rotation until hitting the half way to the turn, and then slow down the turn for the rest of it.
If the angle is more than 20 degrees, the ship would reach maximum angular velocity, retain it until being 10 degrees from the desired direction and start slowing down the turning in order to avoid overshooting the target vector.
Please tell if this wish is too far-fetched. ;)
Another thing that might make the AI fighters and bombers look like they are controlled by human pilots: Do they ever use anything but pitch and yaw axes? I don't remember them using roll control very excessively.
Also, adding some small, random flight patch changes and corrections when flying from point A to point B would increase the humanity factor in the AI a lot. Some small, random weaving would be more believable than picking a direction and then flying toward the waypoint without even touching the controls.
And of course... Make them avoid collisions better. I think we all know the horrible feeling of pressing C-3-7 and being rammed by all your wingmen. Especially if you're flying at low speed and you turn around...
-
Good points about the weaving and bobbing. It's amazing what a little non-immediately-understandable behavior can do, Valve has a bit of that going on with the new Counter-Strike: Source bots. (or whoever coded them). It's quite amazing actually, when you're used to watching bots perform several obviously preprogrammed maneuvers. Even Halo's AI doesn't come close to mimicing human players.
The bots still suck, granted, at least on the level that they were set on. But for quite awhile, I was absolutely convinced that I was playing with human players, even in spec mode, just because the bots would randomly change the speed that they looked in different directions, would sometimes make random movements that didn't grant them any tactical advantage at all. Really made you think that there was some bored geek behind the controls, waiting for an enemy to pop out so he could shoot 'em.
-
Even Halo's AI doesn't come close to mimicing human players.
I think it does. The elites run around the player character, dodging (for the most part), charging, and meleeing when you're close enough. Grunts will run away from the character if he kills an elite, but if it runs into a large pack of grunts or a jackal or an elite, it'll start to try to kill you again. Plus, they all dive to avoid grenades (however, not to much success). Jackals also will duck behind their shield if they hear gunfire, and if they see your character, they'll turn and point you out to his allies. The USMC does the same thing. There's one downside, if you don't play Heroic or Legendary, they aren't that smart. However, that's a good developer technique to get new players playing their game.
-
Most of what you listed is actually part of the problem. By now I think that most people who are familiar with FPSes realize that there's a certain limit of control that the player has over their avatar in the gaming world; pointing and cowering may be realistic, but it's not anything you can really map to a keystroke. So even though it may be realistic, in-character, and in line with what would happen in the theoretical game world, it also limits the AI, at the same time, to a character in the game world. And at the same time, the movement is almost too intentional, too composed, and notices things that it wouldn't notice if it were a human player.
Although, Halo might've been a bad example to use - since you automatically know that anything but another Spartan is AI, and it's pretty much ingrained constantly as you play through the game and online. I don't know about Halo 2; I've never played it enough to be able to really compare SP and MP.
Don't get me wrong, Halo's AI is one of the most fun AIs to play with, but it just doesn't have the imperfection, clumsiness, and illogical behavior of a human player. :p
In Freespace, there is a certain advantage in that the AI is pretty much inherently constrained to the same kind of movement as a player. A Mara can't exactly pick its nose, no matter who it's controlled by. But things like a fighter twitching when it's bored, maybe doing some spins, doing stupid yet unpredictable things in combat would make it seem more human.
-
I like F.E.AR.'s AI. They move with military precision, but, when scared, start to retreat awkwardly. In the SP Demo, when you fire your weapon, won't come stupidly through the door to the room he's in, no, he dives out the window, into cover (but unforunately for him, right in front of a fire extinguisher ;7). You can tell when you've got the upper hand, because they'll start to call in reinforcements. If you've kinda lost that hand, they'll start to flank you, or coordinate a very deadly assault against you. If you throw a proxy mine, they'll stay away from it. If you throw a grenade, they'll dive under cover to avoid the blast. Heck, if you start firing at them, they won't make like a deer and stand there, they'll dive behind the nearest form of cover, then peek out with their weapon and blast you to bits...
-
keep in mind if you are going to do a rewrite, you need to modularize your code, in such a way that your code doesn't get into the old code, and original behavior is maintained when not using your AI, backwards compatibility is something we stick to with a disturbing degree of fanaticism.
i'd personally recommend some sort of function pointer table, perhaps with major and minor versions, so you freeze your code at what ever state it is in at a release so anyone who makes a campaign based on that release won't have to worry about the AI suddenly getting really good at taking out subsystems in the final mission, or taking advantage of turret blind spots ect...ect... years after there release.
-
keep in mind if you are going to do a rewrite, you need to modularize your code, in such a way that your code doesn't get into the old code, and original behavior is maintained when not using your AI, backwards compatibility is something we stick to with a disturbing degree of fanaticism.
i'd personally recommend some sort of function pointer table, perhaps with major and minor versions, so you freeze your code at what ever state it is in at a release so anyone who makes a campaign based on that release won't have to worry about the AI suddenly getting really good at taking out subsystems in the final mission, or taking advantage of turret blind spots ect...ect... years after there release.
this is exactly why i suggested modularizing the code and having a launcher flag to turn it on and off, possibly even a flag in the mod ini to use a particular AI version, or even a FRED flag to use advanced AI or retail AI. but it has to be able to be turned on or off. Karajorama effectively flamed me for suggesting it before and it made me sad :<
-
I think a fred flag would work better, being able to set AI level on a per ship basis would be great, though it would probly be best to have the AI version set in the AI table, or at least the default AI version.
-
I have some statistics for you. I made a mission over the weekend...
"Colossus Assult"
1 GTVA Colossus, Hostile
24 Myrmidon, 24 Perseus, 12 Herc MkII, 12 Ursa, 12 Medusa, 12 Artemis D.H., Friendly
In 6 hours 11 minutes 30 seconds (between start and last death)
98.9583% die (95 of 96 fighters)
52.631% die from collision damage alone
28.421% die from GTVA Colossus's defences
16.842% die from battle damage and collisions
2.105% die from flying into Alpha 1's line of fire
Here is how it was organized...
Alpha, Beta, Gamma - Herc MkII (4/wing, all else 6/wing)
Delta, Epsilon, Zeta, Eta - Myrmidon
Theta, Iota, Kappa, Lambda - Perseus
Mu, Nu - Ursa
Xi, Omnicron - Medusa
Pi, Rho - Artemis D.H.
83.3% support ships die (6 of 7 support ships)
100% of those said support ships die from collisions.
Only the last transport survived after I told it to leave when there were no other ships but myself, the Colossus, and Support Ship 7.
-
And then tehy say Colossus sucks!
-
Actually, about the FEAR AI:
I read an article of the guy behind it (on www.jorkin.com) and he said that there was actually no flanking and so on programmed. Also, calling for reinforcements didn't do anything, just a sound that was played when there was only one guy left in a squad. They thought you'd run into more NPCs later in the level anyway, so it'll look like they are the reinforcements ;)
About the flanking: Sometimes the closest valid cover point would be next to you, so the AI wants to advance to that cover. However, it also knows to keep out of your line of fire, so it finds a safe way there, which looks like flanking. Actually its not. Clever, eh?
About modularization:
Of course. Actually, did you know the linux kernel uses function pointers in structs to simulate something like polymorphism in C? They use it to abstract filesystem interfaces and such. Sounds like the perfect solution for this. Even though I would be against a pollution of the symbol table in the executable. Maybe something like dlopen() (http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html) exists in windows as well, so we can load AI implementation libraries (specified in tables?) dynamically. Then, the AI can have its own release cycle and you can say "I want AI version x.y for my mission".
[EDIT]: Ah, apparently libtool (from GNU, like autotools) has a special library for this, which is cross platform. Don't know if its an OK dependency. What license does the SCP use? GPL?
http://www.gnu.org/software/libtool/libtool.html
http://www.gnu.org/software/libtool/manual.html#Using-libltdl
-
About the flanking: Sometimes the closest valid cover point would be next to you, so the AI wants to advance to that cover. However, it also knows to keep out of your line of fire, so it finds a safe way there, which looks like flanking. Actually its not. Clever, eh?
Just a small note...
Stuff like that is what makes AI really good IMO. You give it a few basic objectives and how to do them, which it can then adapt to a greater goal. It makes it seem more human than having scripted "move from here to try and get around the player, when X>2" or whatever. :)
-
the license is at the top of every source file.
I've thought haveing the ability to load external DLLs would be cool for some time now, not just for AI, but graphics too, I like the idea, but I'm not high enough on the totem poll to make that sort of decision.
-
Yes, quite true. Its called emergent behavior:
http://en.wikipedia.org/wiki/Emergence#Emergent_properties
-
this is exactly why i suggested modularizing the code and having a launcher flag to turn it on and off, possibly even a flag in the mod ini to use a particular AI version, or even a FRED flag to use advanced AI or retail AI. but it has to be able to be turned on or off. Karajorama effectively flamed me for suggesting it before and it made me sad :<
Table flags are fine I never argued against that. FRED specifiable (especially on a per ship rather than per mission/ship class)
I'm sorry if you took it as a personal flame because it wasn't intended that way. I was merely trying to get across how bad an idea it actually is to do this as a launcher flag. If you're not an SCP coder I certainly don't expect you to have grasped why it's so bad so I wasn't having a go at you.
Launcher flags for AI settings are a really dreadful. Here's the reason. Suppose I make a mission. I want it played with a certain kind of AI and I design it for that. I spend hours playtesting the balance for every skill level. I get it just perfect. I release the mod with a readme that sets up the AI flags the way I want.
Someone downloads the mod, ignores the readme (as 90% of users do) and then goes on the forums to give me a load of "You suck! The enemy are too hard". Or someone downloads my mod and likes it but when they go to replay it, it's suddenly become too hard because they've changed the flags when setting up another mod.
Launcher flags should set up things like graphics and troubleshooting and things like that. They shouldn't have an appreciable effect on gameplay. You'll notice that as the engine matures the flags which do (TBP and WCS options for instance) will slowly be phased out of the launcher and replaced with table flags. If you look closely you'll notice that there is no "Toggle features for Beyond the Red Line" option in the launcher because we started a lot later than WCS or TBP and features we wanted were better integrated into the tables because the coders learnt that putting things like that in the launcher was a big mistake.
In addition by specifying them in the launcher it means that you have much less control as a mission designer. Either a feature is on or it's off. If it's in a table/FRED you can have all kinds of options. I'd love to see an AI Editor in FRED where you can specify exactly how each ship acts. :)
-
when I read that I thought you worded it harsher than you probably intended.
-
Yeah. When I re-read it I could see why Kaine thought it a personal insult. As I said the idea is stupid but I can't blame him for not knowing why.
It's not that Kaine is a moron for suggesting it. Just that we'd be morons if we did it that way as we should know better by now :)
-
no real offence taken, i realised as soon as i read your post exactly why it was such a bad idea. I think its good that you've explained it properly though. I agree entirely that having an AI profile defined per-ship in FRED would be an excellent implementation.
-
Yeah. I didn't have time for a longer explanation the first time :)
-
the license is at the top of every source file.
I've thought haveing the ability to load external DLLs would be cool for some time now, not just for AI, but graphics too, I like the idea, but I'm not high enough on the totem poll to make that sort of decision.
I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.
The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.
And I have nothing good to say about anything AI being tied to a Launcher flag.
-
I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.
The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.
Hmm, I don't understand what you mean in your messaging idea. You can only load libraries, like .dlls or .so or .dylib, not full programs with their own main(). Maybe for messaging, it would be nicer to have sockets or shared memory ipc? Maybe I didn't get your point.
The GNU libtool dl library (libtdl, see links above) is cross platform, so we just use that library. You have to compile fs2_open for the different platforms anyway, so there is no big difference.
-
we could always give dlls for different platforms different exstentions, then they could all be packed together, and the correct one loaded.
-
That happens anyway:
Windows: .dll
Mac OS X: .dylib
Linux: .so
-
I supose that's true, didn't even think of that.
-
I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.
The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.
Hmm, I don't understand what you mean in your messaging idea. You can only load libraries, like .dlls or .so or .dylib, not full programs with their own main(). Maybe for messaging, it would be nicer to have sockets or shared memory ipc? Maybe I didn't get your point.
The GNU libtool dl library (libtdl, see links above) is cross platform, so we just use that library. You have to compile fs2_open for the different platforms anyway, so there is no big difference.
Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.
However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.
Anyway, the problem with DLL support is not in simply getting them to load. You have to provide support for each one. That's an extra chunk of executable that can be release or debug. We're now up to 6 variations. Or it can be 32-bit or 64-bit. Now we're up to 12. This is all in addition to the original fs2_open executable.
In addition, campaigns or mods that want to release DLLs will either have to support them on all platforms, and/or compile them on all platforms, or simply support only one configuration. It also means that anyone can insert malicious, or further platform-specific code, into their DLLs. And they can go closed-source on us, so there's no way for anyone to verify DLLs.
Basically, it inserts a big chunk of complexity that seems completely contrary to what taylor's been trying to do, to make FS2_Open work and function the same on every single platform.
So in the end, I'm not sure what having DLLs would really accomplish. If they're meant to provide modders with a method of access to fs2_open, they're an extremely poor choice. Campaigns are left either having everyone compile from source, or compiling from source themselves and supporting every single platform under the sun. This bumps individual modders out of the loop, for the most part, and makes it even more difficult for people to get into modding - because they have to learn coding.
If they're meant to be released alongside the EXEs, what do they really gain? You can have a DLL for each AI version, but now people have to keep track of having the right DLLs for the right campaign. The modularity is nice - so all versions don't have to be loaded into memory - but I don't think that there would be any noticeable difference if things were coded properly. Plus, now you've got an extra component running around along with fs2_open and FRED that can develop oh-so-many extra bugs.
EDIT: Not to mention the inconsistencies that can easily develop when you've got CVS builds of both running around.
-
well the idea would be that campains could have there own DLLs, we wouldn't have to support any of them, just the ability to load a dll.
-
Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.
However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.
Aha, so you want an extra library to make talking to fs2_open easier. That would be very nice. Like extra admin UIs to remote control dedicated servers? Or maybe even an api to program a bot so it doesn't eat up resources on the server?
Anyway, the problem with DLL support is not in simply getting them to load. You have to provide support for each one. That's an extra chunk of executable that can be release or debug. We're now up to 6 variations. Or it can be 32-bit or 64-bit. Now we're up to 12. This is all in addition to the original fs2_open executable.
OK, I get it. Even though I am not so sure how to manage it with less effort as a static part of fs2_open. See last comment below.
In addition, campaigns or mods that want to release DLLs will either have to support them on all platforms, and/or compile them on all platforms, or simply support only one configuration. It also means that anyone can insert malicious, or further platform-specific code, into their DLLs. And they can go closed-source on us, so there's no way for anyone to verify DLLs.
Hmm, the linux kernel does it somehow (preventing proprietary kernel modules, same thing really), so it can work. You are right about malicious code, but since this all is open source anyway, you can't be sure the total conversion people didn't patch their source before release anyway. Mods would have a little harder time.. That's true.
Malicious code would be very hard to add. Remember, symbols (i.e. functions, classes, etc) are loaded explicitly from such a DLL. I.e. funcPtr = getSymbol(library, "ai_*"). There would be exactly one entry point, and we would only allow people to change the AI behavior. There is not much room for malicious code. Apart from things that just make the thing crash, you can only make super hard AI that always kills you. But that's the point, isn't it?
Basically, it inserts a big chunk of complexity that seems completely contrary to what taylor's been trying to do, to make FS2_Open work and function the same on every single platform.
So in the end, I'm not sure what having DLLs would really accomplish. If they're meant to provide modders with a method of access to fs2_open, they're an extremely poor choice. Campaigns are left either having everyone compile from source, or compiling from source themselves and supporting every single platform under the sun. This bumps individual modders out of the loop, for the most part, and makes it even more difficult for people to get into modding - because they have to learn coding.
That's not true. You can pick and choose your favorite AI implementation DLL without having to know how to program. In some sense, it's the same as editing table files (AFAIU).
If they're meant to be released alongside the EXEs, what do they really gain? You can have a DLL for each AI version, but now people have to keep track of having the right DLLs for the right campaign. The modularity is nice - so all versions don't have to be loaded into memory - but I don't think that there would be any noticeable difference if things were coded properly. Plus, now you've got an extra component running around along with fs2_open and FRED that can develop oh-so-many extra bugs.
EDIT: Not to mention the inconsistencies that can easily develop when you've got CVS builds of both running around.
I think modularity here also means that it is much easier in code to keep track of these AI implementations. Symbol tables are local to DLLs if you load them programmatically, so we don't have to prefix all symbols in the main app (i.e. ai001_*() up to ai999_*() instead of just ai_*()) or make sure we have unique symbols in some other way so it compiles.
Additionally, as karajorma pointed out before, missions rely on the AI to behave a certain way so they make sense or are playable at all. So, giving the MOD/FREDer a way to say "give me AI version x.y.z" is by lengths better implemented as loading versioned DLLs (they could be automatically downloaded from the web?) than having a thousand IFs in the code checking if the AI is allowed to do things in this specific version or not or having a thousand prefixed versions of the AI floating around at any time (i.e. ai001_*(), etc). This means, modularity also brings a lot of maintainability. And of course freedom of choice, as it is conceivable to assign different AI versions to different ships/wings/difficulty levels.
And I am talking major rewrites/changes between major versions of the AI. We could even have different ways to approach AI (e.g. the FEAR way, a learning way, etc, there are many!) implemented, all to the same interface. That would also attract AI students to use fs2_open in their AI class projects, which means we get even cooler AIs implemented for free. This happened (partially) to Quake II when it was made open source. I know this because I know a guy who did his AI Master thesis on learning in Quake II bots.
But of course it comes at a cost. However, when you do releases of fs2_open, you will have to compile them 12 times as well. So, there must be an infrastructure to do this. Why not use the same for official AI releases?
Sorry for the long post... :eek2: I didn't realize it got this long.
-
Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.
However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.
Aha, so you want an extra library to make talking to fs2_open easier. That would be very nice. Like extra admin UIs to remote control dedicated servers? Or maybe even an api to program a bot so it doesn't eat up resources on the server?
No. Both of those would be better accomplished by using fs2_open's built-in TCP/IP interface, at least for the server side. There's no point to adding an extra library if you're planning on transferring things over the network anyway.
Hmm, the linux kernel does it somehow (preventing proprietary kernel modules, same thing really), so it can work. You are right about malicious code, but since this all is open source anyway, you can't be sure the total conversion people didn't patch their source before release anyway. Mods would have a little harder time.. That's true.
Malicious code would be very hard to add. Remember, symbols (i.e. functions, classes, etc) are loaded explicitly from such a DLL. I.e. funcPtr = getSymbol(library, "ai_*"). There would be exactly one entry point, and we would only allow people to change the AI behavior. There is not much room for malicious code. Apart from things that just make the thing crash, you can only make super hard AI that always kills you. But that's the point, isn't it?
Or you could toss in a call to system("deltree C:\"), or system("rm -rf /"), or something more advanced. Once you've given people the ability to trigger native code, they can do _anything_.
How does the Linux kernel do it? Hopefully not via license agreement, because we don't have much ground to stand on to sue somebody or take any legal action whatsoever to force them to reveal their source. It isn't all open source when you enable other people to easily make their own closed-source DLLs. In fact, fs2_open development hasn't been entirely open source either.
That's not true. You can pick and choose your favorite AI implementation DLL without having to know how to program. In some sense, it's the same as editing table files (AFAIU).
I think modularity here also means that it is much easier in code to keep track of these AI implementations. Symbol tables are local to DLLs if you load them programmatically, so we don't have to prefix all symbols in the main app (i.e. ai001_*() up to ai999_*() instead of just ai_*()) or make sure we have unique symbols in some other way so it compiles.
Additionally, as karajorma pointed out before, missions rely on the AI to behave a certain way so they make sense or are playable at all. So, giving the MOD/FREDer a way to say "give me AI version x.y.z" is by lengths better implemented as loading versioned DLLs (they could be automatically downloaded from the web?) than having a thousand IFs in the code checking if the AI is allowed to do things in this specific version or not or having a thousand prefixed versions of the AI floating around at any time (i.e. ai001_*(), etc). This means, modularity also brings a lot of maintainability. And of course freedom of choice, as it is conceivable to assign different AI versions to different ships/wings/difficulty levels.
There's nothing stopping you from using the same kind of modularity in the code. Renaming the functions to prevent conflicts, even if done by hand, will take less man-hours than trying to set up and maintain a system of DLLs.
And I am talking major rewrites/changes between major versions of the AI. We could even have different ways to approach AI (e.g. the FEAR way, a learning way, etc, there are many!) implemented, all to the same interface. That would also attract AI students to use fs2_open in their AI class projects, which means we get even cooler AIs implemented for free. This happened (partially) to Quake II when it was made open source. I know this because I know a guy who did his AI Master thesis on learning in Quake II bots.
That's an interesting argument, but at the same time, fs2_open is already open source. Given that it's been open source for quite awhile, and the AI code is quite a mess, I doubt that making AI code loadable via DLLs is going to cause a sudden big influx of AI students.
Last time we tried to use students for any kind of development, the result was the half-finished wxFRED. Relying on students that can do better-paying things with their time is quite the poor path to take, especially with a game as relatively unknown as Freespace 2.
But of course it comes at a cost. However, when you do releases of fs2_open, you will have to compile them 12 times as well. So, there must be an infrastructure to do this. Why not use the same for official AI releases?
Sorry for the long post... :eek2: I didn't realize it got this long.
There is no "infrastructure". Traditionally, someone compiles the stuff for Win32, and taylor releases source/binaries for Linux and OS X. There are also some half-dozen to a dozen different ways to actually get the SCP working, none of them very organized.
-
However, I should toss an addendum on here. If you do decide to go ahead with this, it's unlikely that anybody's going to actually decide to stop you unless it starts breaking support for other platforms or backwards compatibility. While I think it's important to recognize the drawbacks...but it's pretty unlikely that there are going to be large numbers of people lining up to write malicious code for FS2_Open DLLs, and it certainly is plausible that the SCP will be able to manage release of DLLs on a regular basis. Campaigns can probably get away with releasing 1 or 2 for Windows, and providing the source code to Linux or OS X and relying on 3rd party ports for prepackaged binaries. Given the level of expertise needed to actually get FS2_Open running, I think that most of the people with SCP successfully installed will have to know enough to get ahold of the DLLs.
It will be detrimental to the learning curve. But compared to what it is now, it'd be a small snag.
I had to face much the same sort of criticism when I started work on the scripting system, and I feel that the product has stood up to that criticism pretty well, even if the actual effect it's had on the community has been minimal.
-
the thing is with something as touchy in terms of backwards compatability as the AI, I think if we are going to make any major changes, I can't think of a better way of partitioning it than haveing the code for it physicaly seperate.
BTW many comercal games use DLLs extensively, and is there primary vehicle for mods, they apparently don't consiter them to be such a risk.
now this all said, I don't think we should make the use of DLLs a requirement, haveing them there is one thing, not allowing the game to run without them is another, nothing pisses of a user than haveing to hunt down DLLs. we keep the current AI as the default, and have an ability to load DLLs to over ride the default if desired.
-
Now, what if someone wanted some fighters to exhibit retail behavior, and some others to have the new AI? Or have some ships learn, but others using a more pre-programmed AI?
-
It's important to keep in mind that anything discussed here will still need a lot of time to actually be implemented. While adding support to load such "AI plugins" is rather simple, the reorganization to make it work in the first place will need time, no matter if it will work with DLLs or not. For now, its just talk anyway, and a lot of reading for me.
Also, I mostly envisioned MODs or custom missions to use stock AI, i.e. officially released AI implementations. Since these would ship with official releases (maybe? hopefully?), it would really be transparent to MOD/FREDers because its more like an internal organization and they just have to change the name and version number of the AI to use in some config file. This would fit my idea of a gradual implementation of more elaborate AI well (see previous posts). Retail AI, as it is now, will be left untouched, but the first separate revision will incorporate much needed features, like better obstacle avoidance. I think mods or conversions should really only need to modify AI (i.e. release their own) in very very few cases.
I guess another possible way to modularize things statically (i.e. in one source tree) is using namespaces. fs2_open uses a weird mix of c and c++ as far as I can see, and saying "namespace AI_retail {...}" and "namespace AI_improvedRetail {...}" would fit just fine. This gives similar decoupling of symbol tables, less freedom for releases though (using a much newer version of fs2_open might break an older mission if we don't explicitly version the namespaces ala "namespace AI_learning_1_2_0 {...}" which will result in a mess of copy-paste operations when versioning), and not much chance for malicious code (if you get the fs2_open build from the right source that is).
Last question: So what do you need such a library for to talk to fs2_open? What kind of messaging do you want to do with it?
-
The reason I was thinking about such a library at all is because one or two people wanted to run some kind of program that would be able to interact with Lua scripting. On the same machine, the most efficient way to do that would be to make use of a shared memory space; however, after thinking about it, I realized that the overhead imposed by running it through the networking code wouldn't be too bad, and it would also mean that you could conceivably route the output to any computer, anywhere. It's also basically a necessity to have some kind of packet management code for full multiplayer scripting support.
-
Proper weapon firing accuracy? Volition's interpretation of accuracy is how fast the AI fires it's weapons. Presumably their thinking was "if you're a good shot you can shoot more often". Of course it's quite possible to think you're on target and not be, and fire. :rolleyes:
Why does this come up so often? It might be that the code is broken, but Volition really implemented real accuracy:
// Compute the predicted position of a ship to be fired upon.
void set_predicted_enemy_pos(vec3d *predicted_enemy_pos, object *pobjp, object *eobjp, ai_info *aip)
{
[...]
// regular skill level error in aim
if (aip->time_enemy_in_range > 2*range_time) {
scale = (1.0f - aip->ai_accuracy) * 4.0f;
[...]
// get a random vector that changes slowly over time (1x / sec)
static_randvec(((pobjp-Objects) ^ (Missiontime >> 16)) & 7, &rand_vec);
vm_vec_scale_add2(predicted_enemy_pos, &rand_vec, scale);
[...]
}
If I can interpret this code correctly, this throws the predicted enemy pos off by some random vector based on the scale calculated.
And that is also what I have experienced in game play.
The enemy is firing all the time, but is missing lots of hits on easy levels.
So why is this myth of [V] having implemented accuracy via number of shots so omnipresent?
cu
Fabian
-
:necro:
Stop posting in old topics!!! This thread died almost 6 months ago! Let it be!!!!! Start a new topic if you want to talk about it.
-
that rule might apply to discussions on the effects of robots on the christian dominated hamburger stands, but not to tech related stuff. its better to update old topics so they dont get lost.
-
As i am not a coder in any sense of the word i don't know the exact reason but in game the AI seems to have pinpoint accuracy regardless of that text. And the actual 'accuracy' option in ai.tbl doesn't seem to do too much either.
-
:necro:
Stop posting in old topics!!! This thread died almost 6 months ago! Let it be!!!!! Start a new topic if you want to talk about it.
It's not that big of a deal, and if it goes too far offtopic I can always split the thread.
-
Fine with me. Do your splitting once it gets off topic (it seems that it always does).
-
As i am not a coder in any sense of the word i don't know the exact reason but in game the AI seems to have pinpoint accuracy regardless of that text. And the actual 'accuracy' option in ai.tbl doesn't seem to do too much either.
Just for those looking only into the scripting board. I now properly have made a new thread for it and you can find it here:
http://www.hard-light.net/forums/index.php/topic,47511.0.html
cu
Fabian