Indie and Casual Game Development

Windows Phone 7.5 “Mango”Cloud-Backed Mobile ApplicationsXNA-free Game Development

MARQUEE SPONSOR

PLATINUM SPONSOR

PLATINUM SPONSOR

GOLD SPONSOR

GOLD SPONSOR

GOLD SPONSOR

GOLD SPONSOR

GOLD SPONSOR

GOLD SPONSOR

SILVER SPONSORS

Agenda

Who am I? Building Casual Games Multiplayer Gaming Case Study : Demo Case Study : Code Tour Lessons Learned Q&A

Who is this guy?

Casual, Mobile Games are Different

Boredom often impetus to play Users can get interrupted frequently and

unexpectedly Users often play with limited concentration Touches are clumsy with huge target zones Just because you can hold a phone like a

joystick doesn’t mean it is one. Touch isn’t the only input – phones have

accelerometers, compasses, GPS, etc. Network is not always available, or reliable

It’s All About the Dopamine Many successful games are “dopamine squirters”

Periodic, positive reinforcement Achievements Leaderboards “Nags” (come play me!) Measurable, identifiable, frequent progress

Deliver your dopamine in small, frequent doses Give users a reason to come back to your game Your app should be “part of the problem” of smart

phone addiction. Players will play anything if they can advance,

compete, or compare. e.g. “ProgressQuest”

Don’t Re-Invent the Wheel Don’t re-fix well-known, solved

problems: Data Access & local storage Web upload and download User configuration & settings Animated & flowing UI Audio & video

Open Source & Free libraries Code Samples are everywhere

Google is your friend

Standing on the Shoulders of Giants

Not a good enough artist? Crowdsource one. 99designs.com

Open Source libraries JSON REST/HTTP CouchDB Clients Silverlight/WP7 controls (e.g. Control Toolkit) Codeplex.com

NuGet (Library Package Dependencies)

Multiplayer Gaming

Many kinds of multiplayer Cooperative vs. Competitive Real-time vs. Turn-Based

Player discovery (e.g. “lobbies” and “matchmakers”)

Chat Push Notifications

React in real-time to player actions, even for turn-based games

Multiplayer Coding

Real-Time Multiplayer Typically lower level, often hand-coded Sockets

Pseudo-Real-Time Push Notifications via Microsoft & WP7 SDK

Turn-Based Push Notifications

Cloud-based middleman for phone-to-phone comms. Exceptions include local WiFi discovery of nearby phones

– very ugly code. You need “code in the cloud” to send push

notifications.

Choosing a Backing Server Do you even need one? If so:

RESTful Ruby via heroku.com WCF via any # of hosts, including AWS EC2 WCF via Windows Azure WCF via AppHarbor (see demo) PHP or others on other hosts AppHarbor & Heroku: git push FTW.

Cloud databases are everywhere SQL Azure, SQL in EC2, SQL on AppHarbor,

CouchDB

Game UI

Metro games use XAML HTML available for Metro games on Windows 8

Rich, storyboard-based animation library Built-in support for 3D, perspective

transforms Audio/Video APIs, Media support in XAML Touch & Gesture recognition available in

non-XNA apps Phone chock full of sensors & hardware

that can be used by games

What about XNA?

XNA isn’t necessary for smaller, casual games XNA 2D is sprite-based using a “game loop” XNA 3D is vastly more complicated Your goal is to produce gameplay not content

Only pick XNA if its required to support the gameplay for your idea!

Xbox Live libraries can be used from Silverlight Still need an agreement with MSFT for XBL

achievements and gamerscore

Indie Game Development Rules If it feels like work, stop doing it.

Your game must be as fun to build as it is to play Iterative, agile process

Build a core nugget of functioning gameplay Pause, briefly, to clean up & refactor Repeat for each tiny gameplay unit Add finishing touches after essential gameplay is done

(“Perfect is the enemy of done”) Your time is your capital

Favor pay-per-use, pay-as-you-go, and especially free services

Game design influences architecture, not the other way around

Case Study: Go Battle

Approx. 25 hours of coding time Multiplayer, head-to-head, turn-

based strategy In-game chat Push Notifications Log of games stored Player profiles Future support for achievements,

leaderboards, tourneys and ladders

Go Battle

DEMO

Go Battle Architecture

MVVM pattern (not library) WP7.5 Client WCF Web API hosted in AppHarbor

Secure, JSON, RESTful services expose resources to facilitate gameplay

User Profiles in a CouchDB database Games (ongoing and past) stored in

CouchDB database User security via ASP.NET Membership

Provider Membership DB in AppHarbor-hosted SQL DB

Up-front cost: $0

Go Battle : Lessons Learned WCF Web API dramatically reduces development time

Built-in web-based JSON-aware test harness saved incredible amounts of time and effort.

Used harness to simulate other player(s) as game was being developed.

CouchDB JSON documents are tailor-made for agile dev Could rapidly change my data structure without mucking

with foreign keys, queries, etc. Easy to upgrade docs as app version changes Map/Reduce custom JavaScript views are efficient Developer can stay object-oriented the whole time▪ No extraneous joining tables, etc.

Go Battle: Lessons Learned (2) JSON, flexible, RESTful services

“Piece of cake” to add support for iPhone, Android, iPad, Windows 8

Apps can be beautiful w/out being 3D Cloud Services like AppHarbor make

games like this easy! WebClient has “issues”, be wary.

Suppresses RESTful HTTP response codes Caches aggressively, can create ‘stale’

service results w/no errors.

Go Battle: Next Items

Proper use of navigation service Local data caching (AgFx?) Network detection (LittleWatson?) Google Analytics Network download/progress indicator Tolerance of raw notification delivery failures Split to multiple assemblies to speed up load

time Update detection (track last launched version) Crash detection & Reporting Marketplace Review Nag Transitions, animations, “fit and finish”

Go Battle

Q&A