Wow, great work guys! In response to your posts:
1) Data declarations - This basically means declaring all the types, variables, constants etc. so that everyone knows what they can work with. If we didn't do this first, integrating everyone's work into one big program could be problematic, and it may also run less efficiently.
2) Front End - This would include an eye-catching title screen, maybe the functionality to display the contestants profiles, and a limited menu system. Remember, I'ld prefer the finished product to keep the interactive side to an absolute minimum - I'ld like it to be presented as a "TV series", the rounds being the "episodes" of the series. So, for each round, we distribute an executable episode of the action, and then you can run it, sit back, and watch the action unfold by itself.
3) League table - This would be presented at the end of each episode. This won't have to involve any fancy calculations - just given an array of players and their scores, the league table should be able to present them in score order in an eye-catching way.
A question I'ld like to ask is: HUDs, UIs, APIs - what do those mean?!
I second Coorrae's vote that WolRon should be the project leader! Soon, I'll need someone to take over my position as the 'foreman', and I think WolRon would do a fine job.
Drago, I'ld be very grateful if you host our files for us, that would be very helpful!
My biggest concern is using the Millisecs() function to restrict how long each player's AI can work for. This is bound to create inconsistencies between different computers as to how the action unfolds. I've an old, slow PC, so if we restricted the time limit, then some of the participant's bots may not move at all on my machine. I suggest that when a player submits some AI, we perform a test on it to check it runs at a reasonable speed in all possible "arena states". If it meets the test, we then include it into the program. If not, we notify the player that it's "overweight", so that they can make amendments. Then, as we know all participants have fast AI, we impose no timeout restrictions - each player's AI is run for as long as it takes. This is not only fair, but it also ensures that everyone will see the same result. (And we don't have to worry about a time-out procedure, making the project less complex).
Keep up the good work guys!
Ryan
1) Data declarations - This basically means declaring all the types, variables, constants etc. so that everyone knows what they can work with. If we didn't do this first, integrating everyone's work into one big program could be problematic, and it may also run less efficiently.
2) Front End - This would include an eye-catching title screen, maybe the functionality to display the contestants profiles, and a limited menu system. Remember, I'ld prefer the finished product to keep the interactive side to an absolute minimum - I'ld like it to be presented as a "TV series", the rounds being the "episodes" of the series. So, for each round, we distribute an executable episode of the action, and then you can run it, sit back, and watch the action unfold by itself.
3) League table - This would be presented at the end of each episode. This won't have to involve any fancy calculations - just given an array of players and their scores, the league table should be able to present them in score order in an eye-catching way.
A question I'ld like to ask is: HUDs, UIs, APIs - what do those mean?!
I second Coorrae's vote that WolRon should be the project leader! Soon, I'll need someone to take over my position as the 'foreman', and I think WolRon would do a fine job.
Drago, I'ld be very grateful if you host our files for us, that would be very helpful!
My biggest concern is using the Millisecs() function to restrict how long each player's AI can work for. This is bound to create inconsistencies between different computers as to how the action unfolds. I've an old, slow PC, so if we restricted the time limit, then some of the participant's bots may not move at all on my machine. I suggest that when a player submits some AI, we perform a test on it to check it runs at a reasonable speed in all possible "arena states". If it meets the test, we then include it into the program. If not, we notify the player that it's "overweight", so that they can make amendments. Then, as we know all participants have fast AI, we impose no timeout restrictions - each player's AI is run for as long as it takes. This is not only fair, but it also ensures that everyone will see the same result. (And we don't have to worry about a time-out procedure, making the project less complex).
Keep up the good work guys!
Ryan