I am taking more of an architect's approach to building my first title. Enumerate systems, build mechanics, test them, make sure they are dynamic/modular enough to scale when I change focus to content creation. You don't need a well designed character to prototype those things. However, putting some time into doing so will not only break up the monotony of other tasks, but also will give you a better in-game feeling for the character you are building which can inform your design decisions as you progress because they need to work with the character you are playing. Also.... it makes the prototypes a little more engaging to play than running around as a blue box box or some vaguely human adjacent being.

Initially, while chugging away at my milestone list, I decided I just needed something human-like to tell myself and players that the main character was, in-fact, a human and would be capable of wielding sterotypical medieval weapons and shields and the like. So I put a little time to make it so.

proto-vic-the-viking.png

Vic was great. He would dutifully load into each playtest, swing his sword or axe through its attack chain, he would let me know when an attack felt weird or got hit something maybe he shouldn't have, he would help me get a feel for timing of attack animations/parries/etc., he would even make the ultimate sacrifice succumbing to draugr just to make sure the scene would properly reload upon death. I could not ask for more from Vic. But Vic was not without his flaws...

Vic was an eye-sore and it was time for Vic to join his kin in Valhalla.

Before redesigning, I decided to capture down what I wanted out of my main character's first iteration and to look outward for some insipration. I wanted my character to:

I jogged my memory and my steam library for 2d pixel art games I had played recently. Dead Cells, Hyperlight Drifter, Moonlighter, Blasphemous, Link to the Past (gotta boot it up every couple of years), and Iron Oath all came up on the radar. For gameplay I am leaning heavy Dark Souls with world exploration and some loot elements in a mostly top-down perspective, so I dig in to study the Penitent One and Link. OLD SCHOOL link, not all that Breath of the Wild nonsense!

Measuring competence in pixel eat pixel world. The larger a character is in relation to their world, the more competent they are generally perceived to be. If a charater is smaller than a single unit, they are meek, but if they are 4 units large, they must be a destroyer of worlds.

link-height.png

Weighing in at roughly 27 x 18, Link from a Link to the Past is by no means a giant in his world. In this story, he is young and inexperienced, pretty much a child. But he is still slightly larger than a single world tile (about 16 x 16). This gives him a little more strength in the world, but does not make him overpowering by any means. He would appear to be on par with other characters that inhabit the world which would make every encounter feel potentially like a challenge. Take for example the image below:

link-bushes.png

Link is roughly the same height as the squirrelly fellow on the left, and the are both slightly taller than a bush or ground tile (tiles are outlined in black in this image). This gives them roughly equal competency in the game world, and boy is that guy tough to catch until you find a break!

Crank up the competentce by taking a look at the Penitent One.

penitent-height.png

The protagonist of Blasphemous is much taller at about 72 pixels tall. His world, while side-perspective, is smaller in comparison with tiles appearing to be about in the 32 x 32 range. Other people in the world are often smaller than him, as are many of the typical enemies.

penitent-charging.png

In the picture above, you see the Penitent One facing off against a regular enemy. The enemy appears to be about as tall as the main character in the shot, but you can see that the character is squatting in preparation for an attack indicating he is actually larger. This helps makes the player feel powerful. Height, along with the prowling stance of the Penitent One make him seem like he is very much in control of the world around him... which is actually somewhat dissonant with the gameplay if you are as bad at it as I am.

How do we get closer to link's size, but with the Penitent One's more realistic look?

link-penitent-compare.png

Looking at the two characters side by side you can notice some things beyond the obvious proportional differences. Link has a black outline around his major features like his hat, face, arms, torso, and legs which give create a lot of contrast but make him look like a cartoon. Penitent One has little to no black and no outline present. Link's colors are very saturated and bright while Penitent One is more muted and the light to dark range is lower. Penitent One has more room on-screen dedicated to showing the shape of various parts of his body, clothes, and armor while link is more of a chibi silhouette with a few details to make him recognizable.

Let's take a crack at blending the two styles!

viking-height.png

This Favored Son of Odin is roughly in line with Link's height ratio sitting at about 50 pixels tall in a world mostly constructed with 32 x 32 tiles. Most colors I chose are low contrast with each other, which I am hoping will add weight to more saturated shader effects to communicate special statuses and states. His body does have some shape to it. but it isn't so detailed as to be pushing for any degree of photo-realism. To fit the top-down perspective you will notice that more real-estate is dedicated to his head, torso, and arms than his legs and his feet are presented more as being seen from the top of the boot.

I still felt like I had limited real-estate for his head and every attempted hairstyle failed to really communicate 'Viking' to me, even with the bare chest and tattoos, so I decided to grant him a horned-helmet. I know, it was part of my 'success criteria', but after working on it a bit, I can feel the helmet growing on me. The curve of the eye slots lets me communicate a degree of intensity that I was missing and the horns give me a little more room to play with the silhouette.

There is definitely some more refinement of the character to be done, but this iteration should carry me through the rest of my prototypes and maybe even a demo. Keep an eye out for more visual updates in a future post!

A Hyrulian, a Norseman, and a Zealot walk into a bar... a look into the process of designing a pixel art protagonist.

Designing a Pixel Art Protagonist

My first year of unity was spent learning the basics of the engine. I framed everything in terms of the first project I have envisioned. Working from a list of the systems required to deliver that vision, and a list of the mechanics to support those systems, I would script a mechanic somewhere in my codebase, test, and iterate until I felt good about the way it felt then move on to the next mechanic/system. This has been a great way to learn the basics of things like 2d movement, collision detection, leveling, pathing, etc. and to learn them in a way that directly benefit the specific goals I am working towards in my 2d Action RPG.

All was well and good with this workflow as it took me to my first playable prototype. Some choice victims got selected to do a playtest on a test map (made with a purchased tile set) and 1 enemy type on infinite spawn - 'Your presence has awoken the vengeful dead' ;p. Feedback came in from these helpful folks, a spread of gamer to game-acquainted, and the general consensus was that my main system felt good, but the areas I knew were a little suspect were indeed suspect.

To me, this was a massive win. It showed that I had a solid foundation and my internal compass was pointing me in the right direction.

At this point I took a second to step back and plan again. I asked myself a few questions:

My answer to these questions was MORE ENEMIES. They need reasons to use the mechanics I have built and a few tweaks to the mechanics themselves. The best way to do this would be to make new enemies and situations that would challenge the player into using the mechanics at their disposal. So I sat down to make a new enemy and this is when I realized I had a problem. My code was set up roughly like this:

spaghetti-architecture.png

All of my code related to enemys was in 1 big wad of spaghetti called Enemy Controller that was over 1000 lines long. It included a state machine that drove both behaviors and animations, stats, current resources, movement, etc. etc. To make a new, unique, enemy I basically had to write a whole new Enemy Controller for each enemy. If your not a programmer, let me tell you, this is very bad. It's lots of error prone work that is likely to introduce bugs unique to any new enemy. At this point I decided to go heavy into architectural design and refactoring.

My process here was examine the player and enemy controller code to find the individual components that made up each and list them out in some boxes in a diagraming tool. I started by looking at things that were shared between the enemy and player, stats and animations stood out. So I turned stats into a new class supporting a component and just pulled the state/animator a separate component. I also added an interface to the player and enemy controller modules so I could start consolidating the methods in which attacks and interactions were handled between the two entities.

architecture-Controllers-R1.drawio.svg

Doing this indeed created a stronger separation of concerns which would make it easier to create new enemies with similar animation states. I could also now set up unique stats for each enemy type with very little effort. I know enemy behavior is still a big part of my controller, but at this point I can't see a way to break it out effectively. To keep moving, I decided to continue to focus on low hanging fruit in the controllers. Things that were immediately obvious to me at this point were the equipment/inventory and the player input.

architecture-Controllers-R2.drawio.svg

Another good step. My player controller saw massive reductions in amount of code and its complexity, but my enemy controller was still weighted down by large amounts of behavior code. If I wanted to create new enemies I would still need to write a new controller every time... it was time to dig in and get creative.

I started by writing out a list of concepts that I felt defined enemy behavior.

I'm a very visual person, so despite writing this out I still didn't have a clear picture of how to break out what I needed. It wasn't until I was drawing the diagram and on the whiteboard in our kitchen, for my wife who is supportive, but doesn't care about software architecture, that I saw it. As I was explaining my current design in gloriously nerdy detail, I realized that my enemy controller was basically a mirror of my player controller at this point, except with behavior logic in it. The player controller has input, but all the information processing and decision making is in the player's head, the input is just the interface to make it happen. I just needed to create the enemy's brain and let it do the work.

architecture-Controllers.drawio.svg

My solution was to feed the same information a player uses to the enemy decision making modules and let them decide which inputs to return to the controller. The controller is telling the activity management system what it knows and what it is capable of, but the activity manager is calling all the shots.

In this design, activities can be largely built into their own modules and used to dynamically compose behaviors on a per enemy basis using the activity manager. Now Activity manager is the only thing that is certain to be unique to a given enemy type and I have cut out probably thousands of lines of code from my future! This won't be the last refactor, but it's hopefully a big enough step to keep me focused on content and world building for a while.

I needed to make it easy to build interesting enemies, so I spent some time refining the architecture around my characters and AI. This is how I arranged my code so I can move faster during content creation.

I needed to make it easy to build interesting enemies, so I spent some time refining the architecture around my characters and AI. This is how arranged my code so I can move faster during content creation.

Game Architecture: Characters and AI

My goals here are to allow the player to:

To do this, I need a vision system that will be blocked by walls and other obstacles and trigger enemy pursuit if the player is spotted. I saw examples of using colliders and meshes built from raycasts, but flat colliders didn't account for obstructions and meshes seemed like overkill and probably too resource-intensive for my game. So, I decided to just use raycasts to implement. Raycasts should be able to meet my needs and be relatively lightweight.

I started by placing the start point of my rays at the center of the enemy unit and then cast them out in a cone shape looking for collisions. This is where I ran into problem 1. 'Hit Collided with Enemy'... What? After a minute of debugging I identified my error, which I will illustrate below:

raycast-from-within.png

My rays were starting from within the enemy unit's own collider, which would obviously trigger a hit as it travels out of the collider. The result was a bunch of 'blind' enemies who could only see themselves :). How to solve this issue? My first approach was to simply move the start point of all the rays to the edge of the enemy unit using an offset parameter.

raycast-from-single-edge-point.png

This produced the general result I was looking for, but it felt like a slight hack and I didn't like the idea of having to manually adjust the offset for every enemy unit. But I could live with that for an intial implementation, so I decided to do some playtesting before moving on.

I am glad I chose to play it again, because I quickly realized that my enemies lacked almost any peripheral vision.

This meant it was super easy to sneak up on every enemy from the side or behind and made the game pretty trivial. Challenge is going to be core to the experience I am building, so this just is not going to be passable.

no-peripheral.png

At first I thought I could solve this problem by widening up the angle of the cone so I just increased the FOV slider in the inspector. Presto, fixed, right? WRONG.

raycast-wide-angle.png

Overall it felt a little better. Enemies weren't completely blind directly to their sides and navigating through the test area was definitely more difficult. However, you could still be standing right within smelling radius without them seeing you AND it was allowing the enemies to detect the player pretty far off in the periphery or even see around corners. Bad news.

corner-peeking.png

Here is where I decide to take a step back and draw out the problem again on scratch pad. I realize that I can probably use the center of the collider as the starting point for my calculation, but I need the actual start point of the raycast to be at the edge of the collider. 'Can I find that distance without a custom calculations?', I wondered.

At this point I turned to the unity docs for 2d colliders and I find the 'extents' property of collider.bounds. The docs explain that the extents property is a vector and is half the size of the collider in each direction, so I should be able use that to find the edge of the collider. What's that calculation look like....

cone-start-calc.png

I plug roughly this calc into each ray being cast and decide to give it another playtest. The results are exactly what I am looking for. No more enemies chillin with me just hangin out in their awkward blind spot:

no-more-blindspot.png

no-more-corner-peeking.png

With these problems solved, I am closing the book on the initial implementation of vision. I am happy with the results, am having fun playing my latest build, and am ready to move on to the next feature!

It took a bit of math, reading, and tinkering, but here is how I added vision cones to the enemy units in my first Unity game.

Player detection solely based on distance felt cheap and kind of boring. To make that more interesting and give my players some gameplay options, I decided to add vision cones to my enemy units. Here is how I went about that including some of the challenges along the way!

Field of View on Enemies

When I initially started this site, I wanted to keep the web work low complexity and cheap so I could spend my brain power and money on my game. So I went with hand built html/css/javascript, though css coming from tailwind to ease that a bit. I intially thought it was working well, but as I started to want to share my posts and have a bit more dynamic content, I realized I was copying, pasting, and modifying a ton of boilerplate HTML and small things were taking a long time or getting addressed inconsistently across my site. ALL BAD STUFF for a developer.

The combination the amount of work I needed to put in just to create a new blog post, or fix a simple error across my entire website, with the fact that I wanted to focus on my game first and foremost really demotivated me to write content here. So it didn't happen for a while.

It's been on my TODO list for some time to rebuild my site in something component-based, but it took a kick in the butt from a colleague to get me to actually do it. The kick came in the form of a commit against my site with some NEXT.js code. Thanks Daniel!

After a few days of work, I have a new site that is much easier to work with! I can now create a new blog post with a single command from my dev machine and get to writing. All the navigation and meta data is now consolidated down to a few components used across the site and I don't have to worry about anything but the content of my posts. I'm excited to get back to writing and to start sharing my progress again.

On the progress front, A LOT has happened since my last post. I have a few things to catch up on in the next few posts, but here's a quick summary:

Proof of work below, the new shield draugr on patrol.

Shield Draugr

I'd like to close this post with a dedication to start making more regular updates. With the new framework hopefully rocking away, I'll be aiming to release a new post at least every two weeks. Thanks for reading and I hope to see you in the next post!

The last six months have seen quite a bit of action, so much so that I haven't had time to blog about it. To make that easier to do, I converted my static HTML to NEXT.js.

It's Been a While.. What's Next?

Developing in pygame was a great intro to the concepts employed in typical game code. If there was something that needed to be done besides render a line/square/sprite on screen, read an input, or play a sound, I had to think it through and build that code myself! This was marvelous in a way because it pushed me to think through a lot of problems and create solutions for them. I then knew those systems top to bottom and could extend any part of them with relative ease and full control.

When it came time to move over to a modern game engine supported by a commercial developer, I found out just how many of those custom solutions were already solved for out of the box and  often with a gui element to replace what I had build solely

At first it seemed like 75% of my dev time spent  coding would go away and I would focus on design and assets. That idea quickly faded and the work was replaced with not just coding time itself, but learning the new 'unity approach' to things.

First off my workflow changed significantly. With PyGame everything I did besides art creation looked like this:

Enemy Pygame Code

While in unity, my work might start to look more like dropping in and configuring components in an interface like this:

Slime Unity Editor

I was no longer just code based, I was working in a mixed code and GUI enviroment now, which came with its own learning curve. Add to that the fact that Unity is highly customizable, so you could really ignore most of the GUI if you want and just use the engine in a mainly code-based workflow if you want, so I needed to learn where using the GUI was advantageous vs keeping my work in c#, or how to expose my scripts to the gui and prefabs to achieve efficiencies unavailable to just one method or the other. This still proves a to be a bit of a challenge as my needs evolve along with my familiarity with the engine itself and its support of component-based design over object-oriented.

Secondly, I needed to learn and relearn concepts I had already worked through in my pygame implementation. The first big retreading was the management of the game loop.

In my pygame ARPG, I could trace the execution of every event back to the the line of code in the top level of the game loop and back again because I had to build all of that. However, when you pick up unity, you realize that main loop is already baked into the engine somewhere and the passage of time is obfuscated away from you. It meant I had to be aware of my lack of control over that particular aspect while rebuilding.

The next challenge was having to dig into actual physics systems and the like. In pygame and python for my 2d game, I didn't have to think much about actual physics computations, lingo, etc. I could just say this object was going to move in this direction at this rate. No rigid body talk, no apply velocity, no active/inactive bodies, just X + 1 for N ticks of the game loop.

I am actually thankful Unity presented this physics challenge because I believe it would become necessary know at a certain point for an action game of any quality/scale.

It has taken months of learning and rework at this point, but I think I am finally at a point of hitting a development stride with the Engine, AND, I am now a more well-rounded dev because of it.

Growth is never wasted time! Looking forward to changing gears to discussing how my animations evolved during this rebuild on the next post, so keep an eye out!

The indie game engine of choice proves to be both friend and foe while converting lots of systems and code from pygame.

Jumping From Pygame to Unity

One day I sit down... I wanted to draw something Luck(?) would have it that I was just playing around with my pups and had some fun energy kicking around as a result. My dogs, you see, are avid hunters and bug catching is something they pride themselves on. That thought just stuck and I ended up sketching out my pup hunting fireflies in the backyard and it was so adorable I felt the need to capture it with some pixels.

An hour or so later I had a .aseprite file looking something like:

FCG Dog Initial

While cute, this isn't logo material. I expect a logo to be quick to read with a minimal palette. This typically means your focus should have a strong silhouette, so let's see what that looks like...

FCG Dog Initial Silhouette

The result looked... roughly dog shaped. Not spectacular though. So, it was time to look to some inspiration via some web scouring. As I search about, I notice my fellow logo artists are using negative space to define features of the subject that we might normally draw out by utilizing color differences. So I take a stab at that:

FCG Dog Second Silhouette

That definitely reads more dogly! But something is still off. The nose appears to simply be chopped off and the handkerchief as negative space makes the head look entirely detached. I play around with smaller lines and different shapes and locations for these two things but nothing looks right. At this point, I decide to convert to white (like my pup is!) and give up on a single shade as I push some grays into the mix.

FCG Dog Third Silhouette

This is what I am looking for! Just two shades in the main subject and I am seeing a dog with a kerchief. From here it is a relatively quick series of a resizing and positioning to get him onto a plaque. I push through to get text in for Fire Catcher Games (FCG), and give it the shade of light from the very firefly he was chasing.

FCG Dog Final

A couple of hours and I am feeling pretty good about this design. Looking forward to adding it to my works and eventually getting some animation behind it!

A game dev shop needs a logo. As a solo indie dev, it feels like that logo needs to be a little personal without having too much of your own identity tied to it incase you want to get others in on the action. I struggled for a couple weeks to find inspiration, but finally found a spark!

Creating a Pixel Art Logo For FCG

For years I've thought about getting into game development, but it always felt like such a mountain to climb. If running solo you need solid programming, art, music, writing, and visual design skills. Even if you are that renaissance person you still need to build a strong gameplay loop and a narrative that it works with and find the time and capital to actually to build your vision.

Though I am an accountant by education and developer by trade, my focus has been on server-side code, data collection/analysis, and business intelligence, so my starting skills don't necessarily scream 'Game Developer'. I know my way around python, sql, some shell languages, etc., but nothing in the traditional game dev toolkit. Because of that, and the aforementioned mountain, it never felt like a realistic goal for myself.

My perspective changed in a big way when I came across a tutorial video for creating a Zelda-like game with Dark Souls elements using... Pygame of all things.

The video in question was posted by the content creator 'Clear Code' on youtube. If you are at all intrigued check out his channel at https://www.youtube.com/@ClearCode. Continuing on.

'Python is an awful language to create a game in', I thought, but I was curious so I opened it up. The intro showed the end product in action and, although not cutting edge AAA 3d graphics, the quality of the game was much higher than I had really expected would be possible in a language known for being slow and having game frameworks typically used for the purpose of teaching programming to students... so I gave it a try.

This tutorial gave me a walk through on all sorts of basic concepts of game code like:

I eventually got to the end of the tutorial with all the features built by Clear Code and I just kept going. I looked at the base he provided and thought, there are so many things I would add here to make this a more complete game. So I added stuff. Stuff like:

So I looked into building and distributing my Pygame game and while it was very doable thanks to some tools out there, I saw obvious hurdles and challenges to maintaining support in the python ecosystem. I also started to see my first drops in perfomance using single-threaded code running SDL when I made some mistakes in the interaction indicators. And I obviously saw very few examples of games written in python which led me to conclude that almost nobody is developing games with the language meaning help would be hard to find.

... it was fun, but it was now time to find a better home for my new found passion project. More on that in a future post!