Microsoft PowerPoint - EVE05_se-design by monkey6

VIEWS: 15 PAGES: 7

Microsoft PowerPoint - EVE05_se-design

More Info
									Software Engineering Based Approaches to VE Design

17 April 2008

Software Engineering Based Approaches to VE Design
Edwin Blake
Department of Computer Science University of Cape Town edwin@cs.uct.ac.za

Outline
This lecture focuses on using Agile Software Engineering methods to Design VEs
Major target for this design is the programmers

1. Iteration and its Implications for Design
Documentation

2. Use Cases in VE Design

17/4/08

SE Design

2

What is agile?
You should know! Method for developing products using short iterations Each iteration is like a self-contained project in itself Adapt the project plan continuously. Since we are talking about games: how about SCRUM?
17/4/08 SE Design 3

Agile Manifesto for Game/VR Development
People and Communication rather than Process and Tools

Working Game

rather than

Design Documentation

Customer Collaboration

rather than

Contract Negotiation

Responding to Change

rather than

Following a Plan

17/4/08

SE Design

4

Purpose of a Design Document
Designers want to share their ideas The team (including programmers) want to know what they’re building. Problem: Most documentation processes ignore the iterative nature of effective development.

Documentation Goals
Capture design consensus Primary communication medium Aid in scheduling Offer focus Give visibility to future dependencies and design conflicts

17/4/08

SE Design

5

17/4/08

SE Design

6

1

Software Engineering Based Approaches to VE Design

17 April 2008

The Challenges
VEs/Games are complex, interconnected systems. Designers tend to overdesign.
Systems take less time to design than to build.

Embrace Iterative Design
Design the next immediate phase to fine-tooth detail Design far off phases to man-month degree Don’t allow designers to emotionally invest in far-off features Revisit documentation as the design shifts and iterates.

Keep up to date as the project progresses. Embrace iteration …

17/4/08

SE Design

7

17/4/08

SE Design

8

Target
People interested in a design doc:
Design team. To achieve design consensus. Programming team. To build the game. Producers. To schedule and go get money. QA. To build test plans. External partners. To reach quota of annoying demands.

Programmers
Programmers: (the most?) important target.
It’s how the system gets made. Other documents are more useful for other audiences. When in doubt, make the docs serve the programmers

Ask the programmers what they want
If they say to ignore one of my rules, do it!

17/4/08

SE Design

9

17/4/08

SE Design

10

Keep it Short
Short documents are:
Easier to read Easier to write Easier to maintain and keep up-to-date Easier to handle politically Less likely to be contradictory More likely to be simple designs

Who Cares?
Crafting Tithe. Hephaestus, the god of the forge, has instituted his will upon the craftsmen of Athens, and all are humbled by his greatness. As such, any players who wish to craft any items must pay a tithe to the temple of Hephaestus to earn his favor, unless that player has found an item like the Hammer of the Gods, which allows the player to bypass these tithes.

17/4/08

SE Design

11

17/4/08

SE Design

12

2

Software Engineering Based Approaches to VE Design

17 April 2008

Better
Crafting Tithe. Players who craft items must pay a cost in gold (a tithe to the local temple) when crafting.
Bypassing tithes. Certain tools allow the player to bypass the tithe.

No Weak and Vague Language
Players might be able to woo NPCs of the opposite sex. In the future, we may add the functionality to increase your chances to woo women by playing sappy love songs. If this is implemented, maybe players can write their own love songs.

17/4/08

SE Design

13

17/4/08

SE Design

14

Better Language
Romancing NPCs (Prototype) Players can attempt to romance NPCs of the opposite sex by dialogue options Players can also attempt to romance NPCs of the opposite sex by serenading them with songs they’ve learned. Advanced Romance (Phase Four) Players can craft their own songs for use in the romance system.
17/4/08 SE Design 15

Keep it Short for Programmers
Remember:
Programmers almost always want a short bullet list
They kind of like checking things off of lists

17/4/08

SE Design

16

Prioritize the Design
Give the features a priority, break them into phases Be sure document clearly separates out later phase features. Phase 1: Prototype feature
(necessary to validate or demo the game)

Illustrate
Pictures. Tactics:
Screens of other games with similar features. Visio diagrams ‘Example’ text

Phase 2: Core feature.
(features and tools that hold up content creation go here)

Phase 3: Must be in shipped product
(includes features that depend on priority 2 features)

Phase 4: Wishlist, possibly expansion Phase 5: Yeah, right
17/4/08 SE Design 17 17/4/08 SE Design 18

3

Software Engineering Based Approaches to VE Design

17 April 2008

Stick Figures Preferred
The more abstract a picture is, the easier it is for a reader to project his own viewpoint Assuming you have a competent artist, you want to give his imagination room to breathe – don’t try to do his job!

Make it Searchable
Design docs will only be used as a reference if the user can find what he needs. Possible means:
Wiki Desktop Search Design Bibles

17/4/08

SE Design

19

17/4/08

SE Design

20

Automate what you can
Advantages of Documentation Automation:
Accuracy Searchable Easy to add auditing and reports

Use Cases
Independent — doesn’t overlap other user stories Negotiable — details and implementation are less important than end user satisfaction. Valuable — written with the end user in mind. Estimatable — detailed enough for programmers to architect & schedule Small — no more than a week. Testable — design and programming can agree when it’s done.

17/4/08

SE Design

21

17/4/08

SE Design

22

Use Cases and Use Case Scenarios
Use cases are a tool for the design of the dynamic behaviour of a virtual environment. A use case is a single task that has some desirable outcome,
performed by the user of a virtual environment. prompts the designer to understand the system from the users’ point of view. allow members of the design team to communicate with end users about the envisioned system.

Name
Imagine a virtual environment, which models a market.
One use case for this virtual environment is buying a map to navigate the market

All use cases need a Name
This identifies the use case uniquely and describes what it accomplishes. A typical structure is a verb followed by a noun, e.g. ‘buy a map’. The name should describe the user action, not the system response, e.g. ‘make payment’ instead of ‘accept payment’.

Identifier
Some large projects give each use case a unique numerical identifier, so that it can be referenced easily.

Together the Use Cases provide a complete picture of the system functionality
17/4/08 SE Design 23 17/4/08

SE Design

24

4

Software Engineering Based Approaches to VE Design

17 April 2008

Description
Describe what the use case accomplishes in detail
but not describe details of how a particular implementation would work This should describe the flow of the use case, in terms of the steps that must be taken to complete it successfully. the user asks a vendor for a map, pays for it and gets the map.

Participants/Roles/Assets
These are the roles within the use case.
Each role not necessarily a separate actor
one actor may perform many roles.

Desired Outcome
Describe what the useful outcome of the use case is. This could be a tangible output, or an event or condition. the user gains a map of the market.

List the responsibilities (in a separate document)
of each actor when in a role who the actor must communicate with (collaborators) Cross-reference with actor’s asset forms.

User Goals
The goals tell why the user is performing the use case This is different from the ‘What’ of the desired outcome. the user will be able to navigate more easily around the market and find out where interesting stalls are.
17/4/08 SE Design 25

An actor can be a user or part of the VE itself
Roles in the example are the vendor, the user, the money and the map.
17/4/08 SE Design 26

Use Case Dependencies
Use cases are useful for discovering dependency relationships in the VE Dependencies include:
1. Subset/Combines Top-level case combines small subcases 2. Uses/Is-used-by (Includes) As above except subcase is larger with a useful outcome 3. Precedes/Follows Use cases form a sequence 4. Requires As above, except it must precede the current one (dependency) 5. Extends/Is-specialization-of

Subset ◄► Combines
A subset use case (subcase) is a small task into which the more complex top-level use case can be broken down.
Subset
larger use case can be broken into subsets

Combines
smaller use cases can be combined into a larger one.

Diagrams can show dependencies between use cases and objects involved.
Use floorplan or map
17/4/08 SE Design 27 17/4/08

Subcases of the “buying a map” example use case might be ‘pay vendor’ and ‘request map from vendor’.
SE Design 28

Uses ◄► Is-used-by (Includes)
This is similar to a subset/combines relationship, except that the subcase is also a standalone use case with a useful outcome.
For example, if the vendor is someone that the user must interact with frequently in the VE, ‘request map from vendor’ might become ‘communicate with vendor’
the vendor will recognize the user later, which is the desired outcome of the included use case.

Precedes ◄► Follows
This places use cases in a sequence, which can guide the flow of the program.
For example, ‘buy a map’ precedes ‘find location X in the market’

17/4/08

SE Design

29

17/4/08

SE Design

30

5

Software Engineering Based Approaches to VE Design

17 April 2008

Requires
This is similar to the Precedes relationship, except that it indicates dependency, in that a use case MUST precede the current use case.
For example, ‘buy a map’ requires that the ‘find map vendor’ use case has completed successfully.

Extends ◄► Is-specialization-of
Use case A extends use case B if it adds subtasks and operations to B. A is therefore a specialization of B, which often implies a special requirement that doesn’t occur in normal operation.
For example, ‘buy a VIP map’ might extend ‘buy a map’, as the user might need to know the correct password to get the extra information.
The process would remain quite similar to the normal case.

17/4/08

SE Design

31

17/4/08

SE Design

32

Preconditions
These are assumptions about the state of the world when the use case happens. Conditions that must be met before the use case can occur.
For example, the user must be in the vendor’s area of the market before she can buy a map.

Scenarios — Use Case Instances
Scenario is a use case instance we choose to model
Description of someone working through the use case A use case can have several scenarios.

‘happy-path’ scenario
Everything in the use case happens as desired Very similar to the description of the use case.

Others may be failure scenarios or alternatives
allow you to think of recovery or adaption

Scenarios also allow the VE to be presented to others
Initially a simple list of actions. Can use diagrams to visualise the steps in the scenario
17/4/08 SE Design 33 17/4/08 SE Design 34

Example: Alternative Scenario
Alternative in the map-buying use case:
The user approaches the vendor and asks for a map. The vendor quotes a price but the user does not have enough money. The user tries to bargain but does not have anything the vendor wants The vendor turns the user away.

Postconditions
A list of the conditions that must be true after the use case has completed successfully.
A use case might change the state of the system. Also, a use case might need to be followed by others in order to complete a task.

Designer might become aware that the user could substitute goods for money, and so barter. New concepts or objects that appear in scenarios will often suggest holes in the design.
17/4/08 SE Design 35

For example, if the map-buying use case is completed successfully,
1. the user will have an accurate map of the environment, 2. the vendor will have one less map to sell (this might apply in a collaborative virtual environment) and 3. the vendor will recognise the user when they meet again.
17/4/08 SE Design 36

6

Software Engineering Based Approaches to VE Design

17 April 2008

Status
This states how much of the use case has been implemented. Implementation Notes This is where implementation ideas that occur to you while working through the use case can be recorded. For example, how the system might represent the map to the user.

Scenarios Before Use Cases?
Compiling of a complete list of use cases for your VE is a difficult task. One way to make this easier is to begin by exploring scenarios first.
tell stories about how the user might approach the VE done very informally

Each one of these stories will be a scenario
will fit into one or more use cases.

Sequences of scenarios can be developed for the VE The cardboard lab or some other form of visualisation, may help to work through the scenarios.
17/4/08 SE Design 38

17/4/08

SE Design

37

General Tips on Use Case Design
Write from the point of view of the user or actor. Describe actions, not features of the system. Do not consider implementation at all
Except be aware of constraints. Use cases are about how the user experiences the VE

Use user stories
The player gains a level when he crosses the experience point threshold.
The player hears a ‘ding’ sound effect. The player sees a particle effect. The player gains 5 attribute points to be spend on his stats. The player gains 3 skill points to be spent on his skill tree. If the player has reached level 10, he can acquire his Prestige Class
17/4/08 SE Design 40

Go back to use cases and change them, or add to them, as aspects are revealed.
Part of the iterative process of design.
17/4/08 SE Design 39

Final Remarks
Design Documentation is a collaborative Process Always start with a Kickoff Meeting
What are the goals of this system? What are the questions this document should answer? How complex can this system be?

Small Game Example: Small Arms
“’Small Arms’ is an intense but simple multiplayer brawling game with the action and precision of an arcade shooter. Players can jump from platform to platform shooting each other to pieces with 360° aim…” 2 programmers, 2 artists External audio team Approx. 1 year in development 12 unique characters, 8 fighting arenas Online/Offline multiplayer focus

Have an Approval Process Mandate expert consultation — seek out resident experts:
Other designers on the team. The engineer who is building the feature. Artists or programmers with unique expertise The ‘customers’
17/4/08 SE Design 41

17/4/08

SE Design

42

7


								
To top