Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Olive17 days ago(+1)

Yes, exactly! The benefit of StringNames is entirely for modder flexibility, and are much worse when it comes to typing and editor features. I figured out how to jump through some somewhat-cursed hoops in order to keep the dropdowns in the inspector & code autocomplete, seen here, but yeah lost the runtime type safety checks.

The only other marginal benefits I can think of are more readable JSON files when I serialize data, and ability to remove earlier entries without messing up the int -> meaning linkage.

Reply
FeralBytes16 days ago

For your mod support will you be using the new @abstract to outline the functions as an API or how do you intend to approach outline an API for modders to use? Thank you for the detailed response and again thank you for your time.

Reply
Olive16 days ago(+1)

I’m not planning on setting up a separate internal API for modders; they should be able to use the same general services & utils that the base content uses, e.g. there’s a big unit_conditions.gd file that any ability can call into by saying UnitCondition.apply_status(…) to apply Impaired.

The main way an ability can specify working differently than the general rules is by extending and overriding a function from the base class. For example, action_impact_lance.gd from the Vlad overrides func get_self_heat_dice(context:Context) to only gain heat if it’s catching more than one target in its attack.

The drawback to this is that mods will break as I change the internal implementations // function names. But since these usually represent changes in available context, I don’t see a way to maintain an unchanging API that would still work with the old contexts.

Reply
FeralBytes15 days ago

Okay that makes sense. I just want to lead with I am not trying to make you work out what could or should be done. I am just expressing some thoughts, and not necessarily a good solution as I may not have thought through enough scenarios. Also I realize it is probably impossible to set up a unchanging API this early since the game is still in active development.

So do you have a way to let mod's know the current version API, or is it just the game version?

I really am not sure how I would want to address mods this early in a game either. But I do feel that an abstract would help me control the interactions, and allow me to provide some guarantees to prevent breaking too often. Though perhaps many modders would see this as limiting their ability to achieve their desired modding goal?

Do you check for mods to break on load, or how are they loaded in general? I have only breifly touched on the topic in Godot and generally I see it done as an additional ".pck" that can be loaded at a specific point to the "res:/" like in the docs here: https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html 

Again thank you for your time.

Reply
Olive15 days ago(+1)

All good, these are good questions & I don’t mind the opportunity to think/talk them out :)

Yes, any API I’d be able to hypothetically provide would likely have to change along with the game as more or less information becomes available for functions which would defeat the purpose of it. For standardized sorts of mods like simple texture packs I think keeping the way that they load stable is feasible & required… but for a game as complicated as Lancer I don’t think I can predict what features modders might need to pull off whatever they’re trying to do once they get their fingers into the scripts.

Figuring out how we’re handling mod loading & pck files this week; previously LT mods used the player-made modloader by Gavstar, but I think for the official support we’ll be using the Godot Mod Loader project.

Reply
AboutFAQBlogContact us
Copyright © 2026 itch corp · Directory · Terms · Privacy · Cookies