Post on 31-Mar-2015
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