¡Nuevo! En español. (Spanish translation by Andrés de Pedro)
GameDevLessons.com has migrated to HobbyGameDev.com - please update links!
Chris DeLeon's GameDevLessons.com Newsletter
Vol 4 - July 5, 2009
Hello!
I'm Chris DeLeon (about me), and thank you for joining me for my monthly videogame development newsletter, vol. 4. 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.
These newsletters are broken up by skill level. Earlier sections are not needed to understand later sections. You're of course welcome to read it end-to-end if you wish, but for most readers skimming and skipping will probably work best.
II.) Beginner
III.) Intermediate
Stickiness - Why the Player Keeps Playing
Thinking Like a Programmer, Thinking Like a Designer
IV.) Advanced
Benefits of Working with a Company
VI.) Schedule
Volume 1 - April 2009: gamedevlessons.com/lessons/letter1.html
I'd encourage at least checking it out if you haven't already - plenty of resources and starting material.
Volume 2 - May 2009: gamedevlessons.com/lessons/letter2.html
This edition includes an extensive article on the value that videogames offer in the form of experiential personal development.
Volume 3 - June 2009: gamedevlessons.com/lessons/letter3.html
Presented as a series of lists, this one includes starting tips for beginners, notes on transitioning from technical/artistic skills into active game making, and questions for advanced developers to consider It also included a perspective piece on the role of imagination in videogame playing.
Volume 4 - July 2009: gamedevlessons.com/lessons/letter3.html
This is what you are currently reading. Please share this link with others, instead of copy/pasting or forwarding this text around. By viewing it online, you can see the latest version with fixed typos, late clarifications, or added Q&A for questions sent my way.
Subscribe: gamedevlessons.com/?page=free
If you found this link someplace other than your e-mail inbox, and would like to be notified when the next edition is available, you can join my spam-free mailing list. It only takes a minute, I will never send out more than one e-mail each month (only to announce these newsletters), and it's easy to unsubscribe at any time.
If you wanted to become a master chef, would you begin by writing down recipes on paper?
I would start by following recipes. Then I would modify the ingredients or cook time in my favorite recipes, experimenting in the kitchen. Only after a great deal of experimenting would I consider inventing a new recipe starting on paper, since it would then be informed by grounded consideration of how various ingredients combine and react to different preparation processes.
If you wanted to become a singer and songwriter, would you begin by writing notes and words on paper?
I would learn some chords, and take vocal lessons. I would start performing some popular songs that my friends and I would immediately recognize. I might write my own spoof lyrics to the tunes I know, add my own flair to the notes, or read up on music theory. The first real inventing would likely to involve plucking the strings or playing the keys, and experimenting with how words come together in my voice. Only after a great deal of experience inventing directly with instruments and voice would I have a sufficiently grounded understanding of how music works to put notes on paper as a first step.
So why on Earth, when most people want to become a videogame designer, do they begin by writing design docs?
Doesn't it make more sense to...
|
Is anything stopping you from writing down a recipe when you've never cooked before? Or putting notes on a staff with words underneath, if you've never touched an instrument or sang a song? No. Of course you can do that. All it takes is a pencil. But it will be absolutely terrible. The same goes for videogame design. Except that unlike those other examples, a bad design doc can burn months or years of a lone developer's time, or from the lives of a team of people, to yield something that either won't get finished or that members of the team won't be proud to show.
I'm not trying to discourage anyone from starting. I've devoted my life to making videogames, and helping others do the same. I'm only trying to warn gravely against a common first step that I fear may do damage that takes years to reverse.
Keep your cooking in the kitchen, following recipes at first. Let your instrument and voice guide the music you compose, but only after learning classics or hits.
For early steps in the game making experience - notably, modding a game that you already like - game making tools are a decent way to simulate modding of a commercial project. A lot of game making tools are crude level building tools with some other options exposed, and this can provide a sandbox for experimenting with systems/unit design (game balancing) and level design (layouts, scenarios).
http://www.ambrosine.com/resource.php has a very long list of game making software. I'm biased toward PlayCrafter.com on that list since I helped architect and build it, specifically trying to minimize the issues that other game making software runs into. Every tool on there has its own respective strengths and weaknesses though, which is why I'm sharing this link. (In case that previous link dies for any reason, I've copied the list of links here: http://gamedevlessons.com/lessons/ambrosine.html.)
Unfortunately, every game making tool faces limitations. For the reasons that follow, real videogames (the ones you buy in the store, stay up all night playing online, or pay to download) are not made with game making software. Real games get made by programming, image/audio creation... but we'll return to that in a minute.
Unavoidable Limitations of Game Making Tools
|
It may partly be because someone has to really be into it to get started with game programming, but everyone I know that has started by programming has made a lifelong hobby or career out of it, and all but 2 of the people I know that started with game making tools burnt out and gave up after getting tired of the handful of things their tool was good for building.
The Beginner section of Newsletter Vol. 1 has a brief intro into the basics of how real videogames get made. None of the above limitations about "E-Z" Game Making Tools apply - pretty much anything that can be imagined can take place in a videogame, looking and working any way that you can dream up. The catch is that it will take more determination and patience to develop the skills needed, and videogame development done the real way will take weeks or months to complete, instead of hours (until/unless you're an expert doing mini projects). On the upside, these are skills that can grow over a lifetime, are useful professionally, and can be done entirely for free on any computer.
http://gamedevlessons.com/lessons/firstprog.html - I've recently put together a brief guide for getting started with Dev-C++ 5 (PC only; use XCode on Macs) to begin C/C++ programming. If you're looking for a good introductory book to C programming (most other languages build off of C, including the industry standard, C++), I got started with C For Dummies by Dan Gookin.
Still Not Convinced?
Here's an enjoyable ted.com video emphasizing that being patient in exchange for better outcomes may be a key deciding factor in your long-term success.
Stickiness - Why the Player Keeps Playing
There are 3 distinct time frames that need to be addressed:
|
Thinking Like a Programmer, Thinking Like a Designer
Learning gameplay design will make a gameplay programmer a better gameplay programmer.
Learning gameplay programming will make a gameplay designer a better gameplay designer.
The ancient Greeks espoused an ideal of balanced unmatched in modern civilization. Every adult should have experience and developed skill in carpentry, playing an instrument, participating in athletics, speaking persuasively on legal and political matters, dancing, and so on, quite independent of any individual's particular profession or path in education.
Although "equality" is a word that has profoundly positive connotations in the modern world (to the extreme that I expect this sentence will anger some readers), one downside that has come with it is the false notion that to gain ability in one area somehow hinders ability in another. To a literal extent, if every hour of the day were occupied with productivity and learning, this might be true; I contend that this is the case for no one, except perhaps the sort of person that drags out whatever tasks are on their todo to sparsely fill whatever time is afforded for the work to be done.
If you'll put the time and energy into learning design that designer A does, and you'll put the time and energy into learning programming that programmer B does, you'll be far better off in your abilities than either person A or person B.
For the lone videogame development hobbyist, this sort of thinking essential to unblock progress and minimize the risks of depending critically on others. For the professional in a team environment, this can aid tremendously in communication by improving understanding in the languages and mindset of other workers and their processes.
A downside of the information age is that there's an over-emphasis on what people know, with much less attention given to how people think. There's much more to what differentiates an musician from an automobile engineer than simply what they know, or what they practice. The ways of thinking are different - affected and formed, no doubt, by practice and knowledge - but it isn't just a wikipage plus repetition.
Likewise, to be acquire skills in both design and engineering isn't simply a matter of knowing what both know. It's important to learn the differences in how specialists from both disciplines think, and how to switch gears to fit the needs of different situations.
What follows are generalizations. "Design" is a huge field covering many different areas of expertise, and "Engineering" comes with just as much history and complexity. Since the purpose of this newsletter is to help provide perspectives and information relevant to videogame development, what is said about design and engineering in this table (and in these newsletters in general) is based on how I have seen these roles play out during team and individual videogame projects.
| Gameplay Design | Software Engineering |
| Answers what to do, and why | Determines what's possible, how to make it work, then makes it work |
| Decides features, invents the systems of interaction, lays out interfaces, prepares missions/levels/scenarios, balances units/items/weapons/characters, evaluates potential alternatives... | Plans, programs, tests and fixes programming code for gameplay systems: player input, artificial intelligence, level formats, network functionality, graphics rendering... |
| About tradeoffs and compromises | About exactness and robustness |
| Accounting for many things at once | Isolating, solving 1 problem at a time |
| List of parallel goals/constraints | Ordered todo list |
| Exploring many variations to pick the best one(s) to finish | Thorough planning to minimize rework or redundant effort |
| Done poorly, the game isn't enjoyable, or fails to stand out as original | Done poorly, the game crashes, or fails to impress with novel tricks |
| Done well, the game sells itself to anyone that takes the time to try playing it | Done well, the game runs smoothly, is stable, and may accomplish what others don't know how to do |
| Which answers are "best" tends to be subjective, though fundamental principles make certain solutions far more or far less desirable than others | An optimal answer usually exists, although compromises may be made from consideration of time, skill, or prior experience |
| Human feedback takes place throughout, and taking stock of the needs by all groups involved (business, technical, player, peer designers) is a significant part of the work | Requirements are handed over at the outset, and clarity or efficiency of implementation may be judged after completion; while working, machine feedback (as errors) is constant |
| Often involves inventing a novel discipline (new jargon, concepts, groupings) around the task at hand | Builds upon generations of patterns, systems, and generalizable solutions |
| More like art or writing, in treating most problems as one-of-a-kind, though understanding and considering historical approaches | More like legal drafting, in often solving complex problems rigorously via a mixture of previously solved problems and some particulars of the case |
| Focused on player's overall impression, employing consistency and polish to create expectations then fulfill them | Focused on whether each isolated detail works as expected, including how the overall systems connect the parts |
| Although good process distinguishes a good designer from a bad one, end results are what the world cares about | Although good process distinguishes a good engineer from a bad one, end results are what the world cares about |
Special Abilities from Multi-Classing
The application of software engineering thinking in design work is technical design.
The application of design thinking in software engineering is architecting.
(...in the programming/technical sense. This has nothing to do with buildings.)
The combination of software engineering thinking and design thinking is useful in discovering new forms of gameplay by playable prototyping. It brings together the thought process of what's worth doing with an applied understanding of what's possible with the technology.
(mostly as it applies to indie hobbyists)
You've made one or more games. Congratulations! I assume that you have made it possible for people to get to your game, but if you're like most indie develoeprs, odds are good that you haven't gone very far out of your way to make it probable that people will find and play it.
As the New York Herald Tribune noted long ago, "doing business without advertising is like winking at a girl in the dark. You know what you are doing, but nobody else does."
The Independent Games Festival at the Game Developers Conference every year in San Francisco is one outlet that top indie developers have used as a platform to get the attention of players, including Jenova and the gang at thatgamecompany (Flow, Flower), and Jonathan Blow (Braid).
The forums at TIGSource have exploded in the past few years giving indies better visibility of one another's work.
In my own path, Facebook ads were one of the ways that I advertised for my iPhone app Burnit (more info about it is available at http://chrisdeleon.com/burnit/), and I found many benefits to using them. They were extremely cost effective - for a very modest budget of a couple hundred dollars, I was able to run ads for two weeks reaching tens of thousands of people every day. Cost can be controlled by setting a limit of how much you're willing to spend per day, and for how many days you want the ads to run. Even better, the ads on facebook are extremely easy to target - say, you only want to run your ad (or 1 version of your ad) for males, located in the United States, ages 15-25, that mention the word "penguin" in their profile. Done. Facebook even gives you estimated numbers for how many people on Facebook fit into the details you're providing, to see how different constraints are affecting the size of your targeted audience.
Other big wins are to get your game hosted on other sites. Marketing people refer to something called, "Nascar Blindness", referring to the point that even though few people in marketing watch Nascar races, it would be dangerous to conclude that no one watches it and therefore it's a waste of time to advertise there. Don't assume that everyone on the internet goes only to the sites that you do (!). Even though many different portals/hosts have different submission criteria (formats, icon image dimensions, etc.) it's well worth the time to input those values into as many sites as you can uncover. You make content, and there are lots of websites/reviewers/portals that are constantly on the lookout for new content they can share with their users.
While I suspect this is obvious in 2009, just in case you're still on the fence: having a website for your projects is crucial. For that I've been extremely happy with StartLogic (http://www.startlogic.com/) for many years, for their solid uptime, low price, ease of use in creating new domains or e-mail addresses (all of which I forward to/from/through one gmail account anyway), and the flexibility to meet my varying webspace and traffic needs every month. If you don't have the time or money to devote to doing anything fancy, don't let that stop you - a simple text website with links to your work is infinitely better than nothing at all!
After spending weeks, months, or years on a game, surely it makes sense to spend at least 3-5 days devoted entirely to making sure as many people as possible will (not just can) discover and enjoy it?
Keeping Metrics
StatCounter (http://www.statcounter.com/) has been a key part of my websites and videogame work for years. It's 100% free, quick to set up, and provides loads of useful information to you about who is visiting your websites, from where (geographically and by website), and for how long. It displays charts and graphs of visitor traffic over time, distinguishing between unique visitors and page visits, and plots maps of the past 500 visitors to each website you set up with it. Adding StatCounter to the pages hosting your games makes it possible to see how many people are playing, and is important in assessing the usefulness of facebook ads, blog posts about your game, and Facebook/Twitter postings about it.
If you're making an online Flash/ActionScript3 game, I'd strongly encourage taking 10 minutes to implant MochiBot in your application: http://www.mochibot.com/. MochiBot enables you to keep stats on where your web game is being played from, which can be a huge morale boost to go from wondering why no one's playing your game to finding there are tens of thousands of people playing it elsewhere on the web.
Disclaimer: I'm Not a Salesperson. Honest.
To be perfectly clear: I don't do paid endorsements for anyone, and the only reason I bring up GDC, Facebook Ads, MochiBot, StatCounter and StartLogic are because I think what they have to offer is well worth investigating, and all of these have been postive pieces in my own journey. I point you toward them purely from the hope that they might help you along, too.
Always, Always Link Back to What You Do
If your game is downloadable, include a link either in the same start menu folder or in the program itself to jump to your website. If your game is online only, definitely include a link to your page. 4-5 years later you may still find traffic coming in from all over the world, eager to see what you're currently up to. No matter how old it is you, it will always be new to billions of potential players, and for a few extra seconds of work you can convert fans of your past work into traffic aware of your latest work.
Benefits of Working with a Company
Experienced, but still haven't tried the jump to professional work? Or, currently doing professional work with a company, and thinking about how life might be different if you split off to be an independent hobbyist?
My own career path in life up to this point - from independent hobbyist, to a year with a huge game company, to helping establish a start-up (PlayCrafter.com), around back to an independent professional - has given some readers and friends the impression that I would discourage working for an established company. This is definitely not the case! Jobs are not one-size-fits-all, and the big company environment simply wasn't the best environment for my particular strengths and interests at this time in my life. I know plenty of folks that are quite happy and productive in corporate environments. Let's take a moment to enumerate the pros of working on a team of pros.
(As a disclaimer, it's obviously possible to work on a team as a hobbyist, and also possible to work alone professionally. For a variety of reasons, most hobbyists work independently, and most people's start professionally with an established company. That distinction is generally assumed in the points that follow.)
Room to specialize. Want to focus your attention at being the among the best in the world at graphics optimizations, writing scalable networking code, 3D modeling futuristic settings within a memory budget, or creating complex 3D levels? Those kind of opportunities are virtually non-existent in the independent game space, due to smaller teams, smaller budgets, and smaller time frames.
Stability. Large, established companies with diverse product portfolios, distributor partnerships, and popular IP ("intellectual property" - Star Wars, Indiana Jones, Harry Potter) can pay a solid paycheck on a consistent basis, and they can absorb the financial impact of the inevitable (but unpredictably) rough project now and then.
Networking. The other side of that stability point is that, for better or for worse, there's high turnover in the game industry. Many people at many companies either leave or get fired within their first two years at any given company, either from seeking a better fit, seeking something different between projects, or internal shuffling. I knew this was true at companies besides the one I worked at because, here comes the point, I had coworkers from dozens of other companies that told me about it. And 4 years after I spent my first summer at that company, most of the people that I knew then have moved (or have been moved) on to other companies in other places. The result: by spending 3 summers at an established company, I now have friends and contacts all over the world, across dozens of companies. Not too shabby.
Generations of Know-How. In any company with dozens, hundreds, or thousands of people operating for more than a few years, there's an internal science of process created around keeping the company and projects on track. Whether or not you like what they're doing, they're pretty good at doing it by the time you get there, which means there's a pretty solid chance that the game you're working on will make it to the market place, and by the time you're done with it several new opportunities will be starting up internally.
Credentials. This absolutely, positively, had nothing to do with why I wound up where I did. But in hindsight, it was one of the most significant takeaway advantages. That I had been making videogames independently since 6th grade didn't mean a thing to most recruiters or students, but as soon as I had an entry level internship at a recognizable company, people were open to hearing about my other work.
Large Project Visibility. When I entered a big company environment, my best freeware game had about 50,000 downloads, which seemed like a big deal to me at the time. A big company makes games that they can charge $50-$60 for, and if they sold that few copies they'd likely consider the project a failure. Magazine articles get written about these games years in advance. The games sit on store shelves. Strategy guides get written by outside companies about these games. FilePlanet hosts demos to them, cheat code websites have pages devoted to them, mod communities arise around them, and there are fans eagerly awaiting it when it comes out. Those are cool things to be a part of.
Upward mobility. Big companies have positions that rank higher than "the guy that does most of the art", "sound person", and "programmer / designer / producer combo". Positions with really impressive words in the title, like Vice President of this or that, and Chief or Executive (or even Chief Executive), and so on. At a big company, promotions are available to those people that consistently demonstrate a good attitude, sound decision making, and domain expertise.
If anything, I would encourage taking any formal opportunity that you're able to line up in the game industry (except QA. See next section.). Whether as a design intern, entry level software engineer, or whatever other title you might be able to find someplace, it can be incredibly valuable experience, and time well spent.
Starting in QA/Playtesting is usually a dead-end
Playtesting is a very brief and unrewarding experiment for most of the people that go into it. I'm guessing 99%, and there's a chance that may be a realistic number. I know only a few professional game designers, 1 professional software engineer, and 0 artists that got their start as a playtester. It's typically short-term work, kept separate from development teams. Because it assumes zero background in videogame development ability, you're unlikely to have any opportunity to differentiate yourself from the other faces in the crowd. In theory it's a way to get paid to play videogames. In practice, it can be a two month monotonous job, paying you very little to keep replaying the same part of the same game all day long and filling out reports about it.
Considering keeping it strictly as a hobby?
You'll always have the option to find a less time-consuming job to focus on your own games in the off-hours, or to move home and spend time making games on your own. Now is as good a time to go job fishing as any. Despite whatever anyone says about this being a bad market for job hunting, (a.) as I'm sure you've read someplace, game industry employment went up while most other industries shrunk last year (and b.) statistics only affect charts and graphs, but you're just one person. I.e. all you need to find is one opportunity, and they're definitely still constantly popping up and finding their best available fit, every day of every week.
Additional Info on Job Searching
Slides from a game careers talk that I gave at Carngie Mellon in 2006:
http://interactionartist.com/jobs/developer-development-final.pdf
Links to industry career resources:
The interview:
http://www.indiegamepod.com/?p=1202
This was an interview about my daily experimental game projects, for Action, of:
My official site for the daily experimental projects is here:
The JayIsGames article on my experimental work may be a better place to start:
http://jayisgames.com/archives/2009/03/interaction_artist_games.php
My appointments are currently still filled until September. Feel free to drop me a note if you are interested in working something out in advance.
If you only have a one or two line question, I'll probably answer it for free. If it's a particularly good and succinct question, I'll include the answer in my next newsletter.
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/letter4.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 Monthly Newsletter: gamedevlessons.com/?page=free