BAIT 2005
Community Forums/Showcase/BAIT 2005
| ||
| Hi everyone, BAIT, the Blitz Artificial Intelligence Tournament, is a community project that I've decided to start up. The concept is as follows: Each participant of the tournament has to write some AI to control a robot of their own. All of the robots will then either battle to the death like in Robot Wars, or play a variant of tag. The tournament would be spanned over a number of rounds, each round adding new elements to the game, meaning that each participant has to tweak their AI accordingly before each round. My aim is to present the tournament like a "TV series", the 'episodes' being the rounds which make up the tournament. Before each round, a profile of the participants are given, then you watch the action unfold, and then the current league table is presented at the end. These episodes would be distributed as they are made. To make this project work, we need to begin by building up an engine. It's main components, and the order in which we need to construct them, is shown in the flowchart below:  As you can see, we need to start off with the data declarations. There are also two miscellaneous tasks that can be done at any time - the front end and the league table. So, if you want to get involved, tell us which part of the project you want to work on - the more, the merrier. Any suggestions are also appreciated. The tasks that can be done at the moment are: 1) Data Declarations (Highest priority) 2) Front End 3) League Tables To see what has been discussed already, visit http://www.blitzbasic.com/Community/posts.php?topic=45439 Any volunteers? Ryan Moody |
| ||
| Thanks for the sticky Rob! |
| ||
| I will gladly make as many suggestions and bug reports (I'm good at causing programs to crash :D ) as I can for now... Later on I'll try to help out with other stuff. I have a great idea for AI in this type of game though, so I definietly want to help out! One thing: Don't get me to do completion date estimates! |
| ||
| 1) Data Declarations (Highest priority) 2) Front End 3) League Tables what do these mean? |
| ||
| 2) Front end would be the menu interface, possibly HUDs, UIs etc. 3) League Tables would be a championship ladder sort of thing, a ranking system for who's doing well and who isn't. 1) I'm thinking would be the program shell, Type declarations, API declaration in general and such. |
| ||
 Welcome, BAIT (Blitz Artificial Intelligence Tournament), is a Blitz3D Open Source Game For the Blitz Community. Anyone can participate. The conversation has moved to a new thread. Click on this link: BAIT Community Project (thread 2) to see what's currently being talking about and to see what else the BAIT Community project has to offer. To familiarize yourself with what BAIT is, you can check out the Game Overview/Gameplay Rules page. HOW TO GET INVOLVED  Code/Media Conventions And Guidelines 8 Apr 05 WolRonLINKS  BAIT Official Thread 2 Various authors BAIT Official Thread 1 (this thread) 15 Apr 05 Various authors BAIT original discussions 5 Apr 05 Various authors |
| ||
| .......... ... I vote Wolron for project leader. |
| ||
| Another quick question to answer: Who's going to host all of the code/media/site/etc. for the game? |
| ||
| If this is going to use a script engine, you should run just one command from each person's code, taking turns: "a=5" for person one "if b=3 then" for person two "b=3" for person one "attack=1" for person two ... So if someone has a lot of code it keeps the game fair. And maybe have linepick using up 10 turns (skipping 10 turns) Counting millisecs is a bit unfair and what happens if someone makes an endless loop? |
| ||
| I can host the media if you want, if you are interested send an email to bait at Drago-tech dot Net |
| ||
| Well, Luke, your technique will make visual glitches happen, but is good in case of a loop. [edit] Okay, so maybe it wont make too much of a difference on a newer computer than the P60 i was thinking.... :P [/edit] I recommend running each players code for 1ms but do as luke says above, at the point they get a time-out, move to the next playrs code, and continue later on Clean multitasking. :) Also, if you want the complexity to be limited (no super-long, overly complex, tmie consuming procedures..) then you run each players AI until it finishes its loop or a timeout occurs. If a timeout occurs, you could simulate the robot being too heavy for its chasis? :D |
| ||
| btw, my 2 cents worth. about a scripting engine, I would recommend you use BVM or something, since making a scripting engine isn't easy, and if this was being done in blitzmax I would say, you should use LUA since well, it is one of the best scripting engines that I have used. the other cent, is don't care about gfx, and sounds till you have a decent framework, since they just distract from getting the program working, I am talking from personal experience, at work we get alot more work done when there are not artist around, bugging, us. |
| ||
| I recommend running each players code for 1ms but do as luke says above, at the point they get a time-out, move to the next playrs code, and continue later on I think that is pointlessly over complex. I think if you run each line of code in turn as Luke suggests you're going to be fine. If the game core is running at say 120 updates per second I don't think it's going to make a lot of difference. If you've only got 4 players that means each player will get 30 lines of code executed every second. Each player will have their own set of variables so running each script line in turn isn't going to be a problem. And as Luke said, it gives people with longer scripts a minor disadvantage over the more simplistic scripts. |
| ||
| I think that is pointlessly over complex. I think if you run each line of code in turn as Luke suggests you're going to be fine. Indeed, as i edited my post; I was thinking of the thing running on a slugputer for some really odd reason!! What i said isnt difficult to do at all, but youre right, as we can certainly have more than 120 updates a sec, if we make the script engine efficient enough. I am interested in this and will help out, but i have other work to do too, so i wont be joining in often. |
| ||
| 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 |
| ||
| Probably should have asked this too (Gfk's going to like this) Who's working on what?! (i.e. the 3 current tasks) Ryan |
| ||
| Well, can we nominate a person to oversee the project from a technical leader position? I don't like using standard names for roles, so how about a master? That way someone could master BAIT. |
| ||
| Sounds good. Who would like to 'master' the current problem (and essentially SOLVE the problem), the data declarations? Ryan |
| ||
| If no-one else offers, I'd like to master BAIT. And if anyone wants to lend a hand in my position, I'd be most grateful. |
| ||
| Cool. WolRon seems to be doing a good job at laying the foundations, maybe you two could collaborate? |
| ||
| Personally I think the only way this will succeed is with a custom scripting engine. Slow PCs quite frankly isn't a problem, pretty much any old computer can run 120 updates per second without worrying. You just run the game core at this speed and render whenever you can. Timing out is a very very bad way to go and very hard to code as timeout code would have to be between ever instruction or something... personally I'd say bugger that, far to complex, just run 1 line at a time in turn this way everyone gets an equal slice of the cake. However, this cannot work using blitz as the AI script. HUD - Head up display UI - User Interface API - Application program interface Who's writing what?: I'm not doing anything. |
| ||
| Ok, no problem. Maybe it would be a good idea to have some people writing up the data declarations for the project as a whole, and another group for a custom scripting engine. Any volunteers? |
| ||
| Forget the data declarations at this point. You need to work out what each bot is going to have the ability to do. Once you get that nailed you will be able to work out what information needs to be stored and what AI advantages / disadvantages each will have. For example: If a bot can have a turret, then you need to be able to turn the turret, having a turret would add weight, the weight would slow the bot down so you get the trade off there. Further, what weapons are available for a turret? If you have a turret does this mean you can't have a second weapon? Weapons generally, can they be mounted forward, side or rear facing? What weapons will there be? Will there be passive weapons like mines that can be dropped? You get my point... This stuff needs to be worked out before you even start considering coding anything. Unless you know what a bot can do there is no way to write the AI command set for a bot. And therefore no way to write an AI script or AI engine. Here's an example of pretty much what we're talking about but already done! http://www.tacticalneuronics.com/content/aiw3dnew.asp http://www.tacticalneuronics.com/content/AIWHelp.asp |
| ||
| Ryan, sent you an email to the email listed in your profile. |
| ||
| Yes, we need a "Bot Engine" to wrap everything else onto. I see it working in way that all parts plug into the engine. Obviously, the AI side of things needs to be Plugable, as in, you have one function, which you pass a bot_type, and the AI controls it through the interface: Bot\x_dir,bot_ydir,bot\shootflags,bot\target etc etc.. thus minimising the ability to cheat, as these would be the only link to the program. Thats the basis of most of My AI routines and i think the technique fits really well with this, and you can get impressive results. Perhaps i'm going about it all wrong, but wouldnt a base-functionality program be best to start with? |
| ||
| You're right, we need to clearly specify what attributes a robot possesses before we can move foward. Some questions: 1) What physical properties would a robot have? 2) What actions can a robot perform? 3) What weapons could a robot be equipped with? 4) What AI commands would be required to control a robot? 5) What external factors could affect a robot? Once we know the answers to these questions, we can get started on the engine. By the way, thanks for the email Drago, I'll reply in a mo. Ryan |
| ||
| Here's a starter: 1] Basic Bot 1.1 Engine Power 1.2 Max Turn Speed 1.3 Weight 1.4 Armour 1.5 Temperature 1.6 Fuel / Battery power 2] Bot Control See commands [4] 3] Bot Weapons (see gun stats [6]) Examples 3.1 Machine Gun (light weapon) 3.2 Shell (medium weapon) 3.3 Missile (heavy weapon) 3.4 Mine (Passive weapon) 3.5 EMP stun? (close quarters weapon) 3.6 Glue (passive weapon) 4] Bot commands 4.1 Move[speed] (speed -1 to 1) 4.2 Rotate[speed] (speed -1 to 1) 4.3 Scan[reletive angle] (returns wall, mine, refuel, powerup, rival [number] position [x,y]) 4.4 Fire[weapon] 4.5 DropWaypoint (returns waypoint number dropped) 4.6 GetWaypoint[waypoint number] returns x,y of waypoint 4.7 SetVar[varno,value] 4.8 GetVar[varno] 4.9 Repeat 4.10 Until[Argument] 4.11 GoSub[label] 4.12 Label[Label] 4.13 GetDistance[x,y] returns the distance from your bot to x,y position 4.14 GetAngle[x,y] returns the angle -180 to 180 from your bot to an x,y position 4.15 DropWeapon[weapon] 4.16 RotateWeapon[weapon,speed] (speed -1 to 1) 4.17 GetWeaponTemp[weapon] 5] Things that affect the bot 5.1 Hot / cold? 5.2 Collision 5.3 Damage 5.4 Explosions? 5.5 EMP stun 5.6 Glue 6] Gun Stats 6.1 Bullet type (see bullets below) 6.2 Fire Rate (how quickly the gun will fire the bullets) 6.3 Working Temperature from 6.4 Working Temperature to 6.5 Temperature increase per round fire (these 3 will see if you fire too much the gun will stop working) 6.6 Weight (how much it weighs the bot down) 6.7 Max Ammo (how much ammo it can hold) 7] Bullet Stats 7.1 Speed (how fast it moves) 7.2 Weight (how much force it applies to whatever it hits) 7.3 Damage (how much damage it applies to whatever it hits) 7.4 Life (how long the bullet will continue for before disappearing) 8]Additional stuff: 8.1 Heat sinks (cools down the bot quicker) 8.2 Additional Batteries / Fuel tanks If this method is employed you could have a bot creator where you build your bot (accesories etc) and program the AI. On top of this is allows expansion for weapons. |
| ||
| A great start. What would others like to amend/add? |
| ||
| .... I got it when i saw the quote... but when i first saw the original i never :/ 7.x) Bullet TYPE (slung/fired).... Angle of trajectory....? |
| ||
| I like the extensions being made, any others you can think of? |
| ||
| I think that the program should simply not accept a player unless his AI code takes less than some number of milliseconds to complete, and leave it at that. Counting millisecs is a bit unfair and what happens if someone makes an endless loop? An endless loop would not be a good thing to put in AI :) The millisecs counter wouldn't really be a stupid rule, it would be to ensure that everything runs happily. |
| ||
| Pickles, yes, but on slower machines, the code will do a different amonut in a different frametime... thats the issue. I recomend in this case, a built in timer. one tick per line sort of thing :) |
| ||
| We can worry about that later, and I think Luke's already come up with a good solution. Let's work out what functionality the bots should have first. When we've finalised that, we'll be able to make some sort of a start. |
| ||
| An endless loop would not be a good thing to put in AI :) This can easily be handled. Like in my previous suggestion, all AI scripts can have a maximum number of lines of (say) 1100. The engine executes each line (keeping track of the number of lines) and once the engine reaches 1100, the AI's turn is aborted, regardless of where it's at. This puts the responsibility on the AI programmer to make sure that their code is efficient, or else it will suffer.The millisecs counter wouldn't really be a stupid rule, it would be to ensure that everything runs happily. 3.1 Machine Gun (light weapon) This might get out of hand at the number of elements the engine has to keep track of. Of course, huge numbers for computers is no challange, but large periods of time for the user to have to sit and watch the 'show' could be a challange.I'm not sure we want 'rapid fire' weapons. ...tangent... Also, I'm concerned that in a 'TAG' game, the 'IT' player may be outgunned. No weapons (or at least very limited weapons) should be allowed in a 'TAG' game. |
| ||
| 1100? That's a bit high, isn't it? |
| ||
| Well, in my previous suggestion, I was suggesting the extra lines of AI script slowed down the 'bot', so '1100' would equate to a 'bot' with 0 speed. I.E., useless. The AI programmer would have to work with (much) less than that to make a useful 'bot'. |
| ||
| Alterations so far: Bullet TYPE (slung/fired).... Angle of trajectory....? Too complicated I think - I feel bullets moving in straight lines should suffice. Exclusion of the Machine Gun - The bullets could be 'invisible', so you only see the bot firing, and bots in the line of fire being hit. My personal alteration would be that anything temperature related should be removed - I feel that's a bit OTT. *edit* On second thoughts WolRon, if we only allowed one command per line, 1100 may not be such a bad figure - slightly less maybe. Ryan |
| ||
| Temporature stuff will stop the AI from just shootnig 500 bullets a throw :/ The actual angle of trajectory was an idea purely meant so it looks good ;) |
| ||
| Ah, but that's what the ammo limitation is for. I still feel a trajectory angle would make the action confusing from a 2D point of view, what do others think? |
| ||
| On second thoughts WolRon, if we only allowed one command per line, 1100 may not be such a bad figure That was my thinking from the beginning. It's an easy way to control the number of commands per AI script (and most likely easier for the interpreter to read as well). I still feel a trajectory angle would make the action confusing from a 2D point of view, what do others think? 'Trajectories' are worthless in a 2D-top-down-view game. Dump the idea. |
| ||
| Im off home in half hour or so, I may get a couple of minutes free to try some ideas, but ive got a higher priority project. I may try to work on a script engine, not specificaly for this project, but i kept meaning to make a 2d version of CGNovascript (yeah i know, the names taken) that might come in handy here and in my future projects. |
| ||
| That's most appreciated, thanks Cygnus. Don't go too far ahead though, otherwise it might need to be substantially modified later on. Any more thoughts on what the bots should do? Here's what I feel the current list should be: 1] Basic Bot 1.1 Engine Power 1.2 Max Turn Speed 1.3 Weight 1.4 Armour 1.5 Fuel / Battery power 2] Bot Control See commands [4] 3] Bot Weapons (see gun stats [6]) Examples 3.1 Machine Gun (light weapon) 3.2 Shell (medium weapon) 3.3 Missile (heavy weapon) 3.4 Mine (Passive weapon) 3.5 EMP stun? (close quarters weapon) 3.6 Glue (passive weapon) 4] Bot commands 4.1 Move[speed] (speed -1 to 1) 4.2 Rotate[speed] (speed -1 to 1) 4.3 Scan[reletive angle] (returns wall, mine, refuel, powerup, rival [number] position [x,y]) 4.4 Fire[weapon] 4.5 DropWaypoint (returns waypoint number dropped) 4.6 GetWaypoint[waypoint number] returns x,y of waypoint 4.7 SetVar[varno,value] 4.8 GetVar[varno] 4.9 Repeat 4.10 Until[Argument] 4.11 GoSub[label] 4.12 Label[Label] 4.13 GetDistance[x,y] returns the distance from your bot to x,y position 4.14 GetAngle[x,y] returns the angle -180 to 180 from your bot to an x,y position 4.15 DropWeapon[weapon] 4.16 RotateWeapon[weapon,speed] (speed -1 to 1) 5] Things that affect the bot 5.1 Collision 5.2 Damage 5.3 Explosions? 5.4 EMP stun 5.5 Glue 6] Gun Stats 6.1 Bullet type (see bullets below) 6.2 Fire Rate (how quickly the gun will fire the bullets) 6.3 Weight (how much it weighs the bot down) 6.4 Max Ammo (how much ammo it can hold) 7] Bullet Stats 7.1 Speed (how fast it moves) 7.2 Weight (how much force it applies to whatever it hits) 7.3 Damage (how much damage it applies to whatever it hits) 7.4 Life (how long the bullet will continue for before disappearing) 8]Additional stuff: 8.1 Additional Batteries / Fuel tanks |
| ||
| I think we should stop there. If we keep adding features, it will never get finished. We might even drop (or hold on) a few weapon types (namely these two: 3.1 Machine Gun (light weapon) 3.5 EMP (stun))until we get a prototype running. Also, I think we might want to modify RotateWeapon SPEED to RotateWeapon DEGREES Also, since Scans might be pretty processor intensive (if everyone is doing it every cycle) we should probably split them up into different categories, like 'Scan Rivals', 'Scan Replenishing Items', 'Scan Offensive Items (glues, etc.)', etc. so that only the ones that are requested are the ones that are executed. |
| ||
| That's a good idea. In that case, we may as well make a start on the AI scripters and interpreters. Some questions to think about: 1) What methods will need to be implemented? 2) What would their parameters be? 3) What would their pre-conditions be? (i.e. what restrictions would be placed on the parameters, e.g. speed must be > 0) 4) What would their post-conditions be? (i.e. what should the methods do) 5) What errors could these methods produce? 6) How would we tackle these errors? 7) How would input / output be handled? 8) How should a player's AI be stored? 9) How should a player's AI be incorporated into the program? 10) Who would like to write which methods? On that note, I would like to temporarily pass over my role as the project co-ordinater to someone else, or a group of people. My exams begin in just over a fortnight's time, so I won't have the time to carry this on for a while. Any volunteers? Thanks, Ryan |
| ||
| Missing Bot's awareness of surroundings I think :) Need a sensor which detects nearby things - with restrictions, obviously: IE - programmer needs to set up what angles it will scan in (sensor could only scan small chunks at a time?) A function can then be used to determine what everything is (ie: Enemies, level objects, pickups). Can access basic info about other bots that are scanned (or maybe even when not scanned to some extent?) Basic; A health estimate, current weapon, name/handle for access later, position in relation to self (only when scanned?). Other stuff could need to be figured out by the AI's observational skills if it has any. |
| ||
| Ok, we could enhance the scanning function when we write the AI interpreter. As I said in my previous post, I won't be able to carry on managing this project for a while - would you (or anyone else) like to take charge while I am away? Thanks, Ryan |
| ||
| I will take over as project leader for BAIT, if no-one objects. I've got some ideas and am interested in the project. I don't have a lot of time to spend on it every day, but I can spend SOME time on it most days. I've also been following from the beginning and know what's been talked about. So, if anyone doesn't have any objections, then I will carry on and master BAIT. |
| ||
| I've wanted to get someone to master BAIT for a very long time (that was quite clever Caff). Thank you very much WolRon for taking up the role, don't let me down! Cheers, Ryan |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=45569 ehehehe... Might get some ideas for something like this from www.mindrover.com |
| ||
| So is this to make a game where you script and build a robot in an in-game GUI and have the bots face off against one another? Like this? I've played a number of these, there's no gameplay involved when everyone has the same tools and capabilities to make their bot. And I think bot builder has a point... |
| ||
Just a quich scetch on how i feel the AI script should be alowed to control things. of course, it may end up totally different to this, but as i stated above, its a technique that worked for me, and means you cant code the AI to make other bots run off, or make yours teleport... etc etc. Its based on using the same Control Function for both Player and AI, the player function hands the control function the x,y values, fire buttons, things like that, and the control function does what needs to be done. The control function is also where the program does any scanning, and places them into variables for each robot accessible via script. Heres the DOC if you want to tear it apart :) http://DAMIENSTURDY.PWP.BLUEYONDER.CO.UK/bot.doc |
| ||
| Will everyone please check out the "Bot Specifications/Abilities" and the "Gameplay Rules" that I've put together (links are in the 6th post in this thread, the 'OFFICIAL' one) and tell me if you see anything that you agree/disagree with. I've tried to balance the weapons, so see what you think. The command set isn't definitive yet. Let me know if you see any problems. (I'm thinking that for speed improvement issues, Scanning should/could be split up into seperate types of scans.) ----------------------------------------------- Note that the "Engine Interface/Responses" page is still just filled with preliminary ideas at the moment and are there mostly as pageholders. However, if you see something you like on that page, speak up. Time for nighty, nighty, so see you all tomorrow... |
| ||
| I'm happy with that. Pickups will of course include fuel.. Maybe a bot-NOS? hehe.. Honestly though, I'm good to use that. |
| ||
| Pickups will of course include fuel.. Yes, but HOW will the fuel be used? In the specs I wrote, the Engine Power is affected by weight only.What are your ideas on how to 'use' fuel? How will it fit in with the ideas/specs already presented? |
| ||
| i only mentioned the above because fuel was in there with the scan command etc. Having a good think, Fuel/Batteries dont seem required unless its to add a challenge; like, fuel runs out at a Certain rate while the bot is moving taking weight into account. The rate of use will need to be calculated so that each bot doesnt just run for the same amount of time and strategies can be implemented into the AI to preserve fuel, like the bot not moving when its not needed. |
| ||
| After thinking about this a lot, I see a major flaw in our design plans. In our current planning, there is -NO WAY- we can guarantee that our code will produce the exact same results on all computers because of floating point math discrepancies. Some of the reasons for this are our chosen use of the following methods: - Move[speed] (speed -1 to 1) - Rotate[speed] (speed -1 to 1) - GetAngle[x, y] returns the angle -180 to 180 from your bot to an x, y position - RotateWeapon[weapon, speed] (speed -1 to 1) - GetDistance[x, y] returns the distance from your bot to x, y position - Scan[relative angle] (returns wall, mine, refuel, powerup, rival [number] position [x, y]) - 100% maximum speed = 10 units per clock cycle (because 99% would equal 9.9 units) - collisions are based on a RADIUS from center of model, in order to keep the same behavior between different models - Max speed is decreased by .1% for every line of script (not including comments) over 100 (1100 lines of AI code would then equal 0% speed) All of the above methods will require floating point math either by design (-1.0 to 1.0) or because they will return an arbitrary angle (which will not be an integer). For these reasons, we either have to completely redesign how this game will work or tournaments will have to be executed on ONE OFFICIAL computer only and then the results will be posted. Some ways that we could possibly redesign the game are: --attaching all game objects to some kind of grid ..all methods are changed to use integers only (-100 to 100 instead of -1.0 to 1.0) ..any rotation speed commands will have to be changed to exact degree commands ..this will still leave a problem with angles returned from (for instance) a scanning function Do we drop angles and just return co-ordinates? or what? --MAYBE write some kind of custom FPU (floating point unit) that actually uses integers internally ..ALL math performed by the engine will use the custom FPU ..This will most likely be EXTREMELY slow in comparison to the real FPU Where do we go from here? Let me hear your ideas. |
| ||
| Why not just return ints? Any fps calc gets floored before return. I think you need to return an angle of where something is so you know which way to turn. |
| ||
| Returning integers still requires floating point math to be performed before the returned result. Results are not guaranteed. Also, how can the player specify a speed (for example) of .345 (which is between -1.0 and 1.0)? If its FLOORed then it will always equal 0 or 1, nothing else. |
| ||
| I agree with your speed thing (-100 to 100) instead. Regarding floating point differences I think you're worrying too much, after all, it's a little game, nothing more. If you get slightly different results on 2 different computers... who really cares? Yeah, it's annoying but I wouldn't worry. |
| ||
| I agree with Rob here too... I dont have my P60 R1 anymore :P |
| ||
| Well, how do you people feel about these two commands: Rotate[speed] (speed = -100 to 100) RotateWeapon[weapon, speed] (speed = -100 to 100) Do we want to rotate our bots and weapons using a speed factor? or Do we want to rotate them using an ANGLE, and then the engine only rotates the bot or weapon depending on the max speed possible? This is more of an issue with the weapon, I think, because you will mostly want to AIM it at something, which will require stopping it at a certain angle (not just telling it to rotate, and it goes round and round and round...). Perhaps we should add one more command to the set: GetWeaponAngle[weapon] which would return the current weapon angle (since it might not have yet reached the angle that was specified earlier due to speed restrictions). By the way, give me some ideas on how to limit the Max Turn Speed. (Check out the Bot Specs page.) |
| ||
| I think if you have the Scan command accepting an angle then rotate should be to an angle, aiming would have to be for an angle... |
| ||
| I'm bored of revising. And it looks like this could do with a bump! I don't think 'aiming' is necessary - just make the bot fire in whatever direction it is facing. If you want to 'aim' at an enemy, you scan for it first and get it's (X,Y) co-ordinates in relation to your bot, do a bit of trig to work out what bearing the bot needs to face in, rotate to this bearing, then fire. The only problem with this is that a bot may never fire at a moving target as it would have to continually turn to continually face it. Regards the other points, don't worry about floating point discrepancies and get rid of the fuel idea. It would be disappointing to see a strong bot lose by one point just because it ran out of fuel. Regards the turning speed, I feel this should be proportional to the bots weight - the lighter it is, the faster it turns. Keep this project going guys! I've got my eye on you lot! Ryan |
| ||
| And it looks like this could do with a bump! You're trying to bump a sticky? I don't think 'aiming' is necessary - just make the bot fire in whatever direction it is facing. If you want to 'aim' at an enemy, you scan for it first and get it's (X,Y) co-ordinates in relation to your bot, do a bit of trig to work out what bearing the bot needs to face in, rotate to this bearing, then fire. That's the whole point, we need to be able to turn to a specific bearing, not just rotate.I will change the two commands in question to accept Angles (not Speeds). |
| ||
| The only problem with this is that a bot may never fire at a moving target as it would have to continually turn to continually face it. I think that's quite a big "problem" that would affect the users capabilities to program the AI. Yes, it would make it more challenging, but I feel there should be built in angle commands. |
| ||
Ah, I see what you mean now - Here's some code which will help (not tested):
Function turningDirection$( currentBearing, targetBearing )
; Pre: 0 <= currentBearing < 360
; 0 <= targetBearing < 360
;
; Post: Returns which direction the bot should turn in
; to get from its current bearing to the target
; bearing
If currentBearing = targetBearing
Return "Stay Still"
Else
If currentBearing > targetBearing
targetBearing = targetBearing + 360
Endif
; At this point, currentBearing < targetBearing
If targetBearing - currentBearing < 180
Return "Clockwise"
Else
Return "Anti-Clockwise"
Endif
Endif
End Function
|
| ||
More code as I'm bored: (Adapt as required)
; Assumes bots are structured by type Bot,
; with fields curBearing, targBearing and rotSpeed
Function rotateAllBots()
; Pre: None
; Post: Rotates all bots towards their targets
For b.Bot = Each Bot
; Performs rotation
Select turningDirection(b\curBearing, b\targBearing)
Case "Clockwise"
b\curBearing = b\curBearing + b\rotSpeed
Case "Anti-Clockwise"
b\curBearing = b\curBearing - b\rotSpeed
End Select
; Standardises the bearing so that 0 <= bearing < 360
b\curBearing = (b\curBearing + 360) Mod 360
Next
End Function
|
| ||
| (Answering to a post in the previous thread on the subject) Problem is that costs money, and as such would make people that don't have BVM incapable of working on the engine unless you want everyone to shell out cash to work on a community project. Also I am actually pretty flexible and a single license for a small team is OK for me. Just don't abuse it and pretend you have a team of one hundred persons. Certainly it would be a problem for an opensourced project like this where the team is actually entirely open (...but read my offer below). I must say I am very much willing to donate a full license restricted to be used only on this very specific project. It would promote BVM as well as giving me a very valuable feedback. In the same time BVM users would benefit from a complete example to learn from. All I would have to do to discourage people from abusing it would be to add something like a 2 seconds long splash screen stating something like "Featuring BVM, BAIT edition. This edition may only be used in BAIT", plus a note somewhere in the docs stating that you are using BVM, with a link to the site. No more. If a splash screen *before* the game itself loads worries you, it could be done as an additional funciton that you need to explictely call to unlock BVM, and that displays the splash screen. So that you can have it displayed when *you* chose, between the start of the game and the first access to BVM (for a better integration). If that sounds OK for you, please contact me. Note: it is very doable to use BVM in a non blocking way (read: with timeouts) if you need it. |
| ||
| I am greatly interested by your offer Koriolis. What does everyone think about this (WolRon especially)? |
| ||
| I don't have time to look at it now, maybe later. Note that per the Code/Media file structure outlined in Coding Conventions, the source code to BAIT was going to be distributed with the game. I don't know if this affects BVM... |
| ||
| Not really, as the core of BVM is in a DLL, the BlitzBasic code that goes with it is mainly some needed glue, and some helpers. Though I didn't included the main BVM .bb file in the list of freely redistribuable files, this was more because there was apparently no need to, rather than for any real problem. Keep me informed then. |
| ||
| That's a very generous offer with BVM, Koriolis :) Okay... Some functions we could use? Much of the data on another bot should only be picked up when it is scanned - that's obvious. Now, more data that would of use to be recieved from a scanned bot are (not only to make AI coding a bit easier by relieving the boring bits, but to speed along the whole thing) are: Direction it is facing Position in relativity to bot (not global) Speed that it is moving (hey, maybe the speed of bots could be affected by their damage, so the AI could figure out health itself?) (already said this actually... I think.) Estimation of noticeable damage. Is firing weapon (note: Only returns a value other than false when the weapon would be clearly visible... AI has to figure out when the last time was on its own). It returns (when it doesn't return false) which weapon is fired (EMP or machine gun, and other future weapons.) Here's another thought: Scanners can not scan through walls unless the bot is pressed against the wall - Only 1 scan every second can go through the wall in that case. (Good for hiding stuff). |
| ||
| That's a kickass offer, K. Definately something to keep in mind! Speed that it is moving I don't vote for that one. I think that's something AI should work out for itself ;] Scanners can not scan through walls unless the bot is pressed against the wall I like that. |
| ||
| Oooh. The main reason i didn't get involved in this was that i figured you'd never make an interpreter.... Anyway, as far as using BVM, we could develop on the demo (same as the actual thing sept with time limit), and koriolis can pop in the full. I've been sort of playing with the idea for doing the same thing except in bmax. I'll contribute code where possible. b2d? b3d? b+? |
| ||
| Well, I've done some work on the Weapon.bb file (and some minor work on some of the others). I'm trying to finalize the Bot Specifications. We need to settle on a method for Scanning. Scan? Yes or No If Scan, how to scan... 1 scan does it all? Seperate scan for each object? Seperate scan for each direction? Seperate scan for each object and direction? Scan through walls? Don't scan through walls? Let me hear your opinions... |
| ||
| 1 scan does it all - Mind rover has a thing called an IFF Filter. A similar function could be used on the scanned information to figure out what was scanned. Seperate scan for each direction (scanner needs to be somewhat smart to get much of use) with a width of maybe 30 degrees. Scan through walls (well... obviously I would say that). This would (as mentioned above) also incorporate a penalty for how long it takes to scan through the wall, etc. There's my vote :) |
| ||
| Speed that it is moving (hey, maybe the speed of bots could be affected by their damage, so the AI could figure out health itself?) I don't vote for this either. You should be allowed to scan a bot's health, but as Riot said, the AI a player writes should work this out. I don't think there should be a link between a bot's health and their speed either - that would make the end of a battle a bit slow and dull. Here's another thought: Scanners can not scan through walls unless the bot is pressed against the wall - Only 1 scan every second can go through the wall in that case. (Good for hiding stuff). Not nice! I think that would be very difficult to code. Which brings me onto my next question - how will the walls be 'stored'? As instances of a type, in which case the wall's co-ordinates would be used when scanning for walls, or would they be pre-drawn on the arena image, in which case something like the getColor() command would be used to detect walls? Regards your questions WolRon: Scan: Yes Seperate scans for each object: Yes (allows for more variety in players' AI) Scan through walls: Yes (restricting this would be difficult to implement) What will the scan's range be? A straight line or a radar-type scan? What if two or more robots lie in the scanning range - which one will be scanned? Ryan |
| ||
| Seperate scan for each direction (scanner needs to be somewhat smart to get much of use) with a width of maybe 30 degrees I'm afraid that this will just 'force' players to create a loop that goes from 1 to 12, scanning each 30° sector...All in all, I think that will be more tedious for the AI writer and the game engine both. It would most likely be more efficient to just perform 1 scan @ 360° or maybe (I'd say max.) 4 scans @ 90°. I don't vote for this (Speed that it is moving) either. You should be allowed to scan a bot's health, but as Riot said, the AI a player writes should work this out. I don't think there should be a link between a bot's health and their speed either - that would make the end of a battle a bit slow and dull. I totally agree. Perhaps the bot doesn't need to 'scan' for health, perhaps it could know if it got a hit/miss and then use some of its user variables to keep track itself of probable health. What will the scan's range be? I was thinking that if scans were seperated between different types of onjects, then scan ranges could also be different. A straight line or a radar-type scan? I don't follow this... What if two or more robots lie in the scanning range - which one will be scanned? In my previous thinking, I was suggesting that only (say) 4 of the nearest objects positions (or distance & angle) are returned. |
| ||
| I have tried to read through all the posts so I hope this suggestion isn't repeating someone elses ideas. I think it would be beneficial to specify a function prototype that the Game Engine will call for each players AI routine and what objects will be passed. Example: Function Bot1_AI%(Status.World, Player1.Bot) In this example, the status of the Game World, and Bot1's object reference are passed into the AI routine. The AI routine is allowed to look at the Status.World object but not modify if. It then makes any changes to the Player1.Bot object and passes it back to the Game Server for processing and rendering. The Fields of the World and Bot objects should contain all necessary info for the routine to calculate what it needs to do to complete it's goal. IMHO |
| ||
| How bout a scanner where you set the degree range to scan, it takes a number divided by this to find the distance. for instance, 360: 20 degrees - 360/20 = 18 meters 30 degrees - 360/30 = 12 meters 45 degrees - 360/45 = 8 meters 90 degrees - 360/90 = 4 meters 180 degrees- 360/180= 2 meters 360 degrees- 360/360= 1 meter Perhaps a bit higher bias could be set depending on how big the scenarios are. Here's my idea for an example botai: Global ScanAng# Function Init(out.output) out.ScanRange=20 End Function Function Main(in.status, out.output) If in\ScannedEnemy Then If in.ScanAngle>3 Then out.LeftMotor=100 out.RightMotor=100-Abs(in.ScanAngle) Elseif in.ScanAngle<3 out.RightMotor=100 out.LeftMotor=100-Abs(in.ScanAngle) Else out.Shoot=1 EndIf Else ScanAng#=ScanAng#+20 EndIf out.ScanAng#=ScanAng#-in.BotAng End Function |
| ||
| Regards the straight line / radar scanning thing I meant will the bots only be able to scan in their "line of sight", or can they scan anything close to it regardless of whether it can "see" it or not? Thinking about this, the latter method seems much better. I was suggesting that only (say) 4 of the nearest objects positions (or distance & angle) are returned I'ld only return info about the nearest object. In most situations a bot would only want to interact with the object nearest to it, and this allows players to implement the tactic of hiding behind an object to prevent itself from being scanned. I think it would be beneficial to specify a function prototype that the Game Engine will call for each players AI routine and what objects will be passed. So do I, and I believe this is where BVM comes into play. What's been decided about using BVM WolRon? Ryan |
| ||
| Just saw your code Bot Builder (ironic name) - nice, but I think that would involve a fair bit of nasty maths. For simplicity, I suggest a 360 degree scan of a fixed length is always made, and the nearest object in range (if any) gets scanned. What do others think? Ryan |
| ||
| I've had a few thoughts about the number of weapons that a bot can carry. In the Bot.bb file, I've just arbitrarily set the number of weapons a bot can carry to 10 (Field Weapon.TypeWeapon[9]). But then after looking over the Bot Weapons weights, I realized that a player could set up his bot with 10 machine guns (totaling 5000 bullets) because the total weight would only equal 500kg. This may/may not be desirable... So, I would like your input on what (if anything) to do about this. Here are some suggestions: Limit number of weapons carried to a lesser number (say 5, or 3, for instance) Let stay at 10 weapons, but limit only 1 (or 2, or 3) of each weapon. Leave it the way it is (10 weapons total, any number of any weapon). Let me hear your thoughts on this topic. ----------------------------- Seperate topic: How many weapons (if any?) can a bot start out with? Can they start with the maximum allowable (by weight), if they choose? Should they be FORCED to pick up additional weapons if they want multiple weapons? Does picking up a 'PowerUp' add a weapon to their inventory, or does it just add ammo (or both?)? Should we have seperate 'PowerUps' for weapons and ammo? Let me know your thoughts on this topic. |
| ||
| By the way, I've been looking into BVM for use in BAIT. I'm still doing some research on it (since I knew nothing about it before now), but at the moment, it's beginning to look like something that may prove very useful. I'll let you know more about my thoughts on it in the near future... |
| ||
| 3 weapons max of any type. How do they choose which weapons they pick? Simple : Each player is given a certain amount of money, and they purchase what weapons they want, if they can afford them, beforehand. This 'shop' routine can be incorporated into the AI scripting program. However, I would not suggest the idea that you gain money if you win a round, otherwise the strongest bots will win everytime. I think there should be powerups, but none of these should concern weapons or ammo. These powerups could do things like restore health, freeze the other bots for some time, cover the arena in glue etc. To restore ammo, there should be fixed "charge-up zones" placed on the arena which you can use by moving onto them. We still haven't finalised the topics of scanning and using BVM yet (see my previous posts). What do people think about this? WolRon, this thread is quite large now - I suggest you start a new thread, with a very clear, precise "to do" list at the top, along with a list of what has already been finalised. For the code part of the 'to do' list, instead of using the names of the potential files, break it down into as many functions as you can think of, e.g. "rotateBot()". I know you've already specified coding conventions, but I feel it would be easier to work on the code if, for each function, you specify: 1) What parameters it takes 2) The function's pre-condition i.e. what can we assume about the program's state / the values of the parameters, e.g. 0 <= angle < 360 3) The function's post-condition i.e. what the function should do. See my previous posts on this thread for an example of pre and post conditions. Ryan |
| ||
| How do they choose which weapons they pick? Simple : Each player is given a certain amount of money, and they purchase what weapons they want I don't feel this is really necessary (unless others do), since each weapon has a weight associated with it (that could just as well be treated like 'money', in other words, you can only buy so much = you can only carry so much). WolRon, this thread is quite large now - I suggest you start a new thread I will, once the number of posts has passed 100... with a very clear, precise "to do" list at the top, along with a list of what has already been finalised This is already implemented. When I start the new thread, it WILL be at the top. For the code part of the 'to do' list, instead of using the names of the potential files, break it down into as many functions as you can think of, e.g. "rotateBot()". Not a bad idea, but the problem with that, is that "I" DON'T KNOW what all functions we will need yet. Let me think about how to handle that... I know you've already specified coding conventions, but I feel it would be easier to work on the code if, for each function, you specify: 1) Already specified in the coding conventions as Parameters:1) What parameters it takes 2) The function's pre-condition i.e. what can we assume about the program's state / the value of the parameters, e.g. 0 <= angle < 360 3) The function's post-condition i.e. what the function should do. 3) Already specified in the coding conventions as Purpose: 2) I don't think any function should ASSUME anything. This leads to potential runtime errors (crashes). I feel that all functions should perform their own error-checking (within reason). I may adjust the coding conventions to reflect this... |
| ||
| I like the money = weight idea, but we'll still need some sort of shop function to allow players to choose what weapons they want. Of course, some functions will have to perform some error checking. For such functions, the post condition should clearly outline how the function should handle errors. However, it's a good idea to use preconditions and to assume that what is passed into a function is valid as it makes coding the functions easier and promotes a modular approach. There would be other functions which would ensure that such preconditions are met. For example, imagine 5 functions take in a bearing as a parameter. Without the precondition 0 <= bearing < 360, each function would have to check that the bearing is within this range. With the precondition, we can assume this holds and we wouldn't have to worry about error checking. Later on, we would make one function that would ensure that this pre-condition is met. Pre conditions make life much easier, trust me! Regards working out what functions we need, we can do a brainstorm. Work out what the main aspects of the game are (a script interpreter, arena rendering, a league table etc.) then work out what sort of things each aspect of the game needs to do in order to function properly. For example, one of the game's aspects is the league table. For this to work, you'll need functions like SortScores(), DrawScores(), SaveScores(), LoadScores() etc, each function having its parameters and pre & post conditions clearly defined. That way, someone who hasn't been following this project can write code for us by just following a function's specification. For example, anyone could code this just by following the function's specification: Function GreatestCommonDivisor( number1, number2 ) ; Pre: number1 > 0 ; number2 > 0 ; ; Post: Returns the greatest common ; divisor of the two numbers End Function I will, once the number of posts has passed 100... Oh come on! The sooner the better!Ryan |
| ||
| To side track this thread a little : How do bots die? Is it a peaceful death, small explosion, peaceful/leaves weapon or ammo pickups behind or (my personal favourite) when a bot dies, all it's ammo goes off in one big kaboomy. Heh heh heh. it's beginning to look like something that may prove very useful. Replace the word 'very' with 'extremely' and you're getting close ;] There are some caveats (especially if you havn't used the system before) but the vast, vast majority of them can be worked around/with and if worse comes to worst, the BVM forums/Koriolis is -always- very helpful! we'll still need some sort of shop function to allow players to choose what weapons they want. BotInit() or BotCfg() or whatever is a given. Also would be a good place to initialise variables or types that you want to use within your script. Everything in this function should be considered 'weight free' commands (except for the weapon choices obviously)... Oh come on! The sooner the better! Patience is a virtue? ;] |
| ||
| How do bots die? Is it a peaceful death, small explosion, peaceful/leaves weapon or ammo pickups behind or (my personal favourite) when a bot dies, all it's ammo goes off in one big kaboomy All good ideas, but I feel that to not make this project grow out of proportion, that no more than an explosion will suffice for now. BotInit() or BotCfg() or whatever is a given. Also would be a good place to initialise variables or types that you want to use within your script. With or without BVM, I also feel this is a good choice. Thanks for suggesting it. For example, imagine 5 functions take in a bearing as a parameter. Without the precondition 0 <= bearing < 360, each function would have to check that the bearing is within this range. With the precondition, we can assume this holds and we wouldn't have to worry about error checking. Later on, we would make one function that would ensure that this pre-condition is met. Pre conditions make life much easier, trust me! What is everyone elses feeling on this? I think code reuse is always a good idea, but I'm just not sure how practical this will end up being (another function just to ensure the pre-conditions??). Regards working out what functions we need, we can do a brainstorm. Work out what the main aspects of the game are (a script interpreter, arena rendering, a league table etc.) then work out what sort of things each aspect of the game needs to do in order to function properly. By all means, Brainstorm. Let me see the results... For example, one of the game's aspects is the league table. For this to work, you'll need functions like SortScores(), DrawScores(), SaveScores(), LoadScores() etc, |
| ||
| Pre conditions yes, yes, YES! Trust me, they'll make work much easier. Going back to the bearing example, if we didn't have the pre-condition 0 <= bearing < 360, the person writing the code wouldn't know whether to error check the value or not. The combination of the parameters and the pre & post conditions make a precise, unambiguous function specification that anyone can follow and produce the code with. The functions that would ensure these pre conditions are met would usually only be small ones which can be easily tackled. If we define the functions as I did with my Greatest Common Divisor example, we'll be in business. I don't have time to brainstorm the functions and their specifications, but it's something that needs to be done before we put up the new To Do list. I'll leave everyone else to do this! Ryan |
| ||
| What is everyone elses feeling on this?(Pre conditions make life much easier, trust me!) Pre conditions yes, yes, YES! You aren't 'everyone else'... I don't have time to brainstorm the functions and their specifications, but it's something that needs to be done before we put up the new To Do list. I'll leave everyone else to do this! Of course... With the exception of the opinions being expressed in this thread (and I do appreciate those comments), it's interesting how the only name that's been posted after any of the ToDo list item's for work being done, is ... |
| ||
| I know, I'm sorry. What do others think about how the To Do list should be structured? |
| ||
| I feel that to not make this project grow out of proportion, that no more than an explosion will suffice for now. Fair enough <pouts> =] it's interesting how the only name that's been posted after any of the ToDo list item's for work being done, is ... I'm sorry too. I feel like I'm much too vocal not to do anything, but I don't have any time to -work- on this either. Don't wanna see it die though =[ What is everyone elses feeling on this?(Pre conditions make life much easier, trust me!) I think Ryan has a point. But I think instead of running a function that crops a value between 0 and 360, we should disable any scripts that don't follow the rules. |
| ||
| we should disable any scripts that don't follow the rules. If that's the case, then a lot of scripts will be disabled rather quickly! For example, a clockwise rotation will increase your bearing - a clockwise rotation from bearing 350 to bearing 010 is perfectly valid, but if we didn't have a function which standardises the bearing, then the final angle after rotation would be 370, so any scripts which require the angle to be in a standard range wouldn't be run. A program is 'correct' if all of its functions meet their post conditions given the pre conditions. So the number of bugs we could produce would be kept to a minimum if we specify our functions in this way. I know I'm the only one who's really promoting pre conditions, but it seems to be a bit quiet around here, so we need to get this project moving. Trust me, pre conditions will save us a lot of hassle. What we must do now is make a detailed ToDo list and start a new thread with the ToDo list at the top. I'll then make an announcement in the general discussion forum, asking people to help code the functions we've specified. Here's a starter section for the ToDo list: LEAGUE TABLE FUNCTIONS: Function SortScores() ; Pre: There exists Type Player with ; fields score and position. ; ; Post: Assigns a value to the position field of each ; player based on their score. The player with the ; highest score is assigned the value 1, the ; player with the second highest score is assigned ; the value 2, and so on. Tied scores should not ; be treated differently. End Function |
| ||
| Just noticed this thread and it looks kinda fun. As for the scanner thoughts... the script would allow two calls to the scanner. 1. setangle(min,max) would do what it says where 0 degrees is straight ahead. DoScan will return a list of ALL enemies found within the specified angles. The details returned will be distance, damage etc. It will NOT return the angle to the enemy nor any details of speed. It is then up to the AI to narrow down the scan angles to home in on the target. I would prefer it to return all the enemies found rather that just the closest because otherwise you could end up with a situation where you have almost destroyed player1 enemy then player2 moves closer and you end up losing player1. Anyways.. just thought Id throw that into the pot. |
| ||
| Hi QuietBloke, Just noticed this thread and it looks kinda fun Looks can be deceiving! Just kidding... Your idea would certainly make the game more realistic, but on the other hand, it would certainly make the engine more complex to write! If you could write such a routine for us though, that would be most appreciated. WolRon, I'm afraid I can't work on this anymore for a few weeks - I'll fail my degree if I keep working on this! By looking at your current ToDo list, it seems a fair amount of the code is already in place - keep up the good work. However, you must expand on the ToDo list and make it as precise as possible before you start the next thread, so that others who haven't been following this can help out when I make the announcement in the General Discussion forum. Thanks, Ryan |
| ||
| Well, I've been tinkering around with some ideas for the game. (FYI, I've been TRYING to test the possibilities of using BVM in BAIT, but in order to TRY, I basically have to have the game working already, so I've been hammering away at the basic elements of the game/code in order to get a bare minimum elements game running.) Anyways, I've come up with a few ideas for the game, namely, that each arena will have not only a different playfield, but a different objective (I didn't think anyone would object...). I've come up with a few objective ideas (Check the Arena specs. and Game Overview). They may/may not be good ones. Let me know what you think of them. In the same spirit, I've also been working on setting up the game so that the player could have a seperate AI script for each arena. And I've been trying to set up the game to be more modular by using .dat files in the Arenas/Weapons/Bots directories. These will allow the engine to know which files need to be loaded. The plus side to this is if we feel like adding, say, another weapon, we just simply create the associated media, and then add the required information into the weapons.dat file. No recompiling required. |
| ||
| If all of the bots are evading attacks, who is attacking? Or are we going with having complete game bots as well? |
| ||
| Good point. Maybe longest evasion time PLUS highest damage inflicted? |
| ||
| This is the 100th post! New thread time WolRon! If you wish, I'll make an announcement in the General Discussion forum to attract more helpers to the new thread. After that, I won't be available for a few weeks. By the way, did you get my email about the webspace? Ryan |
| ||
| Yes, Ryan, I got your email. I'll start the new thread soon. After that, I won't be available for a few weeks. I'm starting to not believe you... |
| ||
| If anyone reading this wishes to post, please do so in the latest thread: BAIT Community Project (thread 2) Can a moderator please lock this thread? |
| ||
| I'm starting to not believe you... He says that in -every- -pots- yet hasn't stopped posting yet. I'm thinking it's just a devious ploy to dodge responsibility ;] In case the project falls over, you can have the blame, if it takes off well, he can say it was all his big idea ;] I am of course joking, but, you know... freud and all... ;] |
   |