-
Notifications
You must be signed in to change notification settings - Fork 0
Improvement Ideas
Ideas to do with the QuickGame concept as a whole.
I (Nathan) bought the quickgame.net domain. I've had trouble explaining to people how to type in the domain hack (i.e. "it's 'quick', then 'ga'-dot-'me'", or "it's 'quickgame' with a dot between 'ga' and 'me'"). The alternative is more simpler and easier to explain.
QuickGame is inherently two parts: one is an independent board game system built on Akka (i.e. akka.quickgame.net). Anyone can create a client that messages the engine to spawn and use a new game room. Ideally, this engine should not rely on WebSockets and any client that provides two-way communication should work.
The Web App (www.quickgame.net) will be a stateless REST application that uses WebSockets to interface with the game hosting service. The web app stores no data, merely passing along all requests to the Akka backend and providing a pretty interface where users can make requests.
One advantage in this separation is that it's more amenable to current web technologies. Right now, not a lot of platforms support WebSockets, and the ones that do (CloudBees) make it hard to do remoting and other stuff with Akka. More specifically, if you deploy multiple instances of your app, the Akka instances won't be able to talk to each other, so you may get into a situation where a client on one instance can't access a room created on another instance. Separating the apps fixes this because we can have multiple web app instances that contain no data and one Akka server that has consistent data.
Suggestions relating to the model-view-controller of the application.
- Mobile support (put chat window on another screen)
- Overall refactor the design code.
- View room state in client (not just game state).
- "Share" button.
- Add non-square icons.
We could use KnockoutJS or another client-side MV* to make our client-code more streamlined. I like Knockout the best. It odesn't force us to inherit from its own class or use jQuery or REST. I think it should be pretty compatible with Bootstrap and WebSockets.
Pros:
- Can scale automatically to the size of its parent div.
- Easier to create complicated graphics than just divs.
Cons:
- Not supported by all browsers (then again, we're using WebSockets...)
- High learning curve. Maybe we could use Raphael?
The room code is very messy. I want to switch to an Akka FSM model, so that we can separate out the room logic from the logging messages being sent out to players.
The State should be the room state (Lobby, Playing, or Paused), and the data should be a case class that contains the current players and spectators and the current game state.
Unfortunately, Akka's FSM module, as given, won't work. We're doing too many imperative things to support what's currently available. One option would be to use become statements to change behavior between states. Another would be to make a class similar to FSM that provides our necessary functionality (broadcasting to multiple players).
Maybe we can make the chats optional, i.e. if the game is embedded in Google Hangouts.
I still don't like how we're doing JSON input and output in general. A couple of gripes in this one:
- The input
CSMessageclass; I want to figure out a way to make it sealed, so that theGameRoommust handle every type of message, while still being able to create new messages easily.
Requiring clients be children of the GameRoom is restrictive and requires us to pass iteratees/enumerators around (which I'm not sure is thread-safe). One idea is to create the client in the GameManager and have it poll the GameRoom to join. The GameRoom adds it to the list of clients and doesn't need to return anything.
There is too much repeated code in our Game classes. I (Nathan) tried to make the games as modular as possible and outlined the most basic of game definitions. However, all our games right now follow the same convention: two-player, turn based board games. The solution I'm thinking of is to create a bunch of mixin traits such as TurnBasedGame or BoardGame which will help remove some of the code duplication.
The Player type of the Game trait should be abstract and individual games should instantiate it differently based on game idioms. For example, in Tic-Tac-Toe, the roles would be X and O, and in Blokus they'd be Red, Yellow, Green, Blue.
I want to rework our games to use the GameDescriptionLanguage, either by directly defining our games using it or by creating a DSL inspired by it. This will let us create our games declaratively, so we don't need to define our own control.
- Selecting the size of the board, the number of players, etc.
- Selecting between different rules.
- Handicaps for players