Droids?
Author
I've been thinking about the amount of thinking a typical droid would require, and it seems not to be that much. (other then some simple logic, and the ability to obey basic commands through maybe a script). Note, this probably won't hold for protocol droids, but for something with a definite purpose which doesn't require too much smarts...
"Turret 12 direct fire to the engines of the closest ship"
----------- ----------- ---------------- ----------------
Who Type of order Parameter Object
Also, would droids in games be a good thing?
For example, you could control a laser turret via order.
"Shoot the guy to the right"
"ok, try the one on the left"
"Shoot the guy with the flag!"
The orders are very simple, but they could be useful.
"Lay down covering fire on the stairs"
"Shoot anything that comes down the stairs"
All these orders require only a little bit of processing. (for eg. the droid turret would be a fsm, where it stored its "Current target" as a variable which is changed via the command interface).
Or perhaps something similar to boba fets interface with slave I (if you've read the books).
Basically a standardized version of English, which lets you get your point across easily.
"Switch to optical alerts and disable audio alarms" is an example.
Do you think that controllable droids would be a useful addition to games? (like being able to command bots, or having things like turrets which you can control)
Any ideas on how to develop one?
Any other droid related comments?
Hares the place to post.
From,
Nice coder
I like the idea.
Only problem I can see with this, is if the player feels that HE could have done a much faster & better job than be droids.
So the work can be to get the player to send his commands to the droids in a
smart, fast and easy way.
Just my 2 norwegian kroner.. :P
Only problem I can see with this, is if the player feels that HE could have done a much faster & better job than be droids.
So the work can be to get the player to send his commands to the droids in a
smart, fast and easy way.
Just my 2 norwegian kroner.. :P
In my education I had two subjects, Realtime Control Technics (RCT) and Fuzzy logic (FL). Those two subject where to contrary of each other. All my fellow students thought fuzzy logic 'rules' and the other one sucked, because it was so hard.
With these two subject/methods you learned to solve problems with mechanica/hardware.
In the droid problem of you, you can do the following with the methods I mentioned:
Command: "Droid, attack right flank of this unit!"
Methode FL: Aim gun on right flank; Pull trigger/open gun fire.
Methode RCT: Target unit; Store ID in memory; Draw outline the unit; Store output in visualcortex/object-space buffer; Determine distance; Store data in memory; Determine aiming position by using X and Y offset; Store data in memory; Aim gun using X-Y offset; Enable gun fire; Wait for UNKNOWN order to stop;
As you see Methode RCT seems way more difficult as FL, in reality it is the opposite. RCT uses very easy to understand sub-commands, which are 'easy' to make, FL is a crude way to do the same. Saying "attack right flank" means what in digits? Indeed, you still need to convert that into digits. To lets a droid work on FL is hard. RCT is simple cause you determine all simple expects.
Besides this is RCT 1000 times faster in most case then FL, cause FL routines usualy do alot more in background then they need to do for the job.
RCT uses formulas to get an accurate output, FL you first need to set 1.3 as LOW, 4.6 as HIGH. It is not for nothing that a Boeing 747 or Airbus 380 uses RCT for autopilot.
My point is this short story: First determine how you gonna do the simple commands, like fire, position gun or target unit, before you start with the command line order input.
Just my €0.02 ... wait we don't have cents anymore here, make it €0.05 cents then.
With these two subject/methods you learned to solve problems with mechanica/hardware.
In the droid problem of you, you can do the following with the methods I mentioned:
Command: "Droid, attack right flank of this unit!"
Methode FL: Aim gun on right flank; Pull trigger/open gun fire.
Methode RCT: Target unit; Store ID in memory; Draw outline the unit; Store output in visualcortex/object-space buffer; Determine distance; Store data in memory; Determine aiming position by using X and Y offset; Store data in memory; Aim gun using X-Y offset; Enable gun fire; Wait for UNKNOWN order to stop;
As you see Methode RCT seems way more difficult as FL, in reality it is the opposite. RCT uses very easy to understand sub-commands, which are 'easy' to make, FL is a crude way to do the same. Saying "attack right flank" means what in digits? Indeed, you still need to convert that into digits. To lets a droid work on FL is hard. RCT is simple cause you determine all simple expects.
Besides this is RCT 1000 times faster in most case then FL, cause FL routines usualy do alot more in background then they need to do for the job.
RCT uses formulas to get an accurate output, FL you first need to set 1.3 as LOW, 4.6 as HIGH. It is not for nothing that a Boeing 747 or Airbus 380 uses RCT for autopilot.
My point is this short story: First determine how you gonna do the simple commands, like fire, position gun or target unit, before you start with the command line order input.
Just my €0.02 ... wait we don't have cents anymore here, make it €0.05 cents then.
I think the standardized english thing is a big obstacle. It's not impossible though as you can exploit the context of the game to avoid having to solve all of natural language processing. These guys did something similar with speech in Neverwinter Nights http://www.media.mit.edu/cogmac/publications/AIIDE05GorniakSituatedSpeech.pdf
Author
CoMaNdore - Good point, but you would also get to run around, shoot, ect. Just you can order droids around to shoot others. (PVP with destroyers..... :))
Xeile - Suborders (with scripts) would be the best method.
For your egsample "Shoot the flank of this unit"
Execute order "shoot".
Set target to the last unit either marked or mentioned.
Find subtarget of flank in target
Set aim as subtarget
Set Find_other_targets to false
Switch state to attack
When the target is dead set find_other_targets to true
So basically the bot is a self-contained bot, but each of its behaviours (like its find_other_targets behaviour, which determines what it should shoot at) are controled by the users orders.
Also, the variables involved can be changed via orders. (so if you order it to shoot a unit, its doing the same thing as if it decided to attack itself, and its following the same sequence of targetting, then switching to attack.)
Also.
"attack right flank" means:
Find current target
Find subtarget of "right flank" in target
Aim at subtarget
Set Find_other_targets to false
Switch state to attack
When the target is dead set find_other_targets to true
They are all behaviours, which a modified bot could use pretty well (and easily), i'd say.
Edit: New post while i spent a long time thinking and writing.
supportvector - I'll read that.
Basically what i mean by standerdised english would just be something for use only for talking to bots, so if you use it long enough, it should become second nature. Because a simple order language would make it much easier to make bots, it should be used a lot, and therfore more people would be able to use it properly.
From,
Nice coder
Xeile - Suborders (with scripts) would be the best method.
For your egsample "Shoot the flank of this unit"
Execute order "shoot".
Set target to the last unit either marked or mentioned.
Find subtarget of flank in target
Set aim as subtarget
Set Find_other_targets to false
Switch state to attack
When the target is dead set find_other_targets to true
So basically the bot is a self-contained bot, but each of its behaviours (like its find_other_targets behaviour, which determines what it should shoot at) are controled by the users orders.
Also, the variables involved can be changed via orders. (so if you order it to shoot a unit, its doing the same thing as if it decided to attack itself, and its following the same sequence of targetting, then switching to attack.)
Also.
"attack right flank" means:
Find current target
Find subtarget of "right flank" in target
Aim at subtarget
Set Find_other_targets to false
Switch state to attack
When the target is dead set find_other_targets to true
They are all behaviours, which a modified bot could use pretty well (and easily), i'd say.
Edit: New post while i spent a long time thinking and writing.
supportvector - I'll read that.
Basically what i mean by standerdised english would just be something for use only for talking to bots, so if you use it long enough, it should become second nature. Because a simple order language would make it much easier to make bots, it should be used a lot, and therfore more people would be able to use it properly.
From,
Nice coder
Author
Perhaps shortcut-orders would be useful too?
Saying "Point" or "Points" is a whole lot easier then saying "Destroyer 1 come 1m away at an angle of 135 degrees, Destroyer 2 come 50cm away at an angle of 90 degrees, ...... And follow. All destroyers Shoot on site but do not evade attacks. All destroyers syncronise targets, destroyer1 leads."
Which could come in handy. (going in with your droids right behind you, and right infront of you, makes it easy to wipe your way through a whole lot of enimies. (you've got a whole lot of destroyers who are all shooting at you.... then 1/10th of a second after you've been blasted by a few blaster bolts/micro-rpg launches, it aims at the next guy, and so on).
For an mmorpg it would be a nifty design element.
You could buy and sell droids (simple droids for farming, to destroyer droids and battle droids.) for various sums of money.
Having a full scale battle of a few tens of thousands of droids would be beautiful.
Also seeing one army circle a smaller army (with its player controlling it) under orders, then pick off all the remaining droids, before closing in and exterminating the player after the final order is given...
Seeing a droid army of thousands (about a 100 across, 200 deep) just go and charge. Dodging and weaving, straight into another droid army (which is 100 across, and 1000 deep) ....
All the while as it is decimated, a second army (which was given orders beforehand) starts running and firing at the larger army.
As a third army, stationed above the battleground the night before starts opening fire with heavy blashter-machineguns.
:-) That would be really impressive.
From,
Nice coder
Saying "Point" or "Points" is a whole lot easier then saying "Destroyer 1 come 1m away at an angle of 135 degrees, Destroyer 2 come 50cm away at an angle of 90 degrees, ...... And follow. All destroyers Shoot on site but do not evade attacks. All destroyers syncronise targets, destroyer1 leads."
Which could come in handy. (going in with your droids right behind you, and right infront of you, makes it easy to wipe your way through a whole lot of enimies. (you've got a whole lot of destroyers who are all shooting at you.... then 1/10th of a second after you've been blasted by a few blaster bolts/micro-rpg launches, it aims at the next guy, and so on).
For an mmorpg it would be a nifty design element.
You could buy and sell droids (simple droids for farming, to destroyer droids and battle droids.) for various sums of money.
Having a full scale battle of a few tens of thousands of droids would be beautiful.
Also seeing one army circle a smaller army (with its player controlling it) under orders, then pick off all the remaining droids, before closing in and exterminating the player after the final order is given...
Seeing a droid army of thousands (about a 100 across, 200 deep) just go and charge. Dodging and weaving, straight into another droid army (which is 100 across, and 1000 deep) ....
All the while as it is decimated, a second army (which was given orders beforehand) starts running and firing at the larger army.
As a third army, stationed above the battleground the night before starts opening fire with heavy blashter-machineguns.
:-) That would be really impressive.
From,
Nice coder
I like th idea of tens of thousands of droids in battle formation, but I'd hate to be the person who has to actually implement that to run on the average computer system. Just the amount of optimization needed to show things of that scale is just mind bogling. Not to mention you then have to implement AI or have some sort of FSM that every single one follows is just mind boggling when it comes to processing time.
It is true that we all wish that we can recreate the battle scenes like from the movie Lord of the Rings in real time, but in reality, we'd be lucky if we can pull off a few hundred droids in one scene with decent frame rates......
However...with the new Physx Processing Unit that's about to hit the market, it may be doable and you might be able to break the 1000+ unit on screen simultaneously barrier.
It is true that we all wish that we can recreate the battle scenes like from the movie Lord of the Rings in real time, but in reality, we'd be lucky if we can pull off a few hundred droids in one scene with decent frame rates......
However...with the new Physx Processing Unit that's about to hit the market, it may be doable and you might be able to break the 1000+ unit on screen simultaneously barrier.
Author
Quote:Original post by WeirdoFu
I like th idea of tens of thousands of droids in battle formation, but I'd hate to be the person who has to actually implement that to run on the average computer system. Just the amount of optimization needed to show things of that scale is just mind bogling. Not to mention you then have to implement AI or have some sort of FSM that every single one follows is just mind boggling when it comes to processing time.
It is true that we all wish that we can recreate the battle scenes like from the movie Lord of the Rings in real time, but in reality, we'd be lucky if we can pull off a few hundred droids in one scene with decent frame rates......
However...with the new Physx Processing Unit that's about to hit the market, it may be doable and you might be able to break the 1000+ unit on screen simultaneously barrier.
Yes, well.... How do rts games work, with all there thousands of units?
:-) we can always dream.
A nifty thing that would be nice, is (in counterstrike et all) having droids (like destroyers, cargo droids that ship arms, charger droids, so you can recharge your railgun, ect.) lying around, which respawn after you've blown them to bits.
For a fps game (where you'd probably have 2-10 players) about 32-64 droids would be more then enough. (6 1/2-32 droids/player).
The major problem with speed would be the if, while, until, ect type orders.
Like "Blow the grenade when a unit leaves that door".
You then need to keep checking that door, and wait for a unit to leave it, before forfilling that order.
Perhaps having a simpler sub-parts of an order to check beforehand, so you don't spend as much time checking, per-bot.
Also, i think a marking system is required.
So you can say, "Destroy THIS door" and you can point out which door, "This door" referrs to. Probably a centerclick when your cross-hairs are over the door.
And an order-cancelling order would be a must. "No. Disregard previous order".
A small-scale chatbot would be a very nifty feature too.
From,
Nice coder
Well you may have 10,000 droids but you can simplify the amount of decision making each one of them has to do. At the top of the hierarchy you have the player, then several 'generals' that make sub decisions, then captains, sergeants and so on. So the hierarchy might be
1 Player
Makes top level decisions
10 Generals
Makes lower level decisions (with regard to local terrain, enemies etc)
100 Captains
Makes lower level decisions (with regard to local structures, enemy formations, troop morale)
1000 Sergeants
Makes lowest level decisions (with regard to which enemy to shoot at, whether to shoot/run/hide etc)
10000 Troops
Does whatever the sergeant is doing.
Now you have 10 agents using complex algorithms based on terrain analysis, formation analysis etc, 100 agents doing sub analysis (requiring less processnig power), 1000 agents doing decision making (if this else that) and 10000 agents in a set of states (fsm) common to a large group.
Now rules of management say the maximum one person can manage is six people but fortunately these aren't computers so the numbers can be tweaked. I've used ten in the example above but you could scale this based on processing power. Ultimately you'd get different gameplay and there'd be limits on how far you can push it (because 1 sergeant wouldn't be able to give effective order to 100 troops who could be quite spread out) but the option is there.
You've simplified it from 10,000 agents doing complex calculations to a few doing complex, a few doing less complex and a few just doing whatever they're told.
1 Player
Makes top level decisions
10 Generals
Makes lower level decisions (with regard to local terrain, enemies etc)
100 Captains
Makes lower level decisions (with regard to local structures, enemy formations, troop morale)
1000 Sergeants
Makes lowest level decisions (with regard to which enemy to shoot at, whether to shoot/run/hide etc)
10000 Troops
Does whatever the sergeant is doing.
Now you have 10 agents using complex algorithms based on terrain analysis, formation analysis etc, 100 agents doing sub analysis (requiring less processnig power), 1000 agents doing decision making (if this else that) and 10000 agents in a set of states (fsm) common to a large group.
Now rules of management say the maximum one person can manage is six people but fortunately these aren't computers so the numbers can be tweaked. I've used ten in the example above but you could scale this based on processing power. Ultimately you'd get different gameplay and there'd be limits on how far you can push it (because 1 sergeant wouldn't be able to give effective order to 100 troops who could be quite spread out) but the option is there.
You've simplified it from 10,000 agents doing complex calculations to a few doing complex, a few doing less complex and a few just doing whatever they're told.
In reply to "Nice Coder"
You're example of:
The major problem with speed would be the if, while, until, ect type orders.
Like "Blow the grenade when a unit leaves that door".
Is an archetectual problem. You can either have an agent constantly checking a door to see if someone is coming through it or you can have that agent tell the door to alert them when someone comes through. Now, depending on the design, it should be possible for the door to send a message to whoever is watching it when someone uses the door.
e.g. for a messaging system
SendMessage(Object,Action,Response)
SendMessage(BigGreenDoor,Open,Alert)
Which is send a message to the BigGreenDoor to trigger my alert state when the door opens. Now the agent can sit doing nothing until it's alert state is set. When this happens that means the door has been opened (by it's DoorOpen function) and it has alerted the player.
I believe this is called Messaging vs Polling.
You're example of:
The major problem with speed would be the if, while, until, ect type orders.
Like "Blow the grenade when a unit leaves that door".
Is an archetectual problem. You can either have an agent constantly checking a door to see if someone is coming through it or you can have that agent tell the door to alert them when someone comes through. Now, depending on the design, it should be possible for the door to send a message to whoever is watching it when someone uses the door.
e.g. for a messaging system
SendMessage(Object,Action,Response)
SendMessage(BigGreenDoor,Open,Alert)
Which is send a message to the BigGreenDoor to trigger my alert state when the door opens. Now the agent can sit doing nothing until it's alert state is set. When this happens that means the door has been opened (by it's DoorOpen function) and it has alerted the player.
I believe this is called Messaging vs Polling.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement