Limiting factors in Xonotic development & solutions

Now that summer is over, I'm hoping to spend more time with my favorite FOSS games including Xonotic. I run latest GIT, and took the time to check what's new after a few months. As expected, I didn't find many noticeable changes or anything interesting happening. Once again, this made me ask myself "Why does everything seem so dead? Have most of the developers left or lost their free time, or is there no more motivation on the project?". I feel there are a lot of things that could be better and more numerous... many of them easy to do, others already in front of us but unnoticed.

Although I've made threads like this in the past, I wanted to post my observations and opinions in detail about the things I consider need fixing in development. I'm not trying to say what should be done, but what I believe the primary issues are and the solutions I can think of... please correct or clarify me where I'm wrong. I'm hoping that Xonotic might spring back to life and become even better, if a few changes in decision can be made.

1 - Has programming focused only on minor works?

Issue: I'm getting the impression that coding has drifted too much into minor fixes and tweaks, and away from major features and improvements. Looking at the GIT logs of xonotic-data.pk3dir on "master", most commits are things that barely affect the player. Many are code optimizations and cleanups without effect, changes to cvar defaults, or address auxiliary systems such as mutators accuracy and translations. I'm not saying those aren't important too, just that focus seems to have fallen mostly on the smaller things. It's been long since something in GIT caused anyone to say "Wow, what an awesome new addition, so cool Xonotic finally got / changed this".

Example: There are many palpable changes that could be considered. Ragdolls are one thing I've militated for, and that's one of the less important features. The only interesting thing being worked on that I'm aware of are Samual's new weapons.

Solution: I think more of the coding power and energy should be directed to working on bigger and more noticeable features and improvements too. Small fixes are important, but IMHO they risk becoming a sleeping pillow.

2 - Delayed acceptance of contributions:

Issue: Several contributors propose changes, but it takes way too long for them to be accepted or rejected. In many cases, new changes in "master" cause GIT conflicts, which the creator of the code has to rebase on during the waiting period. This causes patches to make it in much later, but also discourages developers who fear they'll work for nothing. I previously asked the devs about this, and some said there's not enough time to check each contribution while others said the bug tracker is too full and difficult to clean up.

Example: This is the main reason why I haven't made code changes in months. If I do, they will likely wait for ages, during which changes in "master" will create GIT conflicts that I must constantly resolve. I also don't know whether the code will be rejected. I don't know if it's just me, but I assume other people have felt this way too.

Solution: I think this is something that could be easily solved with better organization. The core devs know the code well, and it likely doesn't take much to test a patch and conclude if it works well and should be bug free. It could also help to have code and feature guidelines, so programmers know more easily if they'd work on something that would be rejected.

3 - Ignored contributions:

Issue: This is mostly an art problem... such as music, player models, weapon models, maps. There is a lot of good and license-compatible content that we can use, including art made specifically for Xonotic. But in many cases, new art was discussed briefly then forgotten. For maps it's worst: The Autobuild BSP page is full of great finished maps, yet Xonotic only has a handful of in master.

Example: Some might remember the UBot player model. It's a beautiful and detailed robot created long ago by Oblivion for Nexuiz. However, no one rigged it and included it in Xonotic, and it died right after the model was finished. It would likely take me just a few hours to rig, but I know it's probably going to be ignored so I didn't bother. Currently the model can be found on its OpenGameArt page. Several gun models were also posted, such as a new Crylink UZI and Camping Rifle... but no news after years.

Solution: Xonotic already lacks a reasonable number of artists (excluding mappers). For this reason, I believe we need to use everything we can, not let art die off when it's offered to us. I suggest making a list of all contributions (especially sounds, music and 3D models) and thoroughly discussing inclusion.

4 - Lack of artistic diversity:

Issue: Xonotic lacks something that makes other projects great: Diversity in style and themes. Usually this means maps, weapons, player models, and other forms of art. Xonotic revolves around a limited type of environments, with not enough difference in player races and styles.

Example: Almost every map is a facility of metal. Stormkeep was the only one to break this limit, but later it too was given metal floors and frames. Other projects like Unreal Tournament however have a diversity of environments: Outdoor maps, medieval castles (made mostly of stone and wood), cities, even greenhouses full of plants. Player styles are also very limited: You only have humans, one alien race (Gak), and one class that can partly call itself a robot (Erebus, more like a cyborg though). To address this, I attempted making an alien model called Draconi, and insisted on the UBot several times... but again nothing happened.

Solution: I don't believe Xonotic will get further if the artistic monotony can't be addressed. We already have enough metal texture packs, so I think it would be a good idea to include stone / wood / city / etc. textures and direct mappers to use them, which would be a great start toward covering more types of environments. I also believe we should invest in more player models, as different as possible from existing ones and each other.

End.

I'd like to know what you think and which of those things you agree on. Again, I'm not in the position to say what's good or bad... I'm just posting my observations on what I believe is limiting Xonotic from advancing and reaching its true potential. Only thing I'm sure about is that more could be done with little or no extra effort, and maybe lack of organizing is causing things to slip past us.

If possible, I would gladly help with what I can: I'm somewhat decent at modeling in Blender, although zero when it comes to texturing. At the beginning of the Xonotic project, me and FruitieX were assigned as map coordinators, although no one's contacted me ever since to ask me what I think about a map; If the devs trust me with that, I could at least include new maps myself after asking enough people.

Edit: Was replying to a comment that got removed.

Point 1: I think you should look at the git logs.

Personally I would be more in favor of a big part of dev time being spent on bug fixes and performance optimization, things you would call "unnoticeable" even though they are absolutely needed before we reach any sort of 1.0 milestone.

Points 2 and 3: I think those deserve to be addressed in some sort of official, "permanent" way (say, in the dev wiki). Otherwise potential contributors will end up giving up.

Point 4: I think the lack of transparency and communication are to blame there. As Samual stated recently, in terms of design the decision of the team is final. But at the same time there's no public statement or roadmap on this.

I relate with your frustration and I think it's a shame that Samual dismissed the post so blatantly, (I suppose) out of bias against you and the way you formulated your ideas.


EDIT: People, this is the development section. Address the topic seriously or ignore it.

I can't even.... what... what is wrong with you.... *sigh*...

I'm not even going to waste my time on this total nonsense. Please, get off the interwebs, you will do the world a favor.

Thats nice, isnt it?
Offending people is what you are best at, aren't tu?

I think the map statement in on point as 90% of the maps look the same, just a bunch of metal tunnels, hallways or floating spaceship platforms which are really only good for M+H or small team play. If you look at the map usage most servers that have players used old Nex or Q3 maps.

I relate with your frustration and I think it's a shame that Samual dismissed the post so blatantly, (I suppose) out of bias against you and the way you formulated your ideas.

I think his reply was to aa's first post. If he replied that to mine, it would be a very weird and irrational reaction, but I don't think it's the case. Your post isn't very constructive also, aa... regardless of who does wrong or not.

I'm not in resonance with Samual on a lot of things, but I don't consider him guilty for the development issues I listed. I'm only upset because he shoots down most of my ideas on the weapon system before I even attempt to code them. But I have nothing against him and much of what Xonotic has today is thanks to his contributions too. The issues I mentioned are likely things having died down and slipped on a less optimal path.

Just to be clear: The purpose of this thread isn't just to gather and talk about how bad things are. As in, I'm hoping we might find and apply some solutions. I know the developers care, and Xonotic isn't in a state where the devs abandoned the players and no longer give a damn. So the question is, what can and will everyone in the dev team do to help change this (myself included)?

I am very upset as well.

Had a chat about this on IRC. As it's been stated, a big part of the issue is lack of communication between developers and themselves + the community. I think another problem is that the hype Xonotic was born with (after the Illfonic incident) died down, and there might be fewer people who feel motivated to keep things going at full speed now.

I think an important factor is making sure every developer and contributor knows what to do, so they won't waste time on a contribution that won't get in (or that they'll be forced to maintain). Someone who feels their work might be in vain is instantly demotivated, which might be a possible cause for the decrease in development activity too.

So first of all, someone who wants to contribute should know exactly what is within the artistic style and list of acceptable features. After that, have the security that their code won't be forgotten somewhere in a merge request for months. It would also help if there were enough people to guide a contributor, who can see what the person did and tell him what he needs to improve in order for his work to be acceptable.

If a team checking and guiding contributions existed, being part of it is something I could do. But from what I'm being told, I don't understand the development and artistic direction all that well, so unfortunately I might not make a good candidate. Still, I think the idea is a good one, and very much could be solved through optimization and better organization, with little extra effort.

I agree that contributions should be reviewed and generally dealt with faster, as being ignored pisses off people that put efforts into what they want to contribute. I don't know how to address this, as dealing with contributions eats up human ressources that are probably not available.

As for improvements that are barely visible to the end user like code optimizations or cleanups I don't agree with MirceaKitsune. Having all sorts of "cool" features implemented in a hasty way will lead to an absolutely unmaintainable code base that will drive away potential developers that are not yet familiar with the code. You'll also end up breaking things if you base new "cool" features on badly implemented old "cool" features. Also, I strongly support the approach to implement things properly so the outcome is stable and efficient.

With regard to the lack of artistic diversity I see the point but it's part of having consistency in design, isn't it. And there will always be all sorts of maps beyond the official ones.

Points 2 and 3 are in the eyes of a player (in this case me) a MAJOR thing that needs to be taken care of. There was a ton of music made for this game that was quite good (SC0RP's Xonotic themes especially), excellent weapon models that put those in other games to shame (personal favorites being a shotgun intended to have rotating barrels, the new electro or lightning gun model, and I saw a redone version of the crylink in the works. There was also a really cool sniper rifle as well.) were in development and then for whatever reason development on them completely ceased and I fear we will never see any of that in game.


Speaking of models:
(look for anark10n's post, single most interesting shotgun I've seen in literally any game I've played)
http://forums.xonotic.org/showthread.php?tid=69&page=60

(theShadow was working on an interesting machinegun in this thread)
http://forums.xonotic.org/showthread.php?tid=69&page=36

(theShadow was also showing off a crylink and rocket launcher in this thread, though I'm pretty attached to the current RL )
http://forums.xonotic.org/showthread.php?tid=69&page=28

(someone going by sputnik posted a very interesting replacement for the electro or lightning gun)
http://forums.xonotic.org/showthread.php?tid=69&page=24

Those threads have some really good art shown off in them that sadly hasn't made it into the game. Judging by sputnik's last login, the likelihood of getting that lightning gun model in the game appears to be non-existent. Few resources or not, a move needs to be made to secure art when the opportunity to grab it arrives, otherwise it may vanish forever.

I agree that contributions should be reviewed and generally dealt with faster, as being ignored pisses off people that put efforts into what they want to contribute. I don't know how to address this, as dealing with contributions eats up human ressources that are probably not available.

As for improvements that are barely visible to the end user like code optimizations or cleanups I don't agree with MirceaKitsune. Having all sorts of "cool" features implemented in a hasty way will lead to an absolutely unmaintainable code base that will drive away potential developers that are not yet familiar with the code. You'll also end up breaking things if you base new "cool" features on badly implemented old "cool" features. Also, I strongly support the approach to implement things properly so the outcome is stable and efficient.

With regard to the lack of artistic diversity I see the point but it's part of having consistency in design, isn't it. And there will always be all sorts of maps beyond the official ones.

For the first thing, I don't imagine it would take a lot of extra resources. Like I said I'd be willing to do it, if other developers trusted me with decision making. Unless I got flood of features, I could set email notifications to any merge request, and be able to check the code and even test it locally, then mention if I found any issues and agree with the change. The rest is just issuing a GIT command to add the code to master.

Regarding the second thing, I can't disagree, even if I tend to act differently there. The reason I was probably never given commit access to master is that I'm eager to see things done quickly, and if a good feature arises I'm tempted to add it ASAP. Doing that would result in a buggy code, although on the other side I do believe things are happening too slowly. As for minor fixes, I agree they're important too like I said... only got the impression they've taken most of the focus for now.

Onto the third thing, I agree we wouldn't want a very diverse art style, as that would cause Xonotic to look like a lump of different things. However, keeping the art style consistent isn't the same as having only one type of theme and environment IMO. We can have both metal maps, outdoor maps, city maps, etc. with a consistent style, which is what I'm hoping for.

Points 2 and 3 are in the eyes of a player (in this case me) a MAJOR thing that needs to be taken care of. There was a ton of music made for this game that was quite good (SC0RP's Xonotic themes especially), excellent weapon models that put those in other games to shame (personal favorites being a shotgun intended to have rotating barrels, the new electro or lightning gun model, and I saw a redone version of the crylink in the works. There was also a really cool sniper rifle as well.) were in development and then for whatever reason development on them completely ceased and I fear we will never see any of that in game.

Those threads have some really good art shown off in them that sadly hasn't made it into the game. Judging by sputnik's last login, the likelihood of getting that lightning gun model in the game appears to be non-existent. Few resources or not, a move needs to be made to secure art when the opportunity to grab it arrives, otherwise it may vanish forever.

Yeah, that's the story I've been seeing too. Someone posts a good player / weapon / whatever model on the forum. People get excited about it being included. A few days later, discussion dies off. Months pass, the links to those models disappear and the artist is nowhere to be found. Later, someone revives the thread and asks if the contribution will still be added, only to receive the answer "the sources are gone and so is the author, it's dead". I do believe something should be done to prevent such harmful situations.

Though a bit offtopic here I'd like to point out that modelling and texturing (and in case playermodels, rigging and animating!) are totally different fields. If you look at those models you'll see that those are mostly untextured meshes. The model itself might be exceptionally good, however it's still only an unusable mesh if the modeller or anybody else can't texture it.

Though a bit offtopic here I'd like to point out that modelling and texturing (and in case playermodels, rigging and animating!) are totally different fields. If you look at those models you'll see that those are mostly untextured meshes. The model itself might be exceptionally good, however it's still only an unusable mesh if the modeller or anybody else can't texture it.

I think it's perfectly on-topic. That's a problem I believe I can relate to as well: I'm slightly decent at modeling today, but know nothing about texturing. Only solution is finding someone who can both model and texture, or be willing to texture other people's models. Issue is the dev team lacks artists, and unless more can be interested in the project it might remain a problem with little solution

For the first thing, I don't imagine it would take a lot of extra resources. Like I said I'd be willing to do it, if other developers trusted me with decision making. Unless I got flood of features, I could set email notifications to any merge request, and be able to check the code and even test it locally, then mention if I found any issues and agree with the change. The rest is just issuing a GIT command to add the code to master.

I disagree. Merge requests should be accepted after quality control, which not only includes testing of functionality, but also code efficiency and style. Much like Halogene says, it's in our best interest to reject unmaintainable code and ask for it to be fixed before considering merging.

I also think you don't get to commit to master because many other people don't (at the moment only four people have write permissions to master: divVerent, merlijn, -Z-, Samual and Antibody). If you get commit access without being part of the core team, then so should many other people, and we don't want that.

Regarding the second thing, I can't disagree, even if I tend to act differently there. The reason I was probably never given commit access to master is that I'm eager to see things done quickly, and if a good feature arises I'm tempted to add it ASAP. Doing that would result in a buggy code, although on the other side I do believe things are happening too slowly.

Well, part of the problem might be also that due to to very infrequent releases (wasn't that promised to get better?) and the easy accessibility of the autobuilds, most people (including the developers) probably use those as their main version for playing. So instead of it being the "unstable, work in progress and can break at any point" builds, they have to be pretty stable or hell brakes loose on IRC

Concerning the art-contributions... I have to say as a sort of potential art contributor (I have an almost ready set of player-models on my hard-drive and also dabbled with the weapons at some point) I also feel quite de-motivated to finish my stuff I made specifically for Xonotic. This has personal reasons (can't play Xonotic at all right now and for the foreseeable future due to bad geographic location), but also is a result of the perceived "meh, what ever" culture of the current player community.
I attribute this to the fact that most turn off all the effects anyways, go with one player-model and full bright skins etc. The last art contribution that was seriously welcomed here was probably the simply items...
Now this is probably only a reflection of the vocal minority (?) here in the forums, but at least for me it results in more motivation to contribute to another game or a mod or something like that...