Some Ideas for Game Plan

[paulkass]

Hey guys, I was thinking of some changes to the plan of the game. Here they are:

1. Have a MVC implementation. Have some sort of SQL database be our model, the server scripts be controllers, and the client to just act like a view for the user to interact with.
2. Flowing out of point 1, all of the parameters like map size, the extent to which a player can see his surroundings, possible moves for the player, etc. should be all provided by the controller (i.e. server). That way players will only need one client to connect to many different servers hosted by many different people.
3. Let's start with the client being a simple command line program. That way we can work on the server code faster and get it up to speed without messing around with graphics that might not even work out as we expected.

Let me know what you guys think.

[possibly]

Ha! I totally forgot this thing existed!

Thinking about what made me excited about this project in the first place was the idea of a game focused on being played by AI created by the players from the get go. Most games provide some stock bots (think AI in StarCraft), but its never the focus of the player to actually create the AI. It would be so cool to have a very simple way of helping players create AI and unleash them in a world.

Initially I think Gani and I had the idea that we would have a MMO-like server that had rules, and players would just unleash their personally scripted AI into that world whenever they wanted to. Looking at your point #2, I think it would be even more fascinating to encourage people to host their own servers with there own special rules.

It would be interesting to see people given a simple tool that allows them to expose 1) game rules (ex: you can move here) and 2) game states (ex: these are the places you can move at this moment) over some medium like the internet/intranet but does not limit the full expressive power of any given programming language. I would like to see a game made by one group of people that is a classic RPG-style game, and a game like Poker made by a different group of people, but both use the same library to expose the rules and game states. The vision is to enable the making of games that are easily playable by AI by giving programmers the set of tools that do a lot of the grunt work for them.

[possibly]

More thoughts: maybe just specifying a convention of transmitting data over HTTP is enough. Consider a convention that gives a bunch of rules on how a server should transmit basically two types of information: game rules and game state. An example of this convention being implemented would be the following JSON file:

{
  "GameState": {
    "Board": {
      "Left": "Monster",
      "Right": "Empty Tile",
      "Up": "Empty Tile",
      "Down": "Empty Tile"
    },
    "Health": 20,
    "Action Points": 2
  },
  "GameRules": [
    "Move Up",
    "Move Left",
    "Move Right",
    "Move Down",
    "Attack",
    "Defend"
  ]
}

idk how to make this convention flexible enough to actually encompass many different types of games.

[possibly]

Maybe instead of making a game generator, just focusing on making a game that transmits its details through http requests would be a fun exercise. I remember now that the ultimate goal was to make a simple game that everyone at the Coders Club could play by writing a bot in any language they wanted.

These people did something similar: http://theaigames.com/#. If you sign up you can see a lot of specifics on how they expose game state to the players' bots, its rather interesting.

[paulkass]

@possibly That's kind of what I am doing. All of the information about the game is stored on the server, and the client will only have access to specific information about the game through http. So clients just need to use HTTP requests to access information and do whatever they want, be it creating a UI for a potential player of a bot.

[possibly]

@paulkass

I think using http as a communication layer presents a unique set of challenges when actually designing a game that we need to think through.

Consider the difficulty of making a turn based game using http as a communication layer. In a typical client-server game model, the server "pushes" out notifications to each client when it is there turn. When using a http communication layer, there is "no way" for the web server to "push" updates to the client when it is there turn.

Other game systems, in contrast, would be well suited to the asynchronous style of the web. Consider "real time" games. Clients send/receive requests to/from the server as quick as they can, and the faster the better!

The way we design the game is inherently affected by the way we design this application. Its probably a better to design the game now, and then build the code to accommodate that gameplay.

[paulkass]

@possibly I am thinking of a real-time game. However, real-time games present a challenge with spammers. So I was thinking of putting a cooldown on trees (~5 mins.) and players(~10 sec) for each move.

[possibly]

@paulkass, I glanced around the internet and found a really simple option of a way to limit player actions with a concept called (simply enough) rate limiting. We could also provide a "requestTimeout" node in the http payload with a integer value in ms that indicates how often a player should send a new request.

[possibly]

Also, I was just reading the game design doc again and its pretty good. In terms of an artificial intelligence challenge, the game so far is mostly 1) pathfinding (depending on the info we expose to the client) and 2) prisoners dilemma analysis (which could be made easier or harder based on the information we expose). Its a good start, and really easy to expand on. Also, real-time with request limit seems like a good option for this game.

[amixtum]

I like these ideas. There doesn't seem to be clear a clear direction for this yet, but it's exciting.

The interface for the programmer to "talk" to the game could be an api written in python/node/etc. that wraps up the problem of making http requests and using the proper data format in a neat set of functions/objects.

Also do we really have to use node? I think the process of writing a server would be much simpler using something like Flask, in addition to python's request libraries.

[possibly]

@amixtum word up on Flask! By far my fav webserver library for Python.

We have two primary issues here that I think I will break out into two separate threads. 1) What language and framework should we use and 2) what are the rules of the game we are trying to make and what unique challenges does using http as a communication layer present when making that type of game.