• entries
  • comments
  • views

About this blog

Fidelum Games Development Journal

Entries in this blog



Originally posted on FidelumGames.wordpress.com

A few months back I was looking for projects that would be in need of a composer. Jake did contact me via GameDev.net and asked if I’d be interested doing musics to his game and since I’ve always been a huge fan of fantasy RPGs decision wasn’t really that hard to make, even though there was quite a lot going on at that time (I was offered six game music projects at that time, I had quite recently started in a new job ect.). Style of the game and the musics just seemed right for my style.

Okay. Then who actually I am?

My name is Mika Pilke. A Finnish hobbyist musician who has been playing around with music for about 20 years now. I’ve been writing music for years, but just lately I’ve felt that my material and quality of the mix have archieved the level where it is possible to actually consider accepting composing projects. I don’t really know how many songs I’ve written totally, but total number is probably somewhere between 150-200. I have also played in several bands too (mostly as a lead guitarist and/or as a singer), but I guess I never truly found comfort in playing live which is a chaotic moment where your senses are dampened and you can barely hear anything, let alone the small details (which I do find important). I’ve always felt that making music all alone, at night, in a dark room is what I actually love the most. It’s intensity, 100% focus and the flow.



Nowadays (and at this level) the magic happens mostly by using virtual instruments. I use Reaper as a DAW, a midi-keyboard (Axiom61) and various VST/VSTi/VST3/VST3i instruments from various companies (like Native Instruments, Steinberg and Spitfire Audio).
But sometimes it also might add some extra punch to actually record something from the real world too, so I also have Shure Beta 58A, Rode NT1-A and Zoom H1 for recording sound. M-Audio Fast Track Pro serves mostly as an audio interface (and Behringer U-Phoria UM2 as for backup, or for recording sessions that are located elsewhere and you’re too lazy to unconnect M-Audio from the computer). In the end it’s quite a simple, but somewhat capable setup. And still somewhat cost effective too, even though software is not cheap.


What is the meaning of music?

Music and soundscapes are easily undervalued and even forgotten elements, yet they have (mostly passively) a strong impact to viewers/gamers emotions. I believe music is actually one of the key elements that will define the game’s identity and it has a strong purpose in creating memorable moments and atmospheres. I would even go as far to say that all the visual content is the body but music makes the very soul of the game.
When these two elements are combined, sometimes there is a change to create something truly unforgettable. And of course sometimes a good storyline helps too ect. 🙂
But after all, how many games that have become a legend, has a bad soundtrack (if there are any, that is)?

So there are quite a lot reasons to take music writing seriously. It’s a job that comes with a great responsibility and it’s a matter I wish to handle with a proper care and passion.

One of my creations for The Wayfarer:


Mika Pilke

PS. Check out Mika's YouTube channel!


Originally posted on fidelumgames.wordpress.com

Strap yourselves in. This is going to be a big one. And hang in there. There’s some good media part way through.


Since my last post, I let myself get a bit out of hand as far as staying disciplined goes.

I had made some decent progress, and had some cool things to show off, but most of what I was showing was only superficial progress. The things I’m talking about are environments, enemies (actual animated models, not just cubes) and some UI stuff.

The problem with these things is that they were all parts of incomplete systems.

In one of my earlier posts, I wrote:


“…I decided that, although the game is still in a super early state, I owed it to myself to add a bit of polish and replace my cubes with one of the assets I acquired.”

This was a mistake, and led to me falling back into my old habits of sitting down to a development session and asking myself, “what do I want to work on today? What would be cool?”

The result of this workflow was getting a given feature ‘good enough’, making it look cool, and then moving on to something else with the intention of returning to the feature I had just ‘completed’ in order to finalize and polish it.

The problem with this was that I would often go too long before returning to that feature (if I did at all), and forget the mental model required to finish the system properly. I basically wound up with a bunch of fragments that didn’t fit together.

This quickly became overwhelming and really sucked my motivation away.

What I really owe myself is to not add any polish until the game is ready for it.

Luckily, things have been slow at work lately (until today), and so I’ve been left mostly to my own devices. Without any project work to complete, they let me work on pretty much whatever (as long as it’s somewhat related to what we do there), and since Unity is part of the skill set I use on a regular basis at work, I was able to justify working on my own game in order to increase my proficiency with Unity.

God how I wish that was the norm. Working all day long on something I love really makes the time fly.

Some day.

Anyhow, with all of this time to work on The Wayfarer, I decided it was the perfect time to throw away everything I’d done so far and start over, with a new mentality. This might seem like a bit of a waste, but I’ll be able to reuse some of what I’ve done, and consider the original work as a prototype.

The most important thing I’ve been doing is forcing myself to plan everything (except for the smallest tasks) before I even open Unity.

This prevents me from sitting down and asking that awful question “what do I want to work on today? What would be cool?”. Instead, I ask myself, “where did I leave off? What needs to be done today?”

My new workflow goes something like this:

Look at my task list (something I never had before, but to which I adhere strictly to now) and see where I left off. If a task is in progress, pick up where I left of. If not, move on to the next item, adding to the task list as required.

These tasks break down essentially into two categories: planning/design and implementation/development, and both groups take up about the same amount of time.

Before I write a single line of code, I establish my algorithms in my GDD in plain English (which feels strangely similar to coding).

Then, I draw an activity diagram based on the algorithm, identifying any logic flaws along the way and revising the algorithm as required.

Finally, after all of that is done, I move on to actual coding–simply translating the algorithm and diagram to code.

All of this might seem like overkill (and it does feel like a pain in the ass sometimes), but it’s all worth it in the end, and makes writing the code so much easier. Not only that, but my code is cleaner, more robust and more easily expanded upon.

Way fewer headaches now.

For those of you interested, here’s one of the plain English pseudo-code examples taken right from my GDD, and the corresponding activity diagram (these are for enemy AI):



Enemies will have the ability to make the following decisions:

  • Patrol
  • Wander
  • Pursue
  • Retreat
  • Engage
    • Melee
    • Ranged
    • Magic

There are 3 base states which an enemy can be in, which will determine available decisions:

  • Unalerted
  • Alerted
  • Injured

If an enemy has not seen or been attacked by the player, it will be in an unalerted state and will always either Patrol or Wander, unless it has seen or been attacked by the player within x turns.
Patrolling will always occur if patrol points exist for the enemy, otherwise it will wander.

If the enemy has seen or been attacked by the player within x turns, it will be in an alerted state.

In the alerted state, regardless of whether the enemy can currently see the player, it will always ‘know’ the player’s position, unless x turns pass without it seeing the player, in which case it will return to an unalerted state and continue to either patrol or wander.

While in the alerted state, the enemy will first check if its health has dropped below the injury threshold. If it has, it will randomly decide whether to heal (if available), continue engaging, or transition to the injured state.

If the enemy is still engaging, it will check if it is within a certain range of the player (a range it will consider to be dangerously close to the player). If it is and it has any available defensive buff spells whose effects are not currently active, it will perform a random check as to whether it should cast the buff or perform another action.

If it decides to perform another action, it will check if it is facing the player and if it has a clear line of sight within a range of y, where y is the longest attack range of any of its usable (has enough mana) attacks or abilities.

If this case is met, but the distance between the player and enemy is less than y, the enemy will make a random decision to either move backward to increase distance (up to, but not beyond y), or to attack.

If the distance between the player and enemy is equal to y, the enemy will always attack.

If the distance between the player and enemy is greater than y, but the enemy has seen or been attacked by the player within x turns, the enemy will attempt to move closer to the player.

While moving along the calculated path to the player, the enemy will always favor movement over turning, if available. It will do this by first favoring forward movement.

To favor forward movement, the enemy will calculate a new path from the cell in front of it to the player. If this path is shorter, it will move forward. If this path is longer, or the same distance, it will follow the original path.

Enemies may have an option for sidestepping. They will always favor this strafing over turning if it has been enabled for a given enemy.

This process will continue until either x turns have passed without it being attacked or seeing the player, in which case it will return to an unalerted state, or until it is within range of the player again and can attack.

While in the injured state, the enemy will check if it is dangerously close to the player. If so, it will make a random decision to flee, or heal (if available). The enemy will remain in the injured state for at least x turns (unless it has healed itself beyond the injury threshold), but not more than y turns.

If it is not within a dangerously close range, the enemy will always heal if available. Otherwise, it will move away from the player.

When leaving the injured state, if it has seen or been attacked by the player within x turns, it will return to the alerted state—otherwise, it will return to the unalerted state.



I have to say that with all of the practice I’ve gotten in lately, and my new workflows, I feel like I’ve just come out of a learning plateau, and am reaching a new skill level with programming and game development.


I’ve been spending nearly all of my recent development time working on my enemies.

This and the following two sections will deal with the details of that.

The first thing I did was rework my enemy AI, again with my cubes.

I feel like my new system is much more robust, as I’m able to get a wide variety of behaviors just by modifying a few values in Unity’s inspector.

I’m able to make my enemies favor ranged combat or close quarters (or any combination of the two), physical or magical attacks, determine how often they’ll heal themselves, and how likely they are to cast buffs on themselves during or in preparation for battle. I’m also able to dictate how aggressive they are by setting the chance that they’ll become injured and retreat during battle, and for how long they’ll pursue the player. I’m also able to dictate how well they can see. All of this without ever (hopefully) having to touch the AI code again (except for bug fixes).

This system relies on a simple state machine in which the enemy can be Alerted, Unalerted or Injured. In each of these states, the AI will choose how to behave based on their preference for a particular behavior.

You can see more about this system in the pseudo-code and UML shown in the above section.

I’ll show a short video of the AI in action in the next section, but for now, have a look at the variables exposed to the inspector which determine an AI’s behavior:



My goal with my magic system is to allow myself to make everything as generic as possible so that I can easily create new spells without writing additional code, by easily adding status effects to spells, being able to reuse the same visual effects for different spells, setting whether the spell is a projectile or has an immediate effect, or combining/linking any number of spells or visual effects.

The system itself is pretty difficult to explain. Suffice to say I use ScriptableObjects, prefabs and Animation Events, and can just work within the Unity Editor to make new spells. Also, I can just drag spells into an enemy’s spell list to give them the ability to cast them.

The system itself is pretty much done (with the exception of making status effects actually dosomething), but I’ve yet to put any legitimate visual effects in. Just differently colored spheres for now.

Here’s a short video showing how customizable I’ve made spells (I have hopes of letting the player create spells while playing as well):

One thing I would like to point out that I think is kind of cool is the ‘Blood’ Magick type. This type of spell costs health instead of (or in addition to) mana to be able to cast. I see these spells being used heavily by warrior type players who have a lot of health to spare, but maybe don’t have enough mana to be proficient spellcasters

And, here’s a video of my enemy displaying how it behaves, and how changes in its values modify its behavior.

Note that the different balls are placeholder for different spells, and the green thing is a placeholder for a physical projectile, like an arrow.

Don’t mind the bugs.



Along with all of this planning and trying to ‘do things right’ (if there is such a thing), I’ve been working on getting all of my stats set up, and having them actually be meaningful.

The need for this came out of creating the status effect portion of my spell system, which needed stats to be defined (or at least a shell of them) in order to work.

I’ve broken my stats down into three categories:

  • Primary/Governing stats: These determine all secondary base stats, and base proficiencies with tertiary stats. Very D&D-ish.
  • Secondary stats: Anything directly tied to primary stats. Health, Mana, Carrying Capacity, etc.
  • Tertiary/Skill Stats
    • Weapons & Armor (Dual wield, Ranged Weapons, Heavy Armor, etc.)
    • Magick (Proficiency in different types of Magick)
    • Other (Things like lockpicking, etc. If I decide to put them in the game)

The Player, enemies and NPCs all have a common set of stats, and then, of course, some that only apply to a certain character type exist only where necessary.

Nothing overly exciting here, except that I created my first custom inspector in order to make modifying stats easier.

Here’s a before and after:


This inspector lets me modify governing stats and see how it affects everything else. It also allows me to easily modify all stats and quickly restore a character’s health or mana at run time. Hopefully this saves me some time in the future.

That’s it for me. Stay tuned for more!

PS: We’ve got a new team member, but I’ll wait for him to introduce himself!


Waaaay too long since my last update. 

Since then, I've been working (not nearly as much as I should be) on outdoor environments and a skill tree. 

I want this game to follow the classic RPG class formula of Mage, Fighter and Thief, but I didn't want to constrain my players to a single class. Instead, I decided to go with a classless/multiclass concept where players are able to traverse a large skilltree which is implicitly divided into the three aforementioned classes. 

Take a look at the prototype:

So this is still an early proof of concept, and all of the visual elements will probably change, but it's going to function in pretty much the same way as shown here. You'll also get a (very) small taste of the kind of skills you might see in the game. One more note: the three skill branches never merge in this example, but I think they will in the final version. Also, all parent nodes of a skill must currently be unlocked before unlocking a given child node. I'm not sure if this will persists, or if I'll remove that constraint to give me freedom of traversal.

Other than that, I've been spending a bit of time building some outdoor environments to try to nail down what my worlds will look like. 

This first screenshot is, quite honestly, pretty bland and generic, but it will at least give a sense of how villages will be laid out in the world:


After I made this scene, I procured a license for Gaia--a really powerful and full featured terrain generation tool for Unity. 

Here's what 15 minutes of work with Gaia looks like:





Pretty amazing huh?

So in the end, I think I'll be using Gaia to build my world, and then I'll refine the terrain manually and tweak the positioning of settlements and other points of interest to best suit the game's story and gameplay. 

That's it for me. 

Stay tuned for an update on NPCs and monsters!



This is going to be a super short post (and a bit late coming, too), because I simply don't have a lot of time, but I completed my first Ludum Dare entry last weekend.

Here's a link to THE GAME'S LUDUM DARE PAGE, where you can read further about the game, and find links to play it.

I strongly recommend downloading the exe to play as the WebGL build is rather clunky. I also recommend using the mouse for control.

In a nutshell, you play a small planet who must collide with smaller planets to grow bigger, and avoid larger planets or break them apart with your guns.

The game isn't as full featured as I would've liked, but I plan on adding more functionality and bug fixes in the future.

I'll make a proper post in the days to come.


In my LAST POST, I talked mostly about some of the pathfinding options that I came up with. One of these solutions involved relying on raycasting to determine a path to my player, which was a fun exercise and yielded some really entertaining gifs. However, I decided to scrap that system in favor of using Unity's built-in pathfinding system via the NavMesh and NavMeshAgent components.

However, because my game uses grid-based movement, I wasn't going to be able to use said system out of the box.

My first solution to making Unity's pathfinding play nicely with my game was to have the NavMeshAgent generate a path, and then overwrite that path by normalizing each of its points to align with my grid (whose cells are 3x3x4).

This would have been fine, but I soon realized that would have had to account for inserting points along lengthy straight paths, as the NavMeshAgent only calculates the corners, or turning points, along the path.

I could have done this, but after a bit more thought, I realized this would require unnecessarily complex logic, and that I could accomplish the exact same end result with a simpler, but similar solution.

Basically, I just decided that, each time my enemies move, I would have the NavMeshAgent generate a new path. Then, instead of normalizing the entire path, I would just look at the first point in the path and normalize that. Why bother normalizing the whole path if I'm only ever going to be moving to the first point in the path anyway?

After I did this and added a bit of extra logic to account for the locations and movements of other enemies, I was able to successfully have relatively large mobs moving in ways that (more or less) seem to make sense.

Check out this video of some menacing cubes following my player around:

After I got all of that mostly working, I decided that, although the game is still in a super early state, I owed it to myself to add a bit of polish and replace my cubes with one of the assets I acquired.

Check out the difference a couple of textures, 2 models and some animation configuration can make:

So there's a lot going on in this video, so let me explain.

Firstly, here's a list of the key features that you can see in the video:

  1. Grid based player movement and turning (thanks to the awesome iTween library for all of my grid movement and rotation animations)
  2. Mouse Look with rotational snapping (this was actually kind of fun to do)
  3. Dissolving enemies (I'm still experimenting with different effects as you can see. Let me know which one you like).

Secondly, here's an explanation of what you're seeing in the video:

The game view is on the left. This is what the player sees.

On the right we have a bird's eye view courtesy of Unity's Scene View.

Note that the game uses a true turn-based system. Enemies won't perform an action until the player does. In the video it appears that the enemies sometimes take multiple turns, but I'm actually skipping my turn via keypresses in those cases. I guess I should also mention that if an enemy turns to face a new direction, it ends their turn, but the player can turn as many times as they want for free. I might change this in the future, depending on whether or not this becomes an 'unfair' thing to be able to do and tilts the odds too much in the player's favor.

The blue overlay you see is the walkable area of Unity's NavMesh. You'll notice that when an enemy enters an attack state, it will carve out the square that it occupies, making it non-walkable so that other enemies avoid that cell appropriately. I had to do it this way because, although Unity's NavMeshAgents will avoid one another if they're in control of movement, they don't actually take into account other NavMeshAgents when they calculate the path, and since I'm manually moving my enemies, I needed a bit more customization.

You'll also probably notice that some of the skeleton's animations are a bit off--the attack in particular. Unfortunately, I couldn't allow the animations to apply root motion as it interfered with my grid based movement, and as a result, some of the animations are a bit wonky. This was a purchased asset, which I'm still happy with, but if everything goes according to plan, hopefully I'll be able to spend some money to have the animations updated to align with my grid.

Anyhow--that's pretty much it for now.

I think my next focus will be on starting my inventory system. Looting, buying and selling are going to be a core gameplay component, so I'm going to have to get it right.


All Over The Place

In my last post I discussed an Action/RPG/Platformer/Diabloesque/JRPG game that I had started working on, and showed a short prototype video. As if the genre of this game wasn't already all over the place enough, I've since dropped the project (for now at least), and started work on something else.

The main reason for this was simply the lack of assets available to me for the game I wanted to make. I wanted to have fully modular armor for my character, but I simply couldn't find the assets that I needed, even paid assets, and I can't afford to hire an artist to create the level of sophistication for the armor that I wanted. This aspect of the game was really important to me, and without it, it just wouldn't have felt complete. However, I happened upon a large number of highly reusable, customizable, affordable and high quality assets during my search which inspired me to go a slightly different route. Thanks to the prepaid Visa cards I got for Christmas, I was even able to buy a decent number of them ;).

Ever since I was a kid, I've been a huge fan of First Person Dungeon Crawlers. The first that comes to mind is SSI's 1991 game Eye of The Beholder which was awesome (somehow I thought that flipping through a book to find the copyright protection phrase actually added to the fun). Even writing this I get nostalgic thinking about similar games like Catacomb 3D, Arcana, Ultima Underworld, and of course, Daggerfall. This is a genre I'm always returning to. Even with AAA titles like Skyrim and Far Cry sitting on my computer, I'll find myself putting them down in favor of playing old Dungeon Crawlers that I'd never heard of (like Anvil of Dawn).

In the last few years, I've been delighted whenever I've found a new title in the same vein as these classics, and to see how well they've been received.

Legend Of Grimrock did an amazing job of remaining true to these old classics while providing the added bonus of beautiful modern graphics, and has done incredibly well in terms of reception and sales.

Star Crawlers (even though it's still in Early Access) manages to hang on to the meat of the genre while spicing it up with Sci-Fi flavors and innovative new features.

The Quest HD , a lesser known 2016 re-release of an older game is a full fledged first person dungeon crawler in beautiful 2D with open world environments and a great story. I might even argue that it outclasses many of the above titles in many ways. Really worth a look if you're into this kind of thing.

I digress.

The point is: I really love these kinds of games. I don't know if it's something about the atmosphere, the storytelling, looting and killing or just the nostalgia of it all, but I think they stand out as my favorite genre.

So I've decided to make one!

Nailing Things Down

Like all of the games I come up with and want to make (very few of which even see as much as a keystroke of development), I've been thinking about this game pretty much non-stop for a couple of weeks. I've got a ton of ideas for the game--some to do with how to 'stay true' to the genre, some to do with how to deviate to add something original and worthwhile.

A few things I know for sure:

  1. I'm doing this one right. No half-assed hacking just to get shit done. I'm going to need a proper outline and game design doc, and I'm going to have to establish a normal routine so the project doesn't rust and atrophy. Regular refactoring as well. I can't have the tangled messes I've let happen in other projects.
  2. Grid-Based movement with some kind of turn-based play (this could be either semi-turn-based or full-out 'wait for player action').
  3. Nice 3D graphics. I really want to take full advantage of Unity's new PBR and Lighting to make something that really looks great, and as I've said, I just got my hands on some really top-notch assets.

I'm tempted to add more in the above list, but, to stay on the safe side, I'll make a second list of potential features currently under consideration:

  1. Multiple Levels/Areas--I think it would be more fun to have the player have the opportunity to spelunk in a cave system, bushwhack in a jungle, pillage in a crypt as well as crawl in the good ol' dungeon.
  2. Open-world--I know what you're thinking. How is this possible in a Dungeon Crawler? Seriously, have a look at The Quest. It integrates dungeon crawling and open-worldedness perfectly. A part of this is having towns that can be visited where quests can be undertaken and loot can be bought and sold (a feature missing from many dungeon crawlers).
  3. Complex character development--If any of you have read my earlier journals and are familiar with the last game I completed, Pixel Zombie Shooter, then you'll know I'm keen on upgrades. I'd like to have a nice multi-branched skill tree for my players to fill up as they adventure.
  4. Questing--I briefly touched on this in number 2, but I'd really like to have some non-linear questing in this one as well. I think it would offer a lot of opportunity to develop lore and give me a chance to do some good storytelling.
  5. Procedural Generation--Yeah, I know. Buzz word. But seriously, I really want to get into this. I've already got some ideas for randomized weapon implementations like those found in Diablo, as well as for infinite guild quests and random dungeon areas. On that note, I'm not sure if I'd be interested in all hostile areas (dungeons, forests, etc.) being procedural, or just special 'grinding/looting' areas.

Finding My Way

Ok. You've listened to me rant about this new game idea I'm obsessed about, but talk is cheap. Here come a few things to look at as a reward for sticking through this post so far.

I've only had two development sessions on this game so far, and I think they both went well. In both cases, I spent a full day prior to my night-time dev session thinking on and off about how best to implement a feature, and in each session, I've been able to successfully implement at least a basically functional version of said feature in only a small amount of time.

The first of these is a simple movement controller.

The Code:

CharacterMovementController.cs:using UnityEngine;using System.Collections;public class CharacterMovementController : MonoBehaviour { [SerializeField] //How long it should take to rotate or move the camera private float animationTime = 0.35f; [SerializeField] //The amount to move the player by. Should be equal to the size of each level 'tile' private float unitSize = 3f; [SerializeField] //How much to rotate on each rotation (1 == 360?). This shouldn't change unless allowing diagonal movement private float rotationAmount = 0.25f; [SerializeField] //How high off the ground the player sits. private float playerHeight = 1.75f; [SerializeField] //The easeType to use for the iTween animation. private iTween.EaseType easeType = iTween.EaseType.linear; [SerializeField] //This is used to determine appropriate positioning when climbing/descending uneven terrain. private HeightProbe heightProbePrefab; private Hashtable iTweenArgs; private bool canMove = true; //Initialize itween args void Start() { iTweenArgs = new Hashtable(); iTweenArgs["time"] = animationTime; iTweenArgs["oncompletetarget"] = this.gameObject; iTweenArgs["oncompleteparams"] = true; iTweenArgs["oncomplete"] = "ToggleMovement"; iTweenArgs["easetype"] = easeType; } void Update() { /* Uncomment to allow these values to be manipulated via the inspector at runtime for testing iTweenArgs["time"] = animationTime; iTweenArgs["easetype"] = easeType; */ //Move or rotate the player based on input. if (canMove) { if (Input.GetKey(KeyCode.W)) { Move(transform.forward); } else if (Input.GetKey(KeyCode.S)) { Move(-transform.forward); } else if (Input.GetKey(KeyCode.D)) { Move(transform.right); } else if (Input.GetKey(KeyCode.A)) { Move(-transform.right); } else if (Input.GetKey(KeyCode.E)) { Rotate(Vector3.up); } else if (Input.GetKey(KeyCode.Q)) { Rotate(Vector3.down); } } } /* Move the player in the appropriate direction. First initialize newPosition based on direction, then create a HeightProbe to determine the appropriate y value for newPosition. This allows easy vertical movement along both even and uneven terrain. HeightProbe destroys itself after FindFloorHeight() is called. */ private void Move(Vector3 directionVector) { Vector3 newPosition = transform.position + directionVector * unitSize; HeightProbe heightProbe = Instantiate(heightProbePrefab, newPosition, Quaternion.identity) as HeightProbe; newPosition.y = heightProbe.FindFloorHeight() + playerHeight; iTweenArgs["position"] = newPosition; ToggleMovement(false); iTween.MoveTo(this.gameObject, iTweenArgs); } private void Rotate(Vector3 rotationVector) { iTweenArgs["amount"] = rotationVector * rotationAmount; ToggleMovement(false); iTween.RotateBy(this.gameObject, iTweenArgs); } private void ToggleMovement(bool allowMovement) { canMove = allowMovement; }}
HeightProbe.cs:using UnityEngine;using System.Collections;public class HeightProbe : MonoBehaviour { [SerializeField] private float destructionDelay = 0.25f; [SerializeField] // This should be set to only detect the floor in the future private LayerMask layerMask; public float FindFloorHeight() { StartCoroutine(SelfDestruct()); RaycastHit hit; Physics.Raycast(transform.position, -transform.up, out hit, Mathf.Infinity, layerMask); if (hit.transform) { return hit.point.y; } else { return Mathf.NegativeInfinity; } } private IEnumerator SelfDestruct() { yield return new WaitForSeconds(destructionDelay); Destroy(gameObject); }}
Both of these scripts are super simple and will need some updating, but they give a nice final effect:


Basically, when the user gives input, I spawn a HeightProbe in the appropriate neighboring space, which simply finds the height of the floor/ground in that location. The PlayerMovementController will then add playerHeight to this value and use that as the y position to move to. The reason I did it this way, rather than having a set step height was because I wanted the potential to have my player move on uneven terrain while maintaining the grid-based movement. This will be particularly useful for outdoor areas and will give me greater freedom in my level design.

Right now there are no checks to see if the player is trying to move through a wall, and I rely on iTween to do all of the heavy lifting in animating my player's rotation and translations (who wants to manually code that stuff? Not me). Obviously I'll have to do some checking for movement through walls. Also, based on what I've read, iTween is pretty inefficient (I do love working with it though), so I think I'll have to rework the code to use DoTween instead (also free, but apparently performs way better).

Also, I might get rid of the HeightProbe class altogether and put the logic right inside the PlayerMovementController.

Lastly, I don't like having my input hardcoded, so that'll have to change. I'll also want a bit of a mouselook functionality so the player can observe the environment more fully.

And yes, that was a baby dragon :wink:.

What I did in my next development session was implement a bit of pathfinding. Like I said, I thought about this all day, and I came up with my own algorithm. I have no idea what you would call it technically, but in demonstrations I've seen, it performs similarly to a concurrent Dijkstra implementation. e is an enemy, p is the player:


I've never done any pathfinding before (aside from using Unity's built in AI stuff), so this is a first for me. And I think I did pretty good coming up with a solution completely by myself. I won't need a ton of pathfinding in the game (since most enemies will probably only move toward the player if they can see him, or move to a last known location), but I thought this would be fun, and it was.

Not to mention I really like watching my code solve a maze :P. There's something hypnotizing about these gifs.

The Code:

Pathfinder.cs:using UnityEngine;using System.Collections;using System.Collections.Generic;public class Pathfinder : MonoBehaviour { [SerializeField] private Color color = Color.red; [SerializeField] PathProbe pathProbePrefab; [SerializeField] private float unitSize = 3f; public float UnitSize { get { return unitSize; } } [SerializeField] private LayerMask layerMask; [SerializeField] private Vector3[] directions; public Vector3[] Directions { get { return directions; } } private List probedCells = new List(); public List ProbedCells { get { return probedCells; } } private List pathToTarget = new List(); public List PathToTarget { get { return pathToTarget; } set { pathToTarget = value; foreach (PathProbe pathProbe in GameObject.FindObjectsOfType()) { if (pathProbe.Master == this) { Destroy(pathProbe.gameObject); } } } } void Start() { InitiatePathFinding(); } private void InitiatePathFinding() { probedCells.Clear(); pathToTarget.Clear(); probedCells.Add(transform.position); foreach (Vector3 direction in directions) { CreateProbeAtNeighboringCell(transform.position, direction); } } void Update() { if (Input.GetKeyDown(KeyCode.F)) { InitiatePathFinding(); } } public PathProbe CreateProbeAtNeighboringCell(Vector3 position, Vector3 direction) { Vector3 cellPosition = position + (direction * unitSize); if (!probedCells.Contains(cellPosition)) { RaycastHit hit; Physics.Raycast(position, direction, out hit, unitSize/*, layerMask*/); Debug.DrawRay(position, direction * unitSize, color); if (!hit.transform) { PathProbe newPathProbe = Instantiate(pathProbePrefab, cellPosition, Quaternion.identity) as PathProbe; newPathProbe.Master = this; newPathProbe.Color = color; probedCells.Add(cellPosition); return newPathProbe; } } return null; }}
PathProbe.cs:using UnityEngine;using System.Collections;using System.Collections.Generic;public class PathProbe : MonoBehaviour { private Pathfinder master; public Pathfinder Master { get { return master; } set { master = value; StartCoroutine(PathFind()); } } private Color color = Color.red; public Color Color { set { color = value; } } private List pathPoints = new List(); public List PathPoints { set { pathPoints = value; pathPoints.Add(transform.position); } } private List myProbes = new List(); private IEnumerator PathFind() { if (master) { yield return new WaitForFixedUpdate(); if(master.PathToTarget.Count <= 0) { foreach (Vector3 direction in master.Directions) { PathProbe newPathProbe = master.CreateProbeAtNeighboringCell(transform.position, direction); myProbes.Add(newPathProbe); if (newPathProbe) { newPathProbe.PathPoints = this.pathPoints; } else { RaycastHit hit; Physics.Raycast(transform.position, direction, out hit, master.UnitSize); //Debug.DrawRay(transform.position, direction * master.UnitSize, Color.green); if (hit.transform && hit.transform.tag == "Player") { master.PathToTarget = pathPoints; Debug.Log("Path to player found in " + Time.time + " seconds!"); foreach (PathProbe probe in GameObject.FindObjectsOfType()) { Destroy(probe.gameObject); } } } } } Destroy(this.gameObject); } }}
Basically, I raycast in all four directions from the enemy's position, at a distance equal to my grid size. If my rays don't hit anything at those locations, I spawn a PathProbe at the appropriate place and repeat, adding each cell from which rays were cast to a probedCells list, and omitting those cells from future checks. Because each probe performs iterations at the same time as all of the others, the first path to reach the player is always the shortest, so I didn't even need to take that into consideration, and as soon as any path is found, I can stop the search.

Currently, my coroutine's yield is no good and it makes the whole process take a relatively long time (waiting for a new frame before performing another iteration). Essentially, only a single set of cells for each probe can be checked per frame, which can become a problem, particularly in long narrow paths. I need to allow a greater number of checks before yielding to speed up the whole process, but I also have to be careful not to overload it or things tend to crash.

Currently, both of the searches you see above take about 0.75 seconds each. Again, this has nothing to do with complexity, and more to do with how my coroutine operates. In fact, having multiple paths calculated at the same time has had zero impact on frame rate or calculation time so far (though I've only tested 3 concurrent paths to date).

However, I really need to rework this as .75 seconds is not acceptable. Presumably, to be safe, I'll have to recalculate the path each time the enemy moves to a new cell, just in case something has blocked the path or the player has moved. But like I said, I don't think I'll need a lot of pathfinding. I think most of it will be linear movement along a line of sight.

Again, I might remove my logic from PathProbe and put it right in Pathfinder to avoid Instantiate calls.

I was also considering using Unity's NavMeshAgent to calculate a path, and then writing some code to normalize that path to align with my grid (I assume Unity's pathfinding would be more efficient than anything I'll write). Another approach I'm considering is generating an array based on my level when it loads, and then traversing the array based on whether the given index is walkable or not. This would save on raycasting at least.

Anyhow, that's it for now!

Stay tuned for more, including the launch of an official website for Fidelum Games!


So I've yet to do a proper post-mortem for Pixel Zombie Shooter. I will do one soon, but for now I'm very excited about the other project I've started working on, and I wanted to share it with everyone.

I've been thinking about this game for quite some time; since long before I completed Pixel Zombie Shooter (which was only about a week ago). So far, I don't have a name, but refer to it affectionately as 'Knight Proto'.

I have a ton of ideas that I'll list below (combing through emails to myself as I do so). But before I do, check out this quick video. Bear in mind that I've only put about 20 hours or so of work into this so far, and it's strictly at a prototype phase. Graphics are all placeholder free assets I've found on the Unity Asset Store (though I think what you see in the below video is more or less representative of the kind of style I'm going for), Turbosquid and Freesound. However, I plan on staying away from art creation for this project, so I'll either have to pay an artist, or rely on paid asset packs. On the flipside, all of the code is mine (except for some orbital camera stuff, and the lightning spell). But, Everything is hardcoded at this point; I really just wanted to visualize my ideas.

Here's the video. See below for a bit of explanation:

The first screen is the overworld map. This functions the same as it did in games like Zelda II for NES, or any Final Fantasy game up to X. Basically, you use it to navigate between different towns, dungeons, continents, etc. I've really missed these, and can't think of any modern-era 'free-roam' overworld maps. The closest thing I can think of to a world map nowadays is the level select screen in Shovel Knight. It seems like overworlds have disappeared completely in favor of linear based gameplay (in recent JRPGs like the newer Final Fantasies), or sandbox worlds like Skyrim, Fallout or Farcry.

This game is going to be very much a nostalgia trip (I was a Windows 95/SNES kid), so of course, I needed an airship :). Interestingly, the script for the airship, the overworld player controller, and the in-dungeon player controller are all the same (with a few inspector parameter tweaks). Talk about versatility!

I guess I should also mention that the time of day system is highly accelerated compared to what I expect it will be in any final version of the game. Also, the game is currently quite dark (not as bad as the recording, but still).

Here I'll also mention some ideas for the world map:

  • Digging for treasure
  • Fishing
  • Zelda II style encounters (where collision with an on-screen enemy object triggers the launching of a 'level' scene).
  • Hunting (using a mechanic similar to how the cherub in Actraiser fought enemies)

    The second screen we see is one of a few ways that I'll present 'levels'. It starts out in a bit of an isometric view (though I couldn't use an orthographic camera because deferred rendering doesn't support it, and I needed deferred for soft particles), and then goes on to show how the game camera can be manipulated to provide top-down, third-person, or side-scrolling gameplay. This diversity of play is really important to me, as I'm drawing inspiration from a ton of different games/genres, and perspective really matters when getting that across.

    I suspect that some levels or areas will be locked in a certain perspective (boulder-chasing-the-character-scene anybody?).

    The third screen shows more of a diablo-esque style of play. I'll certainly be drawing a lot of inspiration from that franchise, along with the many clones that spawned from it. I have a lot more to say still, so... Stay awhile, and listen ;).

    I guess that pretty much addresses what you saw in the video. So now I'll talk about some more of the general ideas I had.

    I'm not set in the art style. I'm definitely not aiming for high-realism (I suspect there will be a lot of [somewhat hidden] humor and nerd-references in the game), but I'm still not sure if I want to go true low poly (see Darwinia), or more of a handpainted style. I'm leaning toward the latter (I've found some really nice affordable assets I can use). No matter which route I take, I suspect I'll need to play with lighting quite a bit.



    Based on what I've read, mixing dynamic lighting with hand-painted textures is usually a bad idea. But I really want cool torchlight shadows and emissive particle effects, dammit! It'll take some experimentation.

    Lastly, as far as visual styles go: I thought it would be really neat to have pure medieval style armor in the game. The kind of things worn by actual knights (or at least as I imagine it) back in the day:

    As far as gameplay goes.... Well. That's a whole blog post in and of itself. But, here we go... point form:

    • Metroidvania: Oh, I can't open this door in this dungeon. What's that strange marking? Guess I'll have to remember this for later.
    • Modular armor sets. I'm talking old school--Elder Scrolls II: Daggerfall. Leather left gauntlet with a right Dwarven gauntlet? Wizard robe with chainmail? No problem!
    • Fully customizable character classes via armor/weapons/skill tree. At least three main skill branches which can be invested in at any time: Rogue-type, Warrior-type, Mage-type.
    • Dual-wield. I've got some significant thoughts on this, but.... In a nutshell: Magic/single handed weapons/shields can be equipped to either hand. However, bows are single handed until you are holding an arrow, so bows (though typically two handed), can dual wield with spells (but nothing else). LMB = left hand, RMB = right hand. If a shield is equipped, you must USE the corresponding hand (LMB or RMB) to block (see Apothen below, but think in 3D). Holding the block button and clicking the other mouse button causes a shield bash.

      That's pretty much it for now.

      I have a ton of ideas, and this will definitely be more challenging than my last project, but I'm really excited to see where this goes!

      Let me know what you think!


It's Done!

[font=arial]It's Done! Finally.[/font]

[font=arial]It's true! The game is complete! After a couple of (painful) weeks of waiting to hear back from sponsors, I'm sorry to say that I have (so far) been unsuccessful in securing sponsorship for the game. However, my primary goal for this game was simply to complete an entire project, so I'll consider this a success :D.[/font]

[font=arial]I'm not going to wait forever to hear back from sponsors, so at this point, I've decided to publish on my own. See a little lower for links to the game.[/font]

[font=arial]This project has been a pretty big challenge. Mind you, it wasn't a particularly hard game to develop (though I don't really have anything else as reference), but seeing it through to the end has been tough. To be honest, there were a lot of times where I was just sick of this game, and wanted to move on to other things. Many times I felt like the game was shit, and looking at the same damn blocks of color for nearly a year gets really frustrating at times. But I'm glad I stuck with it. I remember reading somewhere that whenever you finish a game, you'll never really be satisfied or happy with it. I kind of get that. I mean, I would have loved to secure a sponsor (there's still some time for that yet if I do well on release, however), and I wish it didn't take me so damn long. But I think I have to say that, for the most part, whoever wrote that probably just made shitty games :P.[/font]

[font=arial]When I originally had the idea for this game, I had planned to spend somewhere around two months on it. It was supposed to be a 'quick' game--one that I could just say I had finished. It's been somewhere around 10 or 11 months now.[/font]

[font=arial]There are a number of things that I attribute to the game's development taking so much longer than planned, the heaviest of which are feature creep (damn those of you who suggested exploding limbs :wink:), completely losing motivation and not touching the project for a couple of months, and my evidently horrendous time estimation abilities.[/font]

[font=arial]Let's comb through my previous posts in this journal for evidence shall we? (Cue the flashback music)[/font]

[font=arial]February 4, 2016:
[color=#282828]"If I'm lucky/diligent, hopefully I'll be done this bad boy by the end of February".[/color][/font]

[font=arial][color=#282828]March 23, 2016:[/color]
[color=#282828]"[/color][color=#282828]I can see the light at the end of the tunnel... The project is almost done, but I'm struggling to sit down and get it done."[/color][/font]

[font=arial]July 8, 2016:
[color=#282828]"[/color][color=#282828]Hopefully late July/early August I'll be done everything? So I'm getting excited to have my first game complete!"[/color][/font]

[font=arial]So there you have it. I really suck at time estimates.[/font]


[font=arial]Since I'm talking about promotion, I suppose this is the best place to do this:[/font]

[font=arial]Pixel Zombie Shooter is the most amazing game you'll ever play! Seriously, you won't know what hit you! It's incredible! No one has ever made a game better than this one in the history of video games ever. And I'm being modest! Until you've played this game, you haven't truly lived! DO IT!!!! And check out this trailer:[/font]


[font=arial]You can (and really should :P) play the game on Kongregate and Newgrounds. Also, if you do play, please take a quick minute to at least leave a rating. These sites base how much they promote a game based mostly on plays and ratings, so you'll really be doing me a solid if you leave a rating. If you have the time, a review would be awesome too![/font]

[font=arial]Ok, now that's out of the way...[/font]

[font=arial]I recognize the importance of promoting my game. If I just upload it to a site, someone might stumble across it, then someone else, someone might share it with a friend, etc., etc. But that's super passive, and really relying on chance. Any game needs exposure. And that's not just going to happen just by magic.[/font]

[font=arial]In my own efforts to promote my game and game company (Fidelum Games), I've started a [color=#0000FF]Youtube channel[/color] where I've been uploading weekly Unity tutorials, and where I've also posted the trailer you see above. In addition, I've linked to [color=#0000FF]Fidelum Games' Facebook page[/color] from said channel, where I post pretty regularly. I'm posting the tutorials in the hopes that people will 'stumble' upon my game trailer, and my Facebook page, where they can find links to the game and play it. If you feel like helping me out, give my Facebook page a like, and share the most recent post about the game's release. It really does make a big difference. Just one share gets it in front of hundreds of people who wouldn't see it otherwise. Just imagine what would happen if everyone who read this shared it! Look, I'll even make it easy for you: SHARE ME[/font]

[font=arial]Now let's talk about some more interesting stuff.[/font]

[font=arial]Tying Up Loose Ends[/font]

[font=arial]I've been quiet over the last few months, focusing on getting the last 'small' details of my game worked out and implemented.[/font]

[font=arial]In my last update, I provided a list of tasks that I set for myself to complete for the beta/test version, and I haven't been back on to talk about it since. For sake of completeness and continuity, I'll talk a bit about that.[/font]

[font=arial]The list I gave myself was as follows:[/font]

  • Implement Headshots
  • [font=arial]More enemy variants[/font]

  • [font=arial]Having my 'Blood Bird' (a crow variant) affect the player's move speed and jump height.[/font]

  • [font=arial]Fixing an accuracy bug[/font]

  • [font=arial]Game ending (The player riding away on the bike when it's repaired)[/font]

  • [font=arial]Playtuning:[/font]

  • [font=arial]Rate of currency accumulation[/font]

  • [font=arial]Cost of weapons, ammo, upgrades and medkits[/font]

  • [font=arial]Upgrade values (weapon damage, accuracy, capacity, fire rate, etc.[/font]

  • [font=arial]Rate of experience accumulation and levelling curve[/font]

  • [font=arial]Ability values (how much damage does the Iron Skin ability negate, how fast should the Fast Feet ability make the player move?, etc.)[/font]

  • [font=arial]Enemy Health and Damage[/font]

  • [font=arial]Wave Tuning (Number of enemies in each wave, types of enemies in each wave, number of predefined waves, infinite wave generator)[/font]

  • [font=arial]Bike repair speed[/font]

    [font=arial]I gave myself 8 days to complete these tasks, and with the exception of the game ending, I was successful. I added the changes, and sent the link to the build to testers just after midnight on the 16th of July (so I missed my deadline by a couple of minutes).[/font]

    [font=arial]Implementing Headshots[/font]


    [font=arial]When I first thought about implementing headshots, I thought that I would just use another collider as a child object to the enemy's main GameObject, and whenever collision occurred on said object, I would send a message upward to the parent to take double damage. Of course, as with most things in life, this didn't go exactly according to plan.[/font]

    [font=arial]After some fiddling, I realized that all collisions occurring anywhere within my Enemy's GameObject hierarchy were being intercepted by the parent object. Apparently, this is the expected behaviour when a parent GameObject has a Rigidbody and Collider attached. So, because of this, my original solution wouldn't work. However, I didn't have to start from scratch.[/font]

    [font=arial]I was able to keep the child Collider, and rather than attach a custom Head script to it and look for that reference in my Projectile's OnCollisionEnter2D function, I started digging more into Unity's Collision2D class. It turns out that this class is good for a lot more than just things like[/font]

    void OnCollisionEnter2D(Collision2D col){ if(col.tag == "Enemy"){ col.getComponent().TakeDamage(damage); }}

    [font=arial]which tended to be similar to how I've used it in the past.[/font]

    [font=arial]Collision2D contains a number of useful properties that we have access to. Most of these have to do with information about the GameObject involved in the collision (such as references to the GameObject, it's Rigidbody, etc.), but the one that proved to be useful for my purposes was Collision2D.contacts. This property contains an array of ContactPoint2D objects, which have a 'point' property, which gives the location in space where the collision occurred. Because each of my enemy types are of a fixed height, I was able to check that the y coordinate of this value was above a certain limit. If so, headshot.[/font]


    Handling UI Updates; Lessons Learned

    [font=arial]In one of my earlier posts, I mentioned that I may have made a bad design choice when handling my UI updates. Originally, I had references to my Stats script (which holds properties for ammo, health, XP, Cash, etc.) inside of each of my UI classes. Then, these UI classes would just update their corresponding elements with whatever values they were interested in on every frame. It seemed to me that doing this every frame was bad practice and had the potential to be more processing intensive than necessary (not much, mind you, but still). So I decided to take an approach where the UI would only be updated when a stat value actually changed. This meant removing the references to Stats from my UI classes, and instead giving references to all of my UI classes to my Stats class, basically just inverting the relationship. Then, rather than call the UI update methods in the Update function, I would call them inside the methods that actually caused stats to change (TakeDamage, Fire, AddCash, etc.) This wound up being so disgusting that I decided to add another layer and bring in a UIManager class. This just wound up making everything more disgusting, and in the long run, my UIManager just wound up updating stats every frame anyway. What a disgusting waste of time. The end result is, from the outside, identical. Internally, however, it's probably worse in all ways imaginable.[/font]

    [font=arial]In hindsight, I should've just left it.[/font]

    [font=arial]I shudder at the thought of what the UML or something for my project might look like. Okay, you twisted my arm, here you go (those of you who are easily offended or prone to seizures, look away now):[/font]


    As you can see, I pretty much threw design out the window at some point on this project. This is completely unreadable and really makes me want to barf. There's circular dependency pretty much everywhere. It's just gross.

    For those of you who are interested, here is the diagram for just the UI and Upgrade related stuff, which is still pretty nasty:


    [font=arial]Of course, as it always goes, now that I have finished the game, I figured out the perfect way to only update when required, and to do so cleanly and maintainably: Events and Delegates.[/font]

    [font=arial]Rather than store references to everything all over the place, polluting my code and making for poor structure, I could have many of my classes completely agnostic to one another. [/font]

    [font=arial]I could use events a delegates all over the place in my project (or any for that matter). They seem like a really great way to keep things clean and avoid storing a jillion references, especially when they're only needed once. However, the implementation I would need for my UI updates would be something simple like this:[/font]

    [font=arial]Stats.cs:[/font]//Create the delegate with the method signature which each UI class will implementpublic delegate void StatEventHandler(float currentStatValue, maxStatValue);//Create events which each UI class will subscribe to, and make them static to avoid the need of storing references to Statspublic static event StatEventHandler OnAmmoChange;public static event StatEventHandler OnHealthChange;public static event StatEventHandler OnXPChange;//Etc., etcprivate void Fire(){... ammoCount--; OnAmmoChange(ammoCount, maxAmmo);...}public void IncreaseAmmo(int amount){... ammoCount += amount; OnAmmoChange(ammoCount, maxAmmo);...}public void GainXP(float amount){... currentXP += amount; OnXPChange(currentXP, xpToNextLevel);...}public void TakeDamage(float amount){... health -= amount; OnHealthChange(health, maxHealth);...}public void Heal(float amount){... health = Mathf.Clamp(health + amount, 0, healthMax); OnHealthChange(health, maxHealth);...}//Etc., etc.
    [font=arial]Then in each UI class, I just subscribe to the event so that my UI class's UpdateUI function is called when these events occur.[/font]

    [font=arial]HealthUI.cs (or any UI class, slightly modified):[/font]Stats.OnHealthChange += UpdateUI;private void UpdateUI(float currentStatValue, maxStatValue){ healthText.text = statValue + " / " + maxStatValue; healthSlider.value = currentStatValue / maxStatValue;}
    [font=arial]Now stats doesn't have a reference to UI classes, or vice-versa, which makes things a lot cleaner. Also, UI elements are only updated when a change actually occurs. I think this is the perfect solution for this case. [/font]

    [font=arial]In fact, events and delegates seem like one of the most useful tools I've found thus far. I could envision a game where you can pretty much avoid storing references altogether (unless absolutely necessary), and rely on a custom event system to drive the game. I could even see this going a step further and having an EventManager class (potentially with subclasses) which acts as an intermediary. It would subscribe to events fired by other classes, but the only events that other classes would subscribe to are ones fired by EventManagers in response to the events that IT has subscribed to. [/font]

    [font=arial]Basically, EventManager would listen to all GameObjects which were firing events, and GameObjects would ONLY listen to EventManager. It seems that this would provide a nice centralized solution. Granted, this would introduce a different kind of circular dependency, but one that I think would be acceptable. I might try something like this on my next projects. Has anyone tried something like this, or know of some design pattern that functions like this? Please share your thoughts.[/font]

    [font=arial]That's really all I have time to write at the moment, but stay tuned for a proper post-mortem and some news on what I'll be working on next.[/font]

    [font=arial]And please, if you have the time, check out the game and leave a rating![/font]


Oh Frabjous Day!

Callooh Callay! The time has come!

I've taken a day off from work, so I'm going to be pounding away at this for the next 5 or 6 hours (I've already been at it for a couple) in order to meet the deadline I've set for myself (tomorrow night).

Don't want to waste time saying too much right now. However, I've managed to shave off most of my list, and I'm 99% per cent confident I'll meet the goal I had set for tomorrow night (barring an act of god).

I'll either update this journal when I've uploaded the test build, or I'll create a new entry.

PS. I'm starting streaming for the rest of the day RIGHT NOW!!!

Unfortunately my mic was broken recently, so you'll only be able to hear the awesome music I play while developing and my game audio. But you'll also be able to watch a genius at work! :P


Simple Brilliance

The thing I was working on tonight was getting all of my enemy variants into the game. I've got the color variants done, with the red versions being more difficult to kill, and I'm working on getting the limb variants in.

This took a little bit of thinking as to how would be best to handle it.

I knew I would need an animation state for each permutation of limb loss (no head, no head no left arm, no head no right arm, etc.), so I set up each animation from the sprite sheets that I already made. Then I had to figure out how to determine which animation state to play based on what limbs were missing from the enemy (and think about how to lose limbs in the future).

My first thought was just to use bools and a relatively complicated if/else structure, something like:[code=:0]if(headLost){ if(leftArmLost){ if(rightArmLost){ animator.SetBool("NoLimbs", true); } else { animator.SetBool("NoHeadNoLeftArm", true); } //etc., ... }}
This would work, but it would just be really ugly.

My next thought was to still use bools, but in combinations--one for each possible state (of which there are 8 in total). I would use a specific combination of them to set any given animation state, one bool for each limb lost to form the specific combination. This solution seemed finicky, and potentially confusing to set up, so I thought maybe I could set up some kind of string concatenation when a limb was lost to use as the trigger name value. Again, this seemed finicky, and would really be a hacky version of the second bool solution.

The solution that I've settled on, though have yet to fully implement, I think is fairly clever, reduces the amount of code I have to write, and will make it easier to remove limbs during play while also easily managing the animation state.

First off, I decided that all of my zombies would be instantiated will their full set of limbs. In their Start function, I will randomly determine how many, and which limbs to remove, if any, to create an enemy variant. Since they always start with all limbs, and because they can never gain limbs, I set my animation states up in a one-directional manner, under the assumption that only one limb could be lost at a time. It wound up being a bit of a thing of beauty:


At first glance, it might not be perfectly clear, but here is the progression if you trace the far right track (notice that the transition from "SkinbieNoLeftArm" to "SkinbieNoArms" runs BEHIND "SkinbieRightArmOnly").

So yeah, the progression tracing the right track:

[font='courier new']-----------------------------------------------------------------------[/font]
[font='courier new']|SkinbieWalk -> SkinbieNoLeftArm -> SkinbieNoArms -> SkinbieNoLimbs | [/font]
[font='courier new']-----------------------------------------------------------------------[/font]
[font='courier new']| All Limbs -> Lose Left Arm ->Lose Right Arm -> Lose Head |[/font]
[font='courier new']-----------------------------------------------------------------------[/font]

It functions similarly for all other tracks as well.

Then, I needed to figure out how to explain to the animator what state the enemies' limbs were in to determine the correct animation.

I figured, I would assign a unique integer value to each limb, and the sum of the existing limbs would be used as an integer parameter in the Animator to set the state. The only caveat with this solution, is that all permutations of the possible sums of the integers must be unique as well.

I started by assigning the integers 1, 2 and 3 to the right arm, head and left arm, respectively:


Then I quickly figured out all possible sums:


Here, we have 7 values, one for each state (and 0, for the 8th state of no limbs)
those of the limbs themselves: 1, 2 and 3
the sums of each couple: 3, 5 and 4
and the total sum: 7

However, all values/sums aren't unique as 3 is present twice.

So I realized that using values of 1, 2 and 4 would give all unique values, from 1 - 7:

This is a pretty simple solution, but I think it's a pretty clever one. Luckily I only have 3 limbs that can be lost, so figuring out all unique values was super easy, but this method could be used on a much greater set of items than just 3 in a similar situation (where removing a single item from a set is required, especially where the removal is order independent).

So I went from that ugly if/else structure:if(headLost){ if(leftArmLost){ if(rightArmLost){ animator.SetBool("NoLimbs", true); } else { animator.SetBool("NoHeadNoLeftArm", true); }//etc.,... }}
To something much simpler:[code=:0]private int limbSum = 7;enum Limb{ Left, Right, Head};public void RemoveLimb(Limb limb){ switch(limb){ case Limb.Left: limbSum -= 1; //Instantiate left limb here when implementing dismemberable limbs. break; case Limb.Right: limbSum -= 4; break; case Limb.Head: limbSum -= 2; break; } animator.SetInteger("LimbSum", limbSum);}
Again, not super complicated, but I think it's a pretty elegant solution.

Crunch Time

Alright. I'm down to the home stretch. I've got just over a week until the deadline I've set for myself, and of course, life has gotten in the way.

A new project suddenly became a huge priority at work, so I've been devoting extra time to getting that done. The good news is that I'm developing my portion of the project in Unity (which I don't normally get to do), so at least I'm having fun at work. Also, I've been a bit sick. Blah blah blah. Excuses excuses.

However, I am not deviating from my deadline of midnight, Saturday, July 16th to have all of the core functionality implemented and have the game mostly play-tuned (beta tester feedback will help determine the final play-tuning) for release to those individuals who will be play testing.

I still have quite a bit I want to do before the initial beta-testing, and little time to do it in, so I'm making it a point to put in at least some time every single night. I'm also going to try to take a vacation day next Friday to work ALL DAY on the project (obligations permitting).

Looking over the list of things I want to do, I'm actually closer to having the core functionality complete than I thought. Here is the list of what I NEED done by the 16th (and this only contains items that will directly affect game play):

  1. Implement Headshots
  2. More enemy variants
  3. Having my 'Blood Bird' (a crow variant) affect the player's move speed and jump height.
  4. Fixing an accuracy bug
  5. Game Ending (The player riding away on the bike when it's repaired).
  6. Playtuning:

  • Rate of currency accumulation
  • Cost of weapons, ammo, upgrades and medkits,
  • Upgrade values (weapon damage, accuracy, capacity, fire rate, etc.)
  • Rate of experience accumulation and leveling curve
  • Ability values (how much damage does the Iron Skin ability negate, how fast should the Fast Feet ability make the player move?, etc.)
  • Enemy Health and Damage
  • Wave Tuning (Number of enemies in each wave, types of enemies in each wave, number of predefined waves, infinite wave generator)
  • Bike repair speed

    This really isn't that bad of a list, so I shouldn't have a problem getting this all done by next week.

    Then there are the nice-to-have's which will all be implemented by the time of actual release, and as many as I can get by the 16th:

    • Add pickup sounds
    • Blood Particles
    • Exploding/dismemberable enemies
    • Enemy Variants V2 (Spawning with limbs missing)
    • Have crows fall from the sky and hit the ground when they die
    • Intro
    • Achievements (Including icons)
    • Wave Counter
    • Add a level up animation.
    • Mute Button
    • Sponsor placeholder
    • Shellcasings
    • Trailer
    • Facebook/Twitter links and rewards
    • Optimization Refactor

      Again, even this list isn't that bad. Hopefully late July/early August I'll be done everything? So I'm getting excited to have my first game complete!

      Also, if you are at all interested in play testing, let me know. I have a decent number of people willing to test, but I can always use more. I won't be sharing the link to this publicly, so if you want to test, you HAVE to let me know.

      Anyway, that's it for now. I'll probably be silent for the next week. Maybe an update some time on Friday (and I suspect I'll STREAM ON TWITCH all day that day as well)

      Wish me luck!


Hey everyone,

This weekend I managed to finish off my Weapon Upgrade UI, and it is FULLY functional and VERY easy to expand if needed. But more on that another time. Tonight I wanted to focus on some graphic updates.

If you've been following along, you've all seen my 'Skinbie'. He's been in the game from the very start, without any real significant changes:

Since then, I've made plans to make him some friends, and to blow him up (sorry, dude).
This simple concept of blowing up my enemies, or being able to shoot off their limbs has turned out to create a fair bit of work, but I think it will be worth it in the end. The initial tests seem promising, and I think it will add a lot to the visual style of the game.

This simply animated character has gone from a total of 9 sprites up to 77 sprites, all because of the new dismemberment mechanic.

Whenever a limb is removed, the main sprite sheet will have to be switched to the appropriate variant showing the enemy missing that limb. This meant that, unless I wanted to switch my sprite sheet animation to bone-based animation, I had to create a new sprite sheet for every possible permutation of dismemberment to the enemy, and a sprite sheet containing the zombie's individual body parts (so I can send them flying).

Anyway, I've made those sprite sheets, as well as one color variant for both my Skinbie and Crow enemies. Here they are:

Enemy Variants


I created these originally just so limbs could be shot off, but I think I'll randomly select from them while spawning just to add some variation as well.

Because my large zombie monster (Slenderbie I call him) uses bone based animation, I won't have to create all of these variants for him. I'll just be able to do a straight color swap on his sprite sheet.

Speaking of color swapping:

Palette Swap in Photoshop for Pixel Art

The GameDev.net community has given me quite a bit in terms of ideas and motivation in the form of comments on these blog posts. I think it's only fair that I try to give a little something back by sharing some tips/knowledge when I can. As such, I'll be providing a brief tutorial (targeted at complete Photoshop beginners, but, hopefully, useful to many) on swapping a color palette for pixel art in Photoshop (with more complex tutorials/explanations to come in the future :)).

The first thing you need to do (after opening the graphic you're going to be editing in PS) is to merge all of your layers.
This is done by simply highlighting all of the layers you wish to merge, right-clicking and then selecting "Merge Layers":


Next, select the Paint Bucket Tool by pressing 'G' by default:


This next part is very important for minimizing the amount of work, and the number of clicks you have to make.
As per the above image, make sure that Tolerance is set to 0 and that Contiguous and Anti Alias are both unchecked.

  • Setting the Tolerance to 0 will ensure that you only switch out EXACT colors.
  • Un-checking Contiguous makes it that ALL instances of the color that you're changing will change with a single click (regardless of whether they're touching or not).
  • And, generally, any time you're doing pixel art, Anti Aliasing is bad. You want full control of your pixels, so you don't want the extra semi-transparent and off-color pixels that Photoshop will generate when anti aliasing.

    Now, select one of the new colors you want to use from PS's Color pane, and click on any pixel of the color you wish to replace:


    Voila! With only a single click, you've replaced every occurrence of a given color in your image.

    Continue picking new colors and replacing old ones in this fashion until you've changed all the desired colors:


    If you've only got a single graphic which uses the colors you've just replaced, then save out your graphic and you're done!

    However, if you've got a series of graphics which all use the same palette, you can set up a pixel palette layer to make switching colors (slightly) less painless.

    Create a new layer, select it, and select the Eyedropper tool ("I" by default):


    Use the eyedropper tool to sample any color in your new image, then select your pencil tool ("B" by default):


    Ensure that the pencil's size is 1 and it's hardness is 100% (I've found this is the easiest way to set up a pixel brush for pixel art in Photoshop):

    Then, place a single pixel of the color you selected in the new layer. Repeat this for each and every new color in your image, creating a single line or a square in an empty space out of the pixels:


    This line or square (5 pixels in my case), is your new palette. Now, for each graphic that uses the same palette, open the file, duplicate your palette layer into it to use for easy color switching via the Eyedropper tool, and use the Paint Bucket Tool to switch the relevant colors.


    Ta-Da! Your done!

    This was the quick and dirty approach to swapping my colors, and it didn't take me that long. However, if an action could be set up to replace the colors and run through Batch->Automate to update all graphics using the same palette, it might be worthwhile depending on the number of graphics to be updated. I spent a short amount of time trying to set up this kind of thing, but it was a bit problematic. Maybe a future tutorial: Pixel art Palette Replacement through Batching in Photoshop?

    That's it for now. I hope this (somewhat basic) tutorial helps someone.

    Next Time

    • UI Update
    • Tutorial on both automatic and manual setting up of UI grids in Unity.



      I still need beta testers! The more the merrier!

      Beta testing will begin NO LATER than Saturday July 16th at 11:59 PM ADT.
      Beta testing will grant you the following perks:

      • Your name in the credits
      • Input on the development of the game
      • Me thinking you're awesome
      • You being awesome
      • Knowing you helped make my game more awesome
      • AWESOME!

        The 16th is only 26 days away! I'm aiming to have beta ready BEFORE this date, and would love to have a list of testers ready to go should I meet my goal of finishing early.

        If you're interested, PM me with your preferred contact info.



Playtester Signup

Very quick update tonight.

Aside from some polish and some additions to help me get a sponsorship on the game, the core functionality is almost done.

The bare minimum left to do to make the game fully functional is to make the Abilities and Achievements UI, tune some variables and define my waves.The UI tasks I figure will take about 1.5 nights each, roughly defining the waves and tweaking values will probably also take about a night and a half each (for the first iteration at least). I also want to add a few enemy variations. Hopefully only one or two night's work at the most.

After those tasks are done, it's a matter of fine play-tuning, adding some polish and effects (sounds, particle effects, an Extra Cash UI linking to a tentative sponsor Facebook/Twitter page, as well as my own pages, and an intro.)

Because I'm so close, and because I've said I've been close in the past, I'm setting a firm deadline for playtesting to begin.

One month from today at the very latest, on July 16th, I will issue links to anyone who is interested to play test the game. This means that I need ALL functionality present by this date (no sense beta testing a partial product right?).

Anyway, I'm beginning to ramble.

All I want to say is: if you want to playtest, either leave a comment or shoot me a message and I'll add you to the list.



Things are coming nicely, and it's finally starting to look like a game, instead of just a bunch of pieces.

Since my last update, I've done quite a bit, including some major refactoring, UI Design, setting up a pixel perfect camera, modifying graphics and experimenting with exploding enemies and blood effects.


First off: when I'm coding, I'm very much in a trance, and I have a bad habit of thinking that I'll, "Just make it work first, then make the code pretty later". All too often, I'll get carried away and don't take the time to do the second part. As a result, I actually had lines in my code like stats.UpdateUI(). I think that one method call speaks volumes.

I set up probably half a dozen new classes (including UI, Audio and Shop Managers), and the project is, once again, pretty maintainable.

While I was refactoring, I was curious how other programmers work. Do you guys actually spend a lot of time on design before actually beginning implementation? This was pounded into my head in college, and I definitely see value in it, but I often find myself thinking that it's just too hard to plan for everything up front.

It seems to me that, for a smaller game like this, just having a small design doc roughly outlining things and kind of winging it during development is okay. But for a bigger project, much more time should be spent considering code structure, etc. What are your thoughts on this?

Pixel Imperfect

After I refactored, I played the game for a bit, microanalyzing every detail, and it occurred to me that the pixel art in-game looked like shit. Some pixels looked okay, while others were more like rectangles than squares. I think this was a lot more noticeable because I put a 1 px black outline around all of my enemies.

I did a lot of googling, researched some pixel perfect camera assets, and scared myself shitless that I didn't plan for this and wouldn't be able to make it work. After fiddling with settings and third-party stuff for a couple of hours, the art that I had spent so much time making look crisp and clean still looked like garbage. Considering the fact that I'm hoping for sponsorship for this game, I almost felt like throwing it out.

But I persevered, and managed to get everything looking sharp.

For any who are interested, here are the settings I had to tweak to make sure everything rendered properly.

In my sprite's import settings, I set the Pixels Per Unit (PPU) to 100 (this becomes important later), set the Filter Mode to Point, and the compression to True Color.

These definitely play an important part, but they're pretty easy to figure out. The next part took some tinkering.

The key to sharp, squarely rendered pixel art in Unity, is to ensure that the vertical resolution of the game, the camera's orthographic size and the sprite's PPU and scale are compatible.

Basically, you have to make this equation true: R/P = O (where R is vertical Resolution, P is PPU, and O is orthographic size).

In my case, I have a vertical resolution of 600, my sprites have a PPU of 100, and so, I set my Orthographic size to 6 (600/100 = 6).

This got things looking better, but, I had one more thing to sort out (and this was my most important lesson).

Stupidly, when I was creating my art, I didn't scale each piece relative to each other, I figured I would just scale the gameobjects as needed. Nope. Big mistake. My zombies had a scale of 1.73..., my bike had a scale of 3, my player 1.5... Needless to say, this resulted in crap graphics.

I've found that, generally, any power of 2 scale will work fine, but in some strange (and by fluke) cases, scales like 1.5 also work. So, I had to rescale all of my sprites and tweak my physics and variables to account for the new scale. A lot of work because I didn't have the best foresight.

Here are some before and after shots of the motorbike:



Huge difference, right?

So, the moral of the story is: Create your art to scale if you're using pixel art.


Also, the other day, because some of you said it would be cool, I started experimenting with enemies whose limbs could be shot off.

I'm on a different machine right now, so I can't share examples of the experiments, but I think they'll turn out nicely.

Each limb of certain enemies can be shot off, and, if killing enemies with shotguns, they'll explode (into all separate limbs) upon death.

Each limb will have a particle system attached which spews red pixels from it in a very excessive anime/kill bill style. The particles will also collide with other game objects, which gives a nice effect. There will be lots of blood.

As an aside, I was lucky that 2d particle collision was JUST added to Unity in the 5.3.5 release in May (though the physics around the collisions still seem a little buggy).

UI Stuff

Lastly, tonight, I've been doing some more UI design, and if anyone would be so kind as to share some constructive criticism, I would appreciate it.

Tonight I mocked up the weapon purchase/upgrade screen. Here is the progression:

Player presses a key to open the menu:


Player clicks the AA-12 weapon:

Player clicks 'BUY':

Player clicks on the Damage upgrade:

What do you guys think?


Nearly There

I'm still working away on this. I think I've managed to improve my work ethic quite a bit, and as a result... I'm seeing results. :P

Check out this short gameplay video to see some new features, including the starts of a UI, some background graphics (from openGameArt.org), and some new enemy graphics.

I still have a few placeholders in there as you can see, but I have the graphics for them. Once I add the UI functionality and define the waves, the game will pretty much be done.

However, I've decided to add achievements as well. I figure the value they will add to the game will far outweigh the level of effort. Really, it will be as simple as adding another UI menu and tracking player stats.

A friend also pointed out that my crow has a black outline on the graphic, while my others don't. I'll have to either remove it from the crow, or add it to the other characters. What do you guys think?

Also, what do you think about the tall running guy? This animation was a bit of an experiment. Everything else uses plain spritesheets, while the new guy uses a combination of sprite sheets and bone-based animation. I might tweak his animation a bit, but I might just be nit-picking. I'd really appreciate some feedback from you guys on this one thing in particular.

That's pretty much it for now. Stay tuned to these journals, I'll be looking for playtesters pretty soon!


Wow... It's been over a month since my last post... Craziness.

Anyway, just wanted to drop a line to say I'm still alive, and making pretty good progress (though, of course, I still wish I'd made more).

I've been working strictly on graphics this last little while, and I had a pretty good streak going. That's been broken about this past week, however. Overtime at work and just the every day grind of life has gotten in the way a bit.

Anyway, time for some good stuff.

I've got all of my weapon graphics done:


Oh, shit. Nevermind. As I was making this collage I realized I missed one :angry:

Ah well... They're all almost done. They probably took me longer than they should have, but towards the last graphics, they were only taking twenty or thirty minutes, down from about an hour a piece at the start. A couple could use some additional shading, but not bad considering this is my first pixel art experience. I think I'm learning quickly.

I figure I'll stay on the graphics for the time being. I've got all my UI icons complete as well (I might post those another time).

Now I need to do a 9mm, Motorbike, two more animated enemies (more if you count color variations), and I need to use shrunken versions of the above weapons for my character to hold (I'm hopeful, but I doubt that simply resizing will work...), and then I can get back to my bread and butter... coding.

Stay tuned.


Live streaming tonight

Just a heads up to anyone who might be interested: I'll be streaming my development live tonight on twitch in just over an hour, at 10 ADT (Atlantic Daylight Time).

I'll be working on some pixel art, tweaking an enemy animation, and possibly building my game's Store/Upgrade UI.

Go to my CHANNEL to watch, and maybe even influence the direction of the game!


[font=arial]I can see the light at the end of the tunnel... The project is almost done, but I'm struggling to sit down and get it done.[/font]

[font=arial]I think pretty much all I've gotten done since my last update (which seems like forever ago) are some graphics:[/font]


[font=arial]Here you can see icons for all the different health and ammo pickup types (which will also be used when purchasing items from the shop), as well as icons for skill and weapon upgrades. I still have to polish these a bit and do a few more graphics.[/font]

[font=arial]That's pretty much all I have for updates.[/font]

[font=arial]In the mean time, let me ask everyone a question: How do you stay motivated?[/font]

[font=arial]I'm sure I'm not the only one with limited free time who struggles to actually utilize that time to work on their games.[/font]

[font=arial]I recently played "The Beginner's Guide" by Davey Wreden Matthew, the creator of "The Stanley Parable", and I won't spoil it, but it seems like I'm not the only one with a love/hate relationship with my games.[/font]

[font=arial]My particular situation is this: I work 40 hours a week, and have kids to watch when I come home. I get up at 5am, get home around 2:30, put the kids to bed around 9 (if I'm lucky) and the rest of the night is a mix of folding laundry and free time. I usually am in bed around 12:30.[/font]

[font=arial]If I'm lucky, I'll get 2-3 hours of actual free time, but it's usually more like 1. And after everything is said and done, my energy level is such that I would rather sit down and PLAY a game than make one. Of course, this always makes me feel like shit, because deep down, I WANT TO MAKE GAMES! Not to mention that I'm always doubting my abilities as a developer. Quite often I'll see an awesome feature in a game, and if I have no idea how they did it, I'll also feel like shit.[/font]

[font=arial]But, I just tell myself that I've only been at it for a couple of years, only been out of college for one year, and that my current work is a lot better than it was when I started. That helps, but the idea that I suck, or am naive in believing I can actually be a game developer is always gnawing at me. I almost feel delusional at times for pursuing the dream of making money from my games, or that anyone will want to play them, or think that they're good[/font]

[font=arial]. [/font][font=arial]Does anyone else struggle with this?[/font]

[font=arial]It also makes it difficult that, after I've stopped a development session, my mind takes quite a while to cool down (I get an adrenaline rush or something, and my mind races, making it difficult to sleep).[/font]

[font=arial]I guess one possible solution is to do the game dev as soon as I get the kids to sleep, set a time limit (an hour maybe), and then do the boring laundry. I guess that would let my mind cool down and also help resolve the low energy problem (to some extent).[/font]

[font=arial]I also used to write quite a bit of fiction, and it seems the biggest hurdle (at least for me) when it comes to creating (whether writing or making games), is just sitting down and starting. After I've forced myself to do that, it usually just pours out. [/font]

[font=arial]I've also started streaming on twitch when I develop. I don't usually get much of a turnout, but it does make the experience a little more fun.[/font]

[font=arial]I guess while I'm here, I'll make a promise to anyone who cares to stream some development starting tonight (March 23) no later than 10pm Atlantic Daylight Time (ADT). In other words: I will be streaming tonight at 10pm ADT. You can find the stream by searching JEJoll on twitch.tv.[/font]

[font=arial]Let me know if you plan on tuning in. (Do it! Maybe I'll incorporate your input into the game).[/font]

[font=arial]Anyway, how do you struggle (or not struggle) to make your games?[/font]


It's been a while since I've done an update. I had a bit a of no-development period (about a week maybe). I was just too busy.

But in the last 3 or 4 days, I've gotten a lot done.

I fixed a bug where bullets were bouncing off enemies when they should just be destroying themselves (apparently the easiest fix was applying a full-friction physics material to my enemies), added two new enemies (functionally at least, they're still placeholder graphics), fixed some issues with item drops, and got the framework for the enemy waves (which was probably the largest amount of work).

Here's a screen shot of my SpawnerManager inspector, which I'll be using to define each wave:c1cef.jpg

This might not be the prettiest thing, and its designed pretty specifically for this game, but it will do the trick. With it, I can easily enable or disable a spawner for a given wave, as well as set the number of total enemies to spawn for the wave, the idle time after each wave, and the random delay ranges for each spawner.

This way, I can easily introduce new enemies and/or crank up the difficulty on a given wave. It should make play tuning fairly painless.

Basically, my spawner manager will pass the values from each wave to each corresponding spawner at the end of each wave.

Right now, my last wave just has a ridiculously large number of enemies to spawn (like 9 billion), so the game will run forever. My final solution, however will most likely be to create all of the 'play-tuned' waves that should be needed for the average player to complete the game using the inspector, then dynamically add to the list when the last wave is reached, randomly tweaking values to make them more difficult as the waves progress.

As I mentioned, I've also added two new enemies: A 'Slenderbie', inspired by Slender Man, and a Crow.

The Slenderbie is really tall, and can't be jumped over or walked through (unlike the regular zombies). If the player touches him, he is knocked back. This significantly increases the difficulty of the game, as the player can no longer easily get away from zombies (at least until they unlock double or triple jump).

The crow flies in from either side of the screen, basically just patrolling back and forth. When it is within a certain range of the player, it will dive on a parabola. If it touches the player, it will attack him, flying continuously around his head until it is killed. The player can jump over the crow to avoid this, again, adding to the difficulty and tension of the game.

These guys are particularly hard to hit with single-projectile weapons (like a rifle or pistol), especially while they're attacking, and the weapon of choice for dealing with them is a shotgun.

I think I'll add another version of this guy who comes in with a different color. While he's attacking the player, the player can't jump, and has reduced movement speed.

Here's a shot of the crow mid-dive, and flying around the player:


Now I've got to get my upgrade/levelling UI designed and implemented. I've been kind of dreading that, but hopefully it's bark is worse than it's bite. After that's done, I can playtune, ensuring the player has enough money/XP to buy new weapons and abilities as the waves get harder, and that the waves get harder at the right rate.

After that's done, I'll add some achievements and stat tracking. Lastly, as far as coding goes, I've got two main bugs I've got to squash. The first is an issue where, when the cursor is close the player, shots are VERY inaccurate. If the cursor is over the player, projectiles fire in completely random directions. To fix this, I'll have to completely revamp how weapon inaccuracy is determined, which will be a bit of a trick.

Right now I add a random value to the cursor's x and y position to determine the direction of a projectile's velocity. I can keep this method, if I add a modifier to the random value that's equal to the percentage of the cursor's maximum distance from the player (I think this will be the easiest, but maybe not the most practical).

Secondly, I use a trailrenderer on my projectiles. They move very quickly, and I really like the effect the trail renderer gives. Alas, apparently there's a bug in the version of unity I'm using (5.3.2f1) (https://issuetracker.unity3d.com/issues/trailrenderer-flickers-and-does-not-render-at-all-times) where trail renderers that share a material will sometimes flicker, or fail to render at all. I've tried dynamically creating materials at runtime, but that slows things down like crazy, so it won't work.

The page says it's fixed in the newest version, so I'll try updating and keep my fingers crossed. If not, I'll have to come up with another solution (firing a steady stream of particles from the rear of the projectile to achieve a similar effect?)

Let me know if you have any ideas.

Then, last but not least, I need to do a graphics overhaul. The player is the only complete graphic. I need to add 1 or two frames to my zombie, make my slenderbie and crows, weapons and all UI icons. I'll probably find something on OpenGameArt for the background and road.

After that, I'm done!

Once I get the Upgrades and Bugs done, I guess I can get some playtesters. Anyone interested?


Spent quite a bit of time tonight. Cleaned up a few things and got my enemy spawners and item drops working as well as a 'coin magnet'. Also, See below for a video of some gameplay.

For my item drops, I wanted to be able to assign a list of prefabs that the enemy could potentially drop in the inspector, as well as the % chance that the item would be dropped, and I wanted to do this so that the prefab name was right next to the % chance in the inspector.

The way I wound up doing this was created a DropItem class with the Serializable attribute, and simply gave it one each of public GameObject and float properties:using UnityEngine;[System.Serializable]public class DropItem { public GameObject dropItem; public float chance; }
That's the whole class.

Then, in my Enemy class, I created an array of DropItems and now my inspector looks pretty much how I wanted:

I realize that I could have customized the editor, but this works pretty well.

I've been thinking about what my different enemy types might drop, and it really seems like it will all be pretty much the same stuff I have already. I don't think I'm really going to implement any special items. I might throw a couple of larger money drops, but that's about it.

Also, you might notice there's only 1 pickup each for Ammo and Health. I'm going to make it so that the ammo pickup either adds to the ammo type for the currently equipped weapon (at time of drop), or to a random selection from the currently unlocked weapons. I haven't decided yet.

The health will be semi randomized between two values.

So that's great. Drops are working perfectly, except that Ammo and Health are just empty GameObjects with a Sprite on them at the moment. Won't be hard to finish them up though.

The other thing I managed tonight was to get my Spawner objects created. Each spawner takes a reference to a prefab that it will spawn, and has a min and max spawn time. After each enemy is spawned, the time until next spawn is set somewhere between those two points. These guys were easy, and are done as far as I'm concerned.

However, the whole wave-based play isn't done yet, and I'm going to ask for some thoughts on this. I've never implemented wave-based play before, so I'm not sure how to best approach it. The best idea I have so far is this:

I will create a SpawnerManager class which will have a reference to each spawner in the scene (I think that I can get away with a spawner on each side of the screen for each enemy type and just configure their random delays for play tuning) which will control the spawn speeds of each spawner, whether or not they're disabled (to enable/disable different enemy types for a given wave), and the number of enemies that should be spawned for the given wave.
For the first X waves, I will hard code the number of enemies in each wave as well as the time between waves (when the player will shop and upgrade). Also, I will manually enable or disable different spawners of different enemies on the first X waves, adding a progressive feel to the game. This will let me ensure a somewhat consistent experience for each user playing the 'main' part of the game. During these 'hard-coded' waves, I may also manually reduce spawn delays and time between waves as well, but more likely, I'll come up with some equation for a decent curve.

Because the game will have a number of weapons that can be bought and upgraded, as well as a number of skills and achievements, I want to give the player the opportunity to play potentially forever so that completionists can have their cake and eat it too. Not to mention that the game isn't beaten until the motorbike is repaired, which is a manual action by the player so they can choose to wait forever to repair it anyway.

In order to do this, after the first X waves, I'll use curves to automate the spawn numbers, delays and time between waves.

Does this seem like a decent approach?

Also, while I was testing my spawners my frames per second went from a steady 60 way down to 7. I knew something wasn't right, but I wasn't all that surprised with hundreds of enemies and projectiles on the screen.

I started commenting out some code, deleting game objects while the game was running, etc. to try and solve the problem. Turns out the problem wasn't with my spawners or enemies, but with my coin pickups. See if you can find the offending code: void Update() { rotateTemp.y += Time.deltaTime * spinSpeed; transform.eulerAngles = rotateTemp; AttractToMagnet(); } void AttractToMagnet() { float xDiff = Mathf.Abs(transform.position.x - stats.transform.position.x); float yDiff = Mathf.Abs(transform.position.y -stats.transform.position.y); if (xDiff <= stats.magnetStrength && yDiff <= stats.magnetStrength) { transform.position = Vector3.MoveTowards(transform.position, stats.transform.position, moveSpeed * Time.deltaTime); } print("hey"); }

At first glance, I thought, "Mathf.Abs() can't be that complicated... Maybe MoveTowards()?" Nope... it was print("hey"), which was just a test that the method was executing that I forgot to take out. Apparently, any more than 5 objects printing out every frame, and the framerate starts dropping like crazy, about 2 fps per object. Had a good laugh about this one.

Anyway, that's what I got done tonight. Check out this VIDEO with some descriptions of what's going on.


Last time I made an entry I said that my next task would be to have enemies drop items, and to create enemy spawners. When I opened my project, I started looking through my code and wound up refactoring quite a bit of it.

By the end I had 3 or 4 new classes, making all of my classes quite a bit leaner and more maintainable. However, one of the solutions I came up with to better handle UI updates still doesn't feel quite right.

My UI basically has 4 main elements: Health, Experience, Weapons and Money. The first three utilize a slider to visualize % of health remaining, % XP to next level and % of weapon capacity currently loaded, respectively. The fourth simply shows the user's current amount of cash (Placeholder icons):


I had two main ideas for a solution. The first was to create a class for each group of UI elements (one for health, one for XP, etc) and to simply have them update the sliders and text each and very frame using a reference to either my Stats (of which there is only one of in the game, as an instance) or WeaponController (of which there is one for each different weapon) objects. Stats holds player variables like health and XP, while WeaponController (which maybe should be split into Weapon and WeaponController classes) contains weapon variables like capacity, roundsLoaded and roundsOwned.

This, to me, seemed like the optimal design choice. It had the least amount of complexity and seemed like it could cause the fewest number of problems. Essentially, the UI elements would stand alone, and even if they were removed from the game, nothing would break. Also, it would be the easiest to write this way.

My second option, the one I chose, was a little more complex, but, I think, more efficient. However, as I'm writing this, I'm beginning to think I made the wrong choice. The reason I even came up with this option was because I was thinking about efficiency. Having the UI elements just update 'magically' on every frame is easy and clean, but maybe a little wasteful. I decided that it would be more efficient to have the UI elements only update when needed, i.e. when stats change.

At the time, it seemed to me that good design is just fine, but it should be tossed out if a more efficient solution exists. Now, I realize that the complexity of simply updating UI elements isn't going to be very CPU intensive, but I figured every little bit of CPU savings helps, so this is the solution I went with. I still have a class for each UI group, as in my first solution, but these classes do not have references to my instance(s) of Stats or WeaponController. Instead, Stats has a reference to HealthUI, CashUI and XPUI, and WeaponController has a reference to WeaponUI.

Any time a player takes damage, gains cash or gains experience, the related code winds up leading to methods in Stats, which complete all the appropriate actions, including making calls to the UpdateUI() method in the relevent UI Manager object (HealthUI, CashUI, etc), passing itself as an argument. So, for example, Stats' TakeDamage() method looks something like this:public void TakeDamage(){ //do some stuff ... healthUI.UpdateUI(this);}
The same goes for the calls to the other UI Manager objects. They all take a reference to Stats as an argument (except for WeaponUI).

WeaponController functions similarly, passing itself as an argument in its calls to WeaponUI's UpdateUI() method.

Thinking about this now, it seems like I've chosen an overly complicated solution with little to gain from it (only slight efficiency benefits), and it seems like the cons far outweight the pros (for example, removing the UI elements will now break the game). Also, it stinks of circular dependency.

I think I've answered my own question, but what do you think? Which option would you have chosen, and do you have any better solutions I didn't think of?

I was going to post some questions about the design of my game's enemy spawning mechanic as well (yet to be implemented), but this post has gone on long enough, so I guess I'll make a second entry for that this evening.


Been Sick - Win Condition

**NOTE: This post was a little longer than I intended. If you don't want to read everything, there're some interesting things about enemy types and game titles near the end. Cheers!

I've been really sick all weekend. I'll spare the gory details. Suffice to say I was unable to do dick all until tonight.

Got some decent work done tonight though (I spent a little over an hour I think):


I've got the motorbike in place and functional (the graphic is placeholder). The bike triggers a win condition when fully repaired (which is indicated by the gray bar above the bike), and I think I've taken into account and implemented every different possible scenario as far as interaction with the bike goes.

Basically, I want the player to only be able to interact with the bike if he's doing ABSOLUTELY nothing else, and is standing in range. If he's firing, or being attacked, or moving at all, he cannot repair the bike, and he is forced to stop repairing if he was doing so when the new action occurred.

Also, repairing the bike spawns the yellow text you see, which indicates how much the bike has been repaired.

I also set up the required code so that the bike is repaired at the appropriate rate (taking into account any repair bonuses or modifiers the player currently has), so I think that all I have to do for the bike is make the graphic and have the win condition actually trigger an animation of the player driving away or something.

In my last post, I mentioned that I would put some code up here. I've been thinking about the structure of some of the code, and I already know I need to change a few classes (I've got some ugly static stuff going on that seemed like a good idea, but doesn't really make sense, etc.), so I'll probably do that first.

Additionally, I've gotten some comments that posting my code in bulk might not yield the best results as far as feedback goes, and I think I have to agree. So, I'll probably pick out a few interesting/troublesome/complex pieces to see if anyone has any ideas about how to better/more efficiently/more elegantly solve the problems. If for no other reason than for fun and to learn a bit more.

You might also have noticed the Facebook and Twitter text in the corner.

I just stuck those in as reminders to add incentive buttons into the game. Essentially, if they like (or at least visit) my Facebook or Twitter pages (yet to be made), they'll get a bonus of X coins for each. I hate social media, but I guess I can't complain about free advertising.

I guess since I've touched on business a little bit with the social media thing, I'll mention that I've yet to decide on a name under which to publish my games. I guess technically, since I'll be selling/marketing/hopefully earning income on these games, even if only on free-to-play online markets, it's technically my development company's name that I have to decide on.

Maybe I'll post some candidates for the name and see how the community reacts. Can you create polls in these journals?

Additionally, I'm going to have to settle on a title for the game.

Originally I was thinking 'Night of the 8-Bit Dead' or 'Twenty 8-Bits Later', to speak to the pixel style graphics, but they're not quite 8-bit, so I don't think it fits.

I had a couple of other titles in mind that I forgot, so they must not have been that good. The only one I have floating around at the moment (which occurred to me today) is 'Dead Pixels'. Kind of a play on words. What do you think? Let me know.

I might stray away from the whole 'Zombie' theme though. That's essentially what the game is, but I might introduce different enemies that don't really fit that 'Romero' description.

Two enemies I've been thinking about are a flying enemy (I think it will be a crow), which will fly in quickly and attack on a parabola (making it a real pain in the ass to hit), and another is a Slender-man inspired enemy that will be tall, tough, and impossible to jump over unless you've unlocked double or triple jump. The Slender Man type enemy will really introduce some challenge, as a key way for the player to avoid the large groups of zombies (which spawn on either side of the screen) is to jump over them. The 'Slender Men' will function as sheep dogs, essentially restricting the players movement, making it much easier for the zombies to overwhelm him.

But I digress. My point was: If the game isn't strictly a zombie game, a zombie type name doesn't make sense any more. So that might open some new possibilities.

My next task will be creating the enemy spawners and having the enemies actually drop cash. That shouldn't take too long, so I might create the health and ammo pickups as well, and implement their random drops by the enemies as well.

Wish me luck.

P.S. If any of you ever have any suggestions, or see anything that looks like particular shit, do me a favor: tell me!


Small Update - Health UI

Just a small update today. Got in ~30 minutes last night. Health UI is working.

Motorbike tonight.

Also, I might regret this, but I was thinking about posting all of the code for this game and letting everyone pick it apart. See what you all think is terrible and could be improved.

Maybe I'll do that tonight before I start development again.


Some things came up preventing me from working on the project for a couple of days, but I was able to get my base AI, health and death working (mostly).

I've noticed a few unwanted behaviours caused by Unity's physics engine and my projectiles where they'll sometimes hit an enemy and ricochet in strange ways instead of just disappearing like they're supposed to. I leave fixing that for clean up after I've implemented the rest of my features.

But I've gotten a simple AI that all (or most) of my enemies will inherit. They basically just move within a certain range of the player and continue to attack until he's out of range, at which point they begin to move again.

I've tested the behaviour with a large group of enemies, and it all seems fine. The enemies overlap one another, and visually I don't much care for this, but I'm not sure there's any way around it if I want to allow multiple enemies to attack the player at the same time (which I do). Maybe I'll add a semi-random hue to the enemies' sprites when they're spawned just to spice up how it looks a bit.

The player spawns indication text similar to that shown in my last post when he's taken damage. He also actually takes the damage and dies (destroys his own gameObject for now) when his health drops below 0.

Haven't had the time to code the UI to display health correctly yet, but that should only take five minutes (I probably just jinxed myself...)

Anyway, it's coming along. I think this journal thing might be helping a bit.

Hopefully tonight I can get the health bar working. After that it's spawning cash pickups on enemy death with a chance of ammo or health pickups being dropped.

Once those things are finished (hopefully one development session), I'll work on the motor bike repair. After that's done, the core gameplay mechanics will be in place and all that's left to do is add the levelling/upgrade functionality (I think the design will take longer than the implementation on this one), add different enemies and create the rest of the graphics.

If I'm lucky/diligent, hopefully I'll be done this bad boy by the end of February.


So, here's my first entry on any dev blog ever. I find it hard to stay motivated in making my games, and to find the time, so I figure a regular journal will help quell that problem. Might as well give it a shot.

I've been making games for about 3 years, during which time I've published a whopping total of 0 titles. Impressive right?

I've started work on a few projects that were just too broad in scope to be realistic to complete given my current situation. Between work and kids, I'm left with an hour here and an hour there to develop, so I've decided to put big projects on hold and just make something small that I can get out there.

I'll probably post some post-mortems for some of my other projects eventually, but for now... let's get to the meat and potatoes.

For a few months, I've been working here and there on a casual 2D zombie survival shooter, with intent to release on free-to-play markets like Kongregate and ArmorGames.

The basic mechanic of the game is similar to the one found in Balloon In A Wasteland. Our hero enters the scene on a motorbike which breaks down. Your goal is to (slowly) repair the bike while surviving endless waves of zombies. Once the bike is fixed, you drive away and win.

The game will be all original pixel art (which I'm fairly new to) and relies heavily on upgrades and levelling to keep the player motivated. I'll provide a list of these upgrades, etc. in a future post, along with a Game Design Document, but for now, I'll just start listing what's been implemented.

So, here's an annotated image of what I've got so far (annotations in green text):


1. Health bar UI(non-functional)

  • I still have to program the enemy AI and loss of player health and player death.
  • The icon still needs some tinkering.

    2. Experience bar UI (partially functional)

    • The bar and its text work, but currently there is no levelling up functionality.
    • The icon still needs some tinkering.

      3. Ammo bar UI (fully functional)

      • This displays the number of rounds loaded in the current weapon, the capacity of the weapon and the number of rounds owned. Its fill also scales depending on how many rounds are currently in the weapon. The icon to the left, currently showing 9mm is placeholder and will be replaced with a nice pixel icon in future.
      • I currently have 11 different weapons including:

        • a .22 revolver
        • 9mm
        • uzi
        • 12 gauge
        • mp5
        • ak47
        • .50 cal sniper
        • combat shotgun
        • M4A1
        • AA-1 full auto shotgun
        • 5mm minigun

        • I think that'll probably be it, but I might add a secondary weapon like a grenade or molotov. Each weapon has unique accuracy (which is still a bit buggy), weapon capacity, fire rate and damage. Each weapon will each come with its own set of upgrades which can be bought with money.

          4. Money UI (functional)

          • Simply displays the amount of money you currently have. This increases when you walk over a coin (see 6)

            5. Player

            • This guy is 90% complete. I have to tweak his animation a bit, and fix some issues with how the weapon fires, but I'm pretty happy with him.
            • His run cycle: pSgDPYJ.gif
            • I have to make him lean forward in the animation, he's a bit stiff at the moment.
            • His controller is complete, and he already has some of the framework for the player upgrades/levelling that's to come

              6. Pickups

              • Currently I only have coin pickups. I have 4 of different value:

                • 1
                • 5
                • 10
                • 25

                • When they're picked up, they spawn text similar to that shown at #8, but in green instead.

                  7. Enemy

                  • I've only got a single enemy type at the moment, more to come. I've tentatively named him 'Skinbie' for Skinny Zombie.
                  • His walk/attack cycle: DwiU0YP.gif
                  • Again, I need to tweak the animation, adding more movement to the legs and leaning him forward a bit. I took some inspiration from daggerfall's zombie for this guy.
                  • All he does at the moment is cycle through his animation, disappear when killed, add XP to the player when dead and display it's XP amount with indication text (see below).

                    8. Indication Text

                    • I've got three flavors of this at the moment. One for displaying enemy damage (shown), one for displaying cash pickup values (in green), and one for displaying XP increases (blue).

                      That's pretty much it at the moment.

                      Tonight I'm going to try really hard to get some time in and make the player's health functional and adding a death screen. That will include also getting the Skinbie's AI done (he will simply move toward the player until he is a certain distance away, and will deal damage perpetually while touching the player), which shouldn't be too hard.

                      So that's all I have to say right now... I guess before I go I'll dump a messy list of functionality I still have to implement. I'll pull this list into future posts and maybe add to it as needed and strike through it as I complete the items.

                      • Enemy AI
                      • Player Health
                      • Player Death
                      • Level Up
                      • Upgrades

                        • ?Will add list of upgrades and skills here in the future

                        • More enemies
                        • Achievements
                        • Motorbike repair
                        • Win Condition
                        • Improved icons
                        • Background graphics (pixel parallax)
                        • Improved projectile graphics

                          Leave me a comment and keep me motivated!