Filed in: Blueprints.CodeRefactoring · Modified on : Mon, 08 Jun 09
This blueprint describes the code refactoring needed to support future features in the next releases. Features which are foreseen are multi player game, more artificial player behaviours, user management of the game rules, or user interface substitution.
It should be stressed that this list of features is not all-comprehensive. Neither is this list limiting for the present refactoring.
One of the Duo's historical features is that it is simple to install. Actually, up to version 0.8.1, Duo is made of a unique Python module.
The program was written by Camille Roux as an exercise to learn the language, and though it is running well, it is not possible to build new features on top of the existing code base. As of version 0.8.1, all the game engine (rules checking and player's turn ordering) is mixed up with the Tk interface code. All the program relies on some global variables. And variable and function naming is made of an English and French combination.
This development impacts the whole code base.
Refereeclass which is responsible of the game organization: accepting players for a round, distributing the cards, announcing the cards played or taken from the deck, the card on the heap and the winner. Actually, all the players only communicate with the
Referee, and in return the
Refereecan send a reponse to the player or broadcast a message to all the players in the game. The
Refereeis also the object which validates all the game events. Thus, the
Refereechecks if a player can draw or pass, and specially if the card he's playing is correct. To achieve that, it relies on a set of rules, each rule having conditions and possibly some action if checked (think pass or +2 cards for example). The
Refereeassumes nothing about the players of a game. They can be human or not, they can be from the same process, on the same machine or anywhere on the net. The
Refereeand players only communicate through a dedicated protocol, and this communication is endorsed by the Duo Protocol Stack. This stack is made of two layers, which are described below.
ProtocolAdapterclass which provides a high-level way to use the protocol for any entity. The class
ProtocolAdapterto provide everything a regular player may need. Note that the protocol does not cover the media used by communication. May the messages be carried using a raw TCP connection, an instant messaging protocol or even mail, there would be no other impact on the game than the media speed. Of course, the faster the media, the better the game.
This document does not enforce the way the main program is written and how these components interact, other than said above. For example, the choice of an interface or of an AI can be implemented in many ways and limiting this is not in the scope of this blueprint.
The rewriting exposed here remains opened enough to authorize further add-ons or minor break ups. For example, allowing the user to tweak the game rules could be achieved in (at least) two ways:
Actually, the correct solution probably lies somewhere between both of these approaches, and may require minor modification to the protocol, the game core, obviously the UI and perhaps other components.
This document implies no choice for the future, but only tries to narrow well defined components that communicate well with each other, and that can be tailored easily individually or together for further features.
duo is now a package which provides sub-packages or modules for the components identified above.
duo.referee contains the
Referee class and supporting tools, like the rules definition. The
game module provides additional tools like the game and cards abstraction.
duo.protocol is the implementation of the 'Protocol Layer component, which provides especially the
duo.ai contains the AI stuff. All coded behaviours inherit
duo.ai.AbstractAI which provides the interface to the other components as well as all the callbacks useful for artificial player programming.
duo.transport contains the Transport Layer implementations. Main interaction with the upper layer of the protocol is achieved through
duo.transport.Context. Transport implementations shall redefine
Endpoint to access network or any other mean to communicate.
duo.ui contains UI implementations.
This space is for User-contributed commentary and notes. Please include your name and a date (eg 2008-12-19) along with your comment.