Course Reflection

After a semester in Intro to Game Studies, I feel like my appreciation for all games has increased. Whether I was designing a video game, a board game, or just a simple party game to play with friends, I learned that there is more to it than just developing the rules. Other factors like how the audience feels, what kind of style the game uses, and who the target audience is affects the gameplay.
The most interesting thing I learned was how audience perception of the game affects the play. For example, in one of our in class demos, we played a "game" called Lonliness, where the player was nothing more than a black square, and interacted with other black squares. While the game itself is incredibly simple, as the audience began to realize the meaning of it, the game carried a more serious tone. We first started out laughing as the little black square tried to catch the others, but as it became apparent that the square was always alone, the audience grew sad. The game then felt more real and hold deeper meaning.

Another interesting thing I realized was during the final presentations, how the style affected the gameplay. One example was from Spellstrike, a fast paced 1v1 battle of wits. This was one of the only PvP games that our class presented, and it created excitement among the players and the viewers. The style of competition made a simple game into an exciting display of wits.
I found that throughout the entire semester, I learned that games were about more than just a ruleset. They can carry a story, create feelings, and create an emotional response. As a game designer, I now have a unique insight into how games can be more than just a set of rules, but a medium to transfer information to a player.

Final Project Prototype: Tower Defense

For my final project, I teamed up with my partner from the Go-Go Granny project in order to create a different game: Tower Defense. Tower defense games are simple in theory, but highly complex in the coding behind the scenes. The goal for our tower defense game is to introduce a new mechanic, which is the idea that as enemies cross into your territory, your land starts to become corrupted. As your land becomes corrupted, so do your towers, giving them new (and slightly corrupted) abilities!

An example of the land becoming corrupted can be seen here above. So far, there is only one type of enemy and two types of towers. Different enemies and towers are planned for future stages of the games, including but not limited to, boss monsters, long range towers, and slowing towers. The way the game works right now is the enemies will try to make it to the bottom, and you have to build towers to shoot them and block their paths.

Some challenges this game has posed to me as of now is dynamic enemy pathing and infinite level scaling. Dynamic pathing means as new objects are placed on the grid, the enemies have to find a new shortest path to the goal. This was one of the first problems I tackled in this project, and was able to solve it using Gamemakers mpGrid function.

In the code snippets above, you can see how I first created a grid object divides the grid into cells with sizes of my choosing. I then add objects to the grid that need to be avoided. Then, when I create an enemy object, I give it a path based on the objects in that grid. Now the enemies will find the best path to the end!

Infinite level scaling is another problem I ran into, and I am still dealing with it. The problem with infinite levels is that you have to predict how the user will play and how long they will play. So far, I have narrowed my style down to two possible forms: scaling health or scaling enemy type. These two difficulties are diagrammed below:

As you can see, the blue line has stronger temporary impact, while over time it only gradually grows, but the red line has a more fair and balanced increase. I decided to go with the scaling HP formula, and use the flat lines to indicate when to release boss monsters. This formula will not be final, so testing will provide more direct feedback.

So far this game has been really fun to code, and I am extremely satisfied with how it has progressed in the last 2 weeks!

The Circle: SJSU Productions

Tonight I had the privilege to attend the dress rehearsal of The Circle, the SJSU drama production of the winter season. This production is truly unique and a first of its kind; an interactive drama performance. Each attendee is immersed into the atmosphere of The Circle and lead through various events through the performance. While I am not a studio major, I have a unique perspective of being a game designer in order to observe the play.
The entire performance is, in a sense, a game. The "players", which are the attendees, have various options and choices they can make which lead them through the production and to different narratives. Then there are collective sessions where everyone gathers at the same time to hear the same narrative. This provides people with different paths to take, and a different perspective for each event.
That being said, I felt each attendee had little to no control over the events of The Circle. The performers drove most of the narrative and the meetings felt very scripted. This lead to a perspective of minimal contribution. However, there was plenty of interaction between attendee and performer, being it an interview or a company survey.
This production was designed to be different and it really was. During the show it felt like a game, where I was a secondary character who was stumbling onto a conspiracy and I had to discover the truth without being caught. It caused a very interesting atmosphere which is different then any other drama production I had ever seen.

Go-Go Granny Final Prototype

Go Go Granny, the lovable infinite sidescroller, is reaching its final stages of development. Since the last posted prototype, the game has had to go through some necessary changes.We started off our edits with the aesthetics. First off, we added two scrolling backgrounds to give the game some depth perception. Next, we changed the color and size of cookies to make them more visible to the players. We also changed the design of the platforms, to differ their style from the ground. We also gave the chaser an animation for eating to add to game clarity We also added a high-score so that the player could feel a sense of progression during the game. For the last aesthetic update, we added visuals to the main and end screens so that the entire game felt more complete.

For gameplay updates, we decided to add a reward for climbing platforms. A cookie now spawns above the platforms, only reachable by jumping off of it. However, this created a scenario where you could collect too many cookies too easily. To compensate, we added the Baker's Dozen bonus, where if you collect 13 cookies, they are all consumed to give you a 500 point bonus! This added a really fun element to the game which was not in the original design. Lastly, for gameplay updates, we adjusted the speed of the chaser, so that the game ran smoother and didn't feel too difficult to play.

After these final edits, our game's prototype finally feels complete! If you feel inclined to play, you may do so by downloading a copy here. This version is only playable on a windows machine, or on a MAC by using Wine Bottler. In the future, we hope to export this game to mobile devices (iOS and Android), so you can play Go Go Granny on the go-go!

Go Go Granny! Prototype

Go Go Granny is a side scrolling game where you control a hyperactive grandma escaping from a care home. You must run away from the caretakers, and throw cookies at them to slow them down.

Over the last 2 weeks, I along with a partner, designed and developed Go Go Granny! My role in this assignment was the programmer, and my partner was the artist. From the programming side, there were a couple of big obstacles to overcome. Firstly, this game is supposed to be infinitely generating with randomly appearing obstacles. From a programmers point of view, this is challenging, because writing code that could theoretically go on forever seems daunting. However, once I got used to Gamemaker: Studio (the software used to develop this game), this task was easily accomplished. By using a series of timers, I was able to create infinitely generating random landscape. The second big obstacle was balancing an infinite game. As the game progresses, it needs to become more difficult, or else it will bore the players. This task was handled by using a level up system based off of the distance you traveled. As you go further and further, the game will speed up to compensate for your progress. With the core gameplay handled, the next step was to have other people test our game.

During class, we had half the students rotating around the classroom testing players games. When they tested our game, we made sure to ask them if the physics seemed fair, and if the cookie worked well. We learned two things from these tests: The cookies can be too hard to see, and the enemy is too fast. Some suggestions we had were to implement an eating animation for when the enemy caught the cookie, to slow the enemy more when he had a cookie, and to change the color of the cookie or fence to be more clear.

These fixes will be implemented in a future version of Go Go Granny!

If you wish to play the prototype version, you can download it from this link. (This version is ONLY playable on Windows machines).

Creative and Effective Game Design

As part of a learning process of developing games, it is important to view games from two perspectives: a player and a designer. When playing a game it is easy to become immersed in the gameplay. While this is the intended purpose of most games, this test session I focused on trying to determine the "behind the scenes" strategies and techniques of design, along with new interesting mechanics and features.

Example Game 1: This Is The Only Level

Figure 1: The first (and only) level

A platforming game such as This Is The Only Level usually comes with many rooms. Dungeon crawlers have checkpoints, boss battles, or simply different layouts. However, TITOL has only one level, and it is shown above. It may seem that a simple game like this is dull and has a really short playtime, but I assure you this is not the case. By using a simple design, the developers were able to skip the long and tedious process of animation and visual splendor, and focus on the gameplay. The trick is that each proceeding level has a small trick to it, such as reversing the controls, or turning off gravity. By minimizing the visuals, the designers created an interesting game with potentially infinite expansion.

Example Game 2: WizardWizard

Figure 2: Obstacles and an enemy!

WizardWizard is a more traditional platformer, where the player needs to collect a key and go through the door. When it comes to WizardWizard, we were very lucky to be presented with the source code, so we could see exactly every aspect the developers used to make this game. This is invaluable to a developer, because it can teach you techniques it may have taken years to develop alone. It also goes to show exactly how much work needs to be put into a game before it can be considered done. This will be extremely helpful as a resource to design games with different rooms, with physics, and with enemies.

Example Game 3: Prismic Shift

Figure 3: Prismic Shift

Prismic shift is a game designed by a student at SJSU for play in an arcade cabinet. The main mechanic I observed with this game was the control scheme. The joystick feel makes this game amazing. The feeling of maneuvering a ship through tight formations of enemies with a joystick can never be compared to that with a keyboard or controller. Another fantastic aspect of this game was how the designer dealt with an ammo system. In some games, ammo isn't even needed, and in others, it is required but very poorly included. This game however takes a simple approach: if you run out, you need to blow yourself up. This mechanic makes the players have to be more conscious about their resources, and strategically detonate in order to score the most points. Its also an extremely interesting aspect for co-op modes, where teammates can blow each other up if they are not careful!

Session Report: The Evolution of Warcage

Introduction:
Warcage is a grid-based war game where a player moves units around the grid in order to try to eliminate the enemies forces. The game is over when either player eliminates the enemy hero. The combat of the game is determined by a combination of dice rolling and card playing, giving the game a unique chance based element with the opportunity for strategic twists. Each player has 4 units (a hero, a warrior, a tank, and a horseman), and a deck of cards. The cards are labeled with single attributes: attack, defense, parry, or boost. Each unit also gains a small boost based off its type. Warriors get +1 Attack, Tanks get +1 Defense, Heroes get +1 Attack and Defense, and Horsemen cannot be Parried.

Fig 1: The drafted rules.

Session 1: Initial game testing
For the first session the rules started off very simple: eliminate the enemy hero. Both players placed 4 units onto the field in the back two rows at each end of the board. We rolled a dice to determine who went first. The first two turns of the game seemed very slow because the units started too far away from each other to initiate combat immediately. After consideration, we decided to keep the game this way in order to allow for strategic maneuverability for the first two turns. The next phase of the game introduced the combat, which was fun but very unbalanced. The initial style of combat we had was based off of 4 card types: attack, defense, agility, and bluff. The attack and defense made a lot of sense together: the damage dealt to a unit was the different between the attack and defense values. With the dice roll determining the total damage, we calculated that the maximum damage dealt from a single dice would be 5 (max roll of 6 minus the minimum roll of 1). Because of this we made each units base health 5 hit points, so there would be a small probability of killing the enemy in one blow. Although the maximum damage by one dice would 5, we determined combat would be decided by 2 dice per player, allowing for more combinations of cards to be played. Also, each unit would apply a bonus to the rolls: warriors would get +1 attack, tanks would get +1 defense, horsemen would get +1 agility, and heroes would get +1 of each.

Fig 2: Day 1 Gameboard

Fig 3: Day 1 Combat

However, we ran into our first problem here. The "Agility" mechanic was a multiplier to either attack or defense, allowing some rolls to be significantly higher than others. The "bluff" mechanic also proved to be frustrating in this sense, because with poor luck, the battle could swing in favor of the enemy way too quickly. The reliance on luck was further increased by the small hand size of 3, limiting the options of each player. Lastly, each players deck had 10 of each of this cards, making poor luck cause you to draw multiple bluffs and very few defense and attack. Warcage was extremely fun still, but after this session I decided to revamp some of the combat to try and make it a little more balanced.

Session 2: Revised Testing
During session two, I tested with a friend who does not play video or board games in order to see how interesting the game could be to pick up and play. After session 1, I revised the rules a little. "Agility" no longer was a multiplier, but instead treated as a tiebreaker. Also, I changed the amount of cards in the deck, to 13 "attack" cards, 13 "defense" cards, 7 "Agility" cards and 7 "Bluff" cards. I hoped this would provide less bad hands and more hands with playable strategies. When the game started, the first two turns played out similarly, slowly but with strategic unit advancement across the board. When the combat initiated, the game was very different. It was no longer a one-attack blowout and instead required strategic placement of units with flanking and pincer placement (trapping single enemy units). This game was much more enjoyable, and usually ended with one player trapping the other in the corner.

Fig 4: Day 2 strategic unit placement

After this play session, it was determined that "Agility" still didn't work as it should, and that "bluff" cards forced too much luck on the combat. However, the new deck breakdown made the draws more consistent and more enjoyable. There were much fewer times when we felt our hands were worthless, and more times where playing cards took more thought than just luck. After this session I decided to completely scrap "bluff" and "agility" in favor of two new abilities, which I would then test with a third partner

Session 3: Final Testing
On Monday, I paired up with my third partner in order to test the updated rules of my game. This time "bluff" and "agility" were replaced with 2 new types: "parry" and "boost". The parry mechanic would counteract any opponents dice roll of equal value, giving the defender a needed boost when behind, but not putting the attacker at a huge advantage for lucky rolls. The "boost" mechanic merged the units with the combat better. It provided a flat bonus to each units type bonus already existing. This change also meant that the horseman's' bonus would have to change. In order to keep the stats linear, the horseman's new ability became "cannot be parried". This unique ability allows for parry and boost cards to still be played as bluffs during the horseman's turn, but not be wasted other turns.

Fig 5: Day 3 unit placement.

After testing one game with my partner, we decided that the "parry" and the "boost" mechanics were extremely fun and made our game hectic and got us both to the edge of our seats. However, after a short discussion we decided to try a game with a hand size of 5, to allow for more combinations. This change was by far the most significant, because it allowed for us to have way more options on both offense and defense, and caused for some of the most intense dice rolling yet. With these final rules, Warcage became the game it set out to be: an epic war game with tense combat, big damage swings, epic counter attacks, and a fun experience.