Well, I'm going to attempt to update the WIP demo with the additions that Ryan made (the clock and league table codes) and the many additions that I made here and there.
Many of the additions that I made were to make Ryans latest additions work with the existing code (this involved creating a seperate, but similar, file called ranksort.bb that sorted the bots ranks between rounds while the leaguetable.bb file sorts the bots ranks at the games end), and to improve the GameStateUpdate() function so that it now changes state from Arena to Arena. (You'll notice that there is no noticeable transition from one arena to the next, but this can be added in much later...)
I would have liked to have added in some of the media that's been popping up, but without the bots actually doing anything yet (because the BVM situation isn't completly resolved yet), there wouldn't be much point to adding it in, so I guess that'll wait for now.
And as far as the BVM situation is going, I've asked Koriolis a few questions about how to get it to work the way we want it to, and he replied with some suggestions.
Perhaps the easiest way to show the suggestions is to just display the email here.
So here it is...
> Hello Koriolis.
Hi
> Thanks for attempting to help out. Here are a few tough questions (or maybe
> not so tough?) for you to answer:
>
> (Unfortunately for your forum, I don't think posting on it is of much help
> to others since these questions are mostly specific to BAIT.)
>
> First question:
> In our talks, we discussed limiting each players bots abilities based on how
> many lines of AI script they used for their bot. if we wrote a custom
> interpreter, we wouldn't have a problem implementing that, but I'm not sure
> if it can be done with BVM. I see that BVM can execute compiled modules or
> can interpret raw Blitz code.
>
> We can certainly count the number of lines in a raw Blitz file (AI script),
> but the problem I see here is that interpreting raw Blitz code leaves each
> players AI script easily accessible/readable. This will be undesirable for
> each player, since others can just write AI script that directly undermines
> their AI script. This is not what we are trying to achieve.
>
> Each player submitting compiled modules can help correct this situation
> since the compiled versions will be much more difficult to read.
> Unfortunately, I don't know how or if we will then be able to COUNT the
> number of lines of script that exist within the compiled file.
>
> So, my question to you is: Is it possible to count the number of (original)
> lines in the compiled module? And if so, can we skip counting the commented
> lines?
> Or, if it's not possilbe to do that, then is there a way for a player to
> distribute their AI script without it being easily readable (and yet still
> usable by BVM)?
Well, before trying to achieve this, I'd like to ask you if counting lines
really is that meaningfull. As I see it it's a pretty poor way of evaluating
the efficency/clerverness/whatever of a script. First because some stupid and
blind rearangement of the script source could radically change the number of
lines, and it would favor poor writing styles (no comments, no returns, all you
can on a single line, etc...)
IMHO a much more viable and fair/undiscutable solution would be to have
something like "action points" (or call that "energy shells" consumption)
associated with each bot command. Like rotating by N degrees takes N points,
firing a rocket takes 50 points, reading the current roation takes 5 points,
and so on.
Besides the fact that it feels fairer and more correct (to me at least), it is
pretty easy to achieve. If you like the idea we can discuss the more
appropriate way to achieve this - mostly a gameplay design.
Now if you really want to limit the number of lines, there is nothing stopping
you from doing if the bot author has to use some tool provided by BAIT to
compile the script. Let me explain: with BVM it takes like 1 line to call the
compiler and compile a script into a binary module. Thus you can design
whatever file format you like for compiled bots, a format that *embeds* the BVM
module and adds additional information specific to BAIT, like the number of
lines, the author name, etc. When loading such a file, you get the information
you need (line number etc) and when it comes to run it, you extract the BVM
module and make BVM execute it. Pretty easy.
Actually even if you drop the idea of counting source lines, the custom file
format is probably a good move as you can put in it whatever information you
might want and need to read before even running a script.
Just a note: to prevent easy hacking of the bytes storing the line number and
othe information, you may want to make some basic encryption, like xoring all
these custom fields with the control sum of the BVM module (well to be
nitpicky, that would really be "obfuscation").
> Second question:
> We also spoke about limiting the number of lines of AI script that a player
> could use. We had suggested that if a player submitted a script with too
> many lines (over 1100), that they would not be disqualified from playing,
> but that they would just suffer the consequences of their actions by only
> the first 1100 lines of their script being executed. After that point,
> control would shift over to the next bot, and the rest of their AI script
> would just not run.
>
> Once again, if we wrote our own interpreter, this would be trivial to
> implement, but since we are trying to use BVM, I'm not sure how to implement
> this.
>
> Now, I did notice that BVM can handle multiple processes and as such, can
> Create/Kill/Pause and Resume them. I was thinking that once control was
> given over to the players AI script to execute, the process could be
> terminated (or paused or whatever) once 1100 lines of script had been
> executed. However, there doesn't appear to be any way to Pause/Kill a
> process after a certain amount of commands have been executed.
>
> I see that you can set up a process to time-out but that really isn't
> helpful. The only delusional method I can see of implementing this would be
> to set up the Process to time out in the smallest time element possible (1
> ms?) and HOPING that only 1 line of script was executed. Of course, I'm
> certain that that would never happen...
>
> So, my question here is: Is it possible to limit the number of commands that
> are executed? And if so, how?
No. But again would it mean much? To me the script size means not much, the
actual actions taken by the script do.
Actually one big question you have to firmly answer before anything else - and
whatever scripting engine you use -
is how are the execution of all the bot scripts "parallelized" ?
To me it seemed that a natural way would be to have some "Update" function
called each frame, but maybe it doesn't fell natural to you.
You seem to be going for a "forever execution" of the script, ie the bot script
would need to have something like Repeat ...forever, with its action in the
loop.
Why not. Say you go for it, the process emulation would be a nice solution if
you replace (or add) the "action points"
by "time points". That is, each bot command takes a given amount of (virtual)
time to execute.
You would run each script as processes with a little timeout (there only to
prevent blocky scripts), and each bot command
would consume an amount of the time slice allocated to the bot for the current
frame. If the counter reached zero
the command issues a "yield" (using BVM_Sleep(0) ) on the current process, that
is it makes another bot script execute.
It's been a *very* long time I didn't touch anything concerning the process
emulation, so it's really from memory and I may
have missed some problem, but for now it seems to me this is very doable like
that.
>
> Question three:
> I noticed that BVM allows you to map more than 1 module to a context. The
> question that arises in my head, is is it beneficial to create a seperate
> context for each module (AI script) or is it best to just map all of the
> modules to one context? What's the pros/cons of each method? Or rephrasing
> it would be, what does using a single or seperate contexts actually allow me
> to do?
Let's be clear, if the scripts are entirely independent - that is you have not
script A importing script B,
nor have you scripts accessing themselves the BVM API to run other scripts -
then using separate contexts is functionally equivalent.
In such a case the only advantage of using a single context is to save some
memory, as a single context means a single allocated stack (each context has
its own stack) .
>
> Well, I hope that you aren't overwhelmed by my rambling.
Not at all.
> Please let me know your answers. I DO ENJOY lengthy replies... ;)
>
> Sincerely,
> Ron
I hope I helped.
If not I'll do better next time :p
Koriolis.
Many of the additions that I made were to make Ryans latest additions work with the existing code (this involved creating a seperate, but similar, file called ranksort.bb that sorted the bots ranks between rounds while the leaguetable.bb file sorts the bots ranks at the games end), and to improve the GameStateUpdate() function so that it now changes state from Arena to Arena. (You'll notice that there is no noticeable transition from one arena to the next, but this can be added in much later...)
I would have liked to have added in some of the media that's been popping up, but without the bots actually doing anything yet (because the BVM situation isn't completly resolved yet), there wouldn't be much point to adding it in, so I guess that'll wait for now.
And as far as the BVM situation is going, I've asked Koriolis a few questions about how to get it to work the way we want it to, and he replied with some suggestions.
Perhaps the easiest way to show the suggestions is to just display the email here.
So here it is...
> Hello Koriolis.
Hi
> Thanks for attempting to help out. Here are a few tough questions (or maybe
> not so tough?) for you to answer:
>
> (Unfortunately for your forum, I don't think posting on it is of much help
> to others since these questions are mostly specific to BAIT.)
>
> First question:
> In our talks, we discussed limiting each players bots abilities based on how
> many lines of AI script they used for their bot. if we wrote a custom
> interpreter, we wouldn't have a problem implementing that, but I'm not sure
> if it can be done with BVM. I see that BVM can execute compiled modules or
> can interpret raw Blitz code.
>
> We can certainly count the number of lines in a raw Blitz file (AI script),
> but the problem I see here is that interpreting raw Blitz code leaves each
> players AI script easily accessible/readable. This will be undesirable for
> each player, since others can just write AI script that directly undermines
> their AI script. This is not what we are trying to achieve.
>
> Each player submitting compiled modules can help correct this situation
> since the compiled versions will be much more difficult to read.
> Unfortunately, I don't know how or if we will then be able to COUNT the
> number of lines of script that exist within the compiled file.
>
> So, my question to you is: Is it possible to count the number of (original)
> lines in the compiled module? And if so, can we skip counting the commented
> lines?
> Or, if it's not possilbe to do that, then is there a way for a player to
> distribute their AI script without it being easily readable (and yet still
> usable by BVM)?
Well, before trying to achieve this, I'd like to ask you if counting lines
really is that meaningfull. As I see it it's a pretty poor way of evaluating
the efficency/clerverness/whatever of a script. First because some stupid and
blind rearangement of the script source could radically change the number of
lines, and it would favor poor writing styles (no comments, no returns, all you
can on a single line, etc...)
IMHO a much more viable and fair/undiscutable solution would be to have
something like "action points" (or call that "energy shells" consumption)
associated with each bot command. Like rotating by N degrees takes N points,
firing a rocket takes 50 points, reading the current roation takes 5 points,
and so on.
Besides the fact that it feels fairer and more correct (to me at least), it is
pretty easy to achieve. If you like the idea we can discuss the more
appropriate way to achieve this - mostly a gameplay design.
Now if you really want to limit the number of lines, there is nothing stopping
you from doing if the bot author has to use some tool provided by BAIT to
compile the script. Let me explain: with BVM it takes like 1 line to call the
compiler and compile a script into a binary module. Thus you can design
whatever file format you like for compiled bots, a format that *embeds* the BVM
module and adds additional information specific to BAIT, like the number of
lines, the author name, etc. When loading such a file, you get the information
you need (line number etc) and when it comes to run it, you extract the BVM
module and make BVM execute it. Pretty easy.
Actually even if you drop the idea of counting source lines, the custom file
format is probably a good move as you can put in it whatever information you
might want and need to read before even running a script.
Just a note: to prevent easy hacking of the bytes storing the line number and
othe information, you may want to make some basic encryption, like xoring all
these custom fields with the control sum of the BVM module (well to be
nitpicky, that would really be "obfuscation").
> Second question:
> We also spoke about limiting the number of lines of AI script that a player
> could use. We had suggested that if a player submitted a script with too
> many lines (over 1100), that they would not be disqualified from playing,
> but that they would just suffer the consequences of their actions by only
> the first 1100 lines of their script being executed. After that point,
> control would shift over to the next bot, and the rest of their AI script
> would just not run.
>
> Once again, if we wrote our own interpreter, this would be trivial to
> implement, but since we are trying to use BVM, I'm not sure how to implement
> this.
>
> Now, I did notice that BVM can handle multiple processes and as such, can
> Create/Kill/Pause and Resume them. I was thinking that once control was
> given over to the players AI script to execute, the process could be
> terminated (or paused or whatever) once 1100 lines of script had been
> executed. However, there doesn't appear to be any way to Pause/Kill a
> process after a certain amount of commands have been executed.
>
> I see that you can set up a process to time-out but that really isn't
> helpful. The only delusional method I can see of implementing this would be
> to set up the Process to time out in the smallest time element possible (1
> ms?) and HOPING that only 1 line of script was executed. Of course, I'm
> certain that that would never happen...
>
> So, my question here is: Is it possible to limit the number of commands that
> are executed? And if so, how?
No. But again would it mean much? To me the script size means not much, the
actual actions taken by the script do.
Actually one big question you have to firmly answer before anything else - and
whatever scripting engine you use -
is how are the execution of all the bot scripts "parallelized" ?
To me it seemed that a natural way would be to have some "Update" function
called each frame, but maybe it doesn't fell natural to you.
You seem to be going for a "forever execution" of the script, ie the bot script
would need to have something like Repeat ...forever, with its action in the
loop.
Why not. Say you go for it, the process emulation would be a nice solution if
you replace (or add) the "action points"
by "time points". That is, each bot command takes a given amount of (virtual)
time to execute.
You would run each script as processes with a little timeout (there only to
prevent blocky scripts), and each bot command
would consume an amount of the time slice allocated to the bot for the current
frame. If the counter reached zero
the command issues a "yield" (using BVM_Sleep(0) ) on the current process, that
is it makes another bot script execute.
It's been a *very* long time I didn't touch anything concerning the process
emulation, so it's really from memory and I may
have missed some problem, but for now it seems to me this is very doable like
that.
>
> Question three:
> I noticed that BVM allows you to map more than 1 module to a context. The
> question that arises in my head, is is it beneficial to create a seperate
> context for each module (AI script) or is it best to just map all of the
> modules to one context? What's the pros/cons of each method? Or rephrasing
> it would be, what does using a single or seperate contexts actually allow me
> to do?
Let's be clear, if the scripts are entirely independent - that is you have not
script A importing script B,
nor have you scripts accessing themselves the BVM API to run other scripts -
then using separate contexts is functionally equivalent.
In such a case the only advantage of using a single context is to save some
memory, as a single context means a single allocated stack (each context has
its own stack) .
>
> Well, I hope that you aren't overwhelmed by my rambling.
Not at all.
> Please let me know your answers. I DO ENJOY lengthy replies... ;)
>
> Sincerely,
> Ron
I hope I helped.
If not I'll do better next time :p
Koriolis.