Writing Use Cases for a 3D Game Engine

Started by
11 comments, last by s4shim 20 years, 6 months ago
Hi all, I am doing my M.Sc. Computer Science Final project. It is a 3D Game Engine in C++. My problem is that I have to write a Use case document for this Game Engine. Can anybody help me that in whay ways and directions should I think to conceive and write use cases of a Game Engine??? Any link or article about this will be highly appreciated. Thanks.
Advertisement
Before thinking about use cases, think about the context of the game engine. Where does it sit in the Grand Scheme Of Things?

1) Who (or what) are the actors? With what other (sub)systems will your engine be co-operating? Directly with the player? With scripts? With an AI engine? Probably not showing the OS or OpenGL/DirectX systems as they''re not affecting your engine in this way.

2) How will those actors co-operate with or use your engine? There are clearly more strands here than just ''play'', especially when you take the non-human actors into account.

Just my €0.02.

Anybody else can help ?????????

Some suggestions with examples will help a lot.

Thanks
Writing use cases for a 3D engine sounds to me like trying to fit square pegs into a round hole.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
If you are really interested in UML, I would recommend you start with Craig Larman''s book "Applying UML and Patterns". In this book Craig covers the entire life cycle of the unified process; including use cases and their inputs.

Generally speaking he recommends that you focus on use cases at the level of elementary business process (EBPs). The EBP is defined as "A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state".

That said; I guess if your Professor considers your use cases of value then they add business value. I would recommend that you start by defining your actors and goals and go from there. Furthermore, you should also keep in mind that that time can and will be in actor.

Lastly, you may want to post your question in the engineering forum:

http://www.gamedev.net/community/forums/forum.asp?forum_id=34

Hope this helps.


Understanding is a three edged sword...
_______________________________________Understanding is a three edged sword...Freelance Games - Home of XBLIG Starchonwww.FreelanceGames.com
quote:Original post by Sean Doherty
If you are really interested in UML, I would recommend you start with Craig Larman''s book "Applying UML and Patterns". In this book Craig covers the entire life cycle of the unified process; including use cases and their inputs.

Generally speaking he recommends that you focus on use cases at the level of elementary business process (EBPs). The EBP is defined as "A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state".

That said; I guess if your Professor considers your use cases of value then they add business value. I would recommend that you start by defining your actors and goals and go from there. Furthermore, you should also keep in mind that that time can and will be in actor.

Lastly, you may want to post your question in the engineering forum:

http://www.gamedev.net/community/forums/forum.asp?forum_id=34

Hope this helps.


Understanding is a three edged sword...



I have studied this book but the problem is that this book is about making software for some business problems that are manual before. This book focuses on automating business processes through RUP and JAVA.

In that example, POS system is something a running system ( a system which has a life in it. i.e Cashier is sitting there, customer comes, do some purchases etc.) In this way you are able to quickly think of Actors and Use cases and write stories for those use Cases.

In a 3D Game Engine, we dont have a real running system. Most likely, this 3D Game Engine will be implemented as a DLL exposing a set of APIs so that Game Developers use this API set and develop their Games.

This concept ends us with only One Real (Physical) Actor i.e. Game Developer and as you said "Time" can be an actor as well. So, if we take Game Developer as an Actor, it means each and every API exposed by Game Engine and used by Game Developer should be a use case ????

Naturally Use cases are stories. Stories of using the System. Actor does this. System do this. Actor does that. System do that and so on. Taking this concept, A GAME developed by a Game Developer using our Game Engine fits enitrely well to this definition of Use Cases. But another problem is how can a Game Engine developer be sure of what a Game developer think about a Game. What kind of Game, a game developer will be developing using this Game Engine.?????????

I think that Use Cases are not fit for Game Engines. We should rather describe the requirements in Feature lists (an old fashion.) It fits well in context of a Game Engine. for example,
1. It performs lighting
2. It gives sound support
etc. etc.

Also, I searched a lot of google but didnt find any material about "Use Cases for a Game Engine". Not an article and not a single book. One Article on gamedev was good about GUP (Game Unified Process).

Passionately waiting for replies....
I don''t think a use case is what you''re looking for. Perhaps an activity diagram would be more applicable in this scenario. Then, at least, you can describe the engine''s actions in terms of a rendering pass within a particular context, without worrying about all the external systems with which it interacts.

ld
No Excuses

I believe the examples you gave can be turned into use cases. When you say, it performs lighting, turn that into a use case talking about the types of lighting if performs and the reasons why certain types of lighting would be used in specific situations.

For a game engine you should think of the use cases at a higher level than defining each api call. You should instead define one more use cases for each feature type such as lighting, culling, etc. For instance, is your actor (the game developer) going to be developing in-door or outdoor scenes. Either could be the start of a use case describing a number of features in the engine.
quote:
I have studied this book but the problem is that this book is about making software for some business problems that are manual before. This book focuses on automating business processes through RUP and JAVA.


Interesting, I never realized that the code was in Java until you mentioned it; apparently I am able to make the translation so easily that it isn''t even noticeable. As for the book, it is the best book to start with for someone for wants to learn use cases, design patterns, sequence diagrams, class diagrams, and get a broad overview of the unified process.

quote:
In a 3D Game Engine, we dont have a real running system. Most likely, this 3D Game Engine will be implemented as a DLL exposing a set of APIs so that Game Developers use this API set and develop their Games.

This concept ends us with only One Real (Physical) Actor i.e. Game Developer and as you said "Time" can be an actor as well. So, if we take Game Developer as an Actor, it means each and every API exposed by Game Engine and used by Game Developer should be a use case ????


Now I am intrigued, if the game developer is the only physical actor; and I not sure why it matters whether an actor is physical or not, then you are basically writing the system for yourself and other developers. Do you think that a single API command adds measurable value? What if you sent an entire day executing the SetTexture command; would this add measurable value? On page 60 Craig Larman cautions against this by saying:

quote:
A common use case mistake is defining many use cases at too low a level; that is, as a single step, subfunction, or task with the EBP.


Keep in mind that a actor can also be an external system; that is you can draw the system boundary where every you would like. Since you are probably going to write some sort of interface to demo the functionality of your engine; why not write the use cases against this interface. For example, the user selects render QUAD and the system responds by displaying a QUAD in the center of the display.

As for whether use case or the UP is good for game development; the software engineering forum gets less than 3% of the post of the DirectX forum. Button line; if you can’t solve the problem than you should redefine the problem and solve it. That said, I guess the solution is to write the use case against a GUI that demos the power of your engine.

Hope this helps...


Understanding is a three edged sword...
_______________________________________Understanding is a three edged sword...Freelance Games - Home of XBLIG Starchonwww.FreelanceGames.com

Thanks for the replies. They are very much helping.

Lets put it another way...

If you have a 3D game engine with following qualities, how will you be going to use it???

1. Engine Core
--------------
This is the main part of the game engine that controls the execution of overall system. After staring the execution from the entry point of the application, this subsystem takes charge of the program and makes necessary initializations. The engine core is responsible for memory management and task scheduling. It also takes care of the communication between different components of the game engine. The engine core provides support for the following features
• Initialization of the game engine and subsystems
• Communication between engine and game application
• Memory management
• Task scheduling


2. Rendering Engine
-------------------
The core part of the game engine is this 3D rendering engine. This sub-engine provides support for rendering 3D objects while simulating the real world scenes. Representing 3D models and worlds on the 2D computer screen is part of this subsystem.
This area requires extensive graphics programming and use the DirectX API for graphical representations. This sub-engine provides support for the following features:
• Representation of graphical elements like faces, meshes and wireframe polygons
• Flat and Gouraud Shading
• Background and Color Settings
• Fog Effect
• Alpha Blending
• Lights and Materials
• Texture Mapping
• Environment Mapping
• Stencil Buffers


3. Animation Engine
-------------------
To demonstrate the game dynamics, the realistic behaviors of the game objects are supposed to be controlled by this animation engine, which is a sub-engine to the game engine. This sub-engine not only require the traditional techniques used in the game programming, like page flipping & back buffering, but also the advance 3D mathematics.
This animation engine is proposed to provide support for the following features as follows:
• Page Flipping and Back Buffering Techniques for animation
• Vertex blending for creating effects such as smooth joints and bulging muscles in character animation
• Color animation for glowing objects and blinking lights


4. Basic AI Engine
------------------
The built-in AI engine will be one of the core parts of the project. This sub-engine is supposed to make creatures in the game intelligent enough. The goal is to develop the learning capabilities of creates and enhance their decision making under different circumstances.
Although this area requires a tremendous amount of work on its own but under the stressed availabilities of resources, the basic AI features are proposed as follows:
• Deterministic algorithms for the simple objects in the game that have predefined behavior
• Patterns with logic programming and randomness for smart objects that are part of the environment like the flying birds
• Finite state machines for the important characters of the game with different states that represent different goals and motives. The states may involve sub-states according to the situation.


5. Physics Simulation
---------------------
Subsequent to the graphic engine, the physics laws for the objects of the game are proposed to be established in the game engine. The primary laws, based on the criticality of every game, which are chosen to be the elementary part of the project, are collision detection & blocking mechanism for the game objects.

This topic is closed to new replies.

Advertisement