En español. (Spanish translation by Andrés de Pedro)

GameDevLessons.com has migrated to HobbyGameDev.com - please update links!

GameDevLessons.com Newsletter

Vol 1 - April 2, 2009


Welcome to the first GameDevLesson.com Monthly Newsletter.

I'm Chris DeLeon (about me), and this newsletter series is one of the ways that I aim to help new game developers get started, while helping current game developers take their work in new directions.

[Jan 2010 update: there are now more than 200 pages in 10 volumes including presentation slides, developer interviews, and a free e-book. More is added monthly!]

Since there are differences in level of reader experience, I've split this newsletter up into sections:

I.) Beginners

II.) Intermediate

III.) Advanced

IV.) Rant

V.) Questions

VI.) Schedule

This first mailing is long. I am attempting to lay foundations that can be built upon in the messages that follow. Additionally, bear in mind that this is multiple target audiences combined into one mailing - it's intended for skimming and skipping, although you're of course welcome to browse it end-to-end.

You can find the latest version of this message (typos fixed, minor additions/notes, Q&A) at the following URL:


Please share this link!

I.) Beginners

What Videogames Are Made Of

Videogames are composed of 2 general things: data (images, sounds, songs, levels) and code (computer instructions).

Images and sounds are made with image and audio editing programs. Levels are also usually made in something like an image editor - but instead of placing shapes, the software is used to place walls, items, and characters. When making videogames, creating the level editor is part of the process. Although many commercial videogames do not openly share their level creation software, a few do.

Code is like a film script. However, whereas a film script can be followed without interruption, interruption is precisely what a player does. Because of this, code is a situational script. Rather than:

Jenny walks in.

JOHN: How was your day?

...code would have the account for changes the player might have made, reading:

If the door isn't locked, Jenny walks in.
(Otherwise, she knocks.)

JOHN (if Jenny is in the room): How was your day?
JOHN (Otherwise): I think Jenny is locked out.

Programming skips a lot of the fluffy prose, though. You'll also notice that I'm struggling to use a consistent format for the options above, and it seems like there are a few ways to write it. Programming has special use of punctuation and keywords to fit patterns like this that come up frequently - this is called a Conditional If/Else Statement. Our example might look this way in code:

if( door.isLocked == false ) {

  Jenny.enter( theRoom );

} else {

  Jenny.knocks( theDoor );


if( theRoom.contains( Jenny ) ) {

  John.say( "How was your day?" );

} else {

  John.say( "I think Jenny is locked out." );


If you can connect the above to the film script text that precedes it, you're ready to dive into the basics of programming. A program called a compiler then translates that human-readable typed language into many obscure characters, which act as detailed instructions to the computer's processor. Every videogame and program you own, whether on a computer, home gaming system, or mobile phone, exists somewhere in a readable form somewhat like the program code above, but usually only the machine-readable output is distributed, to protect company secrets.

Programming is only a tiny bit of memorization, a little making things up and relating them to each other in a meaningful way, and mostly the proper use of a few basic patterns. It's impossible to write a German poem without knowing the language, it's difficult to compose music without knowing how to play an instrument; for videogames, programming is the language and the instrument. There are plenty of free online resources and affordable beginning books out there if you're looking to learn more. I would recommend starting with C, the programming language that is the foundation of C++ (the modern programming language used for most downloadable/installed programs), or ActionScript 3 (a language closely related to C++, designed for making web programs).

Getting Started

Start small. Very small. Smaller. I have seen many game developers give up on their dream after starting a project outside their scope, even starting on projects as modest as a Mario-style platformer, tiny RPG, or sparse FPS game. If your goal is to ever play your dream game, it's more likely to happen if you'll start with modifications to games and making classic arcade games. Your first attempt at novel writing wouldn't be War and Peace, right?

Modifying a commercial videogame is easier than it sounds.  Many modern games for home computers come with level editors, scenario editors, or plain text data formats where you can experiment with altering game content.  Working with professional tools and environments can help you soak up lessons from decades of industry development experience. This is a good way to get the attention of peers, since a new level in a popular FPS game or a new unit in a hit RTS title resonates better with a mainstream audience. This is good practice working on the scale and types of games that are put together by huge teams of professionals, learning about the challenges of workflow and specialization. It's also helpful that if you make a level for Unreal and it's bad, you can safely identify that the level needs work, and it's probably not the guns or player movement that need tweaking.

As fellow indie game developer John Nesky recently explained to a mutual friend, "It's easier to start with something that works, then change it into something else that works, than starting with something unfinished and figuring out what's broken." Find some sample source code for a retro game - Pong, Breakout, Asteroids, etc. - then try reshaping it piece by piece into a slightly different game. Unlike modding a huge modern game with editing tools, when you're working with full source code for a tiny project, you're free to modify every part of how the game works. Even better, you can make those big changes without throwing away thousands of hours of work done in level layouts, weapons code, or enemy behavior that counted on a particular way the player's character moved.

The path that I recommend? First, experiment with creating levels or in-game art to mod into an existing commercial game to learn about some of the data tools and design problems involved. Once you're comfortable there, transition into editing sample source code for small games. With comfort in how the individual images, audio, and levels fit in, you'll be free to focus your attention on how the programming works. Through experimentation you'll be able to gain a more organic understanding of how all the pieces come together.

I generally recommend against using special game building software like Game Maker or languages like DarkBasic if you have a long-term interest in game development. These approaches force severe limitations and scale poorly to the real methods that use traditional programming languages. In contrast, I stand behind PlayCrafter.com as a solid first-step videogame design learning environment, precisely because it focuses on level design and gameplay tuning, while making no attempts to shortcut, simulate, or simplify programming. It's a free, online way to practice videogame design for a physics-based game engine that supports multiple genres. (Open disclosure: I worked for a year with PlayCrafter.com and co-architected the game creation tool for the site. That's not why I think this way, though; that I think this way is why game making on the site works the way that it does.).

If you have already dabbled in making levels, or modding games, and would like some sample source code to tinker with, there a ton of example source files on net. I'm also giving away some of the example ActionScript 3 videogame source that I prepared for students recently:


The most important thing to do: get started! You can learn most of what you'll want to learn for free by experimentation, and from internet sources. The internet is crawling with open-source programmers. Learning jet engineering or structural engineering by experimentation is a recipe for disaster, but learning videogame programming by experimentation is perfectly safe.

Free Resources

For image creation and manipulation:

http://gimp.org GNU Image Manipulation Program

For sound effect creation and editing:

http://audacity.sourceforge.net Audacity

For 3D modelling:

http://www.blender.org/ Blender

Programming compiler for ActionScript3, used in programming web games:

http://opensource.adobe.com/wiki/display/flexsdk/ Includes mxmlc, an AS3 compiler

Programming compiler for C++, used in programming downloadable games:

http://www.bloodshed.net/devcpp.html Dev-C++ 5 (PC only; use XCode on Macs)

Creative Commons royalty-free music (credit Kevin MacLeod if you use his music!):


II.) Intermediate

Make Compromises to Finish

I know a lot of partial indie game developers. I say partial, because whether they're a student making a hobby project, a specialist professional at a corporate giant with their own game on the side, or an expert in another field exploring game making as a hobby, they haven't finished what they started. Unfortunately, the outside world is uninterested in driving a partly finished car, living in a partly finished house, or playing a partly finished videogame.

There are two main killers of indie projects: (1.) lack of excitement in finishing off the little stuff near the end, like menus (and 2.) hopelessness that creating the game the way "it's meant to be" will take too long.

To the first point, while making menus and tying up remaining loose ends isn't as much fun to do as building levels and programming enemies, nothing about game making is more exciting than watching people play it. It's a thrill knowing that strangers around the world are getting a blast (or getting pensive, or getting nightmares) from your work. The only way that happens is after the game is finished. So sprint that final stretch, and ignore temptations to add other cool features that will require additional unplanned work before it can be called done.

To the second point, games that turn out the way they were "meant to be" are often not good. What works on paper or sounds good in conversation is often not what works great in real-time gameplay, and vice versa. A game can be made better through needing to focus your efforts and ideas throughout the development process to fit within your talent, tools, and time. Check out this transcription of the original design doc for id Software's genre-defining hit Doom. Muse for a second on how much the game would have lost in terms of focus if it had 4 main characters, and some of the other junk proposed:


Even a modestly decent game, completed, is worth more to people than the greatest game ever started.

Imagine how much less exciting your thoughts might be today if Mario, Zelda, Final Fantasy, Sonic, Twisted Metal, Myst, MechWarrior, Doom, Chrono Trigger, Okami or another game you love would have stalled forever at 98% done because the options menu wasn't finished, or been cancelled because (note what an obvious trap this sounds like when pointed out!) the developers were able to talk about more ideas than they had time to program and create data for. It would have been like someone stealing from your childhood.

And in conclusion, don't steal from children.

Find Someone to Work With

First, a big word of WARNING: For people new to programming, having multiple programmers on a project can go considerably slower than having 1. A ton of time gets wasted trying to make sense out of someone else's hackish code, rewriting overlapping functionality, and solving bugs from misunderstandings about each other's implementations. 5 beginning programmers working together will not get done 5 times faster than 1, but together they are 5 times as likely to never finish.

When I say find someone to work with, I mean in the same way that friends are most successful at getting in shape when they have a friend to go to the gym with. Having trouble keeping game development a weekly priority, between school/work/social demands in your life? Get someone else having the same problem to help keep you on track, and return the favor. Having someone else interested in videogame development to share war stories with, complain to, ask for feedback, and otherwise share in the adventure is considerably more likely to succeed in a timely manner than trying to swim all alone in the ocean. But until at least one of you has a few games of completed experience, I would tend to advise against working on the same game together just yet.

Not sure where to find someone else interested in game development? The internet is full of them. Cast out a line or go looking for others that are already searching.

Or, if you're too impatient to use that method, or have tried it before and got unlucky with a rough pairing, consider getting a game development coach. Project coaching is a big part of what I do, and have done for years (starting with 2 years as the head of Game Creation Society at Carnegie Mellon, http://www.gamecreation.org), and if you're serious about doing this, whether you just need a one-time discussion to jumpstart direction, periodic help getting past some hurdles, or weekly progress guidance, get in touch with me via http://www.GameDevLessons.com letting me know your situation and we'll work something out.

Pick up a New Language/Tool

Feeling stuck, because you know a programming language already, but it's causing you trouble getting games done efficiently in it (Assembly, Basic, ML...) or getting it to users without them needing to download huge updates (.NET, Java...)? For goodness sakes, start learning a new programming language. If it has been awhile since you've learned a programming language, you'll be pleased at how easily skills in one transfer to skills in another. This isn't like learning Latin, Chinese, or Russian - a good 80% of it is learning what syntax that language uses for variable declaration, and for basic loops, conditionals, and functions. The other 20% is learning the bag of tricks of what structures or options enable you to do in that language what would be roundabout, disorganized, or prohibitively inconvenient in another language. If you've been putting off learning C++, it's as near to a universal language as we have today in programming; if you're fluent in C++ but you're behind the curve on web programming, you'll be alarmed at what you can do with ActionScript 3. If you know all of those, have you done much work yet in Objective-C? (And if you know all of these, what are you doing in the Intermediate section of this message?)

Additional Resources

At my hobby site, where I have my experimental game-a-day work posted, there's a resources section (http://interactionartist.com/index.php?page=resources) with presentations that I developed for college lectures and indie game projects, as well as a list of links to game industry career sites.

III.) Advanced

Trying to get into the wave of iPhone development? It's cheaper, easier, and faster than you may think.

Development hardware for consoles traditionally costs tens of thousands of dollars each. In the case of the cheapest development hardware, which costs only a couple grand per unit, the console manufacturer still demands that you have rented office space, a business plan, and a working proof of concept before they'll take you seriously enough to trust you with one of their babies.

When I was approached by publisher ngmoco, Inc. to make Topple for the iPhone, I had no prior Objective-C experience, I had never programmed on a Mac, and I didn't own an iPhone or even an iPod (Touch model or otherwise). I went out and picked up a $600 Mac Mini, $250 iPod touch, a cheap keyboard/mouse combo, and a $100 used PC monitor. I paid $100 for an Apple developer license, which was approved within a week or two of submitting my request. There for just over one grand, I had everything that I needed. No phone plan, no expensive high-end laptop with hardware accelerated graphics, and no permission needed from Apple besides the $100 developer license, which has been referred to in web forums as a "bozo filter" since that's about all that step is there to do.

Now this is genius. Apple, traditionally the minority of computer market share because developers were making PC applications - in a chicken/egg cycle since most consumers owned PC - has brilliantly figured out a way to get developers onto Apple hardware programming in Apple's Objective-C. With developers on the platform producing piles of new applications, that throws a huge wrench into the developer side of the developer/consumer PC flywheel. I'm typing this from my shiny second Mac.

Back to the point though, I won't say much here in detail about iPhone development since I'm in the sights of multiple NDAs on the subject, but since you're in the Advanced section of this newsletter I trust that you don't need much handholding. Apple has tons of excellent sample code available for the platform after you're a registered developer. Within weeks of investing ~$1k into your own development station (assuming you don't already own a Mac, monitor, keyboard/mouse, or iPhone/iTouch), you can have a working prototype running on device. Submitting to the App Store is an equally quick and surprisingly simple process.

If you're like a lot of game developers thinking about making the jump but rationalizing staying comfortable, I know what you're thinking - the App Store is soon to be saturated, and it's just a big gold rush sure to die out soon. (1.) Creative, clever, well-polished apps are still standing out from the crowd (2.) when someone owns a standard mobile phone, all you can guess is that they know other human beings; when someone owns an iPhone, you can reasonably guess that they're willing to spend a little extra on entertainment value and extras (3.) thanks to Adam Smith's invisible hand, plenty of other companies are rushing to market with competitive devices in an effort to catch the overflow of developers and consumers by emulating Apple's success, so the newly developed skills are likely to transfer.

I'm definitely not trying to give business advice (you probably shouldn't quit your day job or start pestering investors), and I'm definitely not suggesting that this should be counted on as a way to make money (entertainment markets are fickle and unpredictable to say the least). But I will say that I believe it's the easiest, cheapest, fastest way yet to get experience developing on a commercially active platform other than computer/web. This can be a fun hobby, a valuable learning experience, and if the planets and stars align just right, it may also make some money on the side.

IV.) Rant

"Imitating paper on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway."

-Ted Nelson

There's a pervading notion in videogame design courses, lectures, books, conference workshops, and online discussion forums that the best way to understand and plan videogame design is through a deep analysis of dice, spinners, playing cards, board games, and the like.

If our daytime work was with Milton Bradley or Parker Brothers, this would be a worthwhile use of time. For the more than 40,000 of us in the USA working on real-time electronic videogames, I think that most of the analysis in analog space is an inefficient way of highlighting some vague commonalities at best, and more often than not, a dangerously misleading waste of time.

The thinking is that videogames are games, those other things are games, so the study of them must be relevant. The problem is that videogames are not a subset of paper and board games, it's the other way around. With hundreds of millions of calculations happening per second, we can fully simulate paper and board games on a computer; with a hand-manageable amount of limited, visible states and a few state changes every few seconds, we absolutely, positively, cannot meaningfully simulate real-time videogames off a computer.

Nothing about the paper model side of the field relates to what worked about Pong, Warlords, Asteroids, Pac-Man, Tetris, Bubble Bobble, Donkey Kong, Castlevania, Blaster Master, Paperboy, Mega Man, Ninja Gaiden, F-Zero, Goldeneye 64, Quake, Resident Evil, Wipeout XL, Street Fighter 2, Snood, Soul Calibur, Smash Brothers, or Metal Gear Solid. For electronic dungeons and dragons games, or electronic versions of chess, or electronic versions of poker, obviously those paper models and topics apply, insofar as they are the directly emulated material.

That random numbers are involved does not mean dice and spinners are useful, unless your game runs at 1 frame per 30 seconds, because the hundreds of random numbers come out in the wash compared to factors that challenge cognitive perception and reaction, such as rapidly changing spatial relationships, event timing in relation to on-screen cues, learning patterns, and rapidly adapting heuristic judgment. And unless you're playing a turn-based multiplayer game where you're all in the same room, the dominant factor from Poker and many paper prototypes - reading tells - goes out the window.

We can learn things from other mediums, sure. We can compare some aspects of board game playing, or a game of basketball, to what goes on in a videogame. I can also make a comparison to washing dishes, cutting hair, rolling down a hill, running a company, picking a movie at the theater, or doing the Macarana. That does not mean that we should devote every page of every game design book, every hour of class lecture, or every workshop at every conference to these things which have a few relevant parallels to videogame design and playing.

Don't get me wrong - paper is useful. So are whiteboards. Sketching is useful. A programmer is wise to figure out certain things on paper before writing code, and a designer is likewise wise to do some sketching before fiddling around with the level editor. There is a world of difference though between using paper to sketch spaces while considering line-of-sight and navigability vs. using paper to play out elaborately structured rule sets in search of understanding a videogame's "core compulsions."

How it behaves on-device, how everything fits together, is the relevant space. And just as porting a videogame designed for a TV console videogame system to a handheld device or vice-versa may require a total redesign to match the input and hardware constraints to meet platform expectations, you can bet there's a tremendous amount of redesign work to port to/from "hardware" with no processor clock, unlimited display space, fully articulated speed/bodily input, and "RAM" that's limited to a spinner's current position, a boardgame's piece layout, and a few piles of cards. You wind up porting a gameplay scenario that was designed to work for a narrowly constrained 500-year-old game system.

I've heard arguments from academics that this is what they resort to for game design classes because the designers can't program. First, as much as art majors often enjoy dodging calculus, it will help electronic media designers tremendously if they can pick up some simple programming, even if they're writing unshippably hacky code, just to gain a conceptual understanding of how to work with-the-grain of a logic-driven machine to communicate in interactive concepts. Secondly, if they absolutely, positively must have a programming-free videogame design assignment, get them to:

  1. Make playable content with a level editor for an existing engine, justifying their layout decisions to the group or instructor in a formal crit

  2. Tune unit stats in an RTS game to balance teams where different armies have different unit types available, explaining their considerations, methods, and guiding principles used to arrive at a solution

  3. Give them a non-layout mission/level to design, such as planning the order and pattern of incoming ships in a side-view shooter, or setting shape probability and fall speed for multiple levels in an action puzzle game

  4. Give them a multiplayer mod for a deathmatch game that has the weapons deliberately unbalanced; challenge them to adjust the variables related to weapons and projectiles until none of the weapons go neglected

  5. Prepare a study of trends in videogame characters, settings, and other reoccuring themes in videogame history (ex. #101 - Zombies and Robots are indifferent to death, unaffected by minor injury, tireless, expected to make stupid decisions, and morally unobjectionable to slaughter)

  6. Analyze the subtle differences in timing, affordance, interface, interactions, and presentation between successful and unsuccessful games in the same genre; have them summarize this analysis into a list of concrete, actionable suggestions on how the less successful games in the genre could "feel" better to play with just a little attention to the right areas

Exercises like this will do a poor job of preparing them to design new board games, but is there even still much of an industry of people trying to dethrone Chess, Go, or Monopoly? Very few people have those sort of projects in mind when they speak of becoming a game designer.

I’ve seen massive commercial projects and student indie projects alike wallow uselessly in paper prototyping for months, nearly a year in at least one case, designing board and card games to “discover the mechanics”, only to start from scratch the second they switched to digital, because none of that learning was relevant. Companies lose money over this. People lose jobs over this. Students lose hope in their dreams over this. If this was just people arguing about outdated philosophies it’d be one thing, but it’s potentially ruining tomorrow’s games, hurting today’s companies, and derailing yesterday’s careers.

I am not saying that real-time videogames cannot be designed by starting with paper prototypes and principles derived from analyzing board/paper/card games. I am saying that doing so is like trying to design a military jet fighter based on the how a paper airplane works. I am saying that videogames resulting from that process will, generally speaking, not come out as well, except to whatever degree they get a complete overhaul after being adapted to a playable electronic platform.

V.) Questions

Have a question about something in this newsletter? Or just something that you would like to bounce my way? E-mail me at chris@gamedevlessons.com, and I'll get back to you as soon as possible. Answers to common questions will go here:

(no questions are posted yet)

VI.) Schedule

My schedule all this month of April is packed, and June/July I'll be serving as a lead game design instructor at Camp Galileo in Palo Alto. May will be a good month to get my attention if there's something that you'd like a boost with, after that my time will be most flexible again starting in August.

In the future I plan to make these more accessible by providing links to special game development podcasts, more sample game source code, and links to other helpful resources on the net.

Thanks for reading,

Chris DeLeon


PS I am writing this newsletter series to help people, and I want the contents to reach as many people as possible. Please pass along this link if you know someone that might find this useful: http://gamedevlessons.com/lessons/letter1.html Sending the link works better than copy/paste, since that way they'll see the latest updated version with Q&A or corrections. If you'd like to be kept up to date with these monthly mailings, simply subscribe to the GameDevLesson.com Monthly Newsletter.