Chaosforge Forum

  • December 08, 2024, 05:39
  • Welcome, Guest
Please login or register.



Login with username, password and session length
Pages: [1]

Author Topic: Mod organization in future versions  (Read 4328 times)

Simon-v

  • Composer
  • Elder Chaos Guard
  • Captain
  • *
  • *
  • Offline Offline
  • Posts: 272
  • Only Human
    • View Profile
    • The Life and Works of One Simon Volpert
Mod organization in future versions
« on: June 29, 2011, 07:44 »

This is the thread in which the modding community shall establish the guidelines for mod loading and organization, to be implemented in (one of) the next versions of DoomRL. It is a follow-up to the related IRC discussion, placed here by KK's request for further refinement and future reference.

Following are my general ideas on how it should work. The community is to add/modify/remove on them.


When the game is launched, a "Modifications" entry would appear in the main menu. When selected, the game would scan the "mods" directory for *.zip, *.pk3 or *.wad files. Those of the files which contain a mod would be displayed in the menu. This can be achieved by having a meta.txt file in the root of the archives, containing:
  • The mod title;
  • The mod author's name, as well as additional credits;
  • A one-paragraph description;
  • The name of the main mod file (usually "main.lua", but could be anything);
  • The mod's version;
  • The DoomRL version for which the mod is intended;
  • A software license under which the mod is released;
  • The mod type ("EP" or "TC", see below).
The mod menu will look much like the challenge select screen, with mod titles on the left and the description, the credits, the mod version and the DoomRL version of the selected mod on the right.

Once a mod is selected, the game will check if its version is the same as the mod's intended version. If not, a warning will be displayed, among the lines of "This mod is intended for a different version of DoomRL. It might work, but could crash or have bugs that will make it unplayable. Do you wish to run it anyway? (y/n)"

If the mod is an "episode" type (i.e., running on top of DoomRL without the need of a custom doomrl.wad), then it would simply load and run as normal, presenting the difficulty selection and trait selection screens.

If the mod is a "total conversion" (i.e., requires its own custom doomrl.wad to run), then selecting it would reload the game and get to the title screen.

A mod can also be run by supplying the "-mod filename.wad" switch on the command line. In such case the game will act as if the mod was selected from the modifications menu. Note that since all the mods are placed in a single directory, there is no need to supply a pathname on the command line.

Mod makers would (obviously) be required to package their mods appropriately.

As most mods are expected to have more than one file, there would need to be a core.include(str path, bool packaged_mod) directive or similar to replace lua's dofile() directive. The core.include would look for files relatively to the mod package, not the DoomRL directory, allowing mod makers to not worry about predicting where their mods will be placed.

If the mod contains sound.lua, music.lua and/or musicmp3.lua, those files will be parsed as well, replacing the default files.

Optional: A mod server in the form of a simple web page listing the mods by their meta attributes with download links and instructions to put the files into their "mods" directory without unpacking.


If When this makes it into the game, my Mod Loader Script will be obsolete (which is a good thing).

Things that still need to be covered: TC making. Should the mod include the recompiled doomrl.wad or a directory with the contents of such? Will doomrl.wad be available for modders along with modification and packaging tools? Should the mod file internal directory structure replicate the structure of doomrl.wad (which i know nothing about)? Should non-TC mods follow that structure as well, for uniformity's sake?

Things to look into while we're at it: the modding wishlist.
Logged

tehtmi

  • Programmer
  • Local Inquisitor
  • Lieutenant Colonel
  • *
  • *
  • Offline Offline
  • Posts: 458
    • View Profile
Re: Mod organization in future versions
« Reply #1 on: July 31, 2011, 17:08 »

I think pretty much everything Simon-v said is good.

For episode vs total conversion, I think it would be best to allow the modder to choose which Doom RL packages to load (e.g. a modder could load the Doom RL beings but not the items).

Each mod should have separate high scores and stat tracking. This could either be in a separate section of the current score.wad and player.wad, or each mod could get its own score.wad and player.wad; I don't really have a preference. It might be nice to provide a lua interface to a custom section in the mod-specific wads to allow mods to keep track of custom statistics between games.

Many mods will probably want to provide a readme file with more extensive information that what is in the mod menu / meta.txt. It would be nice if this were accessible through Doom RL. It might could be included via the in-game help interface.

meta.txt could be in lua format to avoid using multiple parsers.

Currently sandbox modding is centralized around levels.CUSTOM. Full modding probably needs a similar centralizing structure, and none of the existing things seem like they will work. I would probably call it Episode or Modification. It would include global hooks that apply on every level of the mod, as well as a level/floor list along the lines of the current DoomRL.loadepisode. For mods that don't want to use this model of level progression, it should be relatively painless to just provide a first level and then handle level switching manually. Possible, the Episode could also be responsible for providing a function to load new content.

Mod unloading without reloading baseline Doom RL from the wad is probably too much to attempt even for relatively simple mods, as it is easy (and sometimes desirable at least by me) to wreak havok with the baseline Doom RL content.
Logged
Pages: [1]