Draft
Conversation
Contributor
|
Great stuff, the proposed Lua structure is exactly what I had in mind. I don't know much Lua, but if the dynamic loading/composition works as advertised, then this should be a big win for mod efforts. I'd be tempted to rebrand |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR continues the work on modding support for OpenCiv3. Huge thanks to @ajhalme (#891 (comment)) and @stavrosfa (https://discord.com/channels/909680526498082837/1457726459895484598) for the feedback on the current system! I tried to incorporate your ideas into this PR.
The main theme of this PR is to unite three separate scripting mechanisms of OpenCiv3 under one system.
Currently, Lua scripts are part of the logic for
This PR introduces a new class, GameMode, that serves as an entry point for all these Lua-based modding mechanisms. Similarly to rulesets in my previous PR (#848), the definition of each game mode consists of a base and addons. Each component (base or addon) is represented by a directory.
A base directory should hold the following files (for each scripting subsystem). Each of these Lua files must return a table.
ruleset.lua(orruleset.json)behaviors.luatextures.luaAn addon directory may hold any of these Lua scripts. Unlike the base files, these scripts must return functions.
After the base table is loaded, it will be passed through a pipeline of Lua functions loaded from addons: each addon function will accept the current accumulated table, modify it, and return the result. Again, this is very similar to ruleset loading introduced in #848. However, now this mechanism is applied to behavior and texture definitions as well.
As a side effect, the Lua directory is reorganized: now files are grouped by the mod component they belong to. Since we have two components (civ3 as a base and standalone as an addon), the Lua directory looks like this (auxiliary scripts omitted).
civ3
--
behaviors.lua--
ruleset.json--
textures.luastandalone
--
ruleset.lua--
textures.luaOverall, this PR should give us a base for a system of composable mods. For now, the two game modes (civ3 and standalone) are still hardcoded, but in the future we may want to come up with a UI that will allow users to mix-and-match the mods at the start of the game (similarly to Unciv, for example).
For now, I'm opening this PR as a draft, since I want to do some additional work on commenting the code changes. However, I'd like to know your thoughts on my approach. As always, feedback is very welcome!