3D map editor, more UI, and Mourning Cloak license
over 2 years ago – Thu, Feb 15, 2024 at 04:49:30 PM

EDIT: looks like the gifs didn't survive Kickstarter's new backer update system.

To see 'em, check the post on itch.io: https://wick.itch.io/lancer-tactics/devlog/682706/3d-map-editor-more-ui-and-mourning-cloak-license

(I tried pasting them in and they showed up in preview just fine, but it was only because my browser had them cached, oops)

==============

Hey y'all! This is gonna be one of those bona-fide glorified-changelog-with-gifs updates. Buckle up! (and maybe make sure you're on wifi if you have limited data?)

Map Editor

• Got units able to be placed/deleted/moved in the mission editor

• Can paint/remove command zones in the editor
• Can paint minecraft-like terrain blocks in the editor

• Can paint/rotate multi-tile props in the editor

• Can edit unit character sheets and portrait via the editor

3D maps

• Did a bunch of art tests with 3D mech models, provided by GeneralChaos. We ultimately decided to stick with 2D mechs as a concession to our limited time and experience.

To avoid the can of worms that is animation, we'd have to lean into a static "tabletop minatures" aesthetic, which we decided is not a style we want to be stuck with. By sticking with 2D sprites, we avoid falling into a sort of uncanny valley; it's easier to get away with not animating a 2D sprite than it is for a 3D model.

• We also experimented with 3D terrain. We decided to make a rule that the visual style for a piece of terrain should match its mechanical effect: obstructing terrain that you can't move through, such as rocks or buildings, will be in 3D, while non-obstructing terrain like trees will stick with 2D sprites.

• Hooking up the 3D camera to follow events like movement and attacks did a LOT for making it starting to feel like it's cohering into an Actual Game™

• Implemented cover! And an attack preview! Cover works by aiming a ray from the target to the originator (technically to and from each voxel of each, respectively, to handle size 2s shooting above size 1 cover) and tracking all the terrain blocks it hits (how we'll handle non-terrain hard cover TBD). I think I have it working according to Perijove's cover rules manual, but I'm sure there'll be edge cases to work out. This is a case where things are significantly simplified by working in squares instead of hexes; hexes have a lot more possible weird angles you have to deal with.

• Re-added what I'm stubbornly calling Combat Popcorn; little bits of text that pop out when you use abilities and attacks.

UI & game screens

• Added ability for the engine to show UI that's anchored to the game world via a little word bubble line but also stay on screen as the camera moves around.

• Got word bubbles working; you can now write dialogue in the mission editor, hit playtest, and see it work in a mission! (it does actually translate correctly now; this gif is just from a bug I thought was funny)

• Got ability effects mostly behaving appropriately again, including muzzle flashes. The easiest way to handle them ended up being NOT billboarding them so they always face the camera (like all other 2D sprites in the game); instead, I put them on a plane parallel with the ground and just spin them around the unit to point at wherever their target is.

• Did some work ironing out our tooltip system. The standard in CRPGs these days is this kind of nested labyrinth of tooltops that you see in Baldur's Gate 3:

I Did Not Want to try and figure out how to wrangle that much UI, so we're instead opting to cap the nested tooltips at the second layer. You can lock a general tooltip for e.g. an action and then mouseover various items within that tooltip to get glossary definitions...

...and then instead of having those glossary tips be lockable/mouse-overable themselves, I collect all related terms to that glossary definition and let you tab through them.

• Added skin overlay functionality to the portrait maker, enabling textures like scars, tattoos, stubble, and vitiligo to be applied to just the skin and not extend off into space.

• Midway through writing this update, Carpenter sent me this gif of the randomization button working! There's a still a bunch of skintones/assets missing and a few are a bit janky, but it was exciting to start seeing the range of these lil freaks (affectionate) that this editor can create.

Mourning cloak license!

This is the one I'm probably most excited about: I did a bit of a content dive and implemented a basic character sheet + all Mourning Cloak traits and equipment. They don't have fancy graphics yet, but the weapons and systems can be added via the character sheet and used in-game.

It took a little under a day, including adding soon-to-be common mechanisms like bonus damage. This is great news in that it means the engine we've been building for so long in the abstract seems to do a great job in handling comprehensive actual game content, and that it looks like we've set ourselves up for success when it comes time to buckle down on churning that out.

I'm sure other licenses will come with unique difficulties (I fear the day it comes time to do the Mule Harness // Goblin CP) but I'm feeling good about it!

Vertical slice?

Taking a step back, the pressing question on my mind has been "when will we have a playable early access build?"

I was originally hoping for Feb/March, but what we've internally been referring to as the "3D cataclysm" has pushed everything back by at least three months, so the target for the first alpha build is now in May. So, ah, thanks for your patience! Seeing things come together, I've become more and more convinced that moving to 3D was the right call.

✌️Olive

New year new dimension (aka 3D maps!!!)
over 2 years ago – Fri, Dec 29, 2023 at 03:42:15 PM

Not gonna bury the lede: inspired by another project in the Lancer community, about two weeks ago I did a quick tech demo to answer the question "what would LT look like rendered in 3D?"

Unfortunately, both I and everyone I showed it to really, really liked it:

I say "unfortunately" because we're a lot later in the development process than I'd like for this kind of change AND I have almost no experience in 3D games. 🙃 But I would be a fool to ignore this clear an experimental result!

Moving to a 3D map solves these problems:

• Depicting elevation. We've been jumping through some pretty wild hoops to try and depict size 3 terrain without obstructing the tiles above. A 3D view allows for more interesting and taller terrain-shapes and covering up tiles is fine because the player can rotate the camera.
• Handling cliffs. The most complicated part of the map system was handling having cliffs in-between tiles and the auto-tiling system to select the right graphics for given elevation data. There was a whole second tilemap offset by half a tile in both directions for cliffs over top of the ground — which meant there had to be a system of sorting z-indices for units on both the ground and elevation layers. Putting stuff in 3D space handles visual ordering for free.
• Destructible and constructable terrain. It's gonna be so much easier to make a crater the size of the moon from a charged apoc rail or for a Kobold to play minecraft by being able to add and remove voxels at will and have the engine set up to handle it.

Reasons this is not a huge change of scope that will sink the project:

• I've been doing an AMAZING job keeping the game logic separate from the view layer. It's a common backend engineer's fantasy to be able to say "yeah you can just swap out the frontend for a new one" — and we've actually done that! The circled areas here are the only things I've had to change so far: only stuff that handles rendering to the map-space.

• We keeping the style of lowish-res pixel art. We're not modelling the robots in 3D or animating them; they remain billboarded 2D sprites. I think we can make the game look good with this style (3D pixel-art-esque games are somewhat in vogue right now) AND this will be easier to pull off with our limited 3D experience. The only change is that the map is rendered with 3D voxels instead of 2D tilesets. 
• Well, that's not totally accurate; the one data-level change that I have had to make is a more nuanced system of figuring out what properties the terrain has at any given voxel; a blast-1 smoke bomb should not affect a cliff 4 tiles up (this is that leftmost little red island on the graph above). But I've already made the appropriate changes and it took like two days soooo no worries there.

I feel like expanding on that last point: under the hood, this is still almost entirely a 2D game. This means we have decided against allowing overhangs (e.g. no archways, walking under bridges) or stacking flying units up on top of each other (flying is still an on/off status rather than giving you precise control of your height). This hedges out a tonne of edge cases and will allow us to proceed with the current engine without too severe of a speed bump.

Show the goods!

Now that I've justified to myself and y'all why this idea is good and feasible, let's see where we've gotten two weeks out from that initial test!

Once I got the new cursor hooked up to be able to point at a tile (harder than it sounds; you have to do raycasts and have collision shapes and there was a Godot bug on those that cost me half a day), it was just a matter of feeding that current-tile data into the engine and the event system happily moved units around like we've always been in 3D.

Our current approach for ramps is that they're going to count as elevated tiles, but be cheaper to walk up (no half-speed climb penalty) and will render units on them halfway between their raised and lower parts.

We briefly discussed and discarded the feature of dynamic water tiles. They raise too many questions when combined with destructible terrain. I ain't simulating minecraft or dwarf fortress here. Instead, it's likely that we'll let the level designer choose a z-level and have everything below that be "underwater".

As a bonus side-effect of space rules being the same as underwater rules, this'll give us zero-G maps for free by choosing the maximum water level and making it look like space instead of water. Game design! :)

I've also got multi-voxel objects loading in correctly. These have a "true" origin voxel, but cast out a rectangular area that intercepts requests for terrain at those voxels and feeds the request its own terrain data. There's nothing actually at those voxels in the map file, but the game acts like there is. It works on rotated objects via the sort of 3D math I've spent my life avoiding up to this point (meet Quaternions).

(Those hangar buildings are from this Kenny asset pack! I expect to lean on his resources a lot in the coming months.)

Here you can see me learning how to manually generate meshes from terrain data. In order to show tile ranges (for movement, attack, line of sight) I need a "shell" mesh that sits on top of the terrain like shrinkwrap. I can then draw a texture on it with the same 2D shader I described here to get the final effect:

And finally, this morning I got 3D bezier curves working for movement preview lines:

What's next?

As surprisingly easy as switching to 3D has been, it has taken and will continue to take time we weren't expecting. A vertical slice for early access backers is still months off — I'm still hoping for Q1 next year, but I'd say it's likely that's going to slip.

Remaining todo items to catch up 3D to where we were in 2D:

• convert the attack and ability effects to use 3D
• different textures for the edges of terrain cubes
• texture variants for terrain types (so not all grass blocks look the same)
• getting 2D UI to position itself correctly relative to the tile it's relevant to
• update the mission editor to use the new 3D maps

After we get those done, I be back to hooking up the player-facing UI (e.g. alternate actions e.g. melee vs thrown), character sheets, and working towards that treasure of a shareable early access demo.

Carpenter and Martina have been hard at work on the pilot portrait creator. I don't have a good picture of it, but we've gotten masking layers working which allows hats/hoods to stop hair from poking through and skin-wide texture modifications like tattoos, scars, and short beards. That'll definitely be ready to try out as a standalone program sometime in the next few months.

Happy new year! If you choose to celebrate, please do so safely and covid-consciously! Also it was my birthday a few days ago and I'm 33 now! Cool!

Portrait maker, dialogue bubbles, working towards a vertical slice
almost 3 years ago – Fri, Nov 10, 2023 at 06:17:50 PM

Update day! Have some game dev vignettes!

Rewards update

But first a word for our sponsors aka you. Thanks to everyone who filled out their survey in time for our big shipping push. There's been a steady trickle of like a dozen packages per week to ship since then (for various reasons -- late survey, mail bounced, a new preorder) and the whole task of putting a batch together, verifying all these by-definition special cases, and getting them in the mail takes like half a day on my own. I'm looking at this pipeline of like 200 unresponded surveys in fear that this clerical work is going to continue forever.

So if you haven't filled it out, please do so now because I'm probably gonna start doing the batches way less frequently!

Related, the charge should have shown up as "WICK.WORKS" on your bank statement. A few folks (understandably) didn't recognize it and reported it to their banks; I'm telling you what to expect now because disputes set off a whole communication process Stripe wants me to go through and they're a gigantic pain.  😫

Vertical Slice

I've been getting antsy that we're, what, seven months out from the end of the campaign and we only have something that looks vaguely like a game. I think it was a good idea to start out by building out the underlying engine and tools, but it's time start to pulling it together into a form you can play. I spent the last week polishing the gameplay flow so there's a back-and-forth between you and your opponents:

Work we've done on that front:

• Automatic camera movement and zooming as units use abilities. This doesn't sound like a lot but it's one of those little pinches of polish that goes a loooong way.
• Giving all attacks/abilities default effects.
• Being able to deploy lancers into start zones.
• Giving sitreps enough triggers and hooks into the battlefield to know when their end condition is reached.
• Adding a "mission complete" screen when the sitreps' end conditions are reached.
• AI that can plan where it wants to be beyond its immediate vicinity. The berserker in the gif above runs after attacking off because it wants to occupy a nearby command zone.

FWIW, here's the current engine graph. It's grown a fair amount from last time, with the largest addition being missions and the editor thereof on the right side.

Portrait Maker!!

I've never made any like a character creator before, so it was fun puzzling this out! We ended up making a standalone portrait maker that directly pulls images from a specified folder and imports them as options in the appropriate category. We've only just started adding assets to it, but it's so exciting to see them all the layers come together into a character.

Here you can see me recoloring, adjusting, and adding eyes and it automatically updating when I switch back to the program:

We also had to figure out how to handle letting the player recolor certain parts of each layer. The answer for this kind of fancy graphic stuff is almost always 🌈~shader magic~🌈 and we found a recoloring-sprites one available for godot here. With that as our starting point, we adjusted it to be able to handle multiple channels of incoming color, allowing us to specify where to put up to three incoming colors to an asset.

Here you see the base channel (red) being applied to the entire area of hair. The yellow and magenta areas in the starting asset tell the shader to put the highlights and root colors there, if present, but fall back to red if they're not.

We experimented with blending (e.g. mixing the underlying red with a chosen blue highlight) but didn't find an immediate use for it that couldn't be achieved with just another color palette. We're going to keep that in our back pocket in case we want to do something fancy in the future.

In case you're curious, here's the engine graph for this system.

Dialogue

Visual novels deserve more respect. Managing that much text is not easy.

Background: it's good practice to keep your text content separate from your code in case you ever localize it to other languages, for the reasons listed here. But even if we don't end up translating LT, keeping the list of strings in a unified file makes reviewing and editing that text much easier than if those string were scattered around in a hundred different files.

So for LT, we've been putting all of our text — everything from menu options to ability descriptions — into a google sheet and have a utility that downloads and compiles it into a file that Godot can consume. Every string is associated with a key, so when we want to show some text we just ask Godot to give us the string for that key. The spreadsheet looks something like this:

However, this system works a lot better for static text that is true for one-off mission-based text. We don't want to have to write dialogue in a spreadsheet (much less assign each line its own unique key). We want to write it in-context in the mission editor here.

I'll spare you the gory details, but juggling where that text is saved, how unique keys are generated for each line, and compiling those chunks into the godot localization system took some figuring out and I came out with an appreciation for visual novels and other dialogue-heavy games to keep it together.

Animations

Previously, I said that we'd flesh out the animation system at a later point. That point was reached as part of the aforementioned vertical slice work. I put together a little preview utility to aid in making these effects.

Stuff that went into this:

• Gave effects better control of their "wind up" periods and went to apply damage. You can see that above in the two melee attacks where the attacker pulls back before the hit effect is played.
• Flashing enemies on being hit. This is usually easily done with a shader, but we are already using a shader for unit sprites (allowing the pixel art to resize without looking like garbage) so I had to actually make a second white copy of the sprite and fade it in and out on top of the original.
• Being able to mix & match different attacks and hit effects.
• Particle systems! The bullet hits above are defined by a particle emitter. I've only worked in custom engines before so having these ready to go in-engine is a very exciting area for me to explore.

Whew. I started this thinking there wasn't much to talk about, but the bullet points and gifs add up. As always, I hope you enjoyed getting this little look into the dev process. :)

Physical rewards are on their way!
almost 3 years ago – Tue, Sep 26, 2023 at 09:14:22 PM

Headline says it all! Carpenter flew up last week & we gathered up some friends and had a packing party for the 2000-odd letters and parcels we had to ship out. I'm so happy that we were able deliver these on-schedule. We're doing great.

Notes:

Coin tiers ($96+): you should have gotten email with your tracking number.

Sticker tiers ($36 tier): I think tracking emails might have also been emailed out for Veterans  but with an invalid "n/a" as the number; we don't get tracking numbers for small postcard-sized envelopes, but they're on their way to you nonetheless.

Grunts ($10 tier): It ended up being easier for us to just send you all the stickers than individually parse out which one you chose. Enjoy the extras, merry christmas.

Late-comers: There's a handful of people who filled out the survey just too late for the lock-address cutoff. I'm going to start batching these and sending them out (hopefully) weekly until they stop trickling in.* If you filled out your survey just last week and didn't get a tracking email, this may be why. Message me if you're unsure.

Finally, if your package shows up missing anything or it's been like a month and you still don't have it, please message me so we can replace it! Although we did our best, percentage-wise we're bound to have missed a few & some are bound to not make it. I have a healthy buffer of replacements waiting, so just let me know!

Here's a picture of everything you should get, with/without a coin and with a variable number of stickers depending on your tier. As previously mentioned, I re-printed the IPS-N stickers because I picked the wrong material the first time around. Looking at them all in totality, the original glossy one would have been totally fine, but what's done is done and I need to get them off my hands so y'all get both.

* this is a joke. surveys will never stop trickling in. the record-holder from my last campaign filled out their survey six years after the campaign was over.

Progress gifs + rewards update
almost 3 years ago – Mon, Sep 18, 2023 at 07:42:13 AM

Last call to fill out surveys!

We'll be packing up rewards this coming week and plan on shipping them by the end of the month! Addresses will be locked this week, so if you've moved or are reading this and somehow have still not filled out your backerkit survey (260 folks as of the time of writing) now is the time to fill it out. If you've lost or never saw your link, you can find it again here.

Generic progress report go!

OK I know I said this month would be slower because I'd be traveling and taking some time off and I swear I did (thought I had to cancel going to Ireland because of a Covid scare) but still found time to add... actually quite a lot of stuff. I mostly focused on adding features to the battle engine.

(it should go without saying: since we've been mostly focusing on the engine and UI design, all these graphics are still only a step past being placeholders)

Line of sight: I was able to re-use a lot of code from the demo, which itself borrowed this algorithm from the rougelike community. I spent a weekend trying to optimize it enough to use in gdscript instead of c#, but it ended up being too slow. To calculate for an entire map, the gdscript version took around ~25 seconds to run as opposed to the ~2 seconds in C#. This means that there's not going to be another web version of the game until Godot 4 is able to export C# code to html5 — which I've seen a few mentions that it's being worked on so a browser demo remains possibly possible eventually.

Pathfinding: Godot's built-in A* algo is not set up to have multiple possible movement costs to enter the same tile (such as the difference between climbing a cliff and stepping there from the same elevation) so I had to come up with a sorta-weird hack where I stacked a bunch of pathfinding nodes at the same tile; one for every possible movement cost that could enter that tile. It now is smart enough to use ramps and step up cliffs gradually using shorter climbable objects as stepping stones.

Attack animations: Although we haven't been focusing on the fancy graphical juice of the game, I still needed to set up the structures that would contain the animation data. Not much to say here besides we've done so and will probably flesh it out more once we start focusing on game feel.

Destructible terrain: terrain tiles now can transform into another specified tile when they are damaged (half health) or destroyed. I also added support for multi-tile terrain objects (like large rocks) that share a single health pool.

Enemy AI: I've added a draft of a controller that gets the enemy to run around and use their weapons. I've tried to make it a little more robust than the version in the demo where they just run at you until they're in range and then shoot, but of course this means there's now more room for strange behaviors. For instance, some of them are currently doing a weird little dance before and after they shoot.

Weapon profiles: it's a very strange experience playing Baldur's Gate 3 while working on a video game adaptation of a different TTRPG. I feel like I have a little peek behind the curtain having dealt with many of the same challenges inherent in doing so. One such challenge is how to wrangle the many, many actions available to a character and deal with those actions contextually becoming available and unavailable.

For example, in BG3, when you cast the Hex spell on someone, you become able to re-apply that Hex to a different enemy without spending another spell slot. One way to approach this would be to give some kind of discount on the Hex action so using it again doesn't cost a slot —  but what they've done instead is a far more flexible, modular, and stateless solution: they simply make an entirely separate second version of the action which does not cost a spell slot show up in your action bar. Having abilities be able to just in general hide and show various versions of  actions means you can use that same system for weapon profiles, charged and uncharged modes, and temporary bonus actions like  the re-application of hexes.

So we've copied this for LT. Here's the Drake's assault cannon, which  has two modes: regular and spinning. Using the "spin up" action hides  itself and the regular attack, then shows the spinning and "spin down"  actions. This is also a glimpse at the direction Mark has been going for  the player interface — we're taking some more pages out of BG3's book  and making an icon-and-tooltip-rich action bar instead of the demo's  nested radial menu system which was stylish but we think would end up  being too impractical.

Contextual actions: Sometimes you need to take an  action that comes from your environment instead of from your own  abilities. Since we've done a good job keeping the code for the actions stateless (they don't know anything about where they are or who they belong to  beyond what we tell them when they're activated) it was just a matter of  asking a unit's neighbors if they have any actions they'd like to  share. Here's an example of that in action: a restock drone giving an  adjacent ally an action to consume the drone.

Finally, I don't have a good gif for it, but I expanded the  Buff/ongoing status condition system to have the ability to run custom  snippets of code in reaction to events, just like legit Reactions do.  This will give us the ability to do strange one-off things like handle the Witch's Chain ability that monitors how far the unit it is applied  to moves and do nasty stuff when triggered.

Next month we're planning be shifting away from the battle engine  somewhat and working on more character sheet + pilot portrait maker  stuff.