Title

One of the last features has been implemented: Turrets.

Turrets make up immovable objects that can attack, such as a Ballista. Currently, the idea is to enable units to ‘take over’ a turret that’s on the map, after which it will automatically attack their enemies. The enemy CPU can also do this, so you might wind up on the opposing end of these contraptions.

There’s a lot of different possibilities here, like having them always active (and autonomous) so that they start off attacking any/all units and then can be acquired by either players or the enemy as a means of assisting combat. I could also have them only be active when a unit is next to them, or have them not be able to attack at all, but allow nearby units to use them as a powerful attack during their turn.

They might also not attack at all, instead performing actions when triggered such as pushing adjacent units away from them or giving nearby units buffs or debuffs. Also, their attacks, which are currently projectiles, can be physical or magickal, or not projectiles at all and simply be melee. There’s a lot of potential here!

My main vision for them was a scenario with a bunch of turrets in the middle of the map and as you face off against the CPU, both teams would be trying to keep the majority under their control to do maximum damage to the other team.

Since I can’t show it just yet, here’s a completely unrelated gif that does a good job showing some of the latest additions as well as some minor polish. Basically I like how the unit jumps over their ally to perform a dual attack and then gets countered, something that wasn’t really possible at the start of the year.

The latest updates include a revamped weapon sprite system and the ability to properly dual wield weapons.

When a unit equips a weapon, you’ll actually see it on the character sprite. This goes for both weapons and shields. Each weapon type has a default sprite, which some weapons having their own unique sprite. The update makes it a lot easier to add new sprites to the system and behind the scenes it requires much less memory/overhead.

Dual Attack

When a unit decides to Dual Wield, their Action menu changes and they get a new Dual Attack option. You can read more about combat flow and the Action menu here.

You can perform a normal attack with either the main hand or offhand weapon, or you can use them both in the new Dual Attack!

As seen in the gif below, where we show a Dual Attack using a Pistol and Sabre, the unit attacks twice: once which each weapon. It gets a bit tricky when you start mixing melee and ranged weapons, so the general rule is we limit the attack to the smallest range. So if you are wielding at least one melee weapon, the Dual Attack will require you to be at melee range.

This isn’t a problem if you decide to Dual Wield two ranged weapons, but we’ll still use the Main Hand weapon range for the attack. This is still being worked on, so there may be some changes, but this opens up an entire world of variations.

The only downside is that while Dual Wielding you won’t be able to use the Defend action. Also, the offhand weapon will attack at 50% damage.

The actual attack will use animations, sounds, and visual effects from both weapons, with the main hand weapon attacking first and the offhand second.

At this point, only 1 Handed weapon types can be Dual Wielded, since you need a hand for each one. I did have plans for a passive that allows you to hold 2 Handed weapons in 1 Hand, but I need to see how that’s going to work visually. It may just allow units to equip Shields in the offhand, but if I can, I’d like to maybe add Dual Wielding for even those weapons. That’ll be a long term goal, though.

I remember back in 2018 thinking that I’d have a public release demo out way before 2025. Well it’s 2025 and we’re getting pretty damn close.

There’s way more cleanup going on than I would have ever imagined. So many things to wrap up and take care of, especially as a solo-developer.

–

Dusk Tactics is really two projects: a 2D Isometric Tactical Game Engine and a game built on that engine. The engine provides all the necessary tools to build a tactical role playing game. I created an auto-battler type simulation to test out gameplay scenarios and it actually uses orthographic visuals (top-down), so it doesn’t even have to be isometric, however unit movement would need to be adjusted for non-isometric (the simulator has units instantly move from tile to tile, as the emphasis is on speed).

Now that I am several years into the project, my main focus is on an actual playable demo being released. This has been my goal for the last 10 months or so and as expected is taking quite some time.

I’m currently slimming down the project, keeping only what’s necessary for a small demo release. This includes further debugging as well as fine tuning the core gameplay loop. It also includes testing different release packages and methods.

I’ve mentioned it before, but the first release will be aimed at Windows 10 32/64 bit. Dusk Tactics can and will support both Mac and Linux of course, but to make sure I do this right, I’m going to focus on one at a time. There are already closed releases that run on both Mac and Linux (Ubuntu), but the idea is to release something stable-ish.

–

No matter what happens, I will do everything in my power to finish Dusk Tactics, one way (release a game), or the other (release a bunch of crappy code in the form of FOSS). Still shooting for the former!

Recently I decided to tackle flying-based movement. If you’re familiar with games like Tactics Ogre, you may recall everyone’s favorite hawkman: Canopus. There’s also the elusive Divine Knight class. What these have in common is they are winged humanoids and thus can both fly and walk.

What I always found fascinating was how winged units in Tactics Ogre would choose to travel across a given path. They default to walking, but if the path calls for it, they extend their wings and take off. Flying humanoids don’t stay flying, however, they need to land at the end of the path so their destination must be a walkable tile.

Anyway, borrowing the Divine Knight sprite from Tactics Ogre, I created a flying humanoid placeholder and began the arduous task of not only pathfinding, but also traversing this path correctly.

The gif to the left shows JUST the pathfinding. The unit visits each tile on the path, but does not correctly animate or transition between tiles.

You can sort of see the unit jump from node to node, or in this case tile to tile.

The Dusk Tactics Engine uses a modified indexed A* (A-star) algorithm, which is commonly used for tile-based maps.

Typically this is used with a single layer of tiles and while in this instance I did required a second layer, it’s sort of superficial so I didn’t need to make any large changes such as adding hierarchies.

The superficial layer that sits above the ground is called ‘airspace’ and is essentially an invisible tile above the ground tile that can only be traversed by units who have the flying movement type.

This simple step involved adding a new connection to each tile that connected it to the airspace directly above it. With that done, all of the airspace tiles were then linked together just like the ground units, connecting adjacent tiles and so on.

A few days of banging my head against a wall and I was able to turn this into something that actually looks somewhat decent.

Now that we had a way to retrieve paths for flying units, we need the unit to properly traverse it.

Before I go on, to understand movement in the Dusk Tactics Engine, you’ll want to read about how it was implemented: Dusk Tactics Engine – Unit Movement

Since we’re using 2D and faking a 3rd dimension, we had to employ some tricks to achieve a consistent depth sorting.

This was where it got difficult. Since the terrain is so varied, there’s no one size fits all solution. So I focused on two types of flight: vertical ascending/descending and horizontal.

Horizontal flight is basically movement between two airspaces, which is similar to how land-based movement works. The unit adapts to the height difference and does its best to move from tile to tile.

Vertical ascent/descent triggers when the unit is faced with a strict height difference between tiles. Basically they use their wings to ascend or descend as needed and then switch to either horizontal flight, if they are still airborne, or if they can walk, they switch back to land-based movement.

I still have a bit farther to go, but outside of more advanced water-based movement, this checks off the last box of movement types I wanted to implement. I really wanted to get this in before the alpha testing so that’s pushed back a bit but it’ll be worth the wait.

The next step, of course, is to create winged humanoid sprite base with a special flying animation. It requires the body to be drawn at a different angle, so it’ll be a while before that gets implemented, but you’ll still see flying units as certain items can give you access to the flying movement type.

As always, thanks so much for checking in with the development process. I’ll try and update more frequently, but know that development continues as planned and I hope to broaden alpha testing in the next few months.

In the last few months of 2023 we had our first closed alpha testing of Dusk Tactics. It was on a very small scale, but it has already provided a lot of helpful feedback.

Some of the goals for 2024 are to expand the scope of the alpha testing, focus on getting a solid stat-growth balance for Jobs, and getting as close as we can to balancing the gameplay before it reaches an open demo release.

To help speed things along, the alpha demo will run in a special fixed resolution 1280×720 windowed mode. There is some work that needs to be done to get the UI working (and looking good) at different resolutions and I don’t want that to hold up gameplay balancing.

The current closed alpha demo (version 0.7) has about 10+ hours of gameplay over 10 scenarios. I plan to cut this down to just the first 3 for now to get the most basic of bugs worked out. The full demo is more of a vertical slice demo in that it features a little bit of everything that would be in the full game, which was the focus of 2023.

—

I’m still adding the Development Logs from the previous site, I’ve gotten about ~40 of them up so far (covers up until November 2021). I also have some new logs to add as well. I’ll be updating them regularly from now on.

You can see them by clicking “Development Log” on the menu to the left or by going here: https://dusktactics.com/categories/devlog/.

One day I’ll get around to making a proper landing page, but for now the highest # log is the newest.

Yet another year has gone by and we got a lot done!

In early 2024 we will be expanding the alpha testing to include more people as we continue to iron out all the bugs and start balancing various mechanics!

I hope you’ve all had a great holiday and stay tuned for more updates as always!

Merry Christmas / Happy Holidays / Happy New Year!!

-Lou

So this site will be similar to the last one, sort of a mix between a development log and a game website.

The side menu will have multiple categories that (when finished) should provide up-to-date information about the different features of the game.

So far I’ve completed the Attributes section and laid out the Features section. Current work is on the Story/Characters section.

I’m mostly writing this post to see what multiple posts look like on the main page, but I figure it can also be used as a small update on the websites progress.