Soul Source - Game Journal

Soul Source was completed for Stencyl Jam 2014 and is playable in that form here:
http://www.newgrounds.com/portal/view/636225



I have plans to expand the game from it's current form.  Right now it's a procedurally generated dungeon crawler with some action adventure controls, but I'd like to expand the combat system into a deck building, turn-based combat system.

In addition, the backstory is being rewritten and fleshed out, along with a static over world from which the player will delve into different dungeons. 

SOOooo..... its a 2-d, top-down rpg with a static overworld, procedurally generated dungeons with random encounters and boss battles that uses a deck-building mechanic for inventory and turn-based combat.

More posts to come.  but here's the ROUGHEST draft of a screenshot of the battle system.  Down below are the slots for the player's hand of cards.

Implementing a Deck and Card system into the game is going to require a series of multi-dimensional lists. 
I'll need a list for:

• Library of Potential Items
• Stored Player Inventory
• Carried Player Inventory
• Equipped Player Inventory
• Player Deck
• Player Hand

Thats a lot of lists for just the Player.  In addition to that, however, I'll need Lists to maintain the Cards available to the various enemies to be encountered.

List for Enemies:

• Library of Enemy Cards
• Enemy Deck
• Enemy Hand

So far implementing that plus some temp artwork for visual feedback is taking up all my time.  Will follow up with some notes about the list implementation.

...and some WIP animations...

Updates 04-02-14

Implementing the card processing "stack" is the current beastly task.  The basic game flow of combat involves choosing up to 2 actions from your hand at the bottom.  These two selected cards move up to the selected card slots along the left hand side of the screen.  The enemy character will also choose 1 or 2 actions each turn.  The first cards of both player and enemy will get processed and then the second cards of player and enemy will get processed.

For reference:
"A" cards are attacks, which will be more varied and tied to equipped items and spells.
"B" cards are blocks, which will be tied to armors or shield spells.

***********

Implementing the actual information in the cards is not as complicated.  A "card" is a list with several fields holding it's information.
[Type, Value, Speed, Animation#, ResponeAnimation#]

• Type: differentiates between attacks, blocks, and other special abilities.
• Value: the power of the attack or block.
• Speed: higher speed cards get processed first
• Animation#: this will identify the animation to be triggered for the player.
• ResponseAnimation#: this will identify the animation to be triggered for the enemy.

In order to implement decks and hands of cards, I simply create a list of card lists which can be read using nested [get items "index" from "list"] blocks.

Drawing a card means adding the first item from the Deck list to the Hand List and then removing it from the Deck.  Likewise, playing a card entails adding the card from the Hand list to the "stack" and then removing that item from the Hand.  Each of the cards that are used by player or the enemy is placed in the stack, sorted by selection order and card speed.  The Stack is then processed in order at the end of each turn, which means that use the basic math:

• PlayerHealth = PlayerHealth - (EnemyAttack - PlayerBlock)
• EnemyHealth = EnemyHealth - (PlayerAttack - EnemyBlock)

While these actions are processed, animations are triggered based on the cards played.

After those cards are processed, they are discarded from the stack.  Then new cards are drawn and the next turn can begin.

Thats the rough outline of how the card combat will be processed.  Hoping to get a playable demo of the combat up on the arcade soon!