Posts tagged Hand Dumping
Trap Cards
 
Trap Cards.jpg
 

Hello Everyone!

Time for yet another discussion about design choices for Sigils of Kairos.  Today’s post I will be talking about trap cards.  I’ll start by discussing the reasons for including them, how they’ve changed from that original idea, and then touch on the different traps available.  Let’s go!

First off, one would assume that trap cards came about from playing Yugioh or Hearthstone.  This is probably subconsciously true, but it is important to note that I played neither of these when they were included into Sigils.  Traps were actually a natural and obvious solution for one of my initial worries, Hand Dumping.  Even before my initial mock-up for the game, I knew that there had to be something in place to make players think twice about throwing down a card.  In fact, I liked this idea so much, that I left three spaces for traps for each player!  Thankfully, when Jacob agreed to take on the project, he quickly noted that this is overkill and would serve only to frustrate.

Touching on a design philosophy so wonderfully explained in an Extra Credits video, traps were a perfect way to add a lot of depth with very little complexity.  By this I mean that the traps added a lot of strategy and thinking through plays without having players learn any difficult-to-grasp rules.  Any player can understand how a move could get blocked by a trap, but good players know to bait out a trap by throwing out a weak attack before unloading their special moves.  As our game evolved to include the forge mechanic, this became even more important.  Forging powerful cards meant that a player was putting more eggs in one basket.  If that move gets blocked by a trap, that player didn’t just lose one card, but 2 or 3.  That being said, let’s take a look at the traps that we’ve included in Sigils.

Otto’s Ward

This is probably the most important of the traps as it cuts right to the main purpose of traps.  When triggered, the tank shield doesn’t just prevent one attack, but three!  Throw in the ability to upgrade this to a 5 shield trap, and it’s easy to see why this card defines Otto’s role as a tank.

Skrill’s Ward

The most standard of the different trap cards, Skrill’s bone ward blocks a single attack and throws a bit of damage their way via poison damage over time.  This move (as well as Bone Cage) helps classify Skrill into the support role and pushes back against the idea that support roles are simply just healers.

Stalagg’s Ward

Another seemingly standard trap card, Stalagg’s frost ward (Pictured above) blocks a single attack while slowing the attacker’s draw speed.  Though this may not seem very useful this move serves to slow down the entire game, which was a major goal when designing Stalagg. This allows the player to breathe and plan out their moves against an aggressive enemy team.

Amyth’s Ward

One would have thought this would be the most boring of the traps, but Amyth’s flame ward comes with its own unique mechanic.  Unlike the other traps, the flame ward actually runs on a timer.  This means that over-zealous players can hit this trap twice.  We don’t extend this prolonged trap time for very long because Amyth doesn’t fall into the tank or support roles, but it opens doors for future trap designs.

Lynx’s Ward

Last but not least is the trap for Lynx.  I had planned for this to be another run-of-the-mill trap, but Jacob took this in a completely different direction.  When he had first brought up the idea, I wasn’t sure how it would play out.  After seeing the animation, however, I was instantly convinced it should be in the game.  Mechanically, Lynx’s portal ward ended being a very powerful tool.  Perfectly suited as a strong support move, the stakes for falling into this trap are very high.  By losing a key character like a tank or healer for a short time, the player is now left very vulnerable.

That about does it for this post. Though I don’t post on a weekly basis, I do hope that you find these insights worth reading when I can get them loaded and ready to go. Though I would love to engage more with you all, please remember that for now we are a small two man team working between our regular jobs. Our saving grace is that our build is very far along and playable, despite needing a bit of fleshing out and balancing. We would like to express our ceaseless gratitude for showing interest in our small project in our grassroots days and we look forward to bringing you all the very best gaming experience we can. Until next time.

~ Cedrick

Chopping Block - Double Click Playing
 
Chopping Block Bread
 

Hello Everyone,

It is time once again for the Chopping Block. This is a series of blog posts dedicated to discussing a game function or feature that ended up being scrapped. This week, we’ll be talking about the ability to play cards by simply double clicking them. Though this may feel like a small change, it actually changed a lot within the gameplay experience.

Idea

After a decent prototype was built, we began exploring some different quality of life changes. It was here that the idea of playing a card by simply double clicking it came up. This would prevent the need for a player to drag and drop a card every time a move is being performed.  Though we had mixed opinions on the function, we decided it was worth trying out and coded it into our build.

Implementation

When looking at the list of moves, most cards in a player’s hand would only have one viable place it could go.  Attacks and traps represent the majority of the moves and they can only be played in one way. This lends itself perfectly for the double click function.  For moves with multiple targets, however, the system could consistently select the default target of each card. For example, Skrill’s Bone Cage move can choose one of the opponents in the back row and lock them in place.  By default, double clicking the Bone Cage card could always lock the opponent in the bottom space.

Consquences

When brought up, the idea simply started as an efficiency consideration.  It seemed useful and time saving to double click a card. Though it may seem silly to save the time it takes to click and drag a card, playing the game shows that there could be clear benefits. By allowing players to react quickly, they could effectively counter moves and attack chains. For example, if Player A is watching their opponent’s hand emptying out, she/he will have a chance to counter it. Because each card has its own animation, all of Player B’s cards go into a queue. In between each animation, Player A has a window to play their own card. If that card happens to switch out the attacker, all of the queued cards get wiped out.

This would actually be quite helpful in raising the skill floor for our game, allowing for players to break up big attacks more easily. Despite this, adding the function came with its own set of problems.

Removal

As of now, we have chosen not to implement this function for a few reasons.  First off, we were worried about players accidentally playing cards they didn’t intend on playing.  This consideration is extra problematic if our game end up being ported onto a touchscreen platform and I imagine this is a reason why other digital card games use the drag and drop method.  Our game also boasts the Forge mechanic, where players put different cards together which adds to the problem as cards may get played instead of forged or vice versa.

From a pacing perspective, we also felt that dragging individual cards slowed down the game and felt better to play.  Being a real-time game, this pacing is very important to how the game feels. If cards start flying out of a player’s hand, they will in turn be stuck waiting for more cards to be drawn. To combat this feeling of waiting around, the game would then have to draw cards faster. The end result would be a much more frantic feeling game, which would cut down on the strategic nature of Sigils. Not only this, but the ‘feel’ of dropping a trap or laying a powerful move onto the enemy characters add to the overall experience.

Unlike some of the other topics we have and will approach on the ‘Chopping Block’, I feel that this decision has a potential to change as we move forward.  Both implementing or omitting the double click feature will come with its own set of positives and negatives, so testing for the final product will show which works better.

That is it for this post on the Chopping Block. As you can see, I haven’t been posting the audio version of the blog as it turned out to be pretty time consuming. If there is a greater demand for it in the future, it’s something I may take a look at again, but until that happens I’ll be retiring my microphone for a bit. Please check in regularly and follow us on our various social medias!

~ Cedrick

Initial Worries #1
 
6998-1CROP-WEB.jpg
 

A few weeks ago, I spoke about the origin of Sigils of Kairos. I knew that I was onto something unique with the game from the beginning, but the following days were filled with thinking through how the game would feel. Originally, I had seen Sigils as a mix of a Fighter game and a Collectible Card Game (CCG) and this is how I framed my ideas for development.  When I put some thought into the actual game loop, however, I realized there were going to be some glaring design challenges not native to either of those genres.  By adding a real-time element to cards, Sigils had to introduce a new way of pacing that was foreign to the turn-based CCG landscape. Also, by limiting actions to randomized card draws, Sigils removed a great deal of the freedom that makes fighting games so intense.  Below I'll discuss these design problems that I saw going into the game development process.

Hand Dumping

This is the first and most obvious issue that a real-time card game like ours would have.  In a standard CCG like Magic: The Gathering, the player has a resource pool (mana) that builds gradually turn by turn.  These resources are limited, so players have to choose what to play carefully. Every turn gives access to more mana, allowing the player to use more expensive and powerful cards later in the game.  This keeps the game in check by limiting the amount and type of cards a player can use early on, while slowly ramping up the power.

With our game, there are no turns and so I didn’t feel a resource system would work. If resources entered into a real-time game, both players would be sitting around waiting for resources before they could play a card.  I felt like this would break the flow of a game as players would end up waiting around for resources for most of a match. This style of real-time card game did end up being made years after Sigils of Kairos was conceived, and can be found in games like ‘South Park Phone Destroyer’. Though these games are fun in their own right, they still don’t have the same action-pacing that I wanted for ‘Sigils of Kairos’ due to the mana system they use.

By turning away from the mana-system, the issue of hand dumping became a worry. With no turns or resources to wait for, there is nothing stopping a player from just unloading all cards in hand from the beginning of the match to the end.  This would make for horrible matches as it would remove all strategy and the game would be a glorified dice roll.

Hand Size Limits

This is a design challenge that I was really worried about, that seemed like less of a problem as the game evolved.  Using a sheet of paper as a rough for dimensions of the screen, I wanted to give enough space for readable card descriptions without eating up a lot of the room.  This gave about 6 or 7 cards maximum, which would normally be a decent sized hand for most CCG's. Unfortunately with our game, a team would be comprised of three characters with their own distinct cards.  Instead of having all of the cards available for use at all times, a players hand would get clogged up with all the different character cards. This was on purpose, as it encouraged players to switch up their characters, but with no actual demo to play, I wasn’t sure if the 7 cards would be enough buffer for players to build a strategic hand.

And that’s where I think I’ll leave it for today. Next week will be the second part of this post where I’ll chat about more of the initial design problems that I was anticipating with the game.

~ Cedrick