Archived

This topic is now archived and is closed to further replies.

s4shim

Writing Use Cases for a 3D Game Engine

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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....

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
I don''t think you want to put all the documentation for your engine in one place. I would split up the requirements document into several documents, one for each subsystem.

For example, you would have a requirements document for the EngineCore module. The use cases in this document would explain how the other modules will interact with it and how it will interact with the other modules.

For example, how is your rendering module going to access the "Task Scheduling" capability? In this case, the actor would be the "Rendering Module" and the use case would show how the actor (aka Rendering Module) would interact with the scheduler. Another example, how are Stencil Buffers going to interact with the "Memory management" capability. In this case, the "Rendering Module (or perhaps even the Stencil Buffers)" would be the actor.

Remember, an "actor" isn''t necessarily an actual person. An actor can be another subsytem or another "entity" of code that interacts with the current module.

There are a lot of interactions to think of. A game engine is no small matter. You need to know a lot of things. You have to worry about things like how the game object defined by the user is going to interact with the AI module (and perhaps the AI module requires functionality from the Physics Module). Pathfinding is going to have to know how to interact with the world and perhaps even the physics module if you are including things such as gravity, aerodynamics, or even fluid dynamics. The more functionality an engine implements, the more complicated it tends to be. Unless you can boil this down to an abstract "flyover" level, you will most likely fail. After all, there is a reason that really good engines sell for a lot of money.

I hope this helps at least a little bit.

----------------------------------

"English? English? Why would I need to know English? I''m never going to England!"

Share this post


Link to post
Share on other sites