We’re Screwed!!


Gad­zook! Robots! We’re Screwed!!

Plat­form: Ouya, Android, Mac, PC, Linux

Engine: LibGdx (Java)

I’m happy to finally post about my lat­est game, We’re Screwed!!. For seven months, as my senior project at UCSC, I con­ceived, pitched, recruited, pro­to­typed, designed, lead, and coded this 2D puz­zle plat­former tar­get­ing the Ouya plat­form. Whew! Yes I worked very hard on the game. It was a crazy adven­ture watch­ing my idea progress from a few words scrib­bled in a note­book to a full on dig­i­tal game. You can down­load and read more about the game on the web­site. I’ve had ample time to think about my expe­ri­ence; rather than describe the whole devel­op­ment story here, I’m going to post some of the things I learned dur­ing the process.

  • Dis­claimer — I’m sure I expe­ri­enced the same set of prob­lems any game in the indus­try expe­ri­ences, but since We’re Screwed was cre­ated in an edu­ca­tional envi­ron­ment,  some prob­lems were extremely ampli­fied or dis­torted. Just keep in mind my entire team, includ­ing me, was new to mak­ing games in a large team (18 per­sons) so every­thing we did was an extreme learn­ing process.
  • Find the core mechan­ics dur­ing pro­to­type phase  — Know exactly which mechan­ics make up the core of your game dur­ing the early design and paper pro­to­type phase. The mechanic(s) at this point are what make your game unique from any­thing else and are what play­ers expe­ri­ence moment to moment. Any other fea­tures or mechan­ics can be dropped with­out los­ing the core idea of the game. These mechan­ics are what you develop first.
  • Pre­pare to adapt the design and drop fea­tures often 
  • Cre­ate a dig­i­tal pro­to­type of the game in a cou­ple weeks — Cre­ate a sin­gle level with rudi­men­tary graph­ics. Play it over and over and solve the most glar­ing prob­lems early on.
  • Care­fully choose your team - The senior stu­dio class was intended to emu­late cre­at­ing a real game in the indus­try; my stu­dent team was a small busi­ness mak­ing a game with the over­head of a pro­ducer (the pro­fes­sor) and all. When choos­ing my team, I didn’t have the lib­erty of choos­ing mem­bers based on their skills like in a hir­ing process; I merely chose stu­dents based on what lit­tle I knew about them from other class expe­ri­ence. My team ended up hav­ing a hodge­podge of skill, moti­va­tion, pas­sion, and ded­i­ca­tion lev­els. This lead to all kinds of prob­lems. Not know­ing what my team was capa­ble of skewed the scope of the game. We designed the game blind to the team’s capa­bil­i­ties so every fea­ture was worked on if we thought we could pull it off in time.
  • Assign roles early — Del­e­gate roles and dis­trib­ute respon­si­bil­i­ties even before the team is formed. Recruit your pro­ducer, tech lead, level design­ers, UI design­ers, and art lead all based on skill level and expe­ri­ence. Each team mem­ber should be entirely clear on their role and what they are respon­si­ble for in the game. As the lead, you should over­see each of these heads to make sure their work is going well.
  • Hire skilled artists intrigued with the art style - There were so few artists at my school I couldn’t choose based on port­fo­lio or skill, I let all three join my team. One was a pho­tog­ra­pher, another a sculp­tor; all three had no dig­i­tal art expe­ri­ence. Yes it was a night­mare for the first 6 months. I was so busy with design­ing and cod­ing I hadn’t cho­sen an art style yet. I thought the artists were going to do that… Bad assump­tion! After months of the art going nowhere, I finally took maybe 10 min­utes to browse deviant art to find an art style I loved. I quickly got the artists on board and they began cre­at­ing beau­ti­ful con­cept art. After not too long, the artists were inspired and began cre­at­ing real assets.
  • Don’t spread your­self too thin — You need a role too, no mat­ter how high up, and need to limit your respon­si­bil­i­ties for sanity’s sake. I ended up being a core coder, art lead, man­ager, lead design, and cre­ative direc­tor for the project. I was spread so think I could only halfway work on any one role. In a big team, this can be avoided and should be.
  • Keep music and SFX in mind dur­ing design — My team left sound and music until the last month and suf­fered for it. Games are a com­bi­na­tion of design, visu­als, and sound. Each part of a game includ­ing sounds should receive an equal amount of thought and design. Even if you’re team isn’t cre­at­ing sounds from the begin­ning (which you should be) then you should at least be think­ing about it from the beginning!
  • Code review — My team didn’t code review. I still have never code reviewed in a team. But some of the unchecked code being pro­duced by my team sucked! I’m not sure how code review actu­ally works out, but any amount of dou­ble check­ing of code sounds good to me. A good code base makes every­thing easier.
  • Snacks - Food is more impor­tant than the game. Good snacks make your team so so so happy! It’s a wor­thy investment.
  • Cel­e­brate — Before dur­ing and after devel­op­ment. Enjoy your team’s com­pany, appre­ci­ate them and appre­ci­ate how the game is bring­ing every­one together. Cre­ation is a beau­ti­ful com­po­nent of human nature and games are a won­der­ful expres­sion that can be expe­ri­enced by many.
  • Take breaks and get grounded — Take 5 to 30 minute long breaks and get some air. Take day or week­end breaks and avoid actively think­ing about the game. These breaks give you time to relax your brain to have a refreshed per­spec­tive for new and bet­ter ideas!

I sure wish I knew these things before cre­at­ing the game. I know my next game will thrive after this immense learn­ing experience.



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>