Architecture - mbohl/microgames GitHub Wiki

Introduction

This document provides a description of the software architecture of the MicroGames system.

MicroGames provides a service allowing users to play fast, easy to understand and conveniently paced board games with each other through a web application implemented using Ruby on Rails. The goal of MicroGames is to facilitate the play of as many board games as possible without subjecting users to overwhelming user interfaces or strict time limits dictating the pace of the game. In this way, users are given a casual yet fun way to enjoy their favorite board games with other users in semi-real time.

The goal of this document is to provide a high-level overview of the software and system architecture using the 4+1 Architectural View Model.

Logical Representation

The system can represented as a standard game server with users associated with individual gaming sessions.

The largest piece of the system is the Game Engine. This module represents the management system of instantiating gaming sessions, allowing users to log in and create games. It will provide the initial interface users will interact with, and be the starting point of all new games. In addition, it is the primary communication area between users. Associated with the Game Server are the User and Game module.

In this representation, the Game module represents a single instance of a game in progress, with its type dictating the specific board game it represents. Users are associated to each Game object as they join the session to play. Our initial system will only support gaming sessions involving exactly 2-players.

Each Game will have access to methods governing the rules of the game to ensure fair play. Users will interact with the User Interface, which forwards player decisions and actions to the Game Mechanics module.

Development Representation

The modules within the Development View are sets of Controller and Model objects which are key components of the Ruby on Rails Framework. First is the Session Controller which is responsible for authentication of users. This module will take advantage of implemented security measures to check the database for a user's credentials andvalidate the login of existing users, or the creation of new ones.

The Game Controller module serves as the gateway to all other actions. If a game is to be created, the user can specify a new game type and name and a new instance of Game will be created within the database. When the user wishes to start the game, they communicate with the Game Engine which then moves control to the Game Logic module. From this point, the Game Logic module manipulates the corresponding Game object to the current game session. Functionality of the Game Mechanics is currently implemented only for the TicLogic game (TicTacToe) as shown in the view. Within each Game object includes evaluating player actions, keeping track of whose turn it is, changing the state of the game depending on what players do, and deciding when a player has won or lost the game.

The User Management module handles logistic configuration of User settings as well as adding associations between Users and Games when new Games are created. When games end, the User Management module will also handle updates to a User's game history and evaluate gaming statistics for later use based on the latest game's result.

Process View



The Process View summarizes the functional behavior of the system. Engaging the system begins with authentication. In the event that a user is successfully validated, the Game Lobby will be shown on the UI for the user to interact with. The user can then create a new game or play a game (either newly created, or already existing). When in-game, if it is the user's turn, the user can make an action consistent with available actions according to the current gaming session's mechanics. If an action is made, the game's mechanics are checked to ensure that the move is valid, and to determine what effects the action has on the state of the game. The state of the game is then updated on the server, and the game is evaluated further to determine if the game has been completed. If the game is still in progress after the latest user action, the process can repeat on the next user action (note that this illustration does not explicitly capture the concept of alternating player turns, but this can be viewed as a check against the game's mechanics to decide if it's the acting player's turn). If the game has ended, the system enters the End Game phase (i.e. show "Game Over" screen, display winner, etc.) and the user is returned to the Game Lobby.

Deployment View

The Deployment View depicts the system from a operational point of view. It shows the topology of software components on the physical layer, as well as the connections between these components and devices. The MicroGames application runs on Amazon's Elastic Compute Cloud (EC2) service, which contains any number of virtual machines used to run the application. The application itself is based on the Ruby on Rails full stack framework which provides not only an execution environment but a web server. Supporting the application is a Data Store housing the microgames schema. For this implementation we rely on a MySql database, created via the Rails framework tools.

Playing a Game

A game is played when a player invites a challenger to a new game. As shown above the game objects are instantiated and the turn cycle begins. After each turn, the game state is re-evaluated. This process repeats until and end state is met, a winner is declared, and the game is over.