I may try doing some smaller updates as I typically code in short bursts these days.

Recent Progress:

Doors
Added doors! (Seems silly & was easy enough to do, I just didn't have them in there)

Targeting Locks
Target lock - ranged enemies with this setting now need an extra turn before they fire. This gives you a chance to somehow block or otherwise avoid the shot (force them to move is an easy way). Even with the symmetrical FOV changes I did last week, it still felt like ranged attacks were a bit overpowered. This new mechanic has a fun feel to it - and also differentiates monster difficulty. Now I can have 'easier' ranged enemies that require a target lock - in later levels you may run into enemies that don't. Another idea is to give ranged enemies other disadvantages such as being immobile (turrets).

Environmental Effects
This is mostly behind the scenes, but I added a special 'architect' actor, who acts on behalf of environmental effects (fire, gas, features that interact with player/monsters standing on them). Because my engine is event-based, it was getting a little kludgey to have terrain/feature effects work properly.

This makes more complicated scenarios much easier to deal with. For example, if you want to have differing speeds for the player at some point (e.g. a haste or slow effect) then you want to be sure the 'environment' is behaving. If a player is trying to escape some gas or fire, and somehow speeds themselves up to escape, the fire or gas should not speed up too! Conversely, if a player somehow slowed, the gas should overwhelm them more quickly than normal.

Eventually the architect will also control things like spreading nano-materials and timed explosives.

Lots of tiny steps this week.

I decided to spend some time rebuilding my FOV algorithm, which made it so ranged enemies weren't quite so deadly. This had some knock-on effects that caused me to clean up some more of the AI and generic 'awareness' code behind the scenes. All in all, time well spent.

A main focus of hardpointe is tactical movement, and using the terrain to your advantage. To that end, there are ways for the player to actually create terrain, through various 'nano cores'. These are basically tubes of little nano-bots, and eventually their contents will be unknown to the player until they actually try them out (much like your traditional potions & scrolls). As a placeholder, affected tiles were simply a 5-square 'cross' centered on the point of impact. For the actual gameplay mechanic, I wanted something more interesting, but also predictable. I didn't want a quasi-random plume or cloud of gas. The mechanic I settled on follows a few simple rules:
1. always covers 5 tiles
2. always covers the target tile
3. only grows in cardinal directions, in order: up, down, left, right.
4. if any of these directions are blocked (by terrain, or existing nano-materials) it will stretch in the following direction


This allows the player to (somewhat) reliably create structures that will advantage them, and disadvantage enemies. For example, one of the nano-materials makes you invulnerable for 3 turns, but this affects anyone who steps on the tile - it does not discriminate between player or monster. Combine this with both negative and positive effects and you (hopefully) get some interesting gameplay.

Default spread

Corner limits spread in 2 of 4 directions

Hallways can give you a straight line

Surprisingly (or not surprisingly?) fun so far!

One of the many joys of roguelike development is getting your ass kicked by your own game! However, in my case some of the deaths to ranged enemies felt like cheating. All I would do is come around the corner and blammo -- dead. Was this an example of my own reckless play style? Or an actual bug in the game?

Turns out the problem was with my Field Of View (FOV) algorithm. Since I am using the amazing rot.js library, I had been using the default recursive shadowcasting field of view implementation. After poking around on roguebasin and re-reading Jice's awesome overview of FOV algorithms, I realized my problem is that my FOV was not symmetrical.

Now, depending on who you ask, symmetrical FOV may or may not matter. In a game with only 3 hit points, every shot counts. While I am loath to ever over-optimize, I felt it would be time well spent. I came across Albert Ford's implementation of a symmetrical recursive shadowcasting and ended up coding something similar in typescript. The end result is exactly what I wanted.

Before (Non-Symmetrical): This bot can see me, but I can't see him. Which means as soon as I step over, I'll be in range and get shot.

After (Symmetrical): Neither of us can see each other. In this case, the bot will move closer to the spot where he last saw me - sacrificing some range and giving me a chance to see him one turn before he can attack.

Have been making steady progress on the core gameplay elements of hardpointe. I do feel like the end result is even a little bit.. fun? (Shocking to me most of all)

Here's a longer-play gif of the game in action, with slightly less-embarrassing colors.

Current feature list:

• All six initial powers:
• Shield
• Heavy Axe
• Booster/Charge Attack (was originally jet pack?)
• Cloak
• Phasewalk (not sure if this one will make the cut)
• Hack (turn enemies into allies)
• One-off weapons (take up power slots but limited/non-rechargeable ammo)
• Various combat effects:
• Stun
• Knockback (concussive)
• EMP blast (in progress)
• Enemy behaviors:
• Basic melee
• Keeps distance (ranged attack)
• Explodes on death
• Attacks in packs
• Uses / recharges shield (in progress)
• Terrain:
• Chasms (if knocked into one you or enemies drop to the next level)
• Combat mechanics:
• Wall-smash
• Corpse-tossing (heave enemy remains into other enemies)
• Items:
• Grenades (simple damage & effects)
• Nanotech Cores (effects like acid and health - so far)

Whew. Seems a lot longer when I type it out. Stay tuned.