Most of the skills that you'll need to make videogames, you can teach yourself.

...says the guy that devotes much of his free time to teaching videogame making.

What I most like to do is help people that already know how to make videogames learn how to do it better. The sort of project-specific and game design expertise that I have to offer isn't of much use unless you can already make videogames, and a big part of that is knowing how to program. In sharing free materials and information to help you teach yourself, I'm growing the number of potential developers that I can work with on the challenges that I find most engaging.

Websites are terrific resources for providing answers to specific questions, and finding links to other useful resources like sample code. As explained above, I believe that they're inferior for conveying fundamentals (see: the notes immediately above in the Books section).

Just like in school, if you have a question, there's a pretty good chance that other people trying to learn the subject have this question, too.

Unlike in school, your class size ranks in the hundreds of thousands, and there's a detailed record of virtually every question asked in the past decade or longer.

If you're finding yourself stuck on something - and I know this seems obvious but I'd be remiss to not reiterate it - do an internet search or crawl relevant web forums for an answer. If you can't find one, then - keeping to the school analogy - do a favor to hundreds of thousands of people over the next decade by speaking up on forums with your question someplace that others with your same question will find the answer.

In programming, a library is just a packaged chunk of code someone else wrote to handle specific functionality. This might include network operations, text display, sound playing, image manipulation/loading/displaying, physics simulation, etc.

A good programming library can address a problem that you had no clue how to solve, in a way that's (a.) fast (b.) easy (c.) leaves you clueless how to solve it without using the library. If your goal is learning about something in particular, like graphics programming or network code, point (c) may be a problem. In many cases, a library is used to do something that very smart people have spent decades researching and perfecting. In that case, that library can save you literally years of frustration, and let you focus instead on what you're doing with the graphics, network, and physics code to make your game stand out.

Jackpot!

Finding good sample code can be the difference between taking hopeless shots in the dark about how things tie together, and working with confidence that what you're starting with should work. This is also invaluable early on because by starting with code that you know should work, it can help you determine whether your programming environment is installed and configured properly - if it fails with sample code that came from a dependable source, you know that your project, environment, or compiler isn't set up correctly. That's way better than tearing your hair out hopelessly changing things in your code wondering why it's not working.

Find sample code. Read sample code. Compile sample code. Retype sample code. Modify sample code. Try commenting out various lines of sample code to see how it affects what happens. Add comments to sample code.

Search for sample code appropriate for your level of comprehension. If it's not too long, and it doesn't make perfect sense to you just yet, verify that it compiles in your environment, then print a copy to keep folded in one of your books for occasional review.

Good programmers are dramatically faster and more efficient than less good programmers.

"Good" here isn't in reference to total years of experience, how many different programming languages someone knows, or what projects someone has been a part of building. "Good" is referring to how quickly someone can synthesize the code needed to solve a problem, how well that someone can generate code which is structured with future needs/readability/adaptation in mind, and how easily the person can digest and interpret code put in front of them.

Some people are as fluent and comfortable with programming as they are with their primary speaking language. Others fumble through it like it's a secondary language they remember traces of from when they took a few semesters of it many years ago in school.

I chalk up that difference to the comfort that comes from countless hours of practice. The kind of usage that goes beyond fulfilling a specification someone else handed over. The kind of experience that comes from stretching and applying knowledge to solve problem or create a project that the programmer was personally invested in.

On one end of the spectrum, there's the way that someone with zero background in programming, but access to the internet, could cobble together code they don't fully understand to make something happen. On the other end of the spectrum, there's someone that can just breeze through whatever problem you put in front of them, perhaps occasionally taking a moment to reference documentation or copy something out of their vast library of past project files.

I'm reiterating this distinction for an important reason:

1.) You absolutely, positive, unmistakably, want to be in that latter group. You want to be the person that is really on top of their stuff.

2.) There is no doubt, none whatsoever, about why you will or won't wind up in that latter group, instead of that former group: practice.

Your past project files are much like sample code. The main differences are that you understand everything in it. Because you were responsible for the whys and the hows, you know exactly where to find what.

Time and time again, my mountain of past project code has been the source of my confidence in taking on a new project. Provided that I've done something in a past project, or done something like it, there's no doubt in my mind that I know how to do it, and can probably make it work again without much fumbling around. Instead of spending my implementation time thinking about how to do something, I could start from my past solution, and spend that time finding a way to do that something better.

The only way to get that mountain of past project code is to (here it is again!) practice. On your own time.

If it's done to satisfy classwork requirements, it won't be any different than what every other programmer has been exposed to.

If it's done to satisfy business goals, it's likely company property that you're not free to reuse.

Practice.

On your own time.

At big companies, where specialization deeply takes root, there's a question echoing through the halls asked by artists, programmers, business people, and audio experts alike: "What do game designers actually do?"

The implied answer is often "nothing". They aren't drawing the images, coding game functionality, negotiating funding, or making sound effects.

The lack of clarity about what videogame design involves can pose an even bigger problem to someone making a project alone - it's entirely possible to get so involved in creating images, code, and sounds to overlook design considerations.

To people outside of our industry and interests, they may hear "designer" and think "graphic designer", as in, the sort of person knowledgeable about expensive typefaces and making brochures. Videogame designers aren't necessarily into that sort of design.

Whether experienced in videogame design or not, whether you're familiar with the role's meaning or not, I encourage you to read along all the same. The way that I think of the role might complement what you already know, or perhaps prove helpful in explaining it to others.

The game design for Solar SFUN, Topple, iZombie Death March, the dozens of indie freeware games that I did before, and for my contributions to EA's Medal of Honor Airborne and Boom Blox, all consisted of entirely different types of thinking, work, and deliverables. If we focused strictly on puzzle games, sports games, or first person shooters, we could present a more exact list of what videogame design means for those genres - but how does completely different work between different kinds of games wind up under the same umbrella of "videogame design"?

It's not a coincidence that many versatile videogame designers (not to be confused with people identifying specially as "level designers" or with skills limited to an established genre) express an interest in philosophy. This is not necessarily philosophy in the sense of what German Idealists said about old Greeks, but philosophy in the sense of metacognition - thinking critically about critical thinking, and planning about planning.

Videogame designers enjoy sifting through countless possibilities in search of meaningful patterns, to create terms and label and categorize. Inasmuch as philosophical banter evolved into the fields of biology, physics, chemistry, computer science, law, medicine, and mathematics, a major part of videogame design is inventing a discipline around making content for the current game project. They're often quick study types, eager to dive deep into new information, apply it, then forget it just as quickly to stuff their heads with new systems. (Contrast this to the cumulative learning of specialists in more consistent disciplines like programming, business, or applied digital art.)

What are the relevant terms and concepts needed to discuss and shape the game's detailed direction? What decisions will affect the options of future decisions, and what order can the decisions be made in to minimize thrashing of interdependent considerations?

In the same way that considerations can be identified to rule out valid content from invalid content, fair from unfair challenges, the items and levels for real-time games can be created by a set of principles. How long into a level should the first action should happen? How many enemies at once should be in a room of a given size, with what frequency should new items should be introduced, at what pacing is it fair to raise the difficulty, and how much can the game reuse the same settings for consistency and cost-saving without seeming cheap and repetitive?

In an established genre, such as a space marine first person shooter, a third person survival horror game, or a falling block game, a videogame designer's first objective may be to research what else has been done by competitors in that space to learn from their experiences and improve upon their mistakes. It's a very different design challenge creating the 25th football game in a series, aiming to innovate enough to satisfy critics and excite returners without alienating the fan base.

To be sure, videogame design for a sequel still comes down to simplifying a complex space of possibilities into a manageable system of terms and concepts to be used as the foundation of furthered design and content development.

By the time a developer is nearly done with their game, they have played it thousands, perhaps tends of thousands, of times, and have practiced its controls and puzzles since they first took shape. What's an appropriate level of challenge to a new player may be boring to the game's designer, and what entertains the designer is going to be ridiculously hard to a newcomer. In making the game the appropriate difficulty, though, it is important to ensure that attention isn't just given to it's degree of difficulty, but that the right types of difficulty are adjusted.

If the source of newcomer difficulty isn't properly identified before being addressed, no amount of variable tuning will compensate for it, but attempting to address it the wrong way will introduce other problems to the game's entertainment value.

Although this section of the Free Lessons is focused on the ways that a game can accidentally be the wrong type of difficult, it's helpful to distinguish between a few intended types of difficulty to free up thinking about sources of challenge-

Myst is a hard game.

Street Fighter II is a hard game.

Final Fantasy is a hard game.

Anyone familiar with those franchises recognizes that those are three very different statements. Roughly:

In most cases, Myst makes it easy to do what you're trying to do, but hard to figure out what to do.

Street Fighter II makes it easy to figure out what you're trying to do, but hard to do it.

Final Fantasy is time consuming, and how easy it is to do what you're trying to do is a function of how much time you're willing to spend leveling up.

And now, we'll look at some of the various ways that a game can be hard that aren't particularly fair. Most of these sources of difficulty cannot be addressed by adjusting hit points, power, or speed. A fix likely requires rethinking and redesign. The extremes of the sources of difficulty identified above - too unclear what to do, too difficult to perform important moves, or too much time repetitive required to make the game winnable - will be skipped in the list that follows, for having already been mentioned.

Testing without Teaching Schools don't test material before teaching it first. Doing this frustrates and infuriates people. And unlike school material, there's no chance that someone knows the nuances of how your videogame works until you've communicated it to them. Ideally it's helpful to think about game mechanics being introduced in the order of Introduction, Study Opportunity, then Test/Challenge. But at the very least, that introductory teaching is essential before expecting someone to excel at it.

Expecting Mind-Reading If something looks like it should have multiple solutions, but the puzzle or battle is contrived such that it can only be completed as the designer intended, the game is setting up the player for getting mad and saying "that should have worked." The appearance of multiple solutions should translate to multiple solutions, or affordances should be carefully rethought to steer the user toward the intended solution.

Victory Relies on Unexplained Emergent Behavior Most games with even moderately complex input offer some unintended combinations to jump a bit higher, run a bit faster, move puzzle pieces while others are falling into place, etc. In Doom and Goldeneye 007, it's possible to run ~40% faster by strafing while running forward - the velocity vectors get added together. These and other subtle time/health saving tricks will seem just as natural to the designers as the core interactions after so many hours of practice, but need to be introduced explicitly to the player if they're required for success.

Snags in Unexpectedly Steep Difficulty Ramps Assuming your game isn't the first time a person has played a videogame, they will likely be cruising along undefeated for awhile before their first setback. If it takes too many replays to cross that first hurdle, your game is going back on the shelf, probably forever. A player in this situation, going from no replays to replaying the same section many times without progress, is more likely to blame the game's makers for unreasonable tuning or inadequate instruction rather than think it's from an issue with their own ability.

Poor Affordance Affordance is a design word referring to how something's shape, structure, or style suggests its proper usage to a user. A handle affords pulling, a dial affords turning, a button affords pushing, and a spiky floor affords not-touching-or-you'll-die. The classic example of proper affordance in videogames are the weakpoints on bosses - glowing red areas or otherwise particularly vulnerable areas (brains, eyeballs) that were where the boss needed to be attacked.

Poorly designed affordance becomes an issue in videogames when the character in the crowd that the player can speak to doesn't "pop" visually in the scene (may be a matter of layout), if it's difficult to tell a door you can open from a door that you can't until you try (leaving handles off doors that can't be opened), or the player can't able to identify where a wall is fragile enough to be destroyed (hinted by cracks, rubble, significant discoloration).

Insight Puzzles An insight puzzle is a challenge that doesn't provide feedback for near success, such that getting it right involves a non-trivial shift in thinking, a leap between the data provided and the solution. In everyday life these come up in riddles, in school they come up in advanced proofs. In a videogame they take the form of needing to realize that the mirror isn't really a mirror but a window, that badguys can be thrown onto spikes and used safely as a bridge, or that arrows will become fire arrows when shot through a torch.

Where possible, proper affordance (see previous item) like a giant ice target being near the torch, or a subtle hint, like letting the player witness a badguy walking harmlessly across spikes, can make the difference between the player feeling clever by getting it right and thinking it's their idea, or the player getting stuck.

At the end of the day, the videogame is being made for game players, and it will be played without explanation or demonstration.

Consequently, the best way to check for fairness is to sit down a few testers, separately, that haven't worked on the game, and haven't seen it played by anyone. If they can beat the part in question with a little practice and no outside explanation or hints, it's probably fair.

If they can't, then investigate whether it might be one of the above sources of difficulty; if it's definitely not related to those, consider retuning some of the variables involved. Then find a fresh batch of testers - like bulls with bullfighting experience, they're dangerous if reused.

There's a famous rule from the old days of Atari that it's impossible to make your first level too easy or too short. By sheer virtue of the player's mind catching up to the new setting, new controls, new characters, new dynamics, and new audio, the newcomer's brain is overloaded and challenged even without difficulty added into the gameplay. They temporarily overlook the overload, searching for an answer to whether this investment of their time will pay off. Meanwhile, getting them out of that short, easy, dumbed down setting into real gameplay fast is critical to not losing the player's attention by creating the impression that the game's activity is too shallow.

It's easy to lose the player by overwhelming them with a performance test given too soon. This can scare first timers into believing they can't handle the game's difficulty.

It's easy to lose the player by boring them by ignoring the core gameplay for too long. This can lose first timers from a sense that the game isn't very compelling.

Meanwhile, the immediate reward of progress serves as an appetizer into the game's main course.

It's impossible to make your first level too easy or too short.

"If you aren't sure which way to do something, do it both ways and see which works better."

-John Carmack

Lots more people have the skills related to game making - programming, digital artwork, storytelling - than are involved in making games. The problem in many cases isn't that they lack ideas for videogames, it's that they have too many ideas for videogames, and aren't sure how to prune bad ideas from good ones.

Without being able to tell bad ones from good ones, how can someone know which concepts they should start on? Which will be the most effective use of their time?

Like trying to cram too much through a funnel, the path from brain to hands jams up from uncertainty about how to narrow down the possibilities.

I can give you my answer to this question, but doing so wouldn't be very helpful.

What's a good idea for me to make is based on what videogames I know best, what ideas I'm passionate about, what types of work my own personal experiences have led me to see the most clearly.

What we want to know is what's a good idea for you, and there's only one way to get to that...

These Free Lessons are developed as a gift to the community, and I would like to continue developing them, but they are very time consuming. If you find these lessons valuable, and can afford to make a small donation of $10 (cost of a small book), $30 (a brisk group training session), or even just a few dollars (to show your support, and encourage me), it would be greatly appreciated and help me continue setting aside the time needed to keep quality a priority in my free lessons. PayPal makes the transaction safe and simple - you don't even need to have a PayPal account if you have access to a credit card:

I recently had the opportunity to interview videogame legend Warren Robinett (developer of Adventure for Atari, and cofounder of The Learning Company). I had hoped to include highlights of that interview in this newsletter, but transcribing and editing the informal discussion has proven more time consuming than I had first hoped. It'll be ready in time for next month's newsletter though - bear with me!

Chris DeLeon