Port to "Enhanced" Quake 2?

[Raptor007]

Unfortunately the Quake 2 "enhanced" remaster that was just released on Steam doesn't seem able to connect to real Quake 2 servers, and it can't load Q2 mod DLLs either. This means there's no way to use it to play Action Quake. What a waste.

I haven't dug into the code yet, but I suspect the reason there's no compatibility is that modern shooters typically provide immediate shot feedback (or at least the illusion of it) which requires a different approach to shooting in the netcode and mod. If I'm right, the game mod would need to tell clients how they should act when firing so they don't have to wait for the server to provide all the feedback. It's an admirable goal to reduce perceived lag. Still, I wish this had been handled as an optional extension to the existing netcode, like how Q2Pro added packet compression for compatible clients while retaining full compatibility with legacy ones.

No idea yet how much work porting AQ2 to this would be, or if I'll have the time and energy to do it (I have a 1-year-old now), but unlike Quetoo at least an attempt has been made to provide a mod interface. It looks like they've decided to compile mods as C++ now, which is no problem for me. However, the requirement to include JSON makes me worried that perhaps some poor decisions have been made in the new code that may make porting mods more onerous.

[darkshade9]

I've taken a cursory look as well, it seems that there is significant work and testing ahead if we want to port it. I am not familiar with the cgame model, but Paril said everything we needed was in the Github. Probably involving a lot of GetExtension usage.

As you know, AQ2 was one of the few that took advantage of variable server FPS, but with Q2RM I believe it's locked at 40Hz (which I think is fine, but requires a good deal of playability testing). This is one example of things we might need to pull out of the dll?

I'm happy to do what I can to assist -- being one of the prominent mods of the community, it could be a big boost to player counts. I still have a good deal of general questions, such as

1. Will console players be able to join in or will this cgame/client framework give us all kinds of problems? How will game updates work for them (and us, in case something upstream breaks AQ2?)
2. Will we need a source port of the engine to do what we need? AFAIK there's only a Windows release.

[darkshade9]

If you'd prefer, we can do real-time comms in the AQ2World Discord in the #code channel, I'm sure Reki and ReKTeK are also interested in discussing the plans. 🙂

[Raptor007]

Personally I like having discussions here because it maintains a record that's easy to find later, and doesn't require any scheduling. But I could hop into Discord sometime if that works better for you guys.

I've now scrolled through the readme for the re-release game DLL and it looks like they went down the same road as Quetoo: at some point they decided compatibility with the Quake 2 netcode and mod interface were not part of their design parameters, and so they changed anything they felt like changing, wherever they felt like doing it. That kind of slapdash refactoring dramatically increases the time and effort to port mods. Perhaps more importantly, it defeats any easy way of pushing the same changes to both the original mod and a port; if both are maintained, they must be maintained separately.

Considering the re-release is just for Windows 10+ and consoles, I would not shift my effort to supporting it instead of the original Q2 mod; the source ports and legacy releases of Quake 2 reach a much wider variety of platforms, including some that I use like Linux.

I am disappointed to report that my earlier guess as to why they would break compatibility with Quake 2 servers was wrong. I dropped into a high-ping game (~250 ms) of the re-release just to see how it handles it, and it has all the usual Q2 lag problems, including the long delay when firing hitscan weapons like the shotgun. There's no immediate client-side shot feedback. Honestly I don't see much benefit to the re-release vs other source ports for multiplayer, especially with the lack of compatibility.

I also looked for a dedicated server browser, but there doesn't appear to be one. It only seems to track self-hosted games by others currently playing, though it does still have the connect console command.

From all this I would almost conclude it's not worth porting at all. But... anyone running Quake 2 in Steam on Windows 10/11 now gets the re-release by default, and it would be nice if they could experience Action Quake too.

Time and effort permitting (and I'm not sure I have much to spare right now) I'd lean towards a limited port, starting with the re-release Q2 source code and just pulling in the essential parts of AQ2 like its weapons and items, bleeding, limping, bandaging, kicking, and round-based teamplay. I'd leave behind the LTK bots and tweak the re-release bot code just enough to know how to reload, bandage, and select weapons and items. I would also not bother porting additional modes like domination, matchmode, tourney, etc -- that's more to debug and maintain, and without dedicated servers I doubt they'd get much use anyway.

[darkshade9]

I think chatting here is fine, like you said, if we do it in Discord then none of that data ever leaves the platform, which is a reason I hate Discord :( It would be useful for if we want to setup actual planning sessions on what to do and how we address problems, but otherwise using the GH Issue makes sense.

The lack of dedicated servers, Linux support OOTB and no server browser is a stark difference from the classic Quake II experience. The implemented peer-to-peer matchmaking suffers from standard problems -- poor ping/performance, host leaving-mid game, etc. Downloading assets from servers is done solely though an accidental legacy implementation of the old UDP method and not officially supported.

Some of the biggest differences/gaps I've identified so far:

1. Significant refactoring needed to integrate with the API
2. Converting from C to C++
3. Tickrate changes affecting sv_fps -- do we just drop variable FPS support for Q2RM builds?
4. No dedicated servers (planned?)
5. No Linux support for dedicated servers or clients (planned?) I assume Proton works for Linux users but this still excludes MacOS players
6. No server browser or compatible master server system
7. Matchmaking does support mods, it's a matter of getting the mod online/tested, but how does this get distributed to players?
8. Content delivery: Do PC and consoles not need to download/install not only the game library but also painfully slow UDP downloads of potentially gigabytes of assets?

A limited port approach makes sense to me, given that we'd need to support two different repositories entirely and keeping them in full feature parity sync is a challenge. I would say these game modes would be a good initial set to start with:

• Deathmatch
• Team Deathmatch
• Teamplay
• 3 Team Teamplay
• CTF

[Raptor007]

The big advantage of starting with the re-release code is that we shouldn't have to worry about the API changes too much. We'd just modify their new baseq2 functions with Action Quake's code. (The disadvantage is that it will only gradually start to feel like Action Quake as we work through feature by feature.)

You can drop most C code into C++ unchanged. Aside from a few quirks, C++ is essentially a superset of C. For example, there is no need to replace VectorMA with C++ operator overloads; they just did it because they found it easier to read.

The tickrate should be no problem. The nice thing about AQ2's variable FPS code is that it mostly just replaced a bunch of hard-coded 10fps constants to variables like frametime, as well as enclosing some code in FRAMESYNC checks if it should only occur at 10fps. We can leave that as is and just set these variables as if sv_fps 40 was in effect, or better yet, see if the new game code provides its own similar variables (it probably does).

I would guess only the player hosting needs the mod DLL, but I'm not familiar with cgame, so that could be wrong. Sounds like we can't really control getting assets to clients. If the old UDP method isn't sufficient, maybe the server could send a message to new clients that have just connected telling them where to go download the full mod zip.

Agreed on the list of game modes. I meant that the logic for round-based teamplay (and resetting parts of the map between rounds) would have to be ported. DM, TDM, and CTF modes should basically come free with the new baseq2 code, though we'd need to port over the map item spawn replacement/removal stuff.

[darkshade9]

Paril mentioned that he would like to aim for getting HTTP downloads added much like how most of the modern clients are setup, so that will solve most content delivery issues, though timeline is unknown. It was also clarified to me that clients do not need to do anything other than download game assets (textures, maps, models, etc.) to play a mod with the re-release unless the mod changes anything with the HUD or with pmove, then they will need a local copy of the cgame/gamelib, and I assume this would be a challenge to make sure all clients and servers have the latest/synced versions.

Edit: Paril confirmed that both console and PC should be able to utilize HTTP downloads.

[darkshade9]

I've created a fork here https://github.com/actionquake/quake2-rerelease-dll if we want to collaborate our efforts in that repository.

[darkshade9]

We've been chatting in the Quake II Legacy Discord (now called Quake 2 Remastered Reborn Reunited) and thought it made sense to have a community-level repository, since it appears that the original 'source' repository will not accept pull requests or any sort of outside contributions, so we made our own.

https://github.com/q2community/quake2-rerelease-dll

If we make any changes that would benefit the whole Q2 community in this aspect (like providing an example of how to port an older C-based gamelib into the new API) it would go a really long way on getting the remaster some modding support.