Gadzook! Robots! We’re Screwed!!
Platform: Ouya, Android, Mac, PC, Linux
Engine: LibGdx (Java)
I’m happy to finally post about my latest game, We’re Screwed!!. For seven months, as my senior project at UCSC, I conceived, pitched, recruited, prototyped, designed, lead, and coded this 2D puzzle platformer targeting the Ouya platform. Whew! Yes I worked very hard on the game. It was a crazy adventure watching my idea progress from a few words scribbled in a notebook to a full on digital game. You can download and read more about the game on the website. I’ve had ample time to think about my experience; rather than describe the whole development story here, I’m going to post some of the things I learned during the process.
- Disclaimer — I’m sure I experienced the same set of problems any game in the industry experiences, but since We’re Screwed was created in an educational environment, some problems were extremely amplified or distorted. Just keep in mind my entire team, including me, was new to making games in a large team (18 persons) so everything we did was an extreme learning process.
- Find the core mechanics during prototype phase — Know exactly which mechanics make up the core of your game during the early design and paper prototype phase. The mechanic(s) at this point are what make your game unique from anything else and are what players experience moment to moment. Any other features or mechanics can be dropped without losing the core idea of the game. These mechanics are what you develop first.
- Prepare to adapt the design and drop features often
- Create a digital prototype of the game in a couple weeks — Create a single level with rudimentary graphics. Play it over and over and solve the most glaring problems early on.
- Carefully choose your team - The senior studio class was intended to emulate creating a real game in the industry; my student team was a small business making a game with the overhead of a producer (the professor) and all. When choosing my team, I didn’t have the liberty of choosing members based on their skills like in a hiring process; I merely chose students based on what little I knew about them from other class experience. My team ended up having a hodgepodge of skill, motivation, passion, and dedication levels. This lead to all kinds of problems. Not knowing what my team was capable of skewed the scope of the game. We designed the game blind to the team’s capabilities so every feature was worked on if we thought we could pull it off in time.
- Assign roles early — Delegate roles and distribute responsibilities even before the team is formed. Recruit your producer, tech lead, level designers, UI designers, and art lead all based on skill level and experience. Each team member should be entirely clear on their role and what they are responsible for in the game. As the lead, you should oversee 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 portfolio or skill, I let all three join my team. One was a photographer, another a sculptor; all three had no digital art experience. Yes it was a nightmare for the first 6 months. I was so busy with designing and coding I hadn’t chosen an art style yet. I thought the artists were going to do that… Bad assumption! After months of the art going nowhere, I finally took maybe 10 minutes to browse deviant art to find an art style I loved. I quickly got the artists on board and they began creating beautiful concept art. After not too long, the artists were inspired and began creating real assets.
- Don’t spread yourself too thin — You need a role too, no matter how high up, and need to limit your responsibilities for sanity’s sake. I ended up being a core coder, art lead, manager, lead design, and creative director 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 during design — My team left sound and music until the last month and suffered for it. Games are a combination of design, visuals, and sound. Each part of a game including sounds should receive an equal amount of thought and design. Even if you’re team isn’t creating sounds from the beginning (which you should be) then you should at least be thinking 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 produced by my team sucked! I’m not sure how code review actually works out, but any amount of double checking of code sounds good to me. A good code base makes everything easier.
- Snacks - Food is more important than the game. Good snacks make your team so so so happy! It’s a worthy investment.
- Celebrate — Before during and after development. Enjoy your team’s company, appreciate them and appreciate how the game is bringing everyone together. Creation is a beautiful component of human nature and games are a wonderful expression that can be experienced by many.
- Take breaks and get grounded — Take 5 to 30 minute long breaks and get some air. Take day or weekend breaks and avoid actively thinking about the game. These breaks give you time to relax your brain to have a refreshed perspective for new and better ideas!
I sure wish I knew these things before creating the game. I know my next game will thrive after this immense learning experience.