CODE WARS in Operation Flashpoint

[5133p39 16]

CODE WARS in Operation Flashpoint.

Interesting idea, yes?

I am surprised nobody has came up with something like that a long time ago.

What is it:

It should be something like this,

but instead of Java, you will use OFP scripting.

There should be more categories like "One vs. One" (single soldier's contest),

or "Group vs. Group" (two groups engaging each other), or some mixed category

which would include armor, or air units, etc.

Basic process

When declaring a contest, there will be released a mission template which will

contain all units and objects (if any) placed and named in the mission editor.

The contestants should use this template when testing their scripts, but without

the access to the scripts of any opponents, and they shouldn't alter the template

in any way (mainly for their own good, because the scripts will fight while using

the original template).

In the day of the contest, all contestants will send their scripts to the jury,

which can consist of more than one people - preferably someone trustworthy (any

forum moderator should be good enough :-) ).

The judges will test all the scripts against each another multiple times to

be sure which script is really better (should be defined by the category rules,

for example: 10 tries per each combination of scripts, and the script which will

beat the other one 6x times at least, will be winner. In case of equality, more

or less, other measures can take place if defined in the category rules).

The simplest basic rules should be like this:

1. No 'reveal' command!

2. No 'setPos' command with the connection to any objects nor units defined in the template.

3. No other units than those defined by the mission template.

4. No addons apart the defaults, BIS Resistance, and maybe some defined by the category.

5. No deleting of template or runtime created objects (and units) belonging to the opponent.

6. The contestant's code can consist of multiple SQS scripts or SQF functions.

7. The code must be human readable - no lines over XXX characters, etc.

8. The code must not contain any bugs.

9. Each variable and script filename must be prefixed with contestant's assigned letter and underscore.

...i can't thought of any other right now.

Different goals and different templates could be prepared.

The goals doesn't need to be equal - what i mean is that you could be given a

template where one contestant will be ordered to defend his town/base/anything,

while another contestnat must defeat him in limited ammount of time,

and you can enter the contest as any side you want. Then there will be two winners,

each on the appropriate side, the winner on the defending side will be the one who

was able to resist the longest amount of time, and the winner on the assaulting side

will be the one who managed to defeat his opponent faster (average results should be counted).

The possibilities are almost endless, and the OFP community could make use of these scripts or the ideas.

What do you think?

Would you participate?

Would you accept the tremendous challenge? :-)

[5133p39 16]

hmmm, have i added too few eye candy images, or is it really so stupid idea, so nobody is interested?

Where are you, scripters?

Now when it's time to show what you've got, you suddenly aren't here?

[Artak 0]

I think it's a nice idea. Not considering myself a real scripting genious, I could throw in a couple of hours of work and enter the competition.

[5133p39 16]

I think it's a nice idea. Not considering myself a real scripting genious, I could throw in a couple of hours of work and enter the competition.

well done! it looks like we have a first challenger! :-)

That's good. Anyone else?

I'll start with defining the rules, and creating some easy template for the start.

Meanwhile, everybody please present your opinions and any rules/template suggestions.

See you in the arena ;-)

[vektorboson 8]

I like the idea of some sort of "RoboCup" with OFP-AI units

Regarding rules, I would completely disallow using commands like setdammage, createVehicle/camCreate, addWeapon/addMagazine/*Cargo

You have to create a very solid ruleset, as it is pretty easy to very experienced scripters overcome limitations or hide functionality...

It even is not enough to look for forbidden commands, as you can obfuscate your code (OFP treats strings as code and code as strings).

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_snafu = ["t","e","v","c","l","a","r","h","i"]

_foo = (_snafu select 3) + (_snafu select 6) + ...

Thus you can create the string "createvehicle" just trough selecting and adding the elements from _snafu.

Don't forget creative usage of the OFP-Preprocessor, where mostly only the modder-freaks know about all its commands and usage possibilities...

So one rule should be like: Enemy units may only be killed by bullets/grenades that are fired from the rifles/launchers from AI driven units.

Another thing you have to take into account is CPU-time; scripts can be quite expensive and you have to put some limitations, especially for functions, as they are blocking (take a while-loop for example).

Anyway good luck; and if I find time, I'm going to participate  

[hardrock 1]

Hey that sounds pretty nice. If you elaborate this project and I find enough time to contribute some scripts, I would love to participate!

Somehow I feel though that I know which faces will appear in this topic . . .

PS: setSkill and the like should be prohibited as well.

[5133p39 16]

Ha! We got another foolish soul! That's very good.

SetSkill, yes, this also should probably be prohibited. I will go through all the commands OFP offers, and try to decide which will be put off limits.

Also i have a small problem with the first template - i don't know what should be the goal!

Everything seems to be too easy and dull.

Somebody better slip me some idea before i come up with something really stupid ;-)

[hardrock 1]

What about addEventHandler on enemy units? Is that allowed?

Additionally, things will be a bit hard without triggers. You can't for example detect when your units have spotted an enemy unit without a trigger or an array keeping the enemy units, which you could check periodically using knowsAbout.

[vektorboson 8]

What about addEventHandler on enemy units? Is that allowed?

Additionally, things will be a bit hard without triggers. You can't for example detect when your units have spotted an enemy unit without a trigger or an array keeping the enemy units, which you could check periodically using knowsAbout.

My opinion is, that one should not use commands on enemy units that have an impact on their state/behaviour.

So basically forbid any 'set'- and 'add'-commands on enemy units (including addScore    )

Regarding triggers: I'm against triggers, I think the units should act as autonomously as possible. You could overcome this limitation by using Hit- or Killed-EHs on your own units, and retrieve the enemy group units (but not using reveal on them!.

[Artak 0]

If you rule out everything, there's nothing but two groups of mindless loons running at each other with 50/50 possibility of winning. (no offence to BIS AI)

[vektorboson 8]

If you rule out everything, there's nothing but two groups of mindless loons running at each other with 50/50 possibility of winning.    (no offence to BIS AI)

Errr...

It's all about disallowing stuff like

"_x addScore -100000" foreach units _enemy

Or short: eliminate every way of "cheating". What I imagine from such a thing is, that we have units that advance in an intelligent manner on the enemy's position, using suppressive fire, firing grenades on suspicious positions a.s.o.

But you can't hold such a "contest" without a strict and exact ruleset.

[hardrock 1]

Well, one of the main problems that I see though is that you cannot query whether your units got note of any enemy unit, either visual or by hearing them fire. So they get pretty dumb. And waiting for an enemy unit to hit them is silly also IMO.

This should be sorted out, because spotting the enemy is one of the key points on scripting the AI behaviour.

[5133p39 16]

Well, one of the main problems that I see though is that you cannot query whether your units got note of any enemy unit, either visual or by hearing them fire. So they get pretty dumb. And waiting for an enemy unit to hit them is silly also IMO.

This should be sorted out, because spotting the enemy is one of the key points on scripting the AI behaviour.

what about the knowsAbout command? you can check whether your unit knows about the other.

I didn't meant that you will be forced to script the complete AI, nonono, that is impossible. You will use OFP's AI as is, and you fullfill your objective with the help of additional scripting.

Your script will tell the unit what to do and when, and except of that the AI will act on his own.

I must admit, that right now i can't think up any example, so it seems this wasn't so good idea :-)

But give me some time, i had too much work lately, i hadn't the time to think about this too much.

[5133p39 16]

Hmm, maybe i have something.

I got the whole idea of "code wars" when i was playing a little, making some sorft of "sector control" mission. The mission turned out to be no Multiplayer, even a Singleplayer, but only AI vs. AI with three fighting sides :-)

It wasn't very ingenious, the AI is just attacking nearest sector not belonging to their side. With each sector controlled, the appropriate side gets spawned another group(s) of units.

All units are spawning back when killed, but only if the side is controlling enough sectors to accomodate them.

But it turned out to be funny watching the AI to fight.

Actually i caught myself glued to the monitor, watching the fight very anxiously

Yes mamma, i should go out sometimes ;-)

So now i got an idea about reworking this into a basic template, for which each of the contestants will have to write a scripts to control the AI and help them to capture and guard the sectors as much effectively as possible.

I think this could work.

[-)rStrangelove 0]

I don't think there's much you can do without getting a reference of an enemy object somehow. And all commands for getting such a reference will be forbidden most likely.

If your script doesn't know an enemy object or where to send its groups the only thing you can do is constantly `watch' your groups.

If they stop moving and their magazines are starting to pour out bullets you could assume they're returning fire. And then what ? Getting the average direction of all units could give a hint in what direction the enemy is, but you still dunno exactly how far.

That would be the point where i`d spawn some sandbags (forbidden) or call an artillery script. Or call the other group to rush to a flank, but you can never be sure if they don't run into a yet unknown enemy group as well.

In the end i think it all comes down to 'running around in the darkness until something happens'.

I find the idea interesting though.

[deanosbeano 0]

he he, nice one, i have played a few games of this sometime ago, using vektorbersons debug console, its a good laff.

[5133p39 16]

)rStrangelove @ June 27 2006,23:29)]I don't think there's much you can do without getting a reference of an enemy object somehow. And all commands for getting such a reference will be forbidden most likely.

If your script doesn't know an enemy object or where to send its groups the only thing you can do is constantly `watch' your groups.

If they stop moving and their magazines are starting to pour out bullets you could assume they're returning fire. And then what ? Getting the average direction of all units could give a hint in what direction the enemy is, but you still dunno exactly how far.

That would be the point where i`d spawn some sandbags (forbidden) or call an artillery script. Or call the other group to rush to a flank, but you can never be sure if they don't run into a yet unknown enemy group as well.

In the end i think it all comes down to 'running around in the darkness until something happens'.

I find the idea interesting though.

nono, you misunderstood me.

You can get any reference to anything, BUT in case of enemy units, you can't pass info about them to your units by the "Reveal" command, and such. You can check "knowsAbout" of various objects, you can count yours and enemy cassaulties so you can alter your strategic plans, and so on.

I never wrote you will be forced to disable all AI on your units, and move them through the island like chess pieces.

There will be forbidden just few things like "setDamage" of any units (to prevent cheating, but you can freely use your medics to heal your units), etc.

[5133p39 16]

i am converting the AI-SC mission i was playing with to the basic template.

I will add few respawning vehicles, some objects you can use to build your defense from them, but not too much. I want to keep it simple.

You will have to write scripts which will make use of these units and vehicles and such, and which will control them - make them go somewhere and do something in order to capture all sectors, while of course you will be able to get info about various sector properties like to which side it belongs to, how strong is the enemy presence, etc., and when you capture a sector you will be given additional troops and the like.

Call it a "strategic brain" or whatever, you get the idea now, yes?

[hardrock 1]

nono, you misunderstood me.

You can get any reference to anything, BUT in case of enemy units, you can't pass info about them to your units by the "Reveal" command, and such. You can check "knowsAbout" of various objects, you can count yours and enemy cassaulties so you can alter your strategic plans, and so on.

I never wrote you will be forced to disable all AI on your units, and move them through the island like chess pieces.

There will be forbidden just few things like "setDamage" of any units (to prevent cheating, but you can freely use your medics to heal your units), etc.

But still, how can you get hold of the enemy units without triggers? By using nearestObject? Then it will be too late in most cases.

That's what I meant about triggers before. They usually do the "side detected by other side" stuff in missions, and that's what they are meant for and what can't be solved with scripts. Without that your units are basically blind.

The least thing that the scripter needs is a list of the enemy units for knowsAbout.

[5133p39 16]

The interesting thing about this lies in the fact that each of these so-called "strategic brains" will be written in different ways,

because they will be written by a different people, and so there will be one which will be better

- not like when you put two totally same scripts against each other (if they are good, then theoreticaly there can't be a winner because they are equally capable).

[5133p39 16]

But still, how can you get hold of the enemy units without triggers? By using nearestObject? Then it will be too late in most cases.

That's what I meant about triggers before. They usually do the "side detected by other side" stuff in missions, and that's what they are meant for and what can't be solved with scripts. Without that your units are basically blind.

The least thing that the scripter needs is a list of the enemy units for knowsAbout.

you don't need the "detected by" trigger if you can use the "knowsabout" command :-)

It works pretty well most of the time.

And if needed, there can be trigger of this type, which you will be allowed to use, already prepared by the mission template.

I don't see the problem here.

The basic rules will be that you are allowed to use some predefined units and objects, and within some limit you will also be permitted to create your own - what limits will be set and which prepared objects, that depends of what is needed.

But there must be some constraints so for example you couldn't create hundred LGB bmobs right on top of your enemies, or kill them instantly by setDamage and such.

[korax 4]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{_X addeventhandler ["Hit",{(_this select 0) setdammage 0}];_X addeventhandler ["Killed",{(_this select 0) setdammage 0}]} Foreach units (group player)

Do I win?

[5133p39 16]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{_X addeventhandler ["Hit",{(_this select 0) setdammage 0}];_X addeventhandler ["Killed",{(_this select 0) setdammage 0}]} Foreach units (group player)

Do I win?

no you won't, because there are no units in any of the players groups :-)

...and just a sidenote: the "setDamage" command is one of the banned ones

[vektorboson 8]

But still, how can you get hold of the enemy units without triggers? By using nearestObject? Then it will be too late in most cases.

That's what I meant about triggers before. They usually do the "side detected by other side" stuff in missions, and that's what they are meant for and what can't be solved with scripts. Without that your units are basically blind.

The least thing that the scripter needs is a list of the enemy units for knowsAbout.

you don't need the "detected by" trigger if you can use the "knowsabout" command :-)

It works pretty well most of the time.

His point is that one needs either a trigger or a list of enemy units to use knowsabout at all.

How should you be able to use knowsabout, if you don't have a list of units or at least one enemy unit?

Meanwhile I too think there should be one "detected by"-Trigger per side.

[mr.peanut 1]

This sounds like a lot of fun, but I would need a month to scrounge the time together to participate. Are the units to be completely script controlled i.e. no waypoints or triggers? The only problem I foresee is that given the mission template, it would be possible to script for the specific location. i.e. a huge array of map locations and instructions. I would only take part if only inf units are used to keep it simple.

I have the following suggestions:

1) Contestants should have to compete on each side of the conflict, for a few different mission templates.(or randomised start locations within a given distance of each other, where one group must advance west and the other east).

2) The same island (one of the BIS islands) be used for all conflicts.

3) The camcreate/createvehicle command should be allowed for emptysensors and gamelogics only to allow calculation of above sea level elevation.

4) No respawns.

5) No triggers.

6) No knowsAbout command.

7) A time limit after which losses are counted.

8) The code have some serious constraints on size, perhaps total size and/or number of lines.