Big Bang for your Development Buck - A quick look at the Binding of Isaac's enemies
Coding AI is hard.
While I’ve known how to code since middle school, for much of my life my coding experience was limited to Lemonade Stand Simulators, or Hangman games, or a polynomial multiplier/divider-type projects in high school. For years, creating something that could make decisions in real-time seemed waaaay out of my reach.
My first enemy AI was coded in 2012. It was a little bladed enemy for Blood Alloy’s (then unnamed) prototype; he’d walk left to right until he’d detect a ledge or a wall and then turn around. If he saw you, he’d pop out two little blades and charge at you. If you jumped or dodged out of the way, he’d slowly skid to a stop. If he struck a wall while charging, his little blades would get stuck in the wall, and he’d have to pull them out. It’s also possible to make him run off a ledge, as his ledge-detection turns off while charging.
…. For a first-ever enemy, that’s an INSANE amount of complexity, and honestly I was a FOOL to ever attempt something like that right out of the gate.
(Thankfully, to this day, people really react favorably to that enemy. Way back in 2012, he looked like this:
Now he looks more like this:
But anyway, an important lesson I’ve learned over the past 6 months is that you do NOT need sophisticated AI to make for a deep, fun playing experience. Look at Luftrausers. Look at Hotline Miami. Look at Super Metroid.
And now, for example, let’s look at Binding of Isaac.
I have to say, Binding of Isaac has to take the cake for enemy design for the following:
1) Instant readability. For just about every enemy, after watching it for ~5 seconds, you immediately understand how to kill it, how it attacks, and how to avoid getting hurt by it. The few enemies for which this isn’t obvious make for some very tense moments, as they force you to be on guard and extremely cautious.
2) Compounding enemy abilities allowing for enormous variety. Each enemy has a set of abilities, and the harder enemies simply have these abilities stacked.
3) Ultimate simplicity in enemy abilities - both in expression and in creation
Here’s a little cross-section of the Binding of Isaac Rebirth Monster Wiki:
What I like about this:
1) Enemy classes share the same fundamental movement behavior, which can be used across multiples enemies. Often movement behavior is the hardest/most time-consuming thing to code (less so if you’re doing top-down 2D, but whatever). Huge time and effort-saver.
2) Enemies look pretty similar, but if you know what to look for, you can still identify them at a single glance. This rewards observational skills for players who do memorize the enemy types, but for players who don’t, it just encourages caution when approaching enemies.
3) Variety in enemy behavior is simple (jumps high, jump low, vary jump distance), but has a strong impact on gameplay differences.
Here’s a brief, non-exhaustive rundown in the enemy attributes that enemies in Binding of Isaac juggle:
- Moves towards the player
- Moves away from the player
- Moves randomly
- Moves in straight lines, bounces off of walls
- Grounded (collides with grounded obstacles)
- Jumping (can jump over grounded obstacles)
- Airborne (unaffected by grounded obstacles)
- Damage player on touch
- Does not damage player on touch
- Shoots stuff at the player
- Shoots stuff periodically in a variety of patterns
- Creates damaging trail that fades
- Creates damaging puddle that fades
- Charges in player’s direction
- Always vulnerable to attack
- Must stun/damage before you can do “real” damage to kill them
- Only vulnerable while they are attacking
- Only vulnerable from behind
- Finite HP
- HP will replenish itself if left unattacked for a time
- Dies with no effect
- Spawns multiple smaller enemies
- Spawns a “body part” enemy
- Emits pattern of red orbs
I’m sure there will be a few that I’ve missed, but that’s a large bulk of them. Now, will simple permutation/combination math, the number of possibilities available from this list are staggering, especially considering that some enemies have 1-3 attributes from any category.
So the ultimate lesson here? Enemy variety is important, but you really don’t have to kill yourself to achieve an impressive array of foes.
Especially for your first game, it’s common to start thinking crazy and complicated for your enemies. Don’t. Think small, predictable, and think about how you can get good bang for your buck.
Next up, I’ll look at a few of my favorite boss fights, and look at the underlying simplicity of THOSE.
Boston Festival of Indie Games: A PostMortem
Blood Alloy: Reborn has been in development for almost 1.5 years now, and this years’ BFIGS was our first public showing of the game.
Here’s a brief rundown on how I prepared, how the event itself went, what kind of feedback we got, and what I’d do differently next time.
So, we actually showed off Blood Alloy not as part of the digital game showcase, but as a Sponsor - at the time of submission, we just didn’t have a high enough level of art polish (the entire level was a graybox), but I wanted the playtest feedback so I splurged $200 on a Sponsorship table.
This meant that physically, we were going to be slightly removed from the Digital Showcase games, as Sponsorship tables were in their own cluster of tables about 50 feet away from the Digital Showcase, but it was better than nothing.
Here’s a list of things I brought:
Laptop with a playable build and an mp4 video
40" LCD TV
Two mice and a mousepad
Wired Xbox 360 USB controller
500 business cards - Game art, title, and website address on one side, personal contact info on the other
Self-standing “How to Play” placard made of folded poster board
Printed banner with the Game’s logo on it
The actual BFIGs festival happened on Saturday September 13th, but they allowed exhibitors to come in to do a preliminary setup between 4-7pm the day before, the 12th. Setting up the day before the event was amazing, as it enabled me to verify that I actually had all my equipment and that everything worked appropriately while still giving me a good time window to fix any problems that arose. I originally planned to just come really early day-of, but man am I glad that I did the Friday setup instead.
Everything set up great and functioned without a hitch.
I got some tutorial level art in really, really late on Friday, and I honestly was too exhausted to implement it, so late Friday night I just disabled
the playable tutorial, thinking that between my presence and the “How to Play” placard, people would be fine. This was a huge mistake. More on this later.
Day-of - Execution
So I was the only one demoing the game - the entire development team works remotely, and nobody else could make it up to Boston for the day.
This turned out to be murderous. By the end of the day my legs were jelly, my voice was a raspy whisper, and I was ready to simply collapse and die.
Even if you have to pay a friend to exhibit with you, do NOT exhibit by yourself!! I lucked out because my wife decided to show up and just hang out at the booth and play her 3DS - this meant that at the very least, I had someone to watch over my stuff while I took bathroom/water/lunch breaks.
Because the Sponsorship area was somewhat removed from the Digital Showcase, for most of the day we saw much lower traffic than the rest of the festival. To try to combat this, I actually turned my TV about 45 degrees so that the screen was that much more visible if you were in the Digital Showcase area itself, and that seemed to improve foot traffic.
It seemed that I’d either get really enthusiastic individuals who’d stay and play for 10 minutes or more, or groups of 5-8 people at a time who’d all
watch while one person played.
Without a playable tutorial, I wound up personally explaining the controls to everyone who played. For the most part this worked okay EXCEPT for explaining my boost mechanic - “Hold down on the left stick so you’re crouching, then hold LEFT trigger. No, left trigger. Yeah! Now WHILE you’re doing that, you can press RIGHT trigger to shoot”… yeah, it was terrible. Many people contented themselves just with basic jumping and shooting, and with younger kids I’d just show them how to equip the sword so they could just whomp on enemies with the sword. Which itself is something to consider - consider having different segments or elements of your game easily accessible by people with lower skill levels. If there’s even a very minor, but easy-to-perform gameplay loop that’s satisfying, showing that to lower-skill people will make them happy and satisfied.
When foot traffic died down, I’d pause the build and alt-tab the laptop to a looping trailer.
Right in the day when I got the hungriest for lunch - about noon to 2pm - was the busiest foot traffic. I was starving and had no choice but to put up a “Lunch break” sign on the booth, put the looping trailer up, and go get myself some food, and in doing so I missed out on a big chunk of potential players. Luckily, it turned out that the whole time people were grabbing and taking my business cards, even if they didn’t get to play.
Overall Game Feedback
It was an enormous, enormous relief to see that I wasn’t stone-cold-crazy, and that my own personal thoughts of “I.. THINK my game is fun to play” were not unwarranted. People were genuinely excited to see the game - they loved the swordplay and the art, but teaching people how to boost and how to fire the charged hyperlaser always resulted in cries of “Oh shit!” “Awesome!” I had a huge box of 500 business cards going into the event, and at the end of the day that number was halved. I made sure to tell as many people as possible about the Greenlight page, and so with some media push in the next couple weeks hopefully we’ll see some dividends in that regard.
I also gleaned some great feedback about the game, including:
- I STILL need to improve the camera code, as it still swings pretty wildly and can get the player right up to the edge of the screen.
- The act of crouching and THEN holding left trigger to BLAST along the floor is fairly complicated. I’ll have to either look into a better
tutorial system, or possibly investigate simplifying the controls.
- Of course a few invisible collision bugs made its way into the demo that I’ll have to fix
- The UI was simply not visible or noticeable enough - I’ll need to implement some sort of color-flashing to make it more attention-grabbing.
What to do differently
- Have a playable tutorial that teaches players each movement and attack mechanic and gradually stacks them. The structure of my game is currently an arena-score-chaser (think Geometry Wars or Luftrausers), but given the complexity of possible movement and attack, I really need to implement a mandatory training mode to ensurethat players have an opportunity to practice basic movement without getting slaughtered by an immediate onslaught of enemies.
- Don’t show a game without having at least two people throughout the day to man your booth.
- Bring a snack so that you can push through the lunch-hour/afternoon rush and survive until a late lunch.
- Drink even more water throughout the day.
- If at all possible, have some merch to sell or give out. People love pins, tshirts, and posters, and having that stuff available gives your booth “credibility.”
Overall, it was a great experience, and I’ll definitely be showing off the game more in coming months!
Thanks for reading, and if you’ve gotten this far, I’d love it if you could check out our Steam Greenlight page
and give us a vote!
Follow me on Twitter @FraynkWash
Blood Alloy: Reborn character concept art by Aaron Nakahara, cobaltplasma
Anatomy of a HitSpark - Aces Wild and Muramasa Rebirth
Any game featuring melee combat should strongly consider the use of hitsparks and hitpausing.
Hitpausing refers to the brief pause of a game that occurs on landing a melee attack.
There’s an excellent write-up of hitpausing in Street Fighter here, written by one of the combat designers of the God of War series.
The hitspark is the animated effect that you see emanating from the imagined point of contact of a landed melee attack. The combination of both hitsparks and hitpauses can make a ordinary-feeling melee system feel incredibly dynamic and punchy.
Aces Wild developer Tyler Doak (@CAS_Kicks) gave me an incredibly useful nugget of advice regarding the combination of hitsparks and hitpauses:
Have hitpausing freeze all action on the screen except for the animation of the hitsparks. If you freeze the hitsparks, then it looks like your game has terrible framerate. If you animate hitsparks at the normal speed, but everything else freezes on a hitpause, then the landed strike has that much more of a mental impact to register in the player’s mind.
Seriously, watch the trailer for Aces Wild right now, it is fantastic. Go buy the game too, it’s on sale.
Now let’s take a look at another game’s hitsparks - those in Muramasa, by Vanillaware.
There are three “components” to Muramasa’s hitsparks, and I’ll dissect/illustrate them here.
The following screens are taken from Youtube user Hikkie’s Muramasa gameplay video.
The first component is a long streak with a spherical concussive blast showing the impact location. This sphere quickly dissipates.
This is very quickly followed up by a color-shifting “slash-arc” hitspark, to indicate the force of the slash itself.
And finally, off of every landed attack come out a stream of billowing smoke streams that trace across the screen. You can just check out the linked video about to see how they look.
Together, the three effects make for a really awesome strike that clearly shows point of impact, gives the illusion of a “follow-through” force of the slash itself, and gives a big spray of smoke that seems to billow from the player. (Easily replaceable by blood or oil or what-have-you in your own game).
Currently working with our artists now to put together similar effects, and hopefully soon we’ll have something cool to show in that regard.
Happy to answer whatever questions I can.
An Examination of Wall-Jump Systems Across Blood Alloy, Noitu Love 2, Super Meat Boy, and Super Metroid
Hey all -
This is a brief overview of the multiple ways you can tune the mechanics of wall-jumping mechanics.
I like to think of a wall-jumping system of having 3 possible tiers, each defined by how forgiving/intuitive it is to the player.
I’ll finish this discussion with a brief analysis of Super Metroid’s wall-jump mechanic, simply because of its relative prominence and the fact that it does not easily fit into any of these tiers.
The player must be actively pressing against the wall when they press the jump button.
This is the the worst tier, and the earlier builds of Blood Alloy were damned by this wall-jump implementation.
Allow me to describe it.
In order to wall-jump, you must first be wall-SLIDING.
To enable wall-sliding, you have to directionally pressing against the wall.
Then to wall-jump, you must hit the jump button while STILL HOLDING THE DIRECTION AGAINST THE WALL.
(Please forgive our terrible early-build art).
Playtests pretty much universally revealed that this was a terrible system. It’s not that it’s necessarily difficult to pull off when you know how the system works - I personally had no trouble with wall-jumping, so at first I didn’t get what everyone’s problem was.
But ultimately it boiled down to this very simple fact:
If a player wants the character to move right, very likely they’re just going to hit the right arrow.
In this system, this means that you cease wall-sliding, detach from the wall, and just fall to the ground.
The player automatically starts wall-sliding - even with no directional input - when touching a wall mid-air. To wall-jump away from the wall, the player can simply hit the jump button.
This system is much more tolerant of natural player behavior. Konjak's Noitu Love 2 has a system like this:
This system is workable, but at least in Noitu Love 2 wall-jumping is pretty much optional. You’d be much better off with going to Tier 3, which is…
While wall-sliding, the player can directionally input AWAY from the wall, but for 5-10 “tolerance frames,” the player still remains STUCK to the wall. The player thus can either wall-jump with zero directional input, or can wall jump while inputting the x direction away from the wall.
When a player is bound to a wall on the left, and wants to wall-jump to the right, he/she will tend to hit the right arrow key either soon before or soon after hitting the jump button. This system allows for that imprecision, and the “stickiness” of the wall does not significantly impact agile movement throughout the level.
I believe Tommy and Ed of Super Meat Boy discuss this system in Indie Game: The Movie.
This system is by far and away the most common wall-jumping system you’ll see in contemporary games, and unless you have excellent reason otherwise, if you’re going to include wall-jumping in your game at all you should strongly consider building in these tolerance frames.
This is also the system that Blood Alloy currently uses.
In fact, if any segment of your game forces the player to wall-jump in order to proceed, you should probably consider this system mandatory.
Other notable games that use a system like this include Rayman Origins and the New Super Mario Games.
Super Meat Boy, Rayman Origins, and the New Super Mario games all have a wall-slide in addition to the wall-jump mechanic. Super Meat Boy is unique in that the wall-slide state triggers simply by being next to a wall - regardless of whether you’re going up or down. This weirdly conveys both stickiness and slipperyness with respect to Meat Boy himself.
Tier Super Metroid:
Super Metroid’s system is - surprisingly or unsurprisingly, depending on who you ask - not easily classifiable. It is a little bit like Tier 3, but is slightly more brittle, forcing the player to have good reflexes.
Also to its credit - and feel free to correct me if I am wrong - I believe it is possible to actually finish the game without ever wall-jumping. Thus wall-jumping is a skill-based “extra” for upgrade-collectors and secret-finders.
Anyway, let’s dig in.
First off, to wall-jump in Super Metroid, you MUST be spinning - this means you have to do a running/moving jump towards the first wall. It is not possible to wall-jump when you are already flush against the wall on the ground.
Second, Super Metroid’s wall-jump system actually demands that you press away from the wall. When you are in contact with the wall - or very close to it - and pressing the input direction away from the wall, Samus’ sprite will change and she’ll actually seem to turn around and face the other direction.
However, because of Samus’ low horizontal mid-air acceleration, the player actually has a comfortable time-window in which he/she can hit the jump button and rebound off the wall.
This system only works in slower-paced games like Super Metroid because of the relatively slow movement speed and acceleration. In many faster-paced games, the mid-air acceleration is too high and would result in an extremely small time window in which to press the jump button.
If I recall correctly, other 2D Metroid games, like Metroid: Fusion and Zero Mission also use this system to great effect.
Thus, Super Metroid effectively leverages the player’s impulse to move away from the wall during a wall-jump, and cases that impulse in a reflex-and-skill-based mechanic.
At the end of the day, my opinion is this - if you are making a precision-platformer or a high-speed action game, you will likely want to go with Tier 3. If you are making a slow, methodical exploration game, and wall-jumping is exclusively used for extra rewards, then feel free to attempt a solution like Super Metroid’s. From a functional/coding standpoint, I do think Tier 3 is easier to implement, though.
Oh, and by the way, Blood Alloy looks nothing like that image up top anymore. In fact I daresay it’s shaping up to look pretty awesome (Youtube Trailer).
Follow me on twitter @FraynkWash , or the company @SuppressFGames . Happy to answer any questions!