Tag: combat

C-C-C-COMBO SYSTEM! Part 2

Last time we talked about how players will build Combo Points by playing cards in the right order. This time we’ll learn how that glorious combo can be ripped down in an instant if you’re not paying attention!

Interrupts

Not going with the flow

You can’t just rack up Combo Points carefree. Combos can be interrupted meaning you lose all of the combo points you’ve built up and perhaps even worse! Sometimes you may be able to play a card that is the color needed for you followup Combo Color, as is the case when you don’t have a card of the necessary color in your hand. In this situation you will still want to play a card in order to continue damaging your enemy, but when a card is played that is not the color of the required Combo Color your combo will be interrupted. Having your combo interrupted means setting your Combo Points back to zero and missing out on any combo bonus effects you had been building up! So try to manage your deck and cards in hand to maximize your combos.

Combo Breaker!

Your enemy isn’t going to sit there and let you wail on them all day! Enemies attack the player every few seconds, depending on the enemy. When an enemy attacks it will interrupt any combo you’re trying to put together. In addition to having your combo interrupted you will also be effected by the enemy’s attack typically in the form of being dealt damage. Ideally, the player will want to conclude their combos with a Finisher before an enemy’s attack timer fills resulting in the best combo bonuses while mitigating the enemy’s damage. One last thing, just as the player is given bonus for completing combos, the enemy will get bonuses for breaking the player’s combos!

Finish that combo quick! Dummy strikes back soon!
Finish that combo quick! Dummy strikes back soon!

So there is an overview of the current combo system used during combat. Things are still being tested to see what works and what needs to be changed. The need for the right card colors will hopefully play into the deck building aspect of the game, urging players to be mindful of the cards they put in their deck and to hunt down the perfect cards to fit their strategy.

C-C-C-COMBO SYSTEM! Part 1

Ok, now this is starting to look and feel more like a game. The combo system has been added to the game in a basic, minimum viable product sort of way. Just the minimal amount necessary to demonstrate the idea has been implemented. The code is still a bit of a mess and some refactoring is certainly in order but there are too many ideas to get out. Some other UX improvements have also been added.

Dragon Drop

The ability for a user to drag and drop (I prefer to call this Dragon Drop) cards during combat has been added, making for a much more fluid combat experience. Cards are now flicked at the enemy portrait in order to use the card. This flicking motion lends itself towards faster card plays which feeds into the combo system.

Combos

The idea is relatively simple, all cards are given a color and most cards have a Followup Combo Color. When a card is played and then the next card played is the color of the previous card’s Followup Combo Color the player’s Combo Points are increased. The player can continue to rack up combo points until the combo ends. A combo ends either through the use of a Finisher or by being interrupted. A combo can be interrupted either by the player not following up a card with a card that is not the Followup Combo Color or by being attacked by the enemy.

Finishers

Finishers are almost the same as Followup Combo Colors. Where most cards have a Followup Combo Color, many of them also have a Finisher Color. When a card with a Finisher Color is played and then followed by a card that is the color of that Finisher Color the combo is completed granting the player bonus damage and/or effects. The player’s Combo Points are then reset and a new combo can begin.

sweetCardArt
Early card examples showing card color, name, Combo Color and Finisher Color.

 

Next time we’ll cover how combos can be interrupted and all the terrible things that take place when that happens.

Half Combat

Half of the super basic combat system works! For testing purposes, whenever a player clicks the Explore button, combat is initiated with my good ol’ pal Test Dummy. Yep, that bag of straw and anger is back to take another kicking. preAlpha_Combat01

Once in combat the player’s starting hand get’s drawn. When a card is used it’s cardPower is deducted from the Test Dummy’s health. This continues until the Test Dummy has no health left to lose, at which point the combat window is closed and the player is given a random reward.

Like the patient dummy he is, Test Dummy doesn’t fight back yet. That’s next on the agenda, I can tell he’s itching to strike back… or maybe the itching is from the straw… I’m so corny.

How to handle the Deck, Hand, and Discard

I spent a long time thinking about the best way to handle this aspect of the combat system. The inventory system already has the player’s deck as a Dictionary with a Card as the key and the Quantity as the value for each row and at first I thought I could just use this Dictionary as the deck in combat as well. First I tried to give the Card class a inHand and inDiscard boolean property. The idea was to just toggle these boolean values as the card moved from deck to hand to discard and back to deck again. This quickly became apparent that it wouldn’t work easily and that it would be best if each card had its own row meaning having 2 Punch cards would result in having 2 rows in the Deck array.

So I switched to a List, no big deal. At the start of combat the Combat Manager loops through the deck dictionary and turns it into a deck list. Now I could just look through the list for cards that have inHand and inDiscard booleans set to false and I can draw one of them!

Wait, no, that kinda sucks too! Doing that would make randomly selecting a card difficult as i’d always have to check to see if the card selected was inHand or inDiscard, if it was in either of those places, select another random card and keep doing that until an available card was found. Laaaame!

So the inHand and inDiscard boolean idea was scraped too and two new Lists were added, the Hand List and the Discard List. Now, a random card could be selected and removed from the deck list and added to the hand list. No having to make sure a card in the deck list was currently in the player’s hand. If a card was in the deck and was available to be drawn!

So there I was, spending all this time thinking up the right way to do it, the when I started implementing what I thought was the right, it turned out to be very wrong and the right thing fell right into my lap. I’m a little embarrassed I didn’t think of it sooner!

Better Map Generation, Auras and Deck Include Modifiers

Getting back into the swing of things with the project by first implementing Better Map Generation. Like I said in my last post, the world used to be generated totally randomly as a player moved around, causing Mountain terrains to be right next to Forests which are directly next to Tundras, basically all the terrain types where just mixed together.

But now, when a player moves into a new location, with no terrain tile associated with it. The game takes all adjacent terrain tiles into account before choosing one. This causes larger Biomes to exist, hopefully this will make the world seem less random and give some aspect of actually being somewhere in the world. Especially when I get around to adding biome specific events, enemies and effects.

This is just the first step in expanding the terrain generation mechanic, so we’ll see how that goes.

Next up, I started adding in Auras but quickly realized I need to refine the idea. The basic idea is that Auras give you special abilities, and you can only have 3 equipped at a time. These special abilities would give you additional choices during events or alter how some items work. At first I thought they might just be stat modifiers but I scrapped that idea because I was afraid it would move in on the Deck Include Modifiers idea.

So my plan is to leave Auras alone for now and return to them after implementing Deck Include Modifiers. What ARE Deck Include Modifiers you ask? This is a mechanic I’d like to add where including certain cards in your character’s deck result in your base stats being modified, as a means of balancing a cards power.

For instance a FireBall card might do a large amount of damage when played in combat, but simply adding the FireBall card to your deck will lower both your Max Hit Points and your Defence. The overall idea is that by adding certain cards to your deck you have some degree of control over your character’s “class”. Want to be a Mage-like glass cannon? Add in those fireballs and other powerful abilities at the expense of your health and defence. Perhaps add in Armor cards that have no effect when played in battle, but their Include effect raises your base defense so long as the card is in your deck, making you into a Warrior like tanking class.

These are just off the top of my head, so there will probably be many changes as I start to add it in. Which is exactly what I’m about to try to do!

True Deck Validation, Card/Combat Reconjigger, Additional Content!

True Deck Validation, I was being dumb

Last post I started out boasting about how I implemented Deck Validation, but then as I was writing the post I realized it didn’t work at all. Well this time I actually DID make Deck Validation work, by avoiding the problem altogether. Take THAT last post!

So originally I came up with this way of having the deck get checked for its validity after a change was made. Oh and just so you know, an invalid deck is one which has less than 10 cards in it, for now atleast, I may increase the minimum deck size later. But anyway, I quickly realized this was the wrong way to go about it, as a deck could be made invalid (remove all the cards) then the player could just leave the game entirely by closing the browser, upon returning to the game they would be back in the world, with an invalid deck, ready to blow up my game the moment they enter combat and have no cards to draw! Hell no am I letting some deckless weirdo blow up my game!

So basically, I just made it so you could never go below 10 cards, if you try to the game doesn’t apply your change, warns you of such and tells you to add a card before removing one, easy. I wish I thought of that at first.

Making Cards and Combat not suck

After that it was on to making Cards and combat a bit more interesting. Problem was, until now, cards could only make 1 stat change. That was fine when I only have cards like Punch and Kick that do x amount of damage to the enemy, but if that is the most any card can do then the game will get boring really fast. I’m bored just talking about it, so I set out to make more complex card interactions possible.

Cards are now made up of 2 objects, Card and CardEffect, in a One to Many relationship. One Card can have many CardEffects. Each of these effects can have a different target, effect different stats and for different amounts. This allows for new cards such as Thrash, which does a large amount of damage to the enemy, a moderate amount of damage to the caster and lowers the caster’s Defence stat. Complexity, Fun!

There are many other cards like this and I intend to balance a cards with positive and negative effects to make each choice one of risk vs reward. Hopefully this will make combat more interesting. I have more ideas for making cards have interesting effects, even having them affect the character outside of combat!

Speaking of combat, since I changed around how cards work, that meant that I had to go back and refactor my combat methods. This took a while but it really needed it, since I’ve learned so many better practices since first coming up with my combat methods. I still have to add in text generation but that shouldn’t be too hard… (famous last words).

Filling out the games content a bit

Lastly, I’ve greatly improved the workflow involved with adding content to Nano. This is something only admins like myself would ever interact with, but adding content has been something I kept putting off simply because the only way to do it was via SQL statements. Well not anymore! Now I have nice forms that I can fill out and drop down lists with all my enums. Just the other day I added 20 cards and all their effects. Next will be enemies, consumables and events!

So, things are working out pretty well, and I think I’m still on track to have Nano ready to present at DevelTeam’s game jam. Only thing left that I haven’t thought about is how to host the game. I originally planned on just hosting it on my own computer and leaving my comp on for a few days and giving them an IP address, but I’ve started to look around and it seems I can get some temporary hosting setup and just use that for the contest. Better figure that out soon!

Combat goes in the Combat Box

Long story short, I got the Combat screen to display within the World view via ajax. What does this mean? Means the game looks like this when in combat now…

Featuring background scene art by Koishii Kitty.
Featuring background scene art by Koishii Kitty.

This turned out to be easier than I expected when implementing, but took a while to plan out properly. The result is a smoother transition from Event to Combat. There are still a bunch of things I need to refactor now that this is how the combat screen will be displayed, but it’s a step in the right  direction.

I still need to change the card’s ‘Use’ button to use ajax and the players stats in the top left need to update after each combat round.

I also ajax’d the close button for the inventory screen, meaning now, going from the World screen to your Inventory, using an item and then closing the inventory screen to return to the world screen is all seamless. I’m going to start looking into fancy javascript animations for the opening and closing of screens. While the current transition requires no full page refresh, the switch is somewhat startling. I think all it needs is a slight fade as it transitions.

Weekend Update 05-12-13

Some updates from this weekend:

  • UI improvements for the World screen. It still have a ways to go, but it’s a start.
  • Random Monster Encounters! Characters are now hurled into combat randomly when they enter a new location.

Probably going to need to reconjigger Cards and combat again to make room for more complex card interactions. I’d like to avoid making a separate method for each card, but I think some cards will require it.

Thinking about making more complex card interactions means I might have to step my AI’s game up. Perhaps that is where I can begin implementing the learning AI I’ve been wanting to experiment with.

I need to add a lot more content, more Cards, Enemies, Terrains, Items, etc. I’ll make a form that I can use to easily add those things to the database.

I hope to have a veeeeery early build “playable” in a few weeks, if anyone is interested in trying out what I have so far.