Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Patterns in Game Design

samzenpus posted more than 8 years ago | from the build-a-better-shooter dept.

110

Aeonite writes "The quote on the cover of Patterns in Game Design proclaims that this book is "that rare sort" that is actually "useful." It is perhaps somewhat presumptuous to disagree with someone like Greg Costikyan, but nevertheless I have my doubts as to the book's overall utility. While this book certainly seems like the sort of be-all, end-all of game design theory, what it amounts to is little more than a list, each item on the list referring to the other items like bloggers hawking each others' hyperlinks. What could have been a sort of cookbook for gaming turns out to be less a book of recipes, and more a list of ingredients: "a loaf of bread, a container of milk, and a stick of butter." Read the rest of Michael's review.

The book is broken into two Parts and 15 Chapters. Part I, "Background," explains the overall approach that the authors took in creating the rest of the book, exploring four different categories of gameplay (holistic, boundary, temporal, and structural), explaining the template used for the game design patterns that follow, and suggesting means for identifying patterns and applying them to the design of a game.

Part II, the bulk of the book, is where the Pattern Collection itself lies. The collection is broken into eleven chapters, each covering a grouping of patterns that share a common element. Chapter 5, for example, covers "Game Design Patterns for Game Elements," which includes Game Worlds, Objects, Abstract Objects and Locations. Each of those categories is further broken down into the Patterns themselves; for example, "Abstract Objects" includes Patterns such as Score, High Score Lists, and Lives.

Each Pattern is laid out in the same fashion. First, there is a one-sentence summary of the Pattern, followed by a more detailed description, and any relevant examples. This is followed in turn by examples of Using the Pattern, Consequences of its use, and its Relations to other Patterns. Relations include a list of other Patterns that fall into five categories: "Instantiates" (causes other Patterns to be present), "Modulates" (affects other Patterns and thus gameplay), "Instantiated by" (is caused to appear based on other Patterns being present), "Modulated by" (is affected by other Patterns), and "Potentially Conflicting with" (can cause other Patterns to be impossible within gameplay).

This all sounds a bit scholarly, and it is, but once you get the hang of it, it's not all that hard to slog through. However, it is indeed a slog -- each Pattern is in great part made up of references to other Patterns, which means that for a full understanding of any one Pattern, you must consume many other portions of the book. In their introduction, the authors do point out that this was their intent, and that you can "read the patterns in any order, similar to how a dictionary or encyclopedia is used." Indeed, reading through the book in any fashion is about as entertaining as reading those books. Which is to say, it's occasionally enlightening, but not really easy to do for any length of time. Here's an example from the "Surprises" Pattern, where any italicized word is a reference to another Pattern:

"One requirement for Surprises is the absence of Game State Overview or the presence of Imperfect Information or Limited Foresight. Because of this, Surprises are most often achieved by having Dedicated Game Facilitators such as Game Masters. Never Ending Stories are a way of overcoming the problems of Narrative Structures by combining Surprises with Replayability, thus making the narrative continue and change forever."

At the end of many subcategories are references to "Additional Patterns," which are only explored on the CD-ROM that accompanies the book, apparently having been left out for lack of space. Their omission (they do not even appear in the book's Table of Contents or Index) makes the book itself somewhat less useful than it otherwise could have been, since the Patterns within the book so often refer to Relations with Patterns that are not actually found in the book itself. The net result is that if (for example) you are reading about Surprises, and you want to learn about Never Ending Stories, you have to put the book down and pop the CD-ROM in. Not only is this disruptive, but it's impractical at best.

Were the CD-ROM itself more easily and logically laid out, it might have overcome some of the problems within the book. Containing everything within the book, plus the many additional Patterns not found in print, the bare-bones HTML allows you to browse either alphabetically by Pattern name, or "by chapters." This latter is somewhat misleading, for the list of Patterns within each Chapter is alphabetical on the CD-ROM, and not so within the book. On the CD-ROM, Chapter 5 starts with the following Patterns: Alarm, Alternative Reality, Avatars... In the book, however, Chapter 5 contains the category Game Worlds, and then Patterns such as Game World, Reconfigurable Game World, Levels, etc., in that order. The lack of consistency can make for some maddening moments trying to toggle back and forth between book and CD-ROM, like reading a dictionary that's in part alphabetical, and in part organized by, "nouns," "verbs," "adjectives," etc.

The CD-ROM is also inconsistent when it comes to the book's two Appendices. Appendix A, "Further Reading," contains a list of over fifty articles and books referenced elsewhere in the text, and appears only in the book. Appendix B, "About the CD ROM," appears in both the book and on the CD, where for some curious reason it's in Word DOC format. There are also an assortment of images, including colorized versions of those found in the book, as well as a set of PowerPoint presentations.

Overall, the book does succeed in compiling an impressive list of Game Design Patterns. Whether the list can ever amount to anything more than scholarly masturbation is another question. The thick language, combined with the definition of Patterns by reference to other Patterns, means that overall this book is probably about as useful in the realm of Game Design as a Dictionary is in the teaching of the English language. Which is to say, it's undoubtedly a useful tool as part of a much, much broader toolset, but in and of itself it leaves quite a lot to be desired."


You can purchase Patterns in Game Design from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

110 comments

Sorry! There are no comments related to the filter you selected.

What Incredible Progress (3, Funny)

AKAImBatman (238306) | more than 8 years ago | (#14810198)

1994: The computer scientist and game programmer Andre LaMothe [wikipedia.org] writes the quintessential book on game programming, "Tricks of the Game Programming Gurus [amazon.com] ". The book is dense with useful information, humor, and actual theory on game programming. Millions of Game Players are transformed into real-world Game Programmers overnight.

2004: Staffan Bjork & Jussi Holopainen attempt to bring all the wonder and excitement of development patterns from the business world into the Game Programming world by releasing an utterly boring book full of confusing terminology. (2.5 stars on Amazon.) Programmers everywhere are unimpressed, and budding game makers are left confused. The bright side is that the book explains what an Avatar and High Score List are.

My, my, my. How far we have progressed. :-(

Re:What Incredible Progress (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14810584)

As a game developer myself, I have to say LaMothe is the biggest game development poser that exists. He regurgitates the same awful book over and over again. He never brings any new or enlightening information to the table. He hasn't written any games anyone has ever heard of. Why do people read his books and assume he knows anything. There are so many other books that are a million times far superior to lamothe's books.

At least this book on game development patterns attempts to consolidate and define the basic psychological building blocks of gameplay. Maybe it's not written very well, but i have to applaud the offer for attempting to inject new content into the field.

Not to mention this book is geared entirely for designers, not programmers (why would programmers need to be impressed by a design book?). There is value in deconstructing something to find out what it's smallest parts are. It allows for more intelligent analysis of what makes something "fun" and why.

Re:What Incredible Progress (2, Informative)

BlueCodeWarrior (638065) | more than 8 years ago | (#14810592)

Tricks of the Windows Game Programming Gurus was a good follow up to that book. I have both on my shelf right here.

Non sequitur? (4, Insightful)

Moraelin (679338) | more than 8 years ago | (#14810636)

One is a book for programmers, the other is a book for game _designers_. So the relevance of that comparison is...?

Even if you're of the arrogant school of thinking that programmers are the alpha and the omega, and everyone else is an idiot, the program code itself _isn't_ the alpha and the omega. A game isn't just a collection of clever rendering/AI/collision/whatever subroutines. And knowing how to write clever code doesn't make you a game designer, any more than knowing how to lay out a brochure makes you a marketting expert, or than knowing how to assemble a telescope makes you an astronomer.

At any rate, designing the game and programming game code are two very very different things. Some people may be able to do both -- though a lot less than people who _think_ they could do both -- but still, they're different activities. So exactly what is the relevance of programmers or game programming books there? No, seriously. It's like saying that we don't need a new chemistry book, because a better written gardener's handbook already exists. Yeah, and the relevance of that is...?

I'm not saying that this book is particularly useful. In fact, it sounds like a major waste of time. But I _am_ saying that it addresses a whole different subject and targets a whole different audience. That's all.

Re:Non sequitur? (1)

AKAImBatman (238306) | more than 8 years ago | (#14810900)

One is a book for programmers, the other is a book for game _designers_. So the relevance of that comparison is...?

The comparison is that one did something useful, while the other one doesn't. Or to steal from the forward of "The Theory of Fun":

The title of this book almost feels wrong to me. As a game designer, seeing the words "Theory "and "Fun" in such close proximity instinctively makes me a bit uncomfortable. Theories are dry and academic things, found in thick books at the back of the library, whereas fun is light, energetic, playful and... well... fun.


The book smacks of trying to make an artist out of someone by explaining what an easel, brush, and paints are rather than teaching him to paint while encouraging his creative side.

Gaming has always been about what "feels" right. A good game could be a few tweaks away from a really horrible game, but it's impossible to know unless someone with a creative side jumps in and adds their creative side to it. Tricks of the Game Programming Gurus took the right approach back in the day. It taught you to "paint" while encouraging you to apply your creativeness and artistic side to it. This attempt at "patterns" feels cold, detached, and a very poor attempt at convering what a designer really needs to learn. If you really feel that you need a book on design independent from programming, then something like A Theory of Fun is a far better choice. At least the author recognizes that games are warm things that can't be so easily quantified. (Though I question the concept of separating a tradesmaster from his trade. Would a building, no matter how beautiful, be designed by an architect lacking in engineering background?)

Re:Non sequitur? (1)

Moraelin (679338) | more than 8 years ago | (#14811120)

"If you really feel that you need a book on design independent from programming"

Indeed I do, because the two are very separate facets of it. A game is _not_ just the code implementing it, and what made, say, KOTOR fun _isn't_ the clever lightsaber rendering code or the NPC dialogue code. The most important parts, the parts that the actual users saw, were the game design parts like the actual dialogues, not the implementation details behind them.

"(Though I question the concept of separating a tradesmaster from his trade. Would a building, no matter how beautiful, be designed by an architect lacking in engineering background?)"

I see no problem separating a tradesmaster from a completely _unrelated_ trade. The architect who designed a bank building is _not_ an expert on banking or economics. He may be a brilliant architect, he may have an engineering background, but chances are he's not also an expert on economics. The electrical engineer who designed the coils for a hydro power-plant, chances are he's _not_ an expert on anything else in that plant, and I certainly wouldn't entrust him with designing the dam too. The guy who designed an overhead projector, no matter how good he might be at optics or mechanical engineering, chances are he doesn't know jack squat about the management processes that will use that projector for a business presentation. Etc.

Same here. Just because someone may be a world-class guru in programming, doesn't mean jack squat about his knowing anything about game design. Maybe he does, maybe he does't. It's an unrelated skill.

Re:Non sequitur? (1)

AKAImBatman (238306) | more than 8 years ago | (#14811328)

A game is _not_ just the code implementing it, and what made, say, KOTOR fun _isn't_ the clever lightsaber rendering code or the NPC dialogue code.

I'm not saying it is. However, the the graphics, the way the dialog works, the interaction between the characters, the mechanics of the game, etc, etc, etc. are all key to making it "fun". Any idiot can say, "I think we should have a game where the player can be a Jedi Knight. He can interact with other Knights, jump in an X-Wing, and handle his Light Saber like a real Jedi!"

The problem of Game Design is taking that abstract concept and executing it as a living, breathing game that will entertain the players. Just as an architect can't design a building if he doesn't know how to keep it from being architecturally unsound, someone without experience in development can't know how to make the mechanics of a game work. Simply throwing around terminology with explanations won't provide the combination of experience and creativity necessary. It will only allow you to write a high sounding resume.

I see no problem separating a tradesmaster from a completely _unrelated_ trade. The architect who designed a bank building is _not_ an expert on banking or economics.

Except that game design is NOT unrelated to game development. The designer of the bank building doesn't know how a bank works. However, he does know how to build a structure, and he's going to work with the banker to learn what the needs are. Working with the banker, he's going to learn that there is a much greater need to move cars through the drive-up than through the lobby. The lobby actually needs to devote more space to sitting down with customers to discuss loans and new accounts. So the designer takes this information and applies engineering principles to optimize these different needs, and looks at the entire pipeline to make sure each of these needs are met. This may not actually mean "bigger == better". In fact, the problem may be that the tellers have too much space to work with, and need things closer to move the traffic through quicker. It may mean that the filing department is too far from the lobby to be effective in handling loans and new accounts. It may mean that a lot of adjustments need to be made that only someone skilled in engineering can account for.

Now what would happen if the bank manager was asked to design the building? Well, he'd probably think that it needed a drive-up, a place for communicating with customers, a spot for the vault, etc. But he wouldn't understand the engineering side of things, and would thus fail to optimize any paths. In fact, he may create quite a few bottlenecks through naively filling in sections with the individual components. He might make the drive-up larger, thereby exasperating the large work area problem he had before. He might move the filing area even farther away in an attempt to increase the lobby volume. He might do a lot of things that are counterproductive to his actual goal. Why? Because he's not an engineer.

You don't ask a person inexperienced with gaming technology to design a game any more than you ask a bank manager to design a building. It's just that simple.

Re:Non sequitur? (1)

typidemon (729497) | more than 8 years ago | (#14814911)

Gaming has always been about what "feels" right.

Which is the art behind game development. Note that Art and Design while related are not the same thing. Design is about planning and affordance, Art is about expression, intuition and emotion.

A good game could be a few tweaks away from a really horrible game,

That's the problem. Game Development is filled with Artists, Scientists and hacks. People often don't really know what people want, how to find out what they want or even what makes something popular.

but it's impossible to know unless someone with a creative side jumps in and adds their creative side to it.

Design is incredably creative, but it isn't art. Also, you seem to assume that formal education limits creativity. In my experiance (as a Designer), nothing is further from the truth. There is a science to a lot of design that affords designers a depth of knowledge that is very hard to achieve without formal education.

I get what you are saying about the book, but I just think you should be more careful about the phrasing of your creative is simply creative point of view

Re:Non sequitur? (1)

TD-2779 (840642) | more than 8 years ago | (#14810972)

Is this about "Patterns in the Design of Games", or "Design Patterns in Games"?

I guess it's the arrogant programmer in me that thought it was the 2nd. ;)

Re:Non sequitur? (0)

Anonymous Coward | more than 8 years ago | (#14812276)

> Even if you're of the arrogant school of thinking that programmers are the alpha and the omega, and everyone else is an idiot...

Au contrare, I am a programmer, I assure you we are mentally masturbating monkeys who can type. The good ones shoot off a line of code as often as a monkey 8)

We never get anything right, always have bugs, never make deadlines, and the marketing people and business types are always upset with us for one reason or another.

That's why we get paid the big middle class bucks. It's hard to be unloved.

The arrogance is a self defense mechanism for us weak minded screwups. We act big because we feel small and get tailgated in our small japanese cars by SUV's.

Even you appear to hate us 8*(

-AC

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14810755)

I found "Tricks of the Game Programming Gurus" to not be that helpful. On the other hand, I still use "The Zen of Graphics" (1996, Abrash) (just a subset of games, true, but probably the trickiest one to do well) from time to time even today. I don't generally see the point of books that abstract themselves away from the process so that you're looking at little more than sweeping concepts with a few cheap examples behind them.

Learning the art of developing a good graphics engine from the discoverer of Mode X and a Quake developer (when Quake was new) seemed far more applicable. Also things like how to optimize *properly*, discussion of what the human eye will and won't notice, and a wonderful rant (which I still quote from time to time) on the concept of ownership of ideas make that book stand out much more strongly in my mind.

Re:What Incredible Progress (1)

timster (32400) | more than 8 years ago | (#14810957)

I don't generally see the point of books that abstract themselves away from the process so that you're looking at little more than sweeping concepts with a few cheap examples behind them.

And I don't generally see the point of graphics. The last video game I bought was a used copy of M.U.L.E. for the NES. Now THAT is a game. Quake was just a boring movie where you could move the camera around.

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14811175)

How long would everyone in TAMS have played FF7 were it rendered with the same engine as FF1? Would they even have heard of it? Another way to put it: what game in the top 100 sales has poor graphics?

Yes, gameplay and plot are the most important thing to making a game enjoyable, long term. But when presented with a choice between a purdy game and an ugly one, what does the Average Person(tm) pick up?

Re:What Incredible Progress (1)

Peganthyrus (713645) | more than 8 years ago | (#14813421)

Which one are they going to come back to ten years later - the one that sold based on its hot graphics that look laughably dated now, or the sleeper hit that might not have been pretty, but is tons of fun to play?

Re:What Incredible Progress (1)

AKAImBatman (238306) | more than 8 years ago | (#14811123)

I found "Tricks of the Game Programming Gurus" to not be that helpful. On the other hand, I still use "The Zen of Graphics" (1996, Abrash) (just a subset of games, true, but probably the trickiest one to do well) from time to time even today.

I find that rather amusing, actually. I ran into the exact opposite. I found Abrash's works to go out of date and relevence much faster than LaMothe's more comprehensive, but perhaps less detailed, books. :-)

I don't generally see the point of books that abstract themselves away from the process so that you're looking at little more than sweeping concepts with a few cheap examples behind them.

Eh? I hardly think that Tricks of the Game Programming Gurus was that abstract. Certainly not focused on the 3D engine for Quake (which it predated by a couple years), but it does lay the groundwork in a developer's mind for the entirity of the gaming industry. Sure, I've outgrown the information the book contains, but the ideas it helped me understand back in '94 (Video Scanning, Sprites, Parallel vs. Perspective, an intro to 3D Mathematics, etc.) formed a solid basis for my works today. Most of the info learned translated into the 3D world because he taught the most important thing a programmer can possibly learn about gaming: Stop worrying about how others did it (if I hear one more "How do I code Quake III?" question, I'm going to throttle someone), and figure out your own method.

I suppose that the message really hit me more because of my background as a home schooler. LaMothe's message built on top of the message I grew up with: Education is not about what you know, it's about learning how to learn. The former stops when school is over. The latter lasts a lifetime.

Also things like how to optimize *properly*

I actually cringe when I think about half the stuff that Abrash taught. Sure, it was necessary back then (you didn't have cycles to waste), but I fear that far too many programmers came away with the idea of premature optimization rather than a far more effetive method of optimizing:

Step 1: Use a faster Algorithm.
Step 2: Make it work.
Step 3: THEN look to optimize only the most critical sections.
Step 4: Repeat as necessarily.

Or as the famous "first rule of optimization" goes, "Don't." Quickly followed by the second rule (for experts only), "Don't yet."

discussion of what the human eye will and won't notice

I've learned that this has to be revisited every few years. The human eye is a very tricky thing. As technology progresses, we need to reevaluate what works well with current rendering technology. Certainly, assuming that you MUST maintain a stable, VSynced framerate rendered 100% offscreen is a bit naive (though it did look so smoooooth on those old Pong machines, didn't it?), but there's so much more to fooling the eye. Especially since the topic is far reaching, and covers all types of graphics. Not just games.

In any case, I'm getting off track here. There used to be some really great books on game programming. There are still probably a few of them (I keep hearing good things about the Gems series), but I'm not certain I'm all that impressed by the majority of the market. Especially when compared to the really great books we grew up on. :-)

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14811464)

focused on the 3D engine for Quake

It went into general 3D concepts in extreme detail, especially focused on the "why". The only reason much of it isn't as important any more is because one can now rely more on things like OpenGL.

Video Scanning

Abrash went much more in depth. Remember, Abrash was the first person to publish Mode X, and possibly the first to ever encounter it (he takes caution to credit anyone who might have discovered it before him but kept it to themselves).

Sprites

Abrash was much more in depth, and also this is much more irrelevant now. This is the guy who wrote the sprite engine for the Commander Keen games.

3D Mathematics

Abrash's 3d mathematics sections were *far* superior, even getting into B-trees.

You didn't have cycles to waste

You still don't have cycles to waste, or you get passed up by your competitors.

more effective method of optimizing

Perhaps you're not remembering the book well, but that is what he taught: optimize only the core loops, and apply what he refers to as both "left brain" and "right brain" optimizations.

Right brain optimization is rote; looking at the current code, and figuring out where you can wrench cycles away from the algorithm. Left brain optimization is a step back; trying to reconcieve the problem in different lights. Oftentimes just the thought that something *is* possible to run faster is enough to spur a person to make it faster than they otherwise could have. A good example is the case of when he was on a team developing a graphics card, and they heard a rumor that their competitor's upcoming card would have some ungodly performance for the time. They heard that it had something to do with a fifo. So, they thought about it for a long time, and managed to barely beat them by adding in a write fifo. It turns out that their competitors had actually used a read fifo and didn't have anywhere near the rumored performance after all. He cites a number of such examples, culminating in the process of reducing a textured polygon draw routine from over a hundred cycles per pixel down to 3-4 cycles per pixel.

Knowing how to do that to your core loops (and where *not* to optimize) is important for high performance code.

As technology progresses, we need to reevaluate what works well

This is one section that is a lot more general. I loved his style - begin with abstract, then focus down further and further until you're squeezing every last bit of life out of a specific algorithm. I would recommend that you re-read the start of Ch. 36, "Sneakers in Space", which references, among other things how the fact that one of the space ships in "Return of the Jedi" was a sneaker, and almost nobody noticed until they were told. The key is to let your performance slip on the types of things that people won't notice and to hold it on things that they will notice. Especially critical is that motion allows you to be sloppier, while slowly changing scenes or elements must be taken care of much more gingerly. The same applies to background vs. foreground elements. A person piloting a spaceship through an asteroid belt might very well not notice even if you spell out dirty words with the stars in the background because they'll be so intent on dodging the asteroids.

Re:What Incredible Progress (1)

AKAImBatman (238306) | more than 8 years ago | (#14811721)

Abrash went much more in depth. Remember, Abrash was the first person to publish Mode X, and possibly the first to ever encounter it (he takes caution to credit anyone who might have discovered it before him but kept it to themselves).

No he didn't. He went into cute tricks type of depth that only mattered at the time. Mode X is irrelevant to Video Scanning. That's merely a matter of reprogramming the VGA card, something that the card wasn't supposed to be able to do. (Unix Framebuffers were usually reprogrammable rather than having a fixed set of "modes", so it was not a new idea. Just a hack to let the VGA card do the same thing.) What LaMothe taught was how the video subsystem worked. That "how" stretches back to the very beginning of video games, where the core idea was just to produce a scan signal that represented the game. Fast forward from 1975 to 2006 and you find that the scan signal is just as important, we've just been abstracted away from it. For game developers, this can actually be detremental to their ability to produce games.

With what I learned from LaMothe, I was able to build upon that knowledge [wikipedia.org] , and learn to work with the game system rather than against it.

Abrash was much more in depth, and also this is much more irrelevant now. This is the guy who wrote the sprite engine for the Commander Keen games.

Sprites are not irrelevant. There are still many 2D games that use the original concept. 3D games use the concept as well, except they're usually upgraded to 3D models (aka "actors") rather than 2D images. The cutesy tricks that Abrash taught, however, are out of date. For example, what good are compiled sprites* to anyone? Given a modern graphics pipeline, they're guaranteed to be slower than just pumping the RGB data. That was fun stuff to read in Dr. Dobbs, but not really anything that has stuck with us.

The key is to learn the basic concepts, and build yourself a foundation. The actual implementations are transient, and just not important in the long run.

Abrash's 3d mathematics sections were *far* superior, even getting into B-trees.

As I said, Abrash's book was 2 years after Tricks of the Game Programming Gurus. Quake didn't exist yet, ergo true 3D engines were pretty rare in gaming. (Doom used BSP trees, but that was something of a secret when it first came out.) I actually learned about BSP trees through the Internet before '96, and the follow up to LaMothe's book (More Tricks of the Game Programming Gurus) covered the concept. (The follow-up had a lot of good info, but it lacked the solid foundation the first book gave. Plus, it wasn't written by LaMothe.)

Perhaps you're not remembering the book well, but that is what he taught: optimize only the core loops, and apply what he refers to as both "left brain" and "right brain" optimizations.

I also remember how much time he spent on the low-level optimizations in his books. He tried to explain how to properly optimize, but he then took the reader through all the complex low-level optimizations, and focused very heavily on them. The result is that the take away for many developers was too fixated on the low-level rather than the high level. The consideration of (using an oversimplified example) inventing the Portal Engine as a way of eliminating the need for BSP trees was downplayed in favor of looking only as ways of making the BSP tree faster. LaMothe drilled in the idea, "A 12 year old may invent a better algorithm than a PHD in mathematics, just because he doesn't know any better." (From memory, so I may be paraphrasing.)

I'm not saying that Abrash's writings weren't useful. For their time, they were exceptionally useful for the area of expertise that Abrash wanted to cover. But get outside of that area and suddenly you realize that you have no foundation to build on. Thus his books were best to read if you already *had* a foundation and just needed some inspiration to improve your code. :-)

* Compiled Sprites was a trick whereby the image data would be converted to a set of drawing commands. Fewer cycles were used because the CPU didn't need to move memory. You were literally streaming the data through the processor instead.

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14812997)

First off, to sum up the below: from my viewpoint, TGPG covered almost nothing that I didn't already know in seventh grade, with only a couple exceptions - and I had never read a programming book (apart from an intro to C) before that. That's really saying something. Zen covered brand new material in almost every section, much of which (apart from programming video cards) I still use today.

No he didn't. He went into cute tricks type of depth that only mattered at the time. Mode X is irrelevant to Video Scanning.

Please define what you mean by video scanning. I only brought up mode X to give an example of the depth of his knowledge on the subject of how video cards work compared to LaMothe. I was going on the assumption that you were referring to topics related to syncing with the scan rate of the monitor, which he gets into quite well in Zen.

2 years after

Are you going to claim that 3d mathematics made leaps and bounds in that time? Not even close. TGPG covered only the most basic aspects of matrix rotation. Zen covered not only matrix rotation, but went into its derrivation (in several ways), discussed how to incorporate transformations of various kinds into the matrix, how to eliminate the matrix all together, etc. A way, way, better section, just on that particular 3d topic. But it hardly stopped there.

Sprites are not irrelevant

I said that they were mostly irrelevant. They used to be everything. Now they're bit issues. Sprite blitting speed is not very important at all; most games use sprites simply as interface elements, although there still are some 2d games (heck, I work on one ;) Nethack-vultures, although due to personal issues I haven't been active in the past couple months).

cutesy tricks are out of date

Oh really? Where in TGPG did they cover Wu antialiasing, the cornerstone of all modern sprite smooth scaling? Where did they cover much of *anything* about stretching, especially the issues involved in mapping to polys (and not only the technical ones, but also the practical ones)?

Doom used BSP trees ... something of a secret

I remember using the doom map editor, which came out shortly after Doom; it had to rebuild the BSP trees whever you wanted to save the level. Irregardless, check out "Predeterming Visibility Priority in 3-D Scenes" SIGGRAPH '79, pp 175-181. That's 1979. It was used in professional raytracers well before Doom. Of course, since LaMothe hardly wrote anything of note apart from books (yes, he had some cheesy games that nobody played and a couple of simple toolkits), I'm not surprised that he was unfamiliar with it.

I also remember how much time he spent on the low-level optimizations

He did it in a derrivation style. For each concept, he started out extremely abstract, focusing on "what is the task?" (after a relevant anecdote, often very applicable). Then he came up with the basic algorithm that one would arrive at after thinking about the problem for a while. Then he progressively improved the algorithm itself ("left brained optimization") further and further. A good example of this is going from point drawing with the intuitive floating point remainder, to integer line drawing (fixed point arithmetic for the remainder), to using an overflowing integer to track the remainder (so that it automatically overflows and resets itself when the line needs to shift sideways), then into assembly so that he could check the overflow bit instead of performing an external overflow test, then assembly optimization (such as classifying the line into various categories based on its slope). You get to watch the algorithm trim down and watch the thought processes that lead to the acceleration of the algorithm. Very few of these algorithms have been outmodded by hardware changes, and most are the standard cores of 3d engines.

downplayed the portal engine

That's because the Portal Engine was only a theory then, while BSP trees were real. Not like LaMothe covered either, of course, or anything close to it. The gaps in LaMothe's book could swallow a supertanker; it was just a bunch of junky code and way overbroad examples.

"A 12 year old may invent a better algorithm"

I knew others, and was, a 12 year old programmer at one point. My algorithms were awful. Oh, they were horribly clever given my knowledge base. For example, I accomplished 3d rotation by determining the angle from the camera to a point using arctangents (thanks to learning SOHCAHTOA in sixth grade), then I would add the rotation in (suffering gimball locking, of course), then recalculating the position with sines and cosines. It was horribly slow. None of my friends did more than reinvent the wheel, badly. 12 year olds don't come up with great ideas. They come up with awful ones, and write bad code to boot. The people who wrote the *real* industry-changing engines were horribly educated. Abrash, Carmack, et al were incredibly educated, and that's why they made a fortune in innovative games while LaMothe never did.

By the way, in respect to that algorithm I invented in (seventh?) grade: LaMothe told me how to do the normal style 3d rotation with matrices (one of the few things I learned from that book). However, it was Abrash who actually got me to understand how it worked and to do it quickly, which actually gave me viable 3d engines. And I still use that info to date (my first project on my current job, in fact).

I much prefer an Abrash quote about the "invention of algorithms":

Our part of the world is changing, and I'm concerned. By way of explanation, three anecdotes.

Anecdote the first: In the introduction to one of his books, Frank Herbert, author of Dune, told how he had once been approached by a friend who claimed he (the friend) had a killer idea for an SF story, and offered to tell it to Herbert. In return, Herbert had to agree that if he used the idea in a story, he'd split the money from the story with this fellow. Herbert's response was that ideas were a dime a dozen; he had more story ideas than he could ever write in a lifetime. The hard part was the writing, not the ideas.

Anecdote the second: I've been programming micros for 15 years, and writing about them for more than a decade and, until about a year ago, I had never-not once!-had anyone offer to sell me a technical idea. In the last year, it's happened multiple times, generally via unsolicited email along the lines of Herbert's tale.

This trend toward selling ideas is one symptom of an attitude that I've noticed more and more among programmers over the past few years-an attitude of which software patents are the most obvious manifestation-a desire to think something up without breaking a sweat, then let someone else's hard work make you money. It's an attitude that says, "I'm so smart that my ideas alone set me apart." Sorry, it doesn't work that way in the real world. Ideas are a dime a dozen in programming, too; I have a lifetime's worth of article and software ideas written neatly in a notebook, and I know several truly original thinkers who have far more yet. Folks, it's not the ideas; it's design, implementation, and especially hard work that make the difference.

Virtually every idea I've encountered in 3-D graphics was invented decades ago. You think you have a clever graphics idea? Sutherland, Sproull, Schumacker, Catmull, Smith, Blinn, Glassner, Kajiya, Heckbert or Teller probably thought of your idea years ago. (I'm serious-spend a few weeks reading through the literature on 3-D graphics, and you'll be amazed at what's already been invented and published.) If they thought it was important enough, they wrote a paper about it, or tried to commercialize it, but what they didn't do was try to charge people for the idea itself.

A closely related point is the astonishing lack of gratitude some programmers show for the hard work and sense of community that went into building the knowledge base with which they work. How about this? Anyone who thinks they have a unique idea that they want to "own" and milk for money can do so-but first they have to track down and appropriately compensate all the people who made possible the compilers, algorithms, programming courses, books, hardware, and so forth that put them in a position to have their brainstorm.

Put that way, it sounds like a silly idea, but the idea behind software patents is precisely that eventually everyone will own parts of our communal knowledge base, and that programming will become in large part a process of properly identifying and compensating each and every owner of the techniques you use. All I can say is that if we do go down that path, I guarantee that it will be a poorer profession for all of us-except the patent attorneys, I guess.

Anecdote the third: A while back, I had the good fortune to have lunch down by Seattle's waterfront with Neal Stephenson, the author of Snow Crash and The Diamond Age (one of the best SF books I've come across in a long time). As he talked about the nature of networked technology and what he hoped to see emerge, he mentioned that a couple of blocks down the street was the pawn shop where Jimi Hendrix bought his first guitar. His point was that if a cheap guitar hadn't been available, Hendrix's unique talent would never have emerged. Similarly, he views the networking of society as a way to get affordable creative tools to many people, so as much talent as possible can be unearthed and developed.

Extend that to programming. The way it should work is that a steady flow of information circulates, so that everyone can do the best work they're capable of. The idea is that I don't gain by intellectually impoverishing you, and vice-versa; as we both compete and (intentionally or otherwise) share ideas, both our products become better, so the market grows larger and everyone benefits.

That's the way things have worked with programming for a long time. So far as I can see it has worked remarkably well, and the recent signs of change make me concerned about the future of our profession.

Re:What Incredible Progress (1)

AKAImBatman (238306) | more than 8 years ago | (#14814142)

First off, to sum up the below: from my viewpoint, TGPG covered almost nothing that I didn't already know in seventh grade,

Putting aside the fact that I *was* in seventh grade in 94, not everyone was in the same league, or even is today. :-)

with only a couple exceptions - and I had never read a programming book (apart from an intro to C) before that.

I find it a little hard to believe that you had zero resources, yet still knew how to load PCX files, kick the system into Mode 13h, understood assembly language, and could write up a high performance 3D graphics engine with proper depth sorting with nothing more than the Borland graphics library. (raises eyebrow) That would be quite an achievement. I have a feeling that you were programming WITH resources long before you got to C.

From 8 to 12 years old, a GW-BASIC manual and a few Usborne books containing type-it-yourself BASIC programs (that were for obscure BASIC dialects) were my only companions. If I didn't have so much other info stuffed in my head, I could probably recite you the entire GW-BASIC manual from memory. :-)

At 12 years old I learned C from a rather fat book on the subject. But there was nothing forthcoming after that. I knew C and some assembler (from reading the manual), but I would acquire myself a copy of the Pink Shirt book (Peter Norton's guide to programming the PC) until several years later. Picking up a copy of TGPG was a God-send. A solid, theoretical foundation from which to work from was what it gave me. I could finally stop looking for the magical shareware disk with the code I needed. (Yes, I actually wrote the Shareware Association and asked them if they had any code or recommendations demonstrating image loaders and scrolling code. I feel a little sheepish about that now, but what was a kid supposed to do?)

I spent quite a bit of hard-earned money on TGPG ($50 out of my take home of about $200 monthly from working at the local McD's!)

Please define what you mean by video scanning.

I mean a complete theory of operation of how video screens work. Understanding that is key to video gaming. Did you know that the Atari 2600 only buffered a single scanline? And not very well at that. You had three pixels for every one clock cycle, so you had to work out the scanline during the HSync and while it was drawing. You had about 20 bits for the entire line of the playfield, plus a byte for each of the two sprites, and a bit for a ball. Not much to work with, but even the Nintendo and Super Nintendo didn't improve upon this design all that much. :-)

I only brought up mode X to give an example of the depth of his knowledge on the subject of how video cards work compared to LaMothe. I was going on the assumption that you were referring to topics related to syncing with the scan rate of the monitor, which he gets into quite well in Zen.

LaMothe mentioned Mode X as well. He just didn't get into it because he was building a foundation, not trying to teach you every modern trick. With a foundation, you can figure out many of the other tricks yourself. Heck, I'd figured out Perspective Affine Texture Mapping before it became a term in the industry (without reading Abrash, mind you).

Oh really? Where in TGPG did they cover Wu antialiasing, the cornerstone of all modern sprite smooth scaling? Where did they cover much of *anything* about stretching, especially the issues involved in mapping to polys (and not only the technical ones, but also the practical ones)?

Antialiasing wasn't covered, because it was too costly to perform on the hardware of 1994. The chapter on 2D graphics, however, covered scaling, stretching, skewing, rotating, etc. The poly mapping (which was actually not truly covered, you're thinking of the sliver scaling) was in the chapter on raycasting.

Irregardless, check out "Predeterming Visibility Priority in 3-D Scenes" SIGGRAPH '79, pp 175-181. That's 1979. It was used in professional raytracers well before Doom. Of course, since LaMothe hardly wrote anything of note apart from books (yes, he had some cheesy games that nobody played and a couple of simple toolkits), I'm not surprised that he was unfamiliar with it.

Are you really thinking of 1994 here? Name a SINGLE example of video gaming that used BSP trees (other than Doom, which was cheating like hell - but in a good way - with BSP trees) in 1994? True 3D engines were too slow for the hardware of the day. I don't know how to get that through. He didn't cover it because it had nothing to do with gaming. He DID cover the basic theories behind 3D graphics, gave the calculations, explained how to matrix compute the vertices, gave the Painters Algorithm, etc, and left it at that. That was all that was relevant in 1994.

You seem to forget that in 1994 most users had a 386, Windows 95 hadn't been released, Doom was the most sophisticated game ever released (and a lot of people couldn't run it), and it had literally been released 6 months eariler. Remember, this was the days of Shareware distribution. 6 months was just as Doom was hitting its stride!

By 1996, everyone had either a high end 486 or Pentium, Windows 95 had been released, Doom was old hat, the Internet had caught on, Wing Commander III was out, and 3DFX was paving the way for the future of 3D graphics cards. That was one hell of a difference!

Now would you like to explain how you got info on BSP trees in mid 1994 without having access to anything other than a book on programming C? I really would like to know how you pulled that off, because I would have given my right arm to have research papers on 3D graphics available to me.

For example, I accomplished 3d rotation by determining the angle from the camera to a point using arctangents (thanks to learning SOHCAHTOA in sixth grade), then I would add the rotation in (suffering gimball locking, of course), then recalculating the position with sines and cosines. It was horribly slow.

Mmm. Sounds pretty familiar. The biggest epiphany for me was the idea that the world rotated around the camera, not the other way around. That was pretty deep stuff at the time, especially since Ray Tracers (the only exposure to true 3D I'd managed) do actually move the camera rather than the world.

That doesn't mean I wasn't a clever 12 year old. I'd figured out how to write some pretty good AI for Tron, for example. I just lacked a basis with which to build more complex stuff on. TGPG gave me that, thus why I still recommend it to new game programmers. I'd have to mad to send them to Abrash's book first. Sure, his book is free on the Internet now, but it just doesn't give a theoretical foundation to work from.

And for what it's worth, I kicked ass in Trig thanks to TGPG. Nothing says, "Yes! I want to do Math!" like having a real world applicaiton. :-)

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14817702)

Putting aside the fact that I *was* in seventh grade in 94, not everyone was in the same league, or even is today. :-)

Hmm, looking back at the years, it appears I was in eighth. :)

I find it a little hard to believe that you had zero resources, yet still knew how to load PCX files

And yet I did! Want to see my old PCX loader? A friend gave me some basic info, and I figured out the rest. My first program to use it was a stereogram generator.

kick the system into Mode 13h

A friend got me some sample code that did it. I think they got it from Tricks of the Graphics Gurus, although I'm not sure.

understood assembly language

You know, I'm not sure where I learned assembly from or when. I think I started learning from Borland compiler dumps, but didn't really get very into it then. I forget when I did.

and could write up a high performance 3D graphics engine

LaMothe described high performance 3D engines? Come on, his engines were horrible. Abrash described high performance engines. LaMothe described low performance engines. I did have a low performance engine before TGPG, and as mentioned in the previous post, the only thing his book helped me with was that it let me get rid of my old rotation algorithm.

I have a feeling that you were programming WITH resources long before you got to C.

My resources were my friends, help files that came with programs, and creativity.

From 8 to 12 years old, a GW-BASIC manual and a few Usborne books containing type-it-yourself BASIC programs (that were for obscure BASIC dialects) were my only companions.

I begged my parents to get me a C compiler and an intro to C book so that I wouldn't have to keep using QBasic ;)

LaMothe mentioned Mode X as well. He just didn't get into it becausehe was building a foundation, not trying to teach you every modern trick.

But he didn't give you a good enough foundation to work with - only 320x200 if I remember right. While the video card portion of Zen is obsolete by now (it's only a quarter of the book, and part of what it covered still applies, just not the implementations), for years it gave me the core of my graphics libraries that I would use in my programming.

Antialiasing wasn't covered, because it was too costly to perform on the hardware of 1994.

Not true. Not only was it standard on every raytracer at the time and most graphics editing programs (its theory was laid out in 1974), the Sega Genesis (1988) used antialiasing internally, and of course Abrash used it in the Commander Keen series. Many game developers did at the time. In 1994, we were seing widespread the second generation of "King's Quest" style games (such as my favorites, the Kyrandia series, although the Lucasarts ones were great too). These games often relied on sprite scaling, and without antialiasing, your characters would turn to garbage if they moved too far into the background (first gen games of this type often either avoided scaling all together (perspective be damned, arrr!), used multiple fixed-sized sprites, or let it turn to garbage; the second gens used antialiasing). The thing about properly implemented (See Abrash for how :) ) Wu antialiasing is that it has little cost penalty associated with it.

The chapter on 2D graphics, however, covered scaling, stretching, skewing, rotating, etc.

With horrible performance, and never applied to general-purpose polygon mapping, as I stated. LaMothe taught me nothing I hadn't already figured out with respect to that, while Abrash made my eyes shimmer as I read :)

Name a SINGLE example of a video game that used BSP trees

The fact is that Doom *did* use them, it was known at the time, and LaMothe didn't cover them. Of course, he didn't even cover raycasting as I recall, so he would have been obsolete in 1992.

LaMothe taught some 3D, but what he taught would barely even be able to run the graphics of his day on computers made eight years in the future. He didn't teach fundamental principles of effective 3d programming which still apply to date, which were known at the time, because he wasn't involved in any market-competitive games. He didn't know what he was doing. Abrash did, and taught, well.

how you got info on BSP trees in 1994

At the time, all I knew was that they existed; I didn't know what they were. The doom map editor had to regenerate them when you made a level (I had a lot of fun with the Doom editors - that brings back memories :) Homing rockets with billboards stating "Have a nice day!" on them was probably my biggest accomplishment (the rocket launcher was edited to fire exploding enemies which would attack each other (so they would home) and had slow turning rates so that they couldn't loop back on you) ).

I figured out how to write some pretty good AI for Tron, for example

That's kind of funny. My best code at the time was probably my pong AI. I'm still kind of proud of it; it really felt like you were playing a human, and was much better (in terms of realism) than those I had encountered in professional games that had pong in them. I guess AIs have a smaller learning curve than graphics.

Re:What Incredible Progress (0)

Anonymous Coward | more than 8 years ago | (#14810898)

Intelligent File Format eh?

Looks pretty stupid to me. What problem does it solve? Payloads can still be as obfuscated as they ever were. Looks to me like the only gain is the ability to have a heirarchy of data, which most languages support serializing out to a file anyway.

Besides, having to install a bloated and proprietary closed source JVM on every computer sure doesn't sound like a viable solution to anything to me.

Re:What Incredible Progress (1)

Rei (128717) | more than 8 years ago | (#14811663)

An alternative that we use (for voxel-based images) is to have an XML wrapper (BXH) associated with a file that describes how the contents of the file are arranged. It shows where important metadata of that format is kept, and everything else under the sun that might be important - byte order, slice arrangement, voxel size, orientation, compression, you name it. if you support the BXH standard, you can read essentially any voxel-based image that has such a wrapper without having to have a reader for that particular format.

Re:What Incredible Progress (1)

AKAImBatman (238306) | more than 8 years ago | (#14811881)

Rei, he's trolling. He looked at my sig (a suggestion for improving the state of disparate formats) and instead of joining in the discussion over there, decided to add a bunch of throw-away comments about "Java Suxorz!" in an attempt to get fed.

* AKAImBatman plants a sign in the ground

DON'T FEED THE TROLLS

:-P

Re:What Incredible Progress (1)

Trixter (9555) | more than 8 years ago | (#14813105)

"1994: The computer scientist and game programmer Andre LaMothe writes the quintessential book on game programming, "Tricks of the Game Programming Gurus". The book is dense with useful information, humor, and actual theory on game programming."

I hope you're kidding. Have you actually read the book? It may be hard to interpret 12 years later, but at the time it was published, it was a day late and a dollar short. It was state-of-the-art for 1992 -- a shame, since the book was published in 1994. It wasn't worthless, but it wasn't helpful.

I remember! (1)

jokestress (837997) | more than 8 years ago | (#14810274)

"a loaf of bread, a container of milk, and a stick of butter." Nice Sesame Street reference! Haven't seen one of those here since someone compared Jack Thompson to Oscar the Grouch...

I may be wrong... (1)

Belial6 (794905) | more than 8 years ago | (#14811228)

I may be wrong, but I believe the reference is to a very old Porky Pig cartoon. The one where he was sent to the store for "a loaf of bread, a container of milk, and a stick of butter.", and then got sidetracked and went to the movies instead.

Bow before my questionable knowledge of useless trivia!!!!!

Re:I may be wrong... (1)

circusboy (580130) | more than 8 years ago | (#14811788)

I'm pretty sure you're wrong, but it's possible the sesame street episode followed a warner bros. cartoon. I recall the sesame street cartoon, involving a young child being sent to the store for that shopping list, and as he went to the store he passed a few distractions, (I remember a fire truck being one) and by the time he got to the store he had completely forgotten what to get.

I don't remember how it concluded, except for the fact that he eventually did remember and brought the groceries home to mother... I think it was intended as a lesson in ways to remember things,

I remember the family in the cartoon as being black, anyone else remember? and the animation a fairly loose watercolor style... It's interesting to think about the unlikeliness of a similar situation occurring today. (i.e. often where you would find a corner store, you might be unlikely to send your kid to it alone. (if for nothing else, the possibility of a child endangerment lawsuit...))

Re:I may be wrong... (1)

Thuktun (221615) | more than 8 years ago | (#14812362)

My memory of it coincides with yours.

Re:I may be wrong... (1)

robkill (259732) | more than 8 years ago | (#14812753)

There definitely was a 1930's (black and white) cartoon where Porky Pig was sent to the store. His repeated line to jog his memory was "A loaf of bread, a quart of milk, and come home right away." He passes a movie theater with the sign reading "Kids admitted free!" He repeats "A loaf of bread, a quart of milk, and kids admitted free." two or three times before what is on the sign registers with him, and he then goes to the movies. Since Sesame Street came out in 1969, Porky Pig preceded it by some 30 years.

Re:I remember! (0)

Anonymous Coward | more than 8 years ago | (#14811291)

I was wondering if I halucinating when I saw that and thought "Sesame Street" My wife has no clue where that is from when I quote it, but to give it justice it should probably be: "...a loaf of bread, a container of milk, and a stick of butta."

my eyes!!!! (0, Troll)

Clover_Kicker (20761) | more than 8 years ago | (#14810305)

> It is perhaps somewhat presumptuous to disagree with someone
> like Greg Costikyan, but nevertheless I have my doubts as to
> the book's overall utility.

I don't think this book is useful.

> While this book certainly seems like the sort of be-all,
> end-all of game design theory, what it amounts to is little
> more than a list, each item on the list referring to the other
> items like bloggers hawking each others' hyperlinks.

This book is little more than a cross-referenced list.

Please pull the thesaurus out of your ass and get to the point.

This isn't junior high english class. You should be communicating ideas, not trying to show how clever you are.

Re:my eyes!!!! (1)

kadathseeker (937789) | more than 8 years ago | (#14810430)

How ironic that a class designed to teach proper use of the language (which would be communication, one would think) does the opposite. Eschew obsfucation!

If spleing end grammer are coreckt, then an developped vocabularly be no ass important is.

Re:my eyes!!!! (1)

flyingsquid (813711) | more than 8 years ago | (#14810542)

Sophisticated ideas can be difficult to understand, so you can trick some people into thinking even your dumbest ideas are clever and sophisticated by making them impossible to understand.

Academics are some of the worst offenders when it comes to this, which is one reason why their papers are so dense and difficult to read, even for other academics. I try not to pull this kind of crap... I figure, anybody impressed by your vocabulary, rather than the content of your thoughts, isn't really worth impressing.

Re:my eyes!!!! (1)

Rei (128717) | more than 8 years ago | (#14810877)

Ok, lets look at the first three papers on NASA's site that I run into:

Novel Composite Membrane for Space Life Supporting System [nasa.gov]

Novel manufacturing process for unique mixed carbide refractory composites [nasa.gov]

Novel Tunable Dye Laser for Lidar Detection [nasa.gov]

I hate when people gripe about generalized "academics" just because they're not familiar with the topic being discussed. Yes, there *are* things to criticize about peer review, and which some people (such as Sokal) have abused amusingly. But such broad sweeping generalizations are grossly unfair to the academic community as a whole. If you had to explain every single word that you used, your wordcount would go up a hundredfold. Applied sciences deal with many concepts that simply cannot be summed up concisely.

What word would you use to replace "lidar"? Do you want the author of the last paper to have to write out "holographic polymer dispersed liquid crystals" each time instead of HPDLC? Should the second author have to define STTR when the work is being done as part of a SSTR project? Do they need to explain what a "hafnium/silicon based carbide composite" is for people unfamiliar with some of those words? What about "microporous aminosilicate membrane"?

Technical terminology isn't used to try and sound impressive (99% of the time). It is used because it is the right terminology.

Re:my eyes!!!! (1)

AKAImBatman (238306) | more than 8 years ago | (#14812223)

I hate when people gripe about generalized "academics" just because they're not familiar with the topic being discussed.

He's not griping about Academics in general. He's griping about people who overcomplicate their language as an alternative to content. Academics can be some of the worst because they try hard to gain funding or credibility even when they're fresh out of things to say or invent. So they overcomplicate their speech to intentionally make a mountain out of a mole hill. Not all academics, mind you, but they are in the best position to abuse the English language for their own purposes.

P.S. Yes, I actually understand those papers. They're understandable because they use the technical terminology as necessary, not just because they can.

P.P.S. On the other hand, why are they all prefixed with "Novel"? I mean, if they're novel technologies, shouldn't that be a determination made by the reader? Did NASA's contractors run out of adjectives or something? Or are they writing a novel on technologies that the novel will make appear quite novel in their otherwise non-noval applications in a novel new field? That is a novel idea! :-P

Re:my eyes!!!! (1)

Rei (128717) | more than 8 years ago | (#14813017)

They're all prefixed with "novel" because I literally found them via, at google:

site:nasa.gov novel :) I didn't want to specify a particular type of paper and I wanted a keyword that wouldn't be found in other types of articles, so I figured "novel" would be a good keyword to go on.

Re:my eyes!!!! (1)

What the Frag (951841) | more than 8 years ago | (#14810455)

> Please pull the thesaurus out of your ass and get to the point.
Well he did with the shortest summery of his review: rating 4
If you actual read the whole text, you should keep in mind that a summery like "this book sucks!" won't get on /. :)

Re:my eyes!!!! (0)

Anonymous Coward | more than 8 years ago | (#14810494)

Spoken like an angry person aflicted with true borderline/anti-social personality disorder typical of rogue programmers who think they need not interact with the rest of the human race so long as their software "appears" to work. After all, computers are too complicated for the mere mortal to comprehend so it's a waste of time to be civil to them. Read a non-technical book once in awhile, interact with people outside the computer world, notice the sky and world around you. Perhaps a little less caffeine might help, too.

In your preferred vernacular, "You suck."

are you Aeonite? (1)

Clover_Kicker (20761) | more than 8 years ago | (#14810883)

Or perhaps another big word and awkward phrase fetishist?

> Perhaps a little less caffeine might help, too.

You can't even write 8 words without adding bullshit? Hint:

Less caffeine might help.

Re:are you Aeonite? (1)

PitaBred (632671) | more than 8 years ago | (#14811769)

Because big words are intimidating, right? Never mind that sometimes they say exactly what you want to say. Get over yourself. Just because you can't comprehend words with more than 3 syllables doesn't mean that no one can.

Re:are you Aeonite? (1)

I(rispee_I(reme (310391) | more than 8 years ago | (#14812510)

He has a point. Rule 13 of Strunk's Elements of Style, considered by many writers to be the best guide to writing:

Omit needless words.

I suppose you could trim it to: "Eschew redundancy.", but you get the gist, yes?

Or perhaps maybe you should just consider contemplating utilizing a slight bit less verbage in your attempts to engrave your thoughts upon your surroundings, what?

My review: (1)

cluke (30394) | more than 8 years ago | (#14815596)

Double plus ungood.

Re:are you Aeonite? (1)

Clover_Kicker (20761) | more than 8 years ago | (#14813524)

Big words are effective when used properly.

Baroque verbiage is counterproductive if the only raison d'être is obfuscation and self-aggrandizement.

Horribly convoluted run-on sentences are rarely appropriate.

Go read a random paragraph from Dickens or Twain, and then re-read this fellow's review.

Weight of opinions (1)

Red Flayer (890720) | more than 8 years ago | (#14810345)

FTS: " It is perhaps somewhat presumptuous to disagree with someone like Greg Costikyan"

Not really. There is no reason in particular why his views should be considered more valid than yours, or anyone else's who is familiar with gaming. In fact, I'd say that some other's opinions tend to be more valid, since Costikyan is dependent upon his writing and his rep for funding.

The best opinions out there are the ones that are well-informed, but have no personal stake in the topic at hand, IMO.

That said, Costikyan has expressed some valid opinions covered in previous slashdot threads.

Patterns (3, Interesting)

(startx) (37027) | more than 8 years ago | (#14810397)

"...it's not all that hard to slog through. However, it is indeed a slog..."

It's not meant to be read through like a piece of fiction. Design Pattern books are more of a quick reference guide than a gripping narrative. You don't give a good book at 4/10 just because you aren't reading it correctly! Personally, I found this book an excellent addition to the GoF book, targeted specifically at game designers.

Re:Patterns (0)

Anonymous Coward | more than 8 years ago | (#14811010)

You don't give a good book at 4/10 just because you aren't reading it correctly!

You do give a book a 4/10 because reading it correctly is nearly impossible.

It's completely reasonable to let bad presentation reflect poorly on your opinion of a book's content! What good is a book full of useful information if poor editing and writing practices have made extracting that information unduly difficult?

Re:Patterns (0)

Anonymous Coward | more than 8 years ago | (#14811112)

This is not the kind of book we want to encourage, however. The point of teaching design is to help designers *reinvent* gameplay concepts as well as getting them around any major pitfalls they might encounter.

This book merely lists what everyone's always done. That gets them around pitfalls, but it's only enough to make cookie-cutter gameplay.

Re:Patterns (1)

dubl-u (51156) | more than 8 years ago | (#14811336)

It's not meant to be read through like a piece of fiction. Design Pattern books are more of a quick reference guide than a gripping narrative.

I completely agree. Patterns books are like parts catalogs. When you first get one, you leaf through it, reading about items that happen to interest you. When you actually need to get something done, you grab it again and hunt for the items that apply to your situation.

This review is another fine reminder that if I see somebody do something that seems completely ridiculous, it only proves that one of us has missed something basic, not which of us.

Re:Patterns (1)

angrymilkman (957626) | more than 8 years ago | (#14811765)

Its hard to compare these two books merely because they use the pattern format differently. GoF presents solutions to typical OO design problems and the game patterns book only uses the pattern format (name context forces) etc to describe elements of game design. These two things are completely different.

Save yourself $16.98! (0)

Anonymous Coward | more than 8 years ago | (#14810415)

Save yourself $16.98 by buying the book here: Patterns in Game Design [amazon.com] . And if you use the "secret" A9.com discount, you can save an extra 1.57%!

I want to be an Amazon ho! (0)

Anonymous Coward | more than 8 years ago | (#14811759)

Are you a high school dropout, between the ages of sixteen and twenty-five?...Are you tired of lying around in bed all day with nothing to do? Well. you never need get up again, because in six short weeks I can train you to be high paying Amazon ho...Just think-fifteen hundred dollars a week, without even leaving the comfort of your own bedroom.. Sound too good to be true? Just send for my new book, "I want to be a ho!" [tvacres.com] by me, Velvet Jones!"

you FaBil It (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14810421)

Pallid bodies and stand4oint, I don't long time FreeBSD IS DYING LIKE THE result of a quarrel been the best, it just 0wnz.',

EA Method (0)

Anonymous Coward | more than 8 years ago | (#14810433)

1) Pay thousands for degree.


2) Make popular freeware game.


3) Get job from EA.


4) Recreate a revolutionary game.


5) EA sucks the life out of you.


6) Profit?

Presumptuous? (2, Interesting)

Telastyn (206146) | more than 8 years ago | (#14810446)

I don't think so. Find his list of games. There is one game of actual note (Paranoia), and that's not so much a game as a drug induced interactive story.

No, at first glance this looks like yet another entry into the "Those who don't, teach; those who can barely teach, write buzzword motivated instructional books" category.

Oh, c'mon, one whole book? (2, Insightful)

Opportunist (166417) | more than 8 years ago | (#14810450)

Can be summed up in one sentence: Make it a First-Person shooter, or a Realtime Strategy game. Or a sequel of something.

Or did you see anything else hit the game market last year?

Re:Oh, c'mon, one whole book? (1)

Eightyford (893696) | more than 8 years ago | (#14810750)

Can be summed up in one sentence: Make it a First-Person shooter, or a Realtime Strategy game. Or a sequel of something. Or did you see anything else hit the game market last year?

http://en.wikipedia.org/wiki/Civilization_IV [wikipedia.org]

Re:Oh, c'mon, one whole book? (0)

Anonymous Coward | more than 8 years ago | (#14810903)

I'm pretty sure Civilization FOUR can be considered a sequel... ;)

Re:Oh, c'mon, one whole book? (0)

Anonymous Coward | more than 8 years ago | (#14811219)

oh crap, i thought Iv was the name of the civilization...

Re:Oh, c'mon, one whole book? (1)

SlayerDave (555409) | more than 8 years ago | (#14810756)

Or did you see anything else hit the game market last year?

I did. It's called Guitar Hero. [harmonixmusic.com]

Re:Oh, c'mon, one whole book? (1)

Opportunist (166417) | more than 8 years ago | (#14810774)

Point. But then again, that game only exists 'cause RedOctane wanted to sell its hardware.

Btw, and offtopic, know of a PC version or do I have to finish writing mine? :)

Re:Oh, c'mon, one whole book? (1)

poot_rootbeer (188613) | more than 8 years ago | (#14811741)

Guitar Hero

A trivial variant on the Dance Dance Revolution genre, only the controller is vaguely guitar-shaped rather than in the form of a floormat.

Re:Oh, c'mon, one whole book? (0)

Anonymous Coward | more than 8 years ago | (#14812140)

If you think the form of the controller is "trivial", I think you've missed the point of DDR.

Guitar Hero == Klax Freaks (1)

tepples (727027) | more than 8 years ago | (#14814657)

If you think the form of the controller is "trivial", I think you've missed the point of DDR.

Then it's a trivial variation on another game from the developer of DDR. Specifically Guitar Hero is Guitar Freaks with 2 more keys and a Klax style scrolling notechart.

Re:Oh, c'mon, one whole book? (1)

Bellum Aeternus (891584) | more than 8 years ago | (#14811751)

I was going to say "yes" WoW, but I guess it's a sequel of sorts. So I'll point to Auto-Assault. Yeah - it' sucks, but it's neither FPS or RTS, nor is it a sequel. A rip off of Auto-Duel (see 1980's) yes, but not a sequel.

Re:Oh, c'mon, one whole book? (1)

Opportunist (166417) | more than 8 years ago | (#14815391)

WoW is the most generic off-the-mill fantasy MMORPG I've ever seen. If you consider WoW original, then you must've been missing a "few" other MMORPGs that hit the market during the last 10 years or so.

I heard a bee (1)

rehtonAesoohC (954490) | more than 8 years ago | (#14810459)

"One requirement for Surprises is the absence of Game State Overview or the presence of Imperfect Information or Limited Foresight. Because of this, Surprises are most often achieved by having Dedicated Game Facilitators such as Game Masters. Never Ending Stories are a way of overcoming the problems of Narrative Structures by combining Surprises with Replayability, thus making the narrative continue and change forever."

Continuing on:

"The quintessential Nomenclature for Nonsubstantiating Ideosyncracies has expanded the market share of the Gamer Image in a direct correlation to the Space-Time Continuum"

Buzz buzz buzz buzz...

Re:I heard a bee (1)

saltydogdesign (811417) | more than 8 years ago | (#14814208)

What, is it too much to expect a book on a specialized topic to contain specialized jargon?

Is this a first? (0, Troll)

Jeng (926980) | more than 8 years ago | (#14810466)

Has there ever ever been a bad review here?

I thought every turd scored an 8 here?

Re:Is this a first? (1)

larry bagina (561269) | more than 8 years ago | (#14811455)

Maybe the he was using a 5 point scale. 4/5.

Amazon has it cheaper than BN (1)

heffel (83440) | more than 8 years ago | (#14810485)

Amazon [amazon.com] has it for $32.97 new, 22.89 new
vs $44.95 from BN

Re:Amazon has it cheaper than BN (1)

AKAImBatman (238306) | more than 8 years ago | (#14810554)

#1 Why point it out when the reviewer has just recommended NOT to purchase this book?

#2 Did you notice that someone already pointed out the Amazon link?

#3 Folks around here are generally pretty hostile toward the Amazon vs. BN thing. It's not wise to point it out again and draw their wrath.

#4 Fix your filename. It should be called "mustang_bluecurve.png", not "mustant_bluecurve.png".

Cheerio!

lol ameriniggers (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14810782)

nT

I agree with this review... (1)

CokoBWare (584686) | more than 8 years ago | (#14810508)

I'm not a game designer, but I own this book based on personal interest. I would say this book is more useful in a classroom and a theoretical sense than in front of a keyboard. It's hard to read, but as some level, there are very few other places where you can get this sort of high-level theory regarding game patterns.

Looney Toons (1)

Xaroth (67516) | more than 8 years ago | (#14810552)

The ingredients list reminds me of one of my more favorite Looney Toons, featuring Porky Pig. He'd been instructed by his mother to go to the store and buy "a loaf of bread, a container of milk, a stick of butter, come straight home." Which he repeats to himself over and over again (surprisingly stutter-free, for the most part, I might add) until he reads the sign on a movie theater. Of course, this changes his repeated mantra to include the title of the film (which escapes me), and he ends up spending the shopping money on the movie ticket.

Nevertheless, when making a trip to the grocery store or composing a shopping list for someone else, I'll often find myself using that same line.

Re:Looney Toons (1)

TaliesinWI (454205) | more than 8 years ago | (#14810824)

Pretty sure that was Sesame Street.

Re:Looney Toons (0)

Anonymous Coward | more than 8 years ago | (#14810949)

Given its existance in this book, it's highly likely that the gag is not particularly unique. :P

Re:Looney Toons (1)

Profound (50789) | more than 8 years ago | (#14813416)

Yep, some little girl repeating that as she walked to the shop.

Piggy back on the gang of 4 (2, Informative)

amightywind (691887) | more than 8 years ago | (#14810571)

...what it amounts to is little more than a list, each item on the list referring to the other items like bloggers hawking each others' hyperlinks.

There are an increasing number of books on design patterns being published, all trying to ride piggy back on the success of the gang of four [awprofessional.com] , and each taking more liberties on what a design pattern is. The result is a profusion of 'faux patterns' that obscure real ones. Most of these newer books are catalogs of the obvious. The fact that the original patterns book was published in 1994 and has not had a newer addition should tell you something. It is a timeless trove of good ideas that are independant of the programming subject matter or the OO language du jour. New patterns are pretty rare.

Re:Piggy back on the gang of 4 (1)

angrymilkman (957626) | more than 8 years ago | (#14813725)

What do you think of interaction design patterns or usability patterns?

I like them (1)

amightywind (691887) | more than 8 years ago | (#14813891)

What do you think of interaction design patterns or usability patterns?

I didn't know what they were. I ended up looking here [brighton.ac.uk] . The closest thing in my experience with this is with style guides of various GUI's. But this is better. I think this is very much in the spirit of software design patterns. These are best practices and are well thought out. The ideas are certainly reusable.

Re:Piggy back on the gang of 4 (1)

firewrought (36952) | more than 8 years ago | (#14814077)

There are an increasing number of books on design patterns being published...each taking more liberties on what a design pattern is.

Don't forget that design patterns started in architecture [amazon.com] . I'd grant that most of the books you refer to are chasing buzzwords, but some of them may be trying to create new pattern languages that apply to a different arena of concerns.

I suspect that anything requiring non-trivial design skills could have a pattern language built around it. Whether that would generally be a good thing for each respective field or not is a little less clear to me; from a programming standpoint they seem to be an "ok" but not "fantastic" method for learning new techniques.

Book lacking space? Just add paper (2, Funny)

digitaldc (879047) | more than 8 years ago | (#14810572)

At the end of many subcategories are references to "Additional Patterns," which are only explored on the CD-ROM that accompanies the book, apparently having been left out for lack of space.

And all this time I thought it was CD media that would leave things out due to 'lack of space.'
But this will all be explained in the sequel "Patterns II: The Missing Pages"

Companion book on Writing Patterns (0)

Anonymous Coward | more than 8 years ago | (#14810582)

Perhaps this book's author should have read books about writing patterns.

Yesterday's games vs. today's games (1)

Spy der Mann (805235) | more than 8 years ago | (#14810747)

I remember an old c64 game, "Pogo Joe". It had this guy on a pogo stick that had to step on different squares to change their colors. Meanwhile, he had to run away from these monsters or you would lose a life. But you could crush the monsters' eggs before they hatched.
All of this while you wer hearing a really funny (or fun) melody.

So, was it a puzzle game? Yes.
Was it a platform game? Well, kinda, you had this guy jumping on platforms. I guess it could be applied. And you had to run away from enemies, too.
Was it fun? WAY YES! I remember spending hours playing this game.

Another fun game was Lemmings, too bad psygnosis doesn't release sequels anymore, and sues cloners out of existence.

In contrast, today's games have nearly zero replay value, and most of the time you spend is trying to get to one zone from the other while battling endless monsters: Castlevania, Silent Hill (to an extent), Final Fantasy, all apply, and most of the time the areas are plain corridors (or streets / plains) with no variety between them. Forget a puzzle element and you spend useless time trying to find where the puzzle element is than actually figuring out the puzzle. This was called the "metroid syndrome". Fortunately, metroid did have difficult areas to go thru, you had to jump, dodge, avoid lava streams, hang onto ledges... it was fun. It wasn't just running around and hitting x or o whenever you encountered a monster. And then came the speed-run challenge with SuperMetroid, this is a real innovation, get 100% items under 3 hours by using secret techniques. w00t :)

But in today's games, remove the moving time from one area to another, and your hours of play are disminished a lot. To think we spend about $60 on EACH of these games.

Perhaps a flaw has been the "pseudo-3D maps" in games like Castlevania. Gone are the old days of 2D platformers. But what do we have instead? Top-down runners! It's *NOT* 3D! They replaced x and z with x and y. Sure, it looks 3D in the screen, with all those nice renderings and everything, but a 2D map can describe a level perfectly, even when some areas are "above" others. (An exception to this is the Prince of Persia series, it is a true 3D game, but the levels are not many or as long as one would wish).

So, what happened to the creativity of game designers? :(
It seems they want to try new formulas (3D renderer + 2D top-down maps = profit!!), but bury their old formulas so nobody can use them anymore. I want my lemmings with level editor! :(

Re:Yesterday's games vs. today's games (1)

Junks Jerzey (54586) | more than 8 years ago | (#14810948)

I remember an old c64 game, "Pogo Joe". It had this guy on a pogo stick that had to step on different squares to change their colors. Meanwhile, he had to run away from these monsters or you would lose a life. But you could crush the monsters' eggs before they hatched. All of this while you wer hearing a really funny (or fun) melody.

I know you're trying to make a point about how creativity has fallen by the wayside, and I agree with you, but you picked a bad example. Pogo Joe was one of many hopping and color changing games that attempted to capitalize on the popularity of Q*bert. So in reality, you've cited an unoriginal clone :)

Re:Yesterday's games vs. today's games (1)

Blakey Rat (99501) | more than 8 years ago | (#14811700)

I'll give you Lemmings... but citing an obvious rip-off of Q-Bert as a creative game, that doesn't strike you as odd?

Just like all those Linux users who always go on about how Frozen Bubble is the most creative best game ever without mentioning it's just a clone of Bust-A-Move.

Pingus? (1)

tepples (727027) | more than 8 years ago | (#14814672)

Another fun game was Lemmings, too bad psygnosis [...] sues cloners out of existence.

Are you claiming that Psygnosis is the reason why Pingus [seul.org] hasn't seen any updates?

Learning by doing... (1)

creimer (824291) | more than 8 years ago | (#14810791)

After glancing at the table of contents on Amazon, you would be better off looking at what others did in actual game content and just plunge into the editor to learn how to incorporate their ideas into your own "design pattern". Learning by doing is probably better in some cases than other.

YM "learning by infringing" (1)

tepples (727027) | more than 8 years ago | (#14814685)

you would be better off looking at what others did in actual game content and just plunge into the editor to learn how to incorporate their ideas into your own "design pattern".

But if you learn primarily by doing, you might inadvertently copy something that a federal judge would deem protectable expression. Unfortunately, it has happened [lld-law.com] .

Missing the point of the patterns movement (1)

bigHairyDog (686475) | more than 8 years ago | (#14811074)

The concept of a patterns book is to facilitate communication between designers, *not* to teach people how to program. The idea was started by Erich Gamma et. al. with their seminal book Design Patterns and taken up by other leading authors like Martin Fowler in Patterns of Enterprise Application Architecture.

While these books may contain hands on examples and therefore be useful in teaching people how to design, their real utility comes when I as a software architect say to a new developer "We're using a Plugin object controlled by the Data Mapper to control this behavior". If you know patterns, You know exactly what I'm talking about.

Whether game design is as amenable to splitting into patterns remains to be seen, but don't criticise this effort because it is not a good tutorial; Design Patterns was not a good tutorial either but it was one of the most useful books I ever read.

Re:Missing the point of the patterns movement (0)

Anonymous Coward | more than 8 years ago | (#14811393)

No, you are not quite right. A pattern (or it's name for that matter) is good for communication, that's right. However, a design patterns book is definitely for teaching you how to adress a specific problem/design descision. It teaches you how to program in the large. It identifies problems and gives you *approved* (that is what matters) solutions with well-known pros and cons.

And yes, I found the GoF book a great tutorial. It confirmed me and some of my design descisions and it showed me new ones. It simply inspired me. Actually. that is what I expect from other design pattern books.

Re:Missing the point of the patterns movement (1)

canozmen (898239) | more than 8 years ago | (#14811965)

There is one important difference between software design vs. game design. Although many of us have used numerous pieces of software for years, no of us ever knew about Adapters or Mediators before we had to develop a complex software system and Gamma et. al. published a common language to talk about these issues. On the other hand, anyone who played a few computer games knows personally what a Boss, Level, Power-up, Hi-Score List, etc. is.

I've been having a look at this book for the past few weeks, and it looks like it was written for educating non-players so that they can design games. The question is, do we (as people who enjoy games) really want that to happen?

Fa1lzorsZ! (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14811109)

and arms and dick Pallid bodies and transf*er, Netscape Need to join the

The true pattern in game design (1)

rubberbando (784342) | more than 8 years ago | (#14811178)

As much as I hate to say it, this is the pattern I have seen for the last 2 decades:

1. Revolutionary breakthrough game arrives
2. Everyone else clones said game
3. Profit
4. Stagnation while everyone waits for #1 to happen again.

Re:The true pattern in game design (1)

zerOnIne (128186) | more than 8 years ago | (#14811608)

Yes, this is how genres arise, and the process is hardly unique to video games. These days, though, it seems that people are less willing to push the boundaries of genre formulas.

Design patterns (0)

Anonymous Coward | more than 8 years ago | (#14811249)

What could have been a sort of cookbook for gaming turns out to be less a book of recipes, and more a list of ingredients

Apparently you are completely unfamiliar with the entire concept of "patterns". Yes, they are ingredients. No, they aren't instructions on how to build something.

The idea behind patterns is that you can distill a particular solution to a range of problems down to a name and general description. Then, when you are designing a game, you can refer to these solutions by name, and thus the whole code design phase goes a lot quicker because you are all talking at a higher level.

That's what this book is - a collection of solutions to problems that commonly crop up when you are developing a game. If you thought that it was somehow a recipe book or that it would show you how to do something, then you don't know the first thing about patterns and should learn a bit more before denouncing this book to all and sundry while displaying your ignorance.

couldn't read it (1)

micromuncher (171881) | more than 8 years ago | (#14811302)

Being an ol' fart, and keenly interested in anything like this, I didn't find much value in this book. People keep saying its something for designers to use to facilitate communication, which is a noble cause and good in any other aspect of software engineering; however, the level of complexity to explain the obvious is high, and as soon as you start making up complex terms to explain simple things, you loose the ability to explain it effectively.

Not to mention that most game designers generate their own language that often models an architecture that is creatively delivered. Most game development is highly iterative.

I've got to say it (1)

Flying pig (925874) | more than 8 years ago | (#14811337)

The book sounds like a maze of little twisty paths....

Why does Hollywood suck? Because its movies must all be produced in accordance with movie design patterns. There's an alternative word for design patterns: formulaic. Fine when looking at engineering or software design (we want some assurance that we can analyse this thing and gain some assurance that it will work consistently, and that we can find other people to work on it). But to create something with artistic merit we need to transcend the formula. We live in a world which recycles everything, to the extent that just about everything vaguely cultural has to recast, relocate or make ironic reference to something else. But it's self consuming and ultimately sterile. I suspect that nothing new and exciting will come out from anyone who has to seek guidance from the book. Ex nihilo nihil fit.

Interesting, but... (0)

Anonymous Coward | more than 8 years ago | (#14812135)

Sounds like a book that should have been a website!

A few patterns (1)

Taulin (569009) | more than 8 years ago | (#14814247)

Here are a few game patters: 1) Company A hypes a game, rushes it out the door and it sucks. 2) Company B hypes a game, never gets it out. 3) Company C creates a great game, and gets bought out.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>