next »

[Benjamus_Prime]

Update: Feb 1 2022
Numbrawler is currently on hold for other projects. However, these first few months of development have been extremely instructive for me, and I'm satisfied with how I was able to meet my three main goals outlined in my original post (see below). I've learned a lot about developing in Unity, C# scripting, creating and animating hand-drawn art assets, and implementing dynamic audio with FMOD Studio.

Here is a glimpse of the game in its current state:


Time permitting, I'd love to continue working on this project in the near future. Until then, take care!

~~

Original post
Hello everyone! I'm putting together a top-down action game called Numbrawler. Each enemy is represented with a number, and gameplay will revolve around using a grappling hook to throw enemies into each other, subtracting their values from each other. The aim is for gameplay to be fast-paced and strategic, requiring the player to consider how they want to use the enemies on the screen.

My goals for developing this game are:

• After over 15 years working with Game Maker, learn to use Unity and C#
• Learn to use FMOD Studio for audio implementation
• Get practice with tight, focused game design principles

I thought I'd start this devlog early in the process, so I can document my whole design process. Here's how the prototype looks so far:



The mechanics shown here are the basis of the main gameplay:

• Every enemy has a rank, represented by a number.
• The player has a grappling hook, which can target enemies and bumpers. The player will move to the target, and then throw the target behind them. If a thrown enemy collides with another enemy, their ranks will be subtracted. For example, if a 1 collides with a 3, the 3 will become a 2, and the 1 will be destroyed.
• Enemies also have shields, which can be reduced with the player's gun. Enemies can only be grappled if their shield is depleted. Higher rank enemies will have more shield than lower rank enemies.

Enemies will spawn into the field endlessly, and the goal of the game will be to achieve a high score before eventually being overwhelmed.

I was inspired by this newsletter by Rami Ismail to think about the "core" of a game. Essentially, how I've understood it is that a game's core is a central feeling or motivation that a player gets from the game. The mechanics should then directly support that core experience. Here's how I've conceptualized my main ideas for Numbrawler so far:


And that's about it for now! I don't know how far this idea will go, so I'll just have to see how it feels as the prototype develops. Hope to be back with more soon!

[Benjamus_Prime]

Small update today. Just working out the look and feel of the game to get an idea of where I'm going. Starting to hone in on an art style:



Obviously still lots of placeholders here, but it's a direction! Never really done this kind of animation before, or used high-res art for a game—so I'm learning lots of new tools all at once!

I decided on a hexagon theme for all the shield visuals in order to unify them. It will be really important for the player to be able to easily tell which enemies are out of shield & can be grappled, so I'm planning out how to make that visual distinction. Hopefully will have more to show on that soon!

[Benjamus_Prime]

Update time! Lots of progress on the visuals, including a more complete tileset, an animation and texture on the grapple rope, a more polished animation for enemy shields, and a blazing trail for throwing enemies:



I also implemented some more dynamic wandering AI for the blobs. I wanted a system that would make their movements more organic, and allow them to avoid clumping together or running into walls. I used a system that checks a set of directions around them, applies weights to them based on desired direction and obstacles, and chooses the direction with the highest weight. You can see it in action here:



I based my system on the one in this Game Endeavor devlog video:






The green lines represent positive weights for desirable directions, and the red lines negative weights for undesirable directions. The white line represents the blob's current movement direction, and you can see it interpolating between the colored lines. The system works roughly as follows:

• The blob has an ideal wandering direction, which is determined by sampling Perlin noise. The way that works is like this:
  
  This is an example of Perlin noise taken from the Unity documentation:
  
  Each blob chooses a random y coordinate to sample at, and the x coordinate is chosen by runtime. The values are converted from a range of (0,1) to (-1,1), and then used to cause the blob's ideal wandering direction to meander left and right at random.
• Each blob considers 16 directions around it. Each direction is weighted by the cosine of the angle between it and the ideal wandering direction. The direction with the highest positive weight is chosen as the target direction.
• Blobs consider walls and other enemies as obstacles, in order to prevent them from clinging to walls or clumping together. When an obstacle comes into range along one of the scanned directions, an additional "ideal direction" is added to the system in the opposite direction of the scanned direction and scaled by the proximity of the obstacle (so the desire to move away from the obstacle gets stronger as the obstacle gets closer).
• That's it! Some small details help to make it smoother, such as:
  
  • Enemies don't stop moving if they're overlapping with another enemy, and they try to move in opposite directions from each other.
  • Blobs change their target direction faster if they're currently moving in an undesirable (red) direction. This makes it so that if they cross paths with another enemy or run straight into a wall, they can turn around more quickly.

That's all for now! Next up, I'll be implementing a chasing behavior for the blobs when they get close to the player.

[thehorseman007]

I like the artwork, the logic of your game, simply nice and good, Keep up the good work. 
Good Luck.

[Benjamus_Prime]

I like the artwork, the logic of your game, simply nice and good, Keep up the good work. 
Good Luck.

Thank you very much for the kind words! Greatly appreciate it

~~

Blob chasing behavior

I implemented the chasing behavior for the blobs, and fixed up a few small issues to get the behavior feeling more natural. The wandering system turned out to be robust enough that all I needed to do to add chasing was just make the blobs' "desired direction" point toward the player. Their ability to avoid walls and other enemies was already enough to allow them to navigate simple obstacles while chasing the player.



The blobs will begin pursuit if the player is within range and line of sight, and continue chasing until the player gets out of range or behind cover for at least 3 seconds—that way, blobs can chase around corners, but are still pretty easy to get away from.


Enemy concepts

With the 1s mostly done, it's time to start working out the other enemies. There will be exactly nine, and I want each one to have a meaningful role. I've started sketching out concepts for the first five:





Each enemy should enhance the core gameplay in some way. The player will be balancing several considerations from moment to moment, such as:

• At this moment, should I be shooting, or grappling?
• Are the enemies in a favorable position? (If enemies are grouped up, they're not safe to grapple, because you'll be putting yourself in danger)
• If I get surrounded, is there a shield-less enemy available somewhere that I could grapple to to escape?
• Should I use this enemy to throw at another, or try to throw another at it?
• Which enemies require my immediate attention, and which ones can I leave alone for now?
• If I hit enemy A with enemy B, what will the result be? Will that result be good or bad? (For example, hitting a 6 with a 1 will produce a 5. If 5s are hard to manage, it may be best to try hitting the 6 with something else instead.)

These are some of the main ways I think the gameplay will be interesting. Each enemy design should play into these points somehow, providing some sort of wrinkle or advantage, so that these questions are always interesting in the flow of gameplay. For example, the 4 in my sketches (the ghost) may be difficult to throw, because you'll need to be careful of their retaliation if you shoot at them; but they also may be difficult to hit with another enemy, because you'll need to throw it in a way that the 4 can't dodge. The best answer to this won't always be the same, so it will be up to the player to decide how to approach it.

[wolfsden]

Love your enemy sketches and overall design notes 

[Benjamus_Prime]

Love your enemy sketches and overall design notes 

Thank you so much!!

~~

More concept sketches

Made another page of concept sketches, leaving just the 9 left to design. I decided I'll leave the 9 concept for later and focus on implementing the first eight first; that way, I can test the first concepts in-game, and use the 9 to fill any potential gaps.



Twos

With that done, I started getting to work implementing the 2s. They're very basic behavior-wise: always ignoring the player and other enemies, moving in straight diagonal lines, and stopping intermittently to fire off four diagonal bullets. When they start moving again, they pick whichever diagonal direction that lets them move the farthest without hitting a wall.



You can see I also added a number to show each enemy's rank. Originally I wanted to incorporate these numbers into the enemy designs themselves (you can see this on the 1s... I'll remove those numbers later). I quickly realized this would create a lot of readability issues—especially for enemies who need to face different directions. It's important that the player always be able to easily see an enemy's rank and shield, so I opted for large block numbers instead.

Moving forward, I think I'm going to focus on implementing new enemies with placeholder graphics again. As much as I like to see the concepts fully realized, it's a lot of work to animate in this style, and I'd hate to have that work go unused if an enemy concept ends up not working out in testing.

[Benjamus_Prime]

Big update today! I've added prototypes for the 3s and 4s. No artwork for them yet, but their mechanics are in, so let's talk about how they work!

Threes

The 3s are aggressive boulder enemies which charge toward the player when in range. They wander around like the 1s, and when they detect the player, they pause for a moment, and then charge forward until they hit a wall:



Obviously, there's a problem here. It's too easy to duck around a corner and make them run right into a wall! They need to be able to navigate simple obstacles to find a better vantage point to charge from. Here's how that looks:



To accomplish this, the 3s use A* pathfinding as long as the player is behind a wall. Once the player is in sight again, they stop chasing and resume aiming.

They still have some issues to work out—for example, they have a hard time seeing you if you're standing against a wall. But it's good enough for a prototype, so that's where I'll leave them for now!

Fours

The 4s are little ghosts who mostly mind their own business. They also move like the 1s, but more slowly and smoothly. They don't care about the player—unless you shoot at them, in which case, they'll angrily lunge toward you!



Their field of vision is important: If you try to throw an enemy at them, and they see it coming, they will phase through it. Right now this is shown by the 4 turning blue. Notice how it only dodges if the thrown enemy passes through its field of vision and is coming toward it.



There are some interesting strategic ramifications from these mechanics. If you want to use a 4 to throw at another enemy, you'll have to contend with it lunging at you. It's easy enough to deal with on its own, but may force you into a bad position with other enemies around. However, if you want to instead throw an enemy at a 4, you may need to pull off a tricky angle. Each way has its own benefits and challenges, but this complexity is balanced out by the fact that they put very little pressure on the player unless you start attacking them.

Wrap-up

With four enemies implemented, you can start to see the gameplay taking shape: switching between offense and evasion, planning how to use each enemy, and having to carefully consider your position.



Next up will be the 5s, which have the most complex behavior out of all my sketches. I'll have to see how well they work out in practice, and possibly simplify them if they don't have the desired effect on gameplay. Until next time!

[Benjamus_Prime]

Okay, the 5s are in! Their behavior is more complex than the other enemies, but I have high hopes for how they're working out so far. Let's get into it!

Fives

Here are the 5s again from my concept sketches. Their mechanics are a bit different from what I wrote here, but the main idea is similar: they want to keep some distance from the player, and occasionally will jump in to attack.



Since I'm just using placeholder graphics while I prototype ideas, you'll have to use some imagination for this one. It can be a little hard to track what the 5s are doing without animations, but I'll do my best to explain!

Mechanics

The 5s use the same basic movement system as most of the other enemies. They strongly prefer to keep some distance from the player, and if you get too close for too long, they'll take a swipe at you (represented here by turning magenta and lunging forward).



Occasionally, they will rush at the player for a surprise attack. They'll do this based on a timer regardless of positioning, so they use pathfinding to choose the best route. They then pick spaced-out nodes along that route to quickly jump between, and if you're in range at the end of their route, they'll slash at you:



A controller object keeps track of all the 5s on the field and manages their timer. When the timer's up, it chooses one at random to launch its attack. However, it won't choose the same one that attacked last. This way, it ensures that the 5s all get to take turns being aggressive.

Up until now the 5s have been jumping directly to the player's position, but this isn't really what I wanted. I want them to jump *close* to the player, but not actually hit you until they swing their swords. So instead of setting their pathfinding destination to your position, I needed to make them choose a destination near you. They do this by considering a set of points in a circle around you, starting with the one closest to them and working their way around, until they find a point that doesn't overlap with a wall. Here's how all of that looks:



And now they're mostly working! Of course, the gizmos won't be visible in-game, but I realized that it's important for the player to see the path that a 5 is going to take. So I added a visual for that:



And there we go! Finally, you can see them in gameplay with the other enemies:



Wrap-up

I touched on it in the last post when talking about the 4s, but I think a good way to think about the enemy designs is with the question: What kind of pressure does this enemy add to the gameplay? Each enemy adds a different kind of pressure, but so far they've all been mostly avoidable as long as you stay away from them. The 5s are unique in that no matter where you are, they will force you to contend with them. My hope is that this will keep the player on their toes, without becoming overwhelming.

[Benjamus_Prime]

Big art update! Say hello to Pem, our main character and resident number cruncher!



And here are some early design sketches:



After my last update when I implemented the 5s, I felt like I had enough enemies in the game to start focusing more on the larger-scale game flow. I decided to start working toward a robust vertical slice, with art, a health system, enemy spawning, and audio. To that end, I added artwork for the remaining enemies:

Threes:


Fours:


Fives:



And here's everyone together!



That's all for now. From here I'll be focusing on developing those other aspects I mentioned and working toward a fleshed-out vertical slice.

[Benjamus_Prime]

Update time! Took some time off from Numbrawler to work on other things for a bit (made some music, did a game jam), but now I'm back with more!

Spawning

I've added a simple enemy spawning system! Right now it just periodically spawns up to three enemies, picking spawn points that aren't too close to anything already on screen. Even with just this, the game has already gotten pretty fun to play around in!



Some things I plan to incorporate in the final spawning system are:

• A round/wave structure, to create an ebb and flow in the pacing.
• A difficulty scaling system. Ways difficulty can scale include: spawning higher rank enemies, more enemies per wave, more frequent waves, and more waves between resting periods.
• A system that can tell if it's possible to clear out all the enemies on the field, and if not, what enemy it could spawn in to make it possible. The math on this is pretty interesting, and I'll make a bigger post about this when I have it working!

But, in the meantime...

Audio

I've finally started implementing audio with FMOD Studio! It was one of my main goals from the start to get more hands-on experience working with FMOD, so it's nice to finally be at a point where I can do that.

It's very preliminary, but here's a small demo of the SFX I've designed for the main mechanics:




That's all for now! My next tasks will be continuing to design the audio, and implementing a health system.