Tyger Blade Devlog #1

The story of Tyger Blade begins much like that of many indie games, with me abandoning a bloated and over-scoped project.

That project, titled Nemesis Code began as a simple fast paced, top down arcade shooter, a-la Hotline Miami.  I came to the conclusion that my game needed something to set it apart from the rest, so I began to patch on more an more mechanics.  I created highly advanced enemy AI, that was prone to walking straight through walls.  I patched in an inventory system, that would go on to turn into a mess of spaghetti code that would get it's tendrils intertwined with the game's entire codebase.  And my art pipeline was so complex, that I briefly considered remaking the game into a first person shooter just to make things easier on myself.  I eventually took a step back from my monstrosity, and decided that It was time to begin anew.

Although I must admit, the game did look nice, even if I did misspell nemesis.

This brings us to one week ago.  I sat myself down and wrote out what my new project should, and shouldn't be.

I decided that my new project should...

. Have one central main mechanic, that can be used in multiple ways.

. Be "jamable" I.E. something I could create in a striped down form, in a short time.

. Have a clean codebase, composed of simple, self contained, components.

And shouldn't...

. Have player data shared between levels, having that made Nemesis Code needlessly complex.

. Need to save complex player data, the inventory saving code made Nemesis Code's save system a nightmare.

. Require systems to be built around each other in a way that changing how one works breaks everything else.

Thus I set out and created Tyger Blade.

The main mechanic that I came upon was throwing, and dashing to, a sword.  This mechanic allows for fast paced combat scenarios as well as slower paced combat puzzles.  This mechanic also allows for multiple mutations, such as walls that cause your sword to bounce off of them, or enemies that cant be dashed through.  Most importantly this was a simple mechanic to implement, I was a able to put down the basis of this system in an hour, and had a fully playable level at the end of the second day.

The art asset creation pipeline was a major problem for Nemesis Code.  I attempted a semi-realistic art style for the game.  This made the creation of environmental assets easy, all I had to do was trace over photographs of real objects, and airbrush in shading.  However it made the creation of character assets very difficult.  I eventually came upon the solution of using pre-rendered 3d models for my characters.  I thought this was a good idea right up until I spent three hours rigging, texturing, and animating the player character, only for the sprites to stick out like a sore thumb.

Therefore, I decided that for Tyger Blade, all assets will be simple 2d pixel art.  This made creating enemy and player sprites much more easy, as well as making them fit into a cohesive art style.  This also made creating environment assets that fit with the sprites much more simple.   Pixel art alone cannot carry a game's aesthetic however, I also made a point to learn how to use my engine's shader language to create procedural effects.  The most notable of these being the CRT style warping and vignette, as well as ripple distortions for when the player uses their dash ability.  That, combined with some particle effects, and a Polygon Shadow script created by fellow Godot Dev Miziziz

NOTE:  This gameplay video was recorded before the CRT shader was added.

The enemy AI in Tyger Blade runs off of a basic state machine.  Enemies can exist in one of four states, Idle, Searching, Attacking, and Dead.

Enemies in the Idle state can actually have two behavior types.  They can be in "still" mode, in witch they stand in one position until the player is spotted.  Conversely they can also be in "wander" mode, in which they walk and turn in random directions, bouncing off of walls and invisible "enemy threshhold" objects.

Look at 'em go!

The second enemy state is the "Searching" state.  Enemies in this state simply navigate to the point where the player was when they entered this state.  In practice this means that they will go to the position in which they last saw the player.

The third state is the "Attack" state.  Enemies in this state will navigate towards the player until they are within some threshold, and move away from the player if they get too close.  If the enemy is within the proper range, they will attempt to attack the player.  The enemy attack system in Tyger Blade uses a modular tree based system, this makes adding new enemy attack patterns incredibly easy.

The final enemy state is the dead state, this is pretty self explanatory

In the future I plan on implementing navmesh support for the enemy AI as well as bottomless pits witch the player can dash over.

This marks the end of Devlog #1.  I plan on having a public demo out by the middle of January, and the full game out by the end of 2021.