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 14 - May 31, 2010


Hello!


I'm Chris DeLeon (about me), and thank you for joining me for my monthly videogame development Text Lessons, Vol. 14. 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.) On the Source from Full Videogames


III.) Intermediate - $0 Flash Development Part 2: Flash Game Core Tutorial


IV.) Advanced - Bottom-Up vs Top-Down Game Design


V.) Special Topic - Reader Questions About Chris Crawford


VI.) Call for Your Games - Free Publicity for You


VII.) Donations



I.) Past Editions, Subscribe


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


To be notified when the next edition is available, 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.


Though these writings are not intended to be cumulative, the various topics in each may prove helpful. If you're new to these, I recommend Newsletter Vol. 1 for its non-technical conceptual introduction to programming, and the links it contains to free resources for image editing, audio work, 3D modeling, and other asset creation.


II.) Beginner - On the Source from Full Videogames


After the Humble Indie Bundle event ended, most of the games from the bundle pledged to go Open Source, sharing their source code with the world.

Before I go on, I think it's necessary to clarify a few things: (1.) I enjoy all of the games from the Indie Bundle (2.) I bought it (3.) I 100% support the spirit and movement toward both open source software and indie videogame development. In short, it is in no way my intention to detract from the decision to open source these projects, nor from these projects and the developers behind them. I love these people.

This isn't about the games, or the developers, this is about the developers-to-be drooling over the source code release, under the impression that it will be an excellent learning opportunity.

If it is, then this source code for a variety of commercial games ought to be pretty helpful, too, legally made public courtesy of the developers:

Aliens Versus Predator Gold Edition (10.0 MB), Blood 2 (2.34 MB), Castle Wolfenstein (7.07 MB), Descent 1 (1.42 MB), Doom 1 (Linux) (354 kb), Doom 1 (Atari Jaguar) (303 kb), Duke Nukem 3D (3.83 MB), Freespace 2 (2.64 MB), Half-Life (4.99 MB), Hexen 2 (2.91 MB), Hexen & Heretic (829 kb), No One Lives Forever (5.30 MB), Quake 1 (3.06 MB), Quake 2 (1.40 MB), Rise of the Triad (3.84 MB), Serious Sam (3.74 MB), Unreal (680 kb), Wolfenstein 3D (5.59 MB)
-------------- (Datafiles are not included, i.e. you'll still need the original games.) --------------

I'm not seriously suggesting that you download or read those. But there they are if you're curious.

The indies that released their code for the bundle apologize for its organization - Lugaru's developer's wrote, "The coding style is what you might expect from a self-taught high school student, so it could be a challenge to understand." The developers of Penumbra likewise noted, "the code is far from clean and as expected quite hackish in places." Meanwhile, why has it taken more than two weeks for the Aquaria and Gish source code to be zipped and put on a server? If their experience is anything like when some Linux developers politely asked for the source of Battleship 88, the delay is due at least in part to trying to figure out what can be cleaned up or commented in the code to make it less embarrassing, or at least a little more useful (angles in the Battleship 88 are stored in 3 or 4 different measurement systems).



Lugaru by Wolfire Games



When the people that made Lugaru made it, it was their very first time making Lugaru. It isn't just indies though. When id Software made Wolfenstein, Doom, and Quake - get ready for it (!) - that was also their very first time making those games. Their code, at least by the standards of untested arrogance typical from someone that has never created anything new (a category that includes most programmers, who throughout their education and work life only wrote functionality to do what has been done), is bound to look like an inelegant mess.

Code for finished games is hacky. Nightmare-inducing hacky. Toxic, maybe just a little bit disillusioning hacky. Trying to learn game programming based on the source code for completed commercial games is like trying to learn the legislative process by reading through current corporate law - in either case, it's trying to deduce the process from the incredibly complicated and lengthy result it generated, minus the context of compromises and circumstances that made it possible.

Source code from finished commercial projects is useful if someone is interested in tinkering with enhancements, ports, or modification of the games, but their utility as something to study for learning videogame development is rather limited.

In many cases, for anyone other than the developer(s) that wrote it, it would take more effort and expertise to understand, pull out, and repurpose say, a game's graphics code, than to just write what's needed for a particular game. Not only that, but the sort of optimizations and features worked into a game's code are often fairly specific to that game; one cannot, say, easily yank the combat out of Lugaru and slap it into the Penumbra code for improved rendering, nor gut the level code from Penumbra and use it in place of the outside areas of Lugaru. Remember when, as a kid, cartoons showed brains being switched between bodies, and it made conceptual sense, but as we got older it became obvious that the tangled interconnections make this impossible? It's like that.



Penumbra by Frictional Games



As for adapting the code for a Total Conversion Mod - that is, altering the game into an entirely new game - this is generally a big team undertaking on the order of complexity of producing a commercial videogame, and often does not even require most of the game's source code (only the gameplay portions, at most, which are often in script or standalone dll's to improve iteration). The majority of that mod work is in asset creation: building levels in the map editor, animating and texturing models in Maya, recording/editing sounds, and so on. That's effectively what the sequel to any game is, and it's also what any game is that's built on a licensed engine (Unreal, Source, etc.), which is to say that it's not the best starting point for a beginner.

By the time the game is public, the assumptions that went into the program's initial design are slightly out of date. By the time code gets released later, sometimes the operating system, graphics/audio/networking routines, practices, or (less so in the examples above) programming language can be out of date. Things were done in the program code that these days a graphics API call can do faster in hardware, or optimizations were made that now have only a trivial effect on performance.

But even if you can read the source code from a major commercial project on the day it is released, it still conceals more than it reveals.

Videogame development is an iterative process. What order the features are added is an important part of understanding how a game came together. What did the earlier versions look like during development? What was tried but not kept, or planned and initially accounted for within the code or other design decisions but cut before tried?

Transient business and human elements can have lasting effects. Was part of the code rushed in for a public demo, or faked as smoke and mirrors to win over a budget increase from an internal exec, then left that way because it worked well enough? Is something implemented twice or two different ways because office politics kept two programmers from communicating with each other, or one person moved on mid-project and another came in unsure of how to use the existing functionality? Just as rings on a tree trunk tell bits of the history it lived through, the code for a game is similarly scarred.


Read "Drought" as "Public Demo"


Near the end of the project, people often get stressed out over stretching out the last of the money, morale, and time - first by sneaking in a few polish details that couldn't make it in if done "properly", and later by applying band-aid hacks to sidestep bugs that couldn't be tracked down. In other words, even if a codebase is kept relatively robust and clean during most of development, during the final stretch it usually gets a layer of garbage crusted onto it during the final changes.

There is, then, at least one big lesson that can be learned from all of these open source projects: if you're setting out to program something that has never been made before (as opposed to re-implementing someone else's game), your source code is going to be a bit of a mess by the time the game is finished. You're firing a machine gun of code at a rapidly moving target that's constantly changing directions. There are things that are only possible, given the unavoidable limits on time, resources, and sanity, when love for the code that the developers see is set aside for greater love for what the players will see.

There are plenty of programmers that see a finished game's source code and say, "I could have done better," then return quietly to doing nothing at all. This of course misses the point entirely, like a house painter that criticizes Picasso for inefficient use of paint or lack of consistent color fill.

Someone looking to do a community mod of an existing game may very well find a game's source valuable; but for someone looking to learn videogame programming, studying a completed game's source code is less likely to be the goldmine imagined, and more likely to be a quagmire.

III.) Intermediate - $0 Flash Development Part 2: Flash Game Core Tutorial


Last month, a brief introduction was given for using MXMLC to compile ActionScript 3 Flash games for free at the command-line. For this month, I prepared Part 2, which goes into the basics of image display, mouse/keyboard input, sound playing, collision detection, and real-time/automatic movement.

> > Part 2: Flash Game Core Tutorial < <

In case you missed the previous edition, it's available here:
> > Part 1: Quick Intro to MXMLC < <

IV.) Advanced - Bottom-Up vs Top-Down Game Design

There are a few things that I would like to say about bottom-up design, compared to top-down design. Before I can do so, I want to make sure that we're on the same page as to how I use those terms - they mean somewhat different things to different fields, and I suspect it's likely that some readers have never yet come across these handy terms for discussion.

Top-down design starts from what a mind wants, and shapes that into something a medium can do.

Bottom-up design starts from what a medium can do, and shapes that into something a mind wants.

For example, a top-down art process might begin by thinking, "I want to create an image of Napoleon, in a way that conveys great intensity - this concept is worth attempting and sharing." The artist would then create the most complete or faithful realization of that idea possible, using whatever tools and format the artist is most proficient in (might be charcoal, oil paint, or 3D Studio Max). The goal is to realize an idea, and if it can be made less evident that this is done by oil paint applied to canvas, by making its focal point what it is showing instead of method by which it is shown, that is desirable in this case.



Napoleon crosses the Alps by Jacques-Louis David
Emotive representation of an existing concept of interest
Examples: Call of Duty Modern Warfare, Madden NFL,
NinjaDreams



A bottom-up art process, by contrast, might begin by thinking, "The texture and shine of oil paint on canvas produce a very particular effect - I will find a subject that emphasizes the beauty of this effect." The artist would then seek a technique and subject particularly well suited to make the most of what effect the artist's tool and format convey. The resulting work is as much or more about the paint and canvas itself as it is about the subject matter; the grain and texture take part in the creative process, somewhat like a sculptor carving stone in a way that not only considers existing fracture lines, but perhaps even calls attention to them.



Impression, Sunrise by Claude Monet
Concept inspired by or chosen partly by its form of representation
Examples: Mario Bros, Pac-Man, Asteroids, Yars' Revenge, RoboDefuser



Naturally, there is a continuum, or smooth gradient, between these ideals. It is not as simple as being one or the other. By virtue of being represented through a medium, the work will necessarily account for constraints and affordances of how it is made; likewise, by being the work of a human being, it inevitably will come into contact with how the human mind conceives of reality. There is a significant difference, however, in whether the work starts mostly as a chosen idea or mostly through exploratory execution, and that difference is generally evident in the end result.

As a rough test: if a description of the project sounds normal to someone that doesn't play videogames (or, in our ongoing analogy, study art), then it is probably top-down. The more eccentric, absurd, and arbitrary the description of what the player does (or what a painting is "about"), the further it probably is toward the bottom-up side of the spectrum.

For example, Bubble Bobble is a game where two dragons trap toys, witches, and drunks in bubbles to pop them then eat the fruits, vegetables, and candies that fly out, though if they take too long then the ghost monster chases them until they either die or kill the last enemy - that's bottom-up, because the game mechanics clearly were not invented to support that haphazard concept, but the other way around. Likewise for Super Mario Bros, Joust, or Breakout. It's not primarily about wish fulfillment, like being a superhero that fights crime or a soldier that wins the war for freedom - it's first and foremost about how what's going on is going on, the what being secondary and subservient to the how. The texture of the "paint" (software) and "canvas" (hardware) are central to what these videogames are, and celebrated instead of hidden.

The continuum extends farther off in both directions, too. Miles below my previous example of bottom-up, but in that same direction, an artist might think, "The texture and shine of oil paint produce a very particular effect - I will explore this effect," thus abandoning subject altogether.



Shimmering Substance by Jackson Pollock
It is itself, not a representation of some other idea
Examples: Qix, Peggle, Bejeweled, Tetris, Tumult



When the Wii came out, developers began asking, "What sort of interesting things can we do with this Wii Remote?" That was bottom-up design. When people began thinking in terms of designing games for iPhone that used multi-touch, gravity data, saved photos, or GPS, that was also bottom-up. The first racing games were made partly because racing is cool, but mostly because that was one of the few things videogame machines at the time could represent. Likewise for space-based shooting action - an all black background with no buildings or flora to collide with was the sort of thing primitive devices could represent.

That Pong is a crude representation of "tennis" instead of football or baseball was not a matter of its designer being a tennis player, nor was it being designed to satisfy tennis fans.

Racing the Beam by Ian Bogost and Nick Montfort provides a brief history of how the Atari 2600 hardware limitations influenced (and in many cases inspired) the games designed on the platform. Yars' Revenge was co-designed by Howard Scott Warshaw and what-an-Atari-2600-can-do.

By contrast, when the PS3 came out, developers felt less constrained than ever in terms of computation, and began dreaming about how they might share new stories (Heavy Rain, Metal Gear Solid 4), fantasy characters and settings (Batman Arcane Asylum, Final Fantasy sequels), and appealing concept pitches (make your own physics game in Little Big Planet). That's top-down.

When a modern videogame is about tennis, racing, or space combat, it is no longer because that's one of the few physical metaphors that a computer can process and display in real-time.

Even though many modern games now have the luxurious option of more faithfully representing top-down concepts, and even though bottom-up has largely taken place at the dawn of platforms utilizing innovative controls and graphics (vector to raster was as huge a shift as 2D to 3D), there is nothing ancient, unsuitable, or undesirable about bottom-up design. Part of why I opted to show paintings above is that the Napoleon is from 1800, Impression is from 1872, as Shimmering is from 1946 - that is, it took a lot of time, genius, and creativity for humankind to reach the sort of bottom-up, format-inspired thinking that the earliest videogames employed.

An inexperienced game designer, yet unfamiliar with the grain of the machine - what impressive things it can very easily do well, what somewhat less impressive things it can hardly handle, what the user's relationship is like to the experience through the set of controls provided - most often thinks mainly in terms of top-down design. We're all familiar enough with films and storytelling to think about what happens, where, and to whom in a story, but the typical level of procedural synthesis is that which only knows what it likes when it has tried it, and will thus "borrow" a mountain of assumptions about gameplay and interaction from another game. A certain sort of confidence and understanding of the technology available is necessary for bottom-up design to even be an option.

On this note: to build a clone or derivative of another game, either completely or in terms of core gameplay, is top-down. The elevator pitch for Goldeneye 007 on Nintendo 64 fits in this category. To paraphrase: "It's like Virtua Cop - enemies react to where they are shot, and the gun can move freely about the screen - except not on rails, and it takes place in the James Bond universe with the player completing missions as James Bond." Making a videogame version of Monopoly or soccer is top-down, of course, but so is making a game "like Super Mario Bros" or "like Tetris", even if the original game's roots were bottom-up design - no less than "resembling Napoleon" is rooted in the complete concept of Napoleon that existed before and outside of Jacques-Louis David's painting.

An important thing to bear in mind about top-down design is that, despite the remarkable hardware advances of the past several decades, we are still a long, long way from being able to take a purely top-down approach to videogame design. Façade is the closest thing that we have to The Great Gatsby - or maybe The Sims or Second Life are no further, coming towards it from different angles.



Façade by Procedural Arts
It gets awwwkkkkwwaarrddd.



Even though PS3 and modern computers give a lot flexibility to think in terms of, "Imagine a world, in the distant future, where..." there's still a few qualifying sentences implied after that: "In this magical place, all characters will repeat the same things if spoken to multiple times, they'll have a small set of awkward poses they can switch between to convey expression, and the player will speak by choosing statements from a list of 3-4 pre-written statements. There are only a few things that can be done to interact with the relatively small percentage of the world that can be interacted with, and the solutions to challenges will either be those that we explicitly planned, or possibly some slight variation by clumsily moving objects around in the game's exaggerated physics..."



Half-Life 2 by Valve

We were quite excited in 2004 when there was 1 room in a game where it mattered that objects have weight. The gravity gun and physics gameplay were bottom-up design within an otherwise top-down world.



Top-down is unlikely to free us from limitations, because by its nature it echoes better than it speaks, it adopts the additional constraints that shaped previous gaming and story conventions much more naturally than it pushes the boundaries to test where they end.

Innovation - particularly the surprising, unintuitive innovations that no one could have seen coming - tend to come from bottom-up. It is no coincidence that the genrification of the industry, the attack of the clones, has coincided with the increase in hardware power inviting more top-down design, while those pockets of gaming that see the most aggressive innovation - indie games, mobile games, experimental games, and little web games - tend to be bottom-up (at least, those that don't rely heavily on appeal to retro/nostalgia fandom).

The imagination - the source of top-down - copies but personalizes, mixes and matches what it has already experienced, or even when it thinks it is finally being clever and original, has been swept up by the zeitgeist of whatever recent films, best sellers, and news stories have everyone thinking about. There is, of course, a market for this; people like what's recognizable, and people like getting what they're looking for. But as the top-down market is predominantly derivative, from a creative standpoint it's more like being a translator than like being a writer. For the craftsmen and artists among us, it is not our desired line of work to make variations on other people's work.

With bottom-up the constraints, limitations, and natural texture or grain of a medium push into existence results that are not entirely of human origin. The medium becomes a co-creator, an inanimate but unyielding creative partner, arguing for or against ideas thrown its way by what it will and won't agree to do.

A top-down development team strives to create as perfect a realization of their concept as their available platform technology and skill strengths can support. The hidden member of their team is the work that has been done before them, by bottom-up pioneers, and they benefit from the market's feedback on past products.

A bottom-up development team strives to discover as perfect a concept for the platform technology and skill strengths that they have or can learn. The hidden member of their team is the technology itself, and though they don't have the same benefit of borrowing from the past, everyone benefits when they help create the future.


V.) Special Topic - Reader Questions About Chris Crawford


Chris Hendrickson, founder of the Ithaca College Game Developers Club, recently sent me a couple of questions about my work, and my perspectives on game industry legend Chris Crawford:

Q1) You've referenced Chris Crawford a few times in your newsletters; when in your development as a game designer did his approach inform your own process? How do you think your own approach to game design is influenced by the 'grand-daddy of game design'? I've noticed that both of you draw from separate yet integrated perspectives in talking about and designing games; not limited to visual arts, business, literature, history, as systems, programming, and psychology.

Chris Crawford's games were slightly before my time as a videogame player - or if there was any overlap, his projects were for PC when I only knew console/NES - and I first found out about his work through Ian Bogost's 2006 book
Unit Operations: An Approach to Videogame Criticism. I found the e-text of Crawford's book sometime over the next year. More was said (I think) in Bogost's 2007 book Persuasive Games. During my InteractionArtist micro-projects is when I found the 1992 GDC (then the CGDC) "Dragon Speech", which very much struck a chord with the spirit of what I was up to at the time.

I think the main influence was in reading about one of the game over states for Balance of Power, a game where the player is tasked with managing international affairs during the Cold War era. For context, this was not a historical game, it was relevant to present day - it was released in 1985, and the Soviet Union didn't collapse until 1991. If the player's decisions lead to nuclear war, the game displays this message: "You have ignited a nuclear war. And no, there is no animated display of a mushroom cloud with parts of bodies flying through the air. We do not reward failure."



Balance of Power by Chris Crawford



This runs contrary to so many things that we're used to seeing in modern videogame design - were this a modern videogame, the player would expect options to win by raw military might, as an alternative to diplomacy. This "you can be good or evil" idea entered mainstream videogames between 2001 and 2004, with the release of games like Black & White, Star Wars: Knights of the Old Republic, and Fable, although it has a longer history in RTS (in Command & Conquer, being able to play as the Nod terrorists instead of the GDI peacekeeping forces) and indirectly (from my limited understanding of pen and paper games) through the traditions of Dungeons and Dragons. It was heralded as a breakthrough in game design for increasing player choice, but silently brought with it a muting of the developer's authorial statement.

This videogame asserted itself. Its author - not "developer", but "author" - asserted himself. The breakout of worldwide violence, according to this videogame and its maker, is not a viable alternative to diplomatic stability. Shocking.

If a user has and acts on childish (or worse: mannish) tendencies, it does not accept those as appropriate ways to address the situation, and it would not offer even a visceral reward, let alone unlock additional gameplay challenges for that behavior. In so many words: everyone dies, there's no way to win thermonuclear war, this course of action is intolerable.

Crawford explains that he sees his objective as a videogame designer to communicate principles. This is, of course, profoundly different than the modern conception of videogame design which is merely to entertain, or to offer something to play with for its own sake.

Here's a short video on SCRAM (a computer "game" about basic nuclear reactor dynamics):



A longer and more inspiring video, parts of which have Crawford talking about Excalibur:


Screenshots of Excalibur for Atari 800, a game by Chris Crawford, Larry Summers, and Valerie Atkinson:


This videogame was made in 1983. To say that it was ambitious and ahead of its time is an understatement. For more on Excalibur, check out Chapter 8 from the e-text of his book, The Art of Computer Game Design.

Q2) Crawford was around since the beginning of modern computer gaming, but a lot has changed since then. The discourse in his books was much less focused on new technology or industry trends as much as individual game development issues based in more traditional, 2D computer games. Many of the popular games emerging from companies and individuals right now have complex problems that need to be addressed. How relevant do you believe Crawford's perspectives are to the next generation of game designers who are trying to create solutions for game design issues?

You are correct that Crawford's writing, unlike the majority of writing about videogame development since, was not focused on new technology or industry trends (except, to say, that at the time of his writing, videogames were a new technology, and a trend of sorts).

Very little of his writing has anything to do with traditional computer games in particular though. It's often just as relevant for developing or discussing something like StarCraft 2 or Just Cause 2.

"Illusion of winnability", "smooth learning curves", "triangularity"/"asymmetric games", "actors and indirect relationships", "pace", "limited information", and "balancing solitaire games" (that's 1985 for "single player" - not the card game) are still relevant. Those are the headings from Chapter 6: Design Techniques and Ideals from Crawford's book.

Or, consider Chapter 2: Why Do People Play Games? I think that Crawford's list of Fantasy/Exploration, Nose-Thumbing (overcoming social restrictions), Proving Oneself, Social Lubrication, Exercise, Need for Acknowledgment, and Sensory Gratification still pretty well sum it up, or at the very least provide an impressively modern starting point. There are grad students, GDC speakers, and industry developers running about thinking that they're making breakthroughs when they realize that videogames can be made for social lubrication or exercise. I know of at least one research paper from a few years ago that seemed to think it revolutionary that videogames might appeal to either Fantasy or to Proving Oneself; Crawford covered that before I was born.

There is an error in the statement, "Many of the popular games emerging from companies and individuals right now have complex problems that need to be addressed."

They don't.

And I mean that both in suggesting that the popular games don't have complex problems, and that which problems they do have in most cases don't need to be addressed. With precious few exceptions, developers have given up on the really complex problems, in favor of working on a number of problems that don't need to be addressed. This is a big part of what fueled Crawford's epic Dragon Speech, and part of what led to my going mad with the InteractionArtist series.

Getting a computer to process algorithms and crunch math for graphics and physics isn't a hard problem (that's what computers do), nor is getting humans to interact with one another a particularly hard problem (that's what humans do). To modernize the case further: nor is getting compulsive people addicted to meaningless things a particularly hard problem (that's, unfortunately, what compulsive people do). Show me something instead that helps compulsive people not develop harmful addiction to shallow, meaningless things, and then I'll be impressed.



To be fair, I'm not sure whether making something this addictive was a complex problem. Maybe it was.
I am, however, sure that lack of addictiveness was not a problem worthy of being addressed.



By comparison, understanding how complex meaning is conveyed experientially from computer output to human user is a nut we still haven't cracked, and it's a challenge that encompasses the intersection of so many different fields (to borrow your list: "visual arts, business, literature, history, systems, programming, and psychology") that most specialists feel that it isn't their problem to worry about or take on, and that even if it was somehow thrust upon them, they wouldn't have the right preparation to tackle it.

To return to the question:

> How relevant do you believe Crawford's perspectives are to the next generation of game designers who are trying to create solutions for game design issues?

Ignorance of Crawford's perspectives - which are free online free for all the world - will result in a massive amount of lost time from redundant work, and it already has. Bright, well-connected people burning time discovering and struggling to communicate what he already figured out and articulated very clearly is time wasted that wasn't invested in investigating something that we didn't already know.

If we focus on "game design issues" in the modern sense of extreme specialization - people that tune RTS units, build 3D levels, script in-game objectives and manage spreadsheet tweaks for FarmVille - I'm not sure that Crawford's work will be of much use to people in those roles.

If, instead, we consider Game Designer as Crawford used the title, as it meant in Crawford's day, like an odd variety of writer that sets out to convey meaning through a different sort of solo composition, one that considers all aspects and assumptions about the videogame malleable (pre-specialization, no part was someone else's job), then I would love to see more actual Game Designers. Chris Crawford's perspectives can play an important part in that happening.


VI.) Call for Your Games - Free Publicity for You


With the generous help of reader Ryan Burrell, GameDevLessons is getting a total redesign! (Preview)

A new "Games" section of the site will include a section for links to finished games made by GameDevLessons readers like you. Whether you're a subscriber, or first time reader, you're eligible to share your work with other readers. It's ok if the game is small, campy, or a learning project, just as long as it's of your own creation (or as part of a small team) and it's finished.

To keep this simple, here's all that I need:

  • A link to download the game or to play it online

  • Which operating system it's for (PC, Mac, Linux, Web/All)

  • Description (a sentence is fine; please, no longer than 2 paragraphs)

E-mail the above to chris@gamedevlessons.com.

I will get the following from your link or game, though you can provide these if you'd like:

  • The title of your game

  • Your name, brand name, or preferred internet alias

  • A screenshot in jpg, cut to 550x250 dimensions

I'll try to include as many submissions as I can, although I may not be able to include all games sent in. Experimental, educational, and serious games entries are just as welcome as more conventional game styles. Although teen appropriate content is preferred, all games will be considered.

Examples of games made by readers that I'll be listing:



Space Ship Defender by Eric Wright
Free - click to play online now




12-25 The Game by Otávio Good
Free - click to play online now




VII.) Donations


I have never put this content behind a pay wall. I want to keep it accessible to everyone, regardless of age and income level.

If you find the value of these monthly editions - all 14 now and counting, containing over 200 pages including the free e-book - at least worth buying me a nice lunch ($6.79?), your donation really does make a difference. Especially to my morale. The marketplace is not set up to reward indiscriminately giving away time and experience in an effort to help strangers :)

PayPal makes the transaction fast and safe. You don't even need to have a PayPal account, as long as you have a credit card. Help me help others. Please take a moment to:




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/letter14.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