Game State/Multiple Games

[Pharylon]

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).

[Dubman25]

I think these are all good ideas. The existing server made by skookum did
most of what you are describing, it even had a nice tournament interface.
I'm not suggesting we use the node server long term, but we may want to get
it back up and running to steal some good ideas.

We also discussed a few interesting possibilities of parallel play, like
the fact that the server could play an entire tournament, every match
simultaneously, by simply accounting for every possible outcome of each
starting match up and potential match-ups. It would even be possible to
simultaneously play every game from every possible tournament, by
calculating all the possible starting match up combinations and playing all
potential games of those tournaments. Given the random nature of food
appearance, I think averaging the results of a series of tournaments to
determine the overall winner would smooth out fluctuations in the data and
help pick the superior bot. But, the idea of getting lucky once or twice
and squeaking out a win could also be fun.

As for the gameId, I think there's appeal to both having it and not having
it. As we were working on the first bots months ago, the challenge of
tracking game state based on the board was very interesting to think
about. The previous requirements of the bot not knowing which game a
request would come from or even how many different games the bot might be
playing simultaneously wasn't unwelcome, but no one to my knowledge had
tome to code a tracking and identification algorithm. Leaving the game id
unknown might create an interesting 'second level' of sophistication for
down the road. Just a thought.

I'd like to see if we can coordinate and share the coding work, rather than
each run off and do our own things with different pieces. But I can
appreciate just wanting to get stuff done too. I'm ok either way. I'm
currently just looking through the server code to see how I can get some
real bots hooked into the server. So I like Zach's suggested next step of
registering bots with the game server. I also like the idea of two modes
of competition: honorable and hacker, without and with exploits
respectively. I'm very interested in making this as much of a leaning
exercise as possible. My next priority after learning is just to have some
good clean coding nerd fun. What do you two think?

Dub

On Tue, Oct 7, 2014 at 9:13 PM, Pharylon notifications@github.com wrote:

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).

—
Reply to this email directly or view it on GitHub
https://github.com/Pabreetzio/BotWars/issues/4.

[Pharylon]

I can see not having a Game ID, but I don't think having the bot work out which game this turn precedes is a particularly "fun" problem. Also, I think we should make it easy on the bot logic for now in the beginning (especially as a learning tool for newbies). I say we just make it easy and provide the ID, at least for now.

I say "for now," because one idea we can talk about is, if this thing is a success and we get interest we can create "seasons" in the competition where we vary the rules to keep it interesting. We could do 2-4 seasons per year where we mix things up. For instance, we could introduce walls, or have three bot free-for-alls, remove the Game ID, allow "malicious" play with attempting server spoofing, etc. There are lots of things we could do to keep it interesting. Just an idea (and not necessarily strictly relevant). :)

[Dubman25]

I was unaware that this effort was targeting "newbies". Maybe we should spend some time discussing what the goals of the group are. They may have already been established, but I missed that part of the conversation. Maybe we can discuss before or after the deep dive this Thursday?

Not too put to fine a point on it, but just because one person doesn't think something wouldn't be fun, that doesn't make it not fun right? It just means that person probably wouldn't do it. I'd like us to state our opinions in terms of the potential participants if we can. As I mentioned before several coders participating last time specifically said they thought it an interesting challenge (not fun exactly, heck is coding a node bot actually fun either? Maybe not, but we want to do that too). These coders were advanced, similar to the deep divers, which I thought we were targeting. Now when you reframe the participants as 'newbies' even without knowing precisely what that means, I can imagine the challenge of distinguishing game states might draw less interest from such a group.

Just trying to keep the conversation as open as possible.

Keith

On Oct 8, 2014, at 8:26 AM, Pharylon notifications@github.com wrote:

I can see not having a Game ID, but I don't think having the bot work out which game this turn precedes is a particularly "fun" problem. Also, I think we should make it easy on the bot logic for now in the beginning (especially as a learning tool for newbies). I say we just make it easy and provide the ID, at least for now.

I say "for now," because one idea we can talk about is, if this thing is a success and we get interest we can create "seasons" in the competition where we vary the rules to keep it interesting. We could do 2-4 seasons per year where we mix things up. For instance, we could introduce walls, or have three bot free-for-alls, remove the Game ID, allow "malicious" play with attempting server spoofing, etc. There are lots of things we could do to keep it interesting. Just an idea (and not necessarily strictly relevant). :)

—
Reply to this email directly or view it on GitHub.

[Pharylon]

Totally. Nothing has been established yet, and us talking about the goals is certainly something we need to do. It's part of the reason I've been opening these issues. So we can discuss. ;) But I know the idea was some of the "Deep Dive" people would be doing bots, and I would probably call several of the people at the meeting last Thursday a bit newish.

As for enjoyment... yeah, I'm enjoying playing around with one. I really don't like the idea of trying to associate past requests with future ones without a game ID, and it seems like a really easy way to launch an unsophisticated attack on another bot (start 10,000 games with them, and make it that much harder, especially if you're trying to work back three or four moves). Although I suppose that's something we could handle server-side too. Maybe only let one user have one game going at once.

That being said, other people might find it fun, and whatever is the most fun to the most people is what we should do. Just tossing out ideas. Treat anything I say about what we should do as something you can argue with me about and I won't take any offense or anything. I just want to talk about it. :)

[Pharylon]

The Game ID is now included (I needed it for the API), but you still can't really play multiple games.

[Pharylon]

I'm thinking a cool feature would be the ability for each user to have a sort of "session ticket" that they can give out. If someone then goes to aibattleground.com/Battle/myTickedId they can then just passively watch a match. Not useful in the short term, admittedly, but if this thing takes off it might be a cool feature for people to be able to watch tournaments remotely. I'm not sure how difficult that would be with SignalR either, but I don't imagine it would be too difficult.