Main

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!

There’s a lot of things that I’d like to add to the game, some are outside of the scope while some are just very difficult or impossible to get working and have them look how I want them to. One of these things is map rotation. It’s a downside to going to 2D isometric route, as your rotation options are limited, but not impossible.

Over the years I’ve kept up to date with other projects using similar systems and how they achieved rotation. The best I could find was something similar to an isometric simulation game that instantly rotates by 90 degrees at a time. This method works, but without the animation (as seen above) it can be a bit disorienting.

For now, it’s something supported by the underlying engine and could be a possibility in the future!

As we get closer to a wider alpha demo release of the early version of Dusk Tactics, I will be conducting various tests to see the best methods for handling things like screen resolution.

This is the toughest part because there are so many different resolutions, and then you have OS DPI magnification, etc. Since Dusk Tactics uses pixel art, we really want to make sure the players get the best looking experience possible.

I released an executable JAR file, which you can find here along with instructions: https://dusktactics.com/screentest/

If you have the time, test it out and give some feedback! It’d be greatly appreciated! So far it’s worked well, but we need a much wider sample size.

It emulates how Dusk Tactics would appear on your screen using what I like to call the ‘forced resolution change” method.

If it is successful, it’ll be one additional option to allow players to get a nice, smooth, pixel perfect gameplay experience.

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.