Pål Schakonat

+46732632905

 

Deep down 7

Deep down 7 is a deck-building rouge-lite made in UNITY in 7 week at half time
Deep down 7 is a deck building rouge lite made in UNITY

Game systems

Game Loops

Core Game Loops: The purpuse of this 7 weeks trial was to make a white box that would check if it would be fun with slay the spire core game with an extra game loop on top of it to add more replayability. My inspiration comes from the rouge lite Darkest Dungeon. Darkest dungeon has heroes that gains buffs and nerfs in a dungeon and then you remove some of the nerfs in the city. I wanted to try out the same with the possess system where cards gain buffs and nerfs and you manage the nerfs in the city. The green boxses (see pictuere below) represent the systems that i implemented in this portfolio. My theory is that if these system is fun, then the core part of the game would be fun. My next chapter cover a post mortem on the possess.

Division of the systems

  • Villages​​ - Managning buffs and nerfs, deck building

  • Dungeon - Deck manegment and life/reward magment 

  • Encounters - Set up plays, combos

  • Player/Enemy turn - Defend/attack risk managment

Core game loops

 

One Page Design Document

Discription: This is a one page design document. This is one pictuer that your team can point at and discuss if their is something unclear about the design.

Card One Page V2.png

Agnostic ability class for enemies and cards

 
Same ability class for card and Enemies.
I use the same ability class for card effects and enemy attack. This means that when I add a new ability to a card, I can use the same ability as a enemy attacks. For example, I added the abilitiy "draw X cards" for my cards, later on i tried out a boss that deals alot of damage but also use the ability "Draw X cards" to let the player draw more cards.  
Code Sample: Here you see a agnostic function for abilities used by both enemies and player cards. It takes an ability data where it extract a list of all different abilities and apply those abilities to relevant targets. The ability list can change in size and is don´t need to be rewritten if i add a new ability.

private void myResolveAbilities(AbilityData data)
{
   
for (int i = 0; data.myGetAbilityList().Count > i; i++)
    {
        
BasicAbility ability = data.myGetAbilityList()[i];

        switch (ability.myGetTarget()) {

            case myTargetType.Player:
                myPlayer.myTargetByAbility(ability);
                
break;

            case myTargetType.FrontEnemy:
                myUseAbilityOnEnemy(ability);
                
break;

            case myTargetType.RangeSingelEnemy:
                myUseAbilityOnEnemy(ability);
                
break;

            case myTargetType.IsNotUsed:
                
break;
                            
            
default:
                print("no Targets");
                
break
        }
    }

    myUpdateEnemiesDeaths();
}

Core game loops

 

Core Game Loops: The purpuse of this 7 weeks trial was to make a white box that would check if it would be fun with slay the spire with an extra game loop on top of it to add more replayability. My inspiration comes from the rouge lite Darkest Dungeon. Darkest dungeon has heroes that gains buffs and nerfs in a dungeon and then you remove some of the nerfs in the city. I wanted to try out the same with the possess system where cards gain buffs and nerfs and you manage the nerfs in the city. The green boxses (see pictuere below) represent the systems that i implemented in this portfolio. My theory is that if these system is fun, then the core part of the game would be fun. My next chapter cover a post mortem on the possess.

Division of the systems

  • Villages​​ - Managning buffs and nerfs, deck building

  • Dungeon - Deck manegment and life/reward magment 

  • Encounters - Set up plays, combos

  • Player/Enemy turn - Defend/attack risk managment

Game Loops

Game systems

Possesses system - post mortem

The purpose of this portfolio-piece was to test out the possess system as a core reward system.

The card that kills an possessed enemy gets a upgraded. The possess system is the only system I completely invented myself and with that comes high risk. The possesses change the core reward system from my reference game slay the spire. Slay the spire is rewarding the player with a new card while i will reward the player with upgrading a already exsisting card.   

Possess as a reward

Possesses as a reward dosen´t create a synergy narrative

Possess and geting a new card can appear equal strong as a reward on the surface, both possesses and ganing a new card effect the strength of the deck the same way, but i think ganing a new card is way better. I believe the strong impact of getting a new card is due to the synergy narrative the player form in their head. When the player sees an interesting card they can add to their deck they sees possible plays with cards in their deck. For example, when the player is rewarded with a card that gives “double block” and have the card “Deal damage equal to your block” in their deck, they immediately gain the feeling of synergy. The player creates a narrative where the player plays "Double block" card and then kills the enemy with "Deal damage equal to your block" card. I believe that rewarding every combat with this strong synergy narrative is what put Slay the spire on this written moment at nr 2 on meta critic for newly releases to PC.  

Conclusion

If I would continue making the whole game, I would add gain a new card as a reward every time you win a combat. I would keep the possess system, I think possess creates a strong long-term meta game, but not the immediate impact that a gaining a new card provide.

"I believe that rewarding every combat with this strong synergy narrative is what put Slay the spire on this written moment at nr 2 on meta critic for newly releases to PC games"

 

Comunication

Playtest as quickly as possible with a object shaker
Communication is vital to test your game in a proper way and you want to add it as quickly as possible to start your playtest. I added a singelton that i could shake any object with a singel line of code. With this implemented early i could start give feedback to the player immediately after i implemented a new feature.
Code Sample: Here i did a check if i had energy to cast my card. I could esialy just add two line of code in an already exsisting has card energy check. Almost no work and i used that in final version.
if (!myPlayer.myTryUseCardEnergy(mySelectedCard.myGetCardData().myGetEnergyCost()))
{
    Shaker.self.myShakeObject(myPlayer.getct, myObjShakeDuration, myObjShakeMagnitud); 
    Shaker.self.myShakeObject(mySelectedCard.gameObject, myObjShakeDuration, myObjShakeMagnitud);
    return false;
}
Here is use the same object shaker i used if your out of energy  to show card targets