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.

[Nisaba]

First of all, I think Omnispeak is fantastic, and I greatly appreciate the effort and work that has gone into it. I also believe that you are asking important questions. I will at least try to answer some of them from my perspective.

I consider Omnispeak to be an exciting project for a number of reasons. First and foremost, its portability stands out, which should make it easier for new Keen generations to dive into the keening and modding scene. The native support for Windows systems should lower the initial barrier for those who are not familiar with DOS or its emulation. (And for Linux users relying on the Wayland protocol, emulation through DOSBox is not a stable solution. Instead of working with forks Omnispeak surely comes in handy.) I believe this is its greatest strength, which should be further developed.

It seems to me that Omnispeak could bridge the gap between "I blindly copy patch files from a large database" and "I feel confident working with compiling source codes." However, it would require a good step-by-step guide to reduce the entry barrier for the dedicated modder. Comments I receive from motivated modders after the release of Foray in the Forest often include: how do I easily get into the source code? I believe there is still a need for improvement in this area to further lower the hurdle.

Regarding the syntax decisions, I am somewhat torn. With the above arguments in mind, a user-friendly syntax could certainly be helpful... Personally, I prefer to work directly with C/C++, given the experience I have. Let’s also not forget that these days it is easier than ever to interpret code snippets, thanks to tools like ChatGPT, Cursor, or Copilot. So, maybe stick with C/C++... dunno

The most important question for me remains: who is the intended target audience? And what can be done to lower the hurdle for the novice gamer/modder?

[Gridlock]

I've occasionally wanted to get back into Keen modding, or at least experiment a little, but I've never really broken through the barrier of getting a project environment set up. I don't have a lot of free time or energy, so it's kind of hard to push through the more archaic aspects. For example, I took another stab at understanding CKSRCMOD today, but I got lost around the point where the guide mentioned modifying certain batch files related to paths for Borland 3.1, and I couldn't figure out what batch files it was even referring to.

When I looked into Omnispeak a little while back, I got stuck with figuring out how to actually compile the project with CMake. Unless I missed some documentation, I couldn't find anything about this. For beginners, I think a more detailed environment setup guide could be really helpful. Most of my programming experience is in the context of Unity and Unreal, so I don't have a lot of familiarity with setting up manual build pipelines. I feel pretty confident that I could figure out how to work with the Keen C code if I can get past the initial setup challenges (it can't be more convoluted than Unreal C++ haha).

When comparing Omnispeak to the other modding options, Omnispeak does seem appealing. I've never cared about real DOS compatibility. And, if I'm understanding correctly, it seems like Omnispeak isn't going to run into the same memory limitations that were a real pain with projects like Atroxian Realm (ex: having to compress level dimensions and make cuts to IMF tracks).

I wouldn't say I'm super serious about doing more Keen modding. But, if getting started was easier, it might seem more viable as an occasional side thing. Which is to say, I might be interested if you decide to keep working on it.

[DoomJedi]

but I've never really broken through the barrier of getting a project environment set up.

It's a barrier for me as well in projects.
Though not a great coder - I could consider tweaking engines and mods, but it's complicated to properly set the environment for existing engines/sources.

[weareeletric]

If you want, I can help you find specific setup instructions.