Download
1 / 15
150 likes | 260 Views
Agenda. Overview and Business Goals Design Drivers and Tradeoffs. Goals. Create a general purpose multiplatform board game framework Support multiple board games and multiple user interfaces
E N D
Agenda • Overview and Business Goals • Design Drivers and Tradeoffs
Goals • Create a general purpose multiplatform board game framework • Support multiple board games and multiple user interfaces • Framework does this by allowing any board game development group to easily plug in a board game logic component and run it with minimal concern about the actual user interface presenting the game • In addition it allows any user interface development group to easily plug in a user interface for any platform and to present any framework conforming board game
Design DriversStakeholders and Constraints • Stakeholders • Logic plugin developers • User interface plugin developers • Players • Board game company • Constraints • Time constraints defined by the deadlines • Quality constraints defined by test coverage • Only turn-based games are supported that can be represented in 2D.
Design DriversQuality Attributes • Extensibility • Framework defines a set of interfaces for the plugin developers to implement. These interfaces make it possible to change the game and the UI without changing the code of the framework • Usability • Framework describes an interaction mechanism with the players. • Portability • Any user interface plugin that conforms the framework’s interfaces can be plugged in to the framework running on JavaVM. This enables developers to implement the user interface using any graphical library and platform. • Reuse • Game logic is decoupled from the user interface logic. This allows the framework to be used by multiple games and user interfaces. The basic game loop and drawing sequence are defined by the framework.
Design DecisionsArchitecture Tradeoffs • Extensibility and portability vs. security • The framework supports decoupling between UI plugins and game plugins. Due to the decoupling and high generalization of the framework it is more exposed. For example there are no framework level rules or checks against plugin collected data. • Extensibility and portability vs. performance • Due to the high decoupling, the footwork of the framework has increased. This has a negative effect on the performance of the system.
Design DecisionsDecoupling • Decoupling of user interface using Bridge pattern, by mapping the logical representation and the “physical” one. • Decoupling of plugins using Abstract Factories.
Design DecisionsPlatform and singleton Engine can be used to create a gaming platform, and switching games.
Design DecisionsPlatform and singleton Engine can be used to create a gaming platform, and switching games.
Questions? • Why to use the framework? • Because it is generalized enough to create cool 2D board games • Because it is relatively easy to develop games under it, and there are more than one sample on how to create them • Because it can be turned into a game platform that can spawn multiple games for multiple players
Test Coverage • The only class that has no 100% code coverage is the class PlayResult. In fact, this value comes from a fault in the code coverage analysis tool, which is not able to check code coverage correctly when an enum is included inside the class. • For more information see the Group 4 Test Report.
Lessons learned • There are many different good ways to design a software, and the discussions about it can go on, and on. • Having a technical lead is important in a group. Otherwise technology specific tasks can take a lot longer, even if they are trivial.
