Breaking up the project.

[hallister]

We eventually need to decide how to break up this project into manageable pieces. I was talking with @cawaltrip after class today about it, but the more ideas we throw around the better.

My thought was splitting up into Server and Client teams. This implies the game will be networked rather than hot seat (have to be at the same computer to play). Any other ideas?

[rangera]

Gui, and other component differences makes sense to me. Also, rebel vs empire could be valid depending on how different the actions are

[hallister]

@rangera I was thinking more about how to split up the repositories. If we go the Client/Server approach, then we could have a repository for the client, one for the server and offer them as separate sub-projects, or include the server in the client transparently.

I suppose I should mentioned the main interests in going a Client/Server approach. With a Client/Server approach we have the ability to add several interesting features:

• Game Finder system that matches people of a similar level (assuming we use a centralized server model).
• Could add various in-game achievements (assuming we use a centralized server model)..
• Makes multiple players vs multiple players implementation rather arbitrary.

Of course, Client/Server could still be local so this doesn't imply that we couldn't also do an AI/Single Player without a computer. But I'm just tossing ideas around :smile:.

[andyleejordan]

Before we try to break off, we should split this into layers

So here's my assignment 1 work of detailing the FSM with represented objects, states, constraints, and interactions here. I'm going to post my 3am (that's bold because this was typed originally on my phone, it might have some really terrible mistakes) inspiration last night here:

Entire state of the game is just text. Represent it as a JSON object of textually represented objects of state, with a dynamic game object, player object, controller object (for multiplayer, that takes control of a certain equally divided subset of units per human player, for each game side), with methods for state transitioning, interaction calculations, user I/O, that then encode the changes into the JSON object (which keeps track of game-turn chain and timestamp for majority-rule based peer-to-peer networking abilities), passing around via 0MQ for networked gaming, or to an AI. User I/O abstracted to interface for either text, graphics, network, AI interaction. JSON state object has metadata to track current substate, in addition to entire game-state. Finite state machine turns into a directed, cyclic graph traversal problem (with plenty of algorithmic solutions) with a counter exit trap. Also, P2P network is decentralized, that is, each computer is both client and host, and agrees on game-turn chain. Which could be hashed for integrity.

Large subset states with sets needing to be recorded (such as units, environs, etc. considering the 400 pieces and 132(?) cards) will be identified by key in the JSON object, and the specific static information for each card/unit will be loaded into objects stored in sets, referenced by key. For identical pieces, this allows for data-deduplication in the JSON object by simply pairing a key with a quantity. Also, updating the JSON object is done incrementally.

Pros

• State is really easy to represent
• Text manipulation is not going to be our bottleneck
• It separates game logic from user interaction
• It eliminates the need for separate host/client configurations
• I think I could get a basic game engine going in a few days
• It allows very easy separation of work
• Other things outlined above in it

Cons

• It's not fully fleshed out
• Please point out any cons/pros you can find and how we could improve it

[cawaltrip]

I personally like the idea of using some sort of data object to represent the state (JSON, XML, etc..). Using a preexisting data model gives us access to all sorts of libraries to access/manipulate the object and much more experienced minds have fleshed out a lot of the issues with the model itself - we just have to set it up to meet our needs.

[hallister]

@cawaltrip We could take this one step further, now that we know that we are going to a client server model, and just use JSON-RPC or XML-RPC as the communication protocol. Tornado supports both, and there are other JSON-RPC libraries as well (XML-RPC has a simple, but exploitable, library built into Python).

Thoughts?

[andyleejordan]

@hall5714 0MQ is easy to implement and is pretty much built for passing around a JSON object. I would advise against XML, as it's one of the more difficult markups to parse. The Python JSON library is really good.

[rangera]

Okay, one thing, coming from knowing stuff about graphics, that I think needs clarified, is that user input, and the display of the graphics, are, and should be, separate.

Now, on the display part, I propose, as mentioned in the about us issue, that there be very specific calls to functions to modify the graphics. This is for several reasons

• It will modify only the parts that need it, this prevents clipping, and provides quicker graphics
• It will make the code very clear on what is happening
• It will therefore make debugging easier
• Adds modulity
• Layer Independence
• Defined Interface lets part develop independently (print out function call "ChangeDiplo( 114, 2 )")
• Separates calls: the above is called inside the Dip or Coup mission, right after state is updated
• Avoids the graphics parsing the entire state.

All together, this makes the code clearer, easier to change and improve, and leaves less room for error.

The input is a different topic, and is also where any AI would be integrated/replaced.

[hallister]

@andschwa I'm not sure that's a good idea. PyGame and Tornado are one thing, because those are Python modules. Using a C++ program that happens to have Python bindings may be taking it a bit too far.

Ignoring that, message queue's are amazing when you have millions of requests per second. Turn-based games (by their nature) don't operate on real-time events, so a message queue is overkill, especially for a small game like this. For this purpose Tornado is perfect: It's small, lightweight, easy to use and, of course, a Python Module.

@rangera I couldn't agree more. Nicely put.

[hallister]

I've thrown together a layout of how the project would likely be broken up:

Revised

In order to simplify all of this here's a breakdown:

Database: Persistance layer that stores data over time. Backend: Game logic and conversion of game rules (stored in Database) to a state. Server: A communication layer that converts communication from the client to methods that can be called on the backend.

AI: A decision making engine that, given a state, attempts to make "intelligent" decisions in response. AI Server: A communication layer that converts communication from the server to methods that can be called on the AI.

GUI: The interface the user sees. Client: A communication layer that converts communication from the server to methods that can be called on the gui.

One thing to keep in mind, is that each layer could be a different computer or the same computer. So we have options on our approach.

Given the way the layout works, I think a server team, client team and AI team is the most appropriate way to break up the groups. Any thoughts/comments @ui-cs383/team-members?

[jleithart]

Just so I'm understanding everything correctly, the Client is the game logic and all the game rules?

[hallister]

@leit7193 In this case, the client is the communication medium. It translates responses from the server, into the current game state and tells the GUI how to update the display to match the games state.

[hallister]

I've updated the post to give clear definitions of what each object in the diagram does. Hopefully it makes more sense than a simple graphic.

[jleithart]

Thanks @hall5714! That makes a lot more sense!

[cawaltrip]

@hall5714 Would the method calls that the client uses to make requests/get information be the same calls that the AI would use to do the same?

[hallister]

@cawaltrip Basically yes. The Server will only speak a single language, and if you want to make requests from the server you need to speak in that language. In the same sense, the response to the server will exactly the same to the AI-Server or to the Client. The difference only begins once that communication ends, and processing the response from the server.

[cawaltrip]

Okay that makes a lot of sense to me, thanks!

[hallister]

For anyone reading that, when I say the server "only speaks one language", I mean in terms of format AND syntax. So if we decide to implement this as JSON, for example, the Client or AI may request something of the server like:

{"jsonrpc": "2.0", "method": "combat", "params": [8878, 9929], "id": 1}

In this case the server is being asked to call the combat method, with the params 8878, 9929 (the id's of the groups of military that are fighting).

{
   "jsonrpc": "2.0", "result": {
   "won": 8878, 
       "losses": {
           "9929": { 
               military: 29, 
               ships: 1,
               characters: 1 
           }
       }
   }, 
   "id": 1
}

Once the client (or AI-Server) gets this data back, they convert the data to python objects, update the state and move on.

[andyleejordan]

Dibs on working on the server team (I'm a backend guy by all means, with database and message communication experience).

@hall5714 If I'm understanding you correctly, you're proposing the client deals with the input/output to the user via state changes, communicating that between calls to the GUI, and back to the main game engine (through the server). I think 'AI Server' is a misnomer, it's in fact just a subclass of the client. So you have a 'human' client, and a 'computer' client. The human one runs the GUI, and the computer one runs the AI.

[hallister]

I doubt we do teams based on who read this first :tongue:

Fundamentally yes. The Client (and the AI-Server) are they to take a common language (JSON in this case) and convert it (via method/function calls) to whatever the AI or GUI team determines.

However, I wouldn't call AI-Server a subclass of client. They absolutely do not have to implement the response from the server in the same way at all. All they have to do is form a legal JSON request, that the server understands, and be able to parse a legal JSON response. Aside from that they can (and probably should) be separate implementations.

[andyleejordan]

No, but we should do teams based on experience: I have much backend experience. I have no GUI experience :P

It's definitely still an AI client, as it's not serving anything. It's doing the same functionality as the human client.

They do not need to be implemented as actual subclasses of a client superclass, I'm just saying that logically they perform the same role and therefore should probably be named thusly.

[hallister]

This was a pretty simple model. Technically, all of these are actually peers, not clients and servers because they have bi-directional communication. For example, when human is playing the computer and makes a move, the Client requests the move state be changed by the server, which the server then confirms. In parallel, the server requests that the ai state changes, to which the ai sends an appropriate response.

But frankly, I didn't feel like writing "Server Peer", "AI Peer" and "Client Peer" as I felt that would confuse the issue more than this. I may have been wrong :smiling_imp:

[andyleejordan]

Server Peer, AI Peer, and Client Peer I would agree clarify things :)

[mein1156]

Just a thought, but looking at the teams, they have a similar task spread between them. Maybe all communications (with the server) should be done by the same person/people? Also, I imagine that the server team would need >50% of the people?

[hallister]

@mein1156 The communication layer isn't just responsible for communicating with the server, it's responsible for taking communications from the server and translating them to functions/methods to call against the AI/GUI. Those functions/methods are going to be very different implementations.

I don't think the Server team will need that many people. Frankly, the AI may be more complex than the Server.

[mein1156]

@hall5714 I agree that the translation can be done at the AI/GUI level. I mean the functions/methods that gather information from the server can be done by the same person/people. That way the JSON stuff is done by the same people and everyone else communicates (translates) based on a specified interface.

[hallister]

@mein1156 Ah, I see what you're getting at. Yes, a small part of the code base for the AI and Client will be all but identical. However, that probably is best written by the server team to be honest, for a couple of reasons:

• Client and AI team have plenty of stuff they can do while that is being worked on.
• The Server team knows the API, since they are writing it.
• The client connection library can be released as a module within the project, so it's reusable.

Unless anyone can think of a specific reason that other teams should be rewriting the low-level calling functions, I'd say that's the easy way to handle this.

[andyleejordan]

Having done some AI myself, I would actually highly advise we put that way down on our roadmap. We shouldn't even be thinking of coding the AI until we have a two-player game working. At that point we'll decide if we have the time/abilities to code out a reasonably intelligent AI. As long as we keep the state communication interface (whether that be a JSON object or a database) relatively easy to use, replacing a player with an AI player will be easy. But making the AI actually intelligent is something that should be done way down the line. Like 6-8 weeks from now.

It just shouldn't be a part of the core, as it's easy to add on later, and will be a resource sucker until the game is on it's way to complete.

[hallister]

Going to close this as the team breakup has been decided (along with teams).