dark mode light mode Search Menu
Search

Cronch the Cats

Bartlettbee on Flickr

One of my favorite genres of video game in the past few years is the rogue-like. They’re a genre that’s defined by a few things including:

  • Difficulty
  • Having to start the whole game over when you die once
  • Random generation of levels and items

Rogue-likes include all sorts of games like Spelunky, The Binding of Isaac, and — relevant to the game we’ll be building this issue — Slay the Spire.

The idea of Slay the Spire, pictured previously, is that you proceed through a series of randomly generated turn-based battles to face the final boss. Each turn you draw a hand of cards from your deck. Your only action, as a player, is to choose which cards you’ll play. These cards can attack, defend, cast magic, or use special skills. When you run out of cards to draw the deck is reshuffled before you draw. At the end of every battle, you get to choose from three randomly chosen cards to add to your deck for the rest of the game.

Slay the Spire is a fun, but pretty difficult game, and we’ll be using it as inspiration for our own game: Cronch the Cats. We’ll call our game a (rogue-like)-like, because it’s a little simpler and easier than a true rogue-like. Well, mine is at least. Hopefully you’ll take some inspiration on making it a real monster of a game!

In this rest of this article we’ll be outlining the architecture of Cronch the Cats and the concepts involved, and how you can extend this game or use it as a launching point for something completely different.

The two big ideas for how we’re going to structure the code in this game are:

  1. Using a lot of user-defined blocks with arguments to organize our code
  2. Using generic templates for writing all the basic code for both our cards and our enemies

The basic flow of the game is that when the game starts we create a list that represents all the battles you’ll fight before the boss, and we’ll load the starter-deck for the player. We then run through each of the pre-determined battles. For each battle we:

  • Create the enemy
  • Start the combat loop
  • After combat, give the player cards to choose from as a reward

If the player has won all the battles, then they fight the boss!

The combat loop looks like this:

We draw cards for the player to choose from and then wait until two cards have been played. After that, the enemy gets their turn. We synchronize the player and the current enemy by using a message telling the enemy that it’s time to attack. Afterwards, if the player dies then the game is over. If they win, we finish the Handle combat block and move on in the main loop again.

As you can see, there’s a lot of custom blocks. This helps us show the core logic of game loop and combat loop without letting it get muddied with the details. It also helped with writing the game because first I figured out what the structure of the game needed to be and then filled in code as I went. This is one of the more complex Scratch projects we’ve done together and writing it in a modular way was rather useful in not losing the plot.

Now, let’s talk about the generic templates for the enemies and cards. I chose to write almost all the code for the enemies and the cards only once, on a sprite I call a template. For example, here’s the template for the generic card:

All the code, except for the parts that have comments, stays the same between every card the player can use. Here’s the code for the “Heavy attack” card for comparison:

It’s barely any different at all!
The same story goes for the enemies. Our generic enemy template is:

We only need to change the parts labeled every time we duplicate it to make a new enemy.

There’s a few other things that we’ll need to change as we add enemies and cards: the functions on the player sprite that choose new cards or create the enemies. Those are also labeled and require only a few lines of code with each one.

I’d suggest you look around at my example cards and enemies for some ideas about the kinds of things you can do. They are just examples though!

So what should you do with this game? Well, I’d suggest a few possibilities:

  • Add new card types
  • Add new enemies
  • Add attack animations
  • Add new effects and status ailments
  • Right now we have weakened status, buffed status, and poisoned
  • Re-factor the code so that we can have multiple enemies
  • Add equipment to the game that changes the player’s stats. You can have enemies have a chance of dropping weapons or armor in addition to cards to choose from

Hopefully this game ends up being a fun launching point for some of your own rogue-likes. Feel free to remix it and let me know!

Learn More

About rogue-like games

https://www.lifewire.com/what-are-roguelikes-4117411
http://roguebasin.com/index.php?title=Main_Page

Scratch Resources

Video tutorials for beginners
https://scratch.mit.edu/help/videos/
Scratch community and resources
http://scratched.gse.harvard.edu/