As I said in my last update, while I’d like to get back to the Unreal project I’ve spent the last year on, I really need to get a project done that’s smaller in scope.  In the interest of building my skill set, this smaller project is in Unity.  If you’ve followed the official Unity tutorials, this project should look pretty familiar right now.

What I’ve Got This Month

My starting point was this tutorial, which is a fairly straight-forward vertical-scrolling shoot-’em-up (or “shmup”, as the genre is often known).  The tutorial was a good way to brush up on Unity, and I dove in to another tutorial or two as well, but it also served an additional purpose.  A shmup is a good genre where I can work in 3D and still keep things simple; they’re 3D objects on a 2D plane, and animations usually consist of little more than rotating a model or moving it in 3D space, both of which are things that I can do easily as a coder with little artistic ability.  I’m aiming for something resembling an arcade game that might only be an hour long if you’re good at it, but it will be a reasonable challenge to beat it in one go.

So what am I changing about it?  Well, for starters, the tutorial is oriented vertically, and that might be your preference if you’re nostalgic for the arcade days, but let’s be realistic: most people have their screens oriented horizontally, so that’s how we’re going to get the most bang for our buck on screen real estate without requiring that players physically rotate their TVs or computer monitors.  You could make a case for a vertically-oriented game on phones, but I don’t think this game would be pleasant to control there, so…horizontal it is!  Beyond that, there’s one thing that always rubbed me the wrong way about shmups.  It’s fun to shoot things, but the “shoot” button has pretty much been superfluous; they rarely give you a reason to stop shooting.  I want players to make sure their shot is going to hit before they hit the fire button.  My solution is a combo meter.  The idea is that every X enemies or hazards destroyed (currently 10), your damage multiplier will increase by 1.  Currently, if you miss a shot, your damage multiplier resets to “x1” again, but that might be too harsh, and I’ll probably opt to decrement the damage multiplier for every missed shot instead.

You can see in the below video that I kept the basic asteroids and enemy ships from the tutorial, and they still explode in one shot; they have one hit point.  Meanwhile, the enemy ship that stops and rotates to fire at the player has five hit points.  Early on in the game, this should drive home the idea of the damage multiplier.  The first rotating turret ship takes 5 shots in a row to destroy, but once the damage multiplier gets to x2, it only takes 3.

There’s still time to come up with a title for the game, but I have given it some thought.  Some games are really good about conveying the objective of the game right in the title, and in the effort to come up with a memorable pun, I’m currently calling this game Combo Freighter.  (Get it?  It sounds kind of like “combo breaker”?  I know, I’m not super happy with it either.)

Challenges

The challenges this month so far have been A) trying not to overscope, and B) deciding which feature to work on next.  Relating to the “freighter” in Combo Freighter, I’ve thought about making enemies drop scrap metal when they explode, which would be the freight you’re hauling, so you could pick it up and add to your combo meter, similar to how you score extra points in Call of Duty’s “Kill Confirmed” game mode by collecting enemy dog tags.  I’m not sure if that’s a mechanic worth adding or not, but for every idea like that that I indulge, it could take me longer and longer to finish what’s supposed to be a small project.

What I Want to Have Done Next Month

Right now, because it’s how the tutorial did things, enemy types are selected randomly from a pool of prefabs, and it spawns these hazards over and over again until the player’s ship gets hit.  This leads to situations where my enemy turret ship, which has 5 times as much health as the asteroids and smaller ships, will spawn 3 times in one wave sometimes or not at all other times.  I’ll probably want to keep some level of randomness so that the game can’t be memorized, but I’ll need more control on the reigns of spawning enemies.  Among other things, I need to introduce concepts to the player at the beginning of the game one at a time, like how important it is to build a combo meter so you can take down enemies with more HP very quickly.  After I’ve done that, I’ll need a defensive maneuver so that players have an escape option in tricky situations.  Common examples include Cuphead’s dash, Star Fox’s barrel roll, 1942’s loop-the-loop, Contra: Hard Corps’ slide, and so on.  If I’ve still got time left in the month after those two things, I’ll scour the asset store for something I can start to turn into the game’s first boss.

If there’s one thing I learned this past month, it’s that using AI functionality in Unreal is a whole new ball game.  Unlike the usual blueprint functionality in Unreal, which looks like this:

AI instead uses behavior trees, which look like this:

Theoretically, everything that’s done in behavior trees can be done in blueprints, but I’m told that for organizational purposes, behavior trees are the way to go when it comes to AI scripting.  Maybe my behavior tree just needs more functionality before it will start to click for me, but right now it seems like I’d more easily be able to do what I want to do if I was coding it all up in blueprints.

What I’ve Got This Month

When walking into an invisible vision cone in front of the AI character, he’ll become aware of the player, arm himself, and turn and fire at said player.

As of right now, the win condition is still to be the last player standing, so if you walk in front of an AI, it’s a good way to make sure that he keeps firing at you until you’re dead.  At least right now, he won’t chase you though; he’ll only pivot in place and take the shot from there.

Challenges

It took forever to get the AI character to fire at the player more than once.  Currently there’s a bit of a hack in place to get it to work properly, and that’s because I hired a tutor to get to the bottom of the problem; it turns out that while there are plenty of tutorials for replication and AI, there aren’t many for putting them together, and there are even fewer mentions on the internet of the problems that can arise from that.  The hack that’s in place is temporary, and I took good notes on what I need to do to both follow conventional coding practices for behavior trees and avoid this problem in the future.  To get a bit more into the weeds on the problem, it was a result of making my AI character’s state depend on a replicated variable that was handled by the AI character controller instead of using the “blackboard”, which is how Unreal keeps track of state-based variables for AI behavior trees.

What I Want to Have Done Next Month

I knew from my first blog post here that this project’s scope is larger than it should be, but I’ve been surprised to see how long it’s taken me to even get this far into the project.  Seeing the road behind me and the road still ahead of me on this project, I’ve come to the conclusion that I definitely need to change gears to a much smaller project that I can certainly finish much more quickly, meaning that this current Unreal project will be tabled for at least a few months and hopefully not much longer than that.  This new, smaller project will be in Unity instead of Unreal.  I’m not unfamiliar with Unity, but the last time I went through Unity tutorials was several years ago, and I found out from a recent career fair that local game companies are really primarily interested in Unity experience.  I just did some brushing up the past week or two, and I’ve got an idea for a small project that I’m going to start right after I get back from PAX.  I’m not exactly keeping it a secret, but I’ll hold back on details until next month when I’ve got something to show.

I arbitrarily started keeping track of my hours spent on this project on February 23rd, 2017.  One year later, on February 23rd, 2018, I just happened to have spent exactly 365 hours on the project.  That means that I’m averaging an hour a day of work across the whole year.  Honestly, I’m happy it wasn’t less than that, especially given this past month at my day job, which found itself becoming a night job too.  After working 60+ hour weeks, I had little time remaining to work on my game still.  I didn’t get to make much progress, but I haven’t missed my monthly blog post yet, and I don’t plan on starting now.

What I’ve Got This Month

I managed to fix the cover animation so that the character’s back is always aligned with the angle of the wall.  That bug was coupled with a problem where, if you approached the wall at a steep enough angle, he would teleport straight through it when you try to take cover.  I found that the character’s back wasn’t lining up right due to the same code that makes him rotate toward where he’s aiming; I just had to add an extra condition in the code for when he was in cover so that it would ignore that code.  The bug where he teleports through the wall was just a result of copying the code from a tutorial.  It made enough sense to me as I followed the tutorial, but when trying to figure out this bug, I found that the author of the tutorial really chose a difficult way to set the character’s position against the wall.  He was looking for a position that was relative to the character, between him and the wall, which would sometimes result in putting the character in a space occupied by the wall itself, which would essentially cause the character to squeeze through the wall and stand on the other side of it.  Since my cover code finds a “hit” on the wall where line of sight makes contact with an object, my solution was just to pick a location a few centimeters away from the hit location and move the character there, using the wall as a reference point instead of the character.

Challenges

The other thing I worked on this past month was making all menus navigable by controller and keyboard, without a mouse.  Unfortunately, I found out that my previous drop-down combo box menu item for choosing the window mode is only operable by a mouse.  From what I could find in my research, the ability to programmatically expand the combo box is planned for a future version that’s still months away, but rather than waiting for it, I instead replaced with a label box that you can scroll left and right through.

What I Want to Have Done Next Month

Unfortunately, due to how much time my job has been eating up, my to-do for this upcoming month is just a slightly shorter list than it was last month.  I’d like to finish up the menu navigation by keyboard and controller and set the NPC to turn and attack the player once the player is inside the NPC’s vision code.  Additionally, after doing some research into animation best practices, I’d like to design (on paper) the UI flow of the menu screens for hosting or joining multiplayer lobbies.  Currently, the game just starts right away once you find a session.

I was making progress at a pretty decent pace this past month, but then I began to hit some snags.  My project at work was late for a key deliverable, so a lot of us had to work longer nights and weekends.  In fact, we still may not have made up this deficit, and we appear to still be behind, so I expect my productivity on my game to go down for this next month too.  Just to kick me while I’m down, my solid state drive in my desktop died too, so I had to re-install operating systems and development environments over the past two days.  Fortunately, there was no loss of data; just a corrupt boot sector.  I can safely recover all of my files and move them onto newer drives.  It just cost me time that I was already short on.

What I’ve Got This Month

I can now spawn a non-player character to shoot at using the T key or the Y button on a controller.  He doesn’t do much of anything yet, and if you load up his spawn point with enough corpses, he doesn’t even have clearance to create another clone, but you can do this about 5 or 6 times before the spawn point starts getting clogged.  It’s not much, but it’s a foundation for more NPC functionality going forward.

I also implemented some preliminary aim-down-sights code.  It’s simultaneously intuitive and challenging to aim with a pistol, at least in my opinion, due to the natural hand sway in the aiming animations I’m using.  This does come with a side effect though: aiming uphill or downhill (which doesn’t currently exist in my project but will likely have to at some point) doesn’t work out quite as well, since the camera is in a static position relative to the character’s center of mass.  I’ll have to add some kind of swivel for the camera in the future to handle this.

Challenges

Then there was the aim-down-sights code for the shotgun.  Ideally, there would be an animation where the character puts the stock of the gun against his shoulder and lines up his eye with the sights at the end of the barrel.  You know…aiming down sights.  Unfortunately, the closest animation I have for that is the rifle ADS animation.  This animation is missing the pump action that I have for shooting from the hip.  I haven’t implemented reloading functionality yet, but the pump action feels like it’s important for a pump action shotgun model.  In the meantime, what I did was move the camera closer to the sights of the shotgun but still behind the character’s back, which is a lot like the slight zoom that you get in other third-person shooters.  In my tests, this did work out better for making it a strong close-range weapon, which is the role that shotguns usually fill in games.  I’ll probably want to experiment with proper ADS for a shotgun once I can hunt down the animations for it though.

What I Want to Have Done Next Month

I’ve still got two features left over from last month that I hope to find the time to get done: fixing the cover animation so that the back is always flat against the wall and navigating into drop-down combo boxes (like the full screen settings widget) without using the mouse.  Above and beyond that, I’d like to have the NPC target and fire at the player characters as soon as they walk inside a vision code.  I’d also like to put in some time to investigate technical animation best practices, since I feel like I’m not properly using animation state machines and animation montages to their fullest, and it would be nice to make sure I’ve implemented my animations with proper code re-use.

Happy new year, everyone!  I hit most of my goals for the month, but that has an odd side effect; once I fix the thing I wanted to fix, I see a way in which it could be further improved, adding more tickets to my backlog for the next month.  I’m okay with that, but it does make me wonder how long I’ll be working on the initial mechanics to make them feel right.

What I’ve Got This Month

I managed to fix what was broken last month.  The cover animations now have transitions, and they blend together more or less how I want them to.

I also managed to fix the camera issue when taking cover.  If you’ll recall from earlier entries on this blog, Unreal has a “spring arm component” for the camera to rest on.  If there’s a wall in the way of the camera, the spring arm compresses and the camera gets closer to the player; when the player moves away from the wall, the spring extends again out to its maximum length.  It’s a pretty simple and smart solution for the camera issues that 3D games had 10-20 years ago, and it’s built right into Unreal’s starter template.  When putting the camera over the shoulder, I “fixed” the problem with walking through doorways by offsetting the entire spring arm.  This led to an issue where, when rotating the camera around cover, the spring arm would be on one side of the wall, and the character would be on another, leading to the wall obscuring your view, and the camera would be inside the building the player is taking cover against.  The solution I found instead is to move the location of the end of the spring arm that the camera is connected to, and the camera moves with it.  This way, the base of the spring arm is still connected to the player, and it should travel through doorways and into cover as expected.  I’ll still need to tweak this in the future so that you’re not staring directly at the character’s back when looking the direction the character is facing, but that’s a problem for another day.

I also implemented some initial controller support for the menus.  It mostly works, but the way I set up my inheritance, so that all menu screens share some common properties, Unreal took some issues with it and threw some warnings in my face.  I’ll implement the rest of the menu navigation code this upcoming month, after figuring out how to resolve those warnings.  For now, you can watch in amazement as I select menu options…without using my mouse!

Challenges

Those menus took far longer than I ever thought they would have, especially since there was a set of properties for Unreal widgets called “Navigation” in the right panel that I assumed would be the answer to all of my problems.  Instead I spent nearly twice as long on this feature as I’d hoped, basically having to code the individual navigation logic for each unique button on the screen, and I still need to figure out how to do things like expand a combo box without clicking on it, so that I can set the window mode in the settings menu.

That combined with the holidays at the end of December, and not appropriately budgeting my time around them, led to me not finding the time to implement an NPC character spawn yet.

What I Want to Have Done Next Month

Well, obviously, this upcoming month will first be spent finishing the NPC character spawn logic, and then I’ll finish up the rest of that menu code.  I also noticed a defect in my cover code where the character’s back won’t be flush against the wall if I come at the wall at an angle, so I’ll need to fix that too.  After all of that, I’d like to implement some aim-down-sights code so that you can more carefully aim your gun, even though I fully intend for that to have all the sway that would really come with trying to hold a weapon steady in the real world.

After a rough time trying to solve issues in my project, WordPress decided to delete the contents of this blog entry when I hit “publish”, so thanks for that WordPress; now I’m typing this a second time.

There are two words I really need to keep in mind going forward: regression testing.  At this stage in development, where I’m working primarily on the moment-to-moment movement mechanics and the resulting animations, changing one thing can affect any of the existing functionality very easily.  I won’t make the same mistake twice.

What I’ve Got This Month

You’ll recall from last month that I encountered an issue with multiple monitors in Linux with the Unreal Engine.  Well, thanks to some kind strangers in the Unreal Discord, I found some 100% guaranteed reproducible criteria for running into the bug.  Unfortunately, Epic doesn’t seem to care, because they haven’t responded after the initial “please provide more info” post.  If I get really annoyed with the issue, maybe I’ll read up on SDL and attempt to dive into the engine code to fix it, but even if I’m fortunate enough to be able to fix it, it would be a challenging, time-consuming endeavor.  In the meantime, I worked on more immediately visible things that my game could use.  While attempting to get around the above bug, I started messing with full screen graphics settings.  My project now has a default settings ini file that I can use to select whatever initial settings I want, and I implemented the foundation of a settings menu screen to adjust the window mode while in-game.

After that was taken care of, I adjusted the position of the strafing animations.  Thanks to some animation blending, the problem with these animations was a bit hard to spot, but it was a problem nonetheless.  I exported the strafing animations to Blender and moved them backward a bit so that the character doesn’t lunge forward when running around.  If you focus in on the vertical axis in the center of the screen, you can see in the below before-and-after that the character was initially more forward than the other animations it was using.

Challenges

Of course the fix that I found for the camera spring-arm last month was too good to be true.  I didn’t do my due diligence and do full regression tests, and now I’m paying for it.  It turns out that the adjustment of the spring-arm location alone resulted in some weird issues where it would end up on the other side of the wall that the player is taking cover against.  On top of that, an engine upgrade along the way affected the way the character is oriented along the wall while taking cover, which led to some strange behavior putting the character inside the wall.  I got that problem resolved at least, but with the limited time I reserved for the animation transitions from left to right or vice versa after Thanksgiving, I didn’t manage to get those transitions implemented before this update like I’d hoped.

What I Want to Have Done Next Month

I think it goes without saying that I’d like to fix that camera issue and the transition animations by next month.  While I was working on that this week, I noticed that the transition of the character snapping to cover should have a custom animation as well, so I’ll be working on that too.  After I clean up what I should have had done this month, I want my menu screens to be navigable by controller (right now, they’re mouse-only), and I want to spawn a dummy non-player character into the scene.  This will ultimately be a cooperative game, after all, so there needs to be a force to cooperate against.

I don’t like ending the month with more bugs (that I know of) than when I started, but it all needs to get done regardless, so I guess I’d better get to work.

 

I finally got through my partially completed earlier sprints and got up to date on what I had planned for this past month, so now I’m back on track.  I have a burndown chart that actually shows work completed for the month that it was intended for.  Whew, that took too long.  A little while back, I implemented an explicit win condition, simple as it may be, in the interest of bottom-up design so that whenever I cease development, my game will be something resembling a complete thought.  Looking forward to the immediate future, I want to polish up what I have so that it’s also an acceptable piece of software.

What I’ve Got This Month

The most visible change is that there’s now a shotgun alongside the previous handgun functionality.  The selected weapon can be toggled using either the 1 and 2 keys or the D-pad on the controller.  There’s a nice pellet spread illustrated in the video below where the gun fires a 9-pellet buckshot.  Without adhering to a particular brand of shotgun or buckshot, I took an approximation of real-life buckshot numbers to get as close to real life as possible.  It results in a spread that’s nowhere near as exaggerated as most video games, but it does mean that even at range, you’re more likely to hit your target, given that there are no cross hairs.  As of right now, since I still have absolutely nothing resembling a damage system, getting hit with any of the buckshot is instantly lethal.  Apart from a few other bug fixes, I also managed to fix the camera problem I had in a previous update, where the over-the-shoulder camera would be blinded by a wall when walking through a door frame.  I estimated this would take me hours to fix, but the first thing I tried actually ended up solving the problem, so I was done in 15 minutes.  Rather than moving the camera position, I move the spring-arm instead, which allows the camera to spring around the wall like it’s supposed to, so you never lose sight of what’s in front of you.

Challenges

In a word: polish.  When exporting my build last month, I noticed that the newer version of the engine that I upgraded to automatically defaults to full-screen, which didn’t happen before engine version 4.16.  Maybe this is a Linux-specific bug, but it causes some issues with multiple monitors.  In order to capture the video above, I launched the game, and the UI buttons to start up an instance of the game aren’t clickable, because the game thinks they’re on the left monitor; using GNOME’s window spread, I drag the game to the left monitor, alt+tab to a different window, alt+tab back to my game, and then drag the game back to the right monitor as desired.  I have no idea why this happens or why my workaround for it works, and I bet this issue sticks around for a while as I spend some time researching it.  Probably related is that clicking the mouse when the game is on my right monitor causes the player camera to spin around 180 degrees.  That makes about zero sense to me, but as a result, I’ve done my last two video demos with a controller so that I can actually use the fire button to shoot a bullet.

The shotgun and improved camera functionality were a breeze, but I had to spend an unexpectedly long time solving a problem with rotating the character left and right.  The issue didn’t make itself quite as apparent when strafing and rotating the character, but when standing still and rotating the character, there was a weird double-image of the character, but only on the client window that’s sending the input.  For instance, in a 3-player game, if player 1 is the server and both players 1 and 2 are looking at player 3 while player 3 is standing still and rotating, only player 3 will see this strange double image of their character.  If player 1 did the same thing, no one would see anything wrong.  For this reason, the best I could come up with is that it was some sort of network replication bug in my code, but I couldn’t find it.  Instead, I found a workaround where I refrain from using an RInterp (a rotation blend over time) when rotating the character.  I may want to revisit this issue in the future, but for now, I’m adequately sidestepping the problem with a weird sort of hack.  While testing this defect, I also noticed some strange white artifacts that appear on the borders of the screen while rotating quickly.  Once again, I can’t explain it.

These really weird issues don’t show up in my Google searches, and it bothers me that these problems are so very odd with no apparent solution.  I’m fine with my game not having anywhere near the number of features that it needs to actually be a game, but I’m not fine with the things I’ve got being so inexplicably buggy.

What I Want to Have Done Next Month

As a result of that multiple monitor bug, my first priority is to give the game adjustable and persistent resolution settings.  Maybe there’s some setting I can toy with that will fix all of this when the engine isn’t trying to do it for me automatically.  After that, I plan on adding a transition animation when taking cover and switching from left to right or from right to left, so that it fixes up that weird transition seen in last month’s video.  Then I’ll fix up those strafing animations in Blender so that the character is properly centered, and if there’s still time, I’ll make sure my UI buttons can be selected with a controller, since right now, they’re mouse-only.