So, I was thinking today that what we really need is a standalone server app for bots. Even once we have "private" bots, that still won't be a perfect solution for testing because people need to be able to debug their bot, and that requires talking to localhost most of the time. The production server will never really fulfil that role.

So here's my idea.

Step 1: We open up some of the Host bot as an API. Create an ApiController that can take a gamestate object and PlayerMove objects and resolve the moves and return the new GameState object. Probably a few other API calls will be necessary that I'm not thinking about right now too.

Step 2: Create a .exe app or maybe just a static web page that people can download that calls this API. This app/page would allow you to test locally. So no one needs a copy of the server code, or needs to worry about doing
Migrations and other fairly advanced things just to get a simple test environment going. Or even needs Visual Studio if they (for instance) want to write their own bot in Javascript or Python or whatever.

I'm willing to do this, and I think it's pretty much necessary. So I'm giving notice that I'm about to start working on this and looking for any ideas/feedback before I really get underway.

There is no option in the UI to delete a bot.

In the GameState JSON, the players are identified as "p1" and "p2," but your'e told which player you are by color ("r" and "b"). You just have to know from outside information that p1 is always "r" and p2 is always "b". This is dumb, and we should change it in our implementation. We should either change the name of the p1 and p2 objects to be "r" and "b" or else add an identifier to the player class. So

"p1": {
    "energy": 0,
    "spawn": 5
  },

Becomes

"p1": {
    "energy": 0,
    "spawn": 5,
    "color": r
  },

Right now the game server sends a request to the bot server to ask it for a move. This requires anyone who wants to have a bot to be able to host their bot as a site. It takes a relatively advanced user to be able to code a bot, create their own site and host their bot. I think there is a better way.

We could have bots send a request to the game server to make moves and have the server respond with the next game state. If the bots request to make the move then we could have bots that are entirely browser based.

I'd like to see us going in the direction where anyone can hit F12 in their browser of choice and start making changes to code that they can then see instantly reflected in the way their bots play the game.

We need to allow the server to be capable of running multiple games at once. Since the bots might have to be playing to multiple games at once, we should also introduce a "GameId" string in the game state, so if someone wants to implement some kind of learning algorithm, they can. Otherwise, the bots would always have to be stateless (or else get confused by multiple simultaneous games).

A systems development life cycle document is something we can use as we develop this application to guide us as to what process to follow for designing new features, prioritizing what to work on, how it should be implemented and maintained. Specific questions to address are how we should handle branching and merging for source control.

I'm creating an issue for each server-related item outlined in Milestone 1.

I actually got a bit of this working now on the Battle Controller. The game does now recognized a win. But the webpage doesn't really show "Winner!" or anything like that. It just stops unceremoniously once all the bots of one side are dead. Definitely needs further work.

So, I was going in to update the Instructions section of the website with the information on our GameState class. (what's there now is pretty much just the Skookum information, but our object is slightly different). But while I was there, I saw two things that made me go "Hmmmmmmmmm." So, two questions:

First, what is the "turnId" field for? I wanted to note in the Instructions if a field existed but just wasn't in use yet (like the Api Key), but note what it would be for in the future. But I'm not sure what the "turnId" field is for. It's not the turn number (that's turnsElapsed).

Also, does anyone object to me removing the "NullValueHandling = NullValueHandling.Ignore" property on the "winner" field? I know Patrick had to put this in because Skookum did it that way, but we don't have to do what Skookum did, and it shouldn't affect any existing bots. I'd rather pass "winner = null" if there isn't a winner than that field just be missing altogether.

Steps to reproduce

1. Create a bot, make it public.
2. Edit that bot and attempt to set the private flag
3. When Save is clicked an error message is received: "An error occurred while processing your request"

Expected Results

The changes would be saved and a success message would be displayed.

To really get this going, we need to have a web interface, where people can sign up and register their bot. Your basic username/password combo. I'm also thinking the user should be able to give the server a "secret token." This would just be a string that gets passed to the bot in each move request and is just the server's way of saying "I'm the real server." That way we prevent "spoofing" the server by other bots (unless we want to allow that...? Nah.)

After that, users would be able to go to the front end, log in, pick a couple bots, and have them fight.

I'm up for doing all of this design, but I wanted to get feedback before I started. So this is just be percolating some ideas.

Yeah. Kind of a big one. :)

I created a failing unit test.

There should be a skirmish creation screen where a user can start a battle between two bots of their choosing.

One selection may be limited to their own bots or both their bots and system bots.

For the other selection a user should be able to see a list of the public bots.

The list should be reasonably sized, so after the potential list grows to long it should be a partial list. If the list grows too long we should limit it somehow, perhaps randomly until we reach the point where we need to consider better solutions such as grouping them into categories.

The lists should maintain a user's privacy

We should never expose the URL of a bot unless the user who created it asks us to. We may even not want to expose consecutive primary keys for bots because that could open up potential ways a user can infer the id of a bot that is not public, rather we can create temporary references to the bots using something like a shortcode generator. The shortcodes can reference the public bot, but be changed when the privacy settings for a bot are changed.

The Skirmish settings should be configurable

Things like start time, and time between moves can make it easier for the battle to be viewed. Privacy settings can prevent the battle from being viewed by everyone, or allow it to be published as a public event from elsewhere in the site.

Once two bots are chose the user can launch a battle

The battle room should have a Signal R setup where people can watch the battle live from various machines. The URL for the battle should be a randomly generated id.

Energy can spawn on bases and prevent new bot spawning. I'm thinking that shouldn't happen. Anyone want to chime in and say that's desired behavior before I fix it?

I've noticed bots spontaneously disappear when no other bots were anywhere around. I noticed that there was energy in the square next to the bot when it happened. I suspect it may be an issue resolving what happens when the bot should be picking up energy. When it happens there is no indicator showing the bot's demise, merely the energy that the bot should have collected.

I'm creating an issue for each server-related item outlined in Milestone 1.

This was included in the stuff I pushed that messed you guys up Thursday (sorry about that again!). We don't have the ability to upload DLLs, but I'm not sure if that's even feasible in the short run (once you let a DLL run in local code, the amount of malicious things you could do to win the game increases to nigh-infinity).

Patrick/Keith, does any more work need to be done on this? Or can it be closed?