[META] Xonotic reboot/port in modern engine

Please tell us shortly if you are interested in porting Xonotic to a modern Engine, what your skills are and how much time you could invest initially and on the long run.

I think we can all agree that there is no good strategy to go forward with this. The two options I see are:

1. Xonotic "Quantum" (stealing all the old assets, porting just the bare minimum code to get 1:1 gameplay, breaking all the mods and implementing only like 5% of the cvars)
   
2. QuakeC wrapper (or semi-atomatic converter) to transform at least some legacy code from portions of source code into modern code or at least run it as binary
   

Which engine? Godot 4 seems the only good choice to me.

What comes next? The new Xonotic will essentially evolve into Fortnite on the long run.

Also I think we should name the first 1:1 port "Yonotic". And when it becomes more like Fortnite, we name it "Zoonotic" and it will default to fully customizable furry player models.

About me: I have about 20 years of not so serious programming experience, worked as sysadmin mostly, worked some with Godot and QuakeC, could work a lot short term if something were to take off and maybe long term a bit also.

"port "Yonotic". And when it becomes more like Fortnite" no.

There is (was?) an effort underway to port it to Daemon. You should check in on the status of that. Matrix is probably the best place to do so.

I WANT FORTNOTIC! NAO!

There was already a thread from someone who thought to remake xon in godot. And I agree that this would be a really sweet solution. A ton of work for some years to come but would be worth it.
Theres already even .map support for godot: https://github.com/QodotPlugin/qodot-plugin

Well then only main things left to do is:
-movement
-weapons
-game modes
-ui
-server/client stuff

Imagine Gonotic being compatible with Xonotic online.

I don't mean to be the bearer of bad news, but there's simply a lack of manpower in the community to pull something like that off. Support for alternative engines such as Daemon and FTEQW has been rough at best - the latter of which is the closest example of a functioning alternative to DarkPlaces, the engine that powers Xonotic.
On the other hand, DarkPlaces itself has been receiving a lot of updates that Xonotic may hopefully benefit from someday. Supporting map formats is only a very small part of a functioning engine, and at this stage attempting to fork would mean sacrificing stability of the game and community, along with 15+ years of work going down the drain.  

Perhaps the contribution process does not appear as convenient as it could be, but focusing efforts on making Xonotic a complete and playable game before trying to split the community again with forks is certainly the wisest option at this stage, and I hope any capable people in the community would be more willing to aid in that process in the future.

I appreciate your perspective, but I think it is missing on some very crucial facts:

• QuakeC is like Cobol, hence there is no manpower. New devs never come, they only run away.
  
• Daemon and FTEQW are not modern and major game engines and they won't attract devs either. They are in essence just more muscled versions of Darkplaces. The benefits of switching are tiny, while the effort required to switch is enormous, much higher even than with modern solutions.
  
• Darkplaces is nothing alike a modern engine such as Unity or Godot. Compared to those, it is essentially just 1996 Quake 1 with some nice extras.
  

How is Xonotic not a complete and playable game? It runs well, it has all the game modes it can.

But yes, there is one big big problem with Xonotic: you can't implement any major modern features into it. This is because it runs QuakeC code on a legacy engine, which is extremely inefficient and also extremely limiting to the programmer - if you can even find one. Even if you had a team of 100 full-time employed QuakeC veteran experts, they will not be able to program any of the big features into it that make modern competitor games like Fortnite so much more attractive. It is simply impossible. The engine is the big problem. To make Xonotic more complete and playable, the engine needs to change.

What does switching do:

• it attracts devs who already have specialized in the engine
  
• it attracts code and asset contributors in general, because modern engines are very easy to work with just like other GUI programs such as Photoshop or Blender
  
• it future-proofs the game, i.e. it opens paths to evolve modern features such as in-game level builder or building/crafting systems
  
• it provides many benefits such as new graphical features and higher performance
  
• it gets rid of all the legacy issues and shortcomings
  
• instead of being a dead-end legacy code thing, the project suddenly becomes a prime target example for open source FPS gaming that a lot of people will want to expand and elaborate on in many different ways
  
• easily portable to all platforms, including browser
  

What does not switching do:

• the game can't evolve much. It is not future-proof, thus it will naturally die with time. Like Quake 1 or Pacman it remains what it is and will eventually not be played much at all anymore.
  
• old devs will be gone, no new devs come
  
• contributors become even more scarce
  
• marginal utility will diminish in legacy code maintenance
  

So how can you say that it will put +15 years of work down the drain? I think we all agree here, that we would want to preserve as much as possible from the current game. Of course with the Xonotic "Quantum" solution, it is a tradeoff. Firefox made the same tradeoff, and it was outrageous. But such decisions have to be made, if the software is to evolve and survive.

I think there is no doubt that if we can pull it off, then we should really do it. Unless you are some kind of Pacman purist person who does not care what time and world we live in.

The work is never lost. It is still there in the old code as a template to be converted. But if demand is too low for it, it can wait, maybe forever. Its a shame, but you know what would be an even bigger shame? Being a dying horse on a sinking boat.

I don't want to be demotivating or blame anyone. But as fast as technology and games evolve, we are already at that point in many ways.

I am not sure how much easier and more convenient game engines will become in 3 or 5 years down the road. For Godot there are already plugins to convert maps and assets that weren't there 3 years back. How much easier can it realistically get, without being outright dished QuakeC transpilators and 6503 GL wrappers by the engine? It is not hard to make a look-alike Xonotic game. But making it as good as Xonotic, copying all the game modes and fine details that's quite something.

I think it can be done with a few people being motivated.

We could start very basic, just XPM and DM with no options nothing.

If people see something playable that has a good future ahead then the ball gets rolling.

I understand the pain as a player to see modern games advancing while Xonotic appears to be left in the dust - I can assure you this is not because of the language it is written in or because Xonotic is "complete" (that could not be further from the truth).
The situation is far more complex than it appears and unfortunately I cannot share much, but the gist of it is that radical change does not gel well with an anti-change community. If contributors will only be motivated by an overhaul (such as what happened with Nexuiz) the project will never reach any form of maturity, instead we should be combining efforts to help Xonotic evolve - yes, it is perfectly capable of doing so, the strives made in DarkPlaces engine development lately are proof enough of that. Too many capable people have sat on the sidelines waiting for a handful of team members to keep the ball rolling, it's not sustainable or healthy for FOSS development to work like that.

On a more positive note, there are still a handful of people contributing to the game as it is, that will likely remain the case for the foreseeable future. I hope that is good enough reason for people to want to support the project as it continues to grow.

I would have appreciated if you had read my post and made sense of the points I raised.


I know there isn't really much to argue against. But just bumping the same counter-perspective atop, and just slightly expanding on it ... that feels pretty sad. And besides all that I have already said to that, I really don't have much to add to it ,and of course can't add to it, as it would be too misplaced in the continuity of the discussion.


To keep it shorter to read I can also put it oversimplified: you are arguing from the point of view of a Windows 3.11 project and you describe all the problems it would cause to switch to Windows 10 - without having ever used anything newer than Windows 98 - i.e. not knowing what it actually means. While there is no denying that those problems are real, of course in the light of the situation, those problems are only as meaningful as they have to be dealt with to do what is necessary, to make sane long-term choices. They are not meaningful in order to decide whether or not we should run Windows 3.11 yet another year or maybe indefinitely, when we could do better than that.

Of course if we really can't do better than that (and that's to be seen and why I made this thread), then this can be fine too. It is not a race, it is about developing and realizing the best solution available to us.

But you put it as if we could always run Windows 3.11, as if it is a good viable choice - and as if the considerate option to act sensibly in foresight is actually bad and harmful. While it is of course true that you can still run old Windows 3.11 programs up to this day, it is of course not a sane development strategy that would have a good future. And it creates all those totally deal-breaking issues that I have already elaborated on and that already became true years ago. Again I am not saying that we should abandon and boycott all Windows 3.11 programs. And of course some people would always want to develop or run Windows 3.11 everywhere, maybe even still in 50 years. However, making just a couple of sane assumptions for the wider game-developing community, and by extension gaming community: this Windows 3.11 thing is clearly not the right path.


If you think this is a crooked analogy, you haven't given it much thought. There are 25 something years between Id Tech 1 and Id Tech 7. Game engines are right next to operating systems in code size and complexity. That Darkplaces is still DOS-era-small speaks for itself ... it literally comes straight from the DOS era. That doesn't make it bad or not able to advance. It is just not in the same magnitude of things.


Anyway ... I would really appreciate if you read my previous post.


Pacman came out 1979. Some people still play pacman. It is still an awesome game. However, its not "the" shooter game that people were particularly eager to play in 2004. It was Doom 3. That's how 25 years of technology change everything. As far as FOSS shooters go, Xonotic is "the game".


Who here wants Xonotic to be and always stay to be some retro-relict like Pacman? Seriously, who thinks like this and then claims to speak in any way for the community? No one wants this, like literally no one but maybe people who have grown very old and tired. And I can say that with very high confidence. Xonotic is not EzQuake: an archival version of the original, meant to enhance some purist vintage gaming experience. Xonotic is the FOSS frontier of modern shooters.

And in light of all that, I don't see how there can be any doubt about the nature of this situation. Zoonotic is the next step in evolution.

I find it ironic that you would use Windows as an example here - the NT kernel powering Windows 10 is older than Quake 1, yet comparing Windows 10 to DOS is as ridiculous as claiming DarkPlaces is still a DOS era engine.
It is natural for solid foundations to be built up, not thrown away in favour of the next flavour. This applies to game engines as well; just look at Unreal Engine and the likes. These have existed for years, constantly being improved, not scrapped at every turn as that would be an incredible waste of developer hours. There is no reason why the same can't be said for DarkPlaces and FOSS development, but I digress; I am making the same point here.

If you can find a team to support you in the creation of a Xonotic 2, I can only wish you the best of luck. If you are expecting others to do it for you, then maybe the open source scene is not for you.

will someone move this to the troll cave already

Mario please just stop. You aim so far under the belt you are shooting in your own foot.

I don't want to sway anyone here with crooked sidelining arguments who neither know anything about modern engines, nor about the internal code of Xonotic. Because if you knew about both, you would see that such off rationale does not really follow.

My goal was to address people who are skilled enough to contribute to a port. So at least know about nowadays engines, albeit not about the very old ones.

I know that it is a bit discrediting to say that QuakeC is "is" legacy code and Darkplaces "is" just Quake 1 with extras. However that's just how it falls down in the wider big picture and we should be honest and brave enough to deal such hard truths on the table. It is not like Darkplaces has seen any sort of the development that transformed Id Tech 1 into Id Tech 3, it just hasn't. We are Id Tech 7 now. QuakeC is just like Cobol and that is such a hard indisputable fact. It is a dead long abandoned artifact from the very beginning of engine technology in the 90s that has extreme shortcomings and severely hinders performance. The nail couldn't be hit on the head any more centered than this.

The point of this thread is to gather people who have some time and skill to do a port. You are trolling it, albeit bringing in valid concerns you are trying to extinguish the very idea without playing fairly and you are disrespecting the discussion. Or at least that is what it looks like, because you are making such an effort to jump so far off track while ignoring much of anything that was brought into the room. Talking about "mysterious hidden circumstances", making even provably false assurances about QuakeC and then not explaining yourself in any of it if asked about it. Sorry if I actually misinterpret you, but this just doesn't sit right with me no matter how I try to turn it.


A word to anyone who knows nothing about engines:


Modern engines like Unity, Godot or Unreal are not a "fad" or "flavor", that is they are not just a slightly better thing than we already have. Nothing in the software industry has seen such extreme, rapid and monumental development as game engines. They are like space shuttles (Unreal Engine 5) versus horse buggies (Quake 1 / Darkplaces). You can nowadays make AAA games even without writing code, just in their GUIs, just like you use other GUI programs like Blender or Photoshop. This is because the engine handles almost anything and everything and nothing you need hasn't already been thought of before. It is like working in a fully automated factory with an army of intelligent robots that even wipe your ass. To a 90s programmer, it would totally appear to be magic. The power they have and benefits they bring is absolutely awesome and incredible. Once a game is ported to such a new engine, only minor changes are required to migrate it to the next and next version. Thus the game will enjoy all the benefits and improvements that any future version of the engine brings with it - forever to come. On a classic engine, you are forever stuck with whatever little it does and any new feature has to be coded laboriously by hand. This means writing hundreds and even thousands of lines of custom code to get just a single particular feature, for example ragdoll physics. In a modern engine, you can just enable it with a single mouse click, just like physics in general and so many other things that modern games have. The only problem is that there is no easy way to get any of the existing code into such a modern engine in the first place. This is because a modern engine functions entirely differently to an old engine. In an old engine, only certain low-level parts of the graphics, sound, input and network handling were done by the engine  and the rest was entirely done with the code of the game that you had to write yourself. In a modern engine, basically anything is just handled and done by the engine directly. The programmer doesn't really write much code anymore. They mostly only work assets into the engine, set options and connect everything together with scripts, which can also be done entirely visually (i.e. no code). With Darkplaces, the 2D menus for the main menu, options and such are for example entirely written in QuakeC by hand. Every line drawn, every rectangle, every button x, y, width, height, color, etc. had to be written out as text by a programmer in and as special programming functions. In a modern engine, they would simply be drawn point&click with a mouse, just like in Powerpoint or Inkscape inside the engine GUI. That is how most of the existing code cannot really be reused, but on the other hand a modern engine makes it so much easier to get to the same result, taking existing things as a template, and you don't even have to be an expert in anything to do it. You don't even need a lot of the old code in the first place because it deals with features which are already standard in a modern engine and can be implemented without any coding, or almost no coding at all. Because so much less code is required, it also reduces bugs and speeds up development by a lot. But still quite a lot of things from the old code base have to be transferred somehow. The benefits are very profound and plentiful. This is only to give you a very basic idea.


Long story short: don't compare a space shuttle to a donkey. There are some very critical reasons why people want to switch to space shuttles for transportation, that I find very ridiculous and even rude to be compelled to explaining here in detail. Since this thread is addressed at people who should know about all this already, or at least who can give realistic thought to such possibilities.

And in light of all that, I don't see how there can be any doubt about the nature of this situation. Zoonotic is the next step in evolution.

...

You are trolling it, trying to extinguish the very idea without playing fairly in the discussion.

I start to get confused. Who is now trolling whom? I get the feeling this thread is starting to become a troll party... maybe the party should take place in the cave.

* Halogene gets out some popcorn

I just made a joke with Zoonotic, because people are afraid of change and such a big change is understandably really intimidating. And it is even offensive in some ways.


But like I said, we have to be honest and true here. Make healthy and well-thought long-term choices. Even if that's bumping a lot of people out of their comfort zones.


It is a hard topic. I'm not some Jesus here, who muscles this all alone out of one bread and one fish in a day. I just feel it needs to be put on the table and discussed openly. And of course I am motivated and would like to play a major part in pulling this off if we have enough people.


I believe even with just a small team of 2-3 people it is very doable. 3 years ago it would have been much harder, and now is the right time to do it. Like I said, what else can we realistically expect to be added to the engines, that would make the switch easier? It is already so mind-blowingly easy. I hope other people proficient in Godot or other modern engines can give some input on this.

Well then only main things left to do is:
-movement
-weapons
-game modes
-ui
-server/client stuff

Imagine Gonotic being compatible with Xonotic online.

I don't think network compatibility is feasible or desirable. I am unfortunately not very versed in network coding in Godot. I suspect that is the only part of the port where you really have to do some classic "hardcore" coding. Especially if you aim at an exact 1:1 look and feel copy of it, with how the antilag stuff works and all that. Like I said anything else is pretty much just some minor boilerplate code and "major" GUI work: weapons, ui, player models, maps + hammering it in and roughing out the edges. Movement code just has to be copied 1:1, so that is just dumb transfer + fiddle-it-in work like so much other stuff if not most stuff is. Game modes ... are not so easily transcribed and in my mind they complicate things which isn't good to start with. I really think we should start with just DM and maybe XPM and get game modes going later on. Like all the cvars also ... this is really some devil in the details, as there are so many cvars from like 20 years of development. Maybe we should even put in some of the really impressive new features first, before we implement game modes or even options in the menu. For example adding physics takes virtually no effort, like being able to carry and throw barrels or boxes. but it adds a whole lot more to the game than being able to e.g. specify that the weapon should be drawn left-handed - although it  is on par in difficulty to implement. I think we should get the bare minimum going to make it look and feel exactly like Xonotic to play, and then demo some of the cool new stuff to show off. But it should really just be a demo at that point, to get people aboard. Everything else comes later.


But yeah, in a modern engine it is for the most part just working the assets into the engine and *BAM* there is the finished product with almost no coding. Everything else is just details and details and more details. Details that make Xonotic into Xonotic, what makes Xonotic great. We should preserve everything we can. No one wants just some look-alike ripoff that handles totally differently. You could do that on the weekend even alone but it would be garbage.

Also one very critical factor here is how the Xonotic dev team reacts to this endeavor. It is not unusual for team leaders to suppress, censor, undermine, legally attack, categorically reject or otherwise sabotage such extreme efforts and desires of their communities, because it threatens them in their established positions and privileges of fame and power, which they  worked very hard for to get.


As I don't really know the team very well, it remains to be seen how a dialogue would develop and how much they resonate with reason that can be established through a continuous discussion of the needs and interests of wider communities and apparently also technological plausibilities. Rather than just that which can be said defensively in favor of the established rule.

I have a good feeling though about Xonotic. I think they are honest people and if they honestly can't follow the rationale then I believe they will just as honestly reject the idea with an open mind. That is without doing anything crooked, ignorant or ill-natured to get rid of it. You can never be sure though, such things turn out either this way or that way. With the forums, Discord and Github being the only public places for the community to discuss and assemble anything, those public places are of course technically still full-blown dictatorships where power can be abused almost arbitrarily, and pure fiction can be turned into reality. One always needs to be wary of those things.

It is a hard topic. I'm not some Jesus here, who muscles this all alone out of one bread and one fish in a day. I just feel it needs to be put on the table and discussed openly. And of course I am motivated and would like to play a major part in pulling this off if we have enough people.

This immediately contradicts yourself:

I believe even with just a small team of 2-3 people it is very doable. 3 years ago it would have been much harder, and now is the right time to do it. Like I said, what else can we realistically expect to be added to the engines, that would make the switch easier? It is already so mind-blowingly easy. I hope other people proficient in Godot or other modern engines can give some input on this.
[…]
I don't think network compatibility is feasible or desirable. I am unfortunately not very versed in network coding in Godot. I suspect that is the only part of the port where you really have to do some classic "hardcore" coding. Especially if you aim at an exact 1:1 look and feel copy of it, with how the antilag stuff works and all that. Like I said anything else is pretty much just some minor boilerplate code and "major" GUI work: weapons, ui, player models, maps + hammering it in and roughing out the edges. Movement code just has to be copied 1:1, so that is just dumb transfer + fiddle-it-in work like so much other stuff if not most stuff is. Game modes ... are not so easily transcribed and in my mind they complicate things which isn't good to start with. I really think we should start with just DM and maybe XPM and get game modes going later on. Like all the cvars also ... this is really some devil in the details, as there are so many cvars from like 20 years of development. Maybe we should even put in some of the really impressive new features first, before we implement game modes or even options in the menu. For example adding physics takes virtually no effort, like being able to carry and throw barrels or boxes. but it adds a whole lot more to the game than being able to e.g. specify that the weapon should be drawn left-handed - although it  is on par in difficulty to implement. I think we should get the bare minimum going to make it look and feel exactly like Xonotic to play, and then demo some of the cool new stuff to show off. But it should really just be a demo at that point, to get people aboard. Everything else comes later.

So do you think it's easy and only needs a few people who throw a few assets together or do you think it takes time? I feel that either you are trolling or have not thought about what has to be done at all.

But yeah, in a modern engine it is for the most part just working the assets into the engine and *BAM* there is the finished product with almost no coding. Everything else is just details and details and more details. Details that make Xonotic into Xonotic, what makes Xonotic great. We should preserve everything we can. No one wants just some look-alike ripoff that handles totally differently. You could do that on the weekend even alone but it would be garbage.

If a modern engine makes everything so easy, gather those who said the same thing before and do it. But my guess is that before you manage to create something that somewhat resembles Xonotic's current state, the nowadays modern game engines will be out of date. And at that point, either you yourself or someone in the community will push for a rewrite in whatever is modern then.

Many people praise modern game engines as if they're magic. They're not. Sure, they can speed up development, but only if it's the right tool for the job. Otherwise they will slow you down when you have to fight the engine.

Tl;dr: If you're really serious about it, show it: Analyse the currently available game engines. Which are fit for this? Which features have priority? Which features can not be ported? Plan how many devs are needed and how long it will take. Then at least tripple the time as you will underestimate the effort for sure. You need to do at least that before current devs will take you seriously.

example: martin t's qc2rust project coming "next summer". btw that was over a year ago.

@Freddy:

I don't see how it is confusing to you that certain things are very easy and can be done quickly, while other things take time and are maybe not even of priority. It is not like I am contradicting myself. I am simply talking about different aspects and stages of development. I am not sure where you lost track ... maybe it is too hard to follow if you have no experience in a modern engine? I suggest you watch some videos about Unity or Godot to get a better idea. The implementation we can do now for a modern engine will never get out of date. Although there are version changes and migrations that require a certain amount of work that is annoying but not really that substantial and nothing alike the things you needed to do 10-20 years ago. I have already said that. Just don't fight the engine it is dumb. Xonotic is a simple classic shooter. The only "huge" shortcoming we will ever run into is probably that there is no sandboxing for mods in Godot. So we have to work around this, e.g. by using a central trusted server with approved files to load game code. Until sandboxing will be available in Godot 5 or 6. That's the good thing about modern engines: features write themselves if you just wait a while. If you are in a hurry write it yourself and make a PR to Godot.


@Any people here who do not have any idea about engines, software development or whatever it is, I will try to put it more simple:


To make a viable port of Xonotic, we need a few very skilled and dedicated people in the beginning who work the most important things of Xonotic into the new engine. This is only to build a solid foundation. Then other people can come in later from the outside or the old team and can work even more things into it. Those people who come in later are not required to have a lot of skill and the work they do is almost always very easy. Because the engine makes it very easy for people to contribute things to the game. But the people who do the initial work have to do quite a lot in the beginning. The work they do is also very easy for the most part, and it can also even be done without any expertise, because the engine makes it so easy. But even though most of the work they do is easy, only in the beginning there is also a very special portion of work that is very difficult and requires a lot of skill and knowledge of both the new engine and the old engine's game code. This is why not everyone is qualified to do this initial work, and why it is so important to have a team of people with skills from both the old engine and the new engine who can make a good start for everyone else. When those skilled people have finished their work in the beginning, they can show the new game to other people. And it will already be fun to play and very good. So that other people can judge for themselves if they like the work that has been done and what they can do in the future. But this new game will not be complete in the very beginning, there will be things missing. Probably even some things that you like a lot and that you would not want to live without. This is why it will not be good enough for everyone to play at this point in time. No one will say that people should now play this new Xonotic, rather than the old one. People will still say that the old Xonotic should be played for quite a while until the new Xonotic is ready. The point of making such a game in the beginning is not so that it is instantly better than the old Xonotic. It is so that other people have proof of the things that can be done and how they have been done, so that they do know how they can also do things. This is how the game will be much better than the old Xonotic, much much faster than if just a few people try really hard in secret to make good. How does this new Xonotic game look like in the beginning? Yes, you will be able to play it and it will already look like the old Xonotic and it will also feel like the old Xonotic. For example the player moves the same way as in the old Xonotic and you will also have the same weapons and the weapons will shoot exactly the same way. Very small things might be different at first, that do not really change how the game plays. Like the smoke from the rockets or the lava on the floor might look a bit odd. But this will of course be changed later to look more impressive like many other things. You will also be able to play the old maps that you like, for example Finalrage. And it will be very easy to make all the other maps work with the new Xonotic. It is not like anyone has to make new maps. They just need to press a few buttons to make them work in the new engine. But even though so many things work and are like the old Xonotic, you will probably not be able to play the game mode Key Hunt or Nexball. Maybe you will only be able to play Deathmatch in the beginning. Also there will not be a lot of options in the beginning, only the options that most people really need. Like mouse sensitivity or customizing keyboard keys. Besides the options that you see in the graphical settings, there are also hundreds of options that you have probably never even heard of. Those options are called console variables. Of those options, probably very very few will be available in the beginning. For example, you will not be able to set the console variable bot_ai_aimskill_order_filter_1st or menu_slist_categories_CAT_DEFRAG_override. It is very likely that those options will never be available in the new Xonotic, even not after many many years. This is because people do never use them and it takes time and effort to program them into the new Xonotic that is much better spend elsewhere, for example for new fun things in the game like robots or swords. Over time, more and more things will be added to the new Xonotic: entirely new things and of course also old things that are still missing. Even if very few people help to make the new Xonotic, the game will be fun regardless and you will see that nothing really important will be missing after just a short while. Because the difficult part is not to add things later. It is only the work that the people have to do in the beginning, who are required to have skills from both the old and the new engine, when they are all alone and others cannot yet help them. And if they do this work and others can see it, and that for what they have done they have done it well, then the new Xonotic will be a success. A lot of people will come in from the outside, people that you have never seen in Xonotic before. Those are people who are making many other games with the same engine. And they will be really impressed by what we have done with it and that we share our work with them for free and don't keep it a big secret. They will already know how to easily change things from experience with other games in this new engine, and they will have many ideas about what they can and want to do to improve the new Xonotic and even make entirely new games from it. In the new Xonotic, there will be more and more options and things added, new and old, so that almost everyone will be happy about the new Xonotic. This is the point where the new Xonotic will replace the old Xonotic, and the developers will actually say that the new Xonotic should be just as good and better as the old Xonotic. And so anyone can try the new Xonotic, not just because they are curious about it or because they want to help to make it better. But to actually play it and judge whether or not they like it more than the old one and if it is really just as good and better than before. But even though at this point so much has been done to make it really good and better than the old Xonotic, still some people will be unhappy. This will be mostly because they use options that no one else uses. For example they might feel that the game is not playable without setting the console variable r_shadows_shadowmapscale to a different value. You might not even see what difference it makes, even if you set this value yourself. But they will think that it is very important and they will tell you a lot about this. And another person might feel the same about the variable g_physics_warsow_accelerate. This is where the only real problem is with the new Xonotic: It only makes sense to do so much work as to make most people happy. But it does not make sense to make absolutely everyone happy. Because this work on very tiny details that only very very few people even use is better spent elsewhere. So even though the new Xonotic will be better than before, and there will be many more people to help and many more new players, because the new Xonotic will be able to do so many new awesome things. There will also be some people who still like the old Xonotic more and they will complain about the new Xonotic.



But as you have heard in this thread, the old Xonotic also has problems. For example to make the old Xonotic better, the Xonotic developers have to do all the work themselves all the time and no one else can do the work for them. The work doesn't do itself. They are all alone with their game and no one can really help them from the outside if they are making other games instead where they are making things better all the time. It has been like that for a very very long time, 15 years or so. This is why some modern game engines were developed to work differently. In some modern game engines, everyone is helping each other by improving the code of the engine. And everyone is using the same engine for their game, so everyone is profiting from the improvements no matter what games they make. Now with modern engines, people who make games are not alone anymore with just their game. They all help each other and they learn from each other and can takes pieces of one game and use it in the other without problems, no matter what game they work on. So you don't even have to do most of the work in your own game, the work has already been done for you by others! With old engines, it was often very difficult to get the game working with a new engine. So difficult that it often wasn't even worth trying. This is why we have this problem now that Xonotic still uses an engine that is 25 years old and just has been made a little bit better over time by very few people for mostly only Xonotic and very old games that no one really plays anymore. But with the new engines, this is no longer really so. It still takes some work to get from one version to the next in a new engine, but it is very very little work by comparison. This is because engines do not change as much anymore as they did in the very beginning where they changed in very radical new ways to do more and more things. Today engines mostly only add new features and functions, that people need to make work easier or to make things look more impressive.  And the people who make the engines do not want the people who make the games to have problems with their new engines. They make their engines so that it is very easy to use them. Making the engine easy to use for the people who make the games is the very goal of the game engine. And the game engines are getting better and better at this all the time. They are so easy now to use like a program to edit images or movies. Everyone can use them without having to read books about it or be much of an expert. So in a new engine, we never will have this problem again that we are all alone and no one can help us. And that we have to do this big work to get the old Xonotic into a new engine. This will never happen again.


@Freddy:


As to a detailed game plan: this is largely all just wish-wash. What matters is that we just have at least one more guy if not two to pull this off. And if we have that, then it just matters to get into one wavelength with them and just put in the hours. I only know Godot. I think Godot is the way to go and I have no issues seeing how. But if now 3 Unity guys show up ... then maybe it is Unity instead. It doesn't make sense to me to work out any more details about this without even having people to work with. If you have never used Godot or another modern engine before then to do the initial work it would take you a lot of time to learn about the engine first ... probably way too much time. This only makes sense if you wanted to get into modern game dev anyway and we are talking month if not a year down the road. It wouldn't be that hard to get into it in hindsight though, if you come from the current dev team and the initial port has already been done by the small team. If you already know the old code, then it will probably all fall into your lap how it works in the new engine and then you have little or no issues working with it from that point on. Especially not if it concerns bringing old features in or fixing things that are off.

Otherwise I have explained a lot of details now as best as I could and in excess to people who really are not in the picture and have asked odd questions or said odd things because they do not understand the situation or the process. You are asking for some sort of proof of concept from that perspective. I don't think that makes any sense whatsoever. Either you understand modern game development, or you are interested in modern game development and willing to learn or you are not. There is really nothing I can say that can bootstrap you out of this position, so that you have some sort of assurances of what I have already talked about and tried to describe here with many great explanations, without yourself doing anything substantial by yourself while not trusting in anything I say. That's just not possible.

example: martin t's qc2rust project coming "next summer". btw that was over a year ago.

Yeah, a lot of really important things are also really difficult and at risk of failing due to labor shortage.

But it is not like you shouldn't even try because of that. The opposite is true: they really should be tried and supported even harder.

With QuakeC stuff, the issue is obviously that it is all legacy work. Too few people can do it, it is too low level. And no one ever gets into it just like Cobol because it is so extremely outdated. Then you have a QuakeRust ... but it is still stuck deeply in all the other 25 year old tech. It is still such a dead end generally speaking, even thought it would help a lot to get out of a totally hopeless situation, in a certain sense. I don't know ... this transpilation thing doesn't seem very realistic to me. Maybe feasible for someone really smart, disciplined and on some decent payroll.

Xonotic "Quantum" on the other hand is a safe bet and also the easiest, most promising and powerful one.

Even a lot of girls work with Godot. We could open a female dev section in Xonotic ;-P .

There have been a lot of developers who come into this scene that are comfortable with their own tools and wish to force them upon everyone else to make development more convenient for themselves. Martin was one, you are another, it promotes a very toxic environment that undermines the efforts of those who are still actively developing the game.
If you wish to be taken seriously, do as Freddy has suggested and lay out a plan, don't just attack anyone who responds here with a differing view to your own.

Mario the only person I have attacked here is you, for what I strongly perceived to be foul play, as I have demonstrated very clearly with very solid arguments and evidence that you have not defended yourself against so far in any way whatsoever. I would be happy to see you do, so that anyone who has read through the entirety of this thread can understand how you are actually to be understood differently than that.

I brought up this topic, because it addresses a very grave, problematic long-term situation that can be rescued and vastly improved in a way that I do understand and that anyone else can follow the rationale of to understand as well and do a cost/benefit analysis on. Both about the nature of the problem, as well as the available solutions.


I suggest a tool I am somewhat proficient in, not only because I am willing to burden myself with the initial and very substantial amount of work that it takes to bootstrap a solution out of nothing. But also because it happens to be the most fitting tool for the situation, i.e. FOSS development. Then I even suggested a different tool as an alternative that I have no experience in and that I even dislike, if it only happens to be so that whoever comes in to help will rather be able to work with that tool instead.

You then somehow try to contort this into me creating toxic environments by making things more convenient for myself and undermining the development efforts of the game? I mean it couldn't be any more backwards than this. Yet another very blunt display how you are seemingly only interested in sabotage and foul play here. I wish it wouldn't look like this, and I am really hoping for a response from you. Instead of yet another hit to the knee, and yet another insult, when I have already excused myself over and over for having to cross your side of the pave walk, in an attempt to do community work on the other side of the street that possibly will ruin the nice idyllic view from your house with a bigger and better building for everyone ... or something along those lines of metaphor.

Look I get that you probably have contributed a lot to Xonotic and now this switch would at first kill most of it and you don't see it coming back any time soon. So I guess any solution no matter how many problems it fixes and how awesome it is for everyone else forever to come - it still makes you angry especially coming from someone who has done very little so far to prove themselves.

But to me I am mature enough to say that such decisions and options are not a matter of fame or positions of power or rhetorics or nostalgia. They are a matter of pure reason. And whatever is reasonable and whatever has been reasoned to be the case no matter who said it first and even why, as long as it makes the most sense and nothing else can be established that would be any more sensible then that, it is then plainly said just the most reasonable thing and it should be given due attention. 

This is not to say that it should gain me any trust or faith in whatever I claim to be able to contribute here. But only that we can reach a common understanding about the situation and the possibilities available to us. Or at least if not even trusting each other in the experiences we share, then at least to not fall back into plain denial or ignorance about the facts and possible opportunities raised from sharing the critical insights gained through those experiences. That would be really sad. And it certainly doesn't create toxic environments, quite the contrary it defeats them.

Release to be expected in 2021?

The innate hostility and indigestable walls of text make this an unhealthy thread to garner constructive responses. I suggest you start your project and then recruit people, as the intention of this thread appears to be quite argumentative in nature and people will be less inclined to support that.

Release to be expected in 2021?

If by "release" you mean "initial prototype" for development purposes only ... I am not excluding that it is possible, if we had 3 guys right now and everyone was really trying to work at least sometimes on the weekends and we of course triple the time to any deadline like Freddy suggested.

But I know this kind of work ... it always is like all attempts of sane project management fail, and then it suddenly gets magically completed by totally remote chances and mostly only  one person or no one will get anywhere at all. This is why it is so important to have multiple guys. It is like throwing a dice once per term to get a six. If you can throw three times in a row, chances are almost 50:50 to succeed at first try.


On the other side, Godot 4 is not even released yet. And if it is Godot then everyone has just to be waiting for the release spring next year or so to not cause unnecessary migrations.

But I could already do some legwork and testing. Plus a lot of things like scripts can be developed now just in principle or maybe even without any issues, with the unstable Godot 4 git version. Maybe it is even better now then later as I have gathered that it isn't really that unstable anymore and sort of in alpha stage already.

And if you are into Godot or have been thinking about learning it, even if just very crudely, then please introduce yourself say something this is the chance to do something big or small. Whatever it is, it is good to have at least some people to hop on board straight away.

The innate hostility and indigestable walls of text make this an unhealthy thread to garner constructive responses. I suggest you start your project and then recruit people, as the intention of this thread appears to be quite argumentative in nature and people will be less inclined to support that.

Ok I see how lots of text is off-putting. But like I said the very key is just to gather if there are even qualified people to begin with and what they are qualified in.

Just starting such project without any feedback or discussion in the community seems to be very unwise. Also eventually I would like to get opinions how this resonates with all the long-established devs if the idea really took off to be viable and successful.

I am glad I have explained a lot, even if that was in the end just to about anyone I could think of.

And I am of course open to any new arguments and insights or alternatives.