The Enemy Creation Process
What goes into making an enemy?
Infinite Level game discussed: The Future Project
As it turns out, making an enemy in The Future Project is a surprisingly involved process. Though their behaviours are usually pretty simple, they can still take a lot of time to make. And I'm just referring to the technical aspects of enemy creation. Let's not forget about the effort that goes into designing and balancing an enemy, or the process involved in making any enemy with a unique gimmick. For this dev blog, I thought it would be interesting to take a couple enemies and break down the work and considerations that go into making them. To keep things interesting, we'll take one enemy from Distant Sibling and another from Jeweled Tundra. Though they will both share a lot of general labor that goes into all enemies, each will also have a few traits unique to them that keeps the work interesting.
Before you even begin to to model or program an enemy, you'll first need to design them. This is where you'll usually have a basic sketch of how the enemy should look along with a breakdown of how it will behave. Since I'm a solo dev, the drawing portions of it don't really have to be nice. So long as I can look at my own drawing later and know what I was talking about, that should do the job. Unfortunately, one thing I did neglect to do while designing the enemies of the game was to draw them from different angles. This would have made the modeling process a little easier, as without those angles I had to sculpt from the mind's eye, which can sometimes be a little unreliable in my experience. Though, bear in mind I'm a programmer first and foremost, so perhaps those more acquainted with 3D modeling would have an easier time modeling from the mind's eye. Either way, knowing how an enemy can look from various angles is certainly helpful. Alongside the drawings should be something detailing what its abilities are. So, the Cyclops enemy from Distant Sibling is an enemy that will roam the area and pelt the player with projectiles, while the design for Jeweled Tundra's Dweller will point out its ability to bury beneath the ice and await its prey.
Yup, um…this is my drawing. It’s a good thing I’m better with Blender than pencil.
With that taken care of, one can either go ahead and start modeling the enemy or program it. As mentioned earlier, I am a programmer first and foremost, so my instinct is to get the enemy behaviours programmed and ready to go. However, as I discovered early on in the game's development, there's a lot that you're simply not able to do without the models and animations. All I could really do in this scenario was make the absolute basic version of these enemies and work from there. They would be programmed enough to do everything their design says they could do, but it would be a very early implementation that would inevitably be changed and improved upon. Of course, this also means that the enemies are almost always some basic geometric shapes cobbled together to represent the enemy's appearance. Some were incredibly basic, such as the Cyclops' single cuboid, while others like the Dweller would be a bit more involved, having a cube with four little cube legs. The Dweller's alpha appearance was honestly kinda cute in how simplistic it was, but alas, I didn't take any photos.
Once the behaviours have their first draft implementation, it's time to make the enemy models and animations. Here's a fun fact for you, reader: I had never done 3D modeling before this game. If you look at War Ender or Impressions, you'll clearly see no 3D models anywhere in those games (well, War Ender does technically have one, but it's a basic geometric shape and thus hardly counts). So before I could begin modeling the game's various enemies and other assets, I had to actually learn the process. It took a lot of time to learn the 3D modeling skill, and is a big contributor for why the game has been in development for as long as it has. Once I was ready though, I could finally begin modeling the enemies proper. Something I quickly learned is that, in order to make models, you have to learn how to break things down into their most basic geometric shapes and work from there. For me, I've found that I see a lot of spheres in my designs. Stretched out spheres, sure, but spheres nonetheless. That's how the Dweller would have started, only adding little cubes to act as feet later. Meanwhile, the Cyclops had a little more going on, with a stretched out sphere acting as the base once again but this time with cubes, cylinders, and spheres to act as hands, a neck, or joints respectively. Once you know your basic shapes, you sculpt them slightly to get close to the overall shape of your character, and then start joining the pieces and adding details. You can see this pretty clearly in the image below, which is of the Cyclops as I was just beginning to model it.
The Cyclops, before it got any detail at all
Towards the end of the model making process, you'll have to figure out two things – retopology and texturing. What is retopology, you ask? It's what you do to simplify a model to both clean it up and make it easier to work with during the animation process. There's a handy tool out there simply called Instant Meshes that will take your model and handle a lot of this for you. Professional 3D artists will probably read that and say that it's better to do by hand. And they are the experts, so I'm sure they're right. The way I see it, this program manages to get the retopologized models I need while still maintaining its quality. It's not perfect, and there is some manual cleanup you have to do after running the model through the program, but it's helped me tremendously in getting models ready for animating. I certainly recommend the tool for game developers out there who are like me and don't have a 3D artist to work with. Once the model is cleaned up, I then work on texturing the model, which can be a surprisingly involved process. One would hope that you just pick out the textures you want to use on the model, plug them into the model, and be done. But sometimes you have to dig into what's known as UVs, which in a nutshell is what tells the model what parts of the texture go where. Ideally you'll have a nice, seamless texture applied to the model. But if you don't, then it's off to the UV editor to figure out where the seam in your texture is appearing. For The Future Project, I have discovered that a lot of characters are able to just have a basic color with a normal map texture applied to achieve the look that I want. The Dweller is one such example of this, as it's really just a normal map and an orange color that gives its body the look it has. This of course depends wildly on the model and the look you're going for, so don't take this as applicable advice for every game and every model. Some enemies have adjusted values for what's known as “roughness” or “metallic”, and of course others have multiple textures coming together to achieve the look required.
Then there's animating, which is where much of the enemy's life comes in. I'll write up a list of animations that an enemy may have, usually somewhere between four and six, and then set up a skeleton to animate the model. I've definitely learned to appreciate the work of animators as I've worked on this game, it's not easy work at all! It's often a pretty time consuming process for me, and can even be the most time consuming part of an enemy's creation depending on the number of animations an enemy has and their complexity. I do like to think that I've been getting better as I go along though, and it's taken less and less time with each new enemy to animate them and get them into the game. It's that or I've been secretly finding cheats for getting through the animation process faster, such as reducing how many animations an enemy has. And hey, sometimes an enemy has very few animations. There's one enemy in the game that literally only has one animation, and that's it. But that's definitely the exception, and as you can imagine, it's for an extremely basic enemy.
Defining the events for a Dweller animation, as seen in Unreal Engine.
As we approach the end of an enemy's creation, we return to the programming part of the enemy and put on some finishing touches, namely sound effects and how animations work together. I of course set up the model to be used with the rest of the code that makes up an enemy, followed by creating what's known in Unreal Engine as an animation blueprint. Basically, this is the item that lets you link up all the animations you made, define when to transition to a given animation, and any special code that should be fired during an animation. This is where the differences between one enemy and another really start to appear, as everything from the timings to the kinds of transitions that an enemy has will differ. Probably the only constant I have between enemies is code saying when an enemy is no longer in its attack animation and some of the more basic transitions, such as the transition to its death animation. Let's look at our two examples, the Cyclops and Dweller, to really illustrate how different two enemies can be when working on them. It was mentioned earlier that the Dweller has the ability to emerge from the ground to attack the player, so it's going to have a special animation transition for burying upwards. It will also have special code that plays particle effects for when it buries and the sound effects used. Meanwhile, the Cyclops attacks by picking up a rock on the ground and throwing it at the player, which takes two animation events. The first one is for making the rock appear in the Cyclops' hand, and the second is for firing the projectile. There's a little trickery going on with the Cyclops where the rock fired at the player is not actually the same one you see it pick up, and the animation event in the Cyclops that fires the rock projectile at the player is the key to that trick.
Finally, there's of course the balance. This is technically an ongoing part of the enemy creation process, as feedback and my own opinions on the game balance can affect enemy balance. The main items to consider are how much health it has, how quickly it can fire a projectile, its movement speed, how much distance to keep from the player if it's tracking such a thing, how far it can see, and more. It's also worth noting how this enemy plays off of other enemies. Dwellers are largely by themselves in Jeweled Tundra, so there's less to consider there. Cyclops, on the other hand, is often paired with the Strider or Horned Rambeast enemies, both of which are the rushdown enemy types while the Cyclops plays more of a supportive role by keeping its distance and firing projectiles, so I have to make sure that their projectiles are not too overpowering for the player to handle at the same time as an enemy or two trying to get in the player's face. Gosh, I haven't even talked about enemy archetypes, have I? Well, in brief, I think of them like this – there's rushdown, supports, traps, and specials. Enemies don't have to strictly follow one of those. Some enemies can take elements of two or three. Dwellers, for instance, are a combination of trap and rushdown, while Cyclops almost exclusively play support. If you're curious what a special enemy is like, it's basically any enemy that plays a role that doesn't fit neatly into any of the other three categories. There's an enemy in Jeweled Tundra called the Ice Clad which falls into this category. It doesn't rush the player down with attacks, and since it's always by itself it can't really play support either. You'll see it coming a mile away too, so it can't quite fall into the trap category, so special it is. There's not many special enemies in the game, with the Ice Clad being one of the only enemies that falls into that category.
Take everything you see here, and multiply it by about, hmm...let's see...twenty? Something like that. I'm going to have gone through this process about that many times before the game is done. It sounds laborious, and it is, but I do have fun with it. It's incredibly satisfying to see a new enemy reach completion, as it does so much one it is finished. The enemy gives its respective world a lot of life and personality, and it makes for a more compelling gameplay experience as opposed to fighting cubes all day. As of this writing, I'm through the vast majority of the enemy creation work, with only a few enemies left to finalize. Add on bosses to this, which require some additional thought and labor, and you can see how consuming of a process it can be. And that's the combat part of the game. We've talked before about the map making process as well, which is the other half of The Future Project gameplay loop. Once it all comes together though, I think players will be in for a fulfilling, entertaining experience.
Until next time!
-Lance T.