Project Goals

Our goal is to provide first and second year University students with a simple game that allows them to build the intuition and understanding of pointers as used in high level languages like C/C++. An educational game online could help motivate and engage these students to participate in a meaningful and educational activity and to explore key concepts outside of the classroom. Putting their theory into practice reinforces the theoretical elements and aids in their retention.

Monday, August 18, 2008

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.

Sunday, August 17, 2008

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).