Video Game: Heroes vs. Monsters

This game is © 2025 David Hammerle. All Rights Reserved. You are granted permission to download and play for non-commercial, personal use only. No redistribution or commercial exploitation is permitted. For any other use, please contact davehammerlecoder@gmail.com.

I worked on this game intermittently between March 2008 and October 2015. I put a total of ~2,600 hours into it, the equivalent of about 15 months of full-time work. As with my other attempts at game development, I was hoping to sell the game to make money, but never did. I eventually got feedback on the game from some local game developers, which is something I really should have done much earlier. The feedback was solid enough that I think I had some idea at that point what I needed to do in order to turn the game into something that people might actually buy. But I also realized that making all the necessary changes would have taken a lot longer than I wanted to spend, so I decided to give up on the game. Also, while working on this game, I noticed that it wasn't very much more fun than doing any other form of software development, and other forms tend to pay a lot better.

The game is a real-time pausable fantasy-themed squad-based rogue-like tactical combat game. I was trying to make a game with a combat system similar to Baldur's Gate 1 and 2, or its spin-offs, Icewind Dale and Icewind Dale 2, but without any plot or dialogue, and with a lot of deep, but accessible strategy.

Download the .zip file from here and unzip it to a folder. Run the file HeroesVsMonsters.jar in that folder. If that doesn't work, try running 'java -jar HeroesVsMonsters.jar' from the command line in that folder.

Objective

This is the most complicated game I've made. The objective of the game is to kill all the enemies in each battle before they kill all the player's characters. Each battle puts the player up against a random assortment of enemies on a randomly generated map. There will also be items that the player's characters can equip before each battle, and they will change gradually as the player progresses through the game.

Difficulty Level

The player can set the difficulty level before each battle. After each battle, the player will get a score based on the difficulty level and how well the player did. Even if the player's characters were wiped out, the player will still get a score based on which enemies were left and how much health they have. In general, the player will get a better score if they pick a difficulty level that they can barely beat. The player may

Spells

Each of your characters is a mage, and they share a common pool of magic points (MP). You will have access to a total of ~9 spells. That means that each of your characters will start with access to 3 spells, but each time a character dies the spell slots will be redistributed, so 2 characters will have 4 spells each, and the last character standing will have 9 spells. Each time you cast a spell, that character's spells will all change. You can hover over a spell button to see what it does in the bottom right corner of the screen. If you don't understand something in the spell's description, you can hold ALT and click on it to see an explanation of each part of the description.

Right-Clicking Spells

It's generally a good idea to spend your MP as you get it, rather than waiting for it to accumulate. What you can do is pick a spell that you plan on using once you have enough MP for it from the ~9 spells currently available, and then right-click that spell. Right-clicking the spell will automatically pause the game for you when you have enough MP to cast it.

Keys

• Left-Click: Click a character to select it. Click a spell to use it. When targeting a spell or ability, click a map space or enemy to target it.
• Right-Click: Tells the selected character to move to a specific space. Right-click a spell to make the game auto-pause when it becomes ready for use.
• Shift: Hold shift to queue up multiple orders to be carried out sequentially.
• Space: Pauses/unpauses the game.
• Minus: Reduce game speed. Can also right-click the 'Game Speed' button.
• Plus: Increase game speed. Can also click the 'Game Speed' button.
• Escape: Open the main menu.

Important Terms and UI Elements

• Softness: A higher number indicates that the character is more of a glass cannon that dishes out a lot of damage, but doesn't have much health while a lower number indicates the character is more of a tank. You should try to target softer characters first. Enemies will tend to target your softer characters first.
• Resistance: Most buffs and debuffs will be divided by the character's resistance. In particular, enemy bosses tend to have high Resistance so that debuffs are not inordinately powerful against them.
• White Bars: The white bars near characters that slowly fill up indicate the next time that character will take another action.
• Vertical Bars: The vertical bars next to enemies on the map represent cooldown abilities and buffs/debuffs. To see what one does, hover over it.

Demonstration Video

This is a demonstration video that I made back when I was actively working on this game, showing basically how to play it.

Summary

I made this game using Java and its 2D graphics API, and it uses entirely programmer art, so it doesn't look very good. At least there is an icon for each spell and item. Towards the end of when I was working on this game, I started trying to switch it from Java to the Unity Engine. I was planning on using some free art I had found online along with some free particle effects I found on the Unity Asset Store, and could modify as needed. But Unity was even more awkward back then than it is now, so it probably would have taken a very long time. I only managed to set up a basic Unity project and start experimenting with Unity's particle effects before I gave up on the game. It really would have been better if I had started off by figuring out how I would do the art, graphics, and sound, rather than trying to switch to the Unity Engine later.

The Balancing Module

Probably, the most impressive (and complicated) part of this game is the balancing module. I tend to always care a lot about gameplay balancing when I'm making a game, especially a game like this. I find it very annoying when games are not well-balanced, and it ends up being that, for example, 90% of the items in the game don't matter, because it's always better to choose the other 10%. But I didn't want to have to do all the play-testing that I would have needed to do in order to balance the game normally, so I decided that I would instead try to balance the game using the power of math. I thought by doing a bunch of careful calculations, I could figure out how powerful each spell, ability, item, enemy, character, etc. should be.

The balancing module that I created started off pretty simple. I programmed a bunch of calculations for determining how powerful any given thing was. Then I used a very simple 'root-finding algorithm' to play around with the inputs for an item, for example, the amount of damage that a weapon does, or its range, or both. I figured out what I should multiply the inputs by in order for the calculated power level of the item to be very close to the amount that I wanted.

Play-Testing

As I continued to work on the balancing module, I was also play-testing the game to see which things were too powerful or not powerful enough. That would generally lead to me discovering something important that the balancing module wasn't accounting for, and then I'd add the balancing module to account for that thing. I also found that there were some aspects that I couldn't account for just based on the stats in my spec file. For example, I would play-test the game a bit, find that all abilities that hit multiple enemies at once were too powerful, and adjust the constants in the calculation that tries to account for that until it seemed like those abilities were about as powerful as they should be.

Derived Statistics

The balancing module was made even more complicated by averages and other derived statistics. For example, if there was a spell that gave a character a bonus of 20% to all the damage the character dished out for the rest of the battle, in order to calculate how much extra damage that was likely to do, I needed to know how much damage characters tend to do on average. So I calculated those general stats by taking averages of numbers that I calculated for the individual things. And that worked well, but it introduced another issue. Now the way the balancing module was handling each individual thing depended on the general stats, but the general stats were dependent on the averages of the values associated with the individual things.

In order to deal with this, I set it up so that the balancing module would iterate. First it balanced each individual thing. Then it calculated the general stats. Then, since the general stats had changed, it re-balanced each individual thing. I would keep doing that until the numbers mostly stabilized and weren't changing very much after each iteration.

But sometimes that didn't work. If even one thing to be balanced was balanced incorrectly and its numbers became way too high or way too low, the general stats wouldn't stabilize after a few iterations. Instead, the general stats would change more and more on each iteration. So one little bug or one little typo anywhere in my spec file could make the balancing module non-functional until I tracked down the problem.

Gathering Play Stats

But that wasn't all I tried in order to balance the game. My next idea was to balance the game by making it play against itself and collecting stats on what happened. For example, if I could collect stats on how many enemies tend to get hit at once by a fireball, I wouldn't need to guess at how many would generally get hit by it. I fully implemented this method of generating and collecting stats, and I even set the game up to play against itself at high speed in order to collect the stats more quickly. But I underestimated how difficult it would be to debug this feature, so the stats that I collected were way off and I eventually gave up on this method.

Enemy AI

Another use of the balancing module was in the enemy AI. In order to decide what each character would do at any given point in time, I set up the enemy AI to first make a list of potential things that the character could try to do, like attacking an enemy with a weapon, or casting a buff on a friendly character. Then I iterated over all those potential actions and tried to calculate a favorability for each action. I measured this 'favorability', in units of: damage divided by target's remaining health multiplied by how much damage the target does per second on average. For all abilities that didn't involve just dealing damage, I figured out ways to translate whatever the ability did into these units. The balancing module provided lots of useful stats for the AI module to use, like the estimated damage output of any given character.

Conclusions

Overall, I really should have focused on trying to get feedback on the core gameplay and figuring out how to get art and graphics to make the game look decent before I started worrying so much about gameplay balance. Writing the whole game using Java's 2D graphics API and then trying to transition it to the Unity Engine later was not a good idea. I should have used the Unity Engine to begin with and tried to find free art for the game before I started seriously working on it. Also, looking back on it, I really should not have made the game pause-able, because it just results in the player spending way too much time trying to figure out what to do next (this is called analysis paralysis).