Dusk Tactics is a turn based, tactical role playing game being developed for PC, Mac, Linux. It features 2D isometric pixel art, dynamic battle maps with varied terrain and weather, an overworld, and in depth unit management system.
This project is the culmination of everything I’ve ever wanted in an SRPG / turn-based tactics game and it’s come a long way, however there is still much to be done. I’ll have more info on the devlog soon!
You can check out a list of implemented features here.
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.
Development remains strong as we fine tune the many mechanics found on the battlefield.
–
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.
A small example of one rotation method that has a rotation animation. Ultimately it ends up not looking so good as tiles end up with overlap.
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.
This method shows instantaneous rotation. As you can see, all units and even the projectile trail are kept in the proper rotational view.
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.
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.
So far this month we have already smoothed out dozens of gameplay features and cleaned up several bugs. This includes visual things like small tweaks to sprite animation problems (animations not playing properly) and proper placement/size of 2D shadows. Both of these have made gameplay look a lot better.
Below we can see how the shadow takes on an appropriate size at all times. Even when a unit’s movement type change to hover and then reverts back to normal. This is also used when a unit jumps across a gap. Since we lack a real third dimension, we have to fake a lot of stuff that requires depth, so little things like this really are very important to get right.
In the tactical role-playing game / SRPG genre, you’re going to have a lot of characters. This includes main characters, side characters, enemies, and even one and done NPCs. All of these require both sprites (obviously, haha), and larger portrait art to be used in both dialog cutscenes and on the in-game UI. As of 2/24 we have a complete set of main character portraits, side character portraits, and five (5) generic job portraits (one for each gender, making 10 total!). For now, our goal is to have proper portrait art for everything included in the demo, which is a lot.
The 40+ scenes in the demo include gameplay and dialog that will most likely change in the actual release version. For now, we’re trying to see what works, and set up a proper pipeline to create scenes and display them in a nice looking user interface. There’s so much that goes into little things like where a text box should show up or when to pan the camera that it’s important to get these fundamentals down pat before creating the entire game.
The screenshots below are from the end of the 3rd scene where our main characters, Belavosi Grandoff and Miranda Donovan meet the talented purple haired Scribe, Relena Farrow. This is just one of many variations of our dialog/scene layout that we have tested. It’s possible that for smaller scenes like this where just a few units are speaking to one another, we’ll use a 2x zoom in. It’s also possible we’ll change up the size and location of the textbox.
Currently we’re just using faces (neck up) for dialog portraits, but since we have 3/4 body portraits to work with, we can try out different sizes (busts are used below). No matter the size, the portraits will all feature a range of different emotions (see Relena in panel 1 & 3).
These are the fine work of our official portrait artist, Pzxl. While I don’t want to spoil everything, they just finished up some of the generic portraits, which are done a bit different than the main character portraits.
For generic units, i.e. units you may recruit or that will join you and have no real distinction other than their Job and gender, we have a paper-doll style system to give you a variety of different looks for similar units. Generic portraits are solely based on the Job, i.e. Warrior, Scribe, etc. There are two variants (usually), one for each gender. On top of that, we have several variation in terms of hair style, hair color, facial features, etc. So even two units with the same Job and gender will have some variety.
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.
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.
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.
A few days of banging my head against a wall and I was able to turn this into something that actually looks somewhat decent.
