HOW TO DEVELOP WITH

THE STUDIOIGDA at UAT

WHY YOU SHOULD JAM THIS WEEKEND

Don’t be addicted to brain crack

Fail faster

You need a fun minimum viable product

You need a core team

■ You need an experienced core team that commits to see this project through to completion. This is a good time to build that team if you haven’t already.– They aren’t in it for the class credit. They would gladly work on the

project for no course credit.– They aren’t in it for a portfolio piece. This project will be on their

portfolio but that’s not why they work on it.– They are in it because they want to make this game.– You enjoy working with them and know you can rely on them to get their

work done.– You should have at least one programmer and one artist on your core

team.

HOW TO PITCH YOUR GAME

What is a pitch?

■ A form of communication designed to persuade someone to buy or accept something.

■ See also: sales pitch■ You pitch to publishers to support development of your game (usually

with money).■ You pitch to developers to work on your game.■ You pitch to the press and players to get people to play your game.

Good Pitch Example

Another Good Pitch Example

Another Good Pitch Example

What do these pitches have in common?■ Concise – each pitch is about 3 sentences long and lasts 30 seconds.■ Memorable.■ High information density.■ A clear vision.■ Each pitch is pre-recorded.■ Do not use the words “innovative”, “new”, “good”, etc.■ Don’t focus on backstory.

How to practice your pitch

■ Practice your pitch in front of other people and ask them for feedback.

■ Your pitch is a separate project from your game jam game.■ Dedicate time to developing your pitch.■ Your pitch video has a five minute time limit. That’s a limit, not a

target. Aim for 30 seconds.

The Important Questions

■ Who are we?■ Who am I pitching to?■ What am I pitching?■ Why am I pitching that to them?

The value proposition

■ What does the university gain from what we’re pitching? What does that gain cost?

■ What do we gain from what we’re pitching? What does that gain cost?■ What do the game faculty gain from what we’re pitching? What does

that gain cost?■ What do other students gain from what we’re pitching? What does

that gain cost?

WHAT ELSE DO YOU NEED?

You need a product owner

■ That’s probably you.■ However, this is not your game – this is your team’s game even

though it may be your idea.■ You are not the boss.■ You don’t assign or estimate tasks.■ You are an advocate for the player.■ You don’t write code or create art assets as the product owner. You are

responsible for the project vision and product backlog.■ You must be willing to share control and ownership of your idea.

You need a vision

■ Your vision statement should effectively communicate the goals for the product■ What are your key goals? Do you want to explore emergent gameplay? Do you

want to experiment with new hardware? Do you want to create a new genre?■ Who is your customer? Who are you developing this game for?■ Why does your customer want your game?■ How does your game compare with similar games?■ What makes your game different or unique?■ Your pitch could almost double as your vision statement. Everyone who

sees this pitch should know what your high-level vision for the project is.

You need a product backlog

■ The product backlog is a prioritized features list. This is more useful than a design document because it communicates more data such as the perceived value of a feature, the estimated time to implement a feature, and project priorities – these will change over time as priorities shift.

■ Features at the top of the prioritized list will be worked on first.■ Features at the bottom of the prioritized list will be worked on last, if

at all.■ The game studio classes are using Axosoft. Let me know if you need

help getting a free Axosoft account sent up for your project after the presentation.

Decomposing project features & requirements■ You will be breaking down project requirements into a hierarchy of smaller and smaller

components.– Theme: A logical group of features. These should map to project goals in your

vision.– Features: High level parts of your game that describe a new capability the

customer were have when the feature is complete. These should be minimally described – they will be refined over time.

– Epic User Stories: Very large requirements that support a feature and contain multiple actions. This is part of release planning.

– User Stories: Requirements that contain a single action that is small enough to start implementing. This is part of release planning and sprint planning.

– Tasks: Execution steps to develop a requirement. The product owner most likely won’t be writing these. This is part of sprint planning.

How to write User Stories

■ General Template: As a _____, I want to _____ so that _____.– As an engineer, I want a bazooka so I can blow up tanks.– As a player, I want to shoot an enemy character and see it react

so that I know when it is hit.■ Conditions of Satisfaction:

– When the enemy is shot in the head, they stumble back.– When the enemy is shot in the left side, they twist left.– When the enemy is shot in the right side, they twist right.– The (lead designer/lead artist/etc.) must sign off on this task.

How to write good User Stories

■ Independent: User stories should be independent from other stories in the order they are implemented. Dependencies create problems that make them hard to prioritize and estimate.

■ Negotiable: Not a contract or a detailed requirement – user stories are a placeholder for conversation between stakeholders and team. Negotiable stories enable team members to suggest ideas and take ownership of their work.

■ Valuable: Stories need to communicate their value.■ Estimable: If the story is too large or not enough is known, then there will be

uncertainty about the size of this story.■ Sized Appropriately: A user story should be small enough to fit into one sprint.■ Testable: The story should be written so that it can be verified before the end of the

sprint. This means writing conditions of satisfaction that can be tested.

Commander’s Intent

■ User stories and their conditions of satisfaction should communicate your intent.

■ No plan survives first contact with the enemy.■ You need your team to know what to do when things don’t go

according to plan – you don’t want them waiting to be told what to do or uncertain how to progress.

■ Commander’s Intent is the definition and description of what a successful operation will yield. This allows team members to adapt and improvise when things don’t go according to plan and achieve the ultimate goal without you having to hold their hand each step of the way.

You need a ScrumMaster

■ That’s probably NOT you. Recruit a Game Production & Management masters student.

■ The Scrum Master is a facilitator.■ The Scrum Master handles any impediments that obstruct or slow

down the development team’s pursuit of sprint goals and release goals.

■ The Scrum Master might double as a developer, but ideally focuses exclusively on the Scrum Master role.

■ The Scrum Master’s typical job title in the industry is “Producer”

What is a producer?

You need a release plan

■ You need to have a release by the end of one semester.■ You will be presenting this publicly. The press will be there. Dedicate 1-2

weeks to polishing this build and fixing bugs if necessary.■ Your first release probably won’t be your complete game, but think of it as a

magazine demo and meet these expectations:– It has no major memory leaks preventing it from being played for an hour

or two.– There are no major missing assets. All stand-in assets are clearly

identified as such.– The game has a clean and usable user interface.– The player has a clear objective and experiences the fun of the game.

QUESTIONS?