Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Patterns in Game Design 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.
Patterns in Game Design
author Staffan Björk & Jussi Holopainen
pages 448
publisher Charles River Media
rating 4
reviewer Michael Fiegel
ISBN 1584503548
summary A comprehensive compendium of game design "patterns"


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.
This discussion has been archived. No new comments can be posted.

Patterns in Game Design

Comments Filter:
  • 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. :-(
    • by Anonymous Coward
      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 b
    • 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? (Score:5, Insightful)

      by Moraelin ( 679338 ) on Monday February 27, 2006 @03:07PM (#14810636) Journal
      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.
      • 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, wherea

        • "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 fr
          • 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
        • 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 po

      • 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. ;)

    • 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 Mod
      • 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.
        • 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?
          • 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?
      • 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 themsel
        • 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 d
          • 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 reprogra
            • 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 Sc
              • 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 languag
                • 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
                  • A friend gave me some basic info, and I figured out the rest. My first program to use it was a stereogram generator. 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.

                    Ah hah! See, you were not without your resources. Many of whom were obviously sharing their experiences gleened from sources such as TGPG. Sadly, I had no such resources, and I know I wasn't alone. There simply wasn't anyone in my nearby area who had the experience and un
                    • Who the hell cares if it's 320x200 or 320x240?

                      I certainly did. My 286 ran games with graphics better than 320x200. And it's not a choice between 320x200. It's a choice between 320x200 with no paging and 360x480 with paging. Huge, huge difference.

                      Why would you start someone with a "BTW, ignore this code, and this code, and this code, and that code, because it does some bank switching that we'll get to later"

                      That's what LaMothe does throughout the book - "There's some other stuff you can do, but I'm not g
                    • Actually scratch System Shock - I just looked it up, and I realized that I was remembering System Shock 2, not 1.
                    • Aha!! I figured out some of the confusion, especially the issue of whether or not it covered a raycaster. I went to my bookshelf to grab "Tricks of the Game Programming Gurus" (LaMothe, 1994), and found it: right next to "Teach Yourself Game Programming In 21 Days" (LaMothe, 1994). I had forgotten that I had gotten two books at once, not one (come to think of it, I think they were both xmas gifts). My mind had mixed them up since I read them one after the other. :) TGPG was definitely the better of the
                    • My 286 ran games with graphics better than 320x200.

                      So did my XT. With only 16 colors. The 256 colors was why everyone put up with such a low resolution.

                      It's a choice between 320x200 with no paging and 360x480 with paging. Huge, huge difference.

                      Not for learning. If you're learning how to write a video game the difference is: understandable and completely incomprehensible.

                      Have you ever tried teaching Java to someone who's never coded before? The whole class and main method confuse the hell out of them. All th
                    • So did my XT. With only 16 colors.

                      16 != 256. Sixteen is vastly inferior.

                      It's a choice between 320x200 with no paging and 360x480 with paging. Huge, huge difference.

                      Not for learning.


                      And we had differences in our knowledge base, which is what I think this disagreement is all about. :)

                      Ok, this is where we may get into a difference of opinion over what "Mode X" was. The Mode X features like fast scrolling and page flipping were fully available to the 320x200 mode. Many games claimed they were using Mode X beca
                    • About 25% of your response is again arguing with things I didn't say. e.g.
                      • Why did I say that BSP's were used for rotation? Well, I didn't. I was referring to depth sorting.
                      • I never said that MS Flight Simulator was *more* impressive, only on par. My point being that non-texturemapped 3D code had been around for over a decade. A10 was just another flight simulator and was nothing special in that respect.
                      • The fact that 16 colors was less that 256 was the point that I was trying to make.

                      Another 50% is still utt

                    • Why did I say that BSP's were used for rotation? Well, I didn't. I was referring to depth sorting.

                      I'll quote: "You can optimize them six ways to sunday, but you still have to do 3D to 2D projection, compute surface normals, and handle depth sorting. (Before you cry "BSP Trees!", keep in mind that BSP trees have to be computed somehow. You still have to do the same calculations ahead of time. And don't you dare remove this comment and reply as if I never made it.)"

                      I never said that MS Flight Simulator was *m
                    • Check your email. (The tiresias one.) I just sent you something that should settle things quite well. There are still a few holes, but I'm not looking to pursue it any further.

                      -AKAImBatman
    • "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'
  • "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, 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!!!!!
      • 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 mothe
      • 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
  • 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, C
  • Patterns (Score:4, Interesting)

    by (startx) ( 37027 ) <slashdot AT unspunproductions DOT com> on Monday February 27, 2006 @02:41PM (#14810397) Journal
    "...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.
    • 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 ridic
    • 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.
  • Presumptuous? (Score:2, Interesting)

    by Telastyn ( 206146 )
    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.
  • by Opportunist ( 166417 ) on Monday February 27, 2006 @02:47PM (#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?
  • "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 Ideosyncracie
  • Amazon [amazon.com] has it for $32.97 new, 22.89 new
    vs $44.95 from BN
    • #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!
  • 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.
  • 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 t
  • by amightywind ( 691887 ) on Monday February 27, 2006 @03:01PM (#14810571) Journal

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

    • What do you think of interaction design patterns or usability patterns?
      • 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.

    • 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

  • by digitaldc ( 879047 ) * on Monday February 27, 2006 @03:01PM (#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"
  • 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.
    W
    • 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 co
    • 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.
    • 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?

  • 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.
    • 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].

  • 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

    • 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
  • 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.
  • 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 l
  • 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.

  • 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.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...