If you build it they will come

So after getting used to the Makey Makey system and playing around a little bit with some initial ideas. I got further into paper prototyping in the hope of building something more to scale that would work.

Paper Prototyping

After some more work with paper I felt that my basic concept of the lock was going to work with the Makey Makey system. However, the issue that I kept hitting upon was the contact points and ensuring that they were triggering accurately.

Paper Prototyping

I had build a larger scale system with two points so that I could move my dial through the two gates and see what response would come from the digital prototype. Despite changing my code to listen for KEY_UP inputs rather than KEY_DOWN inputs I was still having issues with accuracy.

Paper Limits

While the Key down looks to see what the keyboard button is lifted before executing the block of code the issue that I kept running into was that the paper and materials I had been using were too flexible. They were not strong or rigid enough to ensure a smooth contact and disconnect. Rather they were making and breaking contact multiple times when moving through a gate. Resulting in the digital lock moving a minimum of two to three points when it should only have moved one.

Take two

Fast Forward a few days and it was time to try something more durable. I Found some wooden kebab skewers laying around at home and quickly took to hacking them up to try and create some kind of frame which would be able to hold my lock points. Unfortunately the construction process was longer than anticipated and with a presentation for another subject looming this was the limit of my progress for last week.

Now its time to enjoy the week off and really get stuck into construction phase.

Redesigning the Restaurant Experience

Experience Prototyping

This week we looked at experience prototyping. Which is essentially taking your prototype into its context of use and allow users to test it. It makes a great deal of sense and it is a nice way of bringing the design process loop back around. Start by placing yourself as a designer in the users context to empathize with them. Ideate and prototype (locking yourself in a tower optional) and then place your design artifact back into the context of your users. Failing this try as much as possible to simulate the context so that testers can have the same experience with your prototype as they would in the real world.

I peeked briefly at the IDEO paper about experience prototyping. Their definition of experience puts into perspective the sheer difficulty of designing a successful product, its not just about how the artifact works and how users interact with it, but a whole raft of dynamic elements which make up the experience.

Armed with this knowledge its time to jump into this weeks lecture exercise which was to look at the experience of a restaurant and come up with ways in which it could be improved with technology.

Exercise

Q1: What is the existing experience from different stakeholder POVs?

I am going to try and keep it brief because I feel like just this question could take a whole blog post. When you consider all the different types of restaurants, some have street dining which would make the general public a stakeholder (especially if there is smoking) and the restaurant managers and owners are another major stakeholder. For the sake of this post I will look at the three major players we defined in the lecture:

1. Customers (Diners)
2. Wait Staff
3. Chefs (Cook Staff)

In terms of the customer the service or experience they get from a restaurant is a transaction in which they are provided food and drinks for a price. Wait staff and waiters are the middle man between the customer and the chefs, they take the order information from the customer and provide it to the chefs. Chefs deal with the preparation of meals and the cleaning of the kitchens.  

Q2: What external/internal factors impact on the experience?

Customer External

• Seating (Chairs, Stools, Standing, Booth Indoor, Outdoor)
• Environment (Temperature, weather, noise, other customers, time of day)
• Wait Staff (Attitude, attentiveness, service)

Customer Internal

• Appetite (Everything tastes better when your hungry)
• State of Rush or Relaxation
• Familiarity with restaurant (The place I always go because I know it is always good affects my perception)
• Level of Intoxication

Wait Staff External

• Management
• Other Waiters
• Customers
• Chefs
• Time of day

Wait Staff Internal

• Attitude 
• Enthusiasm for their job
• Stress level
• Level of competency (trainee or experienced)

Chef External

• Flow of customers
• Other Chefs
• Suppliers (for ingredients) 
• Kitchen layout
• Kitchen tools

Chef Internal

• Skills (Cooking abilities / specialties)
• Motivation
• Workload (stress level)

Q3: What aspects of the existing experience could be enhanced / augmented / supported with technology?

Almost every aspect of the experience could be redesigned. While it may be easier to focus on the external elements to augment to improve the experience it is more important to recognize the relationship between external factors and users internal states. While we may assume that customers hate to stand up and always want to be seated, this may destroy customers perception of the environment and have a negative impact on their experience. It is this subtle difference that may differentiate one bar from another or one bar from a lounge. 

Customer Experience

Transitions glass placed in the restaurant to minimize glare when sitting near windows and prevent sunburn when sitting for prolonged periods.

Wait Staff Experience

Coloured lights on customer tables which change colour depending on the waiter you are being served by, so that staff can keep track of the patrons they are serving. 

Chef Experience

Set up a social media account for each table in the restaurant then provide a live stream of the posts from customers for the chefs to see, so they can get immediate feedback.

Q4: How would introducing technology in to this context change the experience?

Customer Experience
If this change was implemented it could have huge impacts of the overall aesthetics of the restaurant itself. There might need to be extra lights added to ensure that the space was still adequately lit.

Wait Staff Experience
If this change was implemented it may make wait staff less attentive to other tables not of their own colour. While giving waiters direct ownership of a subset of customers may improve their service to those customers it could decrease their attentiveness to other customers and lead to an overall drop in service level.

Chef Experience
If this change was implemented it would change the dining experience for the customers as they might feed obligate to leave a review, or be influenced by the decisions of people who ate at the table prior to them.

What experience scenarios might you test with the technology?

Customer Experience

You might provide customers with sunglasses to wear while they are dining at a restaurant and have them interact as they normally would. You could observe the effects as well as interview them afterwards to find out how it affected their experience.

Wait Staff Experience

You could test this type of system with a low fidelity post it style process where waiters would leave their coloured post it on tables which they were serving. This could be a good way to test what position to place the lights and if wait staff behaviors differed between tables they 'owned' and did not own.

Chef Experience

This scenario experience could be simulated by having a small phone / tablet / screen set up in the kitchen with a chefs social media account up. Then people running the testing session could ask users to photograph or comment on their food and send it to the account.

Time to Evaluate

Final Survey Questions

The qualitative feedback section of my Survey contained only two questions:

• Finish this sentence. After opening the prototype lock i felt...
• Please write a short sentence describing your experience rotating the dial

I got much better feedback from these questions than I did on my original survey. I think by providing clearer instructions of what I type of feedback I was hoping to achieve I ended up with a much better result.

Question 1 Results

Responses for the first question were largely as I had hoped, evoking nostalgia, satisfaction and a sense of achievement and even vindication in users. This sense of accomplishment was exactly what I was setting out to achieve when designing the lock and what I was trying to capture with this question (its nice when things work out).

Answers to this question also brought up some further points for improvement, suggesting a change in unlocking sound to create a more outlaw style theme and to ensure the audio feedback would play as the person moved to the key point. Not as they landed on it, to avoid them from passing over it too many times and having to restart. 

Also confirmed my initial thoughts that the lock controls were a little awkward and raised an important point about the reliance on audio. If this channel is unavailable or if there is significant background noise the game in its current state would be unplayable.

Question 2 Results

This is where most of testers vented their frustration while some testers remarked that the controls were smooth and that the game was fun, there was a lot feedback on how to improve the system. Again the main take away was that the audio clicks needed to play sooner to ensure users would not overshoot the lock points and subsequently have to restart.

Observation Results

Tester 1: Observations

• Tester starts with Physical lock 9:10am
• Unlocked in 1min 30secs
• User only took one attempt before moving onto digital lock
• Tester starts with Digital Lock 9:14am
• 4 Locks completed in the 5min time frame
• 1st lock took the longest to complete
• Subsequent locks were opened in around 30seconds
• "Damn it went past it again"
• More support for changing the audio timings
• User was very engaged with the prototype, there were signs of concentration
• User used the spin method on the first lock
• subsequent locks used the tap method

Tester 2: Observations

• Tester starts with Physical lock 9:27am
• Unlocked in 1min with no real issues
• Checked password between moves
• Again only one attempt before moving onto digital
• Tester starts with Digital lock 9:30am
• 8 Locks completed in the 5min time frame
• 1st lock too the longest
• 5th and 6th lock only 15 seconds for completion
• 7th and 8th took beetween 20-30 seconds
• Clear pattern of learning after the first two locks, from locks 3-6 seemed everything really clicked for the tester. (excuse the pun)
• Used tap method throughout the test

Tester 3: Observations

• Tester starts with Physical lock 9:41am
• Unlocked in 1min 20secs
• One attempt before moving onto digital lock
• Tester starts with Digital lock 9:43am
• 3 locks completed in 4mins
• 1st lock took 30seconds
• 2nd lock took 45seconds
• Used tap method

Tester 4: Observations

• Tester starts wtih Physical lock 9:49am
• Reading through password before attempting to fix the lock
• One attempt before moving onto digital lock
• Tester starts with Digital lock 9:51am
• 3 locks completed in 5min time frame
• Some technical issues 2nd lock only took 30seconds
• Used the tap method
• experimented with spin on the first lock

Tester 5: Observations

• Tester starts with Physical lock 10:54am
• Was unable to unlock and opted to move to digital version
• Tester starts with Digital lock 10:56am
• 5 locks unlocked in 5min time frame
• User had issues with directions and keyboard mapping
• Settled on the tap method of controlling
• used the spin method for the first lock

Tester 6: Observations

• Tester starts with Digital lock 11:17am
• 2 locks completed in the 5min time frame
• Lots of moaning and groaning
• User was explaining that they kept just missing the point or just going too far
• Used a combination of spin and tap methods

Evaluations

Based on the observations and survey results I am very happy with the difficulty level of my prototype. While it was reviewed and was observed to be quite difficult while learning the sense of achievement that was reported was what I was hoping for with this game concept. I will be keeping the combination lock system as it gives a real safe cracking theme and the current code promotes precision. 

From the observation and the feedback it is also clear that the lock code needs to be further tested to ensure that it is stable and working after resets. But also that the sound clips need to be moved to ensure that they play while moving to the point rather than once the correct point has actually been selected.

Overall I feel like this was a much more successful testing session and am looking forward to implementing these changes into the design while also building a physical controller.

IP1 Evaluation: Did I get what I wanted?

What did I want?

From my statement of delivery I was hoping to achieve several goals and answer multiple questions about my concept with this prototype iteration. The big thing I was hoping to find out was how users would interact with the prototype lock and whether they would spin the dial or rotate it slowly point by point. Additionally I wanted to explore:

• Difficulty of the locks
• Feedback and if audio was sufficient by itself to support the interaction
• Difficulty Vs Reward and users feelings after opening the lock

How I go what I wanted?

I used an online survey to capture testers feedback immediately after their experience with the prototype. I also made a conscious effort to move away from testers while they undertook the survey, I learnt from the previous session (as both a tester and testee) that survey responses will be biased if they are observed. So I endeavored to make the survey experience as anonymous as possible given the classroom context.

I also observed each tester who participated and took notes in about the following aspects:

• Number of times unlocking physical lock
• Time taken to unlock physical lock
• Method used to unlock digital lock
• Preference and Approaches to unlocking
• Number of digital locks opened in 5 minute period
• Time taken per lock

I was also going to observe the number of times the reset button was pressed but due to technical issues with the prototype this number would have been heavily inflated and so was not recorded.

Results

Survey Findings

The results from the first two questions were very encouraging with all testers responding yes to both questions as shown below:

Question 1 Results

Question 2 Results

This was a relief as one of my reflections from my first testing session was that I did not stick well enough to the testing process which effected the quality of feedback I received. This time I actually brought a script which I ran through with each tester and provided a full overview of the session. While this made the sessions run a little long (only 6 participants) I feel that I helped the overall quality of results.

The results from question three helped to further understand the audience.

Question 3 Results

From this results as the vast majority of users had a reasonable level of familiarity with combination lock systems, I have decided to stick with this method of controller for the physical prototype iteration. I was initially concerned that the control would not be intuitive but this result shows that it should be feasible.

Question 5 and 6 were designed to look at the interaction method of the lock and how well it mapped to the physical lock. 

Question 5 Results

This result will be explained more in the observation section, but it became clear that the digital lock should have had an inverted control system (right arrow increase lock number, left arrow decrease lock number) rather than a direct mapping of the interaction.

Question 6 Results

Despite the dial not rotating as the majority of users expected there was a clear trend that users believed that the both locks controlled in a similar manner and opened in a similar way. This was the goal of the prototype and helped to solidify the design choice between a free spinning lock and a discrete feedback lock. 

Questions 4 and 7 were designed to evaluate the difficulty of opening the locks and how well the two (physical, digital) mapped.

Question 4 Results

Question 7 Results

I was glad to see that these two graphs overlapped to a large extend with both locks representing a similar level of difficulty. I was surprised to find that the physical lock where you are given the password was so difficult and the digital lock was perceived as easier to unlock. In hindsight a question about how appropriate the difficulty level was, should have been added to the survey.

Question 10 sort of answers this question by asking how long the passwords should be.

Question 10 Result

It is interesting that while testers generally rated the lock as difficult the no one thought that the passwords should be made shorter. While the majority think the 3 key is correct i was surprised that others opted to increase the number as well. This is something that can be further developed in additional prototypes with lock difficulty scaling and password numbers increasing as levels are completed.

Question 8 and 9 were looking to see how effective the prototype was at providing feedback to users on how the unlocking process was progressing.

Question 8 Result

Question 9 Result

This result is somewhat confusing as I was expecting question 9 results to be worse than question 8 results if testers found the feedback mechanisms were lacking. Perhaps this was due to my explanations providing too much detail in the instructions of how the system worked to testers. I still think a secondary visual feedback channel will need to be added for the next prototype to help users through the unlocking process and let them know which direction they should be turning the dial.

This blog post is already over the TLDR status, so I will leave the final evaluation and the observation results for a separate post.

Makey Makeying it Work

This weeks workshop we started getting hands on with the Makey Makey and playing with physical inputs. It was definitely fun experience games like PacMan in a different way (multiplayer each player controlling a direction) was super fun.

After the session exercises we had some free time to play around with the Makey Makeys and try to get our interactive prototypes working. My hacked together paper set up is shown below.

Early Lock Prototypes

After this initial playing I can see that for the next few weeks I am going to need a lot of aluminium foil. The other thing that became obvious is that I am going to need a larger scale lock to make sure that I can get enough contact to rotate the lock correctly. My initial idea is to make a circle which has a number of tabs on it representing the points on the dial and some sort of top with an arm which will make contact with the tabs as it rotates.

Should this style of set up work I will hopefully only have to change my prototype code slightly so that it listens for KeyUP events rather than KeyDOWN events. So that when the arm stops making contact with a point the dial on screen rotates one point.

Physically Alternative

Dreaming Up Physical interactions for Email, Twitter and SuperMario

This was (and still is) one of the most challenging in class exercises so far. I spent most of the time in class staring at my page trying to figure out what was wrong with the current interactions and why they should be changed or how they could be changed in a way that might actually improve the experience. Needless to say there was not a great depth of interactions that ended up in my exercise book. So I am going to follow the instructions from start to finish and hopefully by breaking it down I can come up with five different interactions.

Email

Elements and Controls of Application

To get some inspiration I firstly pulled up Thunderbird and had a look at the interface to figure out exactly what I use (or dont use) it for.

My Boring Emails

The controls of the application itself were fairly simple. Mouse clicks and key presses with the occasional right click or drag being useful or required in some situations.

The elements and actions were more complex. There was the obvious, get message, send message, reply, forward, delete, archive, junk. But then there was also chat and address book functions which I did not really know about. Then there was also the tagging system the staring system the folder system.

Thinking about these I was able to come up with a few different interactions.

1. I noticed that my folders were all pretty useless and not very well maintained and I had a lot of old junk. The idea would be to have a small physical filing cabinet next to the PC set up which would have the draw open further and further for each email that was just sitting in the inbox without being filed.
2. The second idea came about from the inevitable spam that come through my emails. A simple digital click with a smiley face. The face would be happy when you had more non-junk mail and sad when you received a lot of junk or bills (no one likes bills) maybe even a shocked face for when an email from a new sender arrived.
3. Thinking about tagging, it always seems like more effort than its worth. Lots of clicking and sorting and clicking and sorting. This idea would have a projection of your inbox onto a tablet and allow you to use different colored highlighters to tag and sort your emails by coloring them.
4. I am not sure how well this idea would work and perhaps it is better suited to twitter but I will leave it here. The idea is having a old vintage scale with the two measuring cups, one would represent emails coming in the other emails coming out. The scale would adjust as you send and receive emails.
5. My last idea is similar to the first Idea and is the one I came up with in the lecture which was to have a small postbox setup where emails would be printed on post-it notes with the title and sender.

Twitter

Elements and Controls

While I am aware of twitter, how it works, and even have an account. I would not say that I have any real understanding of the twitter space and what it is all about. But just looking at the landing page I can see I can tweet, retweet, follow, tag, and favorite.

1. The first thing I thought of was a collection of Hashtag stamps which could be stamped onto a tablet or screen to add the hashtag.
2. The other idea I had was some sort of token or avatar which you could place onto something or someone to start following them on twitter. Kind of like a QRCode  type thing but creepier.
3. A retweet bird call whistle which would retweet the tweet you were currently looking at.
4. A set of clouds showing the top trending topics, tapping one of the clouds would read the tweet out to you.
5. Tag budget charm. For people who use excessive hashtags. At the start of the day you can allocate an amount of tags you can use. Every time you tag your number of available tags counts down on your charm until you can no longer hashtag.

SuperMario Brothers

Elements and Controls

The classic platforming game. Left,right,up,down, A, B. 

1. First idea is a power glove type system which becomes activated when you get the FireFlower power up. You must then make a certain action to shoot fireballs. 
2. Next idea is a classic Mario pipe (the ones you can go down) as the controller. The pipe can spin left or right to more in the direction and you can press it down to jump.
3. A miniature flag pole is placed beside your computer. At the end of every level you need to raise the physical flag before you can jump to the flag in the game and complete the level.
4. In keeping with the literal adaptations. A controller which is a plunger (because hes a plumber of course). Plunger works like a normal joystick but you can plunge it to make him jump.
5. AR projection of the game where you use your hands to control directions and flick up to make Mario jump.

Exercise Reflection

I feel like the challenge with this exercise was thinking outside of the box. Perhaps I am just too familiar with keyboard and mouse and they are my preferred control system. But I really struggled to come up with ideas that felt interesting and were not just representing the game or an aspect of the concept in a different way. While I think there are always interesting ways to represent data, I had not considered as much changing the way I interacted with applications I use regularly.

Testing the Testing

In this weeks lecture we looked at how to create effective testing sessions and ensure that we ask effective questions which will provide useful feedback. By evaluating our previous user testing questions from our video prototype.

From the initial look at my questions, I do not think I feel into any of the major traps (although some questions could be a little more specific) but there are still some areas for improvement. Some questions could have been reworded while others were qualitative where being quantitative may have been a better option. Each question is explored in detail below.

Q1: The Game inspirations were easily identifiable

Likert Scale from Strongly Disagree to Strongly Agree. This question was qualitative in nature looking to see if users remembered the two games mentioned in the video. This could have been re-phrased and been done with checkboxes instead to make this into a more quantitative measure. Showing that users got the 2 inspirations would have been more valuable than their perception of how hard it was to identify them. Even if they agreed they were easy to identify this question does not capture if they identified them correctly.

Q2: The purpose of the game was difficult to understand

Likert Scale from Strongly Disagree to Strongly Agree. While this question is also qualitative it may have been more effective as a quantitative measure. Also purpose could have been rephrased as goal, as some users may not see a purpose to games, where as the goal or objective of the game may have been more applicable. 

Q3: The game controls were clearly explained

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. The control system contains multiple elements it may have been better to separate this question into smaller parts (I guess maybe somewhat compound) 

Q4: The controls provide an interesting method of interaction

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Need to rephrase interesting if looking to specifically test for uniqueness of interaction. Different users may find different systems interesting.

Q5: How would you improve this game?

Open Text answer field question, capturing qualitative information. While the question could be a little bit more specific, from looking at the feedback it is clear that this questions needed a better outline on how to answer it.

Q6: The Video footage was poorly produced

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Could be a littlle bit more specific, or alternatively follow up with a open text question if they disagreed.

Q7: The Video sound was clear and understandable

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. COMPOUND, need to be over two different questions.

Q8: How would you improve this Video Prototype?

Open Text answer field question, capturing qualitative information. Again more indication could have been given on how the questions was to be answered. E.g write a short sentence indicating how would you improve....

Q9: The Testing method was well explained

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. What the testing method was could have been better explained in this question. So that users better understood which aspect was being critiqued.

Q10: The Survey was too short

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Could have been quantitative with a simple yes or no answer.

More Code Planning and RESULTS

I had another more in depth look at the CRC card concept after the lecture and followed the process a little more thoroughly for the classes that will be specifically important to completion of prototype 1.

CRC part 2

I found that by using the Class HAS format made it a slightly easier way for me to understand what was happening and which parts were static and which were dynamic. This also lead me to see that by physically looking at the lock it did not have any points on it. The points were on the dial and so I Needed another class for that.

CRC part 2

Again looking more in depth I figured I would need some sort of reset functionality which would reset both the dial and the lock (set progress to 0/n). This could take the form of a button which would need its own class to display on the stage. This is something I will need to flesh out more. The sound class was fairly simple as sound contains the sound bytes as well as an x y position.

CRC part 2

Breaking down what each of the class objects CAN do. Again I found this a really good way to conceptually get my head around what I wanted each thing to do and the practical limitations I might hit when trying to code. After playing with my combination lock for a few minutes it dawned on me that the lock cannot spin and that the dial (lock face) was a separate entity that spun.

CRC part 2

CRC part 2

These last two extensions of the CRC cards I found very helpful overall is solidifying my approach to my code. Logically thinking through which elements of the game need to TALK TO each other and what information they need (or listen for) helped to make sure they were correctly compartmentalized and that I had an actual understanding of what they needed to be doing to work together in the prototype.

Getting Flashy

Armed with this new found understanding and (over) confidence I dove into ActionScript and started to rustle together some code. At the end of the week I ended up with a very simple implementation of the lock and its first two attributes (along with comments for days). State and Password.

I manged to complete the implementation of a three key password for the lock system which would generate a random combination each time ;the script was run with each password ensuring combinations numbers were between 0 and 30 while maintaining a left right switch and a decent (yet random) spread.

Overall I am feeling pretty good for my progress thus far which I have made in only a single workshop session. With a full week before the prototype submission I am hoping that the rest of the code will be just a smooth to implement now that all the planning has been done.

Class Responsibility and Collaboration Cards

This weeks lecture was looking more at action script and helped to reinforce some programming concepts of ActionScript. I am glad that I have already done Python coding and JavaScript in the previous semester as this ActionScript work is helping to cement areas that I am already familiar with.

Its also nice that I did not work a lot in JQuery last semester as the ActionScript syntax is very similar to vanilla JavaScript, so I have yet to find myself struggling as I did when trying to learn Python and JavaScript simultaneously.

The main take away from this weeks lecture was the concept of  CRC cards to planning out our prototypes classes. Breaking down the individual elements of the prototype into what values they contain, what actions they take, and what other classes they need to interact with. This process has made me think a lot more about the design of my code and what parts can be recycled and what parts I can get away with hard coding.


From my initial time is the lecture I came up with the following classes:

In lecture Card

PLAYER:

Attributes

• y Position (Will only be moving left and right)
• x Position
• Inventory (To hold Treasure)
• This was something that I initially had overlooked. In my head you just get the treasure but I had not considered where it would be stored until doing this exercise

Abilities

• Move right (Considering a system where player cannot move back but will need to test)
• Add Item (Or take treasure)

Collaborators

• Screen (To know where to be)
• Lock (If locked cannot move past dumpster)
• Treasure (To pick it up ^.^)
• Dumpster? (Will it be enough to know about the lock and the treasure?)

In lecture card

LOCK:

Attributes

• Password (Numbers in an array)
• State (Locked or Unlocked)
• x Position
• y Position 
• Indicator (Some way of knowing which value on the dial is active)

Abilities

• Unlock
• Originally had spin left and right but have subsequently moved this to a new class called dial after further looking at the class cards.

Collaborators

• Dumpster
• Combo Panel (Help Panel?)
• Sound
• Stage
• Dial

In lecture Card

DUMPSTER:

Attributes

• Lock
• Contents
• x Position
• y Position

Abilities

• Open
• Empty? (Seems like a duplicate if player has take item)

Collaborators

• Player
• Lock
• Treasure

In Lecture Card

COMBINATION PANEL

The combination panel came about from the exercise as an idea of how to help communicate to the player what actions they needed to take to unlock a lock.

Attributes

• Lock Progress (How many off the password numbers have been hit)
• x Position
• y Position
• Turn Indicator (Which way to turn the lock next)

Abilities

• Display direction (Which way to turn)
• Display Number (eg 1/4 numbers hit)

Collaborators

• Lock
• Sound

In Class Card

SCORE

Another aspect of the game which I had previously not considered, how does the user know how much more money they need to collect or what their goal is.

Attributes

• Target (Money to be earned)
• Current
• Progress (Current % of target)
• x Position
• y Position

Abilities

• Update (Refresh score when loot is collected)

Collaborators

• Treasure (Maybe?)
• Player

In Class Card

SOUND

Attributes

• Volume
• Playstate (Playing, paused, off)
• Sound (The sound clip itself)

Abilities

• Play Sound

Collaborators

• Lock
• Combo Panel

In Class Card

TREASURE

Attributes

• Value
• Image

Abilities

• Obtain (Probably another duplication with players take item)
• Display (potentially some sort of animation also)

Collaborators

• Dumpster

Implied in most of these cards in the fact that they will need to collaborate with the stage and have both and X and Y position on the stage to display. I did some more refined work on the cards but it will have to wait for another post.