Jump to content
  • Advertisement
Sign in to follow this  

Rendering engine use-cases

This topic is 2856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


I am trying to design (and implement) simple software rendering engine, but I want to do it "by the book" - using some methodology (unified process or waterfall for example - this is one-man small project so I think waterfall is ok too). My primary goal is to complete project using chosen methodology.

Engine will have scene-node manager that will serve as interface to 3d application, so that renderer is decoupled from 3d application. So it's some kind of two-tier architecture:

application - scene manager - renderer

I don't want application to know about renderer.

That said, I have questions about requirements phase, that is similar in both aforementioned methodologies:

1) When I write use-case stories who should be an actor? I guess it is application, because it has behavior and it communicates with scene manager (that is system)?

2) If I choose application as actor, and scene manager as system, I will end up with use-case stories such as "Application calls scene manager to set up camera on some position". That way I will have good understanding of scene manager requirements, so I will be able to design it. But I am wondering about renderer itself. These stories will not give me enough information to design a renderer. If I want to get more information about renderer, I would need to chose scene manager as "actor" and renderer as "system".
In other words, I am wondering if it is ok to separate requirements phase in this way? First you chose one actor on higher level, and another actor as you go deeper into the system?

Thanks in advance!

p.s. sorry for my bad English.

Share this post

Link to post
Share on other sites
In my experience, use cases are best to capture a customers requirements when you have real (second party) customer that not always knows what they want.

If you are the product owner I think you would gain more just imagining what your software should from users perspective and write down requirements one by one.

Then you will end up with a bunch of functional requirements, adding non functional requirements with that as a base together with any other wishes/implications/contraints should not be hard.

Share this post

Link to post
Share on other sites
Use case "actors" are people. The involved people that care about your engine's design are:
- the player using your engine to play a game
- someone running a server or other game client over the network
Stretching the concept of actor a bit,
- programmers using your engine to write a game
- testers inspecting a game based on your engine
- possibly someone marketing your engine

Most interesting design use cases are going to be about how can a programmer implement feature X "well" using your engine.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!