quote: Original post by Hedos
But kevin verify every source code and he can see if they just copied his bots and modified it a little bit..

Which means we only requires a rule about plagurising code on the contest rules page. That way it is in ink by the time any problems roll around.

-=-
"Boy? Girl? It does not matter, all that matters is power, and beauty is power. I am beautiful, so I have power and that is all that matters."
Got Immortality?
[edited by - Timestamp_Zero on January 1, 1970 00:00:00 AM]

I can add orientation.. but it will be in a direction relative to your current direction.

As for time limits, it''s in the rules (as has been explained in 1337 speak).

Well by all means he probably can''t give away the source to his (or any bot) until the competition starts or he''d be giving away too much information about the contest.

I can give the source code to the test bots, but I really don''t know what good they''re going to do besides illustrate the arena interface commands. The max line of code count the bots reached was I think 20, and all they did was run in circles until they found each other - at which point they go after their enemy and fire. But, if people want to use that as a start, they''re free to. I just know they won''t win anything. In fact, these bots have a better chance of killing themselves than they do their enemies.

Part of the reason I mention plagurism, is also for the midterm of the game, where certain players might "borrow" a couple functions, and whatnot.

I know the source will be publicly available, but plagurism still would not be a good thing.

Does "This includes any libraries, outside DLL's, or any other form of executable code required to execute your bot." include standard libraries? Like ANSI functions (atan for example) or STL. I know it does not, but technically the LIBC.lib is included by default in a VC++ project, and it is a library that is required if you use any of its functions.

Also inline assembler would not be any tougher than C++ to review for cheating. You have to use "call" (or the address of a function) to call a function, and you can check malicious use of the stack by searching for instructions that use the stack and base pointers. I think well commented inline assembler should be allowed in time critical sections.

Disallowing inline assembler is pretty harsh. The graphics optimization race is often aided by assembler. Why should the AI optimization race be limited to the smarts of the compiler?

The only problem I can foresee with allowing inline assembler is the minimum processor spec. I'm sure 386s and 486s are out of the question, so how about PII? There are quite a few new instructions since Pentium that will help with aiming, direction detection, object location, etc...

Also make sure that the calling convention {C style "__cdecl", STDCALL "__stdcall", etc...} is mentioned for the exported functions, or at least provide us with a macro to stick in front of our functions like GDARENA_API_EXPORT.

[edited by - Rob9000 on July 10, 2003 7:44:36 PM]

To guard against copying while still allowing some spirit of openness (which I think is very beneficial) entrants could submit a short document detailnig roughly how their algorithm works.

Orientation isn''t maybe too important, but position and a velocity vector (whether in the world reference frame or your bot''s) would be a good minimum to aim ahead of them, guess how long it''ll take them to tuen to face you etc...

RE timing: A fixed frame rate means you have say X milliseconds for your ''move'', right? This then means small compact bots have no response advantage - the best bot would be the one that fits the most ''thought'' into exactly X milliseconds, broadly speaking. But what if you do go over - how is this stopped other than disqualifying you if one of your turns is over-length (which could happen due due a hiccup on the host PC for example), and unless you know the target spec or write an algo which adapts to fill the available time how can you efficiently use all your time? Maybe you have a set of commands for your bot (move, turn, shoot) that you put in some ''registers'' and then every X ms the host looks at the contents of these and acts on them - if you miss your time limit you waste a turn. I dunno - synchronisation isn''t one of my fields - but I think you need to ensure it''s fair and easy to optimise your bot to take best advantage of the time.

I think building a map of the arena could be cool on a 2d ''canvas'' - you could plan ahead to move from obstacle to obstacle. Though effectiveness would highly depend on the implementation of the arena.

Are we likely to be able to see bullets or whatever moving?

Will we be able to tell how much health our opponent has left? Maybe not exact numbers, but an indication would be good. I would certainly change tactics if I knew my opponent had very low health and I was still at 100% (or the other way around).

If we get hit by a bullet/rocket/whatever will there be information as to which direction it came from? Again, not exact, maybe front/left/right/back.

This sounds like a great contest idea, can''t wait to get started.

Alan

quote: Original post by DakeDesu
Part of the reason I mention plagurism, is also for the midterm of the game, where certain players might "borrow" a couple functions, and whatnot.

I know the source will be publicly available, but plagurism still would not be a good thing.

Only the bot DLL''s will be available for download after the Midterm (although, source still has to be submitted to me). I''ll make that more clear in the rules. I don''t think it would be good to release the source code of everyones entry halfway through the contest..

quote: Original post by Rob9000
Does "This includes any libraries, outside DLL''s, or any other form of executable code required to execute your bot." include standard libraries? Like ANSI functions (atan for example) or STL. I know it does not, but technically the LIBC.lib is included by default in a VC++ project, and it is a library that is required if you use any of its functions.

Also inline assembler would not be any tougher than C++ to review for cheating. You have to use "call" (or the address of a function) to call a function, and you can check malicious use of the stack by searching for instructions that use the stack and base pointers. I think well commented inline assembler should be allowed in time critical sections.

Disallowing inline assembler is pretty harsh. The graphics optimization race is often aided by assembler. Why should the AI optimization race be limited to the smarts of the compiler?

The only problem I can foresee with allowing inline assembler is the minimum processor spec. I''m sure 386s and 486s are out of the question, so how about PII? There are quite a few new instructions since Pentium that will help with aiming, direction detection, object location, etc...

Also make sure that the calling convention {C style "__cdecl", STDCALL "__stdcall", etc...} is mentioned for the exported functions, or at least provide us with a macro to stick in front of our functions like GDARENA_API_EXPORT.

[edited by - Rob9000 on July 10, 2003 7:44:36 PM]

I think it would be better if everyone was able to understand everyone else''s code. Being familiar in assembly language of several different dialects, I understand the need to make sure code is well optimized. However, this project isn''t a full-blown, triple-A quality, modern game with a million polygons on the screen at once. There isn''t a ton of AI-entities to manage, and there is no online component to worry about. Is assembly language really necessary? Remember, it''s not the 90''s anymore!