For my scratch project, as the class already knows, I chose to create a maze game. Why? Because mazes are cool! And, they present an interesting challenge depending on how you decide to create them. After going through some major issues with programming some of my sprites, I've turned out a pretty respectable game, but as always, there's tons of room for improvement. Before I get too far into my game, let me reflect and remark on the games that gave me the most help and/or inspiration.
Reviews
Mazes, created over 3 years ago, gave me the idea to create sprites that will force a "game over" screen. However, I'm very proud to say that I didn't copy the code from this game, because a lot of it was too complicated for me to understand. Nevertheless, I was very impressed with the creator's ability to make his sprites turn at the appropriate corners and switch costumes as well.
MazeGame was another pretty impressive game. Instead of using the arrow keys to simply maneuver through the world, the user must use them to also avoid touching the walls, because the sprite automatically moves on his own. Although I thought about this approach for my game, I decided to go with a more traditional feel, simply because I wanted to make my maze levels more complex and with tighter corners.
Opening Screen Instructions
To make my game a little more complex, I created a two-way menu on the opening screen. Advanced or familiar players could simply click start game to bypass my tutorial; however, if the user chose "Directions," they would be launched into a basic level with instructions cued in the upper left-hand corner. After my last usability testing session, I discovered that the directions were still not as clear as my gamers would like, but this was not one of my major priorities for revision by the deadline, so this part of my project has been put on hold until I can revisit the game at a later time.
Still, the directions page of the game introduces the basic controls, explains the objectives and warns about obstacles. Another complaint from my usability tester #3 (a.k.a. Mom): the tutorial was way too long--I shouldn't have made the user go around in circles so much.
Level 1
My game is divided up into three levels of gameplay, plus the tutorial level. For level one, I included a small number of "evil" sprites to create obstacles for my users.By using a dark background, I was able to make the bats almost invisible.
The point of each level is to navigate Mr. Mouse from his corner of the room to the other corner so he can be with his lovely Lady-Mouse.
Here's a look at the full screen.
Level 2
The main way for me to keep my users interested was to create a more complex maze. Aside from presenting this new challenge, I made some of the corners tighter (which can cause the user's sprite to get stuck) and created some more bat sprites to hover around. I made it more difficult for the user to avoid the sprites as well by forcing them to pass each sprite to meet up with the LadyMouse. Users should feel rewarded as they complete the level, because they must be very patient to complete this level.
Level 3
My third level of maze-craziness is definitely the most complex. Along with several sprites to cause mayhem for the user, I created a lot more dead ends in this level, which will hopefully keep the user occupied and determined enough to win. If the user is able to defeat this level in the maze, he or she has won the game!
Win screen
Out of all the aspects of my game, the "win screen" is definitely the weakest link. At this point, all it says is "you've reunited the mice! Congratulations, you win!!" I don't have any other excuse other than I was more concerned with perfecting the coding for my game than I was to perfect my win screen. After all, what's the point in a win screen if nobody's interested enough to get that far?
Lose Screen
The lose screen explains to the user why they weren't successful and suggests that they try again.
At first, I was going to create two ways for the user to lose:
a-The user's sprite accidentally touches the walls in the game. I changed my mind quickly, when I realized I couldn't beat my own game because I created very narrow corridors.
b-If the player comes in contact with any of the bats roaming around the mazes, they automatically lose the game and are prompted to please try again.
Credits
Thank you to all of the minds at MIT who helped make Scratch. It's always been a dream of mine to create my own video game.
Dr. Jerz--Thanks for helping me understand why my sprites seem to have minds of their own!
Scratch Forum: I used the forums to figure out how to make my bats hover overtop of smaller sprites with great accuracy.
Usability Testing Report
Tester 1: Female, Age 18 Minimal exp with video games
I conducted my first usability testing very early on in my project, when I only had about 1 level completed and was still working on including the sprites. This test was probably the most useful, because it showed me that I'd accidentally created two exits for the user to navigate through to reach the LadyMouse. From this test, I also realized that some of my corridors were too narrow for my sprite to navigate through. This prompted a redesign and reprogram of Mr.Mouse.
Tester 1 also asked me what she should use for controls, because this was before I created the directions page.
Tester 2: Female, Age 19 Minimal exp with video games
Right off the bat, this Tester asked me how to navigate through the mazes. "So, do I just use the arrow keys?" This second comment made me realize that I shouldn't assume that everyone will Know they need to use the arrow keys to play the game. I guess not everyone's as serious a gamer as I am. She too had issues navigating through the maze. This prompted a temporary smaller sprite to use for the remainder of my testing. At the end of my revision, I switched back to the traditional Mouse figure.
Tester 3, Female, Age 50 Old-school gamer
This tester, my mom, played video games for years before she had me and continued to play video games with me as I progressed through school and life. Since she's not a huge fan of 3D games, (she loved Mario for the NES and Tetris), I figured Mom would be a great tester for the game. Even though she's my mom, she's very critical about my schoolwork, and told me straight up what she did and didn't like about the game.
Even with the inclusion of the directions page, I found her asking me what the controls were. I think the directions are simply too hard to read on the screen (bad foreground/background relationship). She made comments that the game was "too long" and that the sprite didn't move quickly enough. However, she did admit that maze Level 3 presented a challenge, because it looked much more intense than the first two levels. If I'd had more time, I probably would've revised my actual maze backgrounds to better suit her expectations, but for now I'll just have to make due.
Closing Notes
This has been a very educational experience for me. Although I doubt I'll ever be creating Scratch games for my future employment, I do acknowledge that this was a great experience with learning new to use and troubleshoot my way through new software. It's taught me a lot about patience as well, because my sprites did a lot of crazy things that were not easily resolved (in fact, some of them still have minds of their own). At this point, I'm anxious to create another Inform 7 video game--it's been 2 years since my King Arthur adventure game. I just hope I'm as successful with that as I was with Scratch.
]]>
