Totally Deprecated Concept To Follow
I was just about to start coding this last week when I got really sick and then couldn't do anything. I literally spent a few days in a row focusing on each breath with my heart racing the whole time and now I am in the hospital.
I had already typed up this description of it and had planned to get it working well so I could share the code freely with everyone that wanted it. Now it is all useless, thankfully, because the super awesome devs added the feature to the map editor (actually, there might still be some useful thoughts on initializing units if you can figure that out somehow).
The Old Idea - Refactored To "Don't Read Me"
There were no options yet on the map editor. So to hack it together without having to build your own map editor the following is what I was building. Oh and no, not the cool l33t kind of hacking but the sloppy hack it together or being a hack at something sense of the term.Before Switching To A Robot Type And Looping Forever
Set up a map building routine that says, if I am Team A, I am going to build these troops and place them at these locations and then tell them to wait (aka auto yield) until I note that all troops are ready for the match to begin.
The same routine can have a check for if it is Team B and have its own list of troops/locations/inits. When you know everything will have had a chance to build you can start the game.
Call this routine from your main RobotPlayer.java class and hop out of it and on to your normal stuff as soon as everything is built/initialized. Use the broadcast array to organize a bit and flush the array back to zeros when done.
The Limitations
There are a few over-sites with this, it won't play out exactly as your bot normally would because normally they would have had time to do things, learn stuff and be hurt by the time they got to that position, but it will still work out nicely for testing your micro fights within the map. Also you loose overall rounds that are possible, so however long you took to setup that map will cut from overall play time but in most cases when doing this you are really more interested in micro fights and testing how they play out anyway, so it works.
Unlimited Bytecode
This will never be used in your final bot for actual fights, so you can drop all of this code in debugging functions and not have to worry about any bytecode limits as you are setting up the map.
Storing Units And Location List
I was making two multidimensional arrays. One that Team A would chew through and one for Team B. This way you could have the same RobotPlayer.java play both sides if you wanted. Technically it could be done with one multidimensional array and an extra spot to denote the team, but I like the clarity of splitting it out so later on copy and pasting preset spawn groups is easier and especially easier if you plan to use inits described later on here.
The array would hold types needed and a sub array for location or location paths. The location could in that way be a list of x/y points to make way points or just one final x/y point to go to. Doing that skips any pathing code because we know the maps we will be using this for. If it is a clear walk from spawn to their starting position they only need that one location. In the case you need it to move around trees or other spawned bots you can give a locations in order for it to step through on the way there. Thus, no pathing headaches.
The array would hold types needed and a sub array for location or location paths. The location could in that way be a list of x/y points to make way points or just one final x/y point to go to. Doing that skips any pathing code because we know the maps we will be using this for. If it is a clear walk from spawn to their starting position they only need that one location. In the case you need it to move around trees or other spawned bots you can give a locations in order for it to step through on the way there. Thus, no pathing headaches.
The last piece of data I would denote in the arrays for each bot is a switch case integer. This is optional and could be used to overcome the limitations listed above. Actually, I'd have to get pretty creative but this could probably still be used in conjunction with the new map editor that let's you place units.
Taking It Up A Notch
Then I was going to make it possible to follow up with some optional code to initialize some or all of the bots. Meaning once all bots were in place I would step through the arrays and look at the switch case integer if given.
Using that I would switch to different sections of initialing code. That could be crudely written, copied chucks of code or specific function calls to get trees built around it or to inject some information that it needs and should have learned on its own by this point. These calls could do some things this bot needs to have already done so that I can properly test a micro fight.
Dropping The Starting Flag And Flushing
I would probably use the broadcasting array as a way of organizing the bots for each team. So I would grab the first set of spots and claim them for things like map information, number of each unit type needed and whatnot. Of course not having to worry about any kind of conservation, knowing I will flush the broadcast before staring the match.
After those channels I would have a set representing the array index positions for the team, no matter if it is A or B here because they won't be seeing each other's channels so they won't overlap. The first bot listed for either team in the array would be at broadcast channel number 0 + OFFSET the second 1 + OFFSET and so on; where the offset is however many channels I used up for the beginning block of information mentioned above.
Each time a bot is built it can be enlisted to one of those spots in the broadcast array by raising the flag at that position if it was the first bot of the correct type to see it was still needed. It can also decrement the channel integer corresponding to the number of that type of units needed to be enlisted still.
Process Summary
The basic overview of that process would be to build bots still needed, enlist them by claiming a spot in the broadcast, move them to position, and set the broadcast integer to denote that it is in the starting position and ready to init. Continuing to make any bot initialization as needed, if started before all positions are taken, trees can help save rounds here. Finally once all bots are made, in place and initialized we will raise the starting flag so to speak and flush the broadcast array back to all zeros.
Getting Teams To Talk To Each Other
The only (ok, another) wonky part to this is that you will need both teams to start at the same time still, both teams that can't see each other. To do this you'll need to run it once to see how many rounds each team takes to finish the setup process. Whichever one takes longer you will need to hard code into the function as your starting round (the round after that actually).Stop Staring At Me Swan
No seriously, lol, why are you still here? The super cool devs already added this to a newer version of the client viewer. Go there. Enjoy it..... but thanks for reading.
