Tuesday, July 3, 2012

7/3 - Game Mechanics

This past week our team met to go over game mechanics. We discussed how the user would interact with our game as well as elements within the game that would add to the user experience. Below is a mockup of the user interface design that we came up with. The device shown is Apple's iPad.


The UI is designed so that the user can hold the mobile device with both hands at all times, using their thumbs as the main point of interaction with the game.



Game Mechanic 1: Movement
The UI contains 2 "joysticks", located in the bottom left and right corners. One joystick allows the user to move their character in whichever direction they choose, and the other determines which direction the user is aiming their weapon, item, or whatever else they might have equipped.




Game Mechanic 2: Map & Portal
The Map and Portal buttons are located in the top left and right corners. They are smaller than the movement buttons, as they are not needed as often. If the Map button is tapped, the game is paused and a map screen is displayed. The map screen shows where the player has been before, and areas that have yet to be explored in the level. The default state of the Map button is a translucent map icon indicating its purpose, with a little red arrow that travels along the circumference of the button as the player moves to indicate which way is North, so as to allow the player to keep his bearings without having to constantly pull up the map screen.





The Portal button implements a unique in-game mechanic that provides the "hook" of the game that will get users to want to play the game again and again. Below is a brief explanation of the hook:
  • In the game there are 3-4 playable characters, each with a specific skillset and weapon. When exploring the level and capturing creatures, specific characters will be required to complete certain tasks based on what skillset is needed at that time. The active character is always in possession of a "portal" item that can be dropped or carried at any point in time. Whenever the user needs to switch out characters, the Portal button is pushed and a "Character Stats" screen is displayed. The player can view the stats of the characters, and then select which character they want to use. The player is then returned to the level, and the new character "ports in" to wherever the player dropped the last portal item. This allows for the player to experiment with different characters in trying to achieve the goals of the game as quickly as possible, as there is still a time limit.




Game Mechanic 3: Health, Oxygen, and Time
As the game takes place on another planet, each character has an oxygen supply that runs out the more they are played. They can replenish their health and oxygen with in-game items, or by being switched out and porting back to base. If oxygen or health runs out, they are automatically ported back to base where they stay and are unplayable for a specific amount of time. This keeps the player from only using one character all the time. The purpose of the game is to figure out the most efficient use of the characters' skillsets and weapons to beat the level in time before the planet "dies", all the while trying to keep each character from completely losing oxygen or health. The amount of oxygen, health, and time left for the current character are displayed in meters at the bottom and top of the screen. These meters display the levels of each element, so as to warn the player when they get low.



Game Mechanic 4: How You Win
The game ends when the timer runs out, signaling the death of the planet. The goal in this game is not to save the planet, as is the case in most sci-fi games, but to do as much good as you can until the end. Throughout the game the player accomplishes tasks and gets points for different achievements. Points can be gained from things like collecting items, capturing a creature, not letting any of the characters run out of oxygen, beating the level quickly, using teamwork to defeat an enemy, and other things. The player loses points for killing creatures instead of capturing them, allowing an active character to run out of health or oxygen, and other "bad" things. The potential replayability of this game is very high because there are a myriad of ways to beat the game. Using a specific combination of the characters may not have been as efficient the first time around, so playing the game again and learning from your mistakes the previous round will benefit you the second time around.

2 comments:

  1. Very well thought out and concise; you've done a good job of crafting all our meeting discussions into a coherent write-up.

    Some suggestions though:
    (I'll bring these up at tonight's meeting so we can discuss, but it seems prudent to make a written record here.)

    1. I don't know if the character silhouettes you have here are example clip art or were designed by the guy who's doing concept art. It is a good idea to do silhouettes to flesh out the basic design, but if these are the proposed character silhouettes, then I have a concern that the two outer silhouettes are too similar.

    Tool/weapon and hair/helmet style look different, true, but I'm not sure if that is enough. I might have more specific suggestions once I know what each silhouette's character does.
    ------------------------------------------
    2. You mention that when a character's oxygen or health runs out, he/she immediately transports back to the ship. Since this essentially, as I see it, means none of the characters can actually "die" and become permanently unusable for the remainder of the game, I think we could add a greater threat to push the player to keep these characters alive as long as possible.

    Say, for instance, that when a character's health or oxygen reaches a low amount, 15% maybe, that character will automatically transport back to the ship, same as we currently have planned.

    However, the player can choose (maybe through the character selection or stat screen, viewable at anytime like the map) whether he/she wants to disable this automatic "Salvation Transport".

    That way, the player can decide to effectively sacrifice a character for the good of the entire mission, allowing a possibly critical task to be completed by that character (much better than any other character could perform said task). Scoring can be debated--maybe a "sacrifice bonus" if a character is sacrificed closer to the end of the game, to offset a potential flat rate penalty for losing a character?
    My basic point is allowing a character to die, permanently, may open up replay-ability doors, as well as adding some potential drama to our apocalyptic game.

    (continued in next comment)

    ReplyDelete
    Replies
    1. (continued from previous comment)

      3. I like that the planet is already doomed. But the health bar you have above could use more work, I think, to visually get that fact across. I realize that this point, like the character silhouettes, may not specifically apply if the aforementioned aspects are purely placeholders. In which case, points 1 & 3 can just sit here as potential design aspects. More or less cosmetic and not game altering, but still something to consider down the line.
      ------------------------------------------
      4. Not really a point like the others, but I've been trying to "break" this UI to test it as far as I can in my head. The UI buttons look nice, but I was attempting to find a scenario where the player would want to shoot at the same time, or near the same time, as he/she teleported. In such a situation, that action of quickly jerking the thumb while the iPad is already being held might prove awkward.

      I doubt this would be an issue on any iPhone port we made (if that's still on the table). But with the iPad's relative size, that movement might be an issue. Maybe move the teleport button closer to the aiming button, if we don't mind breaking the "each corner has a button design". (do we have a "fire" button? does the aiming button also fire the weapon? do we even need a fire button?)

      In any case, this is probably the least pressing of my points, since in most gameplay scenarios the movement may not need to be rushed enough to constitute an issue. Still, something to think about.
      ------------------------------------------
      My only reason for posing all these questions is to stimulate the design and development process as much as I can. I'm not expecting any one person to completely answer all of these alone, of course. :D Thanks for reading this far! :D

      See (Saw) you at the meeting!
      Cheers!

      Delete