Interested in developing a standard for "robot" combat?

Evening all,

Anyone interested in developing an open source standard for autonomous vehicle combat?

Something that will allow players to build autonomous vehicles/robots/whatever and seek out and destroy others.

If there's enough interest, I'll create a new thread with a Nomic style blank template and we can see what happens.

Yes, I am - I'd like to see an open standard for damage and weapons that could be read by objects generally.

In the absence of llDetectedDamage(), which would be useful, some third-party script is the only solution.

Hi Ordinal,

Apologies for not replying earlier, I was hoping to get a couple more replies first. We could do with another 3 or 4 people wlling to contribute before we start actually ageeing a standard (I like to use a voting method that needs at least that number)

In the mean time, we can thrash a few ideas around:

Your right, llDetectedDamage(x) would make things a lot simpler. Having a damage set object running a event or two before deleting itself when colliding would b handy as well.

I think that a sytem for automonous objects could end up being a subset of a general system. That is, the autonomous section will need more rules. As an example, we will probably need someway for a vehicle(Im trying to avoid typecasting by saying robot) to know that a detected object is a valid opponent. Not sure you would need that for a general system. But we might end up with something that can be adapted for a general system.

The "How many hit points does it have?" and "how much damage does it do?" questions can also have a different solution. I'd like to explore the idea of using the objects mass as a means of deciding how many hit points a vehicle has, and the mass of a munition determining how much damage it does. A very very simple system, but one that can be implemeted quickly as a starter for 10. One big advantage is that there woud be no need for a script in the 'bullet' as the script in the vehicle can use llDetectedMass(x).

The problem I've found with mass for damage is that there are many different bullet and gun designs around, some of which have high-mass bullets, some low, moving at different speeds etc.

I tried implementing a kinetic-energy based damage system, and I found that, for instance, the bullets from my Seburo barely affected it, as did a buckshot cartridge I made (which fires low-speed balls) whereas more massive bullets from a gun of my own had far greater effect, and I expect that full-buoyancy bullets, which usually have very high speed even if they don't move that fast in-game, would be pretty much an instant kill, though I've not checked. You'd need a standard for gun physics as well.

Most of the damage systems I've heard of seem to be sensor-based, though I do prefer the idea of objects being thrown around.

Ordinal,

I think your right that basing the damage on the kinetic energy is not the way to go, at least not at first.

If the damage inflicted by a munition was based simply on its mass, damage = mass/1000 for example . Then the choice of how heavy to make the munition would be up to the designer. The larger they make it, the more damage it will do. But as the mass is increased so do the associated problems, the delay in rezzing the object, the energy lose increase etc.

I can see several big advantages in doing it this way;

1: Per script, the firing rate for a munition that does 1 point of damage will automatically be faster than one that does 100 points. No need for any code to restrict the rate of fire according to what it is supposed to be firing.

2: The more damage a munition does, the harder it will be to manouver. If it is very large, it may run out off energy before reaching its target.

3: If an automated vehicle detects a munition, it can tell how much damage its going to do before it gets hit. This could allow it to concentrate its countermeasures on the biggest threat.

4: No need for the munition to 'shout out' its details. No need for any code in the bullet at all. Now, this could be the way to go eventually, but since, hopefully, some sort of object to object communication is coming along, it may be worth waiting before implementing this type of system.

5: It would be easy to implement. I'm a great believer in putting something simple in place first and then deciding how to improve it.

We would need to experiment to find the best way of converting the mass into damage inflicted. It will be no use if a 0.1 mass object does one point, but to do two points damage you need something weighing in at 100 mass units.

What do you think of the related idea of basing the HP of the vehicle on its mass?

My suggestion is to wait for the object - object sommunications we were supposed to have gotten by now. Me and my business partner in SL were brainstorming a Mech Warrior type game and when LL told us a new driect object to object communications system had been made and was on its way in 1.7 I decided to wait for that or else I would need a total remake once it came out.

It would be extremely more efficient for these applications. Only thing to do is wait and hope they dont' shelf it until 2.0.

Morning Rayve,

I agree that object to obect comms would be very useful and open up a whole range of ideas, but I not sure I see it as a showstopper. There are an awful lot of things that would have to be discussed and agreed before we knew whether or not O2O comms was actually needed (Yes, I agree that eventually it will be required).

My view is that a standard should fit in with what is avalable now. When new functions appear, the standard is enhanced/further developed to take advantage of them. Alternatively you could have a fork in the development that detailing functions that cannot be implemented until the technology changes (In practice not a lot of use, but dead handy when they do actually release thngs like O2O comms.)

Is there nothing I can do to get you involved now? As a minimum, all you would have to do is vote yes or no to things being added, or changed, to a standard.

Tip

I'm must admit I'm a bit surprised about the low level of interest. I've had relevant comments from the few (Thanks chaps) who have posted here and in the Law Society forum, but I expected a few more.

What's the problem peeps? You can tell me, I'm a big boy, I just don't photograph well.

Is it a case of Noob who hasnt a clue how complex the task is?
Is it not the 'done thing' in SL?
or is the view that within Second Life the tools and functions are not there yet? (1 vote for this already)

Do ppl think that organising something like this in SL is akin to herding starving cats while simultaneously avoiding a flock of Avian flu carrying budgies? (Not that I disagree)

Do our furry brethren have such a hold on SL that any open standard always ends up as system for working out who yiffs who?

Is it the subject? Are Robots a no no since those pictures of Torley and the sex droid got out?

Is it the combat bit? Are activities limited to watermelon decorating as punishment for the soon to be released machinema "Torley Tours Texas"?

Is it the autonomous bit? No one interested in developing some quake style combat bots?

Hey! I really like the idea! But you have my vote for SL not having the ability to fully implement it yet. I've tried driving around uninhabited totally empty sims and its quite laggy at most times. There's also people who're interested in Naval Battles as well.

Oh yea, I like the Mechwarrior idea too!!

I'm interested in helping out... I'm new to scripting, but I can probably get up to speed pretty quickly.

Vince have you seen the Combots by Eckhart Dillon? These use AI and are very good for fighting as they can be killed, also upon killing them, they rez a new bot which allows you to keep at it as long as you want and they can fire at multiple targets, you can can rez as many combots as you want and they shoot at anything that shoots at them including, planes, ppl on foot or some variant of the two.

You should really check them out if you are looking for some good ideas. I think you can find them at Galactic Mall in Shinda.

Hope this helps...Cheers!

-Calix

Calix,

It seems like Eckhart already has a lot of the building blocks figured out for a bot "SDK". The only problem is that LSL doesn't really allow you to sell black box libraries. It would be great if he could sell a toolkit of LSL code that others could use to base their own AI bots on. Unfortunately, as far as I can tell, there is no way he could do that without giving away his code. I think the only way an open bot arena could happen is if someone, or a community of scripters were willing to provide a free bot AI script library that was open source.

I'll leave it to the folks that started this thread to take the initiative on this. I'd be happy to contribute as much as I can.

-Vince

Talked to Devedee Maelstrom? I think I've spelt the name wrong.. but anyway, he likes building open source kits and toys. He has a fun robot-wars kit ready to go, might be able to work something up.

Sorry I havnt replied earlier, the early responses here and the lack of responses to my in game messages made me put this idea on the back burner.

Although the concept of an open source AI is interesting, that wasnt the thought behind my original post. I was thinking along the lines of an agreed combat standard that would allow people to develop their own AI and pitch them against other people's AI creations.

I disagree that SL doesnt allow you to sell black box libraries. Using link messages it is possible to create a movement script(for instance) that takes its commands (move to <x,x,x> from another script, attempts to move the obect to that location and reports back when it has reached the destination (Or failed). With the current SL permissions, I can sell that script as a black box, the buyer cannot see how it works or modify it in anyway. Compartmentalisation of functionality in this way is one of the big advantages of FSMs.

However, you can have as many propriatry and open source AI systems as you want. But unless there is a standard for how the combat works, you could'nt put them up against each other in a 'fair' fight.

Tip,

Thanks for the clarification. Now I think I understand. You're talking about defining a protocol that could be added to this list: http://secondlife.com/badgeo/wakka.php?wakka=exchange

It would define messages that valid bot scripts would have to handle, such as "set start position", "start fight", "stop fight", "penalty", etc... Is that more along the lines of what you were thinking?

Vince,

Correct. Part of the standard would have to be a message protocol.

But it would also have to include agreement over some fairly fundemental concepts about what is meant by 'combat'.

As a for instance, I'll guess that the majority of people assume that some sort of HP (Hit Point) system would be used to determine the amount of 'damage' a bot could sustain before it was 'destroyed'. But HPs are not the only method of simulating damage. And if HP were the agreed standard, what about critical hits? armour? How do you determine how many HP a robot starts with or how much damage a 'hit' does? Does chance vary how much damage is inflicted etc?

All these concepts would have to be agreed before you even started worrying about whether data was transfered via shouting on a channel or by some future O2O (Object to Object) communications functionality.

It could probably be done in stages right? Weapons and hit points could come at a later stage. I think it would still be an interesting contest if all robots could do is move (with physics on) and push things around (like ping pong balls). A simple contest might be "push as many ping pong balls into your box as possible in the given time frame." With limits on robot dimensions and maybe even number of prims, you could probably make it a fair contest pretty easily since it would be hard to cheat.

one problem with this, is that this model of damage / mass etc implys a perfect ratio. Real life battle are exciting because of their paper-rock-sissors nature. One design of bot can beat anouther because its assets worked better against the other's weaknessed.

you need to build this ability into the code, not only by the weight of the robot, but also in some way so that multiple approaches can win in various situations.

Vince,

Agreed,



Hmm, that is a very interesting direction you've taken there. I think I'm going to go away and play with that idea for a bit. 0.25 meter balls? 5 square meter goal area? No interfering with the other bot?



Sirex,

Yeh, you are right. I'll admit that using the mass as the means of calculating the Hit Points and damage probably isnt the way to go. But it does imply weakness's, my current 'bot' is a 30 meter long semi-scale warship. Using the mass to calcualte its hit points would give it a huge number, but compared with a human sized bot, it is very difficult to manovour. A single human sized robot probably couldnt destroy it, but it would have trouble against ten of them. Same with the weapons. create a projectile big enough to do a lot of damage and its going to be hard to get it moving and changing direction.

There are only two advantages to this method that I can see:

1: It stops someone designing any old robot and annoucing that it has 2 million hit points and each one of its weapons does a thousands points damage. So its your choice as a builder, lots of hit points but the turning circle of a whale, or small and nimble.

2: It allows a robot to to determine the 'size' of its oppenent without needing any data transmitted from the other bot. Same with the weapons, a robot would be able to decide which projectile will do the most damage and evade that one ignoring small projectiles that would do litle damge individually.

What would be your prefered method of determining how many hit points a robot started with? Giving them all 100, for instance, is simple, but would suffer similar disadvantages
to what you described.

Tip

possibly a system such as this:

each robot has 100 hit points of damage that they can sustain.

each robot can give out X amount of damage per blow, and a rate of Y.

each robot can protect itsself to a degree of Z.

then, combined with mass / agility considerations, each builder can preference their robot into one category of skill such as defence *at the expense of other areas*.

a bit like in games where you get given experience points that you can spend on various aspects of your player, but once their used up, their gone.

I like the hit points are directly proportional to the mass of the robot (or vehical) and damage done is directly proportional to the mass of the bullet standard.

Another damage method is detecting an impact (a sudden amount of momentum change) on the vehical so both bullets and crashes could cause damage

Another damage method is all bullets do the same amount of damage, but you can only take damage at a certain rate, like 5 points of damage per half second, and it doesnt matter whether you are hit by 100 bullets or 1 bullet in that half second. You still only take 5 points if you are hit in that time increment.

Of course standards only mean anything if people use them.
Maybe make a freebie open source "damagable" script that can be simply dropped into a vehical by any newbie for people who want vehical battles / car wars.
It would need to be completely open source so robot and vehical manafacturers are allowed to steal what they want from it and put that into their scripts, so making it more of a used standard.

Yep, cant disagree with that.

There's been some good thoughts here.

Perhaps we could use the HP = mass * x method while we get other things in place? Then if we have actually got to the stage of shooting at each other we can revisit it.

Does anyone have another method of determining the amount of damage sustained that they would like concidered?

For me, HP's advantages of practicality and familiarity(everyone knows what it means) outway the disadvantage of it not being very realistic.


I'd like to park the Hit Points disucsion for bit and think about some of the other 'challenges'.


How is my robot going to recognise your robot as a legitimate opponent?

Tip you might want to take these questions to the scripting forum section or even wiki or even groups in-game that do in fact help ppl. with such ideas.

Just a thought.

Lot of good people out there who can help...even on other sites/forums.

Good luck.

- Calix

Calix,

I deliberately didnt put this in the scripting forum. The objective is to discuss an open standard for a game, (which probably will include some scripting). I did just checked the 'about this confernece post' and it does say its for game related scripting tips.

I know how I would implement a system to enable one robot to recognise another, but first I'd like to hear other peoples suggestions. If we can come to an agreement over the method, then I agree the scripting forum would be more appropriate to discuss problems with the practical implementation.

Tip