Q.Com, a Plan 🔗


Our build plan consists of two phases, each yielding a prototype that illustrates the basics of our eventual product. The first phase concerns the logic of playing games, the second one communication.

The goal of the first phase is to build a complete game implementation, including game observers and possibly GUI-based players. This phase will thus implement the core of the system, including house players.

The actual work will proceed in a bottom-up fashion split up into the following milestones:
  • the basic game pieces such as the map, the tiles, etc.;

  • the What might these two italicized words mean? game state, i.e., the knowledge that the omniscient referee or a somewhat-ignorant player has about the game pieces;

  • the referee-player interface with a player implementation plus a rudimentary strategy implementations; and

    Note Once we have a player interface, we could actually ask some early adopters to write an implementation in our chosen language. It would provide some first insight on whether our formulation suffices.

  • the referee itself, which sets up games; runs turns and checks the validity of the players’ actions; determines when the game is over, scores a game, and informs players of the outcome.

The goal of this phase is to run the system through thorough unit and integration tests with the goal of eliminating as many logical bugs as possible.

The goal of the second phase is to break up this monolithic prototype into server and client pieces. The server will sign up clients and employ the manager to run games. The client will connect the existing player components to the server. For this step, we will use the remote proxy pattern to “splice” in communication components and separate the logical components. If we have debugged the logic well enough, any bugs that show up now are mostly likely to be in the communication components.

At this point, we can demonstrate this system to our investors as the alpha release of our product.

Warning Like with all software projects, the details of the game may change as experimentation with the prototypes suggests improvements. Even milestone specs may change as the project evolves. So, like with all software projects, the co-CEOs may have to adapt this plan as experimentation with the prototypes suggests changes.