Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 20, 2014
arrowPress Releases
August 20, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
A 10th Grader's Development Cycle
by Tony Yotes on 11/04/13 12:34:00 pm

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

 

     I find myself getting more efficient with this whole game making thing over time. Back in 10th grade I had no idea what I was doing, but was happy to finally have a general direction to run in. I found out games were made through programming, took a few Java classes, and went to Google for the rest.

 

     I figured out lots of things on my own, like object oriented structures and game specific things like animations, health bars, menu flow, music playback, and collision detection. What never crossed my mind back then was listening to how others created games. If I did, I'd know about certain things that just don't work and could have side-stepped a lot of problems. Also, my code would be legible.

 

Take a peek into the mind of my10th grade self.

 

 

     Back in 2009 my priorities were make something playable, then build on it every day. When in class, I'd draw out things I'd work on later. I was also working on four diverse projects at once to prevent myself from being bored or exhausted on any given project.

 

     I had a Dragon Ball Z RPG, a Zelda-style RPG, a Pokemon game, and an arcade game meant for iPads. Of all of those only 2 are going to see the light of day eventually. Another reason why I did four at once was for those frustrating times when I got stuck on a bug.

 

     Having multiple projects allowed me to switch to another one that wasn't broken until I got back to the first with a refreshed mind, often allowing me to find solutions I overlooked.

 

     My current way of doing things is a lot more efficient. Although I can still see merit in my former method, I don't think pushing problems and juggling too many titles makes for a happy development cycle.

 

So in short, my old way of doing things was:

  • Get Idea
  • Doodle on Paper
  • Make Placeholder sprites
  • Make a menu leading to gameplay
  • Make menu sprites
  • Dress up menu
  • Make simple gameplay loop
  • Edit sprites frequently
  • Build on everything until the game is done

None of these games got anywhere near completion. But I did learn a lot, built sprite making skills, and got a lot of excitement out of my system. 


Related Jobs

Disney Consumer Products
Disney Consumer Products — Glendale, California, United States
[08.20.14]

Contract Game Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.20.14]

Lead Network Engineer
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States
[08.20.14]

Animation Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.20.14]

Lead Software Engineer






Comments



none
 
Comment: