Final Poster

Week 18

This final week has been very busy for both of us, as the fall semester classes have begun. We have gathered all the information necessary to begin work on our final poster, and have scheduled a meeting with Professor Gooch to discuss an outline.
We have also arrange to give a final presentation to the Graphics Group, here at UVic, to demo our final project.

Week 17

This week, we continued to make the necessary alterations to our game, in hopes of improving the flow of the educational content.
This experience has been a tremendous learning process for us both, as undergrads. We have had experience with the typical game design process, but we were unaware of the significant differences between the design of an educational game and the design of a game created for pure entertainment. At the beginning of this project, we had planned on following the same steps we took in designing our maze game. We used the same outline for a Game Design Document, and in addition to some background research, we iterated through roughly the same process as before. Part way through our project, we realized that the considerable amount of time we had spent on the game mechanics should have been spent on the educational content. We put too much emphasis on the entertaining aspect of this game, and not nearly enough on the educational part.
These difficulties we encountered forced us to revise our design process, and consider how we might alter this process to reflect, what we believe to be, a more productive practice for designing and educational game.

Week 16

The area that is in need of improvement, this week, is the text in our game. It proved to be quite difficult to integrate all the educational information necessary to fully comprehend the concept of pointers, without having the user read an extensive amount of text. At the beginning of this project, we were hoping to implement and entertaining and educational game that would 'trick' the player into learning about pointers. The way we chose to display the information is through conversations between the main character and the characters they encountered throughout the game. In using this method, we hoped to make it seem as though they were participating in an educated conversation, other than having the information simply handed to them. Even though this tactic seemed to be more engaging for the user, it was still quite obvious that the goal of this game was to educated, and not simply to entertain.

Unfortunately, we we're unable to attend the poster competition in Vancouver. However, Donna was able to attend the 35th International Conference on Computer Graphics and Interactive Techniques (SIGGRAPH), held in Los Angeles, CA. She was exposed to several creative designs and implementations in areas such as animation, gaming, interactivity, art, science, education and research.

Week 15

This week we focused on testing, and alterations/improvements on our quests. We both tested the same version of the game, and provided each other with feedback on the alterations the other had made.
We continued to add to the Game Flow document, and made some changes to the dialog throughout the quests.
Both of us were also able to gather a fresh group of users to test the effectiveness of the education content of our game. This allowed us to get a fresh perspective on our work. The voluntary users come from several different backgrounds, ranging from experienced programmers, to students with little, or no programming experience. The bulk of these tests were done by observing the users as they attempted the individual quests, then discussing and taking notes on the effectiveness and difficulty level.

Testing our prototypes is one of the most important stages in this process. We will continue to test and make the necessary alterations in the following weeks. These tests are focusing on the educational content, intuitiveness, and flow of our game. When the result are satisfactory, we will then test the entertaining aspect of our project.

Week 14

As we moved further into the final steps of implementation, some of the characters in our game developed distinct personalities that we found were not justified with the sprite we were using at the time. This motivated us to look elsewhere for character sprites that, otherwise, would be difficult and time consuming to create on our own with the simple software we had. We discovered Sithjester's RMXP Resources and some additional ones.

Because we had to customized several of our sprites to fit the storyline, we were lacking the battler graphics for certain points in the game (when it came time to display the important dialogue between main characters). We began by making several alterations, using Photoshop, to some of the character graphics that came with the software to make them resemble our unique characters. However, this proved to be too very tedious work and too time consuming, given our schedule. Our resulting images only vaguely resembled our sprites, and we knew we could provide a better representation. We did some searching and Donna discovered this site. These graphics provided us with a quick fix to our problem. We had to remain focused on what we were trying to achieve in creating this game, and that is to produce a successful learning tool for first year computer science students. It was very easy to get side-tracked with small tasks such as creating original and unique character graphics.

We have created an additional document, The Game Flow, to help us keep track of the storyline. This helps us to record when certain triggers should be used, and the state of important switches throughout the game. A version of this document will be added to our Game Design document upon completion.

Week 13

The implementation process continued, as we worked on the last 2 quest of the game. Up to the end of this week, our implementation process has focused on the quests in their simplest state. These versions will assume the user does nothing but what they are told. It will then be necessary to insert several switches and triggers, so the game will provide the correct information at the appropriate time, etc.
It is possible that we underestimated the number of times we would need to iterate through the quests in this phase of our project. We found ourselves having to return to the first few quests for several reasons, such as...
1) We found a more efficient way of implementing a certain event.
2) To slightly altered part of the storyline, in order to fit the improved version
3) To add a switch or trigger that may have been overlooked through the first iteration

Because of this time consuming process, we were unable to tie everything together into one complete playable version. We examined our timeline that was created at the beginning of the summer, and discovered it to be slightly optimistic and perhaps slightly unrealistic with respects to implementation. We are now aware that, even with careful planning and design, more time should be allotted to the coding phase of a project such as this.

We also imported some scripts in hopes of making the educational information in our dialogue slightly more intriguing to the user. From our previous research, we found the text is less effective when it is just displayed all at once. The most effective way to make sure the user has absorbed the educational content in a text box (without using audio) is to have movement within that text box (text appearing letter by letter).

Week 12

The first testing stage was very profitable to us. We were able to discover several details (small and large) that were in need of alterations.
At the beginning of the week, we made the necessary changes to our analogies and posted them for reference under 'Analogies'.
We both agreed that the parts of our game that contained the educational content were our first priority. We focused on implementing the quests, using the maps we had already created.
One difficulty we encountered at the beginning of the coding stage was the excessive number of events on each map (because some maps were meant to be revisited more than once). We needed to implement a different introduction each time the map was revisited, and have different events go off, not only at different times for the duration of that particular map sequence, but at different stages in the game.
The easiest solution to our problem was to create several different copies of the maps that were needed. This helped organize the clutter of events on each map. This also made it much easier to envision the flow of the game, simply by numbering and ordering the different copies of the required maps.
The script for the first, second and third quest are close to being completed. This leaves us with the last 2 quest for next week, and the integration of the quests into the storyline.

Week 11

We began some of our testing this week. On Tuesday, we met with Bruce's summer game design class. We had made paper sketches of our first five quests (which contain the educational content in our game) and ran through each of the quests with six of the kids in the class. We both think that we learned a lot from this process.

Before beginning, we asked each student if they had experience with programming, and if so, which languages. If they had worked with C or C++, we asked them if they had done anything with pointers before. Only one of the six students knew what pointers were, three of the other students had programming experience, and the remaining two did not have any experience with programming.

We read each student a couple paragraphs to set the scene of the quests. Then, we asked the student to "allocate memory" by placing coloured lanterns in rooms, where each colour represented a different type of variable. The students were expected to learn that different variables take different amounts of memory space. Next, each student was asked to place pointers to each piece of allocated memory. Each pointer had a colour that connected them to a variable type, and each pointer needed to point to a specific room (again, the rooms were of variable sizes, so a float pointer wouldn't be pointing to a room of "size" int). Once the students made a connection between the types, they found this task really easily. Finally, the students were asked to change a guest in the room with a new guest, then send a message to the old guest. After a little bit of consideration, each student realized that there was no way of getting at that old guest again (a variable who had been overwritten). We were very happy to see some of the information getting across through these analogies.

Throughout the testing, we asked the students multiple choice questions on the syntax of pointers. This wasn't too much of a problem for any of them.


After the testing we realized that some of our analogies were flawed. Over the next couple of days, we corrected the problems, and are now working on coding those quests to test on the remaining six students in the class.

Week 10

At the beginning of this week we put the storyline aside, and focused on the educational content. This area, we decided, was going to be the first aspect we were going to test on the summer high school students . Incorporating the educational content proved to be the most difficult part for us, and it is the most important aspect of our game.
We found that the first 'level' of our game was going to be more of an introduction to the physical memory of a computer, which would provide the student with a solid foundation before continuing. Since physical memory is not our main focus, we concentrated on the second 'level' of our game, that deals directly with pointers.
We made some adjustments to our paper sketches, since some changes were made when we determined the goal of each quest. We also determined which objects/characters were needed to execute these Quests, and turned them into game pieces.
Early next week, we will be prepared to test the educational content of our game, and take note of any alterations that will need to be done.

Week 9

This week we concentrated on the Quests in our game. We sketched out several different ideas on how to integrate our separate pieces of information into the Quests of each World we created. We found it somewhat challenging to convey the information in a way that included the Quest in the storyline, yet kept some consistency to not confuse the player. We believe to have found a way to ensure that specific information is represented in a single form, and that repetition of a certain skill will be necessary to complete the levels. This repetition will provide the player with the practice which is important in a successful educational game.
We also presented our project to a couple of groups of young children participating in a summer science camp at the University of Victoria. Even though the children were much younger than our target audience (grade 3-5), they provided us with some useful feedback.
We are currently working on a presentation to introduce our project to the summer high school students, and our game sketches that we will provide next Thursday. These sketches mainly focus on the Quests in our game, so that we are able to test the most important aspect: the educational content.

Week 8

This week has been more or less devoted to the artwork. Donna continued to add on to the dialog, and then worked on the character graphics. We started off by creating the characters that would be playing the most important roles, and making them distinguishable. We then continued to create some more generic characters which fit our description of townspeople of that World.
Elyse continued to work on the maps for each levels and the elements in them. We sketched out our main surroundings so that we were able to plot the flow of the game and the placement considerations of the elements in our worlds (characters and animations).

Mini-Map Tutorial

This is a link to instructions on how to make a feature we might want to include.

Week 7

This week we again worked on different aspects of the game. Elyse has been creating maps and events for the first couple of levels. I have been designing the basic dialog, and labeling plot scenes based on the information they are intended to give.

Early this week we made the decision to work on only the first two worlds (which contain the first 5 quests), because the size of the project was beginning to get out of hand.

Tileset Resource

Since the software does not offer certain graphics we wish to include in our game, here is a great resource that will allow us to customize our own tilesets to create the worlds we've envisioned.

Week 6

We took a bit of a step back this week as Bruce brought us some textbooks he's planning to use for his summer game design class. Elyse has been reading about level design, while I've been working on game design and balance.

We've also been working more with RPGMaker, reading tutorials and playing around with the scripting/event interface. Some of the things we were worried about (such as being able to switch between characters) are actually ridiculously easy to do.

We've also added a new section to the site. We are planning to start scripting out the dialog in the game to help us work on tightening up the story and deciding the order of some of our events.

We've still been updating the design document with our other accomplishments, including adding our own tilesets to the game.

Week 5

Everything we did this week was recorded in the Storyline and Game Design Document parts of this page.

Design Document

We modified the "Key Features" section to include "Possible Features". On Wednesday we looked at a series of RPGs for the PS2/PS3 and recorded the features we liked of each game. We will probably be unable to use everything in this list, but it's a good record and has reminded us of some features we would like to add (the ability to be reminded of your current 'mission', the possibility of 'summoning' your skills instead of adding party characters). Highlights in this area are from Folklore. Most of their plot scenes are in a cartoon format where it looks like you're reading a comic, and many of their dialog makes it very clear which character is talking. We definitely believe that we can incorporate some of these methods, and that by doing so we can make our characters more interesting/compelling.

We also modified the "software" section to include the challenges we have solved with RPGMaker. Since we are now confident that we will be using this software, any time we come up with a slightly more complicated visual idea, we make sure that we will be able to code it. This is simply a list of things that we've managed to do, and how we've hacked some of them together if it didn't seem like we would be able to do it.

Storyline

We've fleshed out our characters a bit more. We now know exactly who our main characters are, and have made a couple more decisions on the main supporting roles.

We've been working on giving each "world" its own flavour and set of supporting characters. Each of our worlds now has some information on the mini-world quest inside it, and what the player will have to do to solve it.

Week 4

We started the week by making some last adjustments to our proposal presentation slides, and did a couple of runthroughs with Professor Gooch to help us prepare. We presented on Tuesday to the Graphics Group. The presentation went very well, and we received some great feedback and some new idea to explore.
There was mention of some computer science games that were made for programming practice and entertainment, like Crobots and Corewars. We investigated these games, and discovered that they were created for more advanced user, players who already had experience programming. Our game is aimed more towards elementary users, and students who have never used pointers before. These games are good examples of educational computer games, but not the type of game we are hoping to implement.
For our presentation, we also managed to customize a fight scene using RPG Maker, so we were able to give an example of the flexibility of the software.

The rest of our week was devoted to the storyline for our game. To get an idea of an intriguing story, we looked at the plots of some popular video and computer games. We want our game to be educational, but to also have a certain allure and appeal. First, we determined that the game will have 5 major sections, or 'worlds', consisting of 2 or 3 Quests in each world. Each one of the Quests will cover a topic in that section.
There will be to be 2 main parties in this game, and the player will have a chance to play both at the beginning of the game (female and male). However, the player will be able to choose which one he/she would like to continue playing through the rest of the game.
Second, we discussed what kind of events we would like to take place in our world. Finally, we combined both lists, and determined what events would best fit the information we were trying to convey in that Quest.
Please refer to our Storyline if you would like more information.
We believe we have a good outline of our story and the events, and are currently working on special characters to integrate into these worlds.

Debugging Sementation Faults and Pointer Problems

Here's a site we can use as a reference (if we are going to stick with our idea of having the player be a debugger, and him/her moving back through the code to set everything right).
It lists the possible errors causing segfault, and some examples.
This will be helpful later on, so we are not repeating ourselves (introducing the same problems over and over again to the user)

Storyline Ideas

We've added a new section to the bottom of the page that will help us track our characters and the events of the game's storyline

Proposal Presentation

We gave our proposal presentation today using the slides that Elyse designed and that we spent some time last night and this morning modifying and ordering.

I think it went really well -- way more people showed up for the graphics meeting then I was expecting.

We got some interesting questions. Sven pointed us towards something called "Diamond Age" that we were looking for in the lab later this afternoon, and we got some good ideas of how to map our in-game skills to real-world skills to prove that our game does what we say it is going to do. We will have to add some of this information to our game design document. We already had this idea, but now we're definitely set on have a pre- and post-test for our game testers.

Another game we need to search for is "Core Wars", which apparently integrate some computer science concepts in them.

Week 3

We realized this week that our timeline was slightly backwards -- although we were supposed to be working on the last of our background research, we didn't know what sorts of tools we needed to create our game because we didn't know anything about our game.

On Tuesday we took a small segue to start talking about what order we would present information to players (Week 4). We came up with the following list:

1. Physical Memory and Addresses
2. Types of Pointers/Variables
1. Void Pointers
2. Casting
3. Pointers to Pointers
   
3. Initializing Pointers (pointing them to NULL) and *
   
4. Pointer Assignment (pointing at a variable)
5. Dereferencing Pointers (getting values out of them) and &
6. NULL pointers versus uninitialized pointers
7. Segmentation faults
8. Uses for Points (Arrays, Linked Lists) and malloc and alloc
1. Pointer Arithmetic
   
9. Freeing Pointers
10. Void Pointers and Casting
11. Pointers to Pointers
12. Pointer Arithmetic

The indented points are places that we believe referencing that information will be important, for example, noting that void pointers exist when we discuss pointer types, but not actually going into them until #10. We are also not sure we want to talk about pointer arithmetic, but if we do, it would be the last topic.
We consider topics 10 through 12 to be the "advanced" topics, with everything before then being necessary to a basic understanding of pointers.

Once we had this information, we were able to decide that RPG Maker was the appropriate program to use. We acquired a version, and also downloaded the scripting language Ruby which RPG Maker uses for more complex events. We both completed the online tutorial "Ruby in Twenty Minutes".

Elyse has been working on preparing our proposal presentation for next Tuesday. Donna has been working with RPG Maker. With Elyse's input, she has created a small game where the player tries to fix fragmented memory and learns a little about physical memory in the process. We will be using this game as a prototype for the sorts of more complex events we can have occur.

RPG Maker Tutorials

Elyse -- there are a couple good ideas in here that might help us avoid needing to pop open new windows for "mini-games"

Definitely a link I want to save

Pointer Information

I found this webpage was a very useful reference when figuring out how to describe pointers.

Foundation for problem-based gaming

Article is focused on the development of a model about problem-based gaming that can be used to design a successful educational game.
"The PBG approach emphasizes the meaning of authentic learning tasks, experiential learning and collaboration. Because games usually allow players to creatively test hypotheses and reflect on outcomes in the game world, experiential learning theory provides an appropriate basis for PBG."
The PBG model splits the cyclic learning process into elements (learning process with games):

• Strategy formation to solve the given problem
• Active experimentation (player test his strategies and hypotheses in the game world and observes the consequences.)
• Processing/Reflection stage (feedback that the game provides the player's actions should support reflective thinking and knowledge construction by focusing a player's attention to relevant information from the learning point of view.)
• The outcome of reflection : personal synthesis or appropriation of knowledge, validation of hypothesis laid during playing strategy formation or a new strategy to be tested.

This model really emphasizes the reflection stage, stating that it is the most critical stage and a vital factor of learning. It is important that the player be made aware of reflection, and how it can be facilitated, because it's outcome determines their behavior in the game.
During the reflection stage, if the player chooses to continue using the same strategy , it's known as single-looped learning, and is not effective. One thing that can lead to single-loope learning is lack of challenge! "...It is important that the player endeavours to test different kind of strategies in order to expand knowledge on the subject matter and optimise playing strategy."

So what game elements facilitate reflective thinking?

• performance of other teams playing the game
• Game design can disturb reflection (too fast playing tempo)
• Complexity an also disturb reflection ( too many changing components, so the player is not able to pay attention to them all)
• If the interface of the game requires too much cognitive processing, there will not be enough room to reflect on the game. (Making the game controls and interface 'transparent', to allow them to focus on game-play)
  

Revolution

If we wanted to look at building on Neverwinter Nights, I would really want to check out this game first. It's an educational game built on that platform -- unfortunately, we need the original first, and you can't just download and buy it, you need to actually go out to buy it.

It's something we should remember though, if we become unhappy with RPGMaker

Adapting a Commerical Role-Playing Game for Educational Computer Game Production

This article presents a different method of creating a game that we haven't considered yet.

Researchers at the University of Alberta have used the Aurora Toolset to create adventures using the Neverwinter Nights engine. The benefits to this approach is again a more specialized set of tools -- and one that will create a more professional feel for the game. To mitigate some of the scripting challenges in game making, they developed the tool "ScriptEase" that helps manage interactive events for NVN authors.

I think RPGMaker will probably work for our purposes, but if using it to create mini-games proves to be difficult, this is another alternative we might consider.

Software Analysis

After playing a bit with the various game design tools we found, I think that we can safely remove the OHRRPGCE from consideration.

As well as being more difficult to use, this particular program doesn't save the created games in a format that will allow them to be easily distributed. Game Maker will allow you to export games as a .exe file that can be run anywhere, and RPG Maker also allows exports to a disk.

If we wanted to do a more RPG-style game, I think we would definitely want to highly consider RPG Maker. Unlike Game Maker (which is more general), RPG Maker is designed for RPGs, with many necessary preset classes (items, weapons, magic, stats, monsters, battle system...)

We currently are playing around with a free trial offer. I believe actually buying the game is $60 -- RPG Maker also doesn't work on our lab machine (the one running Vista). If Elyse's machine worked (and ran XP) we could download it there without a problem -- right now the only version we have is on my laptop.

Buying Game Maker Pro would be $20. It seems like Game Maker works with Vista (although I haven't tested it in depth).

Designing User Interfaces for Games

Evaluation Techniques:

Cognitive Walkthrough
A successful game usually allows players to explore by trial-and-error. This should be taken into account when designing the game, to make sure the game (or at least initial levels) are solvable in this manner.

Think-Aloud Protocol
Ask testers to think aloud while they are working with the game sketch or prototype game to help figure out what they are thinking (expectations, frustrations, confusions) as they are presented with different elements of the game.

Fitt's Law
Reduce the distance between controls and increase the size to decrease the players' stress.

HCI Design Innovations in Entertainment Software

One of the four innovations of games this paper introduces is
"fluid system-human interaction -- games communicate information to users in ways that do not demands the user's attention and do not interrupt the flow of work"

From some of our game reviews, we decided that a real-time game would not be as successful at presenting information. In case we change that assessment, here's a couple points made on the system-human interaction that seem to be much more relevent to real-time and strategy games than turn-based or puzzle games (although there may be some elements that are transferable).

Calm Messaging
Unobtrusive messages do "not require users to dismiss, acknowledge, or address them." This allows the system to give the user messages while not necessarily interrupting them. Examples:

• Audio -- prerecorded voice messages, or sound notifications
• Transient text -- disappears on its own (scrolling messages, automatically removed)
• Animation -- draws the user's eyes to a specific place (event notification in a mini-map)

These are, however, ineffective for out-of-game critical messages.

Attention-aware interface elements
Context-aware view behaviours

Game Interfaces

Important features of puzzle-adventure game interfaces

Navigation

• Reversibility -- by allowing players to "undo" moves (generally in the same manner they were taken), exploration is considered to be more harmless and can be encouraged
• Mystery -- by not revealing everything (example: an entire map) at once, players are forced to move through the game. Faster transportation between "zones" can be offered once the long way is found
• Reality -- suspension of disbelief is assisted by making movement (characters, objects) take time instead of being instantaneous

Interaction

• No error reports. The only actions players can make should all be legal. If it's illegal, the player shouldn't have the option to do it
• Controls should be consistent. Only change the interface when the player makes a change
• Corollary: objects with a timer (like bombs) break this rule, but are predictable
• Consistency in similarity. Things (controls, objects) that look the same should have similar rules to help players learn about advanced mechanics
• Immediate visual feedback
• One window -- confine the game, everything outside of it is extraneous

There are other really interesting game tips (reality cues, general principles) on this site, but I was trying to focus on interface design and interaction with the player.

Sandy, the Ampersand

Elyse and I just started playing with art ideas. We had this one -- around the end of March -- and just fleshed it out a bit more.

Pointer Syntax

We will probably want to reference pointer syntax (in C?) in our game -- wikipedia does a really good job of explaining it, but I'd like to keep a copy in here for us (because some of it is so basic to what a pointer is, we could easily forget to add it to the game).


Definition -- "pointer" is a pointer to an integer:

• int *pointer;

Initialization -- At this point, "pointer" could easily be invalid, so it needs to be initialized.

• int *pointer = NULL;

"If a NULL pointer is deferenced, then a runtime error will occur and execution will stop likely with a segmentation fault."
Assignment -- Using the pointer:

• int variable = 7;
• int *pointer = NULL;
• pointer = &variable;

Note where the * and & are located. We've just assigned "the value of [pointer] to the address of [variable]. For example, if [variable] is stored at memory location of 0x8130 then the value of [pointer] will be at 0x8130 after the assignment"

• *pointer = 3;

Here we are changing the contents of "pointer" (at the memory address 0x8130 -- which is also still referenced by "variable") from 7 to 3. Printing the value of variable at this point would now output "3".

Week 2

May 10th-16th
Our second week, we made some final adjustments to our lab space. We set-up some additional hardware, and arranged to have the desk space needed for group discussions and scheduled meetings. We also made some alteration to the website so it was more presentable, and organized so that is was more user friendly. We met with Professor Gooch at the beginning of the week to discuss our progress and a rough agenda for the summer. She had us work on a detailed time line and present it to her in the middle of the week to be approved.

We further investigated some different styles of Game Design Documents, and discovered a template that best suited our project. The bottom of our website now has a section devoted to the document, that we can fill in later on.

Continuing our background research, it was now focused more on the educational aspect of games. We discovered some game like Invar® & Steel Alloys, where the captivating aspects and educational information was well balanced. However, we found others that were strongly lacking one or the other. Games like the Periodic Table Game, gave us a good example of a typical educational game, where it was too boring to engage the user. These games proved to be a good resource, but were not inviting to a university student.

During the background research, we found that one of the important element of the entertaining game was the sound. This prompted us to downloaded some audio editing software to familiarize ourselves with it, so we can easily create some of our own sounds for our game.

Later in the week, we met with Professor Bruce Gooch, now a professor at the University of Victoria, and the author of the book Non-Photorealistic Rendering. He will be teaching a Game Design course in July for high school students, and offered us the chance to use his class to help us gather data. This was a great opportunity to test our game on a large group of students, very close in age of our target audience. We made arrangements and adjusted our time line so that we are able to test our sketch and the content of our game on the summer game students. This will provide us with immediate feedback on the entertaining aspect, as well as the educational aspect. After making the appropriate adjustments, we will then generate a rough playable and test it once more with the same group of students, to see if the key concepts are actually retained after the game has been played. Additional testing can only help us to improve our game. After discussing this, we started thinking about some pre-test and post-testing questions we could ask the students. We created a section on our website where we can add some questions we think might be helpful in determining the strengths and weaknesses of our game.

The Classroom of Popular Culture

What video games can teach us about making students want to learn
by James Paul Gee

Key points:

• Under to subtitle Producers, Not Consumers, Gee talks about good game designers letting players "be producers, not just consumers". This could mean letting the player alter the game so that it fits his/her knowledge level (tutorial, beginner, intermediate, advances, etc.), and letting the player solve problems in several different ways.
• "In good video games problems are well ordered, so that early ones lead the player to formulate hypotheses that work well for solving later, harder problems. " Leaving the user completely free to solve a difficult problem might help them generate a creative solution, but won't provide them with a good hypotheses for generating future code.
• Get the player to think about how each step they take might affect their future actions. I think this principle is important for our game because of the material we are presenting. We must have the player constantly thinking about how a certain assignment would affect a location in memory, and how that assignment affects other variables and data.

Gee's 36 learning principles

Although these are oriented towards a k-12 audience, I think these element would be worth incorporating into our game to make it a powerful learning process.
Ones I thought stood out:
#1. Active, Critical Learning Principle - Doing and reflecting
#7 Committed Learning Principle - Putting out effort because they care (They won't want to learn if they are not motivated)
#12 Practice Principle - Being encouraged to practice
#13 Ongoing Learning Principle - Having to master new skills at each level
#14 “Regime Of Competence” Principle - Tasks being neither too easy nor too hard.
#15 Probing Principle - Doing, thinking and strategizing
#19 Intertextual Principle - Relating information
#22 Intuitive Knowledge Principle - Thinking intuitively
#24 Incremental Principle - Being led from easy problems to harder ones
#28 Discovery Principle - Trying rather than following instructions (avoid cluttering the levels is written instructions)
#29 Transfer Principle - Applying learning from problems to later ones

Life on the Edge

Life on the Edge:
The player as a professor, exploring different zones and discovering the animals, natural hazards and man-made problems of that area. At the end of each level, you answer a 'vital' question to see if you've retained the information.
This game gave me an idea of story line we could use for our game. We could have a character 'shrink down' and venture into the computer ( I thought because we are dealing with physical memory locations).

Strengths: The game presented plenty of important information. This game, if played well, does help the player retain some important facts for the subject. Because of all the reading that is done for each level, and the multiple choice question at the end, it's difficult NOT to retain anything.

Faults: There was too much text in this game to really fully immerse the user in the game-play. The introduction could have been more effective if, instead of the beeping, they used a voice over to explain the story line and goal.
Forgetting the fact that there was too much text to read in each level, the information was not presented in a way that would make the player WANT to read it. I did more dragging and clicking just to read the text than I did to play the actual game. There is not enough player activity to make this an entertaining game.
Also, there was not immediate feedback. The player only received feedback at the end of the level, after he/she would have read through through all the text.

Trying to Design a Truly Entertaining Game Can Defeat Even a Certified Genius

Article in Wired magazine: 16.04

It's best to learn by other people's mistakes...
A professor at Indiana University and a team of researchers designed a game called Arden: The World of William Shakespeare. This was designed to have players explore Elizabethan environment.
Ted Castronova, the professor, then studied the player's behavior. He came up with 5 tips for making a game that 'doesn't suck':

• Don't be overly ambitious : He found that making the game realistic was quite a large task - we should be practical about how much detail we wish to include, considering the time line we put together.
• Go Low Tech : Stick with a simple development platform. (We are already there - sticking with a simple software that we are familiar with (Game Maker, RPGMaker))
• Think About Your Audience: He found that students who were not too familiar with Shakespeare found it boring. We should possibly be thinking about students who are not too familiar with computer science concepts, and what they would find interesting. One of our goals is to create a game that makes computer science appealing to all students (particularly females).
• Get a Full-Time Staff (I think we can handle this)
• Concede Screw-up: To keep in mind throughout the implementation process: Deal with problems as soon as possible (admit it and move on).

The use of computer games as an educational tool: identification of appropriate game types and game elements

Published in the British Journal of Education Technology
By Alan Amory, Kevin Niacher, Jacky Vincent and Claudia Adams

The method they used to determine what type of game is most enjoyed by undergraduate students was to have 20 students play 4 games of different types :

• strategy
• "shoot-em-up"
• simulation
  
• adventure

The students answered a questionnaire after the experience related to:

• enjoyment (sounds, graphics,storyline, technology, etc.)
• skills (logic, problem solving, memory, etc.)
• game play (addictive, boring, too difficult, too easy, etc.)

The 3-D adventure game was ranked the highest in all aspects, along with the strategy game.
These 2 games we're also mentioned to have more interesting story lines. This supports the argument that such elements motivate the player, and promote effective learning.
Simulation game was ranted poorly by students (possibly due to a confusing interface and lack of immediate feedback).
(The effectiveness of the adventure game - see page 8 of pdf)

The study showed that the simulation game was the only one which proved to be difficult to play by the students. Also, all but the simulation game proved to be challenging and addictive.

Walking With Dinosaurs

This is an educational game about dinosaurs, and what they need to survive. The game required you to maintain a certain status (energy, weight an fitness) in order to survive run-ins with other animals.

This is a more complex game that requires some explanations as to what the players need to do in order t succeed. I thought it made the game-play much easier when my goals, and what sort of things I needed to accumulated, was clearly presented. The placement was also very helpful, so I didn't have to search the screen to find where my status was, etc.

Because the game was more complex than some other we have played, they were able integrate a status which the player needs to maintain. Having to maintain this status presents the player with small goals they need to reach throughout the game. This keeps the player attentive.
One thing we should examine is what type of in-game feedback works best, and what their effects are (scores, secret clues, bonus, etc.)

Faults:
There was not much storyline to this game, so it was not as appealing as it could have been. The introduction could have been elaborated to immerse the player in the game.
For most of the educational information, it did not appear in the window of the game, but opened up a new window to a different website. I found this somewhat frustrating (especially because the information was unavailable), because it distracted the player from the game.

Phoenix Quest

I remember playing these math and computer science based games a long time ago. I'm not planning on reviewing the entire game -- that would be a large task, and I think much of what they have managed to do is out of the scope of our project, but I think that some of the mini-games are still good ways to learn and practice math concepts.

I'm going to try to review the games in the general order they are unlocked in the game -- but as you have a lot of freedom in what you do, it's not going to be the only order possible.

Cave Maze Puzzle
The first puzzle you recieve.
A tiled maze. You have two rotations to create a complete path from the start to the finish. You complete the puzzle by dragging the character through your path.
I don't think this puzzle is very relevant to what we want to do.

Coin Puzzle
You are presented with a scale and a set of coins (the number of coins increases with the level of difficulty). You also have a number of times you may use the scale. Within that 'timeframe', you need to determine which coin is a different weight than all of the others, and whether it is heavier or lighter.
Initial difficulties give a chart that keeps track of all the information, partway through the chart will only list "good" or "bad" coins, but not the weight of the bad one, and the hardest difficulties remove the chart altogether.
This game has a good logical progression of information, and really ends up testing deductive reasoning. Not enough weighings are given to allow a trial-and-error approach to the puzzle.

Bees Puzzle
The character stands in the center of the screen with directional coordinates around him. There is a swarm of bees flying around which the character must hit with globs of honey. The character throws the honey in a coordinate direction that the player inputs.
Harder difficulties increase the number of bees and remove visual cues of the coordinates.
Again, I don't really feel this game suits our purposes, but it still has a good progression of difficulty.

Hexagon Puzzle
The player is presented with a hex-map where each hexagon has a number associated with it. The character starts on a "safe" number and has to cross from one side of the map to the other. The numbers follow a pattern including (but not limited to):

• multiples
• perfect squares
• fibonacci sequences starting with x and y
• linear progression
• prime numbers
• numbers that have a remainer of x when divided by y

A wrong choice will cause the character to "die" with a little animation (fire, spiders, venus flytrap) and reset the game to the last correct choice.
Harder difficulties decrease the amount of wrong choices you can make.
This game taught me all about fibonacci numbers when I was younger. I could spot fibonacci sequences like nobody's business. It is really good at teaching people to recognize patterns -- but only the patterns that they have (and the remainder business is surprisingly tough to get)

Puzzle puzzle
The player tries to unscramble phrases and enters them once they are legible enough. I remember this game being really easy because there were only a small number of phrases, and even scrambled you could figure out what they were. This game taught me how to properly spell "medicine", but that's about all I got out of it.
This is definitely not the sort of thing we want to do -- it also seems to be broken now, it doesn't work on either of my machines anymore.

Mask Puzzle
There is a mask on a grid system with some of the pieces displaced. The player controls little black and qhite robots by entering simple commands like "white, north 3, west 3, black, south 2, east 1, 6" with symbol beads. The player has a number of "runs" to finish putting the mask back together.
Harder difficulties add special squares that teleport the robots around or complete parts of the puzzle (trial-and-error is required to figure out what to activate and what to avoid) and allow fewer runs.
I think this is a good game -- it definitely requires some planning

Fishing Puzzle
This game is a lot like the bee puzzle, except that there is now also a distance involved. It requires a lot of trial and error to figure out distances and coordinates, and harder difficulties again remove some of the aids. Mistakes are 'rewarded' with garbage (old tires, rusty cans) that are discarded, correct angles and distances are rewarded with fish.
In later difficulties, a shark is added which is something that you can catch, but need to avoid.
I would put this in the same category as the bee puzzle, except that I like it better. It still doesn't suit our purposes, but the progrssion is good.

Spider Maze Puzzle
A bigger version of the Cave puzzle with one more rotation. 16x16 grid instead of 8x8.

Poison Puzzle
A game to teach about fractions and adding fractions. There are 5 zones on the map where you can get different items:

• berries = 1/4 -- a turtle swims across a waterfall. You can pick up various numbers pf falling berries, sometimes too many
• flower petals = 1/5 -- there are 5 flowers and four bees. The bees move randomly. You can only collect from the flower without the bee on it
• jade = 1/6 -- the jade stream has many types of rocks in it. There is only one 'correct' type of jade that you need to pick out from the other rocks
• spider legs = 1/8 -- the spider cave has one spider. He moves quickly until he has three legs left, then he's really slow. If you pick all his legs, he dies (my sound doesn't work anymore, he used to make this cute "bleeeeeeeeeeeeh"). This is not repeatable. If you pick all the legs, overfill your container and lose them, you can't get the spider back without restarting
• seeds = 1/9 -- the seed tree is like an immobile spider. Once all nine seeds are picked, you can't get anymore

Each item has its own container where it shows the fraction in the lowest common terms (seeds would go "1/9", "2/9", "1/3"...), and there is a group container that adds all the components.

The first levels ask for a fraction and a type: "1/2 jar of spider legs"; "2/5 jar of petals"
The next levels ask for a simple fraction: "4/5 jar of anything"; "1/2 jar of anything"
For the second example, 1 petal and 2 spider legs work just as well as 3 jade
The next levels don't reduce the fraction: "6/8 jar of anything"; "4/12 jar of anything"
Earlier levels will turn the total into the full fraction, later ones leave it in the simplest form
The last levels need more complex reasoning: "13/15 jar of anything"; "5/18 jr of anything"
These often require advanced handling: "13/15 = 26/30 so I need 1/5 and 4/6"

This game has a really good progression of difficulty, preparing a player for the harder levels with the easier ones -- teaching them about creating the more difficult fractions with whats avaliable.

Paddy Puzzle
The player must connect rice paddies with water. Each ditch has a value, and the player most dig ditches to have everything connected under a target value. This teaches players about minimum spanning trees in graphs.
Harder difficulties add more edges.
This is a really simple and intuitive way to approach a much harder problem. I think that playing this game when I was younger has helped me pick up some of the concepts in my algorithms course easier.

Shrine Puzzle
The player must guide the character to four shrines then return to the start. Again, each edge is weighted, and the player must complete the puzzle with minimum weight. Again, this really helps with graph problems, and presents the Travelling Salesman in with a very small map.
Harder difficulties add more edges.
My analysis of this is again like the paddy puzzle.

Key Puzzle
This is a more complex version of the Mask Puzzle. Each robot now has its own string instead of a code, so they can move in unison. Some displaced blocks are now two-by-two and need both robots working together to move. A "wait" symbol has been added.
Higher difficulties again add special tiles and give fewer runs to complete the puzzle.
My analysis of this is the same as for the Mask Puzzle.

Logic Puzzle
My version is still buggy, so I can only play the first couple of difficulties.
The game presents two signs ("this door leads to a passage"; "this sign is not false") and a rule ("Both signs are true"; "Either both signs are true or both signs are false").
The player must first use the rule to decide if signs are true or false, and then click on the door with the passage.
I wish my copy wasn't buggy! This is a great mini-logic game.

Logic Puzzle 2
This is the same as Logic Puzzle, only now there are 3 doors. The signs are update to include more complex statements ("this door leads to a pit and door 2 leads to a pit"; "This door leads to a passage or door 1 leads to a pit")

Gears Puzzle
This game offers both a "playpen" part and a "challenge" part. There are two types gears, an outer gear and an inner gear. All of the outer gears are larger than the inner ones. The challenge presents a design and asks the player to find the gears that would make that design (if the inner gear was set inside the outer and made to spin around with a pencil on it).
I like that this game just lets you play with different sizes of gear. Again, my copy doesn't work very well -- it dies after the third game. I really like having the chance to experiment before you have to answer a question about the gears.

Stepping Stone Puzzle
The player must direct the character to stepping stones to get from one side of a river to the other. The stones all have relative positions with positive coordinates moving the character up or right on the grid and negative coordinates moving the character down or left. If the player takes too long, an alligator appears and swims after the player.
Harder difficulties remove the reference grid and add other stone types (like lily pads, which occasionally move around)

Strife
This is the final game. Throughout Phoenix Quest you can collect "Strife Cards" that are characters, equipment, or actions. Before the game you must pick 4 characters from your deck, and up to 40 cards from equipment and actions. Each character has their special action and two values, stamina and karma. Items and character actions are cost 1, and actions are cost 2 -- you have 3 points you can use in a round. The purpose of the game is to get all of your characters to max karma, or drop all of your opponents characters to below min stamina. When a character is below min stamina it is killed, and cannot be used to take actions.
Some actions can only be taken by characters in a certain karma/stamina range, this is shown on the card.
This is a very complex game, and probably of a different genre than we would want to make. It is still rather enjoyable, though.




Relevant link: http://www.cs.ubc.ca/nest/egems/phoenixquest.html

Periodic Table Game

The Periodic table game is more developed than the Element quiz game, with many different levels to choose form.

One tactic they used to present the technical terms : when the element chosen, the name would blow-up into larger text over the table. This was not as effective as it could have been, because the name of the element being blown-up was not clear. Because the larger, bold text just overlapped the other text on the screen, the spelling for the name was hard to make out. This would have been more effective if they blew-up the text in a different color bubble, that was opaque over the rest of the table.

We found that this game was a very good resource for students wanting to learn more about the elements, because of the extensive description given on the side. However, it did not seem to be an effective learning tool, because of it's lack of engagement capabilities.

Elementary Chemistry Quiz Games

This game presents the user with a periodic table, and some information about the elements on the side.
Element Group: Level L
Strong point:
I found that the way they chose to break this game up into a Learning level, and then level 1, 2, etc. was very effective in presenting the educational information. Implementing a 'tutorial level' first would give struggling students (or students who have not been introduced to the concept yet) a chance to review, or be introduced to the concept of pointers.

Level 1:
The game caters to students with difficulty in this subject. After the second time the user chose the wrong section of the periodic table to put a particular series, the correct blocks would flash so that they could place it correctly and continue. This would help students learn the correct place for the series, but without gaining any points from it. The game provides immediate feedback, so it is effective when in getting the information across.

Faults:
Contrary to the other games we have played, this game does not incorporate many of the entertaining components. What we have noticed is that having intriguing characters and a colorful interface is a key point in creating an entertaining game. This game had a very bland background with very simple images. The game was very successful in conveying the information, but it is not a very inviting game to a typical first or second year student.

Element Lab

Link: http://funschool.kaboose.com/formula-fusion/games/game_element_lab.html

A drag-and-drop game with three stages. I think this could be easily expanded into a harder game -- maybe give each stage a couple different levels to add in more elements and compounds.

Stage 1: Identify the Element Symbol with the Element Name
Stage 2: Identify the Compound Formula with the Compound Name
Stage 3: Complete the Compound by adding the correct Element

Later stages could includes building a compound from scratch, or actually putting a formula together (without them being given)

Can You Fill It?

Link: http://pbskids.org/cyberchase/games/liquidvolume/liquidvolume.html

You have a pot, and three different amounts you can choose to pour into one large container. You're trying to fill the container completely using the least number of pours possible.

I thought it was a neat sort of trial-and-error game...again it had colourful characters (which didn't change the game at all, but probably would make it more appealing to a younger player)

Lightning Librarian

Link: http://funschool.kaboose.com/fun-blaster/games/lightning-librarian.html

This was a fun memory game. There are 15 sets of coloured books, each with their own subject. You get about a minute to try to memorize the location of each subject. After that, a kid will come to the top of the screen thinking about a subject. You need to find the right book (the only penalty for an incorrect shelf is time) and return it to the kid. Unfortunately, the kid doesn't like waiting, and after some amount of time they'll get a thunderstorm over their head, then some fire, and then they'll leave. After five kids leave in a huff, you lose the game.

One of the really good things about this game was the difficulty level. After around 10 kids got their books, two children would come at the same time wanting different subjects. There was room for three kids, but I didn't extend playing it that far. I felt that the game waited long enough before requiring a better memory (you can't afford to take the time to check every shelf now) because I'm sure I could have continued.

The other thing I loved about this game was the characters -- the librarian and the kids. They were very cartoony, which probably makes the game more appealing to a younger audience.

For a memory-testing game, I think this was a very good one

Website

It seems we should have this website submitted by Thursday or Friday.
To satisfy the minimum requirements, we need to include description of our research project and goals, and allocate some space for our individual journals.
Here are some websites of some previous CDMP award recipients:
http://www.cra.org/Activities/craw/cdmp/awards/2007/2007.php
We could also include some other thing such as, a short description:
-of the objectives of the CDMP, and how we hope to further their goals.
-about ourselves (possibly upload a photo)
-about Amy and her work (photo)
-links to CSC department website, NSERC, etc.

Game Design Document

Here is the template we used in CSC212 for our game design document:
link:
http://www.gamasutra.com/features/19991019/ryan_pfv.htm

Week 1

May 3rd-9th
This week, we were welcomed into Professor Gooch's graphics lab and introduced to several of the graduate students who we would be sharing the space with. Some of the projects the graduate students are currently involved with include restoring color, tracing objects in video, single-interaction photograph relighting, and procedural non-photorealistic rendering approaches to create aesthetically interesting effects (generating illusions).
We proceeded to set up our desks and the machines we will be working on. Our mentor then made sure we had the keys to access the necessary labs in the Computer Science Department.

We met with Professor Gooch several time at the beginning of the week to discuss meeting schedules, a general time-line for our project, our goals, etc. Because we both have experience with the process of game design from taking CSC 212 with Amy, we were also able to begin discussing the steps involved in creating a Game Design Document for our project.

The rest of the first week was devoted to background research. We play tested several online games, as well as reviewed several journal entries and articles centered around gaming. After playing each game, we proceeded into game analysis: What makes a game appealing? Entertaining? Are users engaged - cognitively, motivationally, and behaviorally? What is the best method to present educational information? What approach makes information easiest to understand? How do we prevent educational concepts from being overshadowed by the game mechanics? We also reviewed several articles which discussed how to successfully create an entertaining game, and the use of computer games as an educational tool. We posted our reviews on a blog so that we were able to examine and discuss each others entries.

Furthermore, we downloaded different types of game software like Game Maker, RPG Maker, and OHRRPGCE (Official Hamster Republic Role Playing Game Creation Engine), so that we will be able to determine which piece of software will best fit our project. We both have experience using Game Maker, so we are aware of it's capabilities. However, there is a possibility RPG Maker or OHRRPGCE have some components that would be more helpful when implementing our game . We would like to explore the strengths and weaknesses of these other pieces of software, so we choose the right one to successfully execute the project.

Fun Brain (Everything Unlocked, Grade 8)

Link: http://www.funbrain.com/brain/MathBrain/MathBrain.html?Password=IMP6
This link has beaten all of the games at a grade 8 level (the most difficult)

Since Elyse is reviewing each specific game, I'm just going to give a general review/ranking

• Bumble Numbers -- The second one was pretty hard. There are 3 rounds, only 3 lives, and the fireflys are pure evil, I'm sure
• Puzzler -- It was sometimes difficult to get the pieces onto the part of the puzzle you were thinking off, but I thought that this was a really novel game. We could almost do something like it for big O if we wanted!
• Mummy Hunt (1/2/3) -- I liked this game. I think the time limit was a little short, especially for my higher difficulty. The last one was really difficult because it gives you 3 wheels to spin instead of just the one. I think they could have removed answers that were already taken (I sometimes ran out of time with one problem left, which means I solved it, but I couldn't find the unused pieces fast enough). The game seemed to give easier questions the more often you died, which I think was a good thing for one of their really strongly time-based games.
• Ball Hogs -- I liked this game. Reaction time + Math.
• Hillbilly Pig Toss -- A goofy idea for a game. Does allow a little trial and error. Very amusing. Forces you to think about the effect height has on distance and distance has on height when tossing things
• Moon Rocks -- 3 levels. Fewer lives/more rocks each time. Probably teaches more about matching than math, but the hardest level does force you to consider a strategy about shooting the rocks
• Night Swimmers -- It was alright. Controlling the game was easy. The higher level provided some difficulty by getting the screen a little too full sometimes (it was difficult to avoid obstacles)
• Inkster -- Difficult to control the octopus. I found that the correct answer was always in the upper righthand corner. I think there were better games than this
• Revealer -- Typical word problems. I came across the same questions in both levels. You might not (you can end the game early if you guess the picture) but I think they could have come up with a couple more puzzles
• Math Basketball/Soccer -- Really the same game. I didn't like either of them. Gives you unlimited time to work out problems (and at the higher levels, you need it)

Trade Ruler

Link: http://nobelprize.org/educational_games/economics/trade/index.html

The idea for this game is to choose an island with an amount of labour and an amount of capital, and then to choose a trade partner with the same stats. You set up your cell phone and jean production and then offer trades to the other island in an attempt to raise the welfare of your people.

Good:
I liked choosing (and designing) a character, even though that made no difference to the game.
It was interesting to see how your population reacted to the trade deals you made with the neighboring islands.

Needs Work:
I think it would have been neat to be able to change your major trade partner. There were four islands to choose from, so this should have been possible.

The Ear Pages

Link: http://nobelprize.org/educational_games/medicine/ear/index.html

A series of pages you can explore through to learn about the ear and hearing. You collect (inner ears?) these snail looking things, which gives you a "redo" chance in the quizzes, which have three different levels.


Good:
A timer on the intro. You know how much longer it's going to be!
Skippable intro.


Needs work:
Good for someone who is really motivated. I found it had very little direction, so I got bored with it easily.

Math Arcade

I know this has some very elementary information, however i think a couple of the idea's couple be very useful.
This game consists of several games within a game. I thought this was a great idea to keep the player engaged, because they were striving towards more than one goal here - if they are succeed in playing the game (know the material) than they move forward on the board (a kind of reward).
Donna, we had also talked about possibly being able to pick a your character at the beginning of the game (* or &)....In this game is allows you to pick your own piece to move along the board. Here, there is no real meaning to the item you chose to represent yourself - but for our game, your choice of character would really play a large roll in the game-play.

Letting the player choose their skill level is also something we could think about later on....

All these games a fairly short, but might provide us with some good ideas for certain parts of our game, or ways to gain points, etc...

The first game Bumble Numbers:
This idea would work very well with our concepts we are trying to get across - addresses and their content. There was a nice balance between the importance of the material and the game (even though it was pretty simple and less challenging compared to what we are looking to do)., The goal was to retrieve and integer from a cloud, and to drop it onto the correct mathematical equation. We might want to think about doing something similar, maybe for one section of the game you may need to be able to determine the address of a certain variable to pass to a certain level (given only a section of code - including the declaration and assignment of a pointer to that variable).
Round 2:
This was much more challenging, but the same idea.....One thing that is quite engaging about these games is the artwork. The characters are very 'cute' - cartoon-like , and there is always a new characters come the next game.
One thing I noticed is that the obstacles do not fly around randomly, and they don't follow you around, but they fly on a set path. We might want to think about executing some obstacles, in later level, that follow the users character (to increase the difficulty).

Moon Rocks:
There is no need to know the material for this game, so it is not too relevant. It is simply matching up the numbers.

Pig Toss:
This game is also quite i also quite irrelevant to the material at hand (math). It consists of getting a pig at the right height and distance so a character catches it on the other side.

Math Basketball:
This game requires the player to know the material, however it does not offer any other challenges. The bumble Number game at least offered some object to try and avoid.

Inkster:
I enjoyed this game, just like the first one. It's about the same idea: matching the integer answer to the mathematic equation. However, in this game, there is a choice of answers to one single equation. This was a little more difficult to control because there was a slight delay of when you hit the key and the character moved. I would probably be best to avoid any kind of unnecessary kinks like that so it won't add to the players frustration discourage them form playing.
Also, we both found that the correct answers we not necessarily randomly placed. The correct answers seemed to always be in the same spot.

Mummy hunt:
This game was - i believe - the game that was probably impossible to pass without knowing the material. The idea I liked the most about this was the "To be continued". This adds mystery and motivates the player keep playing and pass the next levels to figure out what is in the pyramid. If we could add an element like this to our game, I think i would push the player to move forward instead to giving up.
Note: One observation made was that the questions given become easier to easier to solve if the game notice you getting worse. I'm not sure if we are able to incorperate that kind of AI into out game, but it is worth thinking about.


Revealer:
This game was not as engaging and entertaining as the previous ones. It required you to know all material, however was just a simple question and answer session. I don't think it is completely out of the question to put a couple of formal code questions in our game, maybe we could think about just placing them at points in the game where the player needs to over come a large hurdle to move up in the game (maybe to complete a level?)

Puzzler:
This game consisted of sticking numerical value in accending order. This could be something to consider when we thing of physical locations of memory blocks ( sticking the correct value into consecutive physical memory locations). The content of the memory spaces to choose from could be in different forms (short pieces of code, which assigning the correct value to a variable).

Peace Doves

Link: http://nobelprize.org/educational_games/peace/nuclear_weapons/index.html

The concept of this game is that you're leading a force of "peace doves", each of which is able to disarm one state that contains nuclear weapons. Each dove has a couple clues to which state they belong to, and you have two tries to get them to the right place. 8 doves, 8 states, and I believe 12 places they could go to.

Good:
Multiple tries for each dove.
Links to further reading after the game.

Needs work:
I had no clue what most of the clues meant! They were all about treaties, and sometimes the second clue would list names (which is how I got some of them). I think it would have been a good idea to add more information like the number of weapons in comparison to the other states.
You were also unable to skip any of the text. That was okay in some places -- you needed to read it, but the opening text and some of the animations just got so boring I wanted to be able to skip it somehow

Lord of the Flies

Link: http://nobelprize.org/educational_games/literature/golding/index.html

This game tests your knowledge of the novel "Lord of the Flies". You have a mini-game at three separate parts of the novel: the boys as a unified group on the beach, the pig's head on a stick, and the final hunt for Ralph.

The first part asks questions about 5 of the main characters: Roger, Jack, Ralph, Piggy, and Simon. You need to match images with each character, which was difficult because I don't remember the book that well. Some were obvious (the conch for Ralph, glasses for Piggy, Pig's head for Simon), some were difficult, and some of the images I couldn't even make out what they were. This one could easily become a guess-and-check sort of game, which is what I ended up reverting to.

The second part has catagories that you are supposed to fit images to, which is supposed to represent the symbolism in the novel. The catagories range from "Law and Order" to "Evil and Chaos" to "Hope and Rescue". I think it was good that there were more items than categories. When you got one wrong, it would give you a clue, and when you matched the right one, you'd get all three of the clues. I had some trouble here, mostly because it didn't register the broken conch as "Chaos". That's totally Chaos. These people obviously didn't have Mrs. Brown's very in-depth view on the novel.

The third part asked general questions about the purpose of the book like "Was it a real story or just an adventure novel". There are three questions, I don't know what happens if you get any wrong because I got them all right.


Good:
The island changed as you moved through the game. At one point the images of the boys split, and then before the last mini-game, the entire island is lit on fire.
I liked the style of the second mini-game. I think it gave good hints, and was a neat way of testing the understanding of symbolism.


Needs work:
The first two games could easily be solved by guessing.
There didn't seem to be a score, so there was no penalty for getting things wrong.
Symbolism is a tricky thing to test, especially if you add extra items. I still have a problem with the broken conch not being "Chaos"

Heating Plastics

Link: http://nobelprize.org/educational_games/chemistry/plastics/index.html

I like the little animation at the beginning that explains the plastic making process. The concept of the game is also really amusing (making plastic ducks) which would probably keep kids playing with it.

The little plastic duck introduces you to how plastics are made. You get a random assortment of 6 plastic items and you have to determine whether you can melt them or not. When you select an item, it gives a brief description of the item, the polymer bonds and a couple facts on how we use that sort of plastic. Once you determine whether it can melt, your cursor turns into a flame and you get to try to melt the plastic. If you're right, you get a catalyst. After all 6 items, you make a duck, the size of which is determined by the number of catalysts you were awarded.



Good:
The duck is funny, often adding jokes in with the text
Able to skip the intro
I like trying to melt things on your own. It adds another sort of amusing interaction



Needs work:
I stopped reading the descriptions after I realized that when the polymers looked like "cold spaghetti" it was meltable, and when they were "cross-linked" it wasn't. I think it was a good concept, but this easy trick made me stop working at it. I would generally say a trick like this wasn't necessarily a bad thing, but it made the game too trivial.

Invar & Steel Alloys

A link to the game can be found here: http://nobelprize.org/educational_games/physics/steel/index.html

This was fun! First the "chef" would give you a couple items you were going to make -- like "cutlery", "surgical needles" or "toasters". He's give a couple properties the metal in this object needed to have like "corrosion resistance" or "flexible".

Then you'd have to pick a recipe for the metal choices range from stainless steel to armor-plate steel to high strength steel. Each recipe gives you a little information, the name, ingredients, and some applications. Next you have to actually make the alloy -- this is just remember the ingredients from the previous screen. Finally you need to drag the items you're making with the alloy onto the screen.

This was a cute little game.

Good:
Made reading about each material essential -- the information was immediately applied but you had to remember it. Multiple iterations would probably get people to start memorizing the basic metals in alloys and the various uses for each alloy.
Had important dialogue, but also allowed skipping dialogue (if you were faster than the speaker)

Needs work:
I can't think of anything off the top of my head that I would change about this game. Nothing really stuck out as "bad"

Game Software

Here's a list of various types of software we've either used or heard about for later reference.

Game Maker (we both used it in CSC212 -- Downloaded to our lab machine)
RPG Maker (Referenced in the Game2Learn article. Downloaded a free trial to our lab machine -- http://en.wikipedia.org/wiki/RPG_Maker_XP)
OHRRPGCE (One of my friends uses it to make games. Swears by it. Downloaded to our lab machine -- http://hamsterrepublic.com/ohrrpgce/index.php/Main_Page.html)

Game2Learn: Improving the motivation of CS1 students

I liked this article. I feel it is exploring the same sort of concepts that we are planning on doing.

The examples they give for their "Saving Sera" game are neat. I think we would want to plan to do something along those lines (Using gamemaker, or learning about this RPGmaker, which might be more what we're looking for)....things like "correctly reorganizing a while loop statement of a confused old fisherman's mind; correcting a nested for loop placing eggs; and visually piecing together a quicksort algorithm. When the player makes a mistake, the character must fight a script bug, which asks the users various computer science questions..." (page 2)

Neat ideas.

I think the most important information I pulled out of this is that feedback (and clear goals) are very important in the game. Without them, some students seemed to question the seriousness of learning through games. It seems that they also help keep students motivated to play (and learn).

Ayiti - The Cost of Life

These are my initial thoughts on the game "Ayiti - The Cost of Life" (http://www.ampgames.com/frame/YXlpdGkubmV3emNyZXcub3JnL2F5aXRpdW5pY2VmLw==/n/.html). I wrote them right after playing the game to help us figure out what made a good educational game and what issues we could strive to avoid.



"The game was really good. I think it was the most balanced in terms of information and fun. It follows a family for 4 years through the four different seasons (dry, rainy, hurricane, and one other I can't remember off of the top of my head). Each season have five choices of where to send the family members. To make money, you can make them work (the jobs depend on their education and the season) or go tend the family farm. To spend money you can send them to school or to the hospital, if they are ill. And in the middle is letting them rest at home, which doesn't affect your money but does affect their health.

Each family member has health, happiness, and education. If they lose all their health, they die, and if both parents die, you lose. The goal of the game is to maximize their educational certificates and not -- you know -- let them die.

It's interesting because once you start a season, there are a variety of things that can happen. You can send people to the hospital (in the middle of the season) or home if they get sick, and they can get kicked out of school if you run out of money. If you don't make enough money each month, your living conditions can worsen and you have a better chance of getting sick. If you have surplus money you can go buy stuff at the store (like school uniforms, bicycle, or indoor plumbing) that improves their living conditions. I really like the interplay of factors and consequences.

At the end of each year you get a mini year-in-review, and then at the end of the game you get to see what job people most did and their prospects for the future.

I also love the little sound effects when you move them between the various places on the map."

Oil God

These are my initial thoughts on the game "Oil God" (http://www.addictinggames.com/thearcadewireoilgod.html). I wrote them right after playing the game to help us figure out what made a good educational game and what issues we could strive to avoid.


"This one has potential -- my concern is that it's going to be too much of a game and not enough information. I wish they had more explicit stats fo government/economy types. That's my current feeling about the game."

"I think this one is leaning towards the very game-y, at the cost of some of the information -- then again, with the oil situation being so variable, maybe that's a little more ok. Just some teaching, and more getting people thinking about it?"

"I don't think this style would work very well for what we are trying to do. It's too situational -- you don't really come away with concrete facts"

"Oh...I do really like that it has music."

Darfur is Dying

These are my initial thoughts on the game "Darfur is Dying" (http://www.darfurisdying.com/). I wrote them right after playing the game to help us figure out what made a good educational game and what issues we could strive to avoid.



"Good information around camp, but...well...I found the most information came when you lost the game, not when you did something good. I suppose that makes sense, if you're thinking about it in the way of people suffering, but it almost made me want to lose to find out the fates of the various people when caught by the militant group in the Sudan. Narratively it made sense -- they don't have a terrible fate if they aren't caught, but those were the most touching pieces of information since those were *my* characters that were lost. The water (mini?) game itself was easy, so you rarely got even that."

"It's almost totally unclear what to do in camp, except move water to fields (or buildings, if they need repair)."

"You don't need to hide every time a truck comes. In fact, boys can pretty well avoid trucks completely! All you need to do is send the little kids out. Maybe that raises threat or something? I think it was a better mini-game when I thought I needed to find a hiding place every time I saw a truck coming."

Stuff from the old google document

Our brainstorming outline when we thought we were writing another proposal with the game project, keeping it for reference

Purpose: To provide another resource to help Computer Science students understand the concept of pointers
Target Audience: 1st/2nd Year Computer Science students

• Our goal is to provide simple (2D) games that allow students to build the intuition and understanding of pointers as used in high level languages like C/C++
  
• Additional Questions we would like to answer: Explain the purpose of pointers, how they work, why are they used, as well as how to use them correctly. What are the side effects of using them incorrectly? Syntax (& and * are characters in the game?)
• Methods used:
• People learn in different ways
  
• Sometimes difficult concepts need more than one teaching method to "click"
• Learning from practice, to help understand the theory
• One method mentioned: people who understand assembly and indirect addressing, understand the abstract idea of pointers in higher level languages better
  
• Possible to learn concepts while doing other activities
  • Games can teach a variety of things
    • Logical Analysis
    • Math (Phoenix Quest, E-GEMS, 1994)
    • Social Issues (from "Digital Games Target Social Change", Keri Schreiner)
      • Darfur is Dying (http://www.darfurisdying.com/)
      • Peacemaker (http://www.peacemakergame.com)
      • Oil God (http://www.addictinggames.com/thearcadewireoilgod.html)
      • Ayiti - The Cost of Life (http://www.ampgames.com/frame/YXlpdGkubmV3emNyZXcub3JnL2F5aXRpdW5pY2VmLw==/n/.html)
• Design a game to explain how pointers work to give alternate methods to teach pointers
• Do a case study
• Use Control Group
• same test, no game
• Traditional methods of teaching and test after?
  
• Test again 2 or so weeks later?
  
• Use Group with Game
  
• Test before
• Play game
• Test after
• Test again 2 or so weeks later (retention?)
  
• Background research to be done
• Math/CS educational games (http://csunplugged.com/index.php/get-unplugged.html)
  
• The educational games above
• Analysis (all questions should have "and why?" added to them):
  
• What makes this a good game?
• What would make this a better game?
• How effective are these games at presenting their issues?
• Does the concept get lost in the gameplay?
  Were the users engaged (Cognitively , motivationally, and behaviourally engaged (stratagies, did they need to think to succeed?)
• Teaching Status Quo: Look at really good slides by Prof. Jack Tumblin's slides:
  
• http://www.cs.northwestern.edu/academics/courses/110/notes/18.ppt
• http://www.cs.northwestern.edu/academics/courses/110/notes/19.ppt
• http://www.cs.northwestern.edu/academics/courses/110/notes/20.ppt
• Teaching methods that have failed. Why?
• other alternative methods used introducing new concepts
• Furthermore, games used to introduce new concepts to different levels of education (to understand how to slowly but successfully integrate all key aspects of our subject)
• Any existing games which incorperate pointers
• Based on the educational level of the student, we assume that they are familiar with
• the C language
• Memory of a computer (that it exists)
• The game will introduce the sytax used to reference and dereference pointers
  
• Evaluate game play:
  
• (Reference for Elyse and Donna: see http://webhome.csc.uvic.ca/~agooch/talks/MSGames/Hadwin%20&%20Irvine%20Microsoft%20presentation-1.ppt
• In the furture?
• Further elaborate on pointers (functions, void pointers, etc)
• additional key concepts