tag:blogger.com,1999:blog-11719805.post113739650030739022..comments2023-11-03T01:45:11.288-07:00Comments on Lost Garden: Creating a system of game play notationDaniel Cookhttp://www.blogger.com/profile/10437870541630835660noreply@blogger.comBlogger55125tag:blogger.com,1999:blog-11719805.post-43252498233479297292007-10-19T08:37:00.000-07:002007-10-19T08:37:00.000-07:00My email is danc [at] lostgarden [dot] com if you ...My email is danc [at] lostgarden [dot] com if you want to contact me. :-) <BR/><BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-27354662255503326312007-10-19T08:12:00.000-07:002007-10-19T08:12:00.000-07:00Hello Danc, I am really late on this, I just have ...Hello Danc, I am really late on this, I just have to hope that you'll still read this...<BR/>Well I enjoyed your article A LOT and there is something I wrote I'd love to hear your opinion. I'm Alessandro Canossa, at the moment writing a Phd on level design in Denmark. I don't know how to get in touch with you, but if you have time and are curious enough to google me, please send me a line. I am not a webstalker, I repeat, I'd just like to hear your opinion on my articles. Ciao.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1156696029818195702006-08-27T09:27:00.000-07:002006-08-27T09:27:00.000-07:00Danc,I find this article fascinating and important...Danc,<BR/><BR/>I find this article fascinating and important, and would like to talk to you. I have hosted a small and elite think-tank on the topic of "music on computers" (Project BBQ) that has been extremely successful in influencing that industry over the last 10 years.<BR/><BR/>This year my team is putting on Project Horseshoe, a similar event but for Game Design. http://www.projecthorseshoe.com<BR/>This one is by invitation only, and there will only be 50 attendees. Will you please contact me through the contact info in my website? Thanks.<BR/>http://www.fatman.com<BR/><BR/>Best,<BR/>George A. Sanger<BR/>The Fat ManAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1151388123963878402006-06-26T23:02:00.000-07:002006-06-26T23:02:00.000-07:00sorry for coming late to this discussion, in only ...sorry for coming late to this discussion, in only found it just now. my comments come from the perspective of a software developer who's helped teach an artist (writer, mostly) how to analyze his own work in order to improve it.<BR/><BR/>first off, i think this is a great start. there are some gaps, as i see them, however. the most notable to me is the question of time scale.<BR/><BR/>when i look at the graphics you produce, you have the executed actions on one axis, and the buzz on the other. the first problem that springs to mind with that representation is that actions (in your definition) are a series of verbs, each of which can take the user a certain amount of time to execute. that means that different actions will likely take different amounts of time to perform, thus making the time (actions) axis non-uniform. the result of that is that the length of time buzz is at a particular high or low point can't really be told from the graphs, but that seems to be a very important piece of data.<BR/><BR/>another, related issue is pauses in the game. i'm not talking about the time spent on the toilet while the game is paused, i'm talking about the kind of games that allow you to essentially stop playing for a while. specifically, this problem is posed by MMORPGs, where you can essentially log on to the game and not play, but instead just talk to other players. it's pretty hard to record the difference between time spent doing something like that and time spent actually playing in order to analyze the buzzlevel/time. does running around in the game world count as play? when you're trying to reach a specific point to reach a goal, yes. when you're running around out of sheer boredom because your mates aren't online yet...? that problem doesn't invalidate the model, but makes it hard to apply to non-arcade games, imho.<BR/><BR/>now you might have noticed that i'm hung up on time here as opposed to what the graphs actually _record_, namely executed actions. the thing is, i'm not sure whether buzz/actions is a good metric, or rather, whether it's the _major_ metric you should be looking at. what buzz/actions gives you is a look at how much effort the user has to put in to achieving a higher level of buzz. it shows you which sections of your game are less interesting than others. what it doesn't show you is the actual player experience, which in my opinion is better measured in buzz/time. i hope i made that difference clear :-/ i'm not always good at expressing these things in english.<BR/><BR/>third, the notation system might be problematic when you you look towards how games might be built in the future. i remember a sequence from space quest, where you had to drop a rock on a spider droid. imagine a similar puzzle in a modern game engine. you might take a crowbar from your inventory to push the rock over the edge of the cliff. that's a pretty well-defined action that leads to a clearly defined reward. now what if your game world includes a good physics engine? you could drive a car into the rock instead, pushing it over the ledge. or you could drop the car on the spider droid. or you could park the car next to the rock, put a fuse in the fuel tank, and let the explosion push the rock off... my point here is that the more, umm, let's say "realistic" games get in terms of world interaction, the less simple it becomes to identify which actions led to which rewards.<BR/><BR/>and that, i think, is a very important thing when attempting to analyze your game. specifically, if you don't expend any effort, the reward event will probably not be very rewarding. what i therefore think this notation system sorely lacks is a correlation between actions, risks and rewards that determines the strength of the resulting buzz. no, i haven't figured that out yet :P<BR/><BR/>all in all, i get the feeling that the notation system as it is now would be very well suited to arcade-style games, in which the verbs and rules are fairly limited in number and complexity (i.e. side-effects). i can see jump'n'runs or simple shooters to be analyzed in this way, but when the shooter allows destroying part of the surroundings in order to kill enemies, things become difficult. and not because the notation system doesn't apply, but rather because of the technical difficulty of how to detect and therefore record how an action results in a specific reward.<BR/><BR/>still, it's a great start and it's given me a lot to think about.<BR/><BR/>i'm struck by how many of the posters here seem to think how useless the whole thing is, however. i'm struck by that mainly because it seems to parallel how many, many software developers think about tools to analyze the quality of your software, such as unittesting (not going into that here). there's a famous saying that illustrates why tools such as this notation system are useful: if the only tool you know is a hammer, everything will look like a nail. rephrased it might be: if you only know how to design your game intuitively, you're not likely to produce the best possible results. learn how to use many different tools, and learn _when they apply_. that's the only way known to man to produce works of excellence in a reasonable amount of time (pure chance takes too long).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1139055266897865972006-02-04T04:14:00.000-08:002006-02-04T04:14:00.000-08:00Dan, I'm sure you are aware of the work by Ben Cou...Dan, I'm sure you are aware of the work by Ben Cousins (read his GDC lecture about this) concerning ludology and identifying ludemes.<BR/><BR/>It seems there is a great deal of overlap in what you both are proposing.<BR/><BR/>I absolutely agree that there are strong patterns of mechanical and psychological change during gameplay and that we are wise to study the sequencing of those patterns that lead to what we might loosely term "fun".<BR/><BR/>It seems fairly obvious to me that as we study the core patterns, we will inherently become better at reproducing the pleasing patterns and subdue the less pleasing ones.<BR/><BR/>Its like when you are improvising on an instrument, inevitably you end up drawing on patterns you enjoy to create a core structure for your music, then you apply other sequences, scales, harmonies as appropriate. <BR/><BR/>I think its clearly absurd to think that we wont benefit from identifying and applying some solid theories to these "riffs" at least, then delving deeper into the composition of these patterns.<BR/><BR/>I just dont see why people would have a problem with this.<BR/><BR/>Its like saying that most music hasnt benefitted from popular patterns being identified and re-used. Like there is no value at all to the three-chord-trick?<BR/><BR/>Almost all of popular music is identification of patterns that please people and their re-use within different contexts (or sometimes simply repetition of those). <BR/><BR/>It seems likely that generally when creating games from "experience" all we are doing is subconciously applying the patterns (riffs) we enjoyed in the past.<BR/><BR/>But as any real musician will try to tell you, relying on simple learn by rote riffs is a poor substitute for real musicianship. Sure the three-chord-trick would be fine for a lot of mass media, but if you really want to be an artist, you have to delve deeper into the structure of music.<BR/><BR/>We are at the superficial level right now and I wholeheartedly support the efforts to delve into the deeper structures.Phil Carlislehttps://www.blogger.com/profile/05262518177977960604noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138790171720537772006-02-01T02:36:00.000-08:002006-02-01T02:36:00.000-08:00eyejinx: You say that there won't ever be a formal...eyejinx: <BR/><BR/>You say that there won't ever be a formal language that will help game designers do their jobs better. You say that it isn't possible.<BR/><BR/>So why does all other "entertainment" forms have these kinds of formal languages? Music has, theater has and the film industry has. There isn't ONE language that is used ALL the time by all, but different dialects that all put together gives a potential "artist" or "designer" a great tool to help him make music. Most languages DO restrict the user a great deal, but without it it becomes quite hard to be productive at all.<BR/><BR/><I> Why? Because we can schedule the team more efficiently. Because we can implement already-established solutions without having to prototype them. Because we can rely on the expertise of the team rather than having to verify all of our decisions through playtesting. Because we're not duplicating effort by rough-drafting and then re-architecting the engine. </I><BR/><BR/>You seem to disregard the fact that an "already-established" solution WILL meet upon difficulties during the developement phase that wasn't previously foreseen by the design team. These difficulties COULD potentially lead to a big rewrite of the design, and again rewrite of "finished" code. This has a much smaller chance of happening using an iterative design loop. Thus your project would have a much higher risk factor than what danCs project would. This "flaw" of current top-down game design is rampant through the industry, as you can see by all the games being delayed (close to all in-fact). The bigger the project, the higher the risk. <BR/><BR/>From a funding point of view, these risks makes a project less interesting to invest in. The only reason companies invest in games now, is because of the huge potential for profits, IF the game is successful. And thus game companies design games that are "tried-and-tested" designs with graphics upgrades. Trying to "sell" a game to investors with : "We're going to do this amazing new thing that noone has done before!" will probably be met with alot of sceptisism. And you multiply that with the high risk factor of top-down design, the amount interested investors would be scarce. Iteration promotes creativity. No question about it. <BR/><BR/>And to end this long post : The iteration design HUGELY benefits from the feedback logs that danC is suggesting. And the top-down design doesn't.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138600745088702392006-01-29T21:59:00.000-08:002006-01-29T21:59:00.000-08:00I disagree that it could only be used for "nearly ...I disagree that it could only be used for "nearly completed" titles. By the way, this is by far the best article you have written (in my opinion) at least that I have read. Probably your breakdown of the lifecycle of videogame genres was more informative but as you were working with existing data that is a given. I think you are really on to something here. What is needed is a program to be written that records a timeline and as you said a list of all imput commands from the player and also records defined rewards obviously (with programmer defined amplitudes) and plasters it all on a timeline. You would use this system on what are regarded as the most popular games. The Marios, GoldenEyes and Zeldas. The groundbreakers for new genres and compare them with todays blockbuster titles (GoldenEye to Halo for example). As Danc said we are just collecting data, which we must do on existing games in order to formulate what we could classify as an 'optimal' game notation for an existing genre. Once we have this data we can EASILY distiguish where we need to put rewards (on an average timeline) as well as risks. So we sit down with a game concept, come up with our long term goals versus medium and short term goals and we can award amplitudes to these awards as well as awarding amplitudes to risks, remembering as Danc noted, the exponential buildup associated with layering our awards or our risks. Then we can easily assign these risks and rewards on our optimal notation based on our own chosen "average timeline". It would be exceedingly easy to see where you need what in the EARLIEST developmental stage. Then we build up these timelines with actual scripts and events and playtest them to ensure we are actually hitting our chosen timeline as well as our optimal notation score. Tweaking would be extremely easy for anyone remotely competent in reading the feedback notations. This notation system could even be used to anticipate genre lifecycle instead of using what we would call a "lagging indicator" of game sales. Incredible post Danc, I will have to link to this on my blog if you don't mind.Benjdudehttps://www.blogger.com/profile/17316537542916535224noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138509776303880112006-01-28T20:42:00.000-08:002006-01-28T20:42:00.000-08:00Greetings:I'm always up for a little gedanken expe...Greetings:<BR/>I'm always up for a little gedanken experimentation.<BR/><BR/><I>Imagine that instead of creating a large design and then entering into an extended production cycle, we start with a little design. This little design roughly describes core gameplay and takes a few days to implement. <BR/><BR/>Now, we play test that prototype, log the results in a manner that provides useful feedback. Then we spend a few more days adding to the prototype. Repeat.</I><BR/><BR/>Fine, you're an advocate of iterative game design. I get that. I'd argue that, unless you're building an established genre with an established engine and toolset (like building an FPS with the UE3 engine and toolset), you're not going to be able to build a sufficiently sophisticated prototype in a few days. So, I'd say that you're better off using other mechanics to prototype, like pen and paper, or appropriated pieces from things like board games. But, independent of the mechanics, the answer to the question of whether you can build a game through iterative design is, obviously, yes.<BR/><BR/>Of course, if you've got a large team on staff, you're going to have to work pretty hard to get out in front of the rest of the team; after all, you don't want the programmers to be idle while you're busy play-testing your prototypes. And particularly if you're going to bring in folks from outside the team for your playtests, your iteration cycles are likely to be longer than necessary, or practical for that matter. Of course, there are methods for tackling those problems as well, things like extreme programming, or Scrum. <BR/><BR/>In general, the kind of iterative process you're talking about is going to work best either with very small teams, and thus very small projects, or as a pre-production phase that helps you to identify and refine all the pipelines you'll be using in production. In production, you're still going to need to scale up, which means solidifying the overall design and building for longer periods between evaluations.<BR/><BR/>But, and here's the rub, let's say you and I have equivalently talented groups of programmers, artists, sound designers, scripters, and the rest to work with. You take the iterative approach you sketch out here. I do a more classical implementation of the Cerny method, with a top-down design approach. If we're both trying to make a competitive commercial mainstream product, my team gets there faster.<BR/><BR/>Why? Because we can schedule the team more efficiently. Because we can implement already-established solutions without having to prototype them. Because we can rely on the expertise of the team rather than having to verify all of our decisions through playtesting. Because we're not duplicating effort by rough-drafting and then re-architecting the engine.<BR/><BR/>I don't know which game would be better; not only is that highly subjective, but we just don't know enough about our respective design skills. But if my team finishes sooner, then we've got more time to polish and embellish the final product and get it onto the market before your team is done.<BR/><BR/>So, you know, if you need to create notational systems to record feedback from your prototype play sessions, well, go for it. If you need to compress your data to understand it, then by all means, come up with ways to do that. No one's saying you shouldn't create tools to overcome your personal shortcomings.<BR/><BR/>What I'm objecting to is what you yourself stated as the basic premise of your article: that creating a robust symbolic language of analysis for existing games will lead to increased efficacy in creating new games. I even quoted it in my previous response, so it would be clear. If addressing that is "wildly divergent", then you and I have a much deeper problem agreeing on the semantic definition of terms like "basic premise" that will prevent us from having any useful communication.<BR/><BR/>You're not the first person to call for this kind of project, as Raph's post and his presentation at GDC demonstrate. You won't be the last either, no matter how much I fervently desire that were so.<BR/><BR/>Ultimately, I'm not even against the concept of developing symbolic reference systems (which I state can be useful for refining your own understanding) that help you to refine the particular game you're work on. What I object to is the notion that there's a universal formal language of game design that will help all game designers to do their jobs better.<BR/><BR/>That's just bunk.<BR/><BR/>Best,<BR/>Eyejinx.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138491342108297442006-01-28T15:35:00.000-08:002006-01-28T15:35:00.000-08:00Thanks for stopping by, Eyejinx. Let's run with o...Thanks for stopping by, Eyejinx. Let's run with one of your themes for a little bit. <BR/><BR/>I've heard the comment before that the feedback system I've proposed is 'only useful for tweaking an existing design'<BR/><BR/>Imagine that instead of creating a large design and then entering into an extended production cycle, we start with a little design. This little design roughly describes core gameplay and takes a few days to implement. <BR/><BR/>Now, we play test that prototype, log the results in a manner that provides useful feedback. Then we spend a few more days adding to the prototype. Repeat. <BR/><BR/>For argument's sake, let's build the entire game this way. It isn't a phase. It is the entire development process. Is using the feedback system I've described for this particular process 'bunk?'<BR/><BR/>In this scenario, we are dealing with simple practical problems here, not deep philosophical ones. <BR/><BR/>- How do I record useful feedback from my prototype play sessions?<BR/>- When there is lots of log information, how do I compress it so that I can understand it and manipulate it?<BR/><BR/>I certainly appreciate the wildly divergent thoughts this essay has provoked, but I get the feeling that the core message was somehow lost. :-) It is all good though. <BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138485179618287992006-01-28T13:52:00.000-08:002006-01-28T13:52:00.000-08:00Greetings:Hrm, well, late to the party, I suppose,...Greetings:<BR/>Hrm, well, late to the party, I suppose, but lots of good conversation here. I'll try to avoid the various red herrings and side tracks, and stick to the basic point:<BR/><BR/><I>Here’s the basic premise: If we can measure and transcribe existing game experiences in a robust symbolic fashion, we can reuse the same system to improve new games. Just like the Catholic monks of yore, we are figuring out how to record our medium in a meaningful fashion.</I><BR/> <BR/>I think this goes to the heart of what Danc is doing, and Raph as well, and Doug Church back in the day. This is bunk.<BR/><BR/>Just because you can develop a robust analytical language for describing game design (or in Danc's case, reactions to events based on game design) does not mean that you can use that language to increase the effectiveness or efficiency of generating new game designs. Regardless of whether or not there are game "atoms" or "notes", and in general I am in Samuel's camp on this one, having a defined set and notational conventions does not enable one to generate new constellations of them any better than we currently do.<BR/><BR/>The tools of literary analysis, rhyme and meter, prosody and zeugma, deconstructionism and close reading, may help us to better understand literary artifacts, but they are largely useless to the writer. True, they may help you to meet an established convention (hard to write a sonnet, for example, without paying attention to rhyme and meter), but they do not help you to write better within that convention. In fact, most of the great artists work away from or outside of the established conventions of their time, and it is only retroactively, through criticism, that we adjust our notions of convention such that we can fit these artists' works into our critical models (see Harold Bloom, T.S. Eliot, et. al.).<BR/><BR/>While the exercise of symbolically mapping a game design may be helpful for individual designers to hone their understanding of game design (which, I understand, both Raph and Danc feel that it has for them), there is no symbolic language of game design, no matter how robust, that can arrive at all of the potential constellations that will produce good game designs. This is Godel vs. Russell all over again.<BR/><BR/>Furthermore, the creation of abstract codifying systems touches only on one side of the game design issue. In Matthew Arnold's dichotomy, this is the Hellenic tradition of idealism, which attempts to identify transcendent structures to explain the pleasure of the encounter with culture. Equally important is the, in Arnold's somewhat colonial framework, Hebraic tradition that focuses on the empirical "factness" of the thing itself, and the way that the specifics of the work create a relationship not only of light but of sweetness. It is this interplay between structure and experience that is important, and a symbolic notational system may help us to understand the former, but it does nothing for the latter.<BR/><BR/>Beyond the simple impossibility of creating a complete symbolic notation of game design lies the further problem of production. While there are, no doubt, better ways to document game design than the epic Tome of a GDD, and while it is indisputable that being able to document game designs is an integral part of being able to build games (at least, in the realm of large projects that require large teams), the notion that one symbolic system will produce greater efficiency across a broad range of games is itself nonsense. Ultimately, the symbolic system has to map back onto the concrete questions of implementation (not just code, but art, scripting, sound, etc.), and so while it can be helpful to annotate the structural mechanics of a design, there will always need to be fuller, more concrete desriptions of the play experience.<BR/><BR/>For example, one of the techniques that I find useful when working with non-open-world games (ones in which there are discrete environments and limited paths through them) is to combine a top-down schematic of the play-space with a notational system that describes the various things players will encounter on the map (scripted events, puzzles, encounters with enemies, "wow" moments, etc.), these abstract notations always point to documents that fully lay out what makes those things different from other, similar encounters and how they should be experienced by the player. The map itself, without the referent description of the experience, would be useless to the scripters, artists, coders, etc. who actually have to build the damn thing, and while the map can provide a useful analytical tool to discover issues in pacing, variation, game flow, and progression, it ultimately helps to refine an <B>already established design</B>. In other words, it's an internally useful analytical tool, not a generative language.<BR/><BR/>You can argue about whether or not it makes artists more efficient to understand the vocabulary of the critics, or to apply those critical filters to their work while creating, but it is indisputable that the language of criticism is not sufficient, and generally not necessary either, to producing works of art. Or games, either, for that matter. The examples that bear this out are far too numerous to bother mentioning.<BR/><BR/>So, I'm all for people working to further develop their understandings of game design, and even for people advocating that other people in the industry (or the academy) work similarly to refine their own understandings of it, but I really wish that we could once and for all get rid of this notion that the field of game design will somehow benefit from a formal language, as I've <A HREF="http://www.micrysweb.com/office/formallanguage.html" REL="nofollow">said elsewhere</A>. It's a fool's errand, and for that reason, best left to the academics.<BR/><BR/>Best,<BR/>Eyejinx.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138413752393900482006-01-27T18:02:00.000-08:002006-01-27T18:02:00.000-08:00Folks are very correct in pointing out that this i...Folks are very correct in pointing out that this is not a notation system for writing down the mechanics of a game design. It is instead a feedback tool that facilitates a highly iterative software development process.<BR/><BR/>The music analogy was perhaps a bit too strong and overwhelmed this distinction. I'm certainly not looking to write games designs down like you would write music. <BR/><BR/>I come from a rather radical sect of software development that believes that design documents are generally a load of whooey. They are at best a promise of a conversation and at worse an excuse for why things didn't work out. They are never, ever accurate and never will be. <BR/><BR/>The simple fact is that software development is a process where you learn as you go. You make adjustments and improve. To imagine that there is any system that lets you pop forth a perfect piece of software full fledged from your forehead is highly questionable. <BR/><BR/>A full fledged description of game mechanics is a lovely academic exercise. Someone far smarter than me may create a useful solution. If that happens, sweet. <BR/><BR/>Until then, it is worth creating a useful tool that solves critical development issues that we are facing right now. Once you create a prototype (be it low level or highly polished), how do you know what to change? That is a common question that most game developers face. <BR/><BR/>I'll always take a good feedback mechanism over a master theory of everything. :-) <BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138405515125851632006-01-27T15:45:00.000-08:002006-01-27T15:45:00.000-08:00I think the problem most people are having with th...I think the problem most people are having with this article is that the focus is on the buzzes and lacks thereof. Danc, it's a great start for evaluating, but if you're talking about notation you should probably focus more on the tokens, verbs, and rules than on the results of said items. It's in there, but early in the essay, and not defined as well as it could be. It seems that your focus on the "Element's of a player's psycological experience", as least as far as this article is concerned, ignores the actual game notations, "Elements of a game's mechanical structure." The notation is the structure, whereas Danc describes a method of viewing the results of that structure.<BR/><BR/>Of course, tokens, risks, and verbs are in fact at the top of the game's "sheet of music," but if you're talking game notation they should be the entire thing. With music, the listener evaluates the notes on the page; with games the player should evaluate the structure defined on the page. Danc has skipped the actual notation in favor of measuring the result of the game.<BR/><BR/>Although, it's a damn good start for measuring such results. You just skipped a step.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138401206068874952006-01-27T14:33:00.000-08:002006-01-27T14:33:00.000-08:00Interesting discussion/debate. You guys certainly ...Interesting discussion/debate. You guys certainly have a broader knowledge of notation than myself... make me want to head back to school!<BR/><BR/>One thing I saw lacking in the analogy between music notation and the offered game notation is that the game notation described the end results, the performance so to speak. As a result, it spoke to the feelings and experiences of the player/audience. Musical notation, on the other hand, is instructions for performance, and don't indicate the feelings of the audience or the experience of the musicians (as participants in the performance).<BR/><BR/>In other words, I would say the only connection musical notation has to the notation discussed above is that they are both notations. The notations capture different perpsectives of information and would be used to different ends.<BR/><BR/>A more interesting notation, and the one I expected to see when referred to this article, would be a symbolic notation for describing the decision points, pacing and results. For me, that would be the useful notation to use as a designer; the notation presented above would also be useful, but only as a more concise conveyance of the results of a play session.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138209556176742762006-01-25T09:19:00.000-08:002006-01-25T09:19:00.000-08:00Good gravy people! He never said this was the end-...<B>Good gravy people!</B> He never said this was the end-all, be-all system, just a starting point. As others have pointed out, this is a tool - something that allows us to understand something better, and thus, gives us power. Also, yes, the comparison to musical notation is imperfect - welcome to the world of similes and analogies. That's how we learn - "This is like that, except for ..."<BR/><BR/>Like any tool, it can be used well or badly. Yes, in the hands of a "soulless" company/producer this would be used to replicate previous game experiences, just with a different coat of paint. How is this different from the majority of what we see today? In the hands of someone skilled/artistic - it could help them structure the game, helping not just point out problem areas but reveal patterns of play (risk/reward, feedback, etc - again, these are fuzzy right now) that are both good and bad. A good artist isn't going to rip out a section just because the graph tells them it's "bad", nor will they insist on leaving in a troublesome part just because some notation analysis says it's "good". I think also there is confusion - just because there's a dip in the "buzz" meter doesn't necessarily mean it's a problem, (unless the designer's goal is to keep it above a certain threshold) in music it's called a rest. <BR/><BR/>I do agree that focusing on "buzz" is a misstep, but at least it's a step. Until we try, there will never be a common language we can use. Like all systems, used slavishly it can become limiting - that's why artists sometimes push, bend or ignore completely the rules. (Sometimes to good effect, sometimes not. The risk-reward rythym of Doom applied to a RTS or an adventure game could be genius, it could be utter tripe, but at least it would be possible.) Yes, this may give rise to the game equivalent of the dissolve-to-blurred-flashback with harps, or the evil twin plot device, or any other over-used, hackneyed music/film/literature/drama device - I contend we already have them, but don't have the language to know it. At least then we'll be able to describe why it's what it is, rather than just say "It's sucks" or "It's fun". <BR/><BR/>-Scandalon (Matthew Parsons)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138094626527196392006-01-24T01:23:00.000-08:002006-01-24T01:23:00.000-08:00Well, a little irrelevant but the Byzantines used ...Well, a little irrelevant but the Byzantines used notes long before the split of the church, so your historic reference is inaccurate.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1138032777291203902006-01-23T08:12:00.000-08:002006-01-23T08:12:00.000-08:00Why not just write some rules and draw a map, like...Why not just write some rules and draw a map, like in a boardgame?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137909632004874662006-01-21T22:00:00.000-08:002006-01-21T22:00:00.000-08:00This is very clearly an analytical tool rather tha...This is very clearly an analytical tool rather than a notation system. The notation system would be the design document. It's a good analytical tool, though.<BR/><BR/><BR/><BR/>I never liked the idea of boiling down games to classical conditioning. I mean, there's some entertainment value for it... but it seems like it runs the risk of removing a critical element that will seem obvious once it's not there. A risk-reward schedule wouldn't have brought about, for example, <I>Shadow of the Colossus</I>. It's possible to analyze such a game from the perspective of risks and rewards - but you can't do it backwards. To use a music metaphor, you can take the algorithms used for analyzing pop music - music that is <I>designed to be enjoyable</I> - and analyze a masterpiece like, for example, <I>Rhapsody in Blue</I>. However, the algorithms used to write pop music are never going to create a song that good without adding an element of inspiration, of artistry.<BR/><BR/>That's no reason not to create such algorithms, because masterpieces are rare, and the people demand to be entertained. But reliance on the algorithms will cripple us and flood the market with soulless marketing-driven exercises in appealing to the lowest common denominator.<BR/><BR/>Your articles are useful for creating such algorithms - they will serve as guidelines for the inspired and the focus groups alike. But I don't think they can ever form a heuristic for "making an excellent game."Markhttps://www.blogger.com/profile/15243016271951485772noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137889792174486832006-01-21T16:29:00.000-08:002006-01-21T16:29:00.000-08:00I think one of the things that made music notation...I think one of the things that made music notation so much more powerful to the medium than the type of notation we've seen in games so far is the iteration time. When you change or adjust a piece of music, you can preview your work in real time with a few musicians or on a piano. When you change a script, you can see it's affect on the plot immediately if you've read the rest of the plot. These mediums both share a linear structure, and fast iteration times, something good games don't always have.<BR/><BR/>Lets say for a second that we devise a really good notation system; something that is detailed enough to describe the systems, yet abstract enough to not be like writting code. Will you be able to understand the results of changes at the rate of music or story notation? Probrably not unless you can run a simulation which shows you results in one form or another.<BR/><BR/>In some ways, higher level languages (such as visual node based scripting) are the closest thing we're seeing to game notation. While other attempts do have analytical uses for game revision, they don't seem to lend themselves to initial concept work because concept work often relies on the iterative feedback provided by prototyping.<BR/><BR/>So, I guess my thoughts are these: Any approach to notate game design without being able to 'run' said game from the notation will mostly be useful for tweaking and understanding existing games; not creating new ones.Jason Boothhttps://www.blogger.com/profile/03832373920590563761noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137868043093240382006-01-21T10:27:00.000-08:002006-01-21T10:27:00.000-08:00Samuel said The critical theories of literature ar...Samuel said <I>The critical theories of literature are analysis techniques and they are applicable across media in general (such as the game meta-medium) though.</I><BR/><BR/>It's Lang not Lit. Lit Crit is undeniably usefull in looking at games as cultural artifacts, but doesn't go far in telling us much about our experience of a game itself, for that, we need to use more Linguistic tools (both prosody and phonetics use notational tools).<BR/><BR/>I read Dincs article as a useful theory of the Language of Games (although possibly, with some advancements, of any structured interaction - be it a UI, debate, football match).<BR/><BR/><I>By focusing on rewards, we are illustrating a crucial part of the player experience</I><BR/><BR/>I can see how a rewards-based notation does make sense but annoyance and frustration are just as important as rewards, 'just one more go, and I'll get to level 2!', and in some games ('insert coin to continue') it's <I>critical</I> to it's success or failiure.<BR/><BR/>Another key element of games seems to be learning, from initial controls to advanced powered-up-combo-move skills, and that this learning, more often than not, performs a kind of meta-narrative to the game narrative (where there is one), and could be introduced into the notation as a simple overlay.<BR/><BR/>I see no reason why entire games couldn't be conceptually sequenced out like that as part of the design process, if they're not already.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137770265670216922006-01-20T07:17:00.000-08:002006-01-20T07:17:00.000-08:00The real question becomes: can a scientific system...The real question becomes: can a scientific system help to encourage creativity? A system such as the one danc proposes may be inaccurate, incomplete, or even downright wrong, but could it still be useful? It would never serve to notate the entirety of a game, but it might be an extremely useful tool of analysis. There may be fierce disagreement as to the definition of "game" or whether science deserves a presence in art, but I think of formal systems as placing a direction to my creativity. Currently I am a massage student. When I learn the basic techniques of a swedish stroke, am I limiting myself by that knowledge? Perhaps, but the theories are still based on a conrcrete understanding of human anatomy and how the body works. Without this knowledge, I could experiment and find out what "feels good," but I'd always be lacking the knowledge of where the muscles attach, and and the stroke should finish. <BR/><BR/>More appropriately, Chinese five element theory lays out a description of the human body based on water, metal, wood, fire, and earth. From a western medical perspective, it is bogus. However, a Shiatsu practitioner (shiatsu is a Japanese modality based on Chinese medicine) can still give a kick-ass treatment. I happen to disagree with the basic assumptions underlaying the whole endeaver. But, it seems to work on some level. Does it still have worth?<BR/><BR/>Danc's system is not comprehensive. It is just a beginning. If you don't like it, don't use it. It's just a tool, nothing more.<BR/>-eAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137754350916147202006-01-20T02:52:00.000-08:002006-01-20T02:52:00.000-08:00Hey Raph, I was all raring to go with a reply earl...Hey Raph, <BR/><BR/>I was all raring to go with a reply earlier, but I've changed my mind on doing that. I don't really find that these internet threads ever go anywhere, despite many years of usenet, forums and blogs etc, and they take away from the energy of actually getting on and creating. It's a bad habit of mine to get misdirected so, but I'm trying to get out of it. <BR/><BR/>So, good talking to you, <BR/><BR/>TadhgTadhghttps://www.blogger.com/profile/14763670950211297013noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137722842302238242006-01-19T18:07:00.000-08:002006-01-19T18:07:00.000-08:00So I of course agree with you that the domain of w...So I of course agree with you that the domain of writing is far far more complex than the domain of music, as regards getting it notated.<BR/><BR/>That said, if you say that words are at the basis of language, then I'll trump you by saying that notes are not at the basis of music, but that timbre and pitch are; the notes in the tempered scale we have today are conventions, not mandates.<BR/><BR/>Prosody does not exist for telling the poet how to read aloud; it exists because it is a notation system for sonic qualities in words. That's an important distinction. Prosody applies in cases where the poem is never meant to be read aloud.<BR/><BR/>Not all notation systems are going to be intended to reproduce a given "performance;" in that sense, prosody is more akin to harmonic analysis than it is to standard notation (which is heavily aimed at melodic information). That's why alternate notations such as chord symbols, tablature, and jazz notation exist.<BR/><BR/><I>What you're guilty of doing here is conflating the superficially similar to make a point while glossing over the deeper difference.</I><BR/><BR/>Heh, see, I think you're ignoring the deeper similarities in favor of focusing on superficial differences, such as size of the problem space.<BR/><BR/><I>Um, Raph, the basic building blocks of writing are words, punctuation and the conventions of sentence structure. Unlike music with its eight notes and a small variety of sharps that repeat in a cycle and produce harmony, writing (in English at least) has over 90,000 words (the notes if you will) which do not have any definitive harmonic pattern to them, and we keep making up new notes all the time.</I><BR/><BR/>Twelve notes (sharp and flat are <I>notation</I> devices, not variants on notes) -- and that's if you stay out of microtones, untempered scales, and Eastern scales, 24 keys not counting variations such as melodic versus harmonic minor, dozens of modes (sort of like keys, only not), and that's not even getting in rhythm... don't sell music short.<BR/><BR/>I also wouldn't sell words short -- sentence structure is somewhere between "significant" and "irrelevant" to language arts.<BR/><BR/>I guess we can agree to disagree on this... I've done quite a lot of formal training in writing (prose and poetry), rhetoric, music theory, and various forms of pictorial art. All I can say is that I see significant commonalities in how underlying formal structures and notations thereof are used by craftspeople in all those disciplines. *shrug*<BR/><BR/><I>the fact is that the sense has been sorely lacking owing to the basic precepts being wrong. In my view. </I><BR/><BR/>What are the basic precepts you advocate?<BR/><BR/><I>*WE* are the big problem in the industry because this is what we do. We abstract things beyond the point of all common sense and lose sight of any sense of the why.</I><BR/><BR/>What is the "why" you advocate? And, don't you think that a "why" may well indicate a general philosophy or aesthetic, rather than an ultimate answer?<BR/><BR/><I>The craft is making the good game, not making the game that you think that people will like.</I><BR/><BR/>Oof. That debate is FAR larger than games. In general, I side, as you do, with the artist. But I am not going to make that a blanket statement -- it's far too debated a subject.<BR/><BR/>Wanting people to experience your work doesn't mean that your work won't come from the heart.<BR/><BR/><I>Game development is an art first and an engineering problem second, not the other way around. All of this theoretical guff is just skirting around that realisation, trying to make it not so because for it to be an art means that it is unsolvable and involves learning how to trust instincts. Something that most developers are very bad at doing.</I><BR/><BR/>To be brutally frank, this is a position on art that I have never agreed with. It's a sort of "naif" approach, that talent and hard work will win you through. But the great artists have ALWAYS been half-scientist about their work. Leonardo da Vinci dissected corpses to examine how to render the play of muscles beneath the skin. Bach was deeply into the science of harmony when he developed the form of the fugue. The examples are everywhere. It has nothing to do with creativity.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137712983565773182006-01-19T15:23:00.000-08:002006-01-19T15:23:00.000-08:00Prosody? The entire concept of grammar? Fluffier s...<I>Prosody? The entire concept of grammar? Fluffier stuff such as the terms metonymy and metaphor, tricks and techniques such as zeugma and onomatopoeia?</I><BR/><BR/>Hey Raph<BR/><BR/>Now that's what I call you're trying to fit a square peg into a round hole. <BR/><BR/>The notation system for music is what encompasses all the functional elements required for the performance of same. Now one may argue that such tools as prosody serve a similar function in telling the poet how to read the poem aloud, but they are not the mechanical notation of the writing in the same sense that musical notes are for music. <BR/><BR/>Onomatopeia, metaphor and the rest are tools of the writing trade too, but none of them consistutes the simple pattern that music repetition is. Every one of the few musical notes is an objective and specific thing, a very simple tonal language, and that is part of the reason of why they can be notated in the first place. Musical notation is a simple language. <BR/><BR/>What you're guilty of doing here is conflating the superficially similar to make a point while glossing over the deeper difference. Musical notation is not a catalog of tricks and it's not a record of emotion. It's a communication system that says 'play this note then this note then this note faster'. And that's all it is. <BR/><BR/>Writing, by virtue of having thousands and thousands of such notes in infinitely more varied combinations, is as such non-notable. There is no simple eight-level scale and meter notation of writing.<BR/><BR/>But why am I arguing this? It's as plain as punch that this is the case.<BR/><BR/>Or is it?<BR/><BR/><I>These are the basic building blocks of writing, and they most certainly DO give us a craftsman's window into the process.</I><BR/><BR/>Maybe not. Um, Raph, the basic building blocks of writing are words, punctuation and the conventions of sentence structure. Unlike music with its eight notes and a small variety of sharps that repeat in a cycle and produce harmony, writing (in English at least) has over 90,000 words (the notes if you will) which do not have any definitive harmonic pattern to them, and we keep making up new notes all the time. <BR/><BR/>They're just totally different things. <BR/><BR/><I><BR/>Making steps on craft is hardly worthless. <BR/></I><BR/><BR/>Indeed, and yet the current range of steps is getting us precisely nowhere except in the rarefied blogosphere where we all write very worthy articles and counter-arguments and - forgive me - the odd book, and at the end of all that nobody likes to be told that their grand theory is essentially built on guff. And yet, personally, I'm thinking that that is exactly what is going on in the sphere and the books and whatnot. <BR/><BR/>What we're talking about here is games, of course, but games is such a protean mishmash of horseshit and half truths and designs that got lucky and copied, and while it's all very noble to try and corral the horses and make some sense of it all, the fact is that the sense has been sorely lacking owing to the basic precepts being wrong. In my view. <BR/><BR/>And second to that, of a generation of developers who are terribly frightened of taking the next real step forward (which is to actually grow up emotionally and start making games that really are challenging) and rather invest a lot of wasted time and effort in an embarassing hunt for a perfect system of bottling the creative, an activity that a child of six could tell us is foolishness plain and simple.<BR/><BR/>We have a lot to offer and a lot of mental power to bring to the table, but the thing that stands in the way of that is ourselves. In otherwords, the problem with game development is game developers. *WE* are the big problem in the industry because this is what we do. We abstract things beyond the point of all common sense and lose sight of any sense of the why. <BR/><BR/>Our problem is that we're all very smart, but by God is there a lack of wisdom in game development. <BR/><BR/><I>And yes, much of craft is going to seem terribly instrumental, driven perhaps by "marketing considerations" (which in my opinion is just another way to say "driven by a desire to get people to actually try the thing out").</I><BR/><BR/>But that isn't the craft. The craft is making the good game, not making the game that you think that people will like. There is such a huge difference in any creative field between tailored-for products and from-the-heart work. The first one is Vanilla Ice and the other is Jimi Hendrix. The first one is transitory means-not-a-whit work that'll be forgotten as soon as its media half-life flickers out, the other is possibly going to sink without trace but at least its honest. <BR/><BR/>They both have an equal chance of failing or succeeding in the marketplace, but the big difference is that Hendrix is worth doing whereas the other is just wasting time solving imaginary problems and conjuring rounds of indecision in the fear that somebody somewhere might say a bad thing about you. <BR/><BR/>Game development is an art first and an engineering problem second, not the other way around. All of this theoretical guff is just skirting around that realisation, trying to make it not so because for it to be an art means that it is unsolvable and involves learning how to trust instincts. Something that most developers are very bad at doing.<BR/><BR/>I should really run a creativity workshop or something for game developers, don't you think? <BR/><BR/>:)Tadhghttps://www.blogger.com/profile/14763670950211297013noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137699023628001362006-01-19T11:30:00.000-08:002006-01-19T11:30:00.000-08:00Oh, and Danc covered most everything else I was go...Oh, and Danc covered most everything else I was going to say. My (admittedly rough) notion of game grammar handles all those games without much problem. I am a firm believer in the fact that there is strong craft (call it "science" if you like) underlying all creative expression, because I've trained in it, so I know for a fact that it's there.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-1137698701905121172006-01-19T11:25:00.000-08:002006-01-19T11:25:00.000-08:00There aren't any 'notation'-style schemes that des...<I>There aren't any 'notation'-style schemes that describe the elements of writing, however, which actually work. </I><BR/><BR/>Prosody? The entire concept of grammar? Fluffier stuff such as the terms metonymy and metaphor, tricks and techniques such as zeugma and onomatopoeia?<BR/><BR/>These are the basic building blocks of writing, and they most certainly DO give us a craftsman's window into the process. You seem to be concerned with things at a purely experiential level, and as any practitioner will tell you, experience is driven by both the intangibles you describe AND by craft.<BR/><BR/>Making steps on craft is hardly worthless. And yes, much of craft is going to seem terribly instrumental, driven perhaps by "marketing considerations" (which in my opinion is just another way to say "driven by a desire to get people to actually try the thing out").Anonymousnoreply@blogger.com