olive 🌺

@wick.works

1556 Followers 334 Following

Neurobiologist, portland game dev 🏳️‍⚧️ Making Lancer Tactics. I miss cohost. www.wick.works | wick.itch.io

Lancer Tactics screenshot with the Worldkiller, Enkidu, Tagetes, and Kutuzov alt frames displayed.
godot 2 screenshot taken from https://godotengine.org/article/mir-godot-habla-dein-language-desormais/
Large red banner at the top of Kickstarter that says "a backer requested an update for Lancer tactics". It also sends an email.
Screenshot from Lancer Tactics. 24 ronin mechs standing at the bottom of a pit with one at the top which somehow escaped.
lots of portraits with the skin color being used for all clothing options
Framed print of a mech walking across a field of golden grass with some scifi troopers.
After 48 hours of torture, Dr. Christie wrote a forced confession — “the best thing I ever wrote,” he later told the BBC, noting that he had made sure the confession included “all my recommendations to the African National Congress” about the best way to sabotage Koeberg and other facilities.
White hoodie painted with metallic green abstract designs
Altered screencap from Gundam of Char as he betrays Garma, saying "Garma, if you can hear me, blame this on the misfortune of my build."
Polling the room: I have the player phase in pieces right now from the click-around-to-inspect change and am thinking about input flow. The current system is: - click action button, then click target to confirm // right click to cancel. I'm considering the model: - click action button, then right click target to confirm. Left clicking opens up an inspect window (matching what happens when you left click before picking an action). To cancel, you'll have to hit escape or click the cancel button. Are people using the right click to cancel frequently? Would replacing that with hitting Esc be worth easier inspection?
Re: modding: so, games made in Godot are extremely easy to decompile and edit, no API required. The support that we'll (eventually, someday) be adding are like loaders/unloaders and tooling to make limited mods without having to do that step (e.g. custom pilot/mech art). I am very confident that as soon as somebody motivated gets set up to do so they will, whether we've added support or not.
Re: using LT as a jump-off point to join tabletop: yes, it's really important to me that people will be able to go through this pipeline! The diversity of what people are doing table-to-table is truly wild so there's always going to be an adjustment/learning period for folks. The best we can do is identify and limit specific common tripping points. This is why I'm much more conservative about making PC-side changes (you want to have your builds work no matter where you go) and why we're not using the rebake grunts. NPC stats and specific abilities are already more variable from the player POV so I don't expect will be outside the normal learning curve for any table switch, but we'll of course will keep an eye on it.
Re: other modules on the table: yes actually! The way I've already implemented escort/extraction was taken pretty directly from Enhanced Combat's MCE and payload rules because they're so much more clear and robust than core. And in this update I added the Dazed keyword from Prototype Pattern Groups because we were having trouble with new players breezing through Brace's description and then being confused why they only had one action the next turn. Making it a status helps communicate what's going on with brevity and tooltips. Generally, if picking up a bit of third party design work will slot cleanly in, solve a problem we're having, and doesn't involve a noticeable increase in scope, I see no reason to not pick it up. (By Enhanced Combat "objective types", do you mean bonus objectives? Or the additional sitreps? I would honestly absolutely love to do both at some point because they're great but are also scope increases so can't afford to in the current dev phase. Plus I'd need to talk to Ralf about it. The EC versions of base sitreps are functionally the same as core though yeah?)
Re: community discussion: I must admit I didn't expect how divisive a topic this would be when started moving in this direction. 😓 I've since learned there's a lot of back and forth there about the designs, but freezing and being afraid to make any design decision because people are split on something will end up with a worse game (see: Darkest Dungeon corpses). So: I'm doing my best to listen to folks (esp KS backers) with strong opinions, but I've got a lot of game to program so need actionable things to sink my teeth into (which is why I keep asking for specifics, sorry).
Re: recharges: oh? That's surprising for me to hear. I haven't done a thorough side-by-side of all the optionals, but in implementing the base kits I typically saw the rebake drop the recharge tag for things that should be more consistent (aegis defense net, hive razor swarm), or added additional "when X happens, recharge Y" triggers specifically to help address that exact problem in the CRB (cataphract impale, eng target designator, pyro explosive jet). Are there specific class/systems that you have in mind here? The closest issue in the rebake that I can think of on this front is that the new Bombard plays games with making its gun loading under certain situations, but due to the difficulty in having the AI make those judgement calls and adding support for a sometimes-Loading weapon I'm likely to stick closer to the CRB for that.
Livestream camera footage of multiple ships, one of which is moment from being boarded by about a dozen IDF soldiers with guns. The activists of that ship are near the front with their hands raised.
A sub-tooltip describing the Boost action that has further subsections about Quick Actions and Speed, all hovering above the Rapid Boost Jump Jets tooltip that talks about boosting and flying.
Large Lancer Tactics poster mounted on cardboard with art supplies scattered around.
Wikipedia entry for Gamergate (ant)
Excerpt from the Napoleon core power: "can only use systems with the shield tag — any others immediately deactivate (systems that do not require activation are unaffected);