Modding with Omnispeak

[Multimania]

It's (roughly) 33 years since Goodbye Galaxy came out, so it's time to talk about Omnispeak again. Modding is a really important part of the Keen experience, so introducing some basic support for mods in Omnispeak has long been a goal.

To that end, let me present The Omnispeak Modding Preview Kit (8.4 MB zip, GitHub Mirror).

This is an (unfinished, unpolished) preview of how to create and run mods in Omnispeak.
It includes:

• Mod-enabled copies of Omnispeak for Windows, Linux, and 32-bit DOS
• Debug copies, which display warnings and other information to help you fix any issues you may find.
• Some documentation on how to make mods with Omnispeak.
• Pre-converted copies of Keen 7, Keen Asylum, and Keen 5.5 as examples.
• A huge number of accumulated bugfixes since Omnispeak 1.1. (Even if you don't want to try mods, it may be worth trying.)

It also should work with the 15th Anniversary AAMBA versions, and Operation Station Infiltration was built on top of an early version of this.

As-is, it should be able to (with some conversion) run any mod which just changes levels, graphics, sounds, text, and ]some very basic enemy behaviour changes. (Keen 7 is about as complicated as is possible). More complicated mods can be made, but would require modifying Omnispeak's source code and recompiling — this, for example, is what Operation Station Infiltration did.

The overall way this works is by having "variable files", which store all sorts of "moddable" information. A mod can either replace these entirely, or provide its own file which overrides the originals. The variable files are simple text files, in a ckpatch-style format, and can be easily changed.

So: please give this a try, and let me know:

• Are you interested in running mods on Omnispeak?
• Would you interested in using Omnispeak as part of making a mod?
• Does the technique of "variable files" seem useful, annoying, etc?
• Would you prefer to work with the C source code directly (and can you compile it)?
• Omnispeak uses a lot of Keen Modding terminology (actions, etc), rather than the original game code's (e.g., as used in Keen Dreams, keensource456 cat3d, wolf3d, etc). Do you prefer that? Is it worth changing?
• Is any common change obviously missing?
• Any other bugs, suggestions, questions, complaints, etc?

Depending on what (if anything) people want re:modding, the next release of Omnispeak should be a more polished version of this.

Happy Keening!

[NY00123]

And, here we are I think it's been 12.75 years since the initial Omnispeak preview (if that's what the Keen Day 2012 release was). It's also 10.75 years since the Keen Day 2014 preview, the one allowing a full play-through of Keen 5 (albeit without game saving) and having good compatibility with Keen 5 Apogee v1.4's stock demos (but still having more to go).

Within the PCKF thread for the aforementioned Keen Day 2014 preview, it was also acknowledged that mods were not supported. Well, I guess things have changed now, even if it's still a preview.

Yeah, I kinda seemed to have something leading to the recent release...

It also should work with the 15th Anniversary AAMBA versions

That should be true, more-or-less. There might still be a few issues, but I recall it working with local dev builds. I think it's safe to say that AAMBA15Y was really the main factor in leading to most of Multimania's commits to Omnispeak in the last few months (and also a few commits of mine); At least in terms of timing, if not in contents.

Would you prefer to work with the C source code directly (and can you compile it)?

In my case, the goal was making sure I could use an unmodified Omnispeak binary, including newer future versions (at least if compatibility wouldn't break). Luckily, there weren't that many patches in use for AAMBA, so that seemed to work.

Omnispeak uses a lot of Keen Modding terminology (actions, etc), rather than the original game code's (e.g., as used in Keen Dreams, keensource456 cat3d, wolf3d, etc). Do you prefer that? Is it worth changing?

That's a good question. One example is the usage of the term "state" instead of "Galaxy Action". That's how they had been known in the Wolf3D+SOD sources since the 1995 release, it's just that the identification of Keen 4-6's Galaxy Actions with Wolf3D's states of type "statetype" was not done.

Generally speaking, I think that using the original game code's terminology is preferred. On the other hand, fully renaming things in Omnispeak will be a ton of work that not many will want to do, and there's also the possible concern of mod compatibility.

Then again, having less differences from the original sources may help adapting a game from real-mode DOS to Omnispeak and vice-versa. But (yes, again), more differences in Omnispeak's codebase, including possible refactors, may also have their benefits.

Any other bugs, suggestions, questions, complaints, etc?

One question brought up at times is how to package mod files for Omnispeak. I think that should be discussed here.

One possibility I've had in my mind is having a default file name, like OMNISPK.DEF, recognizable for mods as an alternative to EPISODE.CKx, and later allow loading mods right from ZIP/PK3 files. If they use OMNISPK.DEF internally, then the suggestion here is to auto-detect this file as the starting point, once it was requested to use a ZIP/PK3 file that has a file named OMNISPK.DEF.

To compare the situation for other games:
- You have Vanilla Doom, for which it's often easy to replace resources using a PWAD file with lumps of known meanings given by their names.
- The same holds to assets used in custom PK3 files for (G)ZDoom. ECWolf probably uses a similar approach. All of these ports additionally come with internal PK3 files including default assets.
- For Build Engine games, or at least Duke3D, you have GRP files, and also the need to select a main CON file. For Vanilla Duke3D, The latter is named GAME.CON by default. EDuke 2.0 and a few source ports also recognize EDUKE.CON as another default name. While Vanilla Duke3D and certain source ports expect the main CON file to reside in the directory (outside of any GRP), you have JFDuke3D-derived ports that may load these from GRP or ZIP/PK3 files. Additionally, at least for NetDuke32, it became a convention to use GAME.CON or EDUKE.CON for the main CON file within mods packaged in PK3 files, so you don't need to explicitly specify the main CON file's name.