Project Breach #8 - "Finishing the engine (2/2)"

Project Breach #8
"The engine is finished! (2/2)"

The engine is finished

This is it, and what a journey it has been. It's easy to see a game engine like RPG Maker and think that it's quite simple, but these last 7 months have taught me otherwise. It's not where I expected to end up when I started writing another one of my random voxel engines all those months ago, but here we are. Phase 1 of my very own game engine built on top of Unity is complete. A working engine that I can use to make games with.

This update focused on 3 things:

1. Finding out what core gameplay features were left to finish, I'm sure there are many more I'll discover once I start making a game with it, but there were plenty I could think of to do now.
2. Getting rid of all test systems (like having to press Ctrl+Enter to spawn at a hard-coded position) and replacing them with final ones
3. Making sure the engine can be used reasonably on its own without Unity

There were even several systems I started on, some of which I even got pretty far on, which I then dropped because I realized that although they'd be cool additions to the engine, they weren't necessary for the game. The code I wrote is still there should I decide the game could use them.

This update is definitely the largest I've done so far. So for this update, I'm not going to go over every change one by one, if you want to see those you can read the bottom of the blog post. I'm just going to go over the ones I think actually matter.

So far everyone who has tested it says it feels better than it did before so I'm excited to share with you how I got there. The update splits into two parts, before I took a break & after I took a break, so without further ado lets begin.

Before I took a break

Making way for the new

Remember when this engine was an RTS/Strategy game for a few months? Well, a lot of that code was still lying around and I had left it there just in case I ever wanted to use it again. But having lots of old code clog up the engine was getting annoying so I saved it somewhere safe (a separate git branch) and deleted it from the engine. It only occurred to me afterward that I should've counted how many lines I deleted but my guess was somewhere between 1.5k and 3k. So for a while, this update had less lines of code than the last.

After that, it was time to update some of those old systems to the new & move forward with finishing the engine.

Combat

Starting off on a strong foot, I wanted to make combat feel juicier, after fixing any remaining bugs with it of course.

The camera now shakes when the player takes damage and the shake now zooms instead of just swaying you side to side. The players and pawns accuracy with a weapon are now based off of how fast they're moving. These two simple changes were surprisingly effective at making the game feel more responsive when taking damage and give a little bit more consideration to the player about moving.

And finally, after watching 3klikphillip's "The Game Making Journey" (for the third time) he mentioned in one of his games questioning traditional game mechanics like reloading. Although weapons already had the option to not use ammo, it made me think a bit outside the box and add the ability so that the player could have to reload a magazine but still have infinite ammo to reload with. I think I prefer this as having to loot ammo would only take away from the action I want the player to be constantly engaged with.

Gameplay:

And of course, with all this new combat, I needed the player to be able to die without having to restart the game every time. So I spent time making so that when the player dies, it will lock their controls, create a corpse, then show a game over screen. Then after a little bit, the map automatically restarts.

Well now that you can lose I figured the player should also be able to win. So now there's a map event action which will make the player win the map. It also now tracks and saves their time so they can see their best on the menu.

And of course it wouldn't be Project Breach if I didn't add some customization for modders. If you want players to have to beat all of your campaign's maps in a row or if you want them all to start unlocked, you have that option:

UI

The player can now interact with things just as pawns can. For this I created a nice interaction prompt:

The player can now see a pawns health. This was actually already a system in the game back from when it was still an RTS, it's just that the UI was only visible if the pawn was friendly. So all I had to do was make so the UI appears when the pawn is an enemy too. It had some other bars like showing the pawns cooldown and amount of ammo remaining, I left those in but only for friendly pawns so for enemies you just see the health.

Since I now have 2 UI which track an object in the world (Interaction UI & Pawn UI) I needed to improve the code responsible for tracking them because when the camera was moving fast, the illusion would break. Thankfully I was pointed in the right direction & shown "World Space" canvases which were exactly what I needed, I just had to do a little tweaking to the UI themselves.

I've also redone the players cursor system so it'll show you how accurate your shots are going to be. It does this in 2 ways, first by how fast you are moving and second by how far away you are aiming.

And finally for UI, I added cinematic text. So now during cutscenes you can show dialogue, or use it for whatever else.

Map Editor

Mostly what I wanted to do with the map editor was focus on making sure it was user-friendly and bug free so when I start making a game with the engine, I don't need to worry about it.

Besides that, I also added some new features. You can now finally create player spawns! For the longest time, it was hard-programmed into the game that in order to spawn you had to press Left Control and then Enter. Left Control would set your players team and then Enter would spawn your player with some test gear at the coordinates 10, 10.

Between this and adding the ability to win & lose, it actually feels like I could make a game without having to give people a list of instructions like I've been doing:

I'll throw this out here, while finding that image  I found one of when one of the testers played with the mod files:

And him testing the version before that where the walls accidentally had health & he broke out of the level:

Since the beginning of the project I've been tweaking the lighting but I actually recently got in contact with the guy who made the light system the engine uses and after a short conversation with him I was able to finally get the lighting looking how I've always wanted it to.

And of course, I added many new map events.

Player

I decided to get rid of the camera sway. It made the game feels slightly more cinematic but ultimately just felt like unfairly throwing off the players aim. I also fixed a jittering problem with the camera tracking the player so now moving around the players visual quality stays much more smooth.

I also added a new camera effects system. Currently, the only one being "rain" which you can turn on & off with map events.

The player's visual is now based off of where they're aiming not where they're moving. And the player only shows left/right instead of up/down. This was a style I did for my GMTK 2021 game jam game and it felt really nice so I implemented it here:

Project

There were some old systems lying around that were bothering me, that I knew when I made them would eventually need to be rewritten once I came up with a better solution. Things like looking up a mod object by ID when you don't know what type it is. Well those systems are now much more optimized which should help to reduce any lag spikes.

There were also some quality of life changes. You no longer need to use decimals when deciding how much a block tiles. Originally to make a block's texture take up a 2 by 2 area you would put the scaling as being 0.5. The scaling formula was just 1 divided by however many tiles you wanted it to cover. I've just made so that calculation happens internally so now if you want a block to take up 2 tiles you just put 2. I also renamed all previous systems called "Pawn Dialogue" to "Pawn Prompts" since I might add an actual dialogue system in the future and don't want the two to be confused with each other. Also previously I had 2 different map loading scripts, one for the map editor & one for the game which were 80% identical. I was able to merge them into one system so now when adding things to the map system I only need to do it once.

And finally, for these changes before the break, I cleared up most of the existing data. No more wood walls or demon enemies. It's all test objects & textures now. This is so I'll have a clean slate when starting on the new game. You may have already noticed that from the screenshots & GIFs.

And with that, I considered the engine officially ready to make a game with. After my break I'd learn it still had a few more tweaks to be done in order to work on its own, but for the most part, this was finally it.

Taking a break

I've talked before about needing to take a break but I really did need to. I won't go into too much detail, but I will say that I've never intentionally taken a week off of working on projects. Not since Middle School when I first got into more serious game development. I've never taken a vacation from working, and I work almost every day including weekends. Here's what I wrote at the time:

"I've talked about it before but I'm a bit of a workaholic, I don't know how to spend my free time doing things other than working. I don't even take weekends off. So I decided now that I've finished up the engine, before I start on a game with it, I'm gonna take a break, refresh myself, figure out how to exist without working all the time"

Now, I was still doing my full-time job but just not doing personal projects. I spent most of that time playing Old School RuneScape and had a constant craving for work, I felt like an addict going through withdrawal. It almost felt like the only way I could stop being obsessed with working all the time would be to replace that obsession with something else. Eventually, I branched out into playing Counter-Strike: Condition Zero (Released in 2004) which I had never played before & I actually had a ton of fun playing it. It felt good to really enjoy a video game again since for a while its felt like games have been kinda... meh.

Since then I've bought Darkest Dungeon & Ultrakill and I'm actually excited to play games again. With only 100 minutes Ultrakill has quickly become one of my favorite games of all time.

I haven't been cured of being a workaholic, and I'm not sure that I could or that I'd want to. But finding a balance between work and life is clearly something I haven't done & it's more apparent than ever that I need to. This break helped me figure out at least a couple of methods of avoiding work & how to be more engaged in the things I do outside of work.

After I took a break

Working without Unity

Before I published this update, I wanted to get at least a test map with some enemies going so that I had something to show of the new engine and make sure that the engine could be used without Unity. It took a few changes to get there, but eventually, I was able to prove the engine could comfortably be used on its own without Unity. I even managed to get a good visual studio setup for it (since it's all JSON files & a map editor):

Combat

Stumbling on the game Ultrakill by watching a FUNKe YouTube video was a dream come true. I really wanted my game to be inspired by Enter The Gungeon but I hate to say that game felt like it was close to being fun, but never really did it for me. Ultrakill however has given me infinite inspiration and is likely to continue to be a great source of it for the length of the entire project.

One big change I made was to increase the player and the enemy speed. This one change turned out to be the most important combat tweak I had ever made. Immediately the game felt more responsive & action-packed.

(The cursor is black because I had to make the game window really low resolution in order for the GIF size not to be too large which made the cursor downscale)

After that, I increased the health and damage numbers so that it felt like you were packing more of a punch and with these two changes and the previous ones the combat really felt strong and is making me excited to add more enemies and experiment with level design.

Gameplay

I created a test map for the player to play on which also utilizes the new lighting. It's really basic but it plays better than previous test maps and I think looks much better.

I was also discussing the topic of A.I with my friend Phineas and thought my game could probably handle about 200 pawns at once. But then I remembered I did the optimization of making so pawns can only target the player and wanted to put it to the test. So I created a map with 512 pawns and to my surprise, it ran fine. But I have a good PC, I was still expecting that many to crash a lower-end computer. To my surprise once again, the lower-end PC I tested it with ran at 30fps with the enemies idle and only got as low as 8fps when all 512 enemies were trying to fire projectiles at them at once. Considering I was expecting them to crash once those shots were fired, that's awesome. It means I can safely have 100~200 pawns in a map and still work with low-end PC's. And there are still many optimization techniques I could apply to get this performance to be even better.

Map Editor

I added player templates. This allows you to specify what gear & stats a player starts with in a map. Because there are no item pickups at the moment, this might be a good way to do progression. You could gradually start with better gear or health or speed. It also lets you define what visual the player has.

Project

A big thing I learned about having the engine separate from Unity was not having access to the editor console was a pain. So I made sure to add plenty of errors & warnings into the engine so if something went wrong you could figure it out without needing the Unity console. The cool thing is that I'm not the only one who benefits from the engine being self-sufficient as modders will also have an easier time debugging their mods if things go wrong.

There are also now 2 mods that come with the game. One is "PE3" which contains all of the engines default content like a test player, prototype blocks, and some other things. Another is "Main" which will contain the content for the actual game being made with the engine. The goal would be that the game eventually doesn't use any of the default engine content, but that the default engine content is there so that when first starting on a game you have something to prototype with. Some other of the default content include things that the engine needs in order to operate such as the "Air" block which needs to be in the engine & always have the same ID.

Closing Notes

So here we are. It feels weird saying the engine is done. I don't think in my heart I could ever consider it done since there are a million things I'd love to add and parts of the project I'd like to redo as I've learned so much. But this is it. Phase 1 of the engine where the engine is capable of making a game but doesn't have an application UI, is done. A version of the engine for my own use.

This marks the end of the Project Breach blog posts. Project Breach started off as a voxel engine, then became an RTS, then it became a top-down shooter, and finally it became an engine for:

1. Games that are 2D
2. From a top-down perspective
3. In which you control a player and
4. Does not require programming knowledge

It's likely I'll eventually make a public version of the engine where people can make their own actual games with it. But that's something I'm not going to think about for awhile. Right now it's time to make a game. I'm sure there's still plenty of programming ahead of me as the game takes shape & I think of new features the game needs. But the days of programming big systems every day are over.

Project Breach has come to an end, but my new game, Project Fire has just begun. I'm nervous, I think I'm a pretty good game programmer, but game designer? I don't know. As a programmer, I make great tools that other people use to make great games. But I realize that there's a lot I don't know about game development and design itself. Level design, audio, game feedback & art. It always felt like these were things I never paid much attention to with my previous games and often just by throwing stuff together somehow managed to make games people enjoyed playing. But I want to think about it now. There's a lot for me to learn, truth is, this almost feels like my first game in a way because it'll be the first time where I actually really think hard about these things instead of just rushing along. Where most of the game development will be the game and its content and not the programming. I'm not after making anything big, but I still question will I be able to make something fun & really better than what I've made before. I want my games to be successful, not just pay for themselves but to be successful enough to pay the bills.

So with all that, with this new project ahead of me and all this learning to do, I'm going to take my time. I'm going to spend the extra time to study, polish and iterate. To make not just a fine game but a good one.

So with that, I start Project Fire. The blog posts will continue but they won't be the same. Instead of going over every change like I do now, it'll be about how the game as a whole changed each update. I want to spend less time writing about making the game and more time actually making it, so they'll also be less frequent.

Already even with this test level testers are saying it feels much better than what's come before it. So, here's to Project Fire. And as always, I'll see you guys in the next update.

Sincerely,

Blake Gillman

Project Breach #7 - "Finishing the engine (1/2)"

Project Breach #7
"Finishing the engine (1/2)"

Map Editor

The two big things I wanted to get done to finish up the engine were area triggers & a cinematics editor. And that's essentially what I've done.

Area triggers can now be placed down:

And used in the map events system as a trigger. Although I can't think of any reasons off the top of my head, I figured spending a little bit of extra effort to make so you can customize if pawns activate your trigger would be worthwhile:

These area triggers took slightly longer than I expected just because I had to figure out some math that I hadn't expected to with regards to placement; since aligning the corners to the exact position of a tile would make it in the center of a tile & would result in the trigger not covering the whole tile.

But once those were done I had the tools I needed to start on the cutscenes editor. But then it occurred to me - I don't remember using a cutscene editor when I made WarCraft 3 maps, how did they do it? So after looking it up it turns out they just used their map events system. This was perfect since it meant I just needed to add a ton of new actions to my existing events editor & I'd be able to support cutscenes/cinematics.

I wont list every new action I've added because it's quite a few, but it's all the essentials & a few extras for what I consider necessary to being able to do cutscenes. The second thing I had to do was make so map events could be triggered over time instead of just all at once so I added a "Wait" action. Right off the bat I knew that having a single "Enter Cinematic Mode" action which froze the player & enemies wouldn't be how I wanted to do it because freezing players & enemies could be their own useful actions, as well as the fact that some cutscenes might do things differently from each other so having a universal cinematics action would only limit how much people could do with the system. But having to create many actions every time you wanted to create a new cutscene like "Stop player movement", "Stop AI Logic", "Show cutscene bars", etc. would also be quite annoying. So my solution was to create "Action Templates":

And with all these new actions & a template system, we can now make cutscenes!

(Ignore the black bar not fully covering the ammo text lol)

So it's not quite a cutscene editor but an extension of existing tools which lets us make cutscenes.

I've also added "Starting Music" to the environment tab which is pretty self-explanatory.

And a map event action that lets you change the music:

The map editor is now also able to save your preferences, so if you toggle on/off lighting or anything else like that, the editor will remember for next time you boot it up.

An old remnant of when the engine was being made for an RTS was that a new map started with 4 active slots & each slot set to a different team. Now maps default to just 1 slot & all slots default to the same team:

Visuals & UI

You may have already noticed, the player & pawns have a new effect I named "Mickey Mouse Bounce".

I also updated the player UI to include "HP" next to the health bar:

And I've added support for camera shake when the player fires a weapon.

This can be adjusted in the weapon file:

Pawns

Pawn dialogue was a system created in the second game update published in March 19th 2021 when the engine was originally being designed for an RTS. I had actually forgotten this system existed until I wanted to work on sound effects for when pawns took damage, and to my surprise, found that such a system already existed under "Pawn Dialogue". The reason pawns weren't using this system was because the game was designed for an RTS & I didn't want random voice/text prompts giving away enemy positions so pawn dialogue only got played if it was by pawns who were on your team. And since in the current system, no pawns are on your team, they never played and eventually I forgot the system existed at all.

So I simply removed the requirement that pawn dialogue only be played by friendly pawn & I was able to add sounds for when pawns take damage without changing much else.

Closing Notes

Unity was released on June 8th, 2005, almost exactly 16 years ago. Yet there hasn't been a single moment where people thought that it was done & no more could be done to improve it whether that meant adding new features, removing old ones, or changing things in some other manner.

Similarly, since I'm mostly financially stable I find myself in a situation where I have all the time in the world to work on this engine and an infinite amount of things which I could be doing to make it better. I could work on it for the next two years. I could add network support to the voxel system, I could reprogram the texture & audio system to use a uniform file structure, I could redo the map editor UI to look more like a proper application, I could add a pawn editor so you could create new pawns without needing to change mod files. I could make it so much better. But I could also make a game.

At some point I have to say, the engine is ready, time to make a game.

The GMTK 2021 game jam came & passed where you had to make a game in 48 hours with the theme "Joined Together" and I participated with an entry. It was a lot of hard work to get it done on time and I worked 20 hours on the last day but I submitted it with 5 hours to spare.

During that messy & fast-paced development, I was reminded of what making simple games feels like & made it me think a lot about this project. It was so nice to be able to add something new without having to take into consideration & program the complexity that comes with:

1. How will it work with multiplayer / server-side authoritative model?
2. How will it work with mod support?
3. Will it require an addition to the map editor & if so, how will that be handled?

And it made me remember how less of a grind game development is when you keep things small. Mostly by not having the game be multiplayer which on its own can make even the most basic of tasks a chore & frustrating. That's not to say I regret making this engine, but it was a reminder that game development doesn't need to be as complex & long as I've been making it for myself.

In game development there's a term "Fail Faster". If I've learned anything from the last few projects it's that this may be the best advice there is for someone to learn. And maybe if I had earlier, I wouldn't have spent an entire year on projects that went nowhere. This September it'll officially be 2 years since my last published game. That's insane. That realization alone is what made me decide that this & the next update are the last updates on the engine before I make the game itself. This update I accomplished the two major things I wanted to get done, next update will be finishing off a bunch of small bits & whatever else I figure needs wrapping up. The update after that, the game will officially be under way. I don't know what it'll be about, who you'll be fighting, what weapons you'll be using. But I know it'll feel great to finally start on it.

I'm pretty hyped. This update & the next the engine will be done & I'll be doing almost nothing but working on the game. Figuring out where the game takes place, what the story is, adding levels, enemies, weapons. I'm getting so excited just thinking about it.

-Blake Gillman

Project Breach #6 - "The Demon Update"

 Project Breach #6
"The Demon Update"

The Transformation

Its been over a month since my last update and to say a lot has happened would be an fairly massive understatement. Between then and now I published a video titled "The Dangers Of Being Public" (link here), in which I said the following:

"I’m not opposed to pivoting a game's direction if I feel it’s necessary. With the upcoming demo for Project Breach, I feel that some people might misinterpret this. But hear me out. That's the whole point of a demo, to figure out what's fun, what works, and what doesn't. If it turns out that controlling pawns RimWorld style isn't fun for a tactical game, then I see nothing wrong with changing the game direction or even changing it entirely. The cool thing about building everything the way I have is that its all been built very generically, which means everything I've made applies to all sorts of different games. If I decided the game was to be an RPG or a survival horror, nothing I've made so far would really need to change to accommodate that. I have an armor system, I have a weapons system. Most games would benefit from these things. No work will have been lost. The map editor, weapons system, even enemy AI will be just as useful on any other project as it will be for this one."

I've often said "I've been making an engine not a game", but it was only while making that video I realized I had never said it online. Even builds of the game refer to it as "Perlinia Engine 3".

I kept working on the game but it wasn't feeling any closer to being fun to play. I kept thinking that a tactical game like this just doesn't work with RimWorld controls because you need more precise commanding than that. So I was faced with three options:

1. Scrap the engine: It sounds unbelievable but after 3 months of work and the game still feeling like it wasn't coming together, this was tempting. Also the fact that I was working on a 2D game instead of one of those beautiful 3D ones I see other indie developers posting on Reddit. But I knew in my heart that the problem wasn't the engine itself but rather that the idea just wasn't working, so I was dedicated to using this engine no matter what.
2. Redo the controls: Maybe "A Rainbow Six Siege style game but top-down with RimWorld style controls" just doesn't work. But perhaps with another control system it would?
3. Pivot the game: What if the player controlled a pawn like a normal person instead of an RTS? But leave all the other programming the same? It'd take me awhile to program all new systems for the player to use (I don't want them actually controlling a pawn, just controlling a body with systems similar to a pawn), but it just seems like it'd be more fun.

Any of these options was a major dedication that would require lots of work. But in the end, I went with #3 and I'm so glad that I did.

I started off creating a sort of horror-feeling map where you moved slowly and had very limited ammunition but I quickly realized that I wanted something more like a power fantasy.

I also realized that the existing weapons & enemies were definitely balanced for an RTS-style game and not for one where you were controlling a player. So I deleted all existing weapons and enemies, grabbed some demon textures I had laying around, and made a demon map. It was insane how well it instantly worked. It only took half a day to program a new AI script for the demons to use, a ranged demon enemy, a weapon for the player to use and a map to test it all on. And after that went so well, I worked on the map some more & added a melee demon enemy, and here we are:

Player Body

It took about half a month to program a body for the player to control that had all the same systems as a pawn like equipment, inventory, visuals, combat, movement, health, a new camera and more. I could've potentially just had the player control a pawn as they already existed, but I wanted the player to use completely separate systems so that way they could be changed & polished to better suit a player without effecting pawns. This has meant I've been able to more finely polish player movement & combat than what would otherwise be possible & I think that the positive feedback from testers has shown that it works.

New Pawn AI

I'm proud of how the tactical AI I programmed in the last update turned out. There are still some problems with it but overall it works really well. But enemies that hear gunshots, investigate, take cover, etc. just doesn't match a game about running around killing demons. I remember watching an Extra Credits video (link) about developing AI that best suits the game which sometimes just means having a few simple AI rather than 1 complex AI system. So I thought I'd do just that, after all, the enemies in DOOM felt fun to play against and they boiled down to "Wander in place, chase the player where we last saw them & attack the player when we have sight". So I created my own pawn brain to mimic those behaviors. 

They don't wander yet because after just implementing the last 2 they already felt more fun to play against with this new style of game. This less complex behavior also means they're easier for the CPU to handle. I didn't delete the old pawn brain so I or any modders can use it in the future, I'm glad I had the foresight to write the system in a way that supported multiple brain types!

UI

Most of this speaks for itself from the previous screenshots. There's a new player UI, weapon UI, and game cursor. But something I haven't shown yet is the engines new error screen:

Although not all errors are going to be so straightforward. Sometimes you just mistyped something in the mod file, in which case you'd get a generic JSON error. But at least this error screen tells you which script you made the mistake on:

Having all the games default content be its own mod has let me see things from the perspective of potential modders, so from pretty early on I've implemented systems for debugging what could go wrong when developing mods. For awhile those have been restricted to just being error messages that wrote to the console and I had every intention of keeping them that way & modders would just need to check the games player log to see what went wrong. But I decided that it wouldn't take long for me to implement something easier for modders to see what went wrong so I made the UI. It'll also serve handy in the future as being a popup for potential important errors that could occur in the game.

Campaigns

There's now a "Campaigns" file in mods so you can create your own custom campaigns too if you should choose.

Campaigns can be a series of maps related to each other (a story) or just a pack of different maps. All you have to do is have a campaign name, a thumbnail for it to use, and then all you have to do is write down what maps it'll include in order. When the player launches the game, any campaigns that are loaded from mods will check if they have a save file & if they don't, create one. That's right the engine now supports saving player data too!

Map Editor

The map editor is now a separate application from the main game. This was necessary in order to implement campaigns. The problem before was that since the map editor was a part of the game, you couldn't cache maps because you had to assume they might be edited. But reading all map files every time you need to access map data is extremely slow & led to opening the campaign screen taking ~5 seconds. That doesn't sound like much but consider there were only ~6 maps in the game at the time, as that number increases it'll get worse and worse. So now loaded maps are stored in RAM (cached) when the game is loaded so their data can be quickly accessed in-game.

Now, since I'm developing an engine more than a single game, I've almost always taken the harder option among many easier alternatives. The engine didn't need to have multiplayer which doubles development time, and I didn't need to make the multiplayer super secure by using the server-side authoritative model. It certainly didn't need to have mod support which also increased development time. I didn't need to go as far with mod support as I did, etc. But I did it anyway because this engine might be used for many games to come, and I want it to be the best it can be. I was presented with a similar dilemma when I wanted to add a win trigger to the level. It would've been easy to just program a collider that when the player touched it made the level end in victory & then to have the player place it in the map editor. But I'm so close to being done with most of the major engine features & being ready to focus on just the game, so why take the easy route now?

So, I've been working on a new major feature for the map editor: Map Events! I used to play a lot of WarCraft 3 when I was younger & loved using their map editor. The map editor included a map events system that let you program events without using code. Now I'm not going to make it quite as complex as theirs (I'm just a one-man team after all!) but having something like that in the map editor would let me & other map makers make truly unique levels with different events.

Each map event boils down to having triggers & actions. The event which every map will need to add will be when the player touches an area trigger to make the level end with a win. Even though the map events system is complete, I haven't finished area triggers yet which is a priority for my to-do list, so soon players will be able to complete levels.

This was a more time-consuming undertaking than I originally thought mostly with figuring out how to get the data to save & load to maps properly. But I'm glad I went the extra mile to do it.

Improved Pawn Performance

With this game pivot I saw a great opportunity for improving performance. About 45% of the games CPU usage was pawns trying to determine targets. That may sound like it's a really unoptimized calculation but it's in my opinion just a testament of how well optimized everything else is. It is after all having to do many line of sight checks which involve physics & can be expensive.

Because it was such a major part of performance, I wanted to do something about it but after optimizing it so much last update I wasn't sure where I could make any major difference. But then I realized because the game pivoted I could make so in a pawn file it was optional if pawns could target other pawns. After all, if a pawn solely exists to attack the player, why should it check if other pawns are targets? So for each pawn you can now configure if they're able to target other pawns or the player:

How much performance does this save? Well tests showed that when pawns were set to not try to target other pawns, their performance improved 256~161% depending on how many pawns the level contained. That makes even more sense when you consider that because each pawn must at the very least perform a distance check to every potential target & then do a line of sight check if they're close enough. That means the CPU usage of the pawns combat system scales exponentially with the number of potential targets. That also means reducing the number of potential targets exponentially improves performance!

This doesn't mean the engine can't handle pawns which target other pawns, it just means if you use pawns that do you'll just have to use less of them to get the same level of performance.

Closing Notes

This update was pretty massive & required a lot of work but it's all really coming together. I've been letting some of my close family & a few other people play test a test level I made, and the feedback has been more positive than the testing was for any other game I've made. This makes me think I really have something good going.

There are 2 big things I want to finish before focusing on game content, those being finishing area triggers & adding a cinematics editor. The area triggers shouldn't take much longer since I'm already pretty far with them, it's the cinematics editor that's going to be time consuming. I want the game to be able to have cutscenes. This will be useful not just for while you're playing a level but for the start & end of a level too. I haven't decided how I want to tackle this problem & how in-depth I want to go with such an editor so I have no idea how long it'll take, but it's another one of those things I know I don't need to make but that I feel the engine could really benefit from & since I'm so close to the end, I might as well uphold my record of going the extra mile.

That's it for the major changes, but trust me there were a lot more. You may have already noticed some of them as there were many visual improvements to both the game overall, combat, and effects. If you want to know them all then be sure to read the full notes in the summary at the bottom of the blog. And as always, thanks for reading!

-Blake Gillman