Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
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