If you aren’t familiar, Bitsy is a great starter game engine. It forces a very limited scope upon you, and reduces time creating assets, making complex logic, and debugging. It’s the video game equivalent of limiting your color palette in art. It restricts you to better enable your creativity with a limited toolset. It has 128x128 worlds, 8x8 items, 8x8 sprites, 3 colors per world, and directional movement of an “avatar”. Without using any 3rd party tools, that about sums up the tasteful limitations
I’m currently making a game for the Mysterious Soup Bitsyjam. Of course, this is for a class— Tiny Games, lead by Danny Rankin.
My current idea is to do a traditional journey-based game. I’m still sketching out the details, but the basic idea is that the “mysterious soup” will be a power-up in this game. Whenever you collect a new soup, you learn a new move to use in battle. And yeah, you battle enemies to get new soups Mega Man style. In fact, it’s basically Mega Man as an RPG.
Well, it turns out I ran out of time for all that. But here’s the “finished” game either way.
Soupman by halmic for Mystery Soup Bitsy Jam
So let’s get right into making a Bitsy Battle System from scratch. First things first, we’ll need a room that acts as our Battle Scene! We’ll be reusing this room in order to make adding multiple battles into a Bitsy game as painless as possible.
The Soupman fightroom. Honestly just kinda rushed through it here. You can be much more creative.
As you can see, I’ve added 3 basic options for the user in my game. Healthsoup- which heals you. Basicsoup- which is a basic attack. And of course, an Info option since Bitsy doesn’t really have a real UI we could make use of. Make each of these their own sprite- and I’ll go through the dialog/coding of each one. Once you can make one of a type, you can feel free to extend it with your own attacks, health potions, MP, etc.
Now, the one drawback to making the battle system as reusable as possible is that it does require the extensive use of variables. If you aren’t familiar with Bitsy’s variable system, I recommend this writeup as a refresher.
Okay, refreshed? Let’s get into it. Here’s a list of variables that I created and use.
| Variable Name | Initial Amount | Comment |
|---|---|---|
| hp | 10 | Can be changed! This is the user’s starting hp. A maxHp variable might also be useful for capping health- but I didn’t implement that. |
| eneHp | 0 | We will set this before every enemy fight! |
| dmg | 0 | A temporary value to help store the amount of dmg an attack does- user AND enemy |
| enemyName | "” | Set this to the enemy’s name before a fight |
| enemyDmgMin | 0 | One of three attack values for the enemy’s attack. This is the smallest amount of damage their attack does. |
| enemyDmgMid | 0 | Same, but median damage. |
| enemyDmgMax | 0 | Same, but max damage. |
| userDmgMin | 0 | Same, but for the users attack. Since we only have one attack, this works...but you might want to figure out some logic for multiple attacks. I personally would just set these attack values when the attack is used. |
| userDmgMid | 0 | You get it, right? |
| userDmgMax | 0 | Always name your variables appropriately. |
| enemyAtkName | "” | The name of the enemy’s attack. Set before a fight. |
| userAtkName | "” | Same thing. Can probably set when a move is used. |
| endMap | "” | The map to return to when the fight ends. Incorrectly setting this before a fight causes a softlock. |
| endLocX | 0-15 | The X location on said map to return to. Useful for moving past enemy sprites. |
| endLocY | 0-15 | The Y location. |
Woo... that’s a lot huh? Well, the alternative would be a lot worse...at least I think. Obviously not all of these have to be implemented (use one dmg value instead of 3 each, remove enemyVar ,etc.) But if you’re following the guide, make sure that these variables are defined in the Inventory tab! Don’t worry- we’ll go over them all.