Today, then, I thought I might take a bit of time to walk newcomers through the field. There's a ton of info out there. And sometimes, that can be just as bad as there being no info out there. How does one know they're following advice or tutorials that will lead anywhere? What if one follows a tutorial, only to find that it dead-ends somewhere down the line?
As it turns out, there's both good and bad news here. The bad news is that false-starts are common. Even experienced devs are lured into dead-ends. Technology is an ever-shifting field, and games even more so. It's easy to commit time and resources to something that won't pan out, and that's par for the course.
The good news is that there's usually something to be gained from such failures. This is particularly the case for beginners, where every step is contributing to new skills and perspectives, if not the end product. When one is a complete beginner, there's nowhere to go but up.
Where to Go for Info
As already mentioned, there are billions of places to get info on developing games. Google searching can be a bit daunting:
|Better make some coffee...|
I considered compiling a list of indie development resources, but then I remembered that someone has already gone through the trouble. In fact, many people have:
- Pixel Prospector maintains a gigantic list of indie resources. It's probably one of the most comprehensive lists on indie game development tools, techniques, and wisdom, collected from around the web. http://www.pixelprospector.com/indie-resources/
- TIGForums is one of the more active independent developer forums. Subforums abound, covering every aspect of development, including creative, technical, business, and tutorials. http://forums.tigsource.com/
- Gamasutra is a major source of all things gaming, with a focus more on the developers than consumers. There is a vast catalog of knowledge here, including news, tutorials, GDC videos, jobs, and op-ed. http://www.gamasutra.com/
- StackExchange is probably one of the most valuable places to know about when trying to find the answer to a technical question. The questions and answers are usually of high quality and value, owed in part to their curation and voting mechanisms. Many of my epic quests for esoteric programming or technical knowledge end here. http://stackexchange.com/
- Daniel Cook's blog posts are also a good place to read about game design, business, and the craft in general. Aspiring indies who struggle with art may be particularly interested in his article about sourcing game graphics. http://www.lostgarden.com/2008/07/directory-of-posts.html
Some folks like sharing what they've learned, which might make this a good time to mention an important lesson I've learned: see if someone's already done the work for you. The internet is a pretty amazing thing, giving us near-instant access to a growing proportion of all human knowledge. When it comes to game development, a lot of the problems (most, in fact) are ones that have been tackled before. It's worth doing a quick search first, just in case someone's already saved you the trouble.
Which Tools to Use
Choosing a platform, engine, tools, or project management method is like choosing a religion: fanatics are everywhere, and will try to sell you on their favorite. But in the end, just about any of them will teach you something, even if it's that religion isn't for you.
Again, I'm going to harp on Pixel Prospector. One of the first links they list covers a vast list of tools and engines. Read what people say about them. And more importantly, look up what people are building with them. There's no greater proof of a tool's validity than the thing it was used to create.
What did I learn on? Well, this:
|Computers can do ANYTHING|
The point of my telling you this isn't to say that I've had a lot of training. Most of the above was better described as "flailing," or maybe just "failing." And even the things that did succeed became obsolete with time. Technology comes and goes fast, as do platforms.
The point is to learn something in the process. All of the above taught me bits about how computer programs work, how information is organized, how logic controls data in an application, and how bitmaps work. Sometimes those lessons were learned while modding Dark Reign. Other times, I wrote code that put pixels on the screen in a starfield, and I moved them about in sloppy for-loops.
What's my tool of choice? I'm a fan of Flash's Actionscript, and flixel. Actionscript is a c-style, object-oriented (OO) language, which is a good type of language to learn. Many game-related technologies are c-style, OO languages:
- Objective C
- Haxe/OpenFL (a.k.a. NME)
Learning one is usually a good head-start in any of the others.
Flixel is a game engine built on Flash actionscript, and is a good balance of existing systems and free-reign to do what I want.
Would I build my next game in Flash/Flixel? Probably not. Flash is starting to limit me in some ways, and I'm looking towards Haxe and HaxeFlixel as a next step. It takes a lot of what I like about Flash and Flixel, adds some powerful abilities to it, and frees it from the clutches of Adobe (and the Apple-Adobe-Android wars).
That said, building something in Flash/Flixel now should put one in a good position to transition to HaxeFlixel later. They're similar enough that learning one teaches most of the other.
And once you've chosen your tools of choice, what then? Should you write an epic design doc, plan out all the facets of your game, and start building?
I'd focus on "Hello, World." If you can get code to compile and display that phrase on the screen, there's nothing stopping you from writing "Health = 100," or "You are standing in an open field west of a white house, with a boarded front door."
Or simply print some ascii art, and let the arrow keys move it around the page. Or maybe write some text about how much candy you have. Or how your dwarves feel.
The point here is that once you've got something displaying on the screen, the rest is just tweaking and watching the results. NEO Scavenger was originally a sprite of a man, and clicking a button moved that man closer to a dot. Each time he moved, his sleepiness went up. If you clicked another button, he slept, and his sleepiness went down. I kid you not.
So choose a tool, any tool. Search Google for:
tutorial "hello world" <tool name>and don't give up!