Eat. Sleep. Indie. Portfolio

Professional Freelance Game Design

I recently decided to start keeping a devlog for my personal projects. Here you can find progress updates for my current projects and also check out any new mechanics I've been playing around with in my spare time.


August 6th


...and naplam barrels.


Little By Little

August 4th

I try to get at least a little bit of work done on this project every night, regardless of how dog-tired I am from my freelance schedule. Even if it's just 15 minutes before I call it a day, I feel it's important to be making continuous progress, and those little spurts of development really add up over time.

The last few nights I have been adding a few small things that have existed on my to-do list for a while now and I figured I would share before I take a meal break and then leverage my time off tonight to make some more progress in this project. First, I updated the pathfinding setup for zombies to leverage root motion, which has really opened up my options with regards to having unique zombies with unique movements. I don't have a lot of animations to choose from at the moment, but I will likely be picking up a new package or two from the asset store this week to make full use of this new configuration.

The next night was spent adding accuracy and range settings to firearms. Gone is the assault rifle that was as accurate as a sniper rifle at any distance, replaced instead with one that sprays bullets in a cone and provides a more realistic experience. This then led to the next night's work, which was the addition of a shotgun that sends off multiple projectiles with each shot and is set up to work best at close range and is capable of hitting multiple targets.

The short clip below features the test scene I have been using when working on updates, and it features some basic UI buttons that allow me to spawn and despawn zombies at will, both in the editor and in builds. You can see that there are two new movement animations being used for the zombies, and the original animation has been updated to use root motion as well. Shooting at the ground shows the cone pattern that the bullets take when exiting the barrel, and you can also see that the shotgun is capable of maiming multiple zombies with each shot but is also much more limited in it's range than the assault rifle is.

Several night's worth of dev sprints

I'll eventually put in the work to polish up my IK aiming system which will then lead to adding bullet trails, but for now I am happy with how these few small changes have significantly changed the overall gameplay. I'll also be expanding on my weapons system to allow for various types of rifles, shotguns, and possibly even some sniper rifles.


Drivers Test

July 29th

I spent some time after work last night making improvements to the driving mechanic I recently added. I've swapped out the original top-down view for a follow camera and made some small adjustements to the vehicle settings, but there is still a lot of room for improvement. I'm not exactly sure how this driving mechanic will play into the game, I just know it's a lot of fun and it serves as a great way to break up gameplay between zombie waves.

This configuration is known as 'Woo Hoo'


Zombie Roadkill

July 26th

I had built a small racing game during some off time between freelance gigs back in 2019. It was nothing special and was the result of a desire to play around with a new idea and the fact that Death Race was on in the background. I used some low poly packages from the asset store, set up some vehicles using wheel colliders, added some weapons, and the following was the result:

This old prototype ended up being the perfect vehicle controller for roadkillin' some zekes

I exported one of these vehicle prefabs and imported those assets into Bite Me, and after swapping out the meshes and making adjustments to colliders, I was off to a great start. I had tested hitting my zombies with a vehicle back in March, but the vehicle I was using back then was just a simple controller that drove the car forward indefinitely, it didn't even include steering; I had just placed the zombie in its path and then positioned the camera so that you were looking directly at the victim and the car would come rushing into the frame, hitting the zombie and sending his parts flying.

It needs work, but that will have to wait for another day

If you exclude the 20 minutes I spent playing Death Race as I took short trip down memory lane, the process to complete the work shown in the video above took about 15 minutes total. It actually took me longer to record these two videos, upload them to YouTube, and to writie this post than it did to get the controller setup, but I figured that I would provide some sort of update tonight given that it has been a while since I've shared anything here. I am still committed to finishing this game, it just isn't being worked on nearly as much as it has been in the past due to a busy freelancing schedule. I'll likely fix a couple of bugs remaining on my Trello list tonight before calling it a day, but I am happy that I remembered this little racing prototype I built last year given how well it seems it will work for my current project.


Thriller Party

July 19th

I extended my dismemberment mechanic to 32 more zombies last night and decided to have a little fun with them this afternoon. I ended up writing my own editor scripts to handle the setup of the ragdolls since the native Unity system resulted in colliders that weren't accurate enough for realistic results. I then did the same thing for each and every limb of each of the zombies, and now the time to go from an intact zombie model to a character that I can explode to pieces in-game is roughly 10 minutes total.

In the event you want the music that I can't add because of copyrights: Thriller Music Video

There are still more zombies at my disposal that are not set up yet, but most of them have some unique characteristics that will need some unique configurations. I'll be progressing forward with the 33 total I have in place now and will worry about the rest later on down the line. For now, my plan is to make each of these zombies even more unique with the use of accesories, animations, and more.



July 14th

This will likely be the last post on this devlog for a while, but before I set things aside for a bit I wanted to do something a little different. After weeks of having fragmented this guys skull, severing his limbs, and sending him sky-high via high-velocity explosives, I thought it would be a nice change of pace to give him some downtime. If nothing else it was good for a laugh when I needed a reason to.

In the event you want the music that I can't add because of copyrights: Thriller Music Video


Waves of Zekes

July 11th

I worked a one-day gig today so I haven't added anything new since last night, and I really didn't feel like programming once my contract was completed. But since I try to do something every day, I figured I'd take some gameplay footage of the work I had completed yesterday. This is the first video featuring the addition of weapon swapping as well as the concept layout I did for a small city block. One of my favorite parts of this video is the number of undead corpses that pile up as I progress, and knowing that every body part on the screen has rigidbodies attached just waiting for an explosive to send them flying - while still maintaining my target of 60 FPS - has me feeling like this project is going to turn out better than I'd originally hoped.

For now, I'm overdue for a movie and a good night's sleep.



July 10th

I'm about to wrap it up for the night since I have a short-term freelance agreement to fulfill tomorrow. This should leave me Sunday to put some ideas for expanding on today's work into place. The screenshot below is my first test of a game scene, which was a fun departure from the test scene I have been using up to this point.

I've placed some structures, roads, and a few destroyed vehicles to provide a play area, and they are laid out as a three-way intersection. Zombies are then spawned in a circle a set distance from the player and the zombies find their own path to the player-character from there. This setup provides alleyways and shortcuts that the zombie can take, such that some zombies come into the play area from the end of the street, while others will come into view with only a short distance between them and the player. I've also added code to increase the maximum speed of the zombies based on the current wave so that they get a little faster the longer you survive. There is no end-game yet, but this was a nice start of some actual gameplay and it certainly provided me with a new perspective on how this project could progress.

Bird's-eye view of the play area


Weapon Swapping

July 9th

Don't feel much like writing today, but I figured I'd share the latest addition: weapon swapping.

Where's the party?



July 8th

In keeping with tonight's theme, I present to you the RPG. I'll need to implement a better reload animation, but I'm very happy with how this turned out.

Insert your preferred comic book onomatopoeia here


Grenades Galore

July 8th

A comment left on my recent stress test video suggested that I may need more firepower for such a large a crowd. As a result, I'm proud to present to you the new grenade launcher; likely the fastest way to make short work of zekes available to your character.

Blowing up zombies has never been so easy!

I have also adjusted my camera settings so that the player character is more centered in the screen. This is much more in-line with other third-person shooters I've played, but I'm honestly not sure how much I like the change since the character takes up much of the important mid-screen area. I'll keep it as-is for now to see if it grows on me over time.

Unfortunately I am having some issues with very sluggish internet today so I am limited to posting GIFs only. Hopefuly this will be fixed soon.


Stress Test: Round II

July 6th

Nothing new here, just wanted to share gameplay footage of the stress test I just ran. Very happy with the results.


Player Character Polish

July 6th

I recently switched the grid texture for my testing scene's ground planes for a very specific reason: I knew doing so would eventually drive me nuts because it would highlight the issues with my player-controller that have sat on the back-burner for far too long. These issues were starting to become more noticeable in the gameplay footage I have been sharing, and during the sleeplessness that plagued me last night, I implemented remedies.

As you can see in the video below, there were several small issues. First, my character would snap when the player switched to moving in the opposite direction in which they were currently traveling. The animator would snap the value and this resulted in there being no transition between the two states. Second, the character was moving the same speed in every direction except backwards, which 1) didn't match the animations, and 2) was unrealistic. Third, the dodge mechanic I had quickly implemented the other day provided no benefit insofar as movement; the character rolled at the same speed - and therefore covered the same distance - as if they had just moved normally. Lastly, grenades were always thrown at the same angle and with the same amount of force, and I wanted more control over where the grenade would end up.

These items have all been fixed and polished to a point where they will no longer stick out like a sore thumb in gameplay footage. There's still room for improvement, but with so many aspects of this game still up in the air, I'm chalking this up to "good enough for now." I also played around with a new concept for the first game mode, which involves waves of zombies moving through the streets of a city, and I will be sharing this update after I've worked out some kinks.


Boss Battle Concept

July 4th

I decided to finally test a boss battle concept I've have on my to-do list for a while. This is essentially nothing more than a very, very large version of the zombie I have been using, and I'm simply simulating how gameplay might "feel" by avoiding hitting his limbs until I'm ready to show one getting severed. As with the other zombie, a shot to the leg results in death; this is placeholder until I have the time to work on my other concept, which will likely be tested the next time I take a day off that has an empty schedule.

I'll definitely need to add some IK targeting for his attacks, and I have several other animations to leverage; the goal here was to create a concept battle to test out some ideas and to see what would work and what wouldn't. I'll set this aside for now and focus on the core mechanics again, but it's nice to have this set up in a scene and ready to play for when I feel like playing around with ideas for how this battle will eventually play out.


Chain Reaction

July 3rd

Not much to say here, just celebrating the 4th of July in my own way.


Title Preview

July 2nd

I've been commissioned by a local bar to develop their website so I haven't done much insofar as updates for this project, but I did want to share that I ran into zero issues during recent tests in WebGL builds with 150+ zombies. I am expecting to be finished with this contract by the end of the weekend, after which I will focus on adding a few more gameplay mechanics to this demo before getting it up on this site.

For now, here's a prototype of a title screen I did. The nuclear explosion is way too bright and it definitely needs some TLC, but it's a start.


Skinned Zekes

July 1st

I've been adding some polish to the gameplay since my last post, focusing on the phsyics for explosions mostly, but also improving which inputs have priority over others. For instance, when playing the game I often found myself pressing the reload key while holding down the fire button, and my previous setup prevented reloading the weapon while attempting to fire; the same held true for throwing grenades and bait. With this update, you can now choose to interrupt reloading by throwing a grenade or some bait, and you can also reload your weapon without ever letting go of the fire button; this makes for much smoother and intuitive gameplay and gives you an out if you find yourself overwhelmed with zekes while in the midst of a reload.

I was way too tired to share last night's progress before bed, and if I'm being honest, I'm too tired to go into a lot of details now. I am going to need a bucket of coffee today.


Bait & Barrels

June 30th

I've wrapped up quite a few things with this round of updates, including bringing in the scripts responsible for baiting zombies from the earlier FPS version of this game. I've also implemented an ammo counter and a reload animation and am likely going to start adding some sound effects shortly. Everything is tying together quite nicely so far.


Zeke v Zekes

June 30th

Just a quick post showing a zombie main character. Still enjoying my morning coffee so I figured I'd start off with some simple tests. If nothing else, I'm happy knowing I can swap in just about any character and, with a little effort, get them working with my third-person controller.


Zeke Skeet

June 30th

I call this zeke skeet shooting because I had World War Z on in the background when I started working today. I've implemented grenades, which were taken straight from the first-person version of this I had done back in March, and have also added polish in various areas to give gameplay a smoother feel. There's still plenty of room for improvements, but I'm running out of gas and so it will have to wait until tomorrow.

Since the bullet trails were the only thing making it apparent that the AR was not pointing exactly where the cursor was, disabling them was a small concession to make to save me the trouble of setting up a more accurate ik controller. And, considering how many attempts it took me to write out that last sentence so it was intelligible, I do believe it is way past my bed time.

One quick note: I do prefer this version over the first-person perspective, and I think the fact that the camera is behind the player puts needed distance between it and the blood effects. I also think that tomorrow morning (or later this morning to be more accurate) I will put the player in control of a zombie because I'm easily amused.


Assorted Characters

June 29th

I have reworked the scope of my character controller to allow me to quickly swap between characters in the editor. I will be expanding on this system in the future, including a UI that will allow for a lot of options when customizing your avatar. I've also tested a WebGL build to ensure that there were no issues, and I expect to be doing that tomorrow.

I'll still need to expand on the IK system to ensure the rifle is always pointed correctly based on where the player is aiming, but that isn't a priority now since I can choose a character to work with and get it close enough to look halfway decent. I'll likely do that once every few videos to keep things interesting and to try and work out any problems that may arise from character customization later on in development.


Zombo II: First IK

June 29th

Smoothed out my animations and implemented some IK work to improve aiming. Very happy with the results here.


Rezzed Zombies

June 29th

I couldn't sleep last night, which led me to revisit an old side-project today, mostly because I woke up in the middle of the night in the mood to watch a horror movie and shooting zombies was a better fit than the mobile game I was working on. When it comes to my side-projects, I never feel guilty about changing gears or even abandoning them since the objective is to both expand my portfolio as well as my skill sets. I don't get that freedom with freelance work, so I take advantage of it when I'm off the clock and working on my own stuff. Basically, I wanted to shoot some zombies, so that's what I am doing until I no longer feel like shooting zombies anymore.

I've gone back to the third person view, partly to make sure that this version of the project (which has been collecting dust since the first week of March) updated to Unity 2019.4 without issue, and partly because I never finished my goal of a third-person controller before testing out the first-person version. Everything updated just fine, and it didn't take me long to swap in the animation pack I had bought a while ago but never leveraged in this particular game. It still needs polish but it's a step in the right direction. I'll be focusing on smoothing the transition between animations next, as well as some IK work for aiming.

I'm running at 60 FPS with 200 zombies and realtime shadows, and I'm fairly confident that the wall I will eventually hit will be the number of Animator components on screen at any given time. Not sure whether that will even be an issue in whatever demo I end up creating here, so I'm not going to worry about it until I make decisions about gameplay and, more importantly, the scene layout. For now, I'm just cramming the screen with as many walking dead as I can for the sake of carnage.


Placing Characters

June 24th

My schedule has changed recently, so I am back to work on my personal project for the time being. I've just finished up work on sending a request to the server for placing a character, then instantiating the appropriate prefab when the response is received. It won't take much more work to incorporate the mechanics for attacking the tower that I finished earlier, as well as spawning characters placed by the opponent in the appropriate spot on the upper-half of the arena.

My next post should be a gameplay video of my first match, or at least the barebones mechanics that are required for a match.


WebGL Royale

June 24th

My meeting for this afternoon was postponed until a later date, so while I am waiting for the next, I've been progressing with this project. I've just finished setting up the node that hosts my MMO demo to also host the demo for this game. I may move the project onto its own node in the future, but for now I wasn't in the mood to worry about firewalls and what-not. Everything is working as expected for the WebGL demo, and I've gone so far as to test pre-match client-syncing of a WebGL build vs my Android phone. I will break out my Mac later this week to test iOS builds as well, but given past experiences, I don't foresee any issues with this demo working as-is for Windows, Linux, Mac, iOS, Android and WebGL, and it is 100% cross-platform compatible: any account that works for any build will work for any other build, and progress is shared regardless of how you decide to play.

Beyond that, I have made a few improvements to the deck management interface. Accounts now separate the cards they own based on whether they are currently selected for use in the deck, and I'll be adding buttons soon to allow moving cards in/out of the deck as well. Lastly, I've added greyed-out versions of any cards the player has yet to find, and have expanded the design of my database in preparation for when new cards are earned via treasure chests.

For anyone wondering how I am building this as quickly as I am, the answer is fairly simple: this is a gutted version of my MMO framework with the MMO API removed and the inventory modified to hold cards rather than items; this framework is the result of years and years of feature additions and updates, and I've scoped it intentionally so that it is pliable. On top of that, I began with a detailed GDD that I wrote myself, and this is also essentially a clone of Clash Royale, so I'm saving a lot of time not having to bounce back and forth between Trello lists.

It's time for another cup of coffee and to wrap up the basics of deck management so that I can focus on actual gameplay again.


Syncing Clients

June 24th

I finally found some free time between last night and this morning to get a bit more done on this project. After running some tests with my Android device, I realized that my clients were not always syncing up properly before the start of the match, so I've gone and reworked a fair amount of the server-side scripts to remedy that. The issue was fairly simple, but I didn't want to slap a quick fix on it and then realize later on that there were still some issues.

The client is about as dumb as it possibly can be now, and is essentially sending messages to say that it is ready for the next stage of the match, and the server is receiving these messages from both clients and only broadcasting that they move to the next stage once messages have been received by both. The result is that, when my Android device takes ~2 seconds to load the game scene while in a match with my dev machine (which instantaneously loads the game scene), the faster of the two is now correctly waiting patiently for the "okay" to move on to the next stage. From there, the server sends the countdown update every second, sends the "start match" message once the countdown reaches zero, and then begins the process of sending the clients their current elixir value after that.

I have also added some UI elements for tracking the current health of the towers and castle, and have damage methods in place for updating these UI elements when needed. The damage is currently only working client-side, but it will be a fairly easy swap so that server messages are the only thing that affects their health; these updates will work much like the current elixir system works.

Since it's still morning and I am still drinking coffee, I think I'll turn my efforts towards the deck management system to give my brain some more time to fully wake up. To make things easier when it comes time to move back to the actual gameplay, I'm going to decide on 8 characters that every player will start with, and even though the deck management will be "available", without the ability to earn new cards yet, they'll essentially be stuck with they get at the start. This means I can focus on getting everything working while only needing to replicate the work for 8 characters, versus the 36 cards/characters I'll eventually have available.

It feels like I'm rambling now, and rambling doesn't accomplish much, so I'm going to get back to work. I don't know what a world without coffee would be like, and I hope I never have to find out.


Ogres and Rogues

June 22nd

One of my favorite cards to play in Clash Royale is the Giant; his determination in reaching his goal despite anything standing in his way - often times to his own plight - is something I think we can all relate to. Naturally, I started with a similar character for my own project. The GIF below is some quick testing I've done regarding pathfinding and character animations featuring the Ogre (giant equivalent) and the Rogue. I'll definitely need a walking animation that is a bit more menacing for the Rogue, but I'm happy with the layout and progress I've made so far.

The next step will be to program the mechanic for dragging a card onto the game board to place the character. Once that is in order, I'll put the authoritative server in between the client's request to place said character and the end-result, allowing the server to determine whether it is an acceptable location as well as if the player has the required elixir. This will prevent any client hacks and also allow me to broadcast these events to the opponent, thereby keeping both clients in sync and ensuring that all the data being displayed is accurate.


Clash Royale-ish

June 21st

It's been too long since I've posted anything to this devlog, so I've decided to share some progress on a new personal project. The goal here was to take an existing game, create a game design document from it, and then recreate said game in Unity with the hope of providing some insight into the process I follow when working from a client's GDD.

The game I have decided to use as an example is Clash Royale, a popular multiplayer startegy game designed for the mobile market. I've approached this project as though the concept had not been proven by Supercell already, and will be using placeholder assets and Unity's native UI elements in order to focus on programming. As usual - and while Unity's multiplayer future seems as lost as any of their other features - I am using SmartFox server here, although it's feature-set may be a bit overkill here. Regardless, I figured I might as well program the server to be fully authoritative and leverage as much of SmartFox's grandiose list of features to my advantage, even knowing full well that nothing will likely ever come from this excercise.

The end goal here will be to have another WebGL demo available to play for free on my portfolio as well as having an example APK ready to share with clients if need be. So far it's been mostly setup, laying out the UI, and a ton of back-end preparation. Having finished up the process that syncs clients up to the moment of the start of the match last night, my goal today/tonight will be to implement core gameplay mechanics. For the interim, here are some screenshots of my less-than-stellar progress.



March 11th

I've been spending a lot of time on project clean-up today, mostly removing the parts of asset packages that I won't need while keeping the parts I do need in tact. This work is being done in preparation for the switch from the demo version of this FPS package to the full-version.

While working I decided to whip up some zombie bait, which is really just an extension of the grenade system minus the explosion. When the bait's trigger comes into contact with a zombie, the zombie will chase down the bait until the bait is gone, which is currently set to a 15 second timer. I'll likely expand on this in the future, but for now it serves as a nice way to get out of a jam quickly.

Come get your vittles!

Safety First

March 10th

One of the four new zombies I've added was selected specifically for one of its features, in that the road worker came complete with a helmet. In fact, there are numerous attachments for these zombies that came with the asset package, but I wanted to start with this one since the goal was to incorporate the helmet into the gameplay, and both the mesh of the zombie and the helmet were going to be fairly easy to work with given their simpler geometry.

This zombie has been set up so that his helmet deflects the first several headshots, meaning the player must maintain consistent fire for a period of time to land a single headshot on any road worker zombies. I am leaning heavily towards counting headshots as some sort of in-game currency, most likely for earning skill points that can be spent on things like auto-reload, reload speed, etc. The idea here is that the more difficult headshots help you progress quicker, but the time required to land them successively may put the player in a position where they need to mow down an approacing group of undead quickly, at which point they resort to body shots for a quick and easy way to make some room. This puts them in a position of constantly managing whether they need quick kills to survive or whether they have time to favor precision for the sake of earning headshots that hold more value. This is not set in stone by any means, but it is a feature that I think would work really well with the current game mechanics.


New Zombies to Torture!

March 10th

After yesterday's devlog update I decided that I really needed to put my pipeline through some tests to ensure that I could, in fact, extend all of the work done thus far to other zombies. The package I purchased includes about 50 unique zombie meshes to work with, and while I likely won't be using every single one of them, I do intend to use most. I decided that I'd bump up the project to include a total of 5 unique zombie meshes total for now, and proceeded fire up Blender to begin the painstaking dismemberment process of not only adding in the new ones, but also to run the prisoner (that was alraedy setup and working) through the refined process in an effort to maintain consistency.

I started this work late last night and did not finish until shortly after 5 AM this morning. I estimate the total time to go from package-asset to a zombie I can dismember in-game to come in at around 90 minutes per zombie. I not only need to cut the mesh up into pieces, but I then need to create duplicates of all of the various parts, each separate from the original mesh, and then rig up colliders and custom joints in Unity; these sections are what falls to the ground when the original limb is hidden upon severing. I enjoy tedious work when I'm in the mood to half-watch some Mythbusters episodes while I work on a side project, so it's very likely that new zombies will be added intermittently as I progress.

The process involves spearating out the limbs and head from the torso and exporting that to Unity for ragdoll setup. The torso and limbs all need to have any open gaps that result from this dismemberment filled in, and from there I usually extrude out a small piece of bone and then re-map UVs to appropriate colors. I then duplicate every section and remote it from the rig entirely; these are then setup with their own armatures before being exported so that the arms and legs will bend in a realistic way when colliding with other objects in the game itself. When done, I have one complete, rigged zombie with limbs separated from the torso as well as a rigged mesh for each individual limb. The result is a zombie that can have any of its limbs hidden in an instant and a physics-ready limb for each arm and leg, and when these are all combined and working in tandem with my scripts, you end up with a zombie that can be de-limbed with just about anything. If you're like me then you may be thinking "chainsaw", and yes, I would absolutely love to add a chainsaw melee weapon in the future.

This isn't how I would normally tackle this problem since I could likely get fairly decent results via code alone, but the goal here is to become increasingly comfortable with Blender so as to round out my game development process. I enjoy just about every aspect of game development, but there are still a ton of areas that I need a lot of practice with, and becoming more familiar with Blender 2.8 is at the top of my list. There have been a lot of freelance gigs in the past where my (admittedly limited) knowledge of Blender was of great use to my client, and as a full-time freelancer I am always looking for ways that I can expand my skill sets and deliver more for my clients than they might expect from me.

Before (left) and after (right)

Exploding Barrels

March 9th

I've been adding polish here and there to my setup, and recently incorporated exploding barrels into the mix. Below is a video of current progress; there's not much to say here since most of this work has been spent tweaking scripts here and there for a better overall feel to the gameplay. I did also implement randomly selected skins for when the zombies spawn, which will be extended to the various other zombie meshes once I get around to them. I'm not entirely sure where I'm going with this yet, but I like the direction it is heading.


FPS Update

March 8th

After taking a look at recent gameplay video early this morning, I decided to switch things up a bit. I wasn't sure that third-person perspective was going to suit the game as well as a first-person one, and then I remembered a package I had seen on the Asset Store a while back but never took the time to play around with. So, after finishing a meeting I had scheduled earlier today, I grabbed the demo and went to work. The video below is the result of what I would call my first-draft, brute-force, "get it to work no matter how messy just so I can play it" version. Granted, I did start this project so that I would end up with an improved third-person controller, but I can't help but feel that this perspective fits the zombie-carnage-filled type of game I set out to create. This project has taken on a life of its own.

Implementation went fairly smooth, and it didn't take me too long to get everything setup in a way that suited this project and my workflow; I basically swapped in cInput controls and then played around with their code responsible for bullet physics until I had the desired result, then did the same for the grenade. The assault rifle is as accurate as a sniper rifle at the moment, but I'll be adding some updates to send off bullets with just a bit of randomness, at least for the assault rifle. I will definintely be purchasing the full version of this first-person package in the near future and, given that most of my work thus far has been purely on the zombies reactions to weapon-fire and explosions, nearly all of my earlier work is in tact and seems to be working in tandem with this new package without issue.


First Vehicle Test

March 8th

I'm in the process of implementing yet another way to mess with these zombies, this time in the form of a speeding vehicle. Same ol' song and dance as before; this is essentially an explosive device without any explosion effects slightly modified for when colliding with the buggy. It'll need some polish for sure, but I'll worry about that after I get a mechanic for entering/exiting the vehicle in place - and the transition to vehicle controls after that.

This is a short one. Time to get back to it.



March 7th

My zombie torturing adventure continues as I've just completed the first stages of triggered explosives. This setup was fairly easy to do since I scoped for it when programming bullet collisions; I'm essentially using an overlap sphere to detect zombies within range, ragodlling them the same as I do when they are shot in the head, and applying explosive forces to send everything flying. Add in a particle system prefab that came with the Synty package, and I'm much closer to my vision of maximum zombie carnage.

It likely seems as though I'm all over the place with this, at least in regards of what I say I'll work on next versus what actually gets done, and that's because I am all over the place; I'm pretty much working on whatever keeps me motivated at the time as I play around with ideas and test some mechanics. I'll make get a second zombie rigged up for these as I've said I would, just as soon as I hit point where I'm in the mood for some Blender work. Until then, I'm in the mood to program chaos.

As a wise Mythbuster once said: "When in doubt, C4."

First Stress Test

March 7th

I figured I'd share results from my first stress test; I saw now reduction in my framerate of 60 FPS until 200 zombies were in the scene. The video below was recorded with 100 zombies total (to ensure vsync while recording gameplay), all ready and waiting to be ragdolled and dismembered, and all casting real-time shadows while avoiding obstacles and each other. This project is already performing better than I had expected, even at this stage, and there are a ton of places to improve performance when the time comes for some optimzation.

Lastly, I think I will tentatively and affectionately refer to this project as "Bite Me".


First Gameplay Test

March 7th

I spent the remainder of my day yesterday updating this portfolio site so that it is more mobile-friendly, and with that completed I decided to incorporate some pathfinding into this zombie shooter. Below is the first gameplay video, and while it still looks very odd that the character isn't even holding a weapon, I'm glad to see that all this work is coming together in a way that is fun to play. I'm really enjoying instances in which zombies are clustered together and I can easily land multiple headshots one after the other.

The pathfinding system does incorporate local avoidance, which allows for large clusters of zombies that will never share the same space. I'll likely do some quick stress tests soon to see just how many zombies I can get away with while my scene is still incredibly simplistic, and after that will likely swap in a low-poly terrain so that the zombies are not always on the same vertical plane. I'll also add in some more props and obstacles to make this little prototype feel a bit more like a game-in-progress.

Later tonight I am hoping to put in some time playing around with different animations so that I can add a weapon to the player character and have them move properly when aiming. The setup featured in this video is what will eventually be the pistol; the assault rifle and rocket launcher that I have planned will step up the carnage expontentially.



March 6th

The final steps for dismemberment have been completed and I am very happy with the results. It will need some polish in the future, but I am more than confident with pushing forward on this game's design. I'm going to replicate these results for a second zombie model just to solidify the process in my mind before I turn my attention to other things. I expect this second zombie to come together much faster than the first now that I have a pipeline in place, and I'll likely choose another character with a relatively simple mesh to work with again before expanding this system to work with all the zombies I have at my disposal.

I am admittedly anxious to begin animating my player character so that they are holding a gun and aim properly, but at some point between setting up zombie #2 and animating for weapons I am going to give this portfolio site a much-needed layout update to make it more mobile-compatible. This is something I have been putting off for years, but given that 50% of my web traffic is now via mobile devices, it's way past time I got this done. I haven't decided just how much overhaul I am aiming for yet, but the more I consider the fact that this website hasn't been updated properly in several years, the more I feel like this should have been done months ago.

So, pending updates to this website, this project is (very) temporarily on hold for the next few hours at the least. It's not something I'm particulary excited about, but it will definitely be worth the effort when it's done.

A bit o' zombie surgery

Spare Parts

March 6th

I have just completed the next-to-last step in this process by creating jointed limbs that interact with the game world via colliders and rigidbodies. These are the sections of the zombie's body that I will be spawning in place of the renderers that are currently being disabled when shot. The idea is to simply swap in one of these prefabs as I hide the limb and then let physics take over, and with any luck the end result will equate to the player being able to shoot off whatever limbs they choose before finishing off the zombie with a headshot.

So far things are going better than expected, and I am really happy with the results I've gotten thus far and also feel confident that the end result is going to be very close to my original plan. There was a point recently during development in which I created a script named "SeveredLimb" and couldn't help but chuckle a bit at the idea of programming such a thing; I've programmed aliens with lasers, warriors with swords, and hunters with bows, but I've never programmed a game that was deliberately gory - certainly not one that was comical and involved prep work that is akin to amputating zombies in Blender. I am honestly not sure what I can do with the mechanic of leaving a zombie limbless beyond amusement for amusement's sake, but maybe there is a way to tie the mechanic into game progression more by providing rewards for de-limbing zombies, or by having a timed combo system in which targeting limbs would net you a higher combo level per each zombie. It's definitely something I will keep simmering in the back of my mind as I progress, since it would make all the work I've put into this little side project worth it and then some.

I'll likely work for a bit longer and get some prep work in place to lighten the load for tomorrow. I am very much looking forward to getting this working over my morning coffee, and with any luck I'll have some limb-severing gameplay video to share by day's end.

Inspired by all of the DOTS videos I see on Reddit, even though this isn't using DOTS

Vanishing Limbs

March 5th

I decided to go back into Blender and get a bit more work done on the zombie mesh, mainly adding polys to the severed joints for bones and to select a more appropriate red color for the flesh. I would eventually like to go back in and split the arms and legs in half again at the elbow and knee, but for now I'm going to move forward with this to see how everything comes together.

The next step was to start detecting when the player shoots a limb versus the head, and from there sever the limb so that it falls to the ground. The first half of this process was fairly easy given that I am just hiding the renderer of the hit limb, which will be "replaced" with a separate prefab of just the arm itself. From there I will likely start with severing the arms first since I'll eventually want the zombie to have more of a reaction when they lose a leg, at which point they may need to stand differently, they may fall to the ground, etc. I have animations ready for crawling zombies, the lingering question is how to go from a zombie with both legs to one that is now on the floor and crawling towards the player, and to do so in a way that looks believable. I think watching a few zombie movies while I work tonight is definitely in order. Maybe some World War Z followed by Dawn of the Dead, finishing up with 28 Days and 28 Weeks Later.

I'll admit, the process of updating this devlog is taking about as much time as working on the project itself is taking, but I'm enjoying what is a rare opportunity for me to write in such a way that I don't need to worry about whether it compiles correctly or not. I'm sure an English major would be able to turn my writing red with ink easily, but I'm finding the process of sharing progress to be enjoyable. I'm definitely glad I decided to write about the entire process, even if it means it will take me twice as long to reach the finish line.

Progress is progress

Fragmented Skulls

March 5th

Moving on to adding an effect for bits of skull, I've opted to hold off on creating blood that pools on the floor since after finishing skull fragments, I'm already feeling I need a break from the tedium of particle effects. What I've done for skull explosions is to take the original head mesh and separate a few individual pieces. I then extruded these faces to give the mesh three dimensions and finished up by mapping my verticies to skull and blood colors where appropriate.

With these new meshes imported into Unity, I once again duplicated the blood splatter effect that Synty was kind enough to include in their package and made the necessary tweaks. Gone are billboard particles, replaced instead with my skull fragment meshes. A few changes to initial speed and spawn counts, etc. and I had a decent-looking head explosion in the works. Having done a few quick playthroughs I am already liking how this plays, in no small part due to skull fragments occasionally flying at the camera, which provides a bit more immersion as you walk around and rid this scene of the undead.

In hindsight, I should have selected more than one face when separating these meshes out to give the fragments a bit more shape, but that's a polish item that will likely sit in my backlog for a while. With my headshot mechanics in place enough to continue, it's time to move on to arms and legs.


Poppin' Heads

March 5th

Alright, headshots are in place and the zombies head disappears. It's looking pretty decent already if I may say so myself, and as satisfying as the disappearing head feels when you land a headshot, I want carnage. I want a head that explodes into pieces and gives me that over-the-top horror movie effect of cranium that was filled with black powder. I figured I would let ideas for how to accomplish this rattle around in the ol' noggin' while I added a simpler form of satisfying feedback: blood streaming into the sky from the neck.

The Synty package I am using came with a blood splatter particle system included but it did not contain one for the effect I am trying to create, so I duplicated their splatter effect and made some adjustments to how and when the particles spawn. I added some code to stop the effect after a random amount of time, and the results are already looking pretty decent. Just one thing missing: I want blood to pool on the floor for a bit so that when the player has taken out numerous zombies and bodies lie strewn about the scene, there will be plenty of red covering the floor from all the carnage.

Readers with a keen eye may have noticed in my eariler post that my Animator -> Rigidbody transition was not working properly in the gif I shared, and that has been fixed as well. This was just an oversight on my part - mostly due to the number of hours I have been working recently - in which I forgot to swap the isKinimatic state of my ragdoll's rigidbodies when the headshot occurred. This fix, coupled with the neck now spewing blood as though this were a Tarantino film, and I feel like my vision of carnage and mayhem is really starting to come together.

Before (left) and after (right)

Zombie Surgery

March 5th

I decided to choose one zombie to start working with and opted for the prisoner since its mesh seemed the simplest to work with out of all of my options. I have never had much luck importing rigged models from Asset Store packages into Blender while keeping the weighting and rig in tact, so the first step was to redo the rig and then export it back to Unity for testing. I wanted to ensure that there were no differences between the way my rigged version of the zombie behaved versus the one that is included in the package and was already working with my mechanics.

With that accomplished, the next step was to start dividing the zombie into sections. Given that I've never done dismemberment using this method before, I opted for the obvious: head, two arms, two legs, and a torso. If it works out well I will likely expand on this setup considerably since the ultimate goal with this project is fast-paced zombie mayhem with ridiculous weapons that result in zombie parts flying everywhere. Separating everything from the torso was fairly easy to do and was also right inside my wheelhouse as far as my skill sets with Blender.

I basically just separated the limbs and the head and then capped any open areas created as a result. For now I've just mapped these new caps to render as a randomly chosen red; I'll play around with details once I've got the limb-severing system in place and I can see a rough outline of the end-result. With my character now cut up into pieces, I exported back into Unity, setup the ragdoll and other components, and again tested to ensure my results were the same as they were with the original zombie mesh. With that done, I immediately felt as though this process was going to be well worth my time. I am already enjoying the gameplay and, when considering how it is already coming together along with what I have planned for it, I think this could end up being an entertaining demo.

For now, it's time for some shut-eye.


Blood & Ragdolls

March 4th

I wanted a break from the complexity of my WebGL MMO project so I decided to work on something simpler that I would hopefully be able to use time and time again in the future. I quickly realized that if I focused on my third-person controller, whatever updates I made could be easily implemented into the MMO once they were complete and I'd have a third-person controller package that worked exactly the way I wanted at my disposal for any future projects. I enjoy working with Synty assets for a lot of reasons, one of which is that, although I am capable of creating low-poly meshes, I am not capable of creating them at the quality that they do. I'd like to get to that point one day but for now I find working with their assets in Blender to be both a huge inspiration as well as a great learning tool.

So, I've set out to create another WebGL demo for my portfolio using a more-polished version of my third-person controller; the goal here (beyond having another demo for potential clients to play) is to improve my skills in Blender and to leverage the program to do some things that I would normally do via code; specifically, I'll be shooting the heads and limbs off of zombies, and rather than writing code to separate the mesh and cap any open areas, I'm going to work with the meshes themselves.

I've added a bit more polish to my third-person camera so that the aiming mechanic feels more natural as well as removing the slight jitter I was experiencing in complex areas of certain scenes. I've also imported and setup my favorite input management package - cInput - and was very happy to find out that once I had my XBox controller configured correctly in the editor, it worked with WebGL builds right out of the box. I was honestly expecting some resistance there, but the ease of implementation allowed me to progress forward knowing that if I created a decent zombie shooter, visitors on this website would be able to grab a controller and play it directly in the browser.

For my money, there's no better place to start when making a zombie shooter than immediately implementing blood effects and ragdoll deaths. Things like blood effects and ragdolls really help make the shooting mechanic feel much more tactile, and this in turn makes the prototype feel like a game long before there is anything resembling progression, which subsequently makes play-testing over and over again a much less tedious endeavor right off the bat.

Nothing too fancy here - in fact, my player character does nothing but sit idle while aiming - but it's a working mechanic with acceptable results. Time to move onto exploding heads and dismembered limbs.