Solitaire Pack will be developed for Microsoft Windows, and will run on the following versions:
    Windows 95, 98, and Millenium Edition (Me)
    Windows NT 4, 2000, and XP

Internet Explorer 5 or newer is required. This is a standard component of Windows 98 Second Edition, Me, 2000, and XP.

Windows was chosen as the development platform for several reasons. First, it is the platform with which I, the developer, have the most familiarity and experience with. It provides rich platform functionality that applications can take advantage of. In addition, developing for Windows ensures a large target market of users of all skill levels.

Internet Explorer is implemented in an easy-to-use component architecture, and provides an easy, flexible, and visually-appealing user interface. By embedding the web browser component in Solitaire Pack, I will be able to use HTML as the underlying structure for the user interface. Requiring users to have IE5 is not going to be a significant hindrance to program use, because the majority of Windows users have that version or newer. (IE5 was released in 1999.)

I will be implementing this project using Microsoft Visual C++. Because I have been programming in C++ for many years, and because of its speed and efficiency, C++ is the language of choice for this project. I have decided against using the ActiveX Template Library (ATL) for Visual C++, which is well-suited for building component-based applications such as this one, because I have not had the time or ability to learn how to use ATL effectively.

Although my development will be in C++, developers of third-party game libraries can use any of a number of languages. However, the two games that I actually implement for this project will be written in C++.

The project has been split up into two subprojects, the engine and the game library. Although it is best to wait until later to decide what physical files will constitute the project, I have made several preliminary decisions.

First, there must exist a primary executable file. This will be Solpack.exe, the program that the user runs. In addition, an accompanying library, SolpckLC.dll, will contain all English-localized resources (strings, dialog boxes, menus, etc.) that the engine uses. The engine may be split up into more files, depending on the implementation design.

The games library will be implemented in SPGames.dll. It will also have an accompanying English-localized library, SPGameLC.dll, which will contain, among other things, the game’s help information.

There are a number of different mechanisms for inter-module communication. An older technique is exporting API functions from a DLL. In this way, the engine would look for specific exported functions in the game library DLL, and would call these functions. This technique has many drawbacks, such as requiring the game to be in a DLL, and requiring it to be on the same machine as the engine. This technique will not be used for Solitaire Pack.

Another possibility is to use Sun’s Java. This would allow the engine-module interaction interfaces to be cross-platform. However, using Java is very slow and would limit my and third-party development to a single language. Another option is to use the Microsoft .NET Framework as the underlying architecture. This would allow the possibility of web-based, cross-language, and potentially cross-platform development. However, .NET technology is also relatively slow and requires rather powerful hardware and a newer operating system. In addition, I do not have a very deep understanding of .NET; learning it would be a task unto itself.

The underlying architecture of Solitaire Pack will be the Component Object Model (COM), a popular system which is the conceptual predecessor of .NET. There are many advantages to using COM, including fast, in-process code execution and language independence. Also, having spent many years developing COM-based programs, I will be able to develop the program and its interfaces rather quickly.

Being language independent, COM allows third-party developers to use any COM-compatible language to create solitaire games. Indeed, I wish that I owned Visual Basic, because it would provide an excellent means for testing the engine and game modules.

In the development of Solitaire Pack, I will be using making extensive use of operating system components to make my development as easy as possible.

As mentioned previously, I will be using Internet Explorer in my application. Specifically, I will be using the WebBrowser ActiveX control, inside of which I will display an HTML document that serves as the basis for the Game Menu and game play user interface. In addition, the Help Pane will contain the WebBrowser and will contain instructions for the games. The game’s 3D animation (when the user wins) will use Microsoft DirectAnimation and DirectX Transforms components.

Other "black-box" operating system components I will use include the Common Dialog Box library, containing Open and Choose Color dialog boxes (among others I will not use). Also, I will be using the operating system’s Common Controls library, for the window’s status bar and for some components of the Help Pane. The components that I have listed are in addition to the general Windows API functions that my program will obviously have to use.

Lately, in my development of other projects, I began developing a number of "Bot Productions components," any time where I was developing a generic feature or class that could be used in multiple projects. (Bot Productions is the name of my "business.") These components are not separate code modules but are simply #included into my projects.

Although I continue to have to make changes to these components’ source code at times, for this project I will treat them as black-box components in that I will not include their implementation in any design diagrams and documents that I produce. Thus, components such as the splash screen allow me to quickly and easily add a splash screen to the program without having to worry about it being a superfluous or waste-of-time feature.

The following table lists the components that Solitaire Pack will be using. (The "bmws" prefix has merely historical significance and is simply used as a prefix for the file names.)

bmws_3dshatter	Given an image path name and an MSHTML document object, displays a 3D shatter animation of the image.
bmws_array	Template class to encapsulate arrays of any type.
bmws_browsercontainer	Encapsulates embedding the IE WebBrowser in the application
bmws_choosecolor	Encapsulates the display and management of the Choose Color dialog box
bmws_comserver	Provides a base implementation of functions that are required by COM server DLLs.
bmws_dispbase and bmws_unkbase	Base class for all COM objects exposed by the engine and the games; provides implementation of low-level COM details.
bmws_error	Classes and functions for error checking, error handling and exceptions.
bmws_eventhandler	Object that assists in COM event handling.
bmws_eventsink	Object that assists in COM event sinking.
bmws_hlink	Encapuslates displaying a pseudo-hyperlink in a dialog box.
bmws_htmlhelpers	Provides a number of helper functions for common Dynamic HTML operations.
bmws_ofn and bmws_singleofn	Encapsulates displaying the Open File common dialog box.
bmws_ptr	Smart pointer class for COM interface pointers.
bmws_registry and bms_key	Assists in reading and writing settings into the Windows Registry.
bmws_regservices	Handles user registration code validation and the Register dialog box.
bmws_splashscreen	Displays a splash screen with a specified image and text.
bmws_string	Classes to encapulate standard strings (TCHAR arrays) and COM-allocated strings (BSTRs).
bmws_waitcursor	Class to easily show and hide the hourglass cursor.
bmws_window	Base class to represent window objects.

These components encapsulate a variety of common behavior, allowing this project to focus on the Solitaire-specific functionality.

Requirements Risks:

Since I decided the scope of this project and its requirements, there is no danger that I will build a product that "misses the boat," so to speak. However, this fact means that my development of features and requirements could be faulty, due to my obvious lack of ability to do a comprehensive market study. For this project, however, this is irrelevant.

Technological Risks:

I estimate that this project will have few technological risks. I will be making heavy use out of the IE components, and although they are easiest manipulated from scripting languages, they are completely open to (and faster with) the C++ language. However, there are often little "quirks" when working with these components; sometimes, something that seems trivial to do ends up taking hours of experimentation and investigation. However, my familiarity with using the IE components should reduce this time of frustration. The other technological concern I have is with speed. On my previous version, I tried making the program multithreaded, but COM-based overhead ended up causing a drastic performance hit. Hopefully, my extra experience over the past year since then will enable me to minimize performance-related concerns.

Skills Risks:

The preliminary design decisions I have made are with the intent of reducing skills risks. My choice of language, platform, component architecture, and choice of black-box components all contribute to developing within my skills range. I anticipate there will be some situations which will require me to read articles and documents in order to figure certain things out, but that is to be expected with virtually any project.

My next task will be to diagram my project from a conceptual perspective. Although the Requirements Document goes into great detail regarding features, it is simply a list and does not provide a visual representation at all. The conceptual diagram will be in UML and will provide an overview of the application from an end-user rather than developer perspective.