Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add in-game level editor #2399

Open
wants to merge 31 commits into
base: master
Choose a base branch
from

Conversation

Alberth289346
Copy link
Contributor

@Alberth289346 Alberth289346 commented Sep 7, 2023

*Fixes #level-editor-is-missing

Attempts to make the level editor more reachable for our users by integrating it in he game.

  • As the number of settings is large, I opted for constructing string names from the name of the setting in the level config file.
  • pos_size.lua adds 2 classes for wrapping position x/y and size w/h as a single value.
  • tree_access.lua can read/write nested tables using paths expressed in strings, _S works too.
  • level_editor/data_storage.lua adds classes for data of the level editor:
    • LevelValue represents a value in a level config file with its data,
    • LevelValuesSection class represents an editable list of LevelValue.
    • LevelTableSection class does the same, except for a matrix of values.
    • LevelEditPage organizes one or more of the above sections into a "screen".
    • LevelTabPage manages all edit pages by being able to select "tab"s for the page to be shown.
  • UILevelEditor the level editor main window class.

I am in the process of adding more table sections.

Stuff notably missing:

  • No UI access to the level editor as a whole. While the main menu can open it, you cannot close it. You can also not load or save level data (There is code for collecting and updating LevelValues to/from a nested tree of tables, but that is never called currently. I am not sure where to add these.

Stuff notably ignored:

  • There is ample room for improvements I am sure.

@Alberth289346
Copy link
Contributor Author

Some notes about the current state.

  • All 30 screens with data values editing have been added, and they all fit in the 640x480 screen assumption.
  • You can open the level editor from the main menu.
  • Screen selection also works.

Converting editor data back and forth to nested tables worked in a previous version, and should still work, as there are no changes done since in that area. Entry point for both is loadStoreCfg(table, direction).
I opted for using the original value names in the level configuration. They are slightly different from base_config.lua, since that tree has .Value added at some points, added by the current level config file loader.

Load and save from/to the file sytstem can easily be implemented with TreeAccess (also tested in a previous version). Currently "save" needs a template to decide where to save what information. The template can also contain the comments.

Missing:

  • No UI for load/save, and for exiting the level editor yet.
  • A save template level config if that is the decided direction.
  • The windowing code doesn't honor invisibility correctly. It's possible to activate an invisible textbox for editing which is less than useful.

Other things:

  • Someone should check that the English texts makes sense.

Future optional enhancements:

  • In development, I wrote a Python script that takes a sequence of name1.name2.name.,nameX, = "some text" lines, and converts it to a nested table like in english.lua. That could be adopted if so desired.
  • Organizing the settings into useful screens hasn't had much attention. Some values can likely be deleted (eg unused objects), or similar objects / topics can be moved closer to each other.
  • Some details are silly to a user, eg left entrance and right entrance door as 2 separate objects. The editor should hide such details.
  • "List-like" settings, like emergencies, win conditions, etc currently have a fixed number of entries (typically far smaller than is allowed). That should be extended to allow adding more entries to the list.
  • Everything is a numeric value, while from a user point of view, a checkmark (for boolean values), a drop-down (for a limited number of allowed values), or a graph in time (for eg number of patients, emergencies, etc) would be much more readable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR:Feature PR label
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants