Lucky Cat Bazaar

Direct link to the files: https://notredame.box.com/shared/static/5yc13einw8sresuevv0t.zip

For Lucky Cat Bazaar, I worked much more on the battle engine and the battle scene. After coming up with the general idea for how the battles were going to go down, I set out and slowly built up the battle engine and scene, starting with the basic functionality and then adding all the bells and whistles later once we had a playable core.

I also contributed some ideas to the shop scene (which Dustin worked on) and helped to weed out some of the bugs that popped up while we were developing it.

Progress Report 3

This time, we've been working on the store front scene, and so we've had to learn how to switch between the two different scenes and how to get the two scenes to interact when necessary. I scoured around online and found a good tutorial that taught me a lot about how to make a basic game with different scenes and many other useful features. I also learned (partly because of the in class demo) about how Unity publishes the game and what it does with the game's dimensions when it builds the game.


While working on this, I taught Dustin what I've been learning so he can use it while he works too. In addition, I talked with some friends who are not computer science/computer engineering majors and told them a little bit about my game. For them, I had to think of simpler language that doesn't use computer specific terms in order to explain it to them in a way that they would understand what's going on.

Progress Report 2

I've learned much more about programming a 2D game in unity. Up until now, all we have been working on have been 3D games, but Dustin and I are working on a 2D game and so we had to go search online for some tips for making 2D games. The game also uses buttons/menus for the battle system so I had to learn about how to use those in unity as well.

While working on the battle system, Dustin acted much more as the brains behind everything while I did lots of the programming, so while he was telling me his idea for the game, I thought about it and taught him the way I would implement it. I went over the code that I wrote with him to make sure he understood the generally idea of what it was doing.

P2

The source code can be found here: https://www.dropbox.com/s/o1mm9n0u7dg4p3w/Lucky%20Cat%20Bazaar%204-11.zip

Progress Report

Since I have been busy this week, I haven't had much time to work on the project with Dustin other than working on details and getting our GDD put together.

 This week I have learned about planning out games and making formal definitions for the plans that I make. I have never worked on a larger scale game like this (all my previous 'games' have focused less on gameplay and more on the concepts for the class I made it in, e.g. computer graphics), and so it is a good learning experience to focus on the gameplay and think about how to make the game fun. Likewise, my previous projects in computing have been mostly defined by professors, so I'm learning how to design my own project formally.

As far as teaching others, I have shared the idea for Lucky Cat Bazaar with the class and taught them what Dustin and I have been working on. Similarly with what I have learned my self, I have been teaching Dustin and working with him as I learned these things myself. Although I guess I'm not teaching him from things I've known, I'm learning about all these aspects of making a game with him.

GDD v1.0

This is the link to the first draft of our GDD

https://docs.google.com/a/nd.edu/document/d/19mkiGfIV5JtiSaixYRL7APigp4T8HwW1D7FcqmnffqI/edit?usp=sharing

P0 Team Formation

Team Name: Mid and Feed
Team Members: Dan Gomez & Dustin Liaw

A4

To enhance my A3 submission, I added a few formal elements, dramatic elements, and cool effects to spice up the gameplay. As far as formal elements go, the first thing that I added was really simple: lives. Before I had it set up so that if you fall, you just get placed back on the first floor, but now you will lose lives and eventually get a game over if you lose all your lives. Another element I added was a jump power up that allows you to jump when you get it. I also attached some dramatic elements and effects to this, which I'll talk about later. In A3, you didn't need to be able to jump to win, so I also had to change the level design a little bit to make the power up necessary. Lastly, I added some GUI features to give the player more feedback.

For dramatic elements, the biggest addition I made was with sound effects. I added a sound for collecting the balls and the power up, as well as a sound track that plays when you have the power up. These help to make the game a little more exciting (and possibly silly).

Finally, I added a number of effects that make the game considerably more exciting, I think. Now when you collect a ball, it will give off a sparkle (firework explosion) that just makes it look more exciting to collect the balls. The power up that you pick up to jump is also a simple stream of particles that will disappear when the player picks it up. In addition, once the player picks it up, his avatar gets an aura that shows the player that he has powered up (in addition to being a little silly).

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.

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.

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.

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.

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.

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.

A1 Submission

For this project, I altered the ball so that it can be controlled with the arrow keys and made to move along the x and z axes. If it hits the edge of the plane, then it will bounce off and lose a little of its speed. Also, you can make the ball jump by pressing the space bar, and then it will bounce for a little bit, losing energy with every bounce. The smaller ball orbits the larger one while changing its motion based on how close or far it is from the larger ball.

J2: Formal and Dramatic Elements

From last time, I talked about Flux and Osu!...

In Flux, the formal elements are very interesting, I think, because they are variable as the games progresses. Naturally, certain elements are fixed, such as the players and how you are allowed to play cards. The rules and objectives of the game can change very rapidly, though, and sometimes they can even change every turn.

In Osu!, the formal elements of the game are much more stable. For the players in the game, there is a single player and a multiplayer mode, but the actual gameplay does not change much at all from one mode to the other. The objectives of the game are to hit the circles on screen with the right timing and to get the highest score. The conflict comes from failing to hit the circles at the right time (or even at all), which penalizes the player by reducing his health, but hitting circles properly will restore a small amount of health.

An interesting thing about both of these games is that neither of them have certain dramatic elements that many people have come to look for in a game; a story, characters, or a real premise. The thrill of both of these games comes from their challenge, rather than any thematic elements of the games. In Flux, the challenge comes from having to outwit the other players and better adapt to the changing rules in order to achieve victory. In Osu!, the challenge comes from hand-eye coordination, and the challenge can be changed so that it is suitable for both beginners and experts.

After doing the reading and applying it to these games, I can better see some of the design choices that were made, and I better appreciate the difficulty in making them.

J1: Hello World!

So... two games I've played....
First is Flux, a card game in which the cards decide the rules of the game. The game starts with only two rules: 1) you draw one card every turn and 2) you can play one card every turn. There are 4 (kinda 5) different kinds of cards in the deck: keepers, goals, rules, action, and creepers. Keepers are cards that you play and just hold in front of yourself. Goals allow you to win the game if you fulfill the conditions on them (usually have keepers x and y). Rules add more rules or change rules in the game. Action cards cause various actions such as destroy a creeper of steal a keeper. Creepers must be played as soon as you get one, and they prevent players from winning the game. Players take turns and simply follow the rules that other people have played until someone fulfills the current goal.

The second game is Osu!, a rhythm game in which the player has to click on circles on screen in rhythm with the song. Players can download "beatmaps", which are songs with the accompanying circles, that other users have created and placed on the internet. Gameplay is pretty straightforward, but varying difficulty levels on the beatmaps keep the game interesting and let you play for a long time without getting tired. Also, the user generated content in the form of downloadable beatmaps means that there are songs that almost anybody would enjoy.

From the introduction, I thought that the line "young people in the United States spend an average of 20 minutes per day playing video games" was interesting. Honestly I thought that the number would be higher and it surprised me a little.

From chapter 1, I liked the line "No rule is set in stone. No technique is absolute. No scheme is the right one." This line makes me think about the development process of some of my favorite games and how, at one point in time, the games may have been very different. I know for a fact that 007 GoldenEye was almost released without the multiplayer part, even though that ended up revolutionizing shooters.

From chapter 2, the line "When you play a game, you set the rules of life aside and take up the rules of the game instead." really stood out. I think it's really cool how you can create an entirely new universe for people to jump into and share in your own fantasies.