next »

[Galdred]

Hi there, I am Galdred.
We have been working on a tactical RPG codenamed Zodiac Legion for almost 2 years.
Overview
In this game, you will lead your faction through a fratricidal civil war, in a medieval fantasy setting. You will both control the actions of your faction on the strategic level, and the move of each of your champions on the tactical one.

Tactical turn based battles
Battles will take place on a separate tactical map. You will then control each of them in turn based tactical battles. Many battles will be closer to commando operations than deathmatches : You will lead your band of elite champions in a mission against countless opponents ( they will usually get reinforced over time like in Space Hulk), and you will need to complete it before being overwhelmed.The missions themselves will be things like freeing a prisonner, assassinating an opponent, retrieving an artifact...
The maps will use hexagonal tiles.





Strategic campaign
These battles are only part of the bigger picture, and you will have to choose on which missions to send your parties on the strategic map, how to keep your craftsmen occupied, and which magical knowledge to research. You will also have to choose whether to try to secure an alliance with the neutral factions, or crush them and take over their stronghold.


Human resources
 Your champions can die, get severly injured or captured during these battles. Those who do not will get better over time.
Some will learn to channel magical power and attune themselves to powerful artifacts.


Pixels and paperdolls
The game uses pixel art, but the characters are fully customizable thanks to our paperdolling system :
Each armor piece abd weapon is animated separately, and the characters are then built from all the parts corresponding to their equipment, or the graphical customization chosen.


Inspiration and team
We are a small time of myself and a game designer + a few freelancers who occasionnaly work on the project.
We were inspired by games like X-Com, Jagged Alliance, Descent : Journeys in the Dark and Space Hulk. I know it may sound too similar to Battle Brothers, but it's not like there are that many successors to X-Com being made, and ours has a slightly different focus (larger scale, with less emphasis on the personal level).

Technology and Tools
This game uses the moai game engine which is open source, and awesome, except for its documentation (and its resulting small user base).
We use Tiled to create our maps (from tilesets).
Art wise, our artists have worked with gimp and GraphicsGale for the art, and texturepacker was then used to build the spritesheets.

Status
Game system  60% : The strategic layer is still absent, and the skill, xp, and perk system needs to be fleshed out
Game Tools 80% :  Much work has been done to automate the map making process with tiled. We still need to find a good way to integrate mission logic (objectives, reinforcements points...) to the game.
Content 5% : The game lacks missions, perks and skills, and items, as we are still testing/building the underlying systems.
Display 70% : The paperdolling animation system is in place, we need to make customization easier in game, and add a simple shadow and lighting system.

Right now, we are working on the lighting and shadow system, and testing the base values for the most common items/characters.

Edit: The game now has a Steam page with a short combat demo.
We also made a gameplay reveal trailer

.


We will update this thread with reports of our progress (and failures!), but you can also follow us here, or using one of the following social networks:

Twitter
Facebook

Imgur image dump

[Galdred]

Overview of the combat system

During the tactical battles, each side will play all of its characters at once. Each character have 2 actions, like in Firaxis' XCOM. Attacking ends the activation of the character (so only one attack per round).
Combat takes place on a hexagonal map.
Some abilities can allow a character to do a bit more (like moving 2 hex, and attack twice in melee at the cost of 2 actions for instance).

Elevation gives an attack and defense bonus to the highest character.
Facing does not matter in the game, but flanking does provide an advantage when attacking.

Flanking


The red character on the left is flanked because there is no way he could not have someone in the 3 rear hexagons, regardless of his facing.
The other two red characters are not flanked because the middle one would have no one in the back if facing the hexagon between his two opponents, and the one in the middle is facing his 3 opponents, and have no one in the back.

Ignoring opponents

An important consideration is whether one character has been attacked during this turn. Characters who have not been attacked hampers adjacent opponents when they try to perform an attack. They also provide a higher flanking bonus to allies that manage to perform an attack on a target adjacent to them. They also have a stronger free attack against opponents that try to disengage than characters that have already been attacked this turn.
This was done to de emphasize focus firing, and give a purpose to weaker opponents.

Disengagement and Zones of Control
A character already has some kind of zone of control through the threat of backstab, and defensive support. However, they also have other effects on adjacent hexagons :
moving from a hexagon in the zone of control of an opponent costs a movement penalty, and may grant him a free attack.
Someone trying to disengage will give a free attack to an adjacent character who has not used his attack, or who has already attacked him.

In this exemple, Mr HammernChainmail can get a flanking position against the red knight of Libra : he can either make a detour, or pay 1 extra movement to get from one ZoC hexagon to the next. But if he does so, he will give a free attack to the libra knight, unless he already attacked someone else during his turn.
 
Attack is an opposed roll (attack vs defense), and the margin of success of the attacker will impact the damage he will cause.

[Galdred]

Now about our Line of Sight system :
This image illustrates why walls and tile based line of sight don't go together well.

A and B cannot see each other, which is not what a player would expect.
It would get even worse there :

D2 is partially protected from C by the wall tile, even though it would make no sense visually.

So we wanted a LoS algorithm that would be symmetrical (if you can see someone, he can see you), that would be intuitive (a rule lawyering miniature wargamer would not feel cheated by the algorithm), but that would integrate cover "naturally" (ie, the less we can see of a target, the better covered it is).

The wall tiles did not lend themselves well to a tile based LoS system, as it was obvious they did not take the whole space.
In order to make the system coherent with the graphical representation, we have settled for a finer LoS grid :

   
It throws away the hexagonal side of things, but these hexagons were easier to subdivise in squares than hexagons.
So Los will use a finer grid, (subdivision in green), with 32 cells/heaxgon.
This allows us to have an organic cover system :
Someone has LoS to someone else if there is one of his cell can see one of the target cells (so the algorithm is reciprocal), but cover depends on the number of cells visible from the 2 best cells of the attacker (in other word, you total the number of cells seen by the attacker, and the lower the total, the harsher the cover bonus).
So for instance, if A can see 27 and 16 cells of B from the two best of his cells, but B can only see 9 and 14 cells of A from his two best cells, A will have a large cover bonus (2 cells visible on average over the best 2 defender cells), while B will have a much lower one.
This way, there is no need to have artifical cover rules, and we never un into the wonky case of A being able to see B without B being able to return fire at all.

Here with a classic XCom exemple :
C is flanking D : he has partial cover, while D does not.


Note that we need to rework the northern walls, so that they "stick" to the northern border of the corner, so that the north-eastern corner protects as well as the south eastern one.

[Galdred]

I am now working on the UI.
We tried the HP on top, but it was a bit messy. We also tried big circles, but it attracted too much attention.

Which HP display do you find the eastiest to read?
Squares?

Flattened rectangles?

Thin rectangles?

round?

The health icon and faction circles themselves are placeholder programmer art.
Is the size OK, or are the icons too small?

If you have any other suggestion regarding health, or character faction (the blue and red circles), I'd be glad to hear it.

[Galdred]

Wow, it has been a long time. I have been busy with a lot of things, and have not posted much...
Here is a short blog entry I made on the game site to tell the prototyping stage of the game :

When I first started out, I followed the usual advice of writing design documents. It basically led me nowhere, which shouldn't come as a surprise. Tynan Sylverster explains it well in Designing Games: A Guide to Engineering Experiences, playtesting and modifying a prototype is easy, so there is no point in writing long walls of text to avoid doing it beforehand, just to discover that the game does not work as planned at all(even tough I spoiled some of the book, you should read the book itself, as it is one that bridges the challenge focused gameplay approach of a book like Characteristics of games with the feelings focused approach of a book like The art of game design : a book of lenses. While you are at it, you should also read these two other books too).

After having some rules up for combat, reinforcements, and movement, I started prototyping the game with moai using free assets from Open Game Art, which looked as follow :


First Prototype
The first prototype of the tactical map
But then, when I playtested the game with friends, we changed the rules so quickly that it was much more efficient to work with a board game prototype at this stage. We first tried to use an existing board, but I didn't have anything that would have hexagons for small scale battles, except for Heroscape, but then, the hexagons would have been too large to build a sizable map, so we ended up doing the maps with Tiled a printer, and some tape.


Fabien, who did the initial design, and me, placing Heroquest miniatures on the printed prototype map.


My daughter, helping with the prototyping process.

Once the rules were stable enough, I went back to prototyping the game on PC. At this time, I started working with a freelance artist, Cyangmou (who is very talented btw) to define the way terrain and characters should be represented. I then started to try to turn the prototype into a whole game, but I quickly found out it would not work, as the whole game would use a custom paperdolling system, so I ended up rewriting almost everything from scratch, but kept using moai. I rebuilt the new tactical module with these mock up tiles :


new tactical module with mock tiles
Fine tuning the z sort of the new tactical module with mock tiles
For those interested, the z sorting is rather simple : the priority is given to the element whose bottom part has the highest Y value (in other word, for characters, the Y value of the feet), with Y going from the top to the bottom, but the problem comes from the 2 following facts : Coordinates indicate the top left corner, so it is necessary to add the actual size of the character. The sprites are larger than the elements they represent (especially for characters, where the sprite is 256*256 while the character himself is around 64*64), so it is necessary to estimate the coordinate of the foot (or the wall base for props). The formula I used in moai was the following :

Code:

layer:setSortSacle(1, 20, 6, 1)

so it is weighted with 20 for the Y value, 1 for the X value (0 would work too, but I wanted to have an easy way to predict which sprite would get displayed in front if 2 were at the same level), 6 for the z value (which is only used as a Z sort parameter), and 1 for priority (another Z sort parameter). Z and priority may seem redundant, but Z is more flexible, as you can use transitions to have Z values change smoothly in animations, while you cannot do the same with priority. So priority is mostly set to determine layer priorities (with the floor layer set to 1, the character/props layer to 10000 and the UI layer to 20000).

That marked the end of the prototyping phase (even though I still test a lot of stuff with small prototypes). And the game was later shaped into this :


The new tactical module

[mzn528]

The game itself and the pixel art are both fantastic, keep us posted for more!

[Galdred]

Thank you!
Your pixel art looks quite good actually!

I am working on the UI, but it is hard to get it right from the beginning :

We first went with this :


But it is hard to determine who has already acted at first glance.
So we went with this :

The first lines make it hard to see how many move points are left (red bar is Hit points, number under skull is threat level, purple rectanges are move points, and sword icons are attacks).
Then for the action bar, we went with that first :

But although it looks good on the screenshot, it is very small on a 1080p, and the thinner icons are hard to hit (they are 12 pixel wide).
So we will probably go with square icons only, and have them 48*48 or 32*32.
What do you think about the border? Is it out of place for a floating action bar in pixel art?

[Galdred]

Ooh, sorry for the lack of updates. I am still somewhere in development hell, but I am going through it much more efficiently.

I wrote a short introduction to Moai, the engine I use.

WHY MOAI?
Before starting the development of Zodiac Legion, I had tried several ways of writing games, from programming a FPGA (it was a school project) to using high level languages on my TI-92 calculator, and complete frameworks.

I liked using a high level language, but reusing existing frameworks made it much easier to get things done in a timely manner. But it could also take quite a long time to circumvent the limitations of the engines, and waiting for other to fix bugs was not really an efficient way to move forward.

I also wanted an engine that would let me port easily from one platform to another.

So once I had decided to go 2D, I first tried working with Python, but distributing games made with it sounded like a pain.

Unity felt a bit "too heavy" (or obstrusive) for my needs. I have always preferred lighter frameworks. So I made some research, and I discovered moai. A few simple prototypes later, I had fallen in love with the engine, and lua.

MADE WITH MOAI
moai was used by Doublefine for their adventure game, and by Klei for Invisible Inc:
Invisible Inc by Klei, a game of turn based infiltration.

Broken Age by Double Fine


TLDR

I asked several other moai devs about why they had chosen moai, and here are their answers:

• It is open source, so you don't have to wait for someone else to fix the bugs that might be stopping you, and you can optimize whatever part of the engine you like. Moai is also free, and all you need to do is credit the engine, either in your splash screen, or in the credits.
• It also allows you to add features at the engine level.
• lua is awesome to work with. fast, lightweight, with a good C API. And the code written by other is very readable.
• It is easy to get into. You have very little setup to do before running.
• It is also natively made for 2D.

If you want to know more about it, there also is a mini tutorial on my site (more like a link to actual tutorials).
That said, it is probably only relevant if you really want an open source portble engine (because you want full control over the source code), as the lack of the asset store is a big issue.

Regarding the game itself, here is a recent UI image (some UI elements are not functional yet):

[Galdred]

Now let's go for a more technical entry:
AI area definition subsystem:
Reasoning over tiles quickly becomes overwhelming for the AI, and chooosing on which tile to land is not that important when it is 4 turns away from its destination.
That is why I decided to make it reason over larger areas (I stole the idea from Kohan 2 actually. I had read about itGame AI pro 2).
I chose to pick a different algorithm to define the areas, and went with the one described in Game AI programming wisdom 4: RTS Terrain Analysis: An Image Processing Approach), because I had troubles defining "good" areas with lots of small obstacles (trees, chairs, tables...).

So basically, the general idea is to split the map into "areas" or room of a "correct" size: not too small (or we are back to the tilemap approach), but not too big.

Step 0: "remove" small obstacles like pillars, trees, to get large areas
This is the easiest step, and one of the most useful too.

Step 1
Get a depth map of the level:


In this map, the depth is the distance to the closest obstacle OR other terrain type (as long as they have significantly different effect on combat and movement).

Step 2
Step 2: make a 1st rough pass at deducting an area map from it:
Areas or basically : groups of tiles for which the depth = the starting depth or is strictly deacreasing (so it can be 6-6-6-5-4-3-2, but not 6-6-6-5-5-5 and not 6-6-6-5-4-3-2-3).
Of course, the rules are a bit more complex(I allow pleateau if the resulting area gets too small).



Step3: correct the areas by swaping border areas that create non regular shapes
Basically, if a tile has more neighboring tiles of a given different area than of its own area, I swap it to the new area.
This is also a trivial step.

Step4: try to make the areas "more or less convex": ie, not like area 57 here:
It cannot be strictly convex, because our walls are bizarrely shaped. So our rooms need to pass the convexity test! And zig zaging vertical lines too because hexagons



So we end up with the following set of rules to enforce:

To determine if an area is "good", we check each neighboring tile:

• If it is next to 4 or more tiles of our area, our area fails the convexity test
• If the neighboring tiles of our area do not form a continuous arc, it fails the test too
• If it is close to 2 area tiles that are next to each other, it passes the test
• If it is close to 3 area tiles things get complicated

If we are in the 3 neighbor case:
We start from the neighbor or our area (The tile is the outside border tile we want to check is in yellow).
We draw the two max border lines at an angle (in white).
If there is any area tile in those white limit line, it fails the test, otherwise, it passes.



Then the AI determines how many tiles are beyond the white border. If it is "too many", it tries several splits of the area (from the first tile that did not pass the semi convexity test), and determines which one works best according to a scoring algorithm.

And now, we can reason over areas by creating an influence map of each area to determine who controls it, and analyze which area the players need to cross to get to the objective (insead of the bazillion poissble paths they could take), and decide where to dispatch reinforcements, where to hold, or where to attack.

[Davi Vasc]

Didn't have the time to read the posts yet but the screenshots look awesome. Following to read later

[Galdred]

OUR GAMEPLAY CENTRIC APPROACH TO MAGIC IN THE WORLD OF ZODIAC LEGION

Early on, I had a very hard time with world building, as there were countless decisions to make at once. But things got much better later on after I got an awesome writer on board and we chose to follow a top down approach.

We decided how the game should play, and how the world should work, and inferred the rules of magic from there. But we still need the world internally consistent, so some gameplay concessions are needed to make it work.

MAGIC CYCLES

[/b]
In order to keep most of the feudal structure intact, and to preserve the feeling of technological advancement of X-COM, we decided early on to start from a mundane medieval world in which magic was awakening.

But the fantasy convention for acquiring magic knowledge is to study some millennium old book, not to reverse engineer demonic weapons in a lab, so we needed a reason for these books to be there in the first place. We also wanted to have ancient dungeons filled with artifacts and traps, which would not work well if magic was a new thing.

These reasons made us decide to go with the cliched solution of having magic return, with books, scrolls and artifacts hidden around the world. But we also needed to explain why dungeons would not have been looted while their magical guardians were inactive.

I found the solution when one of my friends told me about the stronghold he designed as a high level D&D player: he built an underground dungeon and had all access points to it collapsed after he built a teleporter. The teleporter only access would allow these ancient dungeons to remain intact during the non magic age, unless would be looters would be willing to do an awful lot of digging (which is obviously much easier with active golems than when they lay dormant). This also gives another purpose to the study of old scrolls and tomes: these could help pinpoint the magic coordinates of the teleporters (or whatever is needed to unlock access to them).

We also needed competing forces that would fight over magic artifacts, and neutral guardians to guard the ancient dungeons and their treasures. Another (budget) constrain was to have as many humanoids as possible, so that the paper dolling system could be reused. That is how our guardians ended up being gargoyles, skeletons and smaller golems. The main antagonist factions would be human, and roaming demons would act as a primal force attacking every faction.


_{Skeleton dispenser is back online}

In order to have the player play catch up with the bad guys, we had to give them a head start, so we ended up with old mages hibernating during times of dormant magic, and reawakening as soon as it has become strong enough.


_{This gargoyle has just finished napping}

HOW HEROES ARE BORN

I have always found cheesy that a "high level" warrior could destroy a whole company of footsoldiers with his sword in most fantasy role playing games. This kind of power makes more sense if the division between heroes and normal characters is the result of supernatural forces, and not training alone. I suppose this is also why ancient mythological heroes almost always descended from the gods. It also ties into the theme better, because if characters can turn into one man armies by themselves, it makes learning and controlling magic much less potent.

Our parties will be composed of a few heroes backed up by regular expendable characters, like these three heroes from Heroquest and their disposable soldiers.HOW HEROES ARE BORN
I have always found cheesy that a "high level" warrior could destroy a whole company of footsoldiers with his sword in most fantasy role playing games. This kind of power makes more sense if the division between heroes and normal characters is the result of supernatural forces, and not training alone. I suppose this is also why ancient mythological heroes almost always descended from the gods. It also ties into the theme better, because if characters can turn into one man armies by themselves, it makes learning and controlling magic much less potent.

Our parties will be composed of a few heroes backed up by regular expendable characters, like these three heroes from Heroquest and their disposable soldiers.


_{Heroes fighting alongside fireball fodder in Heroquest}

However, making supernatural abilities hereditary like in the sagas of old would not work in the game, as it would give us little control over the number of heroes, and losing one would be a tremendous setback, as having a new hero join in for convenience whenever one dies would be a little lame. The better way around it would be to have artifacts or places of power that would be attuned to a character, granting him supernatural abilities as the bond between them grows stronger.

This makes balancing much easier as another character can ascend to become a hero after his predecessor meets his end.

Out of these two, places of power tie with the Zodiac theme better (it could be landmarks shaped like the relevant constellations, or places that resonate with these constellations), and unlike artifacts, would not be lost if the bound hero was to be slain and left behind during a quest. However, they could also be taken by the opponent, which could make securing them too important in the campaign, so a middle ground solution would be to have "large" artifacts to deliver to the stronghold.

Mages are only a subclass of these "superpowered" characters. In a way, the champions of the Zodiac Order would be close to the Jedi (which offer a lot of sub specialization according to the more recent Star Wars RPG), or the Kai monks of the Lone Wolf series of game books.



We end up with a dual pool of characters: regular characters waiting for their chance to "ascend", and ascended heroes that are in limited number.

These ascended heroes will keep learning ordinary abilities on top of their supernatural ones. This dual experience system is close to the way Psionics worked in XCOM: Enemy Unknown.

OF TELEPORTATION

Logistics and transportation determine how fast armies can move and how large an area a ruler can control. For this reason, we needed to establish how teleportation would work early on.

We needed teleportation to exist to allow quickly dispatching your heroes to a mission location, and justify endless reinforcements for the defender during missions. But as the latest seasons of Game of Thrones have shown us, teleporting armies would make it difficult to plan any sort of strategy. We needed to be able to teleport champions to their mission area without travelling for weeks, as it would make little sense for some missions to remain available for so long.

So the stronghold would allow teleportation to the mission location.

Walking back to the stronghold works as a mechanism to enforce crew rotation, and makes it useful to have several secondary bases to teleport our warriors back to the main stronghold.

Teleportation needs to work from a fixed teleporting infrastructure (the Stronghold teleportation chamber) to a chosen destination.


_{A spell of "clear teleportation landing zone" and another of "lock teleporter" were obviously cast before to avoid any collision related harm to our champion.}

We also need to find a way to restrict the possible destinations. By requiring a physical transportable "beacon", carried by a spy, or another known teleporter, we can limit the teleportation destinations to a reasonable number.

In order to avoid army teleportation, we also need to limit the "energy" a teleporter can use, so that only a few characters can use it, otherwise, we'd be back at teleporting armies.

ONE RING TO RULE THEM ALL

We wondered what the player avatar should do. We first wanted to tell the story of Gaius Laptopus, the king of a feudal kingdom who would be confronted with the rise of magic. He would have led his champions from afar, like his modern self in Jagged Alliance. He was supposed to remain in a throne room that would act a bit like Charles Xavier's Cerebro, boosting his telepathic powers, and casting support spells to enhance his champions in the field. But not getting your hands dirty goes against the established chivalric tradition, so that made him lamer than his modern equivalent (JA/JA2 laptop guy or XCOM commander), especially now that the commander ends up being the new Neo in XCOM2 (not bad for a guy who supposedly did not last 2 months in XCOM). Medieval leaders were expected to lead from the front, but it would have made it very hard to handle the player death properly. There are basically three ways to do so:

• Not to let him die at all. He would only be knocked out instead of dying. Or he is some sort of lich that cannot die under regular conditions
• Make his death lead to the Game Over screen
• Have a successor take the mantle

The first solution would go against the theme of a desperate war in which many warriors have to sacrifice their lives to stop the enemy. We definitely wanted a body count close to the earlier X-COMs. It would also lead to stupid gameplay effects, like sacrificing the commander every time it can avoid average Joe to bite the dust. The second solution would basically lead to either a lot of save scumming or the leader never taking part in any mission. The third solution works well when focusing on a kingdom or organization, and not on a single individual, which is exactly what we want, but we would have needed quite a large supply of heirs if the game was to have a high kill count. This would either lead to the main character breeding like a rabbit, or the player ending up with one of his many distant cousins.

That was one of the reasons we switched from a kingdom to a knightly order: Knightly orders don't require a blood related successor. After the death of the commander, another knight of the order would simply be elected to step in and take up the mantle.


_{Ulrich Von Jungingen, Hochmeister of the Teutonic Knights, about to die at the battle of Grunwald in 1410. Granted, it more or less meant game over for the Teutonic Knights in Poland anyway, but it was because it occurred as part of a total party kill.}
This also ties well with the bond between places of power and characters: Becoming the commander allows the ascended character to access powers unique to the ring of command (or whatever artifact/location is tied to the leader). But we still need the Grandmaster of the Zodiac Order to have psychic powers as he should be able to command a mission without being physically present. He just can if he so wishes (and we just need to find proper balance to make sure it is a difficult decision every time).

These changes allow us to make the story about the order itself, and not Gaius Laptopus, which also fits the theme better.

_{The new main character of our story that you can grow attached to (see next blog post about castles in a magic universe)}

THAT'S ALL FOLKS

Note that none of the elements described here are final. We reserve the right to change everything again for any arbitrary reason. We are far from done with magic in the world. We'll address the way magic influences warfare in the world of Zodiac Legion in a future update.

[Galdred]

I have been quite silent for a while, but some good progress has been made with the inclusion of new props:

and destructible walls

Granted, there needs some animation for it.

I also made a short animation to showcase the Paperdolling system of the game:

Each animation works with every combination of armor parts.
1st sketch for the paperdolling system:

silhouette sketch

Rough animation draft

Armor designs

Once the design was fixed, the artists started drawing every piece of equipment as a layer in graphicsgale (so one for left chainmail vambrace, and another for right plate pauldron):

The animation frames are then packed together with TexturePacker:

The imgur post on the same topic is here
The steps of paperdolling in Zodiac Legion

[Galdred]

First of all, here is a "low cost raise dead spell" I made from reversing the death animation.

The end is really weird, though, so maybe I should get some frame redone (but given the way paperdolling works, it would be rather hard, as this would need to be done for all armor pieces too):



I plan to launch a Kickstarter "soon", because I need to reassure my main investor(my wife) and supporters (my daughters) that the time and effort spent on the game were not in vain.
I got a snarky remark by my 8 year old: "You have been working on this game for so long (as long as she can remember actually...) that you'd better sell lot of them to make up for it."
And she doesn't even realize how hard the competition has become in the indie game department.


But self marketing being a skill I have put zero point in, how would you go about a potential Kickstarter?

I currently have a few playable levels, but they need to be more interesting for a proper demo (as I'd rather not have people just think they should be playing Battle Brothers instead).

So I'd need to implement a few skills(mostly "crow control" and positioning abilities), improve the UI and balance the game rules a bit more.

I also need a trailer, but I'd need something that look like a functioning strategic part (and not the snarl of placeholders I have now).

That could also be useful for a Steam page.

And I guess a gameplay video could help too, but for this, I'd need prettier environment (I have been working on these, but there is still work to be done), and someone with the skill to be understood while speaking English (I took the trait that makes my pronunciation barely understandable in any language).

So which one do you think I should best focus on.

Also, I intend to spend some money on the marketing and related stuff, but where do you think they should be used?

I was thinking that spending them on the trailer and KS videos and assets was the soundest, but all the advice I got so far told me to spend them on Facebook and google adds.
What do you think about it?

[Galdred]

Hey, it has been a long time, but I stopped blogging altogether, because it took too much time.
We made a (lengthy) gameplay trailer for the game.



, and we now have a short demo on the Steam page.

The game is still far from complete: I need to add the geoscape layer, and I have a ton of changes to add to the existing dungeon crawling part.

[Alain]

I love the overall style of Zodiac Legion, makes me very nostaglic. Keep up the good work and keep us posted

[Galdred]

Thank you Alain!
I am working on making the demo more user friendly, as it is confusing on many points at the moment.
I hope to get it done for the middle of the next weel.

Here is an preview of the UI overhaul:


with added flanking/support indicators in combat:


and disengagement check preview:

[Alain]

Nice, good job on the UI overhaul. I hope development is going along well!

[Galdred]

Nice, good job on the UI overhaul. I hope development is going along well!

Thank you, it went pretty well, even though the pile of things to do never shrinks :D

Splattercat made a cool video about the game here:

[Copywright]

Oh wow, this looks excellent. A Songs of Conquest competitor, for sue. Love the pixel art -- can't wait to see a demo.

[Alain]

A Songs of Conquest competitor, for sue.

If I am not mistaken, their art director works on Songs of Conquest as well.