Xonotic port/reboot in Godot - roadmap

If you're thinking about "porting the game", the first thing to take care of is implementing the most important things that the current version of the game has.

For me personally, these things are movement, warpzones, sandboxed modding (CSQC) and lots of existing content since 1996.

Bullshit.  Without networking code, none of that matters because you will simply not have a game.

(Damn, why did I spend three hours writing this post?

Because you care.

Without networking code, none of that matters because you will simply not have a game.

Yes, but the netcode should be designed with all these things in mind. In Xonotic, majority of network-related code (except for input and movement not sure...) is implemented in QuakeC (look at NET_HANDLE for reference), and that way non-vanilla servers can customize the protocol to their needs. This also allows older versions of Xonotic to connect to newer servers without having to install a new version of the game (as long as CSQC doesn't require builtins that are not present in older versions of the engine). I expect a similar level of flexibility from "the ported game", which implies something like sandboxed modding, that's why I think this should be the very first thing to investigate.

Without networking code, none of that matters because you will simply not have a game.

Yes, but the netcode should be designed with all these things in mind. In Xonotic, majority of network-related code (except for input and movement not sure...) is implemented in QuakeC (look at NET_HANDLE for reference), and that way non-vanilla servers can customize the protocol to their needs. This also allows older versions of Xonotic to connect to newer servers without having to install a new version of the game (as long as CSQC doesn't require builtins that are not present in older versions of the engine). I expect a similar level of flexibility from "the ported game", which implies something like sandboxed modding, that's why I think this should be the very first thing to investigate.

First, sorry about "bullshit".  I've done looking around for how Godot does network and everything I've seen so far is not what I was hoping.

gdscript is like python (quasi interpreted so slowish, compared to a bytecode language like C# which Godot supports supposedly, which might make things better.  QuakeC is a bytecode language.)

I'm pretty familiar with DarkPlaces protocol that is used for Xonotic (DP7), and it requires a lot of setup and it stores quite a bit of information -- and the time stamps are also important.

The Xonotic QuakeC transmits on top of the DP7 protocol, which allows customized messages like what you linked above.

For example, connect to a Xonotic server and type "status".

It will show "protocol: 3504 (DP7)".  DP7 tracks player input, momentum, a baseline which is the default stuff on the map, tracks what changed, gets "acks" from the client indicating what the client has received (so a lost packet doesn't screw up everything) and there is also the prediction.

I have not yet seen anything out of the box that does this kind of stuff for Godot.

Maybe it exists and I haven't found it yet.  Without it, it would be quite a bit of work to recode something similar to DP7 in, say, gdscript.  It would probably be easier to get it to go in C#, but still no small amount of work.  Would the slower speed of C# compared to DarkPlaces compiled C matter?  I don't know, maybe or maybe not.

And this is assuming there isn't some sort of out of the box solution for Godot that does this type of thing.

Maybe there is.

If you're thinking about "porting the game", the first thing to take care of is implementing the most important things that the current version of the game has.

For me personally, these things are movement, warpzones, sandboxed modding (CSQC) and lots of existing content since 1996.

Obviously, we can replicate almost all of Xonotic's gameplay on another engine (it doesn't matter if it's Godot or not) because it's basically just a first-person shooter. But if you lose some unique features because of the current engine limitations - would it be worthy of being called Xonotic? I'm not sure.

Even if there will be Vulkan, PBR, RTX, lobby, voice chat, blackjack and beautiful female player models - does it all matter if I can't just connect to a non-vanilla server and play weirdcube_v2.bsp?

So for me the list of major things looks something like:

- Do something with sandboxing, modding, mutators etc. This is probably the most important thing that may affect the entire architecture of the game, so I think this should be the very first thing to investigate.
- Do something with bsp, q3 shaders and maybe other assets. The current state is very far from "99% success rate" - almost every map will have some ugly bugs because of the limitations of the current plugins. The process of loading resources at runtime will probably be closely related to modding and mutators, so I think this should be the second thing to investigate.
- Do something with warpzones. I know it's possible to implement some warpzones in Godot, but since it's a pretty complicated thing, I'd like to make sure it's fully compatible with the Xonotic gameplay.
- Do something with movement and related things like client-side movement prediction. I hope this is relatively easy to implement, but since the Xonotic movement is not the same as either Quake or Nexuiz and the movement prediction is not trivial, I think it makes sense to pay some attention to it. By the way, players can move through warpzones.
- Last but not least is optimization. I know that Godot 4 is not optimized yet, but will it be well enough optimized in the future? Is GDScript fast enough? Will sandboxed modding fast enough? Liblast is literally unplayable on my PC due to lots of freezes. I hope this will change in the future, but if the "new Xonotic" can't be as fast as "good old Xonotic", then most players will probably stuck at DarkPlaces just because of performance.

Many other things (gameplay, weapons, graphics, netcode etc.) are minor to me because liblast has already proven that it's possible to implement them in Godot.

(Damn, why did I spend three hours writing this post? I think I'll leave this topic and come back only when the first two items on the list above are resolved.)

Andrewmal, a lot of this has already been addressed in the first post, so please check it again to understand the situation.

• All bsps and old maps can be loaded via described route
  
• loading any sort of legacy formats at runtime is simply the wrong approach (at best this is an advanced no-priority feature for a version 1 or 2)
  
• For a start and dev purposes, the tools available allow in principle most maps to be converted into a playable state, and only need some very defined and clear future improvements to improve mostly-visual flaws and get to better production-alike results
  
• sanboxing support does not exist, so there is no suport to dynamically load mods (or anything for that matter). This does not mean however, that mods and custom assets cannot be loaded. It means that they need to be checked and verified by a centralized authority, and then can be distributed as trusted binaries. This is not so nice, but it is also not the end of the world, considering that it is only a temporary solution.
  
• the network code from Xonotic needs to be replicated by hand, just like movement code to be true to the original. This is the most laborious part.
  
• warp zones don't happen out of the box, but they are also not really a huge deal, considering the abundance of advanced camera and physics functions of the engine
  
• GDScript speed questions were also already answered (tl;dr it is an unecessary concern)
  
• if Godot was to support sandboxing in the future, there is no cause for concern for it to be slower
  
• Liblast cannot be used to make conclusions about performance, since both engine and game are both not in a production state, this was explained also. But by rule of thumb there is reason to believe a Godot port will be overall "somwhat" slower, while being faster at other things that also matter (e.g. when having many players or bots on the map). In the end there is just no way to know for sure. The only thing we know is that Xonotic is in certain aspects already unusually impaired in performance from QuakeC, and that current technology is almost 100 times faster than what the required specs would be to run similar graphics. This number doubles every 2 years. Meaning for now and the future, even worst case scenario we are always far far in the green.
  

Currently, the lack of sandboxing support is the only almost-deal-breaker aspect about Godot. It would just be a huge shame, because modding would be what drives all those new possibilities and advantages coming from Godot. But it would be very short-sighted to say that Godot will never support any sandboxed modding in the future. To the contrary, this feature is bound to happen sooner or later, and this aligns very very well with a realistic timetable we can expect for a full-blown Xonotic Godot port (years). At worst and last resort, basic sandboxing support could be added by us into Godot. Just like Patch support into Libmap (Qodot), whereas the latter would be much less work.

A port will be a work-in-progress for a very very long time, and to demand this and that to be here by yesterday - and to ignore that things will just peter out eventually one way or the other - this is just not reasonable and realistic to get anything done in life at all. With that attitude you just doom yourself. Xonotic will "die" if it can't evolve, it is just a question of time, and we already have seen it happen. How quickly do years pass, or even decades? This is what we should be afraid of and work against. When thinking of right or wrong, we should look at how things will be in 5 or 10 or 20 years and not how they are today. Look at how there is no mobile version of Xonotic, because everyone I talked to about it said "we should not even try this, because it would suck when we don't have this and that on mobile" - although there already are simple Quake engine clones for mobile that can somewhat run Xonotic. If mobile had been a priority, hundreds of kids who saw the game stand out from all the ad-riddled garbage they usually play on their phone, those kids would be adults now playing it and now they are not. And now we are at a stage where the engine itself gets too outdated in 5 or 10 years down the road, so we have to work with that now. We can learn from what has happened in the past to make better decisions in the future. The mobile Xonotic we need now is a Godot Xonotic, and then with time it is the only kind of Xonotic people could be bothered about, who weren't already part of the old community.

To a player Xonotic will be Xonotic if it looks and feels the same, because it has all the assets like old player models or community maps and it has the same movement code and such. What file extensions it uses, or minor differences about how shaders are displayed, this is not something the vast majority of players care about. Yes details are also important, and maybe a lot of work went into them in Darkplaces. But if it is time to move on, one must take the bigger step and make choices that are healthy on the grand scale. If we have the man-hours and capacity to make this one big step to Godot, we really should. If not, then maybe given enough time, things will get even easier and rosier than they already are. Who knows, in 6 years time, we could simply command ChatGPT to do all the coding for us. In that light, you could say it would be kind of stupid to do all this work and make this huge effort to port Xonotic by hand, when we could simply sit this out and have it magically appear some years down the road. There is much to be said in favor of that perspective as well. But so it could be said about anything in life, so who knows what to make of it.

Look at how there is no mobile version of Xonotic, because everyone I talked to about it said "we should not even try this, because it would suck when we don't have this and that on mobile" - although there already are simple Quake engine clones for mobile that can somewhat run Xonotic.

Does the Xonotic Android compile?

I ask because I see Android stuff in the source code.

If it does, and if you can get me those instructions so I can compile it, I can add proper touchscreen capability to the Xonotic 0.8.5 engine.

5 years ago ... I made this Quake for Android

@Baker:

I am really not that well informed about network programming in Godot. What I know is that Godot and other engines don't make it that much easier.

I think you are worked way too much into the details. While it might be important to copy the movement code 100% in a port, I believe that network code only needs to match old code in very basic aspects. Such as that it is input-based and maybe how interpolation happens.

The performance concern about GDScript is misleading. Firstly GDscript will no longer be fully interpreted in future Godot versions. Secondly, the engine does the legwork, and the scripts only point it in the right direction. Xonotic is not a use case (like a city simulator game) where this would be radically different. It is just not right to say, that because it is "interpreted", it is this and that, 3x or 4x slower, this is somewhat misinformed. There will be some remarkable slowdowns in Godot, yes, but this has more to do with bugged or poor implementations in the engine.

Look at how there is no mobile version of Xonotic, because everyone I talked to about it said "we should not even try this, because it would suck when we don't have this and that on mobile" - although there already are simple Quake engine clones for mobile that can somewhat run Xonotic.

Does the Xonotic Android compile?

I ask because I see Android stuff in the source code.

If it does, and if you can get me those instructions so I can compile it, I can add proper touchscreen capability to the Xonotic 0.8.5 engine.

5 years ago ... I made this Quake for Android

Oh that was you?! Amazing! I think this is even the Android Quake engine that someone used for Xonotic, not sure.

Basically you only need to load the Xonotic pk3s with a compatible Quake engine. I am not sure if other Quake engines also work, some are related to Darkplaces, maybe? 

What I remember is that there is source code on Github (that doesn't run). And someone has actually managed to load Xonotic on Android before. But I don't know if it was via proprietary app.

I'm not saying it is super-easy, but it is also not far-fetched to do this. Just that no one did it, because they hated the idea. Heck, I hate the idea too, but the value of it in terms of advertisement/recruitment is undeniable to me. To get an App on Google Play you have to pay a $20 fee once in a lifetime, lots of devs like myself have done this.

Oh, if you mean the Android stuff in the Makefile, I believe this is just redundant. I am fairly certain there is zero actual Android code in Xonotic.

@Baker:

I think you are worked way too much into the details.

I'm scoping all of this out trying to assemble a rough plan in my head.

If I see enough consecutive stoplights that are green, I might even go "for it".

I'm not seeing that so far.  I see some red lights.  In my head, I want them to at least be yellow if I can get them there.

My motivation is that right now, I look around and I feel like open source is "losing" in the games category. It makes me very upset. I see Unity, I see the "sort of" open source but "not really" UE5.

Sometimes I ask, should I put time in DarkPlaces or is that time better spent in Godot. But when I look at Godot., I see a half baked cake.

But maybe the cake is gettiing closer?

I'm just explaining.

Oh that was you?! Amazing! I think this is even the Android Quake engine that someone used for Xonotic, not sure.

Glad you've seen something I made in the past.  (It can't run Xonotic) 

I may end up taking a crack at an Android Xonotic/DarkPlaces at some point .. the dependencies (TrueType and such) ... are a wildcard, I am not super-familiar with the process to "Android those".

I see some red lights.  In my head, I want them to at least be yellow if I can get them there.

My motivation is that right now, I look around and I feel like open source is "losing" in the games category.  It makes me very upset.  I see Unity, I see the "sort of" open source but  "not really" UE5.

Yes, exactly! This is my motivation too. 

The good news is that Godot is a ticking timebomb. One day we will have a shooter like Liblast take off over night, probably it will be a Fortnite-ish or COD-ish game, maybe a little bit CS-ish. And then it will steal >80% of Xonotic players and dominate all of FPS open source gaming. Xonotic will then only be like Open Arena or Rexuiz: dead with few if anyone playing it.

Well the bad news is, this will just be the inevetable death of Xonotic.

I believe this new game, it should be Xonotic, or very close to it. Xonotic should be on the frontier again. It should not be a conserve, only to be authentic to the retro experience and some outdated mentality. It should always be the "thing" in libre gaming, now and next year as well.


What serious red lights do you see?


Godot is not a fully baked cake, yes, but it tastes very good regardless. Godot will always be in some aspects beta-ish and unready. But what it can do and what it does is amazing and nothing really huge stands in the way to port Xonotic into it.


Btw. if you are thinking about diverting dev effort from Darkplaces to Godot *do not decide in favor of Godot*. Doing a port to Godot only makes sense if enough people are pulling on the same string and if we have the man hours to do it. This is not the case right now. However, Godot is just like Blender or Photoshop, a program that can do a lot of great stuff without serious investment. And taking a look at it and giving it some good thought, this doesn't hurt anyone and is beneficial in many other ways.

If on the other hand you really want to improve Godot or Libmap (Qodot), for a Xonotic port or maybe some kind of entirely new game, then the Patch support and maybe the sandboxing would be the best places to start. Though sandboxing is a really major feature, I don't know I think sitting it out is in most cases the best idea.

I'll just sit back and watch and think ...

I just saw this ... looks fantastic:

https://www.youtube.com/watch?v=EvMFVIsoh-4

There is a topic discussing sandboxing in Godot: https://github.com/godotengine/godot-pro...ssues/5010

It mentions a WIP WASM sandbox: https://github.com/ashtonmeuser/godot-wasm

But IMHO from experiences with similar technology in projects like Unvanquished (NaCL) or 0 A.D. (embedded gecko) I would advise against embedding a complex web-centric sandbox like that.

If I was to design a Godot based version of Xonotic (but I am not) I would probably write it in lua and add a luau sandbox (as used in Roblox, and thus well tested). See:

https://github.com/perbone/luascript

https://github.com/Roblox/luau

Edit: apparently something like a lua sandbox already exists for Godot: https://github.com/WeaselGames/godot_luaAPI

There is a topic discussing sandboxing in Godot: https://github.com/godotengine/godot-pro...ssues/5010

It mentions a WIP WASM sandbox: https://github.com/ashtonmeuser/godot-wasm

But IMHO from experiences with similar technology in projects like Unvanquished (NaCL) or 0 A.D. (embedded gecko) I would advise against embedding a complex web-centric sandbox like that.

If I was to design a Godot based version of Xonotic (but I am not) I would probably write it in lua and add a luau sandbox (as used in Roblox, and thus well tested). See:

https://github.com/perbone/luascript

https://github.com/Roblox/luau

Edit: apparently something like a lua sandbox already exists for Godot: https://github.com/WeaselGames/godot_luaAPI

Wow that is interesting, I didn't know there was a sandboxed Godot Lua API.

It would be better to wait for "real" sandboxing first though, than to go for this option. Godot already uses an interpreted language, so the engine only needs to disable/modify a couple of functions like arbitrary file reads and such to make a sandbox. That's why there is no need to use Lua at all. You could potentially code and mod anything at no speed penalty. It is only a question of when Godot devs will code it and make it mainline.

Lua is actually the scripting / modding language for most large game engines, so I would see that as a plus if you want people to contribute mods.

...

poVoq,

I knew I saw your name very, very recently but until 2 minutes ago I didn't know why ...

https://github.com/poVoq/Quake-1-Android-Port-QI4A

That's very ancient code FTEQW also has an Android (and web) port: https://www.fteqw.org/ and it already sort of runs Xonotic.

Yeah, I know.  I've interacted with Spike thousands of times, haha.

I wouldn't know what I know today without him.

Just wanted to share this video, it shows how easy it can be to create multiplayer FPS:

https://www.youtube.com/watch?v=n8D3vEx7NAE&t=1492s

However, as I understand it, this a very simplistic way to do it which is not cheat-safe and also it doesn't work with a dedicated server.

Still though as you can see, what would take thousands of lines of complicated error-prone code in QuakeC can actually be done by noob programmers with tiny scripts in Godot. This is the huge advantage of Godot: lots of devs will come in to help, code will be so much more managable and new amazing features can be added that ship with the engine.

I'm not a Godot expert, so I would have to study proper network code from the Godot 4 CS-alike shooter I posted ( https://git.join-striked.com/striked-gam...ce-shooter ).

This video also provides an overview for dedicated server: https://www.youtube.com/watch?v=M0uGZu0eH0I

It seems to have gotten a lot simpler in Godot 4.

Godot is cool, but as seen with the Liblast project, especially multi-player still requires a lot of custom code and is far from easy to get working well. I think this is one of the post 4.0 release plans to improve on that, but right now making a multi-player game in Godot is probably not the best idea.

I think this is rather true to Godot 3 than 4 and if you were talking about Godot 3 I would have somewhat agreed with you. However the recent improvements in Godot 4 really seem to make it a breeze by comparison. Though, there are tons of examples that prove that it works well regardless in Godot 3, with appropriate effort.

It must be said though, that both versions are obviously well capable to make a well functioning multiplayer game. Neither Godot 3 not 4 make it a bad environment to code a multiplayer FPS in. It is just that in Godot 4, you really have it so much easier than in 3 to get to production results fast, with little to no effort, like you would expect it from a modern engine.

Liblast is a lot of hack-and-slash development, paired with shortcomings from using early beta and naturally that also often means using Godot 3 style approaches.

This is why I think it is rather bad to look at Liblast for comparison.

If one were to develop an FPS from scratch with very thought-trough and clean code in mind, it will probably turn out a whole lot less troublesome.

Just chiming in ...

The network and prediction code in DarkPlaces in the engine in C code and the Xonotic in QuakeC prediction code are very intricate -- there is a lot of it with a lot of exceptions and special cases, certain things have to happen in certain orders on both the client and server.

And I imagine it evolved from the results of live testing over a period of years.

And part of it is recording of a history of actions and for certain things doing a simulation of the client point of view on the server (like to see if an attack hit).

And it is one of the strongest things about Xonotic and would be the hardest to replicate and due to the myriad of things occurring.

I would firmly classify that aspect of Xonotic as rocket science.

If watching a video of Godot ask ... does the video have multiple real players connected that are connect thru the internet and not lan and are any of the players bad ping.

If the video does not have that, it may only be demonstrating networking of a "local game" which involves none of the rocket science hard stuff. 

Establishing a network connection is An Introduction To Networkng 101 course topic.  As a counter-example, Quake3 from 1999 had complex networking/prediction with, as I recall frame buffer histories.

Network code is intricate, but not impossible to replicate. Poor design makes a poor experience. The videos posted are just examples to understand the basics.

Back in the day it used to be complicated, because you couldn't just copy established well-working algorithms from good examples, like you can do now. Also ping was commonly between 200 and 300, sometimes even more, and bandwidth was only 3-5kb/s.

I'm not an expert, but I have seen Xonotic and Quake 3 network code and I am fairly certain that it is actually not overly complicated and fairly basic in design if it comes to just handling player input and facilitating basic movement, shooting and so on. The only thing that makes it rocket science is when it is written in QuakeC or bare C, which can turn trivial simplistic things such as displaying the map voting screen into a huge mysterious mess. This is totally unlike what you can see in the videos.

So it is true, if one was to write network code blindly from scratch, it will probably turn into a fiddle-nightmare and be very hard to get right. However that's why you would want to copy well-established code and methods from Xonotic and other games.

I am currently adding Patch support and BrushDef support to Qodot, the .map importer plugin for Godot.

Check out progress here: https://github.com/QodotPlugin/Qodot/iss...1771591798

Someone started porting Quake 3 to Godot, i.e. for the engine to load the actual Quake 3 assets from .pak files.

It is quite impressive.




This does make it easier quite some to port Xonotic as well. If he has written an interpreter for Quake 3 shader format for example, or if the movement code works well, it's just another major thing you can check off the list of stuff that you would have to deal with in one form or the other. Making it *even easier* and easier than before to port Xonotic.

It is written in C# though, which I and many people have mixed feelings about. It is not bad though, just GDScript would have been preferable in a perfect world.

But unfortunately, however great and helpful that project is, I think that it does not take away many of the core things on the list to make a competitive modern game, such as having good network code and more universal mod suport. And also loading .bsp instead of .map is kind of a backwards approach in my mind. This seems to make sense to me, when the main goal is to support legacy formats, rather than having new workflows and modern formats for a modern game. But hey, it works too. What an awesome place to start if things just work out of the box like that! In the end however you want to have it, it's just yet another feature you can have, and you can load all the old maps without any manual effort. The vast amount of community maps is the gold of the entire game. This is why I would have started with .map support rather than .bsp, so they can be adapted for new content.

Anyway, with such awesome and pioneering developments, maybe in a year or so, one person can realistically pull of a decent Xonotic port all by himself without breaking his neck in the process. Maybe even now, if someone had some time and was overly productive and competent. You have to consider that working 6 hours with Quake C is probably about as productive than 15 minutes in Godot, to put it vulgarly. And there is a vast amount of things in Godot that ships out of the box or just takes 5 minutes, but realistically can't be done in QuakeC ever at all. Or only at the expense of 3 months of work, and huge drawbacks like 3x or 10x slowdowns. Then you got this huge amount of Godot devs and engine-empowered noob devs hopping on the train once it has gained some speed. Well, if by then we still do any manual work at all, and don't simply just dictate it all to ChatGPT....

If Xonotic doesn't go with the wind here, then very quickly we will have just *someone* creating a FOSS Quake Live clone, but with tons of modern features. Like matchmaking, physics, battle royale, new mechanics, open worlds, aimlab levels, voice chat, in-game level editor, maybe crafting, Android version, PS4 version, Steam version, and yadda yadda. Can't wait to see that happen. A little sad though if it is just like QL or Diabotical or whatever and not like Xonotic. And then everyone just plays this new game instead, Xonotic becoming like Rexuiz, kind of forgotten.

Needless to say: The future is now guys. This is it.

Some really great ideas will take off in no time.