Adam Moore goes over what it takes to be greenlit for the UAT Game Studios courses.

1. HOWTO DEVELOP
WITHTHE STUDIO
IGDA at UAT

2. WHYYOU SHOULD JAM
THISWEEKEND

3. Don’t be addicted to brain crack

4. Fail faster

5. You need a fun minimum viable product

6. 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.

7. HOWTO PITCHYOUR
GAME

8. 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.

9. Good Pitch Example

10. Another Good Pitch Example

11. Another Good Pitch Example

12. 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.

13. 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.

14. The Important Questions
■ Who are we?
■ Who am I pitching to?
■ What am I pitching?
■ Why am I pitching that to them?

15. 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?

16. WHAT ELSE DOYOU
NEED?

17. 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.

18. 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.

19. 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.

20. 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.

21. How to write User Stories
■ GeneralTemplate: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.

22. 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.

23. 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.

24. 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”

25. What is a producer?

26. 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.

27. QUESTIONS?