[Edit] Since so many have people have brought it up: I never advocate to write engines instead of games, but rather that there are virtues in writing a game from scratch (for learning and hobbyist purposes, mostly).  The “smartest” route to get something out quickly, as I suggest many times, is to use a preexisting engine.

Yes, that is an inflammatory headline, but it got your attention, right? Before you get violently philosophical, let me elaborate.

Many people argue that you should almost never write an engine from scratch, but rather just use what is out there already.  I disagree (sort of). For the sake of brevity, let’s distinguish the two routes:

• Route A: Use an existing engine.
• Route B: Roll your own engine.

If things like:

• “safety”
• “speed of implementation”
• “quarterly revenues”
• “personal hygiene”
• “eight hours of sleep”
• “feeding your children”
• “sanity”

are all priorities for you, go with Route A…Nancy.

On the other hand, if you are the type of person that:

• hates reading instruction manuals
• likes pushing hardware to its limit / voiding warranties / small fires
• resorts to violence instead of debugger sessions
• smells like an alcoholic lumberjack
• fights honey badgers for scraps of meat

then you should probably go with Route B.

But seriously, why might you want to write your own game engine? Are you stupid? Are these people stupid?

• Markus “Notch” Persson
• John “I Hate The Color Spectrum” Carmack ( I kid, I kid…but it’s not like I’m the first person to crack such a joke ;) )
• Timothy “Not CliffyB” Sweeney
• Richard “Lord British” Garriott
• Ken “Kick Ass and Chew Bubblegum” Silverman
• Eric “Out of This World” Chahi

The answers are: “no” and “no.”  Well, “no” to the latter question, at least.  They (among many others) all wrote their own game engines at some point, and many of them still do (or at least oversee the creation of new engines).  It might seem the polar opposite – some of the smartest people we know in the game industry write their own engines.

First and foremost (and this is just my theory) – people that write their own engines do it because they enjoy it.  Or they are clinically insane, but it’s a thin line, right?

Does this make you somehow inferior if you use a preexisting engine? No; if you fall in that camp, you are probably the more rational of the two.  Some people are able to do amazing things with preexisting engines.

An analogy, if you will: you can customize, upgrade, and otherwise enjoy your car without being an auto mechanic.

Are there more concrete reasons you might want to roll your own engine? I think so.  Here are a few:

• You may develop an understanding of game engines, computer hardware, and advanced algorithms by only using preexisting engines.  But your understanding will quite likely be dwarfed by anyone who has put serious effort into building their own engine (given equal experience).  If you have built your own engine(s), you will likely be able to better utilize and hack preexisting engines.
• You have full control over your own engine, and full understanding of its inner workings.  Changing any detail is relatively trivial – in a prebuilt engine (especially without access to source) sometimes the most trivial details can be a nightmare to change.
• Many preexisting engines are bloated.  If you are writing a simpler game, sometimes it’s like using a sledgehammer as a flyswatter.
• Your game might have very unique mechanics that are difficult, impossible, or too performance-intensive to implement in a preexisting engine.
• Most preexisting engines are very good at importing assets (3D models, textures, etc).  But what if you want to generate your own assets within the engine (i.e. procedural generation/synthesis).  Many engines are ill-suited for this purpose.
• A trivial and superficial point, but nonetheless something to think about: you can stretch many preexisting engines to their limits, but you will probably will not have as much of an opportunity to create something technologically innovative.

I have started to hate the word “hacker” ever since “those” people started using it.  You know, the “I just created a webpage on notepad — LOL I’m a hacker!!” type of people (I was probably guilty of this at some point).  But let us pretend the word has not been desecrated.  The “famous” hacker guide states:

• The world is full of fascinating problems waiting to be solved.
• No problem should ever have to be solved twice.
• Boredom and drudgery are evil.
• Freedom is good.
• Attitude is no substitute for competence.

I think “hacker” is a just a fancy word for “pioneer.”  They like exploring new areas, and hate covering mapped ground.  It might not be the most rational or profitable course, but “real” hackers are more about having fun then churning out a few extra bucks.  If you roll your own engines, you might not be a hacker, but you are probably on the right path.  Grasshopper.

You might argue that times have changed, and it is no longer feasible to roll out your own engine and meet audience expectations.  If you are a AAA company, this is probably the case, but if you are an independent developer, ugly and lo-fi are hip.  Hardware has changed, nothing else.  You can still write games and pretend like you are living in the days of shareware, 3.5 inch floppies, and BBSs.

You might also argue that if a hacker is someone who hates reinventing the wheel, why would they create their own engine when much of the work has been done for them elsewhere?  The answer to that depends on the purpose of the engine.  If you are simply building your own copy of the Unreal engine, you are not doing anything new, and there is no point to writing your own (other than perhaps learning, and the ability to easily modify and open-source it).  If you are writing your own engine, hopefully its because you want to try things that other engines cannot do (or cannot accomplish with the same level of performance).

All of that aside, there are more fundamental reasons for creating engines.  In a healthy software ecosystem, there are options.  Not everybody wants (or can afford) the latest AAA engine – some times people want simpler, smaller, and cheaper (or free / open source) alternatives.  Somebody needs to create these engines, they are not formed in a vacuum.

So what are the drawbacks (aside from the obvious ones)? Your first engine will probably be a failure.  A messy, flaming failure.  So will your second, and third.  But at some point, you will probably get the hang of it.  If you want to learn, keep scrapping.  If you want to actually get a game out the door, suck it up and stick with your current engine, or use an existing one.  Most importantly, if you want to build a game, do not get caught up building an engine.  Do the bare minimum to get the game out, do not obsess about adding features to your engine.

[Edit] As Richard Fine pointed out in the comments below, it can be kind of fruitless for a newcomer to write their own engine when they have no idea of the complexity or scope of what it takes to make a solid engine.  I think there is truth to this – you might be able to learn a bit faster by learning how to use other engines first and getting an idea of how they function.  Nothing wrong with that, really.  Alternatively, you can get your hands dirty and learn the hard way – it is possible you will come out with a different (not necessarily better or worse) understanding of game engines.

Am I biased? Absolutely. But I am also speaking as someone who has tried many preexisting engines (UDK, Unity, Torque, and a few others), and I have been writing my own engines for over a decade.  If rolling out your own engine is such a bad thing, you might think that at this point I would have learned not to do it?

“Future” is the key word here. Without an unexpected jump in technology, we probably will not see mainstream use of ray tracing this decade.

Click here to see the WebGL demo above.

In an (often-cited) interview, John Carmack once said “Head to head rasterization is just a vastly more efficient use of whatever transistors you have available. [In comparison to ray tracing]”

I think he is absolutely right. However, rasterization cannot be parallelized nearly as effectively as ray tracing, mostly due to the way depth sorting works. Without some insanely complex memory architecture, rasterization is forced to work triangle-by-triangle on any given buffer, because it must know whether a triangle is above or below any other triangle. In theory, you could parallelize it by comparing multiple triangles at any given time, but then you are tending towards ray tracing and giving up what makes rasterization so efficient (the same goes for order-independent buffers). You could also render to several buffers and then combine them, but that is probably not the best use of memory, and it would take considerable bandwidth to combine a significant number of buffers. Ray tracing, on the other hand, inherently works on a per-pixel basis. It does not matter what order the pixels are rendered in, and the results of any pixel are completely independent of the results of another pixel.

When it comes down to the number of instructions executed, ray tracing is probably grows by a linear magnitude of complexity in comparison to rasterization, without optimization or ray-bounces. However, I think with the proper underlying hardware, this complexity could be catered to with a growth in compute units. As hardware tends towards an increasing amount of cores, the case for ray tracing will likely become stronger.

There are many more things to consider though.

First of all, I think that ray tracing with triangles is not an effective use of ray tracing, as Carmack suggests. I also think that sparse voxel octrees are not necessarily the answer. The problem with triangles is that they begin to lose their value as they approach the size of a pixel (which they already are in many cases). The problem with sparse voxel octrees is that they are not efficient for storing curved or noisy surfaces. Both solutions are limited by the resolution of the underlying data, even with tessellation or super-sampling.

The main advantage of ray tracing, as I see it, is the ability to define arbitrary types of primitives or even extremely complex mathematical structures. As far as smooth surfaces go, I think the most efficient method of ray tracing might be to use a form of isosurfaces, that is, surfaces that are equidistant from a given set of points, lines, or other primitives (or even modified for varying distances) — not to be confused with metaballs. In combination with texture or parameter-based displacement-mapping, I think you might be able to achieve a wide variety of surfaces. Higher order primitives are also easier to work with because they are not subject to the same anomalies that lower-order ones are, like gaps, (counter)clockwise errors, and bad normals. Also, unlike triangles, higher-order primitives are not subject to strange interpolations like collections of triangles are, which can result in odd texture coordinates or lighting.

Defining things in a mathematical manner is the basis of procedural generation – it allows you to reduce file sizes and produce dynamic geometry that can vary with different parameters. Obviously, there is a ton of work to be done before such assets could compete with hand-crafted ones, and the tools are simply not there for producing ray-traceable objects based on various primitives. That said, triangles are very poorly suited for procedural generation, whereas isosurfaces are very well suited. The problem comes down to how simple it is to describe an object in mathematical terms – isosurfaces implicitly describe their own structure by simpler underlying primitives like lines or curves, whereas the entire surface must be explicitly defined when using triangles, in addition to the points of every triangle and how they connect.

Ray tracing has other advantages, obviously. The quality of reflections, refractions, shadows, and radiosity simply cannot be reproduced efficiently (or at all) with rasterization. Ray tracing can also produce solid objects and use boolean operations, which could have interesting effects (for scene cut-aways, object destruction, etc). Ray tracing also does not (inherently) support anti-aliasing or multi-sampling, because at a given point a ray either intersects or it does not – there is no partial intersection. From a programmer’s perspective, I think this is a good thing because it keeps pixels “pure” and prevents data loss – many post processing techniques do not work in conjunction with MSAA or require hacks. MSAA can always be applied as a post-process technique where needed.

I think at some point in time the loss in performance for ray-tracing will become small enough and the tools for it good enough that it will shift into mainstream use. This is not to say rasterization will (or should) ever be dismissed – I am sure there will always be uses for it, and hybrid approaches will likely be common. Most importantly, realtime ray tracing is still a very young area of study. We have had over a decade to produce all sorts of cool tricks with GPU rasterization, I am sure there are many similar hacks we could produce for ray tracing. I think that we also find many ways to effectively “fake” results and gain a lot of speed at the loss of a little accuracy (in particular, there may be efficient ways for summing up the propagation of light at any given point, although I am sure this is no small task). Regardless, we should not hesitate to experiment in this area on the basis of rasterization’s dominance – at the very least, offline rendering (for film and other applications) could greatly benefit.

I like to program “close to the metal.” It gives me a feeling of control, even if the compiler is actually completely rewiring my code. I like C and C++ because they do not try to hide much from the programmer – they are very basic imperative languages. That said, there are many, many things I hate about them.

For a long time, Java struck me as a somewhat mediocre language. Its performance seemed a little bit weak and most people would scoff at the concept of using it for game programming.

More recent versions of the JVM actually have great performance. It can be difficult to organize an effective benchmark (see: http://en.wikipedia.org/wiki/Java_performance), but some tests suggest that Java can actually exceed the speed of C/C++ in certain cases. This is due in part to the fact that Java has more constraints in some areas (i.e. pointers), and that it can be optimized more effectively based on this. Java can also optimize itself with JIT compilation, and optimize between successive runs. That said, you definitely should not choose Java on the basis of performance alone.

I once heard something that has stuck in my mind ever since: “servers are cheap, programmers are expensive.” In other words, you have to carefully choose your battles: at what point is optimization worth a programmer’s sanity? Java might not be the fastest language, but it will keep you slightly more sane than C/C++, and is usually worth the slight performance penalty.

But what is really important is that the loss of performance can be a good thing. When you stop focusing on performance, and start focusing more on your game, a new world of opportunity opens up. I hate to always bring it up in examples, but take a look at Minecraft: simple graphics, but it runs on a variety of hardware and operating systems. Java programs have better potential for a long lifespan – this might not seem too important, but try launching an old DOS game these days — can be quite tricky sometimes, even with an emulator.

Java is also cross-platform — this makes porting really painless. You can also run Java in the browser as an applet or via a quick-launcher. Managing “imports” and “packages” is much easier than dealing with “#include” statements in large projects. You can also easily get a free IDE up and running quickly: Eclipse (for C/C++, last I checked, setting up the compiler could be tricky on Windows, which does not include a compiler by default like gcc on Mac/Linux). C# actually is quite good in many ways as well, but unfortunately its open source counterpart (Mono) leaves it trailing a little bit behind on operating systems other than Windows.

I am no expert on how well Java interfaces with DLLs and what the performance penalty is for accessing the GPU from Java. I also do not recall how Java handles passing resources to the GPU, which are usually passed via pointers. But it is fast enough to generate simplistic graphics at the very least (see: JOGL, JMonkey Engine, LWJGL, etc). While WebGL and Javascript can do the same, Javascript is not quite at the performance level of Java (even with V8 and the like), and as a language it is not the best designed for taking on larger projects.

Clojure is another language you might want to examine. It is a relatively new functional language that compiles to the JVM, and is a LISP dialect. It imposes certain restrictions (i.e. state-based immutable data) to make multithreading as simple and painless as possible. As the number of cores on a CPU increase, I could see Clojure being a real contender, although I am still slightly skeptical of its performance in some areas.

TL;DR: sacrificing performance can be a hard pill to swallow – but it is also very liberating to not worry about it so much and focus on making something simple and easy to code.

Let us start with DirectX. I remember programming on DirectX when it was still a fixed-function pipeline, and I thought it was a brilliant move when programmable shaders were introduced, or at least when they matured a bit in shader model 3.0c. Obviously, this was not solely Microsoft’s innovation, but a joint (even if not directly cooperative) effort between MS, the Khronos Group, and various hardware manufacturers. That was August, 2004.

Fast forward 7 years later. Most titles are still shipping based on DirectX 9.0c code or the OpenGL equivalent (except in mobile applications, obviously). Why? Because its still the lowest reasonable common denominator, especially with the number of consoles that support this hardware level.

To be honest, DirectX 9.0c is not that bad, but it is 7 years old. The real problem is the mess of APIs Microsoft has introduced since 2004.

DirectX 10 introduced geometry shaders, new texture formats, and slight performance improvements in some areas, but required new hardware over 9.0c cards. Geometry shaders (at least from what I have perceived) were poorly received by developers. 10.1 introduced more texture formats, blend modes, and enhanced MSAA support, but required a new set of hardware over 10.0 cards. DirectX 11 introduced tessellation (which some people viewed as “geometry shaders, but done right”), native multi-threading support, and DirectCompute (similar to CUDA/OpenCL). I have done a lot of experimentation with tessellation (see pic below), and while it is a very cool feature, I have to say the hardware is not quite there yet in terms of justifying the performance gains. Also, the documentation is horrible at best – at the time I programmed with it, there was literally no documentation that properly explained the functionality of each tessellation pipeline. DirectX 11 is not a bad product overall, but the timing of its release was absolutely horrible.

A quick and dirty screen-space displacement mapping / tessellation demo I worked on

Since DirectX 9.0c, 3 new levels of hardware have been required for each subsequent version (10.0, 10.1, and 11.0). Over a span of 7 years, that would be a rough average of 2.3 years per hardware cycle. It takes more time than that to create a single AAA title! But the absolute worst part of it all are the consoles of 2005 to present. Don’t get me wrong, they are all great consoles, but they all obliterated the practicality of programming for 10.0 and above hardware.

Rightfully so, consumers have become jaded about purchasing new graphics hardware, because so far the payoff has been increasingly slim.  Microsoft did not give DirectX 9 enough time to mature; 10, 10.1, and 11 only constitute the beginnings of a significant new version IMHO – I felt like they were rushed out the door to promote Vista and Windows 7, respectively.  The lack of drive to develop on these new APIs has sent out the wrong message to every party – that we don’t care about advancing technology and might as well continue catering to the old APIs.  Instead of a console refresh, we have Kinect (I actually think the product is great for certain applications, but I hope MS is developing a new console relatively soon as well).

In reality, there are many parties responsible, but I would argue Microsoft has the most influence in the world when it comes to determining graphics APIs, given they have the most popular operating systems and a remarkably popular console. Indeed, it would appear that the past releases of OpenGL have simply followed in the wake of DirectX features. Microsoft should have held off on a new version of DirectX until the next console generation – I hope they have learned this lesson.

But it does not stop at DirectX. XNA studio seems to be exacerbating the problem of hardware/platform fragmentation. In a rather questionable move, the most recent release of XNA (4.0) has been dumbed down to support Windows 7 Phones, although they allow you to override this by targeting different releases (i.e. “performance” and “reach”) – but this fragmentation leads to confusion and inability to target all platforms with a decent level of hardware. XNA also has a few strange limitations on PC because it is forced to support Xbox hardware. Windows 7 phones also only support very limited shaders, not even 9.0c level – almost fixed-function-like.

So, I am going to ask it once: one API, one level of hardware to worry about please, Microsoft. If this means abandoning backwards compatibility with older hardware, so be it. Just make sure you only do it once every five years or so, and give the hardware and platform time to mature.

While I am complaining, allow me to bring up your various GUI technologies. Silverlight, WPF, Windows Forms, and now with Windows 8: HTML 5 – yet no support for WebGL. What in the world is going on over there? It’s almost as if you have 20 different people independently making executive-level decisions. And why is it still so hard to get a decent GUI inside a DirectX/XNA application? One ring to rule them all, that is all I ask.

I think that our problems run deeper than the APIs though.  Current graphics hardware is still, in many ways, tied to its fixed-function past.  It does not resemble the design of CPUs, which try to minimize instruction sets and maximize flexibility.  I do not doubt that GPUs will continue to dominate in graphics performance, but I think there is a viable market for less powerful, more flexible, easier to work with hardware.  Intel tried to enter this arena once before with Larabee, and although they were not initially successful I still see a bright future here, perhaps one aided by their new 3D transistor technology.  I think that as you lower the barrier to becoming a competent graphics programmer, you see an influx of new developers and products into the market.  I cannot count how many times I wanted to give up learning on account of the difficulty in working with modern graphics hardware and APIs.

If you want to really amaze me, Microsoft, start working with your hardware partners to get a CPU-based graphics solution in place with competitive performance. I think the intricacies of GPU hardware are annoying. I understand from a performance standpoint how they are justified, but at what point are performance gains worth a programmer’s sanity? I hate having to deal with a million different texture formats. What would be ideal is to simply output to a variable number of channels, say 0-64 channels, each 32-bit floating point, rather than juggling a number of textures, each with different bits per channel, number of channels, etc. Yes, it might very well consume a lot more bandwidth, but I think overall it is a more optimal solution – if you look at most CPU’s, they do not have special registers to store and calculate bytes – rather they convert bytes to 32-bit integers and then perform calculations on them. Even if performance is worse, it is easier for a programmer rather than trying to carefully decide how to pack information into channels between several textures. Obviously it would pay off to build a memory and caching system that would play nicely with this. It would be nice to have 16 GB of memory at my disposal, instead of the standard 0.5-1.0 gigabyte in a given graphics card, perhaps optimized to be divided among each thread or core. Most importantly, it would be amazing to to eliminate the CPU/GPU bottleneck that prevents us from doing a lot of meaningful interactions between the two. Also, for the love of all that is holy, make the depth buffer easily readable. Or better yet, get rid of the fixed-function buffer and replace it with something programmable. I think that it might even be possible to do away with features like MSAA, especially with the increased interest in ray-tracing and post-process rendering, for the sake of speed and simplicity in designing new chips. Keep the APIs as low level as possible – people writing the middleware will worry about the rest.

I would love to see a return to the “good old days” when people like Carmack and Silverman could write their own engines from the ground up – things of real technical beauty – instead of dancing around the awkward limitations of graphics hardware and APIs.

Roughly 90 out of 2,400 PC games reviewed on Metacritic scored 90 percent or above.  (Similar figures apply to other platforms.)

In other words, less than 4 percent of games have received decent universal acclaim.

(I would have to admit that having universal acclaim is not always that great, in all types of media – many of my favorite games and movies have scored in the 80 percent range, or even 70 percent.  But nonetheless, there is something telling in how many bad reviews there are.)

You might say: “well, making fun games is hard.”

Making a game is hard.  Making it fun is only a little bit of additional work.  There is a concrete science behind game design that mostly boils down to an understanding of human psychology.

But it gets even easier than cracking psychology books – just look at game reviews.  What do people like in games?  What do they dislike?

Admittedly, a large part of this problem is due to how tight deadlines are in the industry.  Once a game is functional, it gets shipped.  Too often, whether or not it is fun seems to be an afterthought.

Another part of this problem stems from the fact that a large portion of the game industry is run by people who do not know how to design games.

So, I am going to make it very easy…at the bottom of this article, I have provided some guidelines.  Follow them (at least somewhat), or fail.

Think of your favorite games ever, and why they were fun.  Here are some of mine, for example:

• Ultima 6 and 7 [highly-interactive, unconstrained, functional worlds and interesting storyline and characters, visually appealing]
• Star Control 2 [excellent storyline and dialog, huge galaxy to explore, well-executed mix of rpg/arcade/adventure, possibly the best game music ever, and great visuals] – it is now open-source, get it here.
• Dungeon Master 2 [interesting puzzles, fun character progression and strategy, nice visuals]
• Heroes of Might and Magic 2 [great strategy, appealing visuals]
• Fallout 1 and 2 [great strategy, character progression, and storyline]
• Master of Orion [great strategy]
• Orions (iPhone) [great strategy, appealing (if simplistic) visuals]
• Puzzle Quest [great strategy (sometimes)]
• Advance Wars [great strategy, fun visuals]

I’m going to add two to this list that (shamefully) I never played enough to get into, but I am pretty sure I would have enjoyed given their high acclaim:

• X-Com series [great strategy, progression]
• Civilization series [great strategy]

Raph Koster did a pretty good job of laying out what makes games fun in his book ”A Theory of Fun” — most people in the industry are familiar with this book. It has been a while since I read the book so I might not recall everything correctly, but I believe he claimed there were several different types of fun, which is not a new theory but has been present in the field psychology for a long time.  I don’t recall his exact list but I will make my own that probably has a few duplicates:

1. Logic / Strategy: the feeling of fun we get from solving puzzles, learning patterns, making complex decisions, etc.
2. Competitive: the feeling of fun we get from watching sports, trying to get a high score, or out-smart our opponents.
3. Progression: the feeling of fun we get from positive progression: beefing up our RPG character, losing weight, climbing the corporate ladder, buying new a new computer, and so forth.
4. Sandbox / Creation / Interactivity: the feeling of fun we get from building things and guiding interactions: The Sims, Minecraft, Line Rider, Legos, and even playing in a real sandbox (!) are some obvious examples but it also applies to every craft and trade: drawing art, programming, wood-working, etc.
5. Random Positive Reinforcement and Chance: the feeling of fun we get from gambling, random loot drops, and rare conditions that make for interesting interactions.
6. Visual / Audio Stimulus: the feeling of fun we get from looking at something beautiful or awe-inspiring, or listening to a great song.  Other senses apply as well, but for the sake of games I will only list these two.
7. Vicarious/Immersion/Alternate Reality/Emotional: the feeling of fun we get from immersing ourselves in a fictional world and plot – most movies and books rely on this.
8. Social Interaction: the feeling of fun we get from going out to restaurants, clubs, bars, social gatherings or interacting with people via chat/phone etc.  Believe it or not, this can be slightly satisfied by convincing AI.
9. Thrill / Adrenaline: the feeling of fun we get from sky-diving, roller-coasters, driving fast, or media in the scary/horror genre.
10. Twitch / Reflex / Agility: the feeling of fun we get from mastering hand-eye coordination, balance, and so forth.  This applies to everything from gymnastics to skateboarding to most action/arcade/FPS games and many other real-time games.

(From here out I will refer to types of fun as (1), (2), (3), and so forth, using the list above.)

Has anyone ever made a game that has executed very well on all of these elements?  I don’t think so, but let me know if anything comes to mind.  But does it matter?  I do not think so, although I would still be interested to see someone do it.

Looking over my list of games, it would appear that the majority of them depend on fun type (1): logic and strategy.  In fact, if I really had to throw away my nostalgia and pick the games that were the most fun – the ones that kept me glued to the seat and lost little replay value over time, it would have to be the games that tended to be based more on logic and strategy.  Most of these were also turn-based (not a coincidence).  Still, my favorite games of all time (Ultima 7 and Star Control 2) had little (1) but many of the other types of fun.

Just to be clear, there is no superior type of fun.  That said, if you want a higher chance of success (or at least a cult following), I would aim for at least having lots of (1) in your game, and whatever other types of fun you can afford to put in.

Types (1) and (10) can sometimes work against each other.  Why?  Strategy is based on (at least semi) predictable outcomes and full control of the input, not to mention enough time to make rational decisions.  If the player does not feel like they are in full control, or that they do not have enough time to make strategic decisions, it can work against type (1).  However, you can still have lots of strategy within a real-time game – Braid is a great example of this, or even Tetris.  Turn-based games tend to have the highest-acclaim because they give you enough time to solve hard, mind-challenging problems and are often designed with enough permutations that they do not easily grow stale.  Turn-based games also tend to have higher learning curves, and drive away many players because they do not cater to short attention spans.  Whether or not you cater to people with short attention spans or not does not really matter, there are markets for every genre.  Analogously, sometimes fast food is more appropriate than dining in a fancy restaurant.  That said, twitch games can have over-arching strategies that do not conflict with their innate qualities.

As you can see, there are many types of fun, and they can all be used in games.  But what makes a games uniquely fun?

First of all, the game MUST have a strong strategy/logic element, without this, it is just an interactive movie.  I enjoyed Mass Effect, but I enjoyed it the same way I do when I watch a science fiction movie.  I found it to be not very challenging or engaging on a strategic level.

If you want to design an interactive movie, there certainly is a market for it, but I won’t cover it in my guidelines because these types of games are generally more susceptible to criticism.

But pointing out what is fun is very different from saying how to make a game fun.  Here are a few guidelines, off the top of my head:

• IMHO, it is very important to prioritize fun types (1) through (10) as they pertain to your game, and then include as many of them as is feasible.
• Competent (experienced) players should fail at least 50 percent of the time.  Why 50 percent? Because it is “fair.”
• Incompetent (or inexperienced) players should fail almost 100 percent of the time, but rapidly ramp up their ability to succeed.  Designers tend to worry too much that they scare away players with too much challenge.  Challenge is not scary – lack of challenge is.
• Failure should be based more on failed strategy than bad luck or nearly-impossible to overcome situations.  This differentiates “fair” games from “unfair” games.
• The game should be easy to learn, but (nearly) impossible to master.
• Not just easy to learn, but as easy to learn as possible – eliminate awkward rules that don’t add much to the game.
• The game should have many permutations and varied conditions that engage the players mind in as many different ways as possible without being overwhelming.
• The rules should shift or change so that they do not get stale, but at the same time follow a common structure.  One mechanism for this can be found in card-based games like Orions or Magic the Gathering.
• Never engage the player with the same scenario.  Chess always starts out the same, but gradually shifts towards a random scenario based on player actions.
• The game should always be balanced, but not so balanced that all of the game elements are more or less equal.
• There should be a decent amount of probability involved, but not so much that it is the primary factor in the game (Texas Hold ‘Em involves too much probability, IMHO).
• Likewise, the player should always feel mostly in control of their fate – that is, whether they succeed or fail.
• The game should abstract something from the real world (or a sci-fi / fantasy world).  Sudoku is challenging, difficult to master, and has many permutations, but it can wear thin quickly because it does not engage the mind on any level other than a mathematical/logical one.
• The game should never waste your time.  This means having to repeat too much, travel too long, grind to slowly, or do other boring, time-consuming tasks.
• Artificial constraints are bad.  Let players do what they want to do – even if it means killing and robbing NPCs.
• Interactivity is good, even just a little bit.  Players are pleasantly surprised when objects actually respond to them.  In Ultima 7, you can move around almost any object in the world, bake bread, go fishing, and do a variety of other things (mind you, this was roughly two decades ago).
• Emotional engagement is good.  I remember when I played Master of Orion, I found myself getting pissed at the other species, and I felt like I was pissing them off whenever I did something bad to them.
• Hard-coding and scripted events are bad.  Gameplay should be emergent and based on simple, solid abstract principles from which random permutations can be easily derived.
• Instead of throwing 100 incompetent enemies at a player, throw one very challenging one at them.
• If you are making a game that revolves around horror, take away the player’s ability to defend themselves most of or all of the time.  This is very effective.
• Even outside the horror genre, the player should never feel too at-ease (unless they are in a safe area).
• Saving and loading can destroy challenge, but checkpoints are not always a good alternative.
• Players want more than just good path-finding from your AI.  But at least have good path-finding if that is relevant.
• This one is going to be controversial, but…realistic graphics are bad for fun, but good for telling a story or increasing immersion, where appropriate (as with a movie).
• Unrealistic (or stylized) graphics provide more visual stimulus than realistic graphics do, because they provide a unique stimulus.  Imagine if you ate pizza every day – the stimulus would wear thin, obviously, and you would get sick of it.  We experience reality every day, we use games to escape it.
• ASCII is not a good substitute for graphics.  I enjoyed all of the Rogue games as much as anybody else, but forcing players to decode ASCII characters ups the learning curve and limits what you can display visually.
• Bright colors provide more stimulus than drab palettes.  This does not mean they have to be overly-saturated, but players tend to enjoy bright, varied palettes that make use of most of the color spectrum.  There are some cases where bright palettes are not always appropriate (but hey, if Plants vs Zombies could do it, why can’t you?)
• Minimalism tends to be effective, in every area of game design and visual design.
• Reality is not necessarily a good model for all game mechanics – much of reality is boring.
• Plot/Story design should consider the concepts I laid out here.
• [Feel free to add your points in the comments below and I will try to add them in here.]

There are many more points I can address but I will not try to think them all up at once – you can help me with that.

At minimum, a game should be easy to learn, difficult to master, always challenging, and have many permutations both in the scenarios and the rule set.

For those of you who follow TechCrunch, you probably noticed this recent article:

http://techcrunch.com/2011/04/10/peter-thiel-were-in-a-bubble-and-its-not-the-internet-its-higher-education/

Which was not long after followed by a response from Vivek Wadhwa:

http://techcrunch.com/2011/04/12/friends-don%E2%80%99t-let-friends-take-education-advice-from-peter-thiel/

In shorter words, Peter Thiel (one of the first VCs involved with Facebook) argues that getting a degree from college is over-valued, while Vivek Wadhwa (a reputable entrepreneur and academic) claims more or less the opposite.

Everyone has a very heated on opinion on this topic, but I will try to remain as objective as possible, even though subjectively I side more with Thiel.  Personally, I have nothing against professors, schools, or college students (I was one, after all).  Everyone has the right to place their own value on a degree, and if it was worth it for you, more power to you.  I am not rallying to burn down universities, I welcome whatever benefits they can bring; I am only arguing that a degree may not be the best path to success for many people.

Based on the college you attend, the amount of money you borrow to pay for it, and the yearly rise in fees (historically 5-8 percent), you can ultimately pay anywhere from $80,000-$220,000 for a 4-year degree (keep in mind, many engineers take 5 years for a B.S.).  Add $25,000 for a masters and $50,000 for a doctorate (or more – these are the approximate medians).  For a premium education, it is not unheard of to spend upwards of $300,000.  This is not even accounting for the cost of housing. Many graduates have difficulty finding jobs after finishing school.  Many also claim that school never really did an adequate job of preparing them for the “real” world.

I think that the school system may have once been unquestionably justified.  But now we live in an age of democratized information, where pretty much anything can be learned online.  I think that this is especially relevant to software engineers. True, there are some degrees that will require special certification and some degrees that require more “hands-on” work, particularly degrees in the medical and chemistry fields.  For the sake of narrowing this discussion down, let’s look exclusively at the case of software engineers.

Can someone please answer this question for me:

As a prospective software engineer, what can a college education do for me that is worth $80,000-$300,000?

Let’s play devil’s advocate. [Please give me more arguments in the comments section, and I will do my best to address them here.]

You say: “College gives a structured way of learning materials and ensures that you learn the right things.”

I say: “So, I am paying $80k+ for a syllabus?  Couldn’t someone just post a list of books I should read and problems I should solve online?”

You say: “Not everyone is an autodidact.  Some people need motivation or a push to learn.”

I say: “So I am paying $80k+ to have teachers force me to do work? Shouldn’t I be interested enough in the degree I am pursuing to learn it on my own? Also, is it worth modifying my schedule to accommodate a professor’s? And [as Richard Fine pointed out] if you are not at least somewhat of an autodidact, how can you survive in an industry that often requires you to be independent and solve problems on your own?”

You say: “College allows you to interact with your peers and professors and get special mentoring.”

I say: “So I am paying $80k+ to talk to people? I can do that for free.  If I have a problem, I ask Google, StackOverflow, or Quora.  If I want to discuss something, I go on IRC.  And mentorship is over-rated: with a 30+:1 student/teacher ratio, you really do not get much attention.”

You say: “College is a special experience that cannot be replicated.  Nowhere else can one immerse themselves in academia.”

I say: “Going to Cancun is a special experience that cannot be replicated.  Nowhere else can one immerse themselves in of all the intangible aspects that are the experience of Cancun.  In other words, is it really worth $80k+ to rub shoulders with academics?”

You say: “Just try and get a good job without a degree.  Good luck.”

I say: “Just try and get a good job with a degree.  Good luck.  See how well your degree distinguishes you when you have to get in line with 10,000 graduates from Ivy League schools.  The best job is the one you create yourself, and you don’t need a degree for that.  Ask Zuckerberg and Gates about that one.”

You say: “We can’t all be Zuckerberg or Gates.  We are more likely to fail than succeed if we build a startup.”

I say: “That is true.  And that failure will be gold in the eyes of any employer.  Experience is experience, good or bad you learn from it.  Employers hire based on experience and reputation.  Degrees are just a threshold for lazy employers.”

[Added via JohnS] “Higher education is free in many countries (particularly throughout Europe).  So how can it not be worth it?”

I say: “It is not really free in these cases, but comes from tax payer dollars.  So, as soon as you are making money, you are paying for it in income taxes, in addition to shouldering the cost of education for those who do not work.”

[Added via various comments] “But higher-education makes you a well-rounded person! And being well-rounded makes the world a better place for everyone!”

I say: “No, you make yourself a well-rounded person.  If you decide to stop learning outside of your field when you leave the university, you are not truly well-rounded.  That said, what is the real, tangible value of being well-rounded?  If you learn information that you never once use, what is the point?  Is being “well-rounded” worth $80k+?  Giving $80k+ to starving children makes the world a better place, learning Art History does not.”

[Added via various comments] “But college teaches you important theories and fundamentals that you would never learn on your own!”

I say: “So, once again, I am paying $80k+ for a syllabus?  Why can’t I learn the fundamentals on my own?  Do I really need to pay a teacher to ram them down my throat?”

Y-Combinator, a startup incubator, once gave people $6,000 per team member for a period of 3 months to build a prototype (they now give $150,000), in return for 2-10 percent of their company.  Say what you will about Y-Combinator and its alumni, but even if your startup fails, having Y-Combinator on your resume is much more impressive than even a Stanford Degree (ask any employer if you don’t believe me).

Now, imagine if you invested $80k-$300k in yourself.  If you live frugally, that can carry you a long, long time, especially if you live with your parents.  Long enough to launch several companies, and learn from your very likely failures.  I can guarantee that this path will be 1000 times more impressive to prospective employers than a degree will.  That, and you might not even need a job if your company ends up successful.

A degree is an expensive piece of paper.  An education is something that can be attained with or without a degree.  Can we agree on that?  So what is a degree really worth?  In my personal experience, almost nothing.  Here is why:

I went through college almost without attending a single lecture (aside from the lectures where my attendance was required, and in those lectures I took out my laptop when possible and tuned out the TA or professor).  This was not because I thought I was a hot-shot, it was just that I really hated sitting through lectures and preferred to read through the books at my own pace.  Even with that said, I did not crack most of my books (some still had the plastic wrap on them).  The vast majority of what I learned came from the internet, and most of all from working on hobby projects.  The great thing about working on my own projects was that I learned why things worked because I derived them myself, rather than regurgitating material that professors rammed down my throat. I graduated with a GPA over 3.8, which is relatively high for students in Computer Science, in spite of hating most of my courses.

Upon graduating, I started applying for jobs.  I sent out hundreds of applications and did not get one response.  So I continued working on my hobby project at the time, a 3D engine for a MMOG.  A few months later (mid 2006), I published my first tech demo to Digg, and it was featured on the front page.  Then I was featured on Joystiq, Kotaku, Destructoid, and other gaming blogs.  Up until that point, I had no reputation, but within one week my website had 600,000 hits and my name turned up on webpages from every country in the world.  Employers came to me, including Pixar and Electronic Arts.  Not one of them asked about my degree, or if I even had one.  I was not a Zuckerberg or Gates, and I was not smart or gifted.  I was not even successful.  My project failed, as it turned into vaporware when all my time was sucked up by a “real” job.  But it was, by far, the best use of my time up to this point, and put me where I am today.

There are schools that specifically teach game development, such as Full Sail University but I cannot vouch for how well they prepare their students for the industry because I have no idea.  What I do know is that most standard schools do not prepare their students for a career in the game industry, I think that most people can safely agree with me there.

Why is this notable? I remember when I went to the orientation for engineers at UCSB.  One of the orientation guides asked all of us why we had entered the program.  The overwhelming response was “to learn how to make video games.”  Very few of them, to my current knowledge, ended up doing that…but it gets better.  Most of the students I knew actually ended up working for startups.  Throughout college, we had programmed almost entirely in C/C++ and Java, two languages that are almost never used in the startup environment.  Needless to say, college failed to both teach them what they were passionate about and what they needed to know for their career.

What is my biggest gripe with college?  It teaches you how to follow instructions pretty well, which is a great skill if you want a job.  But what if you want to be an entrepreneur?  Yes, there are plenty of leadership classes and such, but I can tell you this right now just as well as anyone else can: you cannot be taught how to be a leader.  In fact, the very act of being taught means you are following, not leading.  Leaders are born in the fires of real struggle and failure, and nothing else.

There is no doubt in my mind that education is very important, but it would seem that college often fails to provide the education that we seek.  So what is the difference between a degree and an education?

A degree gives one a false sense of entitlement and pile of student loans.  Degrees also promote class-warfare, racism*, and academic elitism, as the best degrees (statistically speaking) go to children of wealthy people or the poor saps who are there to fill a diversity quota.

On the other hand, an education is free, and never ends.  Thanks to the internet, everyone has (more or less) equal access to the same education.  Education is blind: it does not care about your class, skin color, credit score, SAT score, or GPA.

[*Say what you will, but in my book reverse-discrimination is racism: it is demeaning to minorities, as if they were not capable of great achievements on their own two legs.  Do minorities generally have it harder? Yes, but reverse-discrimination is an insult to those who have persevered through even harder conditions than our relatively modest modern ones.  If someone gets pushed around in a wheelchair their entire life, their legs will get weak.  Whatever struggle minorities might face only makes them stronger, more capable people.  In short, treating anyone differently based on their race qualifies as racism to me.]

I am almost 30 years old, and I have been programming for almost 18 years – some of those years I spent 100 hours of every week programming.  I know just enough to know that I know very little.

I have felt entitled, as if I knew everything, and I have felt humbled, as if I knew nothing.  For some reason, to me, the latter feels much better.

In my last article, I gave a brief overview of Procedural Generation (PG) and User-Generated Content (UGC).  In this article, I have decided to discuss something that gets surprisingly little attention: procedural generation of storylines/plot/quests/dialog and so forth.

Procedural generation of storylines is very common, whether or not we realize it.  Sadly, most of these consist of fetch object X to receive reward Y or kill monster A to proceed to area B.  We use these kind of mechanisms all the time, but we have a hard time pinning down what is “wrong” with them.

I think that games stand as their own medium, but that does not mean we cannot learn from other types of media.  Imagine that you are reading a book.  Throughout the book, the character kills monsters, grabs loot, travels through different areas, and talks to different people.  This describes many books, but it is a superficial aspect of them.

Bad books tend towards this superficial aspect.  Good books have something going on under the surface.  Everything that happens makes sense, but at the same time, is not entirely predictable.  There are a million ways you can break it all down, but I am going to start from the top and work downwards.  Note that I have no formal education in writing, so I am doing my best to describe patterns as I have seen them.  I will scatter some examples from popular stories throughout.

At the top level, you have:

• Characters (Actors)
• Items (Props)
• Environments (Scenes)

CONTEXT

Now, let’s dig deeper.  Every character, item, and environment has a timeline that dictates their qualities, abilities, and motivations, from past to future.  We will call this the context.

• Characters (Actors)
  • Beginning: Character is born, genetic makeup is determined.  Also notable are the family and environment the character is born into. (Hercules was the bastard child of Zeus and Alcmene, Zeus’s real wife Hera was pissed.)
  • Past: Character’s back-story, determine’s their learned behavior.  In combination with their genetic makeup, this determines their personality and motivations. (Jean Valjean was born into hardship, learned the ways of a thief, and grew to value morality over the law.)
  • Present: Character’s current state, location, conflicts, tasks, etc. (Horton’s acute hearing tasks him with helping a village of tiny people.)
  • Future: potential of character, fulfillment of a prophecy, etc. (Harry Potter was viewed as one of the few people who could defeat Voldemort.)
• Items (Props)
  • Beginning: how the item came to be; where its resources were collected from, how it was crafted, etc. (The Ring was forged in the fires of Mount Doom.)
  • Past: who owned the item, what historical significance the item has, etc. (The Ring was lost in a river and eventually found its way to Gollum and corrupted his figure and morals.)
  • Present: where the item currently is, its current state (broken, hidden, scattered across the land, etc). (Frodo carries the Ring, Sauron is looking for it.)
  • Future: where must the item go? (The Ring must be taken to Mount Doom and destroyed.)
• Environments (Scenes)
  • Beginning: How was the land formed, how was the structure built, what inherent qualities does the land have, etc.
  • Past: how did the environment change over time, what happened in the area, etc.
  • Present: the present state of the environment, what events are occurring.
  • Future: what will happen to the environment (The Tree of Souls will be destroyed unless the Navi can stop the humans.)

All of these things set the context – they explain why things happened, what is happening, and what might happen.  But the context alone does not make a story, in fact it only introduces what we need to know to understand the interactions that will occur throughout the story.

INTERACTIONS

Given the context of the characters, items, and environments, how will things play out?  These interactions are a fundamental part of the progression of the story, but on their own they do not necessarily make for an interesting story.

Lets look at all of these permutations of interactions – below are just a few examples, I am sure you can think up more:

• Character-Character: Characters talk to each other, lie, fall in love, (attempt to) assassinate each other, vow for revenge against one another, transport one another (hostages, bodyguards…), etc.
• Character-Item: use items to empower themselves (i.e. drink a potion) or achieve a goal (i.e. using a key to unlock a door), or even kill themselves (Juliet uses Romeo’s dagger to kill herself.)
• Character-Item-Character: characters give an item to empower or curse another character, they use items on one-another, etc. (The Witch gives Snow White a poisoned apple.)
• Character-Environment: Characters must travel to their destination, seek haven, find a place to eat, etc. (Harold and Kumar seek out White Castle.)
• Character-Environment-Item: Characters must seek out hidden items from environments, collect items scattered across different environments, use an item to proceed to a new environment, etc.

Interactions will create a story, but not necessarily an interesting one, as stated earlier.  You need to have a clear goal and progression in order to derive meaning.

MEANING

Meaning is all of those “intangible” things you learned about at some point: theme, climax / turning point, epiphany, character progression, and so forth.  Instinctively, we might think that it is impossible to put effective meaning into games, unless they are very linear in nature like books and movies.  I would argue that it is not impossible, just hard.  If you give your users free reign and make a total sandbox game, chances are they won’t produce a very effective storyline.

This “problem” has been solved, and it might surprise you how old the solution is.

Dungeons and Dragons.  I must shamefully (proudly?) admit that I have never played the board game.  Regardless, I understand the mechanics behind it.

I am sure there have been plenty of D&D games where players kind of just mess around and do what they want.  Interestingly, these have probably been the least enjoyable games for everyone.

When players follow a structure, and more importantly, play a role, they tend to have much more interesting sessions, because their games have meaning.

Roleplaying has become a bit of a misnomer.  We are very, very rarely playing a role in modern video games.  We are controlling a person who has a context and is capable of many different interactions, but they are rarely confined to a role. This is why most of the characters we play feel like they have no personality – because we aren’t really confined to one (I’m looking at you, Commander Shepherd).

I am as much against artificial constraints as the next guy, but I think we can easily introduce motivations for people to play their role.  We can do this without having to pretend, but instead using the game’s inherent mechanics.

It all comes back to meaning.  I can go slay the monster, collect the loot, and return for another quest, but what does it all mean? You cannot have meaning without persistence.  What impact does my action have on the world, and what is my incentive to perform this action?  How can we effectively insert meaning into nonlinear games?

STORY ELEMENTS AS GAME MECHANICS

In order to have any semblance of structure, we must play a role.  How do we get players to fulfill roles without placing artificial constraints on them? We have to make qualities of the role a tangible aspect of gameplay, and reward players for following their roles and not reward (or punish) them for stepping out of their role or diluting their role.  Given our character’s context, we must determine their motivations. We must also determine how their interactions fulfill or conflict with their motivations.

How do we turn this into something tangible?  There are many ways, but I will point to one obvious way: the meter.  If you ever played The Sims, this game used a system of meters to determine the state of your character.  They had a hunger meter, a bathroom meter, a fatigue meter, and various meters representing their emotional needs.  If their needs were met, they would function properly and succeed in the various aspects of their life (career, relationships, etc.).  In theory, you could do whatever you wanted with your Sims, but the game encouraged you to try and fulfill the needs of your Sim.

Imagine that in your roleplaying game, a character has a meter (or some other tangible entity) that measures how well you have fulfilled their ambitions, goals, and so forth.  Perhaps this meter affects other areas of gameplay (i.e. how effective your character is in combat), or perhaps it has direct effects of its own.  If your character is a thief, perhaps you must satisfy their urge to steal, and you must avoid combat because it makes your character uncomfortable (they prefer to sneak around).  In order to construct an effective storyline, you need a number of roles to be played.

• The Hero(es)
• Neutral Characters
• The Villain(s)

Additionally, each role should have a fairly well-defined subset of abilities.  Characters that can do everything and have no weaknesses are boring characters.  This is why we have archetypes in stories.  Each character is a piece of the puzzle and they all use their strengths to achieve a goal while their weaknesses are exploited by the villain or other circumstances.  Character archetypes are popular in story-telling, here is a fairly comprehensive list of them:

http://www.listology.com/list/character-archetypes

EMERGENT STORYLINES

We can encourage characters to go down certain paths and motivate them to play their roles, but how do we create a game engine that constructs meaningful storylines on its own?  It is actually surprisingly simple, and only involves a little bit of AI work.  I won’t delve into the technical details, but if you understand propositional logic, backwards chaining, expert systems, and how languages like Prolog work, you probably have a good idea of how to implement systems like this.  I will layout the basic functionality of this system below:

• You play a character who has a set of motivations that you try to fulfill.
• The game controls a number of NPCs via AI.  Each NPC has its own set of motivations.
• One or more NPCs has motivations that are in conflict with yours.

Let’s take a look at a simple example.  Imagine that we present the following facts into our system.

• There is a playing field with a limited amount of gold and three characters, and random walls everywhere.
• One player can only see another if a wall is not blocking their line of site.
• You control character A (the “hero”), whose motivations are to abide by the law and collect as much gold in your stash as possible.
• The computer controls character B (the “villain”), whose motivation is to collect as much gold in their stash as possible.
• The computer also controls character C (the “guard”), whose motivation is to enforce the law and prevent crime.
• The law states that it is illegal to kill or steal, and the punishment for either one is death.
• Dead people cannot perform any actions (namely, they cannot collect gold).
• If a crime is not seen, a punishment cannot be enforced.

Left to its own motivations, the villain might try to kill you (the hero), even though it was never explicitly instructed to, because out of all the paths it can take, killing you might yield the maximum amount of gold (provided it can do so without being seen by the guard).  Or, if the guard is always too close to the hero, the villain might just try to steal from the hero’s stash instead.  On the other hand, you will probably not kill or steal, because the game mechanics will find some way of punishing you for defying your given role, whether or not the guard is watching.  Also, interestingly, the guard will probably follow around the villain more closely, because it knows that the villain is more likely to break the law and it is motivated to prevent crime.

This is a very simple example, but the important thing to note here is that there are no explicitly-defined scenarios, everything is implicit based on the circumstances.  Personally, I think that explicitly-defined plots are bad for gameplay.  They might be able to create a better, more powerful storyline, but they are bad for gameplay because they tend to force players into linear scenarios, thus limiting replayability, increasing predictability, and diminishing the feeling of a truly interactive environment.

So, what do you need to form a coherent, emergent storyline?

• Characters, Items, and Environments (this should be a given…)
• Context (properties and history of each entity)
• Interactions (each character has a given set of actions they can perform which are probably partially dictated by what items they posses and their current environment)
• Meaning (motivations to perform actions that make sense, clear end-goals)
• Well defined roles
• Abstraction of each of the former for the purposes of AI and gameplay mechanisms – most things should be able to be measured by a number or boolean/fuzzy logic.

Tying it all together: in every instance/turn, characters weigh the facts (context), the state of their present environment, and their motivations against a list of possible actions.  They then select the action with the highest predicted return towards their motivations and the system is updated with the new data.  Repeat as necessary.

MYSTERY

Good storylines have mystery and plot twists, even if they are not explicitly classified in the “mystery” genre. It is fairly easy to incorporate these elements meaningfully into a game.  For example, lets take another set of facts from a hypothetical game (here, the “?” represents facts that are not immediately apparent to the player or AI):

• A farmer has the motivation to keep his sheep alive and has some money.
• You play a mercenary that will kill anything for money.
• Dragons kill sheep.
• ?
• A farmer’s sheep are being killed.

With a bit of backwards chaining, the farmer will probably deduce that he can keep his sheep alive by paying you (the mercenary) to kill the dragon that is killing his sheep.  So, you camp out, waiting for the dragon to attack.  Instead, you see some wolves attacking the sheep (this fact is represented by the “?” – and represents part of the mystery/plot twist).  Again, this is a very simple scenario, but imagine the possibilities when you set the stage with a myriad of characters, items, environments, and context with high potential for mystery, conflict, and other story-telling mechanisms.

DIALOG

So, how might you handle dialog in a non-linear game with emergent storylines?  Well, lets keep it simple for now and imagine that everything is text (no recorded speech).   Creating an AI that is able to fully understand and parse every word you type is probably beyond the scope of most games, but there is a simpler alternative: sentence fragments.  Imagine that you are able to construct your dialog from a series of words or sentence fragments.  Here is one example: [promise to][kill][1][dragon][in return for][20][gold coins].  It might seem difficult to interpret a series of fragments like this, but we have been doing it since the dawn of computer languages.

If you have ever written a compiler, this is exactly what you would need to handle something like this.  So, you have a series of sentence fragments or words, which are basically the equivalent of tokens/keywords/functions in a compiler.  Then you have names of people, places, and items, which are the equivalent of IDs or variables in a compiler.  You could parse any string of sentence fragments and validate it against a Context-Free Grammar (which is basically a grammar check).  Upon parsing and interpreting your sentence, the AI adds it its database of facts or propositions, and then acts on its new set of data.

I cannot recall a game that has yet implemented something like this to an effective degree.  It would lend itself to many interesting possibilities though.  The AI might try and manipulate your character’s motivations by lying to you, or similarly you could attempt to manipulate the AI by asking NPCs to do tasks for you (i.e. distract a male guard by telling a female NPC that the guard thinks they are attractive, thus prompting the NPC to flirt with the guard).  Even beyond manipulation, it could be the infrastructure that creates a real, breathing world in which characters interact with one another in a totally improvised, but believable, manner.

In a greater scope, it might sound like a pipe-dream, but I think that if we attempt to implement simple game mechanics systems like this are totally doable.

There is room for a lot more discussion in this area, but I should probably cut it short at some point. I apologize if I lack clarity but feel free to ask me anything.  Mostly, I just want to get the gears turning.  What do you think? Are systems like this a good idea or doomed for failure?

On the 7th day, [insert preferred deity here] became lazy and said, “Nature, design thyself.”

There is an undeniable link between math and nature.  I could start boring you with talk of the Mandlebrot set, Voronoi diagrams, Delaunay triangulations, the Golden Ratio, and so forth, but here is a cool video that does the job better than my words could:

Whether it is nature that defines math or math that defines nature, we will leave those questions to the burger flippers…oh, I mean philosophy majors. ;)  For now, all we need to know is that this link, as programmers and artists, benefits us dramatically.  It means that we can more easily abstract the laws of nature into code, and thus more easily simulate and create nature in a virtual environment.

But procedural generation applies to much more than just nature, it is also perfectly capable of generating non-organic, “man-made” structures.  In fact, it might surprise some people that man-made structures exhibit many organic properties, and are often intentionally designed to mimic nature.  The columns in Ancient Egypt, modeled after papyrus and palm plants, are one simple example of this.  A city map, in some rural areas, often looks similar to the vein layouts on certain plant leafs.  Even in areas not directly tied to nature, structures exhibit mathematical symmetries and designs that can easily be expressed by simple logic.

So, those of you who do not already know might be asking, “What is procedural generation?”  It is, as the name implies, the process of generating things procedurally (or, via code).  The opposite approach would be manual generation, or “doing it by hand.”  As far as it is related to game design, these things are better known as “assets” or “content.”  These assets can literally consist of anything – textures, meshes, animations, scripts, behaviors, parameters, you name it.   In terms of the types of content that can be produced, the sky is the theoretical limit: humanoids, buildings, cities, terrain, plants (flora), animals/creatures (fauna), clothing, vehicles, and so forth.  In some cases, game designers will expose some of the procedural generation abilities of their engine to the end-users, either in-game or in an external editor.  This leads to user-generated content (henceforth: UGC).  In some cases, the mechanisms used to achieve this can be very complex (as with some map-editors), or they can be very simple (masked as elements of gameplay, as in Spore).

So, in less words, procedural generation (henceforth: PG) takes much of the work that your artists and level designers would have to do by hand, and automates it.  Sounds awesome right?  Well, it can be, if it is done right.  But many people in the industry frown upon PG (and UGC, for that matter).  Sometimes, it is with good reason, and sometimes, it is just because they don’t really understand what PG and UGC are capable of and how they can easily be abused.  I would like to clear up a few of those points (I will call them “myths,” but feel free to disagree).  Mind you, all of the “myths” below have been said to me before, often multiple times.

Myth: PG/UGC leads to watered-down, random, sand-boxy gameplay

Many people will claim that PG is a lazy replacement for real, intentional, hand-crafted game design.  And it often is.  In The Elder Scrolls II: Daggerfall, all of the towns, people, dungeons, quests, and so forth, were procedurally (or randomly) generated.  On one hand, this led to a huge game world, far beyond the size of anything that had been made before it.  On the other hand, the towns, people, dungeons, and so forth all had (in my opinion) incredibly boring design, because they all lacked the hand-crafted touch that could have made each character and location unique and interesting.  In some cases, PG gets the job done adequately, like in Rogue-esque games such as Diablo, which are basically all about grinding.

But these are not the best examples, because they were around before the term “procedural generation” was being used a lot.  To date, the reigning champion of PG (and UGC) examples is Spore…unfortunately.  [Side note: I was contacted by someone at EA many years ago that asked if I wanted to work on Spore, after they saw some of my work with PG -  I did not take the job though.]  Don’t get me wrong, it is an interesting game in its own right, but it failed to properly represent the capabilities of PG/UGC on many levels, and caused many people to get the wrong ideas about PG/UGC.  Before I insult anyone that worked on it, let me say that they did a remarkable job given their constraints.  The problem with Spore is that it is not so much of a game as a sandbox.  And even as a sandbox, it wears thin pretty quickly.  Its main problem is that it does not really use PG or UGC to its advantage – the assets you generate do not impact gameplay very dramatically or meaningfully.  Some aspects of it were done very well, but at times it felt a little bit too much like Mr. Potato Head, where the procedural generation was simply pasting together prefabricated assets.

UGC is an issue on its own.  It can be difficult to monitor UGC, and in some cases it can detract from the suspension of disbelief (especially when juvenile humor is involved).  A strong brand and design can also be easily destroyed by UGC.  That said, UGC can be given constraints that make it an effective tool for growing your game’s content while not destroying its image.  The best way to do this (in my opinion) is make the design process for UGC directly affect gameplay.  So, for example, if users are building a castle in an RTS game, it will survive if it is properly designed to defend its people, and it will be destroyed if it is a pile of garbage.  People can also police/moderate themselves, which is also sometimes an effective mechanism.

As for PG, I would argue that it is almost always a good thing, if it is done right.  PG should be used to help the designers and artists, and get rid of monotonous work.  If it can’t be properly automated, then it should not be.

Myth: Procedural Generation == Random Generation

Random Generation is a subset of Procedural Generation, just as squares are a subset of rectangles.  Procedural Generation does not have to be, in any way, random.  Explicitly provided parameters can be used to adjust every aspect of procedural content (for example, the radius of a tree trunk or the number of buildings in a city).  Random generation can often work against designers, and they will find themselves regenerating assets constantly to get them to “look right.”  Even “random” assets can be given a consistent look by using a fixed number for the seed in the random function (versus, say, basing the seed on the system timer).

Myth: Procedural Generation cannot produce assets of type X

Anything that you can logically describe can be procedurally generated.  Some things are much harder than others.  One of the hardest things, in my opinion, is procedural animation of creatures and humanoids.  It has been done successfully, to varying degrees, depending on how you define success.  But I still do not think anyone has yet created creatures that use true AI (without any preset behaviors or motions) to navigate through complex environments using all of their limbs (for example, jumping and grabbing onto ledges, and so forth).  I’m working on that one, I’ll get back to you on it….;)

Myth: Procedural Generation cannot produce stylized characters or assets

Wrong.  Spore is very stylized, although, as I mentioned before, it is, at times, a bit too cut-and-paste of pre-fab assets.  As stated before, procedural generation can produce anything that can be logically described, which is…anything.  As humans, we like to think that we have some kind of special “creativity” gene that computers can never replicate, but our notion of “creativity” is clouded and vague.  Creativity is actually very simple – it is simply the process of absorbing all that we have learned to produce something “new” (not necessarily unique) that has intentional meaning.  To clarify, even if a computer randomly threw blobs on the screen, and it happened to look like a butterfly, that is not creativity, it is coincidence.  Computers can, and have, already produced creative works of art, without explicitly being told how to do so.  That said, at this point in time it is not really the job of PG to be “creative” – PG is only supposed to help artists and designers express their creativity faster and more efficiently.  Artists should be able to tweak almost every attribute of a PG object to style it according to their vision.

Myth: Procedural Generation is a lot of work, and often not worth the effort

It is true that procedural generation is more work than it is worth, if you are looking at one title.  But if you are reusing your work, PG is the goose that lays golden eggs.  Once it is built, it is built, and there is no need to reinvent the wheel, only fine tune it.  When I look at many modern games, I cannot help but think what a shame it is that so many artist hours are wasted on what are essentially identical assets.  Even worse, all of the work that goes into assets that never get past the cutting floor – PG can at least let artists experiment rapidly with prototypes, before they go in and fine-tune things manually.

Myth: Procedural Generation is too slow to be used in commercial games

Some consoles might be too limited to use PG with (in terms of memory), during runtime.  That part is true.  But you can do PG offline and benefit from it as well.  However, if it is done right, PG can be a lot faster than loading dense meshes and texture maps from disk (That is, generating data in memory, even with a bit of CPU work involved, has the potential to work faster than a hard disk or DVD can load).  Often times, it will be too slow to generate assets every frame (as with procedural textures), but it can be done once and then cached in many cases.

Myth: Procedural Generation will never go mainstream

I would argue that, as a force of nature, it will have to.  Budgets for games are simply growing too big.  People simply cannot produce content fast enough for consumers.  There is not enough room for risk and innovation.

Myth: Procedural Generation will replace artists/level designers

PG will empower artists and level designers, but it will never replace them until we can build an AI that can do everything an artist or level designer can (no small task).  At that point, we would probably have AI that would mostly replace programmers as well.  Whether or not that is possible, feel free to debate, but I think it is – however, not for a very, very long time from now.  Regardless, the goal is not to replace people, but allow them express their vision easily without worrying about the tedious details.  If you define procedural generation as taking a high-level command to create/modify low-level data (a mesh, texture, etc), artists already use procedural generation every single day.  A brush stroke in Photoshop takes a click and procedurally turns it into a set of pixels (or bytes) to mimic a brush stroke.   A tween procedurally creates frames of animation between the parent key frames, freeing the artist of a time-consuming task.  I could go on…

Conclusion

In short, I think that procedural generation has a bright future, but we still have yet to realize a fraction of its potential.  Progress has been slow for two reasons, in my opinion: the misconceptions listed above, and the generally low appetite for risk within the industry.  I think that PG has the potential to bring us back to the golden era of the 80s and early 90s, when “AAA” games were made by small teams.  I have much more to write on this topic but I need to leave room for my next articles.  Please join me next time for a more interesting and in-depth discussion on PG and UGC.