The Hand System

So this post is going to cover a bit of how the card system actually works in GutsyGrid and how you can launch your very own sweet attacks.

As soon as the player enters a battle he gets dealt a five card hand from his deck

Each card will be displayed via it's icon as seen above (again, this is filler art and even the UI is just really a placeholder for now). Each card is bound to a key (A S D F G by default).By pressing the keybinding of a card, the player will launch the attack the card actually contains. Upon using a card, it will be discarded from his hand and the player will have to wait a very small cooldown period until they can use their next card (based on the individual card).

Once a player has used three cards, the remaining two cards in the hand are discarded and the player is dealt a completely new hand. This was decided for a multitude of reasons. 

The first being that players must actively choose the best cards for the situation. Unlike Mega Man Battle Network players will NOT have pauses mid-battle to choose their cards. This means that the player will actively have to decide the best cards for the occasion, while dodging enemy attacks. There will be certain situations where a player has five cards that he or she wants to use, but they will be forced into choosing the best possible three. This is especially important because a key goal for the player in GutsyGrid is to finish battles as quickly as possible

The second is that some cards in GutsyGrid are fairly situational. Some cards will trade off versatility for pure power. A melee card that hits the tile in front of you will deal way more damage typically than a full row projectile. If the player had to use all the cards in their hand to get a new one, they'd find themselves in situations where using certain cards. Using a card for no reason other than to get a new hand feels shitty and doesn't provide much of a game play experience. By ensuring that the player can pass on using two cards in their hand, we minimize how much

The last reason for this is that it allows a player to likely see more cards in their deck in an average battle. Because a player will use three cards out of five and than cycle to the next hand there will be an increased probability of them seeing different cards in their deck.

These reasons and some play testing is what led to this design decision. This system was originally designed in the prototype for GutsyGrid (BATTLE ARENA!), a game I created for a class. The three card limit actually came from my good buddy Zach Fand and I actually shot it down. After much debate and a little testing I realized he was right and my arguments against it were weak and not especially relevant.

So yeah,

Paul

So what is GutsyGrid?

GutsyGrid is a game I started really developing about 6 months ago.  There's a lot of history on GutsyGrid, but I'll save that for another post farther down the road.

So what is GutsyGrid? It's an action/trading card game hybrid, highly inspired by the Mega Man Battle Network Series.

This is a current in game screen shot of GutsyGrid (Note that all pieces of art/UI are placeholders!)

The goal of the game is to eliminate all enemies. The battlefield is typically split in two halves, the player can move onto blue panels while enemies typically can move on red panels. Battles are entirely real time, the only pauses being for the actual pause button and rarely on attacks.

In order to defeat enemies the player must use cards! Before a battle the player sets a deck of thirty cards. These cards invoke wildly different attacks when used. For example one card might be a shot that paralyzes enemies, while another might warp enemies off the battle field for a set amount of time, while another might be a highly damaging melee attack.

As seen in the above screen shot, the player gets a "hand" of five cards at a time. Upon using a card, it is discarded from the hand and the player cannot use it again. Upon using three cards the entire hand is discarded, allowing the player to draw a new hand of five cards from his deck. Once the entire deck is drawn, the discards are shuffled and the player once again draws a new hand. I'll actually be writing more about the hand system tomorrow, and why these systems are set in place.

That's really the basics of GutsyGrid, but before I end this post I want to talk about the first playable demo.

The first real demo will be done April 19th, and I'm unsure if I'm willing to let it be freely downloadable.

Regardless the demo will include:
15 Cards
6 Enemies
1 Boss
The World Map Mode
Deck customization

So far I have
13 Cards
6 Enemies
And the world map partially done, so I'm right on track. I'm also hoping to get a lot more polish on the game (number balancing, better art).

So yeah, thats GutsyGrid.

Paul

GutsyGus Post Mortem

GutsyGus is the result of the second game jam I participated in. I created GG at Northeastern University Game Development Club's 32 hour game jam back in November (which I also ran!). The jam required participants to pick two themes out of a possible five and use both in their games. I decided on merging the themes "heist" and "masks".

Seeing as how the game jam was only 32 hours long I really had to get to working. I was lucky enough to have an artist this time around so I wouldn't have to make my own art. I found myself quickly inspired and came up with the base design for GutsyGus, which I ended up deviating away from, but more about that later.

GutsyGus was designed to play as an isometric stealth based 2D game. The player takes on the role of Gus, a cat burglar who's attempting some pretty dangerous heists. He is also gifted with the mysterious mask of the cheetah, which allows Gus to gain a short burst of speed. The player must gather all gems in a level and then make it to the sand trail to move on. It was a really, really quick project and I had a lot of fun making it. Along the way I learned numerous lessons, some from things I did well, others from my mistakes. This Post Mortem will focus on level design, as that is a trait I focused on while making GutsyGrid.

The Good

The thing that stands out the most as a success in GutsyGus is the level design. I'm happy with the way I approached the level design in general. There's five levels in total; one goal I had coming into this game jam was to design the levels to teach the player how to actually play the game.

The first level introduces the player to basic movement, the fact that Gus cannot cross water, and that the player must touch the trail to advance.

The second level reinforces the fact that Gus cannot cross water and also teaches the player that they must collect all gems in order to actually clear the level.

The third level introduces the dastardly corgi police (who are actually probably very nice dogs just trying to feed their families etc.), but it's key to point out that the corgis cannot actually catch the player. This level teaches the player so much about the corgis in this small amount of time. First the player will realize that the corgis will pursue the player. Then they will realize that they cannot cross water. Lastly the player will most likely notice that the corgis will retreat to their original position after a distance between them and the player has reached a certain point. This third point didn't work out perfectly, but I'll cover that a little later on.

The fourth level was intended to teach the player two major things. The first was to teach the player that getting caught by corgi's makes the player lose, forcing them to restart the map. This was a huge success. Every player I tested with attempted to just walk past the corgis, getting caught every time The second lesson was to teach the player that the cheetah mask could be used to outrun the corgis. This was almost a victory, but I ended up not really implementing it all that well.

The fifth in final level turned out really well, the player had to combine all the things they learned up to this point to defeat it. They needed to collect the gems, use the cheetah mask and water sections to avoid the corgis, and they had to get a certain distance between them and the corgis in order to reset them. I'm actually really proud of how I implemented this. If the jam had been longer, I would've loved to design more levels.

The Bad

There were a couple of small flops on this project. I could have done a way better job designing two levels. The first of these was level three. It's a really, really minor thing, but players don't always see that corgis reset after you clear a certain distance. I should have made the islands trapping the corgis smaller, so that players ALWAYS see them reset. This would've ensure that the players see this happen. The second level that could have used a vast improvement was level 4. The level had a lot of potential to be well done, but I didn't quite implement it well. The level featured a small area the player had to cross through, with two corgis.  The goal was to force the players to try to outrun them by using the cheetah mask. Unfortunately during development I realized I wouldn't have time to create an instructions screen, so I had to try to convey the control in another way. I thought back to games I've played in the past and instantly though of the Donkey Kong Country games. One awesome thing those games would do, was use bananas to teach the player. They'd use them to reveal secrets or even controls.

 So I decided I'd try to spell out two F's in gems for the player. Not a single player that played my game made the connection. So why were Donkey Kong's Banana's obvious and my gems not? Some probable causes are:

1. The gems are very dark in color and don't particularly stand out
2. The concentration of bananas is much higher, making the definition of the letter much more obvious
3. A keyboard has significantly more buttons to press than a controller. A player seeing an A on a SNES 
4. Up until this point, there was no indication that the player had any additional abilities besides moving.

So yeah, those are my guesses why my plan didn't succeed.  Regardless, I learned a lot while creating this game and I've got a lot of pride in what I managed to create in such a small time frame.

A small side note on GutsyGus, is that I originally wanted to include two other masks that would grant Gus new abilities. The falcon mask would let Gus jump great distances (and over corgi's and water!). The second was the fox mask, which would reduce the range Corgis could detect Gus at. Unfortunately due to the duration of the jam I had to scrap these early in development. I was also planning a resource mechanic along with these so players would have to think about which masks they wanted to use, and use them sparingly.

-Paul

GBVU Post Mortem

GutsyBot VS The Universe was a game I created nearly single handedly for a Game Jam competition last June (Ludum Jam). It was my first game jam project and I did everything in the game except for the logo and sound. Needless to say, it was a pretty exciting weekend (the game am was 72 hours, but I was working full time!).

Along the way I faced numerous challenges in game design, programming, and making the art. This Post Mortem will focus on the design aspect. While designing GutsyBot I had a couple of successes, but also had a huge batch of missed opportunities for exciting gameplay.

The theme of the game jam was Tiny World. I had the idea of a giant fighting robot defending a planet from aliens. I designed the game play with the idea that the character would have fight enemies that continually spawn (speeding up in rate as the time goes on).

The Good

During the initial stages I decided to have dead enemies fly off the screen rather than a death animation, mostly because I felt it'd be a really small rewarding feature. During development this created a bug where dead enemies would kill enemies they collided with on their way out. I quickly realized what was causing it, but also realized that this created exciting and awesome game play. This created an entirely new set of strategies. Players could look for clumps of enemies and try to knock an enemy into them to kill the entire pack. Additionally weak enemies became an awesome mechanic, as they provide the player with an incredibly powerful weapon. Weaker enemies that die in one hit can easily clear a huge amount of enemies, providing a very rewarding and cool game play experience.  This mechanic is ultimately the part of the game I'm most proud of. Although it's a highly simplistic and straight forward design element, it seriously made the game exponentially more fun.

The Bad

There were also some design decisions I definitely regret.

The first is pretty minor, but the control scheme could have been so much more. The current controls in game are really simple: move and shoot. This means that the player shoots in the direction he is facing/currently moving. This really limits how the player can move and gun enemies down, it also makes aiming overly difficult. A superior analog control scheme would have made the playing experience superior. Simply doing analog controls (as in four buttons to shoot and four buttons to move, one for each main direction) would have given the player a much better experience. This is a lesson I won't forget, controls can seriously add a lot to game play experience while not being especially difficult to implement. I'll take more time in my future projects to work on controls.

The second design issue I should have addressed was the collision issue. The collision's look off for player bullets and enemies, but this isn't actually a programming bug. This was my first project where I really spirited almost all of the art assets (with the exception of the logo) so I'm not too surprised I had a slip up here. I realized a day or two after finishing the game that I made the outline for the player, enemies, and projectiles the same as the background color. Although this is another, rather small detail, it made the game noticeably less fun for players who were aware of it. A lot of players commented on it and it was very obvious that it really negatively affected the feel of the game.

The third and final issue I had with GBVU was the lack of any direct interaction between the player character and enemies. The PC could destroy enemies with shots, but if he collided with an enemy nothing would happen. This really felt like a lost opportunity. There were a ton of directions I could have taken this in. For example I could have added another complication to game play by having enemies damage the character on contact. This would create additional gameplay that forced the player to not only worry about defending the planet, the aliens would also be a direct threat to the player as well. This additional threat would have definitely made the game play more immersing. Another spin on this would be to reward the player for making contact with enemies. Gutsy could launch a strong melee attack. If this change were to be added, the spawns would definitely have to increase in order to compensate for the new power the player has gained, but it would create moments were the player truly felt powerful. Clearing out huge waves of enemies, knocking them into other enemies, would be an awesome engaging experience for the players. There's probably more possibilities that I haven't considered, but the point is this is something I should have put more thought into. I missed an opportunity to add a really awesome layer of complexity to the game.

GBVU is definitely rough around the edges, but ultimately it's a project I'm incredibly proud of. I definitely became a stronger programmer and designer after this game. The lessons I've learned will stick with me for a long time.

- Paul