tag:blogger.com,1999:blog-11719805.post598608964756593733..comments2023-11-03T01:45:11.288-07:00Comments on Lost Garden: Project Horseshoe 2007 slides: Smashing the game design atomDaniel Cookhttp://www.blogger.com/profile/10437870541630835660noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-11719805.post-38397541549581641632008-01-16T05:19:00.000-08:002008-01-16T05:19:00.000-08:00Hi,Em, probably should've said "I'll send it when ...Hi,<BR/>Em, probably should've said "I'll send it when its published!"<BR/><BR/>Still curious about the karate diagram...Anonymoushttps://www.blogger.com/profile/08852086658302034166noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-49594551780000956822008-01-15T14:02:00.000-08:002008-01-15T14:02:00.000-08:00Re: JoshActually, the skill atom idea is built aro...<B>Re: Josh</B><BR/>Actually, the skill atom idea is built around the concept of learning, which comes in many forms, not only acheivement. Your love of arranging and feeling your own improvement fits quite nicely into the model. I recommend you read the Chemistry of Game Design article located here: <BR/><BR/><A HREF="http://www.gamasutra.com/view/feature/1524/the_chemistry_of_game_design.php" REL="nofollow">http://www.gamasutra.com/view/feature/1524/the_chemistry_of_game_design.php</A><BR/><BR/><B>Re: zenBen</B><BR/>Send me your paper! My email is danc [at] lostgarden [dot] com. <BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-60765786977696891352008-01-15T13:46:00.000-08:002008-01-15T13:46:00.000-08:00Once upon a time a man had a computer game, and he...Once upon a time a man had a computer game, and he wanted to make it better, so he added a little process that would take everything that wasn't fun out of the game. But when he started it up, nothing seemed to happen, the little process had removed itself.<BR/>I have a little theory about burnout, it is when people play a game for a reason, but as they play the game encourages them not to play that way, but they keep going out of habit. Eventually they twig this and stop, but they may not know what it was that originally encouraged them to play. I still play tetris quite happily and have never moved onto the "advanced" high scores, I play it because I have a love of arranging and of feeling my own improvement, tetris allows both, as the slow speed-increase allows it to get harder as I get better. I stopped playing my old favourite clone when I was faster than the control mechanism, and the ability to improve maxed out. Finally your skill atoms remind me of levels, just as you might play the same level of a game without progressing, you might play the same skill set over and over for some other part of the experience. Your skill atom system is centred around the ideal of achievement, there are others.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-44410758803519506992008-01-12T14:43:00.000-08:002008-01-12T14:43:00.000-08:00Nice post, one would think it an almost tautologic...Nice post, one would think it an almost tautological proposition but since no one is doing it, past time to be saying 'lets model what experience the player has'!<BR/><BR/>I haven't much to add today, I am working on a player modelling PhD but the doing takes precedence over the talking :D <BR/>Still, I would like to say thanks for an earlier post that alerted me to work by Biederman and Vessel, this has been most useful to validate some of my theory. I'll send you a free copy of the (long, dull) paper :D You don't have to read it!<BR/>Also, I was curious - why pick a diagram of the Shotokan karate kata Empi in your opening slide? Personal curiosity...Anonymoushttps://www.blogger.com/profile/08852086658302034166noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-41678061971511269492007-12-05T16:13:00.000-08:002007-12-05T16:13:00.000-08:00In Reply to the 2nd to last comment ... relax, it ...In Reply to the 2nd to last comment ... relax, it was supposed to be inspiring :)<BR/><BR/>In reply to the comment directly above me ... **SNAP** ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-68076222942737675262007-11-27T13:01:00.000-08:002007-11-27T13:01:00.000-08:00In reply to the post aboveAll religions, arts and ...In reply to the post above<BR/><BR/>All religions, arts and sciences are branches of the same tree.<BR/>-Albert EinsteinAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-58562857373021611812007-11-26T03:54:00.000-08:002007-11-26T03:54:00.000-08:00You shouldn't have posted that last picture. It's...You shouldn't have posted that last picture. It's completely pretentious. How can you compare a bunch of game designers to a collection of nobel prize winners, the greatest minds of their time. "I see the same potential." Maybe it was meant light heartedly, etc, but that's context and we [reading] do not have it.<BR/><BR/>I'm sure you are all intelligent, but keep your feet on the ground, for God's sake. If you were comparable to the likes of Einstein, you wouldn't be designing games, that's for sure.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-46088728118697200612007-11-23T13:43:00.000-08:002007-11-23T13:43:00.000-08:00Great comments! I'm glad the idea resonates. Do sm...Great comments! I'm glad the idea resonates. <BR/><BR/><B>Do small feedback cycles help if your initial concept is completely off base?</B>: Johnh and Travis both wondered if the feedback system would have been enough when there were obviously numerous dysfunctions within the team. Feedback systems are by no means a panacea, but they can help signal failure early in the process. <BR/><BR/>For example in the horror story above, early testing with target customers might have revealed that the fundamental concept was incorrect. All it takes is a few user early in the process to say "You know, this whole jumping idea is kind of stupid. What I really want are ponies!" The red flag is raised by an external source, one that ultimately pays the teams bills. This doesn't always get through, but at least the right signals are being sent into the team so they can have an opportunity act in an informed manner. <BR/><BR/>I disagree that you only need to 'intuitively get' your user. It is certainly important to attempt to build up empathy, but even the most tuned in developers find themselves in trouble when they rely solely on mental models instead of concrete customer evidence. Great design mean repeated putting your product in front of the customer and observing how they react. <BR/><BR/><B>The line between Active and Burnout</B>: The lag time after when in atom was last activated is the variable you'd use to determine burnout. As the designer, you need to set a baseline of what the expected periodicity might be and then test to see what actually happens. If it is a larger meta-game atom that happens every 20 hours of play you might allow for a long time before you mark the atom as burned out. If it is a core atom such as movement or using a primary attack, you might set a very short burnout fuse. <BR/><BR/>It is worth noting that it is highly likely that you will need to adjust your skill atoms as player data is collected. Players will figure out new skills and learn existing skills in ways that you didn't initial imagine were possible. <BR/><BR/>Skill atoms are your theory. The play test is the experiment. This often results in revising your original theory. :-) <BR/><BR/>Setting up the system: This is going to highly depend on your game. The most obvious candidates are web-based projects, but you can achieve similar results if you can push updates to users and you have a net connection. The details of exactly where you add you instrumentation, how often you collect the data, how you store it and how you display it are all wide open problems. Go forth and try something! :-) <BR/><BR/><B>Meeting in Seattle</B>: T.carl, I'm always up for meeting folks in Seattle. Drop me a note at danc [at] lostgarden [dot] com and we'll figure something out. <BR/><BR/><B>Bigger images</B> Here are a couple:<BR/>- http://www.lostgarden.com/files/Tetris%20Skill%20Chain.pdf<BR/>- http://lostgarden.com/uploaded_images/notation-mockup-766936.jpg<BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-54936676112316145102007-11-23T01:39:00.000-08:002007-11-23T01:39:00.000-08:00I am not only grateful for the insights of this ar...I am not only grateful for the insights of this article, but intend to be mildly evangelical about it in my workplace. So frequently the production concerns dictate the design process and allocated resources; that the horror story outlined doesnt sound unfamiliar - and many industry veterans would be lying if they said otherwise. <BR/><BR/>If would be most obliged if you could post higher resolution images of both the skill chain and the activity graphs.Jolyonhttps://www.blogger.com/profile/00514781559951899365noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-54456440982526194792007-11-20T23:01:00.000-08:002007-11-20T23:01:00.000-08:00Danc,As always, your latest post is filled with wo...Danc,<BR/><BR/>As always, your latest post is filled with wonderful ideas and inspiration. I can't help but think about the number of day to day problems developers have that could be avoided using the techniques you suggest. Do you have any advice for how to set up the technology to properly record the data, as well as aggregate it all into something meaningful?<BR/><BR/>Also, I was browsing some of your older stuff and ran into this:<BR/><BR/>http://www.lostgarden.com/bali_Neighbors.htm<BR/><BR/>and couldn't help but notice the similarities to Viva Pinata. Incidentally, what is your opinion on Viva Pinata, and how do you think it compares to your original idea of Neighbors?<BR/><BR/>Finally, I would love to hear your thoughts on Expression Design. What went right, what went wrong. How would you review it in comparison to your competitors?<BR/><BR/>Thanks!Lukehttps://www.blogger.com/profile/09028839300017005828noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-44879432582320531742007-11-20T21:36:00.000-08:002007-11-20T21:36:00.000-08:00"Small build cycles with tons of play testing is j..."Small build cycles with tons of play testing is just about always going to yield better results."<BR/><BR/>Only if the following are true:<BR/><BR/>- Meaningful changes take short amounts of time to make.<BR/>- Only the truly important aspects are reworked between iterations.<BR/><BR/>Otherwise the developer may be either walking in circles, or walking too slowly. It's not enough to go in the right direction, you <B>have</B> to get there.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-85685381652256410142007-11-20T20:09:00.000-08:002007-11-20T20:09:00.000-08:00I believe in that situation, the automated game lo...I believe in that situation, the automated game log analyzer would observe that nearly every time you were presented with a turtle, of the actions available to you (avoid turtle's area of influence; jump over; stomp and leave; stomp and kick at unbounded area; stomp and kick at area bounded on one side; stomp and kick at area bounded on two close-together sides; etc) you rarely chose to stomp or stomp/kick the turtle.<BR/><BR/>A human surveilling a gameplay session in progress would comment that the player never noticed you could kick turtle shells, or never seemed to want to use that ability. An automated parser should detect the same thing.<BR/><BR/>Before you can have behavioral extinction you must have a behavior. I believe a system can easily detect when a mechanic is being used inconsistently across the player population (take it or leave it), or when the mechanic is consistently being tried, used for a while, and then abandoned. If it's being abandoned, what is it being abandoned in favor of?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-22755930516678870592007-11-20T19:39:00.000-08:002007-11-20T19:39:00.000-08:00heh, I hardly ever used the turtle shell kicks in ...heh, I hardly ever used the turtle shell kicks in mario. I'd generally be much happier to just slowly jump on everything's head and explore the level at a slower pace. (Yes you can explore a side scrolling platformer level)<BR/><BR/>Would my behavior pattern be described as skill burn out? Should it be described as such? Should the game change because of it?Unknownhttps://www.blogger.com/profile/13857778855289469682noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-52102001296895446102007-11-20T19:32:00.000-08:002007-11-20T19:32:00.000-08:00I'm not in the industry, just a lowly computer sci...I'm not in the industry, just a lowly computer science grad student. When I try putting on the game designer hat and thinking deep thoughts, the hat falls off. Still: it seems to me behavioral extinction and burnout can be observed in an automated way by measuring player behavior in terms of known addictive behavior models. <BR/><BR/>Think back to reward schedules, fixed and random reward intervals, and behavioral extinction. If your game session analyzer can detect when certain skills can be usefully applied by the player (known/learned/mastered or not), you should be able to detect when skills are available but aren't being used, when skills are being used successfully/unsuccessfully, or when skills are being used at inappropriate times.<BR/><BR/>From there you should be able to detect early player experimentation, skill usage and mastery, the presence or absence of overt reward or punishment, and even behavioral extinction.<BR/><BR/>I like Danc's use of Super Mario Brothers (SMB) as an example. Suppose we are trying to model the effects of "turtle shell kicking" in SMB. What does player frustration and behavioral extinction look like, as applied to that specific atom? Imagine the game notices the first appearance of a turtle, and logs the player's behavior with regard to that turtle. Now suppose the player starts to frequently die from kicking the shell at a wall, only to have the shell bounce back and damage the player. The player becomes frustrated with the effects of this atom, and stops using it.<BR/><BR/>What pattern of events would you see on an event log, if you were manually reviewing the "atom hits" from a gameplay session? Now how would you design an automated system to detect those patterns and label them?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-61008508257125606312007-11-20T09:47:00.000-08:002007-11-20T09:47:00.000-08:00I stumbed on to this site (I forget how) looks in...I stumbed on to this site (I forget how) looks interesting i'll have to read up on it. The tile art is what caught my eye. Anyway I apologize for the off topic post but I have a proposal for you, it is a paid artist position for a project I am working on. Please email me at ssc_at_smithcosoft dot com if you are curious at all.<BR/><BR/>And just so you know said project is a ways from finished so you could work at your own pace (within reason).<BR/><BR/>I look forward to hearing back from you, even if the answer is a "no thank you" or "not interested"Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-63512538610758535472007-11-20T08:09:00.000-08:002007-11-20T08:09:00.000-08:00I'm quite interested in how a state like Burnout i...I'm quite interested in how a state like Burnout is judged. It's not so difficult to imagine the atoms and make the connections, nor to measure their usage, but finding the dividing line between Active and Burnout seems arbitrary.<BR/><BR/>Also, it's difficult to see how the system would yield useful results for the designer given in the case study. Comparing a situation with no testing to a system both with testing and a design visualisation aid such as these atoms changes 2 factors in the experiment, thereby failing to comprehensively demonstrate the benefit of either.Ben Sizerhttps://www.blogger.com/profile/16973645498493273495noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-67157360388339870482007-11-19T08:16:00.000-08:002007-11-19T08:16:00.000-08:00@JohnH: Certainly there were more issues with the ...@JohnH: Certainly there were more issues with the given example team and game than simply a flawed game design core, however given the talk and the audience the flawed game design is certainly the highlight for the crowd.<BR/><BR/>And the ultimate problem is that the example situation isn't unheard of. While I wouldn't call it common, it likely happens far more frequently than anyone would like to own up to.<BR/><BR/>Dan's whole thing here is to get a unified mind set going, and he is modestly proposing it be his system, simply because there is no unified process in the industry yet. Things that we do where I work that seem like common sense, don't happen at other places. Even the things that Dan has in his presentation about getting lots of feedback and tweaking the system to accomadate the feedback which I'm sure many people are "duh", just isn't happening as much as it should.<BR/><BR/>Of course, the factors for the lack of adoption are as varied as the reasons why the example team failed. But you have to start somewhere.<BR/><BR/>Dan - I specifically would like to see larger versions of the skill-tree of tetris, and the two slides on test feedback results. Also, being in the seattle area, I was wondering if there were any local game design informal gatherings that you attend that it would be possible to attend and/or pick your brain at.T. Carlhttps://www.blogger.com/profile/05952726978966520516noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-83061191907681266472007-11-19T02:10:00.000-08:002007-11-19T02:10:00.000-08:00Your idea of including a feedback-response system ...Your idea of including a feedback-response system from the beginning reminds me of a similar view taken by 37signals' book <A HREF="http://gettingreal.37signals.com/" REL="nofollow">Getting Real</A>.<BR/><BR/>Using interactable, usable prototypes from an early stage to get a true feel for what the system does when a user meets it. Instead of writing up countless documents that only prove to further clarify (and then muddy) what the goal of the project is, create what the user sees. Start with the point at which users interact with the software and then work on building functionality into this shell.<BR/><BR/>As for creating meaningful metrics from your skill atoms, I don't see how it would be any more difficult than how some groups currently analyse log reports. In most cases I'm sure it would be simpler to build a framework around the feedback from atoms and this definitely excites me.<BR/><BR/>More agile ideas coming together, bridging design and development? This is what brings people forward, the aspect of groups working towards a common goal.<BR/><BR/>As Einstein once said, "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."Simon Dowlinghttps://www.blogger.com/profile/11889284080287138916noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-39205825570849207762007-11-18T21:24:00.000-08:002007-11-18T21:24:00.000-08:00Small build cycles with tons of play testing is ju...Small build cycles with tons of play testing is just about always going to yield better results.<BR/><BR/>A large part of the benefit from the practice of egg head analysis is simply that someone is paying attention to design and test results.<BR/><BR/>Having said all that, the skill atom idea sounds really neat, I've been watching some of the "player stats" things that appear in Team Fortress 2 along with some of the achievements that happen in XBox, Steam, Battlefield etc.<BR/><BR/>I think this skill atom thing could be really interesting for the players themselves to look at if it can be well visualized. <BR/><BR/>Obviously not for all users, but being able to see what you're doing well and where you are on the "skill curve" could be quite a motivator for the hardcore crowd.<BR/><BR/><BR/>In other news, like JohnH said, your story about the designer and his team of slave monkeys has a whole lot of things wrong with it along with the bad design choice and late play testing.<BR/><BR/>I think if the same designer was given tight play testing and feedback on who gets the skill atoms when you'd probably end up with a higher quality Zelda clone with well tuned jump puzzles that the target audience still wouldn't buy.<BR/><BR/>It sounds like what was required was a jump to a completely new game idea, which I think would be even less likely with small iterations and lots of tester feedback.<BR/><BR/>Failure to understand your target audience is a real killer, because your target audience generally isn't going to explain themselves to you, you've just got to intuitively 'get them'. <BR/><BR/>Analysis is just a dissection of your understanding once you've got it, it won't deliver your initial understanding.Unknownhttps://www.blogger.com/profile/13857778855289469682noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-82742896713222832602007-11-18T19:20:00.000-08:002007-11-18T19:20:00.000-08:00This is interesting, but I'm unsure how useful it ...This is interesting, but I'm unsure how useful it all is. Of course designers should keep the player in mind, run experiments to see what works, and refine the core system to make the game accessible to many. But I wonder how useful this way of explaining it all is.<BR/><BR/>From your description, it seems the problem with the designer in the example story wasn't that he was trying to make a game ill-suited to the license, but that he eventually made a late change without fully considering the ramifications. That no one would have noticed that it broke the later levels until a whole month later seems odd, like it speaks of other, unmentioned problems with the team.<BR/><BR/>I'd also take issue with the structure of the team. No one likes to be chained to a project they know is going off the rails. Why didn't anyone tell this to the designer instead of just blindly walking off the cliff? If they were afraid for their jobs, if they weren't listened to, if they were listened to but over-rulled peremptorily, if no one had the capacity of seeing the game was in trouble, those are also problems that could be solved in ways far different than inventing a new way of thinking about the process of game design.<BR/><BR/>I dunno. I could well be wrong I suppose. It's certainly a jarring story.Rodneyliveshttps://www.blogger.com/profile/03476187929555342435noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-21011953926199940782007-11-18T17:41:00.000-08:002007-11-18T17:41:00.000-08:00Most of the images are just for flavor. Let me kn...Most of the images are just for flavor. Let me know if there are any specific ones that you want to see more clearly. <BR/><BR/>As you say it doesn't need to solve all the problems at once to be useful! This is a key insight. :-) <BR/><BR/>Something I need to make clear in a more complete writeup of the whole test driven game design concept is that skill atoms are not intended to be an alternate description of the game. I believe that the game is ultimately the code. Anyone who attempt to break that golden rule by creating a parallel all encompassing game grammar has permanently entered ivory tower land, IMHO. <BR/><BR/>Instead, think of skill atoms as a useful view on your game that provides insight into the player experience. They can let you know when the player does the things you hope he/she will do. They can let you know when the player doesn't do those things. And due to their relatively simple structure, they perform this service in a manner that is highly amendable to automation, remote play testing and regression testing. <BR/><BR/>Such activities are all useful and worth doing as a matter of course. Wax on, wax off. There is also another benefit hidden away in the mundane practice of testing your designs. It requires you to be thoughtful and exacting about how you define and think about skills, feedback and learning within your game. In the long run, this the difference between the naive writer who merely jots down what 'sounds right' and the writer who knows how to wield the vocabulary of their trade with penetrating precision. <BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-89835319083030848302007-11-18T00:09:00.000-08:002007-11-18T00:09:00.000-08:00Interesting. I wonder how "encodable" an Atom real...Interesting. I wonder how "encodable" an Atom really is: whether it's really possible to describe a complete game design in concrete terms that an automated system can process. Even if there is nontrivial design work that can't be encoded as Atoms, it seems like there could still be value in an Atom-like language. It doesn't have to solve all the problems at once to be useful! :)<BR/><BR/>(Also: your images link to copies of the same size rather than more-helpful larger versions; this means some of the slides are completely unreadable!)Unknownhttps://www.blogger.com/profile/05499323478151576011noreply@blogger.com