Thursday, February 27, 2014

J6

Most of the responses I got from the people who play tested my game were similar to what I expected, but there were still a few differences between their experiences and my expectations. One of my biggest worries about the game and something that a lot of the people who play tested my game said was that the weapons that I currently have in the game are not balanced at all. Some of the weapons are really powerful without having any significant drawbacks. One of the play testers suggested that I could fix this by treating the items as probabilities (each weapon has a damage value and a hit percentage) and then balance them by making the probabilities equal. One of the differences that I noticed, though, was that the play testers did not approach the strategy in the same way that I thought they would. When I was designing the game, I expected players to take a certain approach to buying items and general combat strategy, but the play testers' strategy was quite different.

As it stands, the game is not very functional, complete, or balanced, but this is about what I expected so I'm not too worried. I knew that the game would not be balanced because I couldn't think of a good way to chooses parameters for weapons and characters, and I just chose numbers semi-randomly. It's hard to make the game complete at this point, I think, because I'm planning a story and several levels for the player to go through, but only made a test scenario with a few example items for the demo. Lastly, the game was a little less functional than I thought because the calculations that are required during combat took longer than I anticipated, but this should be cleared up once I begin to program it.

This prototype made me think more about how much work actually goes into making a new game. I had always guessed that new video games always started as programs, but it seems that having a physical model for the very first prototype is a good thing. It helps you to think more about the game itself and less about how you implement it.

As a prototype, I was quite pleased with how the play testing went, and I don't think the game needs too many large overhauls. I have played with numbers on the weapons and characters to make them more balanced (for example, I've lowered the damage on the battleax, which was overpowered before, from 13 to 11). I've also added an element to the characters to give them proficiency with weapons in order to align people's strategies more closely to my idea of how the game should be played. I did this because some people tried to play a mage (who should stay in the back and attack from a safe position) as a fighter (who runs in and fights up close with the enemies). As I continue to work on the game, I'll work on adding more characters, weapons, and levels as well.

Sunday, February 23, 2014

A3

For the game, there are 3 floors and one elevator. Each floor has a ball on it that must be picked up in order to get the elevator up to the next floor. Once the player has collected all three balls, he wins! If the player falls off, then he will be replaced on the bottom floor. The controls are simple: up is forward, down is backward, and left and right turn the player.

Tuesday, February 18, 2014

J5

For the prototype, I've tried to keep things simple and make sure that I have the basics right. Therefore, the player will only set up for and then participate in a small battle using three characters. I have prepared six characters for the player to choose from and an array of weapons and armor for them to buy beforehand. The player will then use the three units he chose with the equipment he bought to try to defeat two wolves and three bandits on a small (6x7) map.

The actual combat takes quite a few calculations, so I'll explain them here:
  • Damage: calculated differently depending on the weapon...
    • Swords & Axes & other: 2 x Strength + weapon's damage
    • Twin Swords & Bows: Strength + Dexterity + weapon's damage
    • Spears: 1.5 x Strength (rounded down) + weapon's damage
    • Staves: 2 x Intelligence + weapon's damage
  • Defense: Constitution + 1/2 Strength (rounded down)
  •  Magic Defense: Wisdom
  • Hit: 3 x Dexterity + weapon's hit
  • Avoid: 2 x Dexterity + Intelligence - armor's penalty
  • Critical: 2 x Luck
  • Dodge: Luck + 1/2 Wisdom
In combat, the actual damage dealt to the other character is (damage - defense) or (damage - magic defense) if the opponent is using a staff. To determine if the attack hits and deals any damage, a random number generator (between 1-100) must produce a number under the value (hit - avoid). Likewise, to determine if an attack lands a critical (dealing 3x damage), an RNG must produce a number under the value (critical - dodge).

On each player's turn he can choose to move each of his units up to 5 spaces. If the unit is wielding a sword, twin sword, axe, spear, or other (i.e. claws, bite), then he can attack after moving. Otherwise that unit is done. The game is over once one side has been defeated.

Each character can wear one piece of armor and carry up to two weapons. If the character is carrying a sword, then he may take a shield instead of a second weapon, which would increase his defense. Regardless of whether or not the character has two weapons, he may only attack with one at any time. For the purposes of the prototype, the player will start the game with 3300 gold with which to buy equipment.

Wednesday, February 12, 2014

J4

Since I play a lot of RPGs, the game I would design would probably be an RPG. I've kinda been playing around with an idea for a game in which the player starts by inheriting a guild in a fantasy setting and then has to build up the guild's reputation and members by completing quests and the like. The game would have two main parts to it: managing the guild and partaking in quests. While managing the guild, the player could do things like buying equipment, recruiting new guild members, and upgrading the guild's facilities. While out on quests, the player would command guild members on a 2-D grid while trying to complete the quest's objectives (e.g. protecting a convoy or defeating enemies).

In the game, there would be player characters (the guild members), and two types of computer controlled characters (enemies and neutral/friendly characters). Each of these characters would have certain stats (such as health, attack power, magic power, defense, etc.) that are affected by leveling up, changing equipment, and possibly some special training (not sure if I would do that). Likewise, the characters would have different attacks based on what weapons they are using. Most of the conflict would occur while on quests in the form of managing your own units to defeat the enemy units. Managing the guild, however, would still serve some role in this because the player must properly outfit his units before going into battle or else the units might be too weak.

As far as a story for the game, it would probably start with the player inheriting his father's/grandfather's guild and now he has to build it up from its lowly level to be one of the greatest guilds in the kingdom. Throughout the course of the game, the player would meet other characters who join the guild and have their own back stories and personalities. It would be set in a particular kingdom in a world of swords and magic in which there are many guilds that complete tasks for other people. The different guilds would have different rankings that correspond to their strength and general reliability. Another dramatic element that might make the game more interesting would be adding a rival guild that the player could compare his own guild to.

Tuesday, February 11, 2014

A2 Submission

For this assignment, I created a maze using cubes as walls and a terrain piece as the floor. Then I placed 3 spheres with soccer ball textures around the maze and a single sphere with a golden texture near the center as the player's ball. A camera follows the player's ball from behind and the player can move the ball using the arrow keys (up = forward, down = back, left = left, right = right). The player simply navigates through the maze and can try to push the balls through the one opening in the wall. The game uses simple physics, so the soccer balls can be pushed around by bumping into them with the player controlled ball.

Tuesday, February 4, 2014

J3

Since the game Osu! is quite simple, there is really only one system that the player interacts with, namely the notes that appear on screen. There are 4 types of notes that the player has to respond to while playing the game. The first type is a standard note that the player just has to hit. The second type is a hold note that player has to click and drag while following the note. The third one is like the second, but it will bounce back along the path. The fourth type of note is a spinner that the user must click and make a certain number of circles on the screen before the spinner disappears.

The game itself then emerges from this system rather unexpectedly. Despite each note being simple and not to hard to hit correctly, when notes are put in sequences to the beat of a song, the game comes to life and the challenge emerges. Even though all the elements of the game are very simple, the different beatmaps that users have made make the game complex and challenging.

While I don't think that the game elements would have been tuned too much, I'm sure that users who create beatmaps tune them extensively to modify the difficulty and ensure that beats match the music. To make the beatmaps, users would have to experiment with the different types of notes, when each note appears, and where each note appears on the screen. Placing notes too close together temporally or too far apart on the screen can make the song too difficult, but the opposite could make it too easy and boring.

To add a formal element, you could add an "endless" game mode in which the player would complete multiple songs in a row (as opposed to going back to the select screen between each song). This would increase difficulty and the excitement of playing for multiple songs because players would not have a rest between songs to recover themselves.

Adding a dramatic element would be difficult I think, but you could expand an element that is already included in a number of the beatmaps. Some of the beatmaps have a video that plays in the background and is somehow related to the song, but many of these are not very involved and some of the songs simply have a still photo, so I think there is lots of room for improvement here. This could make the game busier (and a little harder to follow the notes), but it would make it much more exciting for people spectating the game.