aspose file tools*
The moose likes Beginning Java and the fly likes Game Tutorials -->> Development Process Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Game Tutorials -->> Development Process" Watch "Game Tutorials -->> Development Process" New topic
Author

Game Tutorials -->> Development Process

Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
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 ]

    [How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
    Rob Ross
    Bartender

    Joined: Jan 07, 2002
    Posts: 2205
    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.


    Rob
    SCJP 1.4
    Dirk Schreckmann
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    Bingo! (err - TicTacToe!?)
    As the first phase of the SDLC suggests, we'll do just that.
    Dirk Schreckmann
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Ranch Hand

    Joined: May 17, 2001
    Posts: 2823
    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
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    But then you're supposed to refactor the garbage into art!
    Dirk Schreckmann
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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
    Bartender

    Joined: Jan 07, 2002
    Posts: 2205
    I agree. Another name for this process is "XP" , or extreme programming
    Dirk Schreckmann
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    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
    Ranch Hand

    Joined: Nov 30, 2001
    Posts: 102
    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
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    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
    Sheriff

    Joined: Dec 10, 2001
    Posts: 7023
    Jennifer,
    That's a good question to consider and answer:
    What are we trying to accomplish in the project design process?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Game Tutorials -->> Development Process