Posts in Development
Ultra Bar
 
Blog+-+Ultimate.jpg
 

Hello Everyone,

Today’s post will delve into Ultimate moves, a mechanic we have shown a lot in person but rarely online. Ultimate moves were always slotted to be a part of our game.  Mechanically, they give nice spikes in power that lead to some powerful turnarounds. This shakes up matches and makes them more dynamic and interesting.  Stepping back from sheer mechanics, I personally feel that the real power of an ultimate lies in the feel and spectacle of the moves.  Ultimate moves are fun, plain and simple. This is why implementing them into our game had to be done with a subtle touch to ensure they kept the power balanced mechanically while still feeling epic.

Haste, as we originally conceived it, had a set number of cards for each player much like a physical deck of playing cards.  These decks would be comprised of basic attacks shuffled in with cards from each of the 3 characters. Since the ultimate cards were powerful, we decided that only 1 ultimate card from each character would be shuffled in. This resulted in the problem where players could potentially draw an ultimate card in their opening hand.  An opening hand with an ultimate card would of course give an early spike in power that would be a huge advantage much too early in the game. To resolve this, we tried several solutions including built-in downsides for cards that discouraged playing them early.  This will be further discussed in the ‘Chopping Block – Ultimate Costs’ post coming up. Until then, the best example of a downside designed for late game would be Skrill’s Devour ultimate which sacrifices Skrill to resurrect another player. This card couldn’t be played until one of the characters died, and even then the card retains less value while Skrill has high health.  Other solutions included a hidden card counter that would stop the player from drawing the ultimate cards for X number of turns. Unfortunately, this still gave a huge variance on when a player can access the ultimate card before their opponent.

After brainstorming, we landed on an Ultra bar.  Despite the game’s RPG aesthetics, Haste is very much influenced by fighting games.  Early on I mentioned how Haste is closely related to fighting games like Street Fighter due to the constant action from the real time aspect.  Naturally, we looked at games like these for inspiration, which lead to our *ultimate* decision.  sorry...

Haste - SS 2019-10-05.gif

The Ultra bar works out great for a few different reasons.  First off, it solves our issue with ultimate cards being drawn too early.  Stopping players from randomly drawing ultimate cards also meant we could remove all detrimental costs attached to them, though we chose not to for several of the moves. One unexpected advantage of using the ultra bar, was that we could now play around with how fast a hero could build their ultra bar. This not only gave us a new balancing tool, but also allowed us to make different ultimate moves of different power levels. The longer it took to get your ultimate card, the better the payoff could be.

More broadly, the ultimate bar adds a sense of build-up and tension.  The bars on either your own characters or your opponents’ let you plan for upcoming ultimates to be used or defended against.  Also, with the bar comes a new risk/reward consideration when choosing who to put into the line of fire. If players are on their last legs and need that ultimate for offense or defense, chances are they’ll play a lot more desperately to get that ultimate out.

The last point I will make is that ultimate moves feel great to play after they’ve been ‘earned’.  By working towards the ultimate, the player now has a sense of investment even though they just played the game as they normally would.  This ‘investment’ increases the perceived impact of a move which actually allows us to lower their power level. Granted, some of the moves are still quite strong, but this isn’t true for all of the characters.  The ultimate bar in conjunction with Jacob’s epic animation effects give players the feeling of importance and power without breaking the overall game balance.

UI Update: Select, Equip, Defeat!

Hello Everyone,

This blog has been around for quite a while and I am very happy to share our design discussions with you all. I’ve mentioned it before, but it’s worth re-iterating that we are a small two person operation and as a result we have been working on this project for quite a while. This explains why pretty much all of the blog posts on Hot Sauce Bread have been retrospective takes on our design process.

In a way, I really like this format as it gives us the advantage of hindsight to unveil some hidden consequences of our design choices. Unfortunately, this also means that our game often looks like it’s at a standstill when it very much isn’t. Today we take a peek at what is happening with Sigils up to this point.

Victory and Defeat

 
Sigils-KO.Gif
 

If you’re an avid follower, you might have noticed a twitter post with the new victory screen. Though there are going to be some tweaks to the design of the font, we are both really happy with how this looks and feels. I personally really like the arcade aesthetic, and I feel like our game really benefits from it. Unlike other card-based games, Sigils (Haste) plays much more like an arcade game which I don’t think comes across well when looking at our screenshots.

Character Select

 
Character Select Hotsaucebread.png
 

This is our crack at the character select screen. We needed a way to showcase the characters while still lumping them into their respective roles. I think Jacob made the right choice on this one because it looks pretty straight forward and clear.

Inventory

 
Equip Screen
 

This is a mysterious shot posted on our social media accounts a few weeks back. What does this mean for our game? Well, I think it’s clear that we’ll be adding cosmetic items, but I will likely go over this more in the future. The only thing I can say now is please don’t jump to any conclusions, especially in regards to how we plan on monetizing. In all honesty, we aren’t completely sure of which route to take, but we have a few different ideas kicking around.

We have some more things we’re working on, but this is a general look at some of the updates that we’ve made. Unlike a lot of our other devblog posts, this one seems more similar to what a ‘normal’ dev blog looks like. I hope you all enjoyed a peek behind the curtain, and please help us out by giving us a bit of feedback! You can reach us via the Contact page or making a comment directly on this post. If you want us to get back to you, you are welcome to leave your email address or sign up for any new updates. As usual, if you want to see some of these screens before they hit the blog, you can also follow us on our social medias like twitter or Instagram. This summer is wrapping up at an alarming pace, so we here at Hot Sauce Bread Studios hope you make the best of it.

~ Cedrick

Trap Cards
 
Trap Cards.jpg
 

Hello Everyone!

Time for yet another discussion about design choices for Sigils of Kairos (Haste) .  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 (Haste) .  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 (Haste) .

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

Forging #2
 
Forging #1.jpg
 

Hello Everyone,

A couple weeks ago, I went about describing our ‘forge’ mechanic. If you missed that one, click here and give it a skim as it sets up for this week’s discussion.

One of our basic tenets when building Sigils of Kairos was to keep it as accessible as we could while still providing a rich playing experience.  Introducing a mechanic like ‘forging’ comes with more decisions which in turn adds complexity. Though complexity is not inherently bad, we had to make sure that adding these mechanics it would add enough depth to the gameplay to be worth the steeper learning curve.

How did we do this?  First off, we had to reduce confusion by ensuring we had a clean UI and limited what could and couldn’t be forged.  These topics will be touched on in later posts, so for now we will focus on the ‘depth’ side of this depth vs complexity.

The key to adding depth was to make sure that the decisions presented to the player were meaningful.  First, we wanted the choice of forging to have different outcomes. We wanted to give a player reasons to not only forge a card, but to also choose not to depending on the situation.  A great example of this can be seen with Lai’s move ‘Blitz Strike’, which disarms an opponent’s trap (ward) if one was laid. Players can choose to merge two ‘Blitz Strike’ cards to turn it into ‘Frenzy Strike’. Doing this adds high damage on top of the disarm effect, but the cost is a second disarm effect.  Depending on who the player is facing and the state of the game, it might be wiser to not forge ‘Frenzy Strike’ so that more traps could be disarmed. Conversely, it might be better to forge ‘Frenzy Strike’ for a spike in damage to finish off an enemy hero. Discovering what choice is best for any given situation is vital for the gameplay of Sigils of Kairos.

Lai performing the forged 'Frenzy Strike’. Useful as a high damage finisher.

Lai performing the forged 'Frenzy Strike’. Useful as a high damage finisher.

Secondly, we needed the forge mechanic to make a difference in the game.  This basically comes down to balancing, forged cards needed to be strong enough to be worth playing without being overpowered.  Though this seems straightforward, there were some subtle factors that we didn’t anticipate at first. Originally, we looked at the power output of a card and used a standard multiplier for its forged version.  This didn’t pan out when we actually ran the prototype of the game. Sigils is a game of class roles, and as such, players try to protect weaker characters from harm. This results in critical windows of opportunity where weaker characters are only brought forward for short periods of time.  Players take advantage of these windows by spiking damage using forged cards. When we loaded our baseline set of damage, we didn’t factor in how impactful these damage spikes would end up being. As such, early versions of the game had squishy characters absolutely destroyed before seeing much play. This ended up being a valuable lesson to learn and is a constant consideration as we balance the game further.

With the forging mechanic adding so many meaningful decisions that involve so many quick calculations, our game became much more competitive and interesting.  Forging increases the skill cap that allows good players to shine and gives room for new players to grow. With more meaningful decisions to make, players learn what the most optimal play is in any given situation.  This road to mastery is not only great for Sigils of Kairos, it is the end goal that gives the game longevity and replayability.

Please keep checking in for more design discussions regarding our upcoming project!

~ Cedrick

Forging #1
 
Cards like ‘Scotch’ have a gap showing that there is space for another card to fit in, this lets players know that it is forge-able. If you look at ‘Insane Combo’, you can see a fully forged card.

Cards like ‘Scotch’ have a gap showing that there is space for another card to fit in, this lets players know that it is forge-able. If you look at ‘Insane Combo’, you can see a fully forged card.

 

To begin this topic, I’ll discuss what ‘forging’ is in Sigils of Kairos.  In short, there are cards that can be upgraded by merging them with a similar card.  The simplest example would be when a basic attack card. When one basic attack card dragged onto another, they are replaced with a single card that does more damage. Each individual character also has a special move that can be forged with duplicate itself to create a more powerful version. These character-specific cards can’t be mixed and matched with other types of cards.

When we came up with the idea of forging cards together, it felt like a very natural extension of our core game idea.  Originally conceived as a ‘combo’ attack, the forge mechanic served to fix some fundamental issues with the game and add to the meaningful decisions for players.  Where we are currently in development, it is difficult to even imagine Sigils of Kairos without the forging mechanic as it is so integral to our game.

As briefly discussed, there were some projected issues with hand sizes early on.  Throughout the game, the player is dealt a hand with cards from all of the characters in the party.  Since the player can only play cards that belong the active character, their hand would get gummed up until they risked putting a more fragile character out front.  Although a risk-reward dynamic adds to the game, we also wanted players to hold cards for specific openings as opposed to playing cards for the sake of getting them out of their hands.  Though this hand crowding is bound to happen, we wanted to minimize it and make sure decisions are both distinctive and impactful.

By merging cards together, players are given more space for new cards to come in and amplify the card effects already in their hands.  This doesn’t just allow cards to be held for specific openings, but highly encourages it. This leads directly into the next and more important outcome of the forge mechanic, decision making.

Please drop by in a couple weeks and I will dive into some of the decisions that stem from this mechanic.

~ Cedrick

Roles
 
© Hot Sauce Bread Studios

© Hot Sauce Bread Studios

 

In one of our first posts, we touched on the decision for a team of three instead of 1 vs 1 matches.  Though I didn’t mention it, another reason for our decision included on adding different roles into the game. This fit for a variety of reasons and was pretty much a no brainer when we began fleshing things out.  The basics of these roles are pretty straightforward, but I feel like there is still some merit in discussing how they work in our game.

It will be no surprise that we focused on the three pillars that define a RPG party: Tank, DPS, and Support.  The beauty of these roles is that gamers have been trained on the basics of these roles over the years, cutting down on things we have to explain.  Though I could’ve drawn this framework from pretty much any RPG, I naturally looked at World of Warcraft as a polished example.

Playing WoW for as long as I did showed me how different classes can approach the balance between versatility and min/maxing. Classes in WoW such as the Druid, show how you can have a jack-of-all-trades character that can still be useful in their versatility even in the end-game. By doing this,  WoW also displayed how different classes interact and can fill a role while still distinguishing themselves in play style. These takeaway lessons can be seen in how we approached different characters within the same role.  More ‘Pure’ class characters in our game include Otto, Diam and Amyth that are meant to focus on the basics in their role. Otto tanks, Diam heals, and Amyth burns faces. Alternatively, looking at the mixed class characters such as Khurn, Skrill, and Garric show how versatility can switch up gameplay while still fulfilling a role.  Skrill, for example, can’t heal the rest of the team, but has a move set made to handicap the other team and prevent damage intake.

© Hot Sauce Bread Studios. Pure role classes. From top to bottom: Amyth (DPS), Diam (Support), Otto (Tank)

© Hot Sauce Bread Studios. Pure role classes. From top to bottom: Amyth (DPS), Diam (Support), Otto (Tank)

 
© Hot Sauce Bread Studios. Mixed role classes. From top to bottom: Skrill (Support), Garric (DPS), Khurn (Tank)

© Hot Sauce Bread Studios. Mixed role classes. From top to bottom: Skrill (Support), Garric (DPS), Khurn (Tank)

For some of you this was all obvious enough, but how does it play out in our game?

Whatever game you see these three party roles, there is always a trade-off for keeping a tank character in the forefront. Naturally, there is a trade off in health and damage output, but it needed to go further.  In our case, the speed in which cards are drawn was a natural fit giving a ‘durability vs card draw’ dynamic. Durable characters would draw cards slower but be able to take a hit while flimsy characters would draw cards faster.  The result of this is twofold. First, the overall speed of the game changes depending on the characters put out front creating a satisfying ebb and flow. Secondly, players now had a risk/reward tension when deciding on who to keep out in front and when to pull a character back. Though we anticipated this would be important, it wasn’t until after the first few play tests that we realized how defining this tension would be to our game.

Again, I hope that gave some insight on how we made some of our decisions for Sigils. Please follow us @hotsaucebread on twitter to get more updates on our game!

~ Cedrick

Chopping Block - 'Standard' Character
 
Chopping Block.jpg
 

Hello Everyone!

Welcome to the first in a series of blog posts that we will be calling the ‘Chopping Block’. As you can see, we even have a nifty image reserved for this feature. Chopping Block will be a discussion over an element of our game that didn’t end up working out for one reason or another. As with most game development, a lot of stuff hits the cutting room floor for all sorts of reasons and we wanted to shed some light on some of our thought processes regarding these cuts. Some of these chopped ideas were definitely removed from our game entirely, while others may have been recycled into something that better fit our game.

In today’s post, I will be talking about the very early days of development when I was pulling together ideas for characters in Sigils of Kairos.

Idea

When conceiving the basic framework for this game, there was always one character idea that was sure to be a lock.  Some may be thinking of Otto the tank or Diam the healer, as they are iconic tropes that fill ‘pure’ roles, but they would be wrong.  One of the original characters envisioned for Sigils had their moveset completely planned before being cut. Which character? The ‘Standard’ character.

The idea of the ‘standard’ character is one that’s used across the board.  For any Street Fighter, it’s Ryu. For Overwatch, it’s Solider 76.  For any Mario game, it’s-a him, Mario. Although each of these characters are unique, they also have the most straight-forward tools for their respective games.   For our game, the ‘Standard’ character was supposed to be the baseline for all the other characters to bounce off of. ‘Standard’ was set to be the jumping off point for new players, introducing the basics by using a generic play style.

Reasoning

Standard would have been the face of our game from the beginning. This tutorial-ready character that would’ve been a normal-looking human for skittish players to ease into the world we’ve built.  In contrast, other characters like the Khurn (the blacksmith) or Lynx (the cat) involve a bit more knowledge of the game as their moves use lesser known mechanics such as defense buffs or provisional damage. For new players, these characters can come off as overwhelming or even underpowered if not used correctly.

In terms of moves, ‘Standard’ would have had a mix of a little healing, a little damage, and a basic trap/disarm to touch on main mechanics.  Originally envisioned as a typical RPG reluctant hero, Standard would wield a sword and fall back on some of the RPG tropes for her/his move list:

Standard Moveset:

  1. Damage Card (A special move that attacks the front opponent)

  2. Potion Heal (Standard uses a potion to heal target ally)

  3. Splash Damage (A special move dealing damage to the front opponent and minor damage to the back opponents)

  4. Disarm (Remove a trap, Laying a trap was also considered here)

  5. Ultimate: Discard up to 3 cards, Deal 3 attacks and a crit to the front opponent

Card Draw – Medium / Base Damage – Medium / HP – Medium

Removal

As you can see, the character would have lived up to the name ‘Standard’.  By all accounts, the character would have been fine in the game, but there was one vital flaw.  Standard… was boring. With no discernible hook, the character’s mediocrity far outweighed the appeal of being relatable to the player base.

Another big reason why we ditched this character, is that the Paladin (Garric) seemed to lean in the same direction as ‘Standard’. It was Jacob that recognized this and basically cannibalized ‘Standard’ into our ‘Paladin’ moveset.  By converging the two characters, we made a single character that was a lot more interesting both mechanically and narratively. Looking back, this change was bound to happen eventually.  With a limited roster, each character needed to shine. Constructing a character for the sake of filling a slot will always be less interesting than an organic creation.

That’s it for this week. Hopefully you enjoy the new Chopping Block feature as we’ll have plenty more coming your way in the future. My hope is that ‘Chopping Block’ will give a better understanding of our design thought process.

~ Cedrick

Initial Worries #2
 
Hotsaucebread pepperparty.jpg
 

Hello Everyone!

This is another development post following up with the one last week. If you didn’t get a chance to read it, you can check it out here to get a bit more context. Just as a brief reminder, the issues presented in this post were some of the worries that I had going into Sigils of Kairos, even before I reached out to Jacob. Though I had a good idea of the core loop of the game, I was thinking through some of the design problems that came with an innovative genre bender like Sigils. So without laboring the intro…

Lack of Options

It may seem strange that I originally saw Sigils of Kairos as a fighting game at the beginning of development, but the genre has a lot of strategy in high level play. From a design point of view, well crafted fighting games become like a game of chess. Though I am personally not that great at fighting games, I’ve played enough of them (and watched some breakdown videos) to catch some of the nuances in a match.  Watching veteran matches in games like Street Fighter or Dragonball Fighter Z shows a fascinating dance of attack/counter-attack. Each player has a ton of options for attacking like dashing, jumping, projectiles, fake-outs, poking, or even just standing still and swinging.  If an attack lands, great! but if it misses, the player is left helpless to a barrage of counter-attacks from the other player.

I wanted this feeling for my game from the very beginning.  I knew that Sigils was going to be a competitive game so every choice had to build up that combative tension.  Unfortunately with cards, the broad range of actions and attacks gets reduced significantly. I saw this lack of complexity as a potential game-killer for a competitive game and was worried that the game wouldn’t offer enough strong and interesting options to players.

Over-Complexity of Play

The other extreme to the design challenge above is the over-complexity of the cards.  Sigils of Kairos was a strong concept because it marries a few strong game genres together, which opens up a huge well of potential directions to go. With so much to work with, it is very tempting to take up as many game elements as we can, but this would be disastrous.  Not only would the scope be out of hand for a two-person team, but every mechanic we add creates a barrier for casual gamers. These barriers make it harder for newer players to compete and become veterans over time.  

Card games have justifiably been correlated with complexity from the beginning. With a turn-based game, players have a chance to familiarize themselves with the rules and cards so they can plan out optimal plays. In a real-time setting, however, every moment spent reading a card or figuring out a mechanic is a big handicap.  Because of this, we tried to avoid adding any overly-complicated mechanics and wanted things to stay pretty straight forward. This is a very delicate design challenge as we have to find the perfect balance between an easy-to-understand accessible game and deep satisfying experience.


As with any project, we hit a slew of other unforeseen challenges in the making of Sigils of Kairos.  Still, I hope these posts show some of the hesitations going into Sigils of Kairos and sheds some light on some of our design choices that mitigate these problems.  Also, keeping these potential problems in mind still allows us to avoid pitfalls as we tighten up our gameplay.

Naturally, you’re probably wondering how we went about addressing these problems. The answer is: a lot of things. A big reason why I am posting these initial worries now is to help set up future posts on design elements that we’ve put in or taken out of our game over time. I hope that by doing this, it shows how thinking things through early on helped shape our design philosophy going forward. This might not be a very satisfying way to end the post, but please bear with us as we go forward and post more about our development.

~ 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

In the Beginning
 
The original sketch for a game that was to become ‘Sigils of Kairos’. See if you can notice all the design changes made since this was drawn.

The original sketch for a game that was to become ‘Sigils of Kairos’. See if you can notice all the design changes made since this was drawn.

 
Image from the original Plants Vs. Zombies from ©PopCap Games

Image from the original Plants Vs. Zombies from ©PopCap Games

As this is one of our first posts talking about our actual game, I suppose I will delve into the genesis of Sigils of Kairos.  The idea that would turn into Sigils actually began from a minigame in Plants vs Zombies. In this minigame, cards would scroll onto the screen and players would use them as they became available.  Having played Collectible Card Games like Magic: The Gathering, I felt like this would be an interesting twist on the genre.

The idea kept burning in my brain for the next few days and I was scrambling to find a framework to incorporate as many of my ideas as I could.  I strayed away from summoning minions and complex mechanics because I was hoping for a faster paced game. I settled on having cards played as attacks using a set character for the player.  After a while I realized that having only 1 character for each player wouldn't work for a few reasons.

  1. Each player would run out of cards right away and it would turn into a spam-fest of cards as soon as they were drawn.  

  2. Both players might draw at the same speed (negating the need for the real time)

  3. If one player picked an avatar that draws faster than another, it would be infinitely frustrating for the slower player.

Instead, I looked at games like Marvel vs. Capcom, which swapped characters in and out.  I also incorporated class roles, which would give players reasons to switch characters often and for strategic reasons.  

It was now time to get a rough layout of the game.  I drew out my idea onto some scrap paper, and it hasn't changed much throughout the entire development.  Obviously inspired by the old JRPG games of my youth, this rough drawing became all of the inspiration I needed.  Weeks passed and the more I stared at it, the more everything seemed to fall into place. This of course brought on unique design challenges which I’ll delve into on some upcoming posts. If you’re reading this as I’m posting and are in the Ottawa area this weekend, please drop by the Ottawa Geek Market happening at the Nepean Sportsplex. It will be our first time running a booth and we would love any support you can give.