Game Tutorials -->> Development Process

[Dirk Schreckmann]

This is part of the package of Game Tutorials threads, for which a complete listing of threads can be found in The Table Of Contents.
So, how should we develop these games?
My idea is to follow John Smiley's example in his new book Learn to Program with Java and use the Systems Development Life Cycle (SDLC) process. John Smiley was recently a featured author here at JavaRanch in one of April's book give away contests.
This process fits well with the style of conversation the Saloon provides us.
The six phases in the SDLC are:

Preliminary Investigation

Analysys

Design

Development

Implementation

Audit and Maintenance

A quick search on google would probably provide some more information to further describe the SDLC. Later on, I'll discuss each phase of the SDLC further in this thread.
What are your thoughts on any development process that we could use?
[ June 05, 2002: Message edited by: Dirk Schreckmann ]

[Rob Ross]

The best way to start is just to start. I find that too much process gets in the way of progress. Of course, not enough process and you end up spinning your wheels uselessly.
I'm not familiar with SDLC, but in most projects there's a phase where you collect user requirements, use cases, user "stories," etc. I assume there's something similar in SDLC.
So first I'd suggest you define what you want this program to do, how it will be accessed, what environments it will run in, feature set - multi player? network-aware? Graphical, or command based? (Ie, type in Circle on square 1,1, or drag& drop a circle there,) etc, etc, etc. Pictures/screen shots/mock-ups are very useful in this phase.

[Dirk Schreckmann]

Bingo! (err - TicTacToe!?)
As the first phase of the SDLC suggests, we'll do just that.

[Dirk Schreckmann]

I'm proposing that we don't start from an assumption that we're great programmers with years of experience (this is the beginners' forum) and get to writing unit tests and following other extreme programming practices such as The Test First Stoplight yet.
Some implementations of the SDLC call for a detailed design process before any actual coding is to begin. I'm proposing, rather, a process more like Rob has suggested. Sort of a "let's just start doing something, but first decide what we're going to do" approach.
Then, as we're actually coding a program, we can introduce concepts and practices of extreme programming to (as I like to think of it) create the program as it wants to be created to solve the problem under consideration.
For any interested parties, a listing of SDLC readings:

The U.S. DOE on Software Engineering with the SDLC

pdf on The SDLC

SDLC info at John Smiley's site - you may need to increase the display font size

Webopedia on SDLC

And a listing of extreme programming readings and sites:

XProgramming.com

JUnit.org

WikiWikiWeb on ExtremeProgramming

an example XP experience article at ObjectMentor.com

xp123.com

[ May 11, 2002: Message edited by: Dirk Schreckmann ]

[Paul Stevens]

Rob in this case you may be right. But in general if you skip those first 3 steps, you end up with garbage.

[David Weitzman]

But then you're supposed to refactor the garbage into art!

[Dirk Schreckmann]

From John Smiley's description of the SDLC:

Each phase of the SDLC creates a tangible product or deliverable. An important component of the SDLC is that at each phase, a conscious decision is made to continue development of the project, or to drop it. In the past, projects developed without the guidance of the SDLC were continued well after 'common sense' dictated that it made no sense to proceed further. The deliverables act as milestones against which we can judge the progress and continuing viability of the project.

The deliverable from the first phase of the SDLC, The Preliminary Investigation, is the decision whether to proceed with a project - the details of which haven't been fully addressed, but for which a well understood request has been made.
John Smiley lists three constraints to consider when making this decision: Technical, Time, and Budgetary.

[Dirk Schreckmann]

In the next phase of the SDLC, The Analysis Phase or The Data Gathering Phase, the deliverable is a beginning draft of The Requirements Statement that lists all the major details of the program. Many of the details of what the program should do may have been determined in the previous phase, but we'll be using this phase primarily to explore these details.
[ May 08, 2002: Message edited by: Dirk Schreckmann ]

[Dirk Schreckmann]

The deliverable in the third phase of the SDLC, The Design Phase, includes a formal Requirements Statement that describes the output, input, processing, and any stored information that the program might use. During this phase, we wil also develop a sketch of what the user interface will look like.
This Requirements Statement would serve as our contract with the customer concerning what we are expected to create and how we are to be compensated. (For our purposes, since we are our own customer, our compensation will be what we create.)
As we move through the remaining phases of the SDLC, some details of our Requirements Statement may well need to change as we discover new things and *listen* to what the project tells us it needs to be or do to satisfy the problem we're solving. Details of the processing and the user interface strike me as areas that develop best from explorations that take place during the actual development (coding) of the program. So, for the purposes of the Requirements Statement, we won't be spending time detailing these aspects that are likely to mutate (evolve).

[Dirk Schreckmann]

Borrowing some more from John Smiley's book, The basic outline of the Requirements Statements we'll develop will include:

A General Description

The Output from the System

The Input to the System

Business Rules - A brief description of the processes involved in producing the output from the input.

[Ilja Preuss]

Originally posted by Dirk Schreckmann:
From John Smiley's description of the SDLC:

The deliverable from the first phase of the SDLC, The Preliminary Investigation, is the decision whether to proceed with a project - the details of which haven't been fully addressed, but for which a well understood request has been made.
John Smiley lists three constraints to consider when making this decision: Technical, Time, and Budgetary.

Sounds a lot like the Exploration Phase of XP: http://c2.com/cgi/wiki?ExplorationPhase

[Ilja Preuss]

Originally posted by Rob Ross:
The best way to start is just to start. I find that too much process gets in the way of progress. Of course, not enough process and you end up spinning your wheels uselessly.

I don't think that it is *too much process* that gets in the way, but a process that focuses more on producing documents than on developing the actual software. Such a process (for example a heavyweight instance of RUP) tries to indicate progress by creating diagram after diagram instead of code.
The problems with this approach are:

- How do you know how much of the project is done when the design phase is finished? How much percent of time the testing phase will cost?
- You don't really know wether your design is appropriate before you try to code it.
- You don't know wether you coded the requirements correctly before you tested the code.
- You don't know wether you correctly understood the requirements before the users tried to use the system.
- After using months for the analysis and design phases, the requirements may have changed just by the flow of time. (You know the saying: "A working program is outdated".)
The only way I know to overcome these problems is to start designing, coding and testing from week one on, getting feedback on the growing, working system as early and often as possible and being prepared for changes...

[Rob Ross]

I agree. Another name for this process is "XP" , or extreme programming

[Dirk Schreckmann]

Ilja Preuss on the Preliminary Investigation phase:
Sounds a lot like the Exploration Phase of XP.

Good. I'd like the way we do things to sound more and more like aspects of extreme programming.

[Dirk Schreckmann]

Concerning Ilja's reference to the RUP:
For more information on what the RUP (Rational Unified Process) is, a quick search on google lists some useful information, including an article from therationaledge.com: The Ten Essentials of RUP.

[Ilja Preuss]

Originally posted by Rob Ross:
I agree. Another name for this process is "XP" , or extreme programming

That's one possible process, but there are others.
Take a look at http://www.agilealliance.org.
[ May 10, 2002: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Dirk Schreckmann:
Concerning Ilja's reference to the RUP:

I want to emphasize that I was referring to heavyweight instances of RUP. It is possible (and even preferable) to create and use agile instances of this process framework; there are even descriptions of an XP-like process as such an instance.
In fact, Rational is even sponsoring the Agile Alliance...

[Dirk Schreckmann]

Originally posted by Ilja Preuss:
It is possible (and even preferable) to create and use agile instances of this [RUP] process framework; there are even descriptions of an XP-like process as such an instance.

This is exactly where I hope we're heading. I'm very pleased that we've grabbed your attention, and I look forward to your advice and ideas throughout our discussions.

[Dirk Schreckmann]

In the Development Phase, we finally (see note below) get to code our project. The deliverable will include a fully functional software package that satisfies the specifications developed in the previous phases. The deliverable will also include any complete user documentation and help system to accompany the software.
Note on facetious use of finally: As previous considered in this conversation, it is not our goal to follow a system of heavy design that is finally followed by the actual coding many days/weeks/months later. For the games we will develop, the first few phases could take as little as a few hours of discussion over what we want the game to do and look like.

[Jennifer Wallace]

Dirk, I am learning a lot from these software development process threads which you have started here. I am still trying to grasp the idea fully.
This is what I have been understanding from the above discussions that you sit down and have a nice chat with the client and figure out what he wants and write out a statement, the Requirements Statement, describing the problem. I see from the Tic Tac Toe game thread .. that it is so!
But when do you design on the program flow ? Or the Program Logic/ Algorithm ? Shouldt that be part of the Requirements Statement also? Is it necessary that your plan of implementing the program as to what objects you will be using and what methods in the program should be stated in the Requirements statement?
It seems that it would be too tedious to think it all out at the very beginning. But is that how a good design is supposed to be done ?

[David Weitzman]

Jennifer, the best way to notate your program logic is just to write it in Java code. Unless you're working out a complex finite state machine or heuristic algorithm or something similarly mind-twisting, well written code should speak for itself.
It's often a good idea to name a few classes and assign the responsibilities, but don't use too much detail since you often can't tell where a project will end up until you've started it. The sort of thing you can do is:
Board (data) -- maintains a matrix of X's and O's
Scoretable (data) -- maintains a win-loss record for a gaming session
TicTacToeReferee (logic) -- validates moves and updates/owns the Board. Determines game result. Keeps track of Players and tells them when to move
Player (interface) -- moves when told and accepts the Referee's judgement without argument
TacTacToeApplet extends Player (UI) -- Allows a human to act as a Player
AiPlayer extends Player (logic) -- computer opponent
Note that this list is not in any official format (in fact I don't think I've ever made one quite like it).

[Dirk Schreckmann]

Jennifer,
That's a good question to consider and answer:
What are we trying to accomplish in the project design process?

[Ilja Preuss]

Originally posted by Jennifer Wallace:
But when do you design on the program flow ? Or the Program Logic/ Algorithm ? Shouldt that be part of the Requirements Statement also?

No, it shouldn't. The Requirements should describe the system from the users perspective - what the user expects the system to do. He shouldn't care much about how the system is implemented. In other words: Every requirement should be directly associated to business value.

Is it necessary that your plan of implementing the program as to what objects you will be using and what methods in the program should be stated in the Requirements statement?
It seems that it would be too tedious to think it all out at the very beginning. But is that how a good design is supposed to be done ?

That is what "traditional" processes try to do, but it's not only tedious but also very inflexible. The uprising "agile" processes use another approach (roughly "designing on the fly" aka "evolutionary design") - with some success. See http://martinfowler.com/articles/designDead.html for more details.