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




This free information is made possible by my iPhone/iTouch Apps.
If you like these text lessons, or if you just like neat free/cheap stuff, please check them out.




Chris DeLeon's GameDevLessons.com Text Lessons

Vol 11 - February 26, 2010


Hello!


I'm Chris DeLeon (about me), and thank you for joining me for my monthly videogame development Text Lessons, Vol. 11. This 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.



I.) Past Editions, Subscribe

II.) Mailbag Edition - E-mail Q&A

Math and videogame making - do I need calculus?

Steps in building a basic RTS

Programmer transitioning into game development

Modding to gain design experience

Game student seeking job

Free E-Book on game development using Python

The sky isn't falling: common industry concerns

Sequels

Stuck Developers

On Nintendo

On Valve

Quality of Life

More on Crunch

Changing Release Dates

Predictable Release Dates

Used Games

Engine Development

High Price

Huge Games

I have a question!


III.) Special: A Reddit Conversation - Rapid Q&A


IV.) Donations



I.) Past Editions, Subscribe


To read previous editions, or subscribe: http://gamedevlessons.com/?page=free


If you would like to be notified when the next edition is available, you can join the mailing list. It only takes a minute, I will never send out more than one e-mail each month (only to announce these text lessons), and it's easy to unsubscribe at any time.

New! You can also follow @GameDevLessons on Twitter for updates.


Although these lessons are not intended to be cumulative, how recently a given part was written probably does not correlate to how relevant the material is to your current project phase. If you're new to these lessons, I recommend Newsletter Vol. 1 for its non-technical conceptual introduction to programming, and the links it contains to free programs for image editing, audio work, 3D modeling, and other asset creation.



II.) Mailbag Edition - E-mail Q&A


I enjoy answering questions. Doing so increases the odds that my time typing is actually addressing someone's real and current problem, and in turn provides me with better targeted material for future editions at GameDevLessons.

This month, just to try something different, I'll preserve the original Q&A format rather than adapting the replies into articles.

Here are a few responses to messages from this past month's mailbag, paraphrased to better fit the general case:

Math and videogame making - do I need calculus?


Q: How important do you think it is to learn calculus for game programming? Which math fields are most useful in hobby game development?



A: I needed calculus for classwork, however I have virtually never used it for any of my dozens of freeware and small commercial projects.

That said, I'm not very involved in writing physics or 3D graphics libraries - when I need those features, I reference libraries written by other people who are more knowledgable in those areas. Someone working on rendering features or optimizations for 3D engines might well have more use for calculus than I do.

For most gameplay-related math - jumping, bumping into things, the speed of a shield recharge - simplified approximation suffices. In many cases the sloppier estimation approach is even better than trying to work out proper precision. As one example, the tried-and-true platform game mechanic of "how long the jump button is held after leaving the ground determines jump height" clearly does not in any way reflect the real physics of jumping. It's more important for a videogame to behave as the player wants (or expects) than it is for a videogame to behave realistically.

Of course, if we were trying to design an authentic flight simulator for military training, or model a car accident for the purposes of studying safety and real-world engineering, this would be a very different story. But for games we can usually just twiddle with numbers until things look and feel right. Videogame spaceships and helicopters move because we add a velocity value to their coordinates every frame - not because of rocket propulsion or Bernoulli's principle. For 2D game programming, spacecrafts and helicopters only need 1st grade arithmetic.

But beyond basic gameplay interactions, here are the fields of math that I run into most frequently for game programming, along with notes on what I find each most useful for:

  • Basic Geometry. 2D graphics programming is a matter of nudging object coordinates around on a plane, then drawing images every frame based on those coordinates. Bounding boxes (comparing coordinate differences) and the distance formula (Pythagorean Theorem) are commonly used to test whether two objects have collided with one another.

  • Trigonometry. Sine and cosine are helpful for angle-to-component translation, for example when determining what percentage of a bullet's total velocity the x-speed and y-speed are given the angle of a firing cannon (see illustration below) - this also applies to an overhead race car. Atan2 is handy for getting an angle between two things, given their relative offset in grid locations - good for getting an enemy to face the player, pointing a simple homing missile, and so on.

  • Vector Geometry. The dot product is an incredibly versatile math operation to gain mastery of, even in the simplest 2 vector 2D case. Learn how to use it, and you'll greatly increase the number of nifty things that you can pull off in game programming. This is useful for reflection off angled surfaces, checking line-of-sight, determining which direction something is facing, and many other common spatial/angle relationships.

    Addition (courtesy of fellow indie Tyler Glaiel): Normalizing vectors is another basic and useful aspect of vector geometry. Properly applied, these offer a more efficient way to accomplish some of the same things that trigonometry is commonly used for, including aggressive homing missile logic.

  • Boolean Logic. It's common in game code to want something to only happen either when multiple things are true (if player is on ground AND pressing jump button, then jump) or when at least one of several things is true (if [W Key] OR [Up Arrow] is pressed, then try to jump). At first glance this doesn't look like math, but when these statements begin to compound there's are math-like rules that can be used to untangle and simplify boolean logic.

  • Simple Algebra. Old-fashioned line-intersection check calculations are great, and trivial to write as a function. This comes up for things like pong AI, which needs to anticipate where an elastically bouncing ball will intersect a screen edge, or finding if and where a laser or bullet shot hits a wall.

  • Modular Arithmetic. The modulus (signified by the % sign in many programming languages) returns the remainder after dividing one number by another. This can be used to bound a number within a given range, such as ensuring that a potentially huge positive number points to a valid array entry, or limiting a random number to being less than the divisor given. Example: rand()%35 is a common way to get a random integer from 0-34, inclusive.

  • Matrix Algebra. In 3D, matrix math is used to perform faster coordinate translations and rotations to render models at various locations and angles. In 2D, rotating a Tetris block 90 degrees involves a little matrix math.

  • Tile Arithmetic. Admittedly, that isn't really a math field. But it is very important for game programmers. I'm referring to the use of multiplication to translate grid coordinates from a 2D array to world pixel/character coordinates, and division to match pixel/character coordinates to corresponding indexes in a 2D array. Turning a pixel coordinate (208 pixels from the left edge of the world) into a tile index (assuming 16 pixel tiles, 208/16 = 13, so the 13th tile) gives a fast way to check what type of tile fills that location in a 2D array. If the player is found to be standing on a wall tile, the player can be bumped backward; if a brick breaker ball hits a brick tile, it can change the value at that tile's array index to clear it, and reflect the ball's movement.


(For simple brick game examples using Tile Arithmetic to track brick states via 2D array: check out my C++/Allegro Breakout Source from Vol. 5 or the ActionScript 3 Breakout Source from Vol. 1.)

Another important thing to keep in mind, particularly pertinent to any sort of math used for videogame development, is that in good programming, every problem is only solved once. That solution is then abstracted (hidden! buried! never to see the light of day) inside a function.

This means that frequently, the math needed for game programming can be looked up on an as-needed basis on Wikipedia (basics) or Wolfram MathWorld (fancier), wrapped up in a new function, followed by almost immediately forgetting how that function works, freeing you to think instead in terms of what it does for your game.


M.C. Escher, known for carving crazy wood prints in the 1930's that we'd have trouble tricking a modern computer into rendering, was not a mathematical generalist. He didn't learn everything that he could find to learn about math, only to use whatever tiny fraction of it applied to his work. Quite the opposite - he dabbled in just as much math as he needed to create what interested him.



Steps in building a basic RTS


Q: I've been wanting to do a military strategy game. I learned C++ in high school. I made a few text-based games, but nothing major. Any starter tips?



A: If we were to make a demo or proof-of-concept version of the military strategy game that you have in mind - i.e. pretty much the bare minimum of functionality and assets to demonstrate what it does and how it goes it - what would be involved? For starters, that should be the target, rather than a full game. If the core functionality of a "demo" works (1 level, a couple of enemy types, basic winning and losing), then you can use that as a foundation to build the rest of the game; if that proves out of reach, then you'll figure that out far sooner, and be able to adjust plans or switch projects before getting in too deep.

Speaking of getting in too deep, if parts of this text refer to programming elements by a name you're unfamiliar with, or you could use a quick refresher on how various code aspects could make sense in videogame making, there's a section to address that in
Text Lessons Vol. 5. If you're needing some help getting a C++ project started with Allegro in order to track the mouse cursor and draw rectangles/images, you might want to start from the Asteroids Starter Code from Vol. 9.

As one possible starting outline, in whichever language/API/environment you choose to do it in (C++ with Allegro for downloadable, AS3 for web, etc.)...

  1. Get the mouse showing up, either as a default cursor or by drawing a small circle where the mouse coordinates are. Create two numbers, x and y, to store a soldier's position, and draw a colored rectangle on screen at that coordinate representing the soldier. Before moving on, set it up so that clicking close enough to the soldier kills him - this can be as simple as a distance check between mouse cursor and the army man each time the mouse clicks, setting a "dead" boolean flag to true which draws him a different color. The distance check to the solider should be written as a separate function that uses pythagorean theorem to return a distance for numbers/coordinates given as parameters.

  2. Create a game loop so that action can happen 20-60 times per second, rather than only when the mouse clicks. Do this by making a bool "gameRunning" set to true, and wrapping the core of the game (drawing, input handling) in a while(gameRunning) loop. If the user either presses a key (Escape perhaps) or clicks in the top-right corner of the screen (coordinate comparisons), set gameRunning=false to quit the program.

  3. Have the soldier keep track of a target destination by creating two new numbers, tx and ty (standing for target x and target y). Update the target destination to where the mouse last clicked. Each frame in the game's logic, if the soldier's target destination is more than some distance from his current location, have him move closer to his destination. To fudge this, just do a straightforward:

    if(x < tx) { x++; } // are we left of it? move right.
    if(x > tx) { x--; } // are we right of it? move left.
    if(y < ty) { y++; } // are we above it? move down.
    if(y > ty) { y--; } // are we below it? move up.
    // Remember: an increase in y is down, by default, for most game programming

    If you want to be fancy, use atan2 to find the angle from (x,y) to (tx,ty), then use sin and cos of that angle times a move speed (see previous Q&A for hints) to move the soldier nice and evenly toward the destination. If this seems correctly coded but is acting strange, verify that you're using float precision numbers for coordinates, rather than the whole number int.

  4. We've previously been keeping track of the soldier's position and destination with variables of ambiguous scope or organization, presumably global. Wrap up the soldier's x, y, tx, and ty in a new struct or class, and update the code to use the object's values (they can be left public for now).

  5. Refactor that code so that instead of having 1 soldier instance, you have an array/list of soldiers in the world starting in various areas. Keeping track of a current and target position for each should be automatic given an array of the struct or class defined in the previous step. Also add a new number: an index indicating which soldier in the array is "selected" (set to -1 by default, to indicate that no soldier is selected). Adjust the previous "click on to kill" code so that it sets the selected value to that soldier's index - a brute force iteration through the entire array comparing each soldier's distance to the mouse is fine at this scale. If no soldier is found close enough to the mouse to change the selection index, set the currently selected soldier's tx and ty to where the mouse clicked.

  6. Give the soldiers 1 extra integer: army number. Set to 0 for half of them, 1 for the other half, and draw them as different colors. Only let the player select units matching a particular army number.

  7. Give the soldier class/struct two more integers to apply to all soldiers: a killTarget index where another soldier's index can be stored (which can be used to change tx,ty coordinates if beyond firing range) and hitPoints integer that starts at 3 and goes down whenever hurt. #define or make a constant int that centralizes a definition for gun range. Have the code a draw line from any soldier with a non -1 killTarget to the position of the enemy having the index they're targeting.

  8. If an enemy soldier is clicked, instead of selecting that soldier, set the target of the currently selected friendly soldier to that enemy. Use random countdown timers between shots fired (maybe every 100-300 ms?) to randomize who wins, and/or give a probability of missing ( if(rand() % 3 != 0) gives them a 1 in 3 chance, etc.) and depict the missing, firing, or hitting in some way like flashing circles, sapping health from soldiers that take damage.

  9. If a soldier's target is defeated, either assign them a new living target at random or await player orders.

  10. Make AI by having countdown timers either per enemy soldier or per enemy army between discrete moves, which could consist semi-randomly of 1 of 3 things: move a soldier to a new spot, move 2 soldiers closer together, target a random/nearest player soldier, or team up with a fellow soldier by selecting the same target as his nearest teammate is targeting). Tune those probabilities and timers until it's reasonably fair.

  11. If you've made it this far - congratulations! It's an infantry war game now. A simple isUnitType integer added to the soldier class or struct could correspond to an enumerated unit type (TYPE_TANK, TYPE_PLANE, TYPE_ARTY, TYPE_GRENADIER, etc.)...

My friend Nate Yun (multiplayer software engineer for Battle for Middle Earth 1 and 2, Command & Conquer 3, Red Alert 3, and the upcoming C&C 4) saw this topic and mentioned the FreeCNC and OpenRedAlert projects, open source rebuilds of the original Command & Conquer and its prequel. The sources for these projects are available here:

FreeCNC - http://sourceforge.net/projects/freecnc/

...and here...

OpenRedAlert - http://www.ohloh.net/p/openredalert

Thanks Nate!

Note to readers about the C&C source: code for professional team projects can be daunting to look at, due to its sprawling complexity. By all means, browse and study away - but don't be scared off by it. For obvious reasons, hobby projects don't grow to anywhere near this size or level of complexity.


Programmer transitioning into game development


Q: I can code: experience in C, ASM, C++, Python, JS, Java, C# and Haskell. Give me a language, docs and a graphics library and I'll give you pong or tetris in 24hrs. How can I work toward creating a 2D platformer with RPG elements?



A: Technical ability is best thought of as a gate to entry - while it's great to have it behind you, it'd be counter-productive (and inaccurate) to presume that the most important things to learn and get practice with are already learned.

> give me a language, docs and a graphics library and I'll give you pong or tetris in 24hrs

Have you done this yet? Is it in shareable condition - i.e. has some acceptable art, plays music, has menus instead of going straight into gameplay, maybe offers some options like volume changing or customization of controls?

If not, and if it only takes 24 hours, then by all means, do it. There's a good chance that you'll learn some useful little details that you're one step from knowing (but don't yet), and it can also cement your current understanding of how to wire a game together into a tangible form. That also allows you to worry less about overall structure for the next project.

By the time you're working on a game project that you care about, you shouldn't need to devote much mental energy or development time to the aspects of it that every project needs. For the 2D platformer, you should be able to borrow code liberally from yourself, and build upon that, freeing you to focus on the creative challenges. This also means that as many pieces as possible will be starting at a second draft level of polish and functionality. The game that you want to build shouldn't be the first one you work on, presuming that you want the game that you want to build to come out as well as it can.

Programming language and platform are entirely up to you. My background and suggestion tends to be C++ for downloadable games (higher performance), ActionScript 3 for web stuff (larger audience, simplifies distribution and exposure). Since you have experience in technical matters I'll trust those details on your end.

Congrats on the strong start, and good luck with the road ahead!



Modding for design experience


Q: I recently made a simple 80's-style arcade game. In the past I got partway into a retro RPG but it has been on hold for a while. Professionally, my background and current work is programming intensive. I've also done some tinkering with OpenGL. Any suggestions on what to take on next?



A: Since you're comfortable with game programming end-to-end, but have less experience in the purely design side (level/puzzle design, unit balancing, compulsion loops, difficulty progression, etc.) - would you be open to beginning by modding a game or two? This would be my recommended direction, since it would help balance your experience, and would give a structural foundation for considering design problems apart from their relationship to programming.

If there is a commercial game with mod tools easily available, I'd be open to helping get some traction there. I used to mod Doom, Command & Conquer, Descent, and Quake, but newer FPS and RTS games come with better, official tools. If no commercial game that has mod tools readily available piques your interest, there are dozens of freeware games I've made that I could hand over the source and assets for as part of exercises relating to puzzle, level, and unit design. There are also countless little puzzle and racing games all over the internet that support user-generated levels, character tweaks, or other modifications.

Engines that are a couple of generations older, or making levels and tweaks for smaller homebrew games, offer a very important advantage: the lower fidelity of assets makes it more plausible to all be done by one person, in a reasonable period of time. Older engines can also be a good springboard toward more modern tech, where a lot of the same concepts are at work as fundamentals beneath a newer layer of technology and design thinking. This isn't to say, of course, that you should feel the need to change course from programming to being a level designer - I'm only suggesting that having some applied experience on the other side of the spectrum will likely unlock your existing programming ability to develop and act on new kinds of ideas in the future.



Game student seeking job


Q: I'm a game design student. What can I do to help my chances of landing a job?



A: I think - and this will come as no surprise - that one of the most important things to do is to finish hobby games on the side, outside of what's required by classes. There are a lot of students graduating every year with degrees related to game development, and there's a growing community of developers learning by experimenting from home. Combining the knowledge, experience, and background credentials of both methods of learning can go a long way toward distinguishing you in the job market. Not only does it look good to have both formal and independent training, it will also help your actual skillset stand out, in part by developing your ability to responsibly trust your gut when it comes to taking initiative autonomously to generate results for your own satisfaction.

Internships can make a big difference. Due to countless factors outside any applicant's control (shifts in industry, limited number of positions, the human element in recruiting...), they can't be counted on to work out no matter how qualified someone is. However, it's important to apply. Not just to one, either - apply to as many places as you can reasonably push yourself to apply to. Like a tree planting seeds, there's a lot of luck left in what the winds and weather will do to any given resume you plant. While there's not an application fee (as there is for, say, many college applications), I encourage thinking of the brief background research about a company/team/game as your application fee for any opportunities applied to - cover letters and conversation should never make it apparent that any given company is but one of the many that you've contacted..

Apply early in the school year for internships. Even if deadlines fall later, many of the best opportunities will wound up filled closer to summer break.

Networking is also critical to finding a favorable spot in industry. Attend the Game Developer's Conference if at all possible. It's a great way to meet people from all corners of the industry - I consider it the single most important conference for professional developers.

Also on the subject of job search, theses slides may be handy:

Improving the Odds - A Presentation on Game Industry Careers

(These slides have been previously linked to in Text Lesson Vol. 4, which contains a few other job search links as well, right above Section 5.)



Free E-Book on game development using Python


Q: I wrote a book called "Invent Your Own Computer Games with Python" and put it on the web for free under a Creative Commons license at http://inventwithpython.com. I wanted to write a book that young adults could read and immediately start making small games while learning programming. The book is project-centric and each chapter has the source code for a complete, small game. Do you know of any groups that could make use of this resource?



A: I've passed along the link to one of my developer friends who is more familiar with using python to make games, to see whether he has any thoughts or impressions to offer based on his experience.

[ ...One day later... ]

My Python guy had overwhelmingly positive things to say in response to the book - I'll include a link and some information about it in my February newsletter to help people that are looking to get started into Python game development find it. Thanks for passing this my way!

Fellow indie developer Jonathan Hartley's notes on the free e-book:


The book is totally appropriate for someone who has never programmed before. Explains everything, right from the ground up. Overall, I would wholeheartedly recommend it for its target audience: kids who want to learn to program specifically so they can create games. An adult, or someone who knows programming but wants to learn Python, will find chapters they can skim over, but it isn't condescending nor too simplistic.

In terms of Python, it does not remotely cover all language features (e.g. it doesn't mention creating your own classes) however it covers everything that you absolutely need to be able to create your own games, and it conforms to a fair 'pythonic' programming style using the parts of the language that it does cover.

+1 for maintaining a lively style without dumbing down
+1 for friendly and effective hand-drawn diagrams
+1 for use of the word 'poop' on page 21.

Things the book doesn't cover

* Splitting your program up into multiple files
* Creating new classes, object oriented development
* Getting ideas for games, designing the gameplay. Perhaps this is wise, maybe this is better addressed in other types of forum, not a programming book.
* More advanced programming: dynamic typing, the point of unmutable types, first order functions, higher order functions, decorators, classes & metaclasses, generators, generator expressions, coroutines, lambdas - but that's OK: It succeeds very well in its remit of teaching the reader enough programming and enough Python to create their own simple games. A perfect first stepping-stone.

My breakdown of the contents:

The first 10 chapters do a great job of leading the reader through the creation of many small games in the text console, which cumulatively cover all the basics of programming: variables; datatypes; expressions; strings & their methods; booleans and if statements; loop constructs; functions; variable scope; lists; dictionaries; multiple references to the same object (although not creating new classes of your own); short-circuit evaluation; assignment operators; string formatting; ascii;

Chapter 11 is on Cartesian co-ordinates; negative numbers; abs(); two minuses make a plus. At first I was taken aback because this seems so simple, but presumably if you haven't covered these things at school yet, then this is vital.

Chapter 12 to 15 create one new game per chapter, using the things we've learned thus far, and cover the creation of simple but effective AI.

Chapter 16 to 18 breaks away from the text console, using the Pygame library to display rectangles, polygons, circles and bitmaps in a window. This covers the Pygame event loop; reading the keyboard; animation; 2D collision detection of axis-aligned rectangles; reading the mouse; bitmaps & scaled sprites; sounds; music.

I was disappointed that the 'flags' parameter on the Pygame set_mode function was glossed over without any explanation ("you will never need this".) This is used to create a fullscreen window. For me, fullscreen mode is a vital component for me to enjoy a graphical game. Personal foible.

Chapter 19 caps the whole thing off with a final game incorporating all the techniques discussed, with music and the works.


While I wouldn't recommend just anything sent my way, as is clear from Jonathan's notes above, Invent with Python passes the inspection of someone who is experienced in what the book aims to teach. And best of all: it's free! So, if you're still looking for a way into programming, why not take a minute see whether Invent with Python passes your inspection, too?

(Disclaimer: I don't know the book's author, I am in no way compensated for promoting this free e-book, and there's nothing in it for me if the book gets more readers. I just want to help more people get started in hobby videogame development, and this presents a free, viable route!)



The sky isn't falling: common industry concerns


Q: I think there are a thousand problems with the business of making videogames, and I want to do whatever I can to fix some of them, and in the process, make life easier for creative people like yourself...

A: Developers would certainly appreciate some more idealists on the publisher's end. You're right that there are many things wrong with the business end of game development. A bit like the journey that lawyers find when they earn law degrees to do good though, don't be surprised to find (a.) challenges of politics and structural/process momentum have made it hard for those already attempting reform to do so successfully (b.) many of the things that are wrong today aren't due to laziness, ineptitude, or malice, but are instead the best scaleable way that anyone has been imaginative enough to solve a few previous wrongs while staying in business. It's certainly not my aim to hamper your idealism, only to better prepare it for battle by reminding it of what it's up against.

Sequels

> ...How we can build new kinds of brands so that we can capitalize on successful games without having to endlessly churn out sequels?...

The best-selling Halo, Sims, Madden, Street Fighter, and Zelda franchises are effectively releasing the same game again and again, with different maps, a few different items, and a couple of feature additions.

People that play these games like what they're buying. The Mega Man franchise fell off the horse when they started fooling around with different gameplay than what that franchise proved out.

These games have an established audience, an audience that can be studied, polled, and tested in focus groups to help steer the next project to make them happier. That makes it less of a financial risk, which enables a company to take bets elsewhere - as EA first did when the first Sims came out. (Its success looks obvious now, a decade later, but when it first came out it seemed like a really crazy move for the then even-more-male-dominated videogame market.)

Some games don't find their core value until the second or third iteration. Ask a friend to list their 5 favorite games, and take note of how many of those games are sequels - the last time someone was talking to me about their concern with a sequel-heavy market, it turned out that every one of that guy's favorite games were sequels.

Right now, the top 10 games on
GameRankings.com are Heavy Rain (spiritual successor to Indigo Prophecy), Dragon Age: Origins (PC) (spiritual successor to the Baldur's Gate series), Mass Effect 2, BioShock 2, Napoleon: Total War, Mass Effect 2, Aliens vs Predator (strikes again), Call of Duty: Modern Warfare 2, Assassin's Creed II and Dragon Age: Origins (360). Every single one of those games is a sequel, a spiritual successor, or a rehash. Tons of original projects are being made - they just aren't filling up the top 10 sales lists.

It helps to have market-quality design/engineering/fiction foundations to build upon. Then the next game can become a second draft in terms of polish and execution. Additionally, the semi-established audience means a higher expectation of return, which can help justify investing a little more in it than might happen for a totally new project.

Street Fighter 2, MechWarrior 2, Twisted Metal 2, and Grand Theft Auto 3 are all groundbreaking titles that left a significantly greater impact on the industry than their predecessors. The challenge, of course, is that it's often difficult or impossible to know until a project is nearly completed how well it's going to come out. Any given release could be the one to wake up the franchise and find its identity. Or, it could be something great in an entirely different way (Half-Life 2), it could be a mediocre release damaging the value of the franchise (Driv3r, Tomb Raider 3), or it could fall behind on technology and thus never see the light of day (SNES Star Fox 2, also arguably the treadmill that killed Duke Nukem Forever and delayed Team Fortress 2 for a decade).

And, for nearly every time a creative director goes with their gut to do what they believe is the right way to follow their inspiration, fans of the previous games cry foul. Metal Gear Solid 2 left a lot of fans confused.

It doesn't help either that in the past few console generations, game budgets have inflated from $1 million, to $8 million, to $25 million, meanwhile as the industry has grown there are more people competing with more products for space on the same shelves and top sales charts. The consequence of this is that if you can re-use considerable parts of the art direction, animation, sound effects, programming, tools and design patterns that were solved in one large budget project project - especially one that pleasantly exceeded expectations - to absorb a major fraction of those costs for a followup, it'd be crazy not to do it.

And more often than not, consumers are quite happy to buy straightforward followups to games that they liked, for the same reason people buy the same brands when we run out of something - it's easier to put down our money for something that we know, in advance, we're going to enjoy. Good sequels work for the same reason that people like TV shows as a series, rather than every show somehow being an original concept and cast. (Note too that latter scenario would cost far more to produce, while not doing as good a job at meeting consumer wants.)

Stuck Developers

> ...but I hate to see a team get trapped by their own success. The first Halo game came out in 2001, which means that Bungie's been working on Halo now for over nine years (probably 11 or 12?), and they've still got at least one more to release. Maybe the guys at Bungie are content to work on the same franchise for so long, but as a fan, I'd really like to see what they can do next. However, Halo's a far bigger brand than Bungie, and outside of the true enthusiasts, it's probably going to be a little difficult to capitalize on Halo's brand equity once Bungie finally does move on to something new...

The producer of old Halo left to make Stubbs the Zombie on top of the Halo engine. It's charming (but short), and the soundtrack rocks.

Fans and consumers keep up with company brands and logos, but the people behind those change companies and projects all the time. If they want to take big creative risks, there are valid business reasons (both from risk of downside and possibility of new upside) to not attach those risks to established brands.

Perfect Dark Zero was weak because the creative people that made the original game work left before that project to form Free Radical.

Meanwhile, some people prefer stability over creative or artistic exploration (and the risks that come with it). Certain specialists may be indifferent to what their project is about creatively - some of the business and financial types. A few positions may find extremely engaging work in games that play the same but find new technical challenges in the sequels - such as more robust multiplayer, or overhauls to the graphics code. Others still are perhaps themselves fans of the franchise, and they're just excited to be a part of helping to bring something that they love to new audiences.

People that like stability get drawn to stable companies and franchises, where they're likely to stay for as long as they can. Those of us that get restless easily and prefer to stay moving go elsewhere. The world benefits from having both.

On Nintendo

> ...Nintendo also doesn't rush to churn out sequels. They make one Mario Kart per console, and they continue to support it for the rest of the cycle. I'd love to see more publishers doing that, though it would also require them to be less graphics-focused...

Nintendo (1.) has R&D - just like SquareSoft, Sony, Capcom, and many other Japanese game companies do, and just like none that I'm aware of in the US - meaning they try a lot of ideas internally that never make it to the outside world and (2.) is a sequel factory (though as explained above, I hardly consider these "fightin' words").

Nintendo has been releasing Mario, Kirby, Zelda, and Metroid games that play pretty much the same for the better part of two decades, except for 1-2 changes to mechanics during that time per franchise. Within the past 10-15 years this has grown to include Mario Kart and Smash Bros as well. If they don't make 4 sequels of a given game per console (though there are notably several Zelda and Metroid games on any semi-recent platform), it's because they're making 1-3 remakes/sequels per console for a half dozen or more games.

Konami has done the same thing with Castlevania, Capcom has done the same thing with Mega Man, to a lesser degree with Resident Evil, and rather shamelessly with (Super Turbo Alpha Hyper New Champion World Warrior Challenger Edition EX) Street Fighter 2 (aka Street Fighter IV).

We translate The Odyssey by Homer into English so that today's readers can read it, because it's still very much worth reading. Those companies keep putting out the same games on each new platform because they're still very much worth playing.

Again though - I'm not criticizing these companies for continuing to re-release their best games. They'd be silly not to, and they'd be doing a disservice to today's players not to. My goal in highlighting that Nintendo does it too isn't to say that Nintendo is bad, but rather to emphasize that many of the companies generating sequels belong in a similarly respectable footing.

On Valve

> ...What about the way Valve approaches things?...

They release a lot of sequels, too, including episodes / micro-sequels. They also take a very, very long time between games. The riskiest things that they've done in recent memory: pulling in a student team to remake their student game as Portal, and making a zombie game plus its sequel (which, to be fair, had neat co-op and online multiplayer).

Meanwhile, relatively few outside companies use the Source engine, compared to, say, the Unreal Engine, and none of those games are anywhere near as high in profile as Valve's own releases (the same is not true for Unreal-based games, several of which were listed on that top 10 list I included earlier).

As for their building their own digital and indie distribution channel via Steam: absolutely brilliant.

Quality of Life

> ...How we can produce quality games without destroying developers' quality of life?...

A lot of us do that to ourselves. The dynamics of crunch have more to do with the waxing and waning of inspiration and creative rush central to the shaping of a creative product, the interdependence between art/design/engineering/marketing and how as each stretches itself it drags the others even further from their own expectations, and the fact that developers know our reputations and financial futures ride on squeezing every last drop of goodness and love that we can into our projects.

To expand upon that interdependence point from the previous paragraph: if I'm voluntarily staying late as a designer working on a wish list feature or extra level content, before doing the stuff that is on the must-do list (because I know we'll have to make adjustments for the must-do list, but not vice-versa, so this way I can be sure to pack more in), then it should be no surprise when soon after I'd be staying late even when it isn't my choosing to do the must-do items that I wasn't focusing on. But this wouldn't just throw me off. No, it could affect bottlenecks in the schedule, it could introduce a need for new bug fixing, sounds, or modeling work that otherwise could have been avoided, and so on. Now imagine every person doing this to every other person as the project gains momentum and people get excited. Combine that with a financial imperative to release on a certain ship date, and exactly why this turns into a train wreck nearly every time should be fairly obvious.

What if we just had 3 more weeks though? Well, we'd all try to cram an extra 5 weeks of work into that time, and then just have the same train wreck (or maybe a bigger one) 3 weeks later.

We're going to push ourselves. Our careers, our reputations, our sense of self worth (some of us are more neurotic than others), our certainty going forward that we gave it everything we had - all of this and more are potentially on the line.

Not all crunch is from the publisher (though certainly some of it is). When it is, I expect that it's in large part because they have enough experience working with developers to have gotten used to the fact that we sometimes work stupid hours, and may even feel like we thrive on it in reasonable doses (which is sometimes true, and sometimes isn't; adrenaline has an unpredictable impact on the quality of a complex industrial art project).

More on Crunch

> ...That comment was more a reaction to the recent Rockstar San Diego news and other horror stories I've heard about crunch...

There's certainly the other side to this, so I'm glad you're keeping this topic going a bit longer. My previous comments were not intended as a defense, or excuse, or justification - just to provide my own developer-side perspective, since I've found myself going into crunch mode for dozens of freeware projects that didn't even have a publisher, manager, or financial consequences connected to them.

The game industry is no longer comprised entirely of 20-something, unmarried, crazy spark plugs. A lot of these men and women have families to take care of and go home to - real obligations that they'll be (rightfully!) stressed out over missing for months on end, imposing a very real toll on someone's emotional health. Spending day after day sitting down inside, sleeping inadequately, and living on ordered food can take a non-trivial toll on someone's physical health, too.

Pacing of new workers who are full of energy and desperate to prove themselves - those who are sprinting and have not yet taken on a marathon mentality - is an issue with a long history in traditional manufacturing. The long and short of it: managers would love to capitalize on it, given an opportunity to do so, whereas coworkers may be inclined to discourage such behavior, or at least advise against it to help guard against early burnout.

And, certainly, every now and then, someone inevitably comes along and fills a management position that isn't a good fit for that role. While this can be true for any job, when it's a manager the damage reaches further, and when the project suffers it may not be as obvious who is to blame.

Those situations are clearly unfortunate, although it's difficult to really say what more can be done about them. If the person's behavior is hurting the project, and it's clear that's what's going on, then it's in the company's interest to let that person go. Employees are also free to leave, although naturally this can be tricky, and is perhaps an unfair shift in consequence. Sometimes people take things to the blogosphere and courtroom, both of which (especially when combined) seem to have been fairly effective in recent memory.

Changing Release Dates

> ...When I asked a few people how it was possible to implement a marketing campaign for a product whose release date is constantly in flux, they would sort of shrug and say, "That's video games."...

The only way to know, before something is done, exactly how long it will take, is to have done something almost exactly like it before (this is again where sequels are nice) or to set such modest goals that they can be predicted without much concern for miscalculation.

Some projects discover their identity mid-stride, internally rebooting, discovering an emergence and inspiration spike that can't be planned - passing on it would miss a potential hit. However, making a habit of betting on it ahead of time in terms of budget allocations and schedule would be a waste of money on most projects that will never spot a goldmine during their development process.

Part of what looks like laziness or indifference is that the scheduling of industrial arts needs to be dynamic if there's any hope at spawning new hits, as opposed to merely re-delivering on past brands or shooting low for the sake of making Excel spreadsheets and calendars look good.

Predictable Release Dates

> ...In terms of release dates, I think marketing games would be a lot easier if we didn't start the PR cycle years before the game is complete. Why not wait until the game is actually finished, or in the final stages of production where the rest of the schedule is relatively predictable and the assets are finished, before we start advertising it? Then, you can set a solid release date, show off actual assets rather than mockups, and organize a stable marketing plan...

There are a few reasons for not doing this - although provided these benefits can be covered some other way, there might be other benefits in changing it. Namely:

  • If marketing starts right before the game is released, then there isn't sufficient buzz built up pre-release to meet the sales figures necessary on the day of release to hit the top sales charts, which in turn are an important piece of reaching high enough sales to justify major expenditures.

  • If the game is released later, say, by waiting a long time for marketing to build up while the game sits around already finished, then by the time it is released its tech is months behind what the competition has done in that time, and the probability increases that a competitor will be first to market, making you look like an unoriginal follow-up even if your project started (or was finished) first.

  • Even if you release before the competition, if they start their marketing cycle first, it can make you look like you ripped them off, which can threaten a brand's image as a thought leader or innovator. Unless someone is doing something really out there, like Nintendo did with the Wii, at any given time there's a pretty decent chance that someone else is working on almost exactly the same thing.

Used Games

> ...When I asked someone in Sales for their opinion on GameStop and the used market, they said that publishers have basically come to terms with it. A huge amount of the industry's business is still done through GameStop, and the used issue is just a cost of working with them...

GameStop hardly has us in a corner on this one. Between Steam, Direct2Drive, the App Store, WiiWare, PSN, XBox Live Arcade, DSiWare, and a growing mountain of other means of digital distribution, it's unclear what the future of brick and mortar sales of digital products (including film and music) looks like. Between Netflix, Redbox, iTunes, Hulu, and torrents, it's pretty clear that Blockbuster is dying off, and looking at the similar list of automated middlemen for the game industry, GameStop has plenty of reason to be worried.

Their scramble isn't them being greedy, it's them scrambling to still exist and maintain their significance, which a business is obliged to do. A business owes it to their employees, customers, and shareholders alike to not just roll over and die any time the market changes. Meanwhile, to consumers, the resale value is part of how they can still justify that $50 retail price tag.

For what it's worth, currently their added value for customers is making games easier to browse than one can do online (in some sense), making used games available at very low prices, buying games back (even if they don't pay much), and "warranties" (which don't have much real value, but do have perceived value). They make an effort to have "friendly and knowledgeable employees" but that inevitably varies one store/region to the next. Lastly, they offer a retail experience, which many consumers are still more comfortable with - serendipitously peek in while passing at the mall, make an impulse purchase, and go home with a tangible case and manual in hand.

If the publisher dislikes the value and visibility that GameStop has to offer, there are plenty of alternative distribution channels, including building your own (as Valve has successfully done). So long as our industry still needs GameStop as much as they need us, we have little right to be indignant that the tides threatening their existence have not yet swept them away altogether.

Engine Development

> ...How difficult is it to build an engine like Source and continue adding to it and modifying it for many different IPs?...

It's extremely difficult, requiring a great deal of talent and experience for the engineering, design, and management aspects. Even with all the money in the world thrown at it though, there's still be no guarantee that it would come out better than the competitor's engines which have been tested and refined through multiple other titles already. Speaking of which, it's not just difficult: it can be absurdly expensive.

This is what I was referring to when I indicated that multiple sequels need to be hits for a franchise to recoup the costs of developing its own engine. Typically a studio has to have a few runaway hits under its belt before it can come close to taking a chance on building its own 3D engine that's suitable to compete with other established technologies, and it takes a long-term strategy and a luck to recoup the costs that go into it.

All-in-all, trying to make an engine in-house is a lot more of an expensive and risky course of action than simply licensing an existing technology platform, particularly if nothing about the game requires a specialized engine to work. The engines that are already out there are stable, proven, have strong tool pipelines, and are competitively priced when the alternative is to try to roll your own.

High Price

> ...The $50/60 price point seems self-defeating, especially for an industry that supposedly wants to be mainstream some day. And if that's the only way to sell games that take three to five years to build and tens of millions to finance, then maybe we shouldn't be spending that much time and money on those games. It often forces teams to fill their games with fluff, even though no one actually finishes those 30+ hour epics, or tack on useless multiplayer modes in order to justify the price...

It's worth pointing out that sometimes the 30+ hour epics and useless multiplayer modes are a product of developers falling in love with their game (either the producer always dreamed of making a flight simulator, the programmer wants to prove to himself he can do it, the designer wants to feel current by working on the latest game trends...), and sometimes it's an unfortunate byproduct of marketing/publishing pushing the development team to add bulletpoints for the box as part of a marketing strategy, even if no one on the team is crazy about those features. And, as mentioned earlier, it's often impossible to know ahead of time how well (or poorly) something will come out until it's (nearly) completed. If we knew the results in advance, there would be no risk to distribute through publishers, meaning that most videogames wouldn't exist, and publishing might not be a business.

All that said, a few years ago the 2K sports franchise was experimenting with price differentiation, and a number of Wii titles show up in the impulse buy shelves of superstores at prices well below $50/$60...

Huge Games

> ...In any case, I'd probably argue that, if the only way for you to profit on a $25-million game is for it to become a smash success and spawn a trilogy, then maybe you shouldn't be spending that much money in the first place...

Of course! That's why there's an increase in the number of games being made for iPhone, web, Android, DSiWare, PSN, XBLA, PC download, WiiWare (or, to a lesser degree, plain Wii), and other substantially lower-cost (compared to X360 or PS3) development channels. Then the challenge is that instead of being able to charge $60/copy, like we do for a $25 million project, we're fighting in the $2-$15 space to recoup our costs, which means we wind up fighting many of the same fights just on a different scale, and with more direct competition.



I have a question!


If it's not covered here - and you don't see it in the topic listings for
my previous text lessons or the Reddit AMA Special Feature, e-mail me at chris@gamedevlessons.com or tweet the question to the new @GameDevLessons account.

If it's an unusual question, I'll reply directly; if it's something likely of interest to other developers, I may work it into a future write-up.


III.) Special: A Reddit Conversation - Rapid Q&A


Last month, I was asked to submit an AMA (Ask Me Anything) topic to the website news aggregator Reddit. This in turn created a temporary forum where people were able to pose questions that might be shorter than what someone feels comfortable asking by e-mail. It generated 112 comments - about half of which are my responses or replies to my responses, so ~50 questions - on a variety of introductory topics, some of which readers of my monthly write-ups might find useful.


> > My full Reddit AMA thread on hobby videogame development is available here < <

(Update: I later deleted that Reddit account. Consequently most of my posts on that AMA are now marked as coming from "[deleted]". My apologies if this makes it trickier to follow!)



IV.) Donations


If you find these lessons valuable, and can afford even a small donation of $5.12, $10.24, or more ($40.96?) to show your support, the encouragement of readers like you helps me continue setting aside the time needed to keep quality a priority in the text lessons and one-on-one feedback. PayPal makes the transaction fast and safe - you don't even need to have a PayPal account if you have a credit card!




Don't have $20.48 to donate? I'll be just as happy if you'd instead tell a friend or two about these text lessons! Virtually all money donated goes back into advertising for these newsletters anyway (I'm in this to help people, not make a quick buck), and your personal referral will likely be a lot more effective than a few more views of the ad that I run on Facebook.




Chris DeLeon

chris@gamedevlessons.com


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/letter11.html Sending the link works better than copy/paste, since that way they'll see the latest updated version with Q&A or corrections.


PPS If you'd like to be kept up-to-date with these monthly mailings, simply subscribe to the GameDevLesson.com Text Lessons: http://gamedevlessons.com/?page=free and/or...

(New!) follow @GameDevLessons on Twitter.