Puzzle Game Project 2

From MultimodalEnvironments

Contents 1 Problem Statement 2 Scope 2.1 Improve existing functionality through: 2.2 Add new functionality through: 2.3 Puzzle Ideas: (Choose One) 2.4 Environment Design: "The Collision Game" 3 Evaluation 4 Group Member Roles 4.1 Andrew 4.2 Dustin 4.3 Ryan 4.4 Wenhui 5 Links 5.1 Internal 5.2 External

Problem Statement

The first Puzzle Game Project demonstrated our environment's ability to guide a user familiar with SMALLab, but unfamiliar with the specific interaction, through a series of tasks exploring some affordances of the SMALLab environment. The game, however, was limited in scope (three interactions, only one of them game-like) and we did not complete a significant evaluative portion of the project.

To build upon our previous success and address weaknesses in our solution, we propose to refine aesthetic and technical areas lacking in the initial system, build one additional puzzle environment, and perform a small user-study with users from outside the AME/SMALLab context to evaluate the effectiveness of different combinations of graphics/sound feedback at guiding unfamiliar users through the game.

Scope

Improve existing functionality through:

• transitions
• art sets
• control panel for Java game engine
• enforce collisions (ghost cursor)
• sound sets

Add new functionality through:

• new "level" or game mechanic
• "basic" art set, "basic" sound set
• text cues
• timing
• end state
• new games

Puzzle Ideas: (Choose One)

• marble platform
• magnetic objects
• collision game (*)

Environment Design: "The Collision Game"

• For implementation details, check the Puzzle Game 2 Specification
• For timeline, check the Puzzle Game Project 2 Timeline

Evaluation

A control panel will be introduced in order to switch out graphical sets and cues. It will also be used to provide feedback through timing results and cue counting. The users will be evaluated by these quantitative, hard results. The user will be given a set scenario to solve the puzzles. The results will tell what graphical set was used, what (if any) cues were used, how many cues were used, and how long it took to solve each puzzle. The user will then be asked a series of questions to further back-up the hard results with more qualitative results. We will also take notes while the user is interacting with the system so that we can better evaluate the results we gather (e.g. if the user was more interested in exploring the space or focused on solving the puzzle).

Time allowing, we would want to test the user again with a different set of parameters in a different set scenario, log the hard results, and then get a comparative evaluation from the user with a follow-up interview, knowing that the user was already familiar with the environment and knew how to solve the puzzles. These results would be used to further back our conclusions from the initial results, or even change our conclusions entirely.

Group Member Roles

Andrew

• In-discipline
  • Assisting Ryan with programming
  • Taking lead role in coding:
    • algorithms for collision detection
    • game mechanics for collision game
    • control panel development
• Transdisciplinary
  • Evaluation of user interaction by:
    • Preparing scenarios
    • Constructing and conducting controlled user interviews
    • Reporting quantitative results
    • Reporting qualitative results

Dustin

• In-discipline
  • Developing interactive sound environment
    • Developing patch to coordinate w/SCREM
    • Designing sounds
      • Sound Set 1 - Egyptian Theme
      • Sound Set 2 - 8-bit Simple Theme

• Transdisciplinary
  • Evaluation of user interaction by:
    • Preparing scenarios
    • Constructing and conducting controlled user interviews
    • Reporting quantitative results
    • Reporting qualitative results
  • Being present during coding
  • Being present during SCREM environment configuration
  • Contributing to a holistic and unified design process (collaboration with Wen Hui, graphic design)

Ryan

• In-discipline
  • Lead a unified, collaborative team
  • Improve upon existing system
    • Implement transitions, improve rule-set
  • Build out new functionality
    • New game mechanic
    • Ability to swap graphics and sound sets
• Transdisciplinary
  • Evaluation
    • Assist with development of qualitative and quantitative study questions
    • Data analysis and reporting
  • Evaluation of

Wenhui

• In-discipline
  • Visual Design part
    • Refinement: Improve the visual cues and feedback to be more “Egypt-like”
    • Development: Design the new graphics needed in the “Collision Game” and art sets in “basic” parts
    • Implementation: Introduce the concept of levels, experience value, timing and so on, into the game
    • Special Effect: Develop simple animation to make the game more appealing and interesting
  • Programming part
    • Assisting Ryan and Andrew with programming
    • help completing the collision game based on the Java game engine
    • learn OpenGL graphics programming in Dash

• Transdisciplinary
  • Game evaluation
  • Feedback evaluation
  • Results analysis

Links

Internal

• Puzzle Game 2 Specification
• Puzzle Game Project 2 Timeline
• Puzzle Game + Building Legible Environments : the first part of this project

External

• add a link