2011/2/15 Eino Keskitalo <eino.keskit...@gmail.com>: > 2011/2/3 Johanna Ploog <johanna.pl...@googlemail.com>: >> The only problem is that the entire tutorial takes about 30~40 minutes >> to play through, so your testers may not actually get around to >> playing the real game. However, I think the time is reasonable (5~8 >> minutes per map), and because of the episodes, it doesn't feel as >> long. > > This is the thought of the testing team (now named "Dungeon Olms") as > well, so we need to reword our aims for the testing. (Was: "to see if > skills taught by the tutorial translate into skills required by the > actual game.") > > I suppose we should concentrate on looking at the general > functionality of the tutorial first anyway. :) We could start with the > problems that were identified by the UP Team: > > # 2.1: Tutorial texts have too much information > # 2.2: Tutorial gives some information about gameplay too soon > # 2.3: Too long tutorial texts > # 2.4: The word “tutorial” raises different expectations than what the > mode actually is in the game > # 4.7: The difference between lower and upper case letters as commands > is hard to pick up > # 4.9: vi-keys are obscure and unintuitive > # 7.1: It is not obvious that resting is the main way of regaining health > # 7.2: Player doesn't realize that corpses need to be chopped before eating > # 7.7 It is not obvious that the player can (and should) move diagonally > > Some of those (such as the confusion about the word "tutorial") are > clearly fixed by now; also, there are specific parts in the tutorial > lessons about 7.1, 7.2 and 7.7. > > We could condense the text points into the following questions: > > * Is the amount of text digestable - does the player read everything > painlessly? > * Is the context of the information correct - does the player feel > like the information is relevant? > > I'm not sure about upper/lowercase, and vi-keys. We could rather ask: > > * Were the controls intuitive and easy enough to pick up? > * Did the testers/each individual tester prefer mouse or keyboard? > * Were there problems in learning the commands? > * Were there problems in remembering the commands? > > And about the individual commands: > > * Are there scenarios within lessons where the information text is > hard to understand? > * Are there scenarios within lessons where it is uncertain what the > player is supposed to achieve? > > Additonally, Johanna identified the following problems with the 0.7 > tutorial, before re-redesigning the tutorial: > > * A lot of commands in a very short time. > * No intuitive breaks between lessons, no re-caps. > * The player gets no time to experiment with e.g. a new combat system > before learning about the next one. > * If you want to go back to re-read a specific part of the tutorial, > you have to re-play through the entire movement section which gets > annoying even with autoexplore. > * Also, the levels could be made to look more interesting. (Should be > a bit of a teaser for the real game.) > > So, we could ask.. > > * Was the flow of information comfortable, or were there points where > there was too much information? > * Was the pacing of the lessons good? Were they divided sensibly, and > were the recaps useful? > * Did you feel you had the opportunity to try out the skills you learned? > * If you wanted to replay a lesson, was it easy enough, or was there > too much re-playing bits you already knew? > * Were the levels visually pleasing and interesting? > > I'm not sure asking about re-playing the lessons (in user testing > anyway). The testing situation is artificial in the way that the > testers are expected to play all the lessons in one go. They could of > course be given the option to replay the lessons as they please (and > of course, quit when they like). > > Another thing to ask the testers, would be if they died during a > lesson, how did it feel? Was it unfair, unexpected, or all right? > > To recap with the full list of aims/questions: > > * Is the amount of text digestable - does the player read everything > painlessly? > * Is the context of the information correct - does the player feel > like the information is relevant? > * Were the controls intuitive and easy enough to pick up? > * Did the testers/each individual tester prefer mouse or keyboard? > * Were there problems in learning the commands? > * Were there problems in remembering the commands? > * Are there scenarios within lessons where the information text is > hard to understand? > * Are there scenarios within lessons where it is uncertain what the > player is supposed to achieve? > * Was the flow of information comfortable, or were there points where > there was too much information? > * Was the pacing of the lessons good? Were they divided sensibly, and > were the recaps useful? > * Did you feel you had the opportunity to try out the skills you learned? > * If you wanted to replay a lesson, was it easy enough, or was there > too much re-playing bits you already knew? > * Were the levels visually pleasing and interesting? > > > Comments! The list is a bit long, perhaps some questions could be combined? > > --Eino >
The timeframe is that on Monday, the Dungeon Olms will turn in their testing plan for the course, and on Wednesday, they'll do the pilot test. They asked today, if it'd be ok to make 0.8.0-a0-5263-gffd1c9c the version for the testing, or if there need to be any tweaks or fixes before the testing. Also, my previous mail is relevant for their test plan. If my list of questions looks ok, I'll forward it to them. One thing that comes to my mind is the ammo quantity bug, where q:n has no effect in the vault specification. I think hasn't been fixed. It affects the ranged combat tutorial, the player runs out of ammo too easily. It could be circumvented by placing several piles of the stones. cheers, --Eino ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Crawl-ref-discuss mailing list Crawl-ref-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
