Home
   Home  |  Preliminary Docs  |  Design Diagrams  |  Reference  |  Development Docs  |  Download  |  Source Code  |  Final Reports  |
Project Proposal

My independent study will focus on the design and implementation of a solitaire game engine, currently with the working name of "Solitaire Pack."

Solitaire Pack History

The motivation to program a set of solitaire games first came during junior high. Originally, I wanted to create a set of games that my mother would be able to play. (Then, and to this day, she plays Sierra’s "Hoyle Book of Games: Solitaire," a DOS program from 1990.) Thus, with a few sketches of screenshots, Solitaire Pack was born.

The first version, which shouldn’t even count, didn’t consist of anything more than a main menu, and a set of cards simply painted on the screen. Attempt number two actually succeeded in implementing two games (Aces Up and La Belle Lucie). However, it was a single, monolithic application; its drawing mechanism was difficult to use; and after the passage of several months, the code was so difficult to understand that I had to start completely over again.

The third incarnation actually works quite well. It was the result of several months of planning, and its implementation was actually relatively easy because it had been planned out. I stopped working on the project during April of 2001, and since that time, I have improved my programming methods significantly. With the desire to create and release Solitaire Pack as a shareware product, I decided that doing an independent study around this project would be a fun and meaningful experience, one that would help me gain "real world" experience.

Project Goals

The overall architecture for Solitaire Pack will be the same as that of the third incarnation: a "game engine" module, and a series of "game" modules. Separating the engine from the actual implementation of a game allows the product to be updated with new games and even allows other developers to create their own games for the product.

The primary goal of this project is to get me to do a significant amount of detailed designing before implementing the project. Currently, although I do put a lot of effort into designing and planning the architectures of programs I write, I usually end up doing most of the designing while I am actually writing the code. This largely stems from the fact that I like to see progress and results immediately. Hopefully in this project I will "reap the benefits" of a thorough design phase: an easier implementation phase and an easier-to-understand architecture.

By using the Unified Modeling Language (UML) to design Solitaire Pack, I will gain experience with the industry standard and will be able to easily and effectively communicate the project’s architecture. By maintaining a language- and platform-neutral design, I will have prepared a design that can be used in other environments in the future. (The implementation, however, will be platform-specific, and to an extent, language-specific).

Besides getting experience in the design process, I hope that this project will improve my skills in object-oriented programming. All too often my projects have had too much functionality lumped into the "main window" class, failing to take full advantage of an object-oriented design. Taking more time to design classes and interactions first should result in a more componentized, flexible implementation.

For this project, I only intend on writing two of my favorite varieties of solitaire: Spider and La Belle Lucie. Instead of trying to be "more productive" and get as much done as I can, I intend to focus on the design of these two games to make them reliable and bug-free.

Throughout the project, I will be logging time spent on this project and will be detailing progress made.

To conclude my project, I will be writing a summary of the things I have learned and the experience I have gained. Also, I will outline where the project will go from there, describing any other features that I intend to add that were not a part of the project. Thirdly, I will compare the development process with that of my independent work and with that of the Team Software Project (CS3141).

Timeline

This timeline establishes a rather rigorous pace for this project. However, this project is not just for the independent study but is a project I would be working on regardless. If, however, the dates need to be modified to allow for more time at a particular phase, we will adjust accordingly.

Documents and diagrams that I prepare will be placed online. Once the actual construction phase begins, I will demonstrate the program periodically to show progress.

Task

Due date

Requirements document

  • Describe the intended market
  • List and explain end-user program features
  • Describe features for third-party developers

1/28/02

Preliminary design decisions

  • Explain decisions such as target platform, language used, component architecture, etc.
  • Describe the "black box" components I will be using in the project
  • Describe project risks

1/28/02

Conceptual design

  • Create class, collaboration, and activity diagrams from a conceptual perspective
  • Identify and describe a number of use cases

2/6/02

Specification design

  • Create design diagrams based on engine and game abstractions
  • Identify objects and interfaces exposed by the engine and games

2/18/02

Implementation design: Engine

  • Create design diagrams for actual implementation objects and interactions
  • Establish code modules for engine (EXE, DLLs)
  • Identify possible test cases for scenarios
  • Write preliminary documentation for engine interfaces

2/26/02

Implementation design: Games

  • Design a base class for a generic game
  • Create design diagrams the La Belle Lucie and Spider rules
  • Identify possible test cases for scenarios

3/4/02

Construction of engine *

  • Create the main executable, with general program features
  • Implement recognition of game modules by the engine

3/11/02

Construction of engine

  • Implement primary engine objects
  • Perform non-game-specific testing on engine objects

3/25/02

Construction of games

  • Implement game objects
  • Perform non-engine-specific testing on game objects
  • Describe any modifications needed to the engine specification

4/8/02

Modification of engine and games

  • Based on additional "features" needed by games, improve engine design and implementation
  • Modify games as needed
  • Describe final testing procedures

4/22/02

Testing and finalization of project

  • Perform testing based on testing procedures
  • Fix bugs
  • Finalize documentation for engine interfaces

4/29/02

Project wrap-up

  • Package application in installable form
  • Write project conclusion

Finals Week

* Construction of engine will begin after the engine implementation design (concurrently with the implementation design of the games)

  January 20, 2002 jmhoersc@mtu.edu