Skip to main content
GameDev.net gamedev.net
🔒 Locked

Software engineering - how to get going?

Started by Structural Sep 8, 2003 at 1:18 PM 3 replies 400+ views
Original Post
Structural
Structural
I''m now in my fourth year of Computer-engineering Uni here in Holland, and again we''re doing this "project oriented teaching" stuff. This time we have to make a game (4 in a row) that can communicate over the network and have some crazy AI. Now, in the past few years we''ve done some basic UML and had a course of sofware engineering/management last year, but there were never any clear links between the two. Personally I''ve always been more of a "hack now and made designs afterwards for the teachers" person, but I want to learn to do this properly as I feel it will speed up my personal projects. More detailed: - What UML methods are put in the functional specification? (use cases, and what more? My book is no good in explaining me that) - What UML methods are put in the technical specification? (Class diagrams, component design, sequence diagram... what more?) - Are there specific things I should watch out for when software engineering is applied to games? Also, I''m making a planning template now for my own personal use in future projects. I made a list of deliverables but I feel it''s rather incomplete (mainly due to my lack of knowledge of UML and how to apply it in a project). is this complete? - Planning - Requirements - Functional specification - Core game play - User interface (Use cases) - 2D & 3D art - Game Flow - Technical Specification - System component design - System functioning (Sequence diagram, State diagram) - Class diagram - Implementation - ??? - Test cases & results - Manual I thank you in advance for any information and linkage. I can assure you that it will be used wisely, if not by this project group, then by me personally.
STOP THE PLANET!! I WANT TO GET OFF!!
Pipo DeClown
Pipo DeClown
Hey, I''m Dutch too!

Don''t have anything to tell you but, check my game out =)
http://www.gamedev.net/community/gds/projects/default.asp?projectID=815

.lick
darookie
darookie
Your list seems to be a little bloated, but I don''t know your
team size and schedule.

Just some thoughts:

Usually the technical design document already covers
- technical requirements
- functionl specification (beware of the scope here! The level
of detail should not be too high)
- technical specification
- system component specification and design (more or less a
refinement to technical requirements)
- implementation details (if not already covered by source
code documentation)

I would not suggest the use of detailed class diagrams as
class layout and details will change often during the
implementation phase. A solid JavaDoc/Doxygen-style source
code documentation will generate a more up-to-date document,
which even includes class and collboration diagrams (at least
if you use Doxygen and Dot).

Personally I use UML for high-level design and system description
only. The source documentation will generate much more detailed
information on the implementation while UML is more or less
"the big picture" part if you''re not using a complex round-trip
engeneering tool like Rational Rose.

Starting with the game design along with the manual seems to be
a good idea, too as the technical requirements can be derived
from a detailed design document quickly. This would be called a
top-down approach I guess.

Use cases are IMO rather trivial for such a simple game. I would
not try to model them in UML and rather refer to the manual and
the game-flow described in the design document. Creating UML use
cases appears redundat work to me.

There are also different approaches for the test cases, such as
low level component and integration testing first and game-play
testing later.

Good luck with your project,
Pat
Shannon Barber
Shannon Barber
Practical UML

Deliverables are specific items to the project, not general ideas. Example deliverables for your project are: drawing the board; dropping a piece into the board; sending & receiving piece placement over a network; AI making placement choices; AI making optimal moves; AI taking counter-AI measures.

Use-cases are starting a new game, creating/joining a network game, dropping a piece, and maybe undoing a move and asking the AI for suggestions.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Structural
Structural
Thanks people
STOP THE PLANET!! I WANT TO GET OFF!!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.