My way of doing things is certainly evolving over time. I often try to find new ways to do things more efficiently and it's starting to pay off. I was able to make Candy Shop Catch in 5 weeks as opposed to my other mobile games which took multiple months each.
I think of it as another aspect of game development I'm practicing: production. I'm improving my art, programming, and design skills, so my production skills should be no different. Check out how I get things done by tapping that "More" button below!
In list form:
- Disorganized Notes
- Sit on Idea
- Cement Details
- Game Design Document
- Placeholders (if necessary)
- Art & Sound Assets
- Write Code Logic on Paper
- Make Adjustments
- Make Unity Mock-Up
- Basic Gameplay Loop
- Follow GDD
- Flip the Hype-Switch
- Publish
- Seek Reviews
- ???
- Profit
In paragraph form:
Disorganized Notes
The first thing I do is scribble out everything I think up on my iPod's notepad app. That way, it's always with me in case I get a random idea at a random time in a random place. It's also helpful because in order to put it in a nice Word Document for safekeeping I need to email it to myself and download it on a PC. That gives me a chance to proof read it and I often find that things that sounded good in the heat of the moment are often terrible ideas.
Sit on Idea
After I feel like I've got everything out of my head, I let the idea sit. I think of it as cooking over a low flame fr a long period. I let the idea mature in my head, making little revisions in my head so when I go back to the notes later I can decide what ideas are worth keeping in the game.
I keep games in this stage and the first for ridiculous amounts of time. There are some games in my mind that I don't plan to start for at least 6 years. But really, what game designers doesn't have ideas pouring out of their heads? It's all about picking the ones that could be executed the best with your current ability and resources.
When my current project is finished, I choose one of my simmering ideas to work on next. I base my decision on what I think I could do well based on my skill level. If I don't completely believe I could make the game I imagined in the notes, I'll let it sit longer and choose something more feasible. I learned early on that biting off more than I could chew left me with sore jaws and a chunky mess where my game was supposed to be.
After I pick out my next project, I type the notes into an organized word document and write a few paragraphs describing what the game is. I call it the game focus and use it to make sure I have a concrete idea to go by, then base a design document around it.
This is the part where I scrap a lot of ideas, shrink the scope, and sometimes completely change the game's direction, theme, and/or control scheme.
Once I have my main idea, I start finalizing things in a Game Design Document (GDD). I write what is essentially a bible & instruction booklet for making the game. I include every detail possible aside from line-by-line code. I even write up the press information I'll need (Descriptions, one sentence summaries, review requests, etc.) in a Press Document.
I lay out menu flow, the gameplay loop, any art, sound effects, and music I'll need, all objects I'll need to create, examples for important lines of code, a list of important methods and variables, and most importantly (to me) a schedule.
That schedule is what keeps me moving throughout the project. I even copy it to my iPod's notepad just to keep it with me. I habitually look at it every day to see what I need to get done that day. I have a general timeline outlining what to work on every two weeks or so, but I also have a day-by-day to-do list I keep on my notepad. I mark my iPod calendar with the general timeline so I get a little message every Sunday telling me what to focus on for that week. My day-by-day list is a small list of things to do in the span of time given by the general schedule.
My little list helps me a lot with staying on task and feeling like I'm progressing because every time I accomplish a small task I erase something from the list and see it become smaller and thus, more possible to finish. So, instead of seeing "Draw Player Sprites" on my general schedule I see "Draw:" followed by "Idle", "Walk", "Attack", "Left", and "Die" on my to-do list and it feels so much easier to digest.
I heard on a podcast by Joe Method that if you just work on something, anything, no matter how small, for your game everyday, it will eventually get done. I took it to heart and I feel it working. A big problem with making games is never being able to finish them. With my current process I eliminate that by working out everything I'm going to do in advance by having the GDD that won't change and just chipping away at the list from there.
I can't stress the importance of concept art enough. It helps infinitely to have even just a doodle of what everything looks like ahead of time. Especially if multiple people are involved and you need to unite under a single idea. Having doodles of game screens also helps with object placement when it's time to make mock-ups and a prototype.
The GDD calls for an asset that I know will be difficult to make or find, I'll make a placeholder of approximate size/sound to replace later on. For Fish Feaster, it was the boxes representing fish sprites. I often use music files from other games as placeholder background music to find a proper mood to match what's happening on screen.
I tend to find all the public domain sound effects I need on freesound.org and free music on incompetech.com. Any sound effects that I can't find are made by me making noise into my computer's microphone or mixing sounds in Audacity. I usually cut background music files down in audacity and make short edited loops out of the to save memory and sound slightly unique. I also save all the files as compressed mp3s in order to keep the total file size tiny. With mobile games, space is limited so it's best to keep my app's size down.
I draw all sprites using Gimp and Microsoft Paint. I like Gimp for it's advanced Photoshop-like features and MS Paint for it's simple interface that's perfect for basic sprite making. I used to draw all my sprites out in a grid and even re-sized them by hand. That was dumb. I learned that there is never a reason to draw the same image twice. Every sprite is separate now, I flip and re-size them by code, and even break down objects into individual moving pieces if I have to. All those SNES sprites of segmented monsters make sense to me now. It's good for memory and easier on the artists.
It's also very important to draft things on paper, then MS Paint in order to get sizes and placement just right before making things look pretty. The number of decent sized buttons that can fit on screen can be smaller than you think.
It's also very important to draft things on paper, then MS Paint in order to get sizes and placement just right before making things look pretty. The number of decent sized buttons that can fit on screen can be smaller than you think.
I'm still looking for an efficient way to make an SD & HD version of my games at the same time however. With Candy Shop Catch I tried having a global variable called "isHD" determine which sprite to display on screen, but it means either a bigger or smaller copy of it exists in the game's file. I definitely need to figure something out before making a giant RPG because file size and memory will be very sacred for that type of experience.
I write out what I'm going to code so that when I code my code has less bugs to un-code. That make sense? I like to write it out and use paper, pencil, and a calculator to make sure the logic makes sense, that way I only have to deal with syntax problems for the most part.
Writing out code also helps me make it look nice when I type it in because I don't get that subconscious "It looks fine" feeling and leave messy code behind. I can't count how many times I've done long debugging sessions and finally solved the logic problem, only to leave the code immediately and section it off to never be touched again.
Most time spent coding is on fixing problems you never expected to have and it's best to minimize having those problems altogether. Debugging is also the reason why I always give myself 20-30% more time on my project schedule to get things done. I usually spend all that extra time fixing annoying-little-things-that-make-no-sense-and-need-to-DIE!!
If I find logic problems that conflict with the design laid out in the GDD, I usually change it here. For Candy Catch it was the algorithm for making candy fall, which I rewrote about 6 times until I found the most efficient way to do it. And even that had bugs I needed to fix at run-time. It's really interesting seeing how the GDD for the code and the final code's structure are so different. IT's why I'm going to be more general about the code in the GDD from now on. I can lay out the systems I'll need and fill in the details as I need to code them.
I use the Unity engine to make games. It's easy. It's magical. It's fun. It's free. And It's full of surprises. I just drag & drop objects and have a working interface and gameplay screen in a matter of minutes instead of the hours it took me with Cocos2d.
After I place things where they need to be, I spend some time adjusting the layout to look the most pleasing and easy to use. I form all the objects I'll need to manipulate by code in this stage of development so I only have to dig into my development toy box and make them all move and act the way I want. I basically get everything ready to fit around, and evolve with, the gameplay loop.
This is the fun part where my starts to look like a game. I start making the meat of the sandwich and form the game loop written out in the GDD. I use all the pre-created assets and code whatever I need to make the game work.
The bulk of development time is spent here, working on my game little by little. School gets in the way a lot, but I find a way to get something done every day. My to-do list keeps me going through this stage and I can watch my game grow from concept to reality.
I can liken the feeling to a mother watching her baby grow, a wizard conjuring a creature from a book, a baker making a cake, or Red obtaining a Charmander and raising it to become a god of destruction.
I usually combine this step in my development cycle with the previous one. I announce the game on my blog and start talking about it more openly. I also try to find time to make publishing & press assets like app icons and banners to put up on my site and anywhere else I'm found on the web. I usually post the game's focus/introduction document on my blog once I feel like I could make it before (and better than) any potential copy cats.
I also hold off on announcing the name of the game until release is relatively close and use a "Working Title" name instead. I can't believe how many times a name I wanted to use was taken. With millions of apps and games in existence, unique names are harder to come by. That's also why I make a list of potential names in my design document with the exception of the name for my dream game (the RPG I'm making next year) which I trademarked over the summer.
This is also when I update the thumbnails on my website which are images of my latest and upcoming games linking to their app store locations. The newest game gets the orange "New" label and the upcoming game gets the blue "Coming" label.
When my baby is complete I jump around and scream for a few minutes, then build & run one last time before uploading the APK to Google Play and using my Press Document to enter in all the information Google Play requests.
I always do Apple second because of their long review times and fickle requirements. It's a matter of inconvenience really and I don't think I need to reiterate on why I don't like publishing on iTunes just yet.
The day after my game is uploaded I check it out to see if it shows up in the store's database. If it does, I open up my list of Android review sites and use my Press Document to spread the word and try to get sites to consider reviewing my game.
Once (or if) the iOS version of my game is available I'll do the same for iOS specific review sites (which there seems to be a lot more of) and hope for the best. Fish Feaster Free managed a few hundred downloads with minimal advertisement and press so there is no doubt that's it's possible to get into a lot of people's hands if you let the ones searching for games know about it.
This is the mystical step that is out of my hands. The Holy Grail of game development. Going viral. If the game is really good and something people are compelled to share, it will become popular. If you made a game the audience agrees with, things will sort themselves out and the game starts to sell itself. Climbing the top apps ladder is the game developers play with each other, and it's both incredibly ruthless and rewarding.
Once I get a few games under m belt and come out with a true gem the money should start coming in. By true gem I mean a game that is truly something people want to play and share. The kind of game you see over someone's shoulder and ask about.
I'm making games while still in school in order to have an established brand (Yotes Games) and library of games to sell when I eventually start an Indie Game Studio. My college degree is both a backup and an opportunity. If my indie plans don't work out, at least I'll have one incredible resume. If it does work out, I would have met countless people to work with and inspire me.
An IT college is a much better environment for meeting people and learning new things than coding at my parent's house for 4 years. The experiences I'm getting from being in college are already proving to make me a better developer. I've also met some people who could potentially be in my life for a very long time, career-wise and personally.
Also, if I never took calculus, I'd still want to become a Technical Director at Retro Studios or Obsidian. Taking a long look at myself and why I loved making games helped steer me toward a Creative Director career and eventually to the Indie that I am today.
In short:
I don't rush into 4 projects at once anymore. I carefully plan out games months, if not years, in advance and make them when I'm ready. My first priority is making a good design document in order to go step-by-step and finish the game in a decent amount of time. I announce the game once I have at least an alpha up and running and I make sure to take care of it once it's released.
It's a dramatic change over how I used to do things in 10th grade and I can't help but wonder if I'll improve my process even more in the coming years...
To see how my old methods from high school, read: A 10th Grader's Development Process
To see how my old methods from high school, read: A 10th Grader's Development Process
No comments:
Post a Comment