September 2010 Archives

html & css Project Proposal

| No Comments
Although it might be rather ambitious, I'd like to create a web app for the Setonian Online. At a later time, I'd like to also work on revamping the S.O. regular site as well, but for now, let's just focus on the iPhone/iPad application. To gather inspiration, I downloaded and analyzed several existing News Apps.BBCPort.jpg

BBC News has a two-view interface that's similar to my vision for The Setonian. When in the portrait orientation, the page will show the nav_bar above the selected story.


When in landscape orientation, the app is split evenly: half of the display shows
 the article selected while the other side allows the user to browse through other stories.

The Problem: The "icons" used for BBC's all feature photos--something the Setonian doesn't always include.


I'm probably going to model the App's top nav_bar after the one used in theHuffington Post. It is a simple nav_bar with a colored background and white text. 

I really didn't like the rest of the Huff Post's app. It reads too much like its webpage. However, I did like that the majority of the page displayed a large photo to link to the lead story. However, for purposes of our app, I think it would be best to stick to the basics for now.


Out of all of the Apps I viewed, the USA today's was the least user-friendly. There is no sliding Nav_bar or easy way to otherwise navigate through the site. Furthermore, nothing really changes when you shift from portrait to landscape.



Cnet has a simple design. It displays a simple nav_bar across the top and then includes a list with chevron links to stories. Some headlines include photos, but all do not, which is ideal for our pages.  At the bottom are additional links: News, Twitter, Search, Favorites, Etc...

For my project, I'd like to create a hybrid using different ideas from each of these web apps. 

Portrait orientation:

A cross between Huff Post and Cnet, I'd like the page to have a nav_bar similar to the one in the Huff Post. If design permits, I'd also like to include an oversized image to go with the main story on the page. From there, the remaining stories will be sorted in a list similar to Cnet's app: the stories with photos will have a thumbnail image next to them, but photos will not be necessary. When a story is selected, a new page will open for the user to read the story.

Landscape orientation:

This display will be very similar to BBC's landscape orientation, with a slight twist. As with BBC, when the story is selected, it will be displayed on the right side of the story, and the user will still be able to browse through other stories. However, instead of using the thumbnail/caption links, I'll use the same list style as in the portrait style. The Nav_bar will remain at the top as well.

The next step:

I'm going to create some hand-drawn templates before I move on to creating a mock-design in photoshop. From there, I'll implement the code. I hope I'm not biting off more than I can chew!

Inform 7 Portfolio

| 1 Comment
For my inform 7 initial project, I decided to create a semi-mystery game, where the player must navigate through a crime scene (the victim's house) in order to collect clues and solve the murder. Although I did not play any actual mystery-text adventure games, I drew my inspiration from two specific games: 

Slouching Towards Bedlam is a game where you're moving towards a creepy insane asylum. I played it as a freshman and just really enjoyed the dynamics. This game was very difficult, however, because you really had to be thorough to find all of the items and descriptions.

9:05  We've covered this game several times, but it's still one of my favorites, mostly because you can solve the game within the first few turns if you know to look under the bed. Even though it makes you do mundane, everyday items, like taking a shower and driving your car, it still teaches the basics of the game. This game inspired me to use the "look under the bed" feature in my game as well.

My major influencer for creating this game is my love for mysteries in general. For as long as I can remember, I've been watching Law and Order with my mom. I still enjoy reading a good Agatha Christie novel. And, I'm not too ashamed to say that I still play the Nancy Drew interactive mystery computer games--although, I now buy them at least a year after their release at a much discounted price.

I also wanted to be able to create multiple endings in my game, and I figured a mystery might be the perfect way to implement something like that. Of course, initially, I planned to let the player determine who the murderer was depending on the clues he collected; however, I ran out of time, and decided to focus on two endings for now. (See below!)

[Opening sets the mood?]

When I look back to my freshman year, I'm really proud of how far I've come when it comes to coding in Inform 7. This was the first time I really utilized the manual inside of Inform 7. With the help of some tutorials and sample coding, I was able to both code an item to appear "under the bed" as well as code a player to find an item in the last dresser drawer. Of the two, I'm especially proud of the dresser drawer coding, because it was much more complex than the "under the bed" coding. Also, I was able to troubleshoot without asking for help from Dr. Jerz to fix my coding when I found errors. Here's a sample of some of the coding:

 A drawer is a kind of container. A drawer is always openable and closed. The description of a drawer is "The dresser drawer is crimson just like the the rest of the furnature in the room. It looks like there's a bloody handprint on one of the drawers. Maybe you should look inside..."
  The top drawer is a drawer. The middle drawer is a drawer. The bottom drawer is a drawer. The top drawer, the middle drawer, and the bottom drawer are part of the dresser. A drawer can be explored or unexplored. A drawer is usually unexplored. Instead of searching a closed drawer, try opening the noun.


After opening an unexplored drawer when exactly one drawer is explored:
now the noun is explored;
say "You use some force to open the second drawer. Again, you find nothing but the victim's clothing."

Before opening an unexplored drawer when exactly two drawers are explored:
move the bloody knife to the noun;
now the noun is explored.

There's more code that makes this example even more complex, but I don't want it to weigh down the length of this blog entry. Basically the only way the player can obtain the "bloody knife," which is a key object to the game, is to search the entire dresser. Only one of my usability testers took the time to do so. 

A few things make the game more complicated as you get further into gameplay. First, the coroner "arrives" after 15 turns, removing the body, along with some key evidence, from the scene of the crime. The game is still solvable without this evidence, but it adds to the story...The whole point of this game is to search as much of the house as you can in order to collect as many clues and uncover the mystery as quickly as possible, because the game also terminates after a specific number of turns (see endings). 

I didn't have time to create a point system in my game, so the only rewards I created to encourage gamers to continue playing the game is the clues. As he examines more clues, he uncovers more and more of the mystery, as welll a background information concerning the victim's love and personal life.

Initially, I planned to create a game with several endings--I wanted to allow the user to determine the killer depending on which clues they collected; however, because I was short on time, I limited my gameplay to just two endings.

The losing ending: The game terminates after a specific number of turns (If i disclosed this information, it would ruin the game!) After a specific number of turns, I end the game saying that the murderer got away with it, and killed you along the way.

The winning ending: Once you collect a certain number of clues, you have to give the partner two specific clues to win the game. Again, I'm not telling what clues, because that'll ruin the game :-)

Credits: I used a couple coding samples in the Inform 7 manual and also received help from Dr. Jerz:

Princess and the Pea (for looking under the bed)
I also used coding for the dresser drawers, but I'm having trouble locating the coding example in the manual.

Usability testing:

1) I used my mom again for my usability testing, because she's about as blunt as they come. She never worries about hurting my feelings and took no time at all in picking out all of my proofreading errors...thanks Mom :-) She's also a big fan of Law and Order and mysteries, so I had to smile when she tried to "bag the knife." Logically, this made sense, she argued: Why would she want to take the knife? This would put her fingerprints all over it, thus rendering the knife useless as evidence. This prompted me to plan a third ending for the game when we return to it--the player is wearing rubber gloves. If he removes the gloves and touches a clue, he loses the game, because he is tampering with evidence.
She skipped over the purse, phone and partner in the first room as well. This made me think about how I can motivate my users to explore more in depth. When she read that Tim had fingerprints on the knife, she tried to "find Tim," and didn't understand why that was not recognized. Alas, she's never played a text-adventure game, so this really didn't surprise me. And, she never made it into the kitchen.

2) I used two of my golfer-gals for usability testing. Golfer 1 was confused as to where to navigate from the get-go. In some cases, my descriptions mentioned doors that no longer existed (because I ran out of time to code these rooms), and in other cases, the rooms didn't mention where any of the doors were. It prompted me to take a deeper look at my map to make sure all of my rooms are covered.

Golfer 1 was able to successfully navigate to the red room, with my help. From there, I discovered an issue in my code concerning looking under the bed. She had no need to "look under the bed," because the object that's supposed to be under the bed is already displayed in the default description. I had to make the item "scenery" in order to hide it from the initial view. When she tried to examine the dresser, it said there was no such thing, so she never had a chance at finishing the game. 

3) Golfer 2 was the most successful. She made it upstairs on her own. She even figured out that she could "open drawers" even though the dresser wasn't present. 
She was also the only one to examine the purse, which was useful, because for whatever reason, it wasn't openable. 

A similar instance happened in the kitchen. You're supposed to open the refridgerator to find a clue, but the game wasn't even registering that a fridge was in the room. 

All in all, I feel like I was very successful with my coding thus far. I'm excited to take a break and come back to the project in a couple of weeks, because Inform can be extremely frustrating. 

Inform 7 Game Plan

| 1 Comment

For my IF game, I'd like to try to create a murder mystery of sorts. This is the first time I've ever attempted to write a mystery, so it's gonna be an interesting experience.


1. Games that Inspired me
--Slouching Towards Bedlam. I played this game two years ago as a freshman in EL 236. I enjoyed the mystery aspect of the story
--9:05. I've always loved the double endings in this game...and also the fact that user typically doesn't realize he's the murderer during his first play through the game
--photopia. It's been a while since I visited this game, but I always loved the fact that it seemed like the user would move from setting to setting almost at random. Although I'm not planning to implement this in my game, I do value the complexity of the game.

2. Setting (see drawing)
Genre: mystery

3. PC is homicide detective, female. Has partner. Dressed professionally.
Inventory: notepad, cell phone, gun (loaded, safety on), pen, wallet (license, credit cards, a few assorted dollar bills--$34)

4. Concrete objective: find all the clues. Navigate through the house to collect evidence. Process at crime lab. Tell partner who committed the crime correctly with all evidence to complete the game

5. The body hasn't been taken to the coroner's office yet. The victim's blood is everywhere, on the walls, the ceiling, the couch, the never thought a human could have so much blood in his body. The living room is a disaster, even without the blood. The books from the bookcases cover the floor, and are covered with blood as well. It appears the victim put up a struggle. She didn't go down without a fight. Your partner stands in the corner, disgusted by e scene in front of him. You only have 48 hours to solve this murder before it becomes a cold case. You shudder at the thought of another murderer roaming free in YOUR city.

X living room: the living room looks pleasant enough, or at least it would without the blood everywhere. Yellow caution tape lines the doorways; only specific individuals, like yourself and your partner are permitted in the room. The vicitm's body is laying in the middle of the floor. There are books laying around the room, and you can hear a quiet hum coming from the tv. The evening news is on, but they haven't heard about is crime yet. If they did, they wouldn't be smiling.
A door leads to the west, south and southwest.

X victim: female, around 24 years of age, pretty girl. Blond hair, wearing a striped sweater and jeans. No shoes. The laceration to her skull appears to be the cause of death, but you wont know that for sure until the coroner takes a look. She has scratches on her arms and face, as well as a mark on her neck where it looks like a necklace was ripped from her. She is wearing a watch, and her cellphone is lying next to her as well as her purse. She was probably attacked as soon as she walked in the door today.
X cell phone: the last phone call received was at 1:32 pm. That was hours ago. How long was she lying here? The last text received was from one Benjamin Conrad. There are assorted photos in her phone and hundreds of contacts.
X purse: the purse contains a date planner, an iPod, the victim's wallet and a Luna bar (power bar)
X wallet: inside the wallet is the victim's license, her pnc debit card, $1000 cash ( who walks around with that much money in their wallet, and why didn't the murderer take the money?) a folded up piece of paper, her blood donor card, and a picture of the victim and a man (her boyfriend?)
X license: according to her license, the victim's name is Felicity Williams. She turns 25 today, October 2, 2010.
x photo: the back of the photo says, Summer, 2008 in the picture, the two stand in an embrace, genuine smiles on both their faces.
X paper: the paper simply reads, "see Rudy about $$$"

6. The player will figure out what to do because I will include a brienf "tutorial..."
You only have 48 hours to solve this case, so you better start investigating and EXAMINING evidence. This is a big house after all.
7. The game will get harder, because the game will count the steps of the user. When they reach 25 interactions, the clock loses an hour. They must complete the game in a certain amount of time.  The player must not only collect information but must also process evidence at the lab.

8. The game will have 2 endings. To win, you must collect x-amount (tbd) of evidence to convict your suspect. Once you have enough clues, you jut need to interact with your partner, and say something along the lines of "Suspect (John doe) is the murderer" the partner will not agree with the user untill they collect enough evidence.
The second ending: if the user does not solve the murder mystery in "48" hours, they will lose, and the murderer will strike again. This time, you are the victim.

9. If I run short, I'll limit the amont of rooms accessible for the time being and will make the number of required evidence smaller

10. If I have extra time, I'll include some other areas away from the home and crime office to investigate, such as the victim's job and boyfriend's apartment. 


EL 405

Mouse! Scratch Portfolio

| No Comments

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.

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.
pic1.jpg           pic2.jpg

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.
pic3.jpg    pic4.jpg    pic5.jpg

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.


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.

Usability Testing is REALLY Useful!

| No Comments

In a good usability test, your testers will use your document to do whatever your real users want to do.

--Usability Testing: 8 Quick Tips


I've already worked through a couple usability tests. Both have been very successful, and have proven the above statement. However, because this statement is true, I've still got a lot of work to do on my project. At this point in time, both of the individuals I used for testers looked to me for directions on exactly how to play the game.

"Do I just use the arrow keys?" They both asked me, so it looks like that's where one of my greatest weakness lies. Because of this observation, I'm moving that up to the top of my list on my agenda.

I like to think of Usability testing as a parallel to asking someone to read over my rough draft of a big term paper. I usually lose points on grammar, because I've read something so many times that I cannot see my own errors. In a similar fashion, it helps to sit back and watch an outsider work her way through my program, because it shows me where my strengths and weaknesses are. For example, I mentioned in my progress blog last week that my first usability tester found an alternate route through my maze. Had I not done usability testing, future gamers would've avoided much peril in my game.

At this point in the stage, I'm still working out a lot of bugs, but the project's becoming quite polished. I need to do probably two additional usability tests to work out the remaining kinks. I'll try to blog again with those results as well.


EL 405

EL 405 Scratch Project Progress Report

| No Comments

At this point in my scratch project, I've developed two distinct maze levels for the user to navigate through. I created three sprites thus far that generate a game over screen when the user's sprite (mickey) touches them. I'm still in the process of creating an "intelligent" game sprite that can navigate its own way through the maze levels. I've got a few ideas on how to make this happen, but I'm focusing on creating the third level at the moment.

So far, I've had one successful user testing subjext. One of the freshmen on my golf team trie to navigate through the first level of the maze. As it turns out, she was unsuccessful, because there were a few narrow coridoors that were not passable. My tester also found a second way to navigate through my maze. This second route was not my intention, because it took about half the time compared to the other route. Since her testing, I've created an additional wall to block off that route.

At this point, I'm still having some glitches when the user runs into walls. I keep finding temporary solutions, but I'm not satisfied. I'm really worried that I'll have to make the corridors wider, which will make the maze easier in my opinion. I'm going to further explore my options before settling for a less extreme version of the current glitch.

Here's my list of things to do by next thursday:

  • Create 2-3 more levels (5 total?)
  • Create the intelligent sprite(s)
  • fix the on-going glitch where the user sprite gets stuck on walls
  • Create an introduction
  • Create a button sprite on the game over screen that will start the user back at level one
  • Create the "win" background
  • Make the bat and cat sprites hover over the actual navigating antagonist sprites.

These goals are in no particular order, and I'm aware that I probably won't complete every task on my list. I'm determined to finish as many as I can, but I'm going to focus the majority of my energy on making the bats and cats over, creating the winning screen and fixing that glitch.

EL 405


About this Archive

This page is an archive of entries from September 2010 listed from newest to oldest.

May 2010 is the previous archive.

October 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.