Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
The fate of Xonotic development

#1
I couldn't help noticing something rather worrying during the last months, and am probably not the only one. I run Xonotic as well as Darkplaces from GIT, and regularly pull for new changes. Whereas an year ago there was about one GIT update per day, I'm currently seeing as little as one change per week / month... in both darkplaces and xonotic-data.pk3dir. In the Xonotic data repository, the last commit is actually one month old, and there's only 10 commits dating to this year! I don't think either Nexuiz or Xonotic ever dropped to such a low commit rate in their existence.

Is Xonotic development actually dying? I know that less activity on GIT doesn't necessarily mean that... but combined with the lack of any new major changes, less visible motivation, as well as occasional friction in the team, it gets one wondering. Whatever the case, it's still sad to see such a great project slowing down so horribly Sad

Anyone know what's really happening? Are developers leaving the project, no longer have free time due to real life issues, are no longer motivated to do anything new, or something else? Is there even still a chance of ever seeing Xonotic 1.0 at this rate?

In what regards my own opinion, this only strengthens my view that some sort of major change is needed, because something must have killed off the project's activity. Even if just an artistic or management change to further attract and motivate players and developers. More automation of issues and pull requests might be one thing that helps... in my case I stopped coding for Xonotic once my changes had to wait for years to get acceptance / rejection. Since I doubt any idea I come up with will be put in practice however, I don't think it would help much for me to poke my nose further into things... but I still believe some sort of change is very needed.
Reply

#2
I don't know anything about Xonotic development but as an old regular player who now comes once a year, there's something that I've never understood since Xonotic was born: why so little players? It seems like nobody wants this beautiful game to be known accross the web given the low activity we can see on the public servers. I read the post about Steam and I understand that the team doesn't want to publish an unfinished game, however I don't think a little bit more advertising would be bad. New gamers means new members and the more people are supporting a project, the more motivation the development team gets. A larger community can also bring more feedback and more developpers. That can sound simple but that's the way I see things. Every huge growing project such as Xonotic must have a big support community behind it to give everyone the motivation to go further.
Heart Heart
Reply

#3
You are right, development seems to have slowed down recently.
Since I'm not currently active on IRC, I have no idea about the reasons, though I'm not overly concerned either.

(05-06-2014, 08:44 AM)MirceaKitsune Wrote: In the Xonotic data repository, the last commit is actually one month old, and there's only 10 commits dating to this year! I

The reason you don't see any commits from me in data is because I'm building up the sourcefiles for the Luma theme in mediasource first.
In fact, over the past couple months, I have pushed almost 280 files already, with more to come.

Even if free time is sparse, I still am motivated to finish a first public version, and clean it up based on the feedback.
(I guess this post is my way of giving a life signal Big Grin )
Reply

#4
(05-06-2014, 11:24 AM)sev Wrote: Even if free time is sparse, I still am motivated to finish a first public version, and clean it up based on the feedback.
(I guess this post is my way of giving a life signal Big Grin )

Big Grin
Reply

#5
It's good to hear some positive news too. Thanks sev, and good luck with that! More or less jokingly however, I hope you won't also make a goodbye post before that happens... seeing how many people started doing that recently for various reasons Undecided

But to expand on my idea some more, an impression I'm getting at a first sight is that everyone in the community is drifting apart from each other, until no one feels like there's anything worth staying for any more. A good idea might be coming up with something new, grand and exciting. Like some special matches and contests, unique new features in the game code, etc. I guess I can see why for some people, Xonotic is getting to the point of "Ok, so now what?"

On the development side, I believe we really need a way to have developers be able to check contributions more easily, but without making it feel like it's an effort. Last time I complained about my pull requests waiting for months, I was told that the developers don't have time to take care of them or that they keep forgetting, due to real life issues or bad bug tracker. Maybe having the bug tracker send emails every week / month for pull requests with new changes would do the trick. After all, we don't have hundreds of contributors making dozens of pull requests each day, getting divVerent to have to sit in an office until 4am drinking coffee Tongue

Also, we could do something other projects have; Create an xonotic_next branch, containing all code being proposed but not yet verified. Pull requests from trusted people could automatically be added to it. Servers who don't mind the risk of buggy code would run it, and the bugs of many contributions could be tested and found at once before they make their way in master. When you have a dozen branches and someone always has to pull then compile then test each one, it's less motivating. Sadly, last time I proposed master_next branch, I remember that the devs didn't find it a good idea.
Reply

#6
(05-06-2014, 03:18 PM)MirceaKitsune Wrote: Also, we could do something other projects have; Create an xonotic_next branch, containing all code being proposed but not yet verified. Pull requests from trusted people could automatically be added to it. Servers who don't mind the risk of buggy code would run it, and the bugs of many contributions could be tested and found at once before they make their way in master. When you have a dozen branches and someone always has to pull then compile then test each one, it's less motivating. Sadly, last time I proposed master_next branch, I remember that the devs didn't find it a good idea.

That sounds to me like it would lower the quality standards and put even more pressure on the team to accept popular changes even if they don't fit the game's design...

In Nexuiz we had divVerent's test server which IIRC ran off a non-master branch and hosted some experimental changes. That was great, and quite popular for a while. Then heavily modded minsta ctf servers came and the frequentation of the testing CTF server dropped :|
Reply

#7
Just by the time I start some small changes in a big project to step in.

I can't say I'm extremely reliable because I tend to fluctuate back and forth between multiple projects but somehow I need Xonotic.

It has good graphics and sounds, original content, a welcoming community even if a bit small when going out of mistahook but still alive. There aren't much free (as in free speech) games of this quality. This is on of the few games I can speak about in gaming rooms without giving an image of the kind of "free games suck".

By the way, thanks for all your efforts and I hope to bring mines to the stack.
Reply

#8
I also want to see 1.0 Smile Xonotic rules

Until now i have only made some maps(2 atm, and contributed in 1 more) and plan to fix some others, maybe some contributions to code and models when i have time.

I try to contribute fun maps, the kind of maps that are great to play for newcomers and give the feeling that this is fun, more chaos than strategy, (the kind of maps duelers hate), also i know at least other 2 mappers that are actively mapping for xonotic.

Maybe not at master branch at the moment, but irc got a huge improvement in the last week, thanks to melano i think, invasion is quite playable too.

By the way, a little offtopic, can i have commit access? Smile http://dev.xonotic.org/issues/1899
[Image: 9074.png]
Reply

#9
(05-07-2014, 04:34 AM)Ari Wrote: By the way, a little offtopic, can i have commit access? Smile http://dev.xonotic.org/issues/1899

On behalf of the team, sorry about that. It wasn't noticed.

The issue has be reassigned and should be taken care of by divVerent tomorrow. And for your information: the string at the end of your key is actually part of it Smile
Reply

#10
I think the development should be moved over to GitHub, it's Facebook of open-source. Many potential contributors already have accounts there and know how to use it, so they won't have to learn Xonotic development infrastrucutre. LMMS moved to GitHub and went from stagnation to 1.0 in a short time.

To get more players, Xonotic devs should make sure that the game is fully playable with default settings (key bindings (assuming standard keyboard), mouse sensitivity (assuming 800 DPI mouse)), add a simple in-game tutorial (like one in Nexuiz), and make movement more intuitive (no strafejumping). If necessary, the game will have to be dumbed down. There's a reason why game companies dumb their games down. It's that, or oblivion.
Reply

#11
As someone who was kind of anti-github I have to say I agree. The reason I think people like to contribute to projects on github vs. just contribute to projects that use their self hosted repo and bug tracker is that on github you actually see that they have contributed (in their profiles, which people like to link just like their twitter accounts). This may sound silly, but I know friends who try to push code everyday just to have a full green bar in his github profile. This also have downsides of course, you often see trivial changes sent that may just be mere annoying, but I think the overall win outtakes that.

(05-11-2014, 09:11 AM)lamefun Wrote: To get more players, Xonotic devs should make sure that the game is fully playable with default settings (key bindings (assuming standard keyboard), mouse sensitivity (assuming 800 DPI mouse)), add a simple in-game tutorial (like one in Nexuiz), and make movement more intuitive (no strafejumping). If necessary, the game will have to be dumbed down. There's a reason why game companies dumb their games down. It's that, or oblivion.

Strafejumping does not practically exist in the movement, it's there but it adds so little speed no one even need to know about it.
Reply

#12
(05-11-2014, 09:11 AM)lamefun Wrote: To get more players, Xonotic devs should make sure that the game is fully playable with default settings (key bindings (assuming standard keyboard), mouse sensitivity (assuming 800 DPI mouse)), add a simple in-game tutorial (like one in Nexuiz), and make movement more intuitive (no strafejumping).

Default keyboard settings accomodate what new players expect from various other games (wasd movement, jump on space, numbers for weapons, "t" for "talk"). It's just how MANY other games are configured out of the box, regardless of whether that is particularly useful for the specific gameplay of Xonotic (which it is arguably not). But it helps new players to access Xonotic gameplay functions without having to study the binds, which is better than needing to read the entire input configuration and memorizing it lateron.

Mouse sensitivity is highly subjective anyway, some are wrist aimers and need a matchbox size of an area to make a 360 degree turn, while some arm aimers require a whole desk with preferrably nothing on it to do so (see http://forums.xonotic.org/showthread.php?tid=4289).

In-game tutorial is something that is being worked on, I agree that is one of the most urgent issues to attract and KEEP new players.

As for strafe jumping, what machine said.

I'm indifferent to GitHub.
My Xonstats Profile
Latest track on soundcloud: Farewell - to a better Place (piano improvisation)
New to Xonotic? Check out the Newbie Corner!

Reply

#13
(05-11-2014, 11:25 AM)machine! Wrote: As someone who was kind of anti-github I have to say I agree. The reason I think people like to contribute to projects on github vs. just contribute to projects that use their self hosted repo and bug tracker is that on github you actually see that they have contributed (in their profiles, which people like to link just like their twitter accounts). This may sound silly, but I know friends who try to push code everyday just to have a full green bar in his github profile. This also have downsides of course, you often see trivial changes sent that may just be mere annoying, but I think the overall win outtakes that.

Besides the fact that moving to GitHub would be a regression in terms of control and freedom (github is not free software), there is also the problem of size:
https://help.github.com/articles/what-is-my-disk-quota Wrote:For best performance, we recommend repositories be kept under 1GB each. This limit is easy to stay within if large files (typically, binaries) are kept out of the repository. If your repository exceeds 1GB, you might receive a polite email from support requesting that you reduce the size of the repository to bring it back down under 1GB.

If we're going "social", we might as well consider GitLab or Gitorious (self-hosted though, because of bandwidth and/or storage limits again).
Reply

#14
There's both pros and cons to moving on Github IMO;

The good side is that we would indeed get more attention, and contributing would be a lot easier. Minetest, my other favorite FOSS project next to Xonotic, uses it... and contributing / forking / etc is so easy it's not even funny! We could sure use that too... especially one particular feature called "pull requests" Big Grin Confused Sleepy

The bad side however is that the Xonotic developers would no longer be in control of the GIT server. Sure, Github is a nice place... but is it really better than hosting the repository yourself just to be on the safe side? And as the post above stated, size might be a problem... GH probably doesn't allow so many gigabytes of textures like we have.

The middle way? Create a Github repository, and setup a mirroring system between it and ours. If size is a problem, we could only use GH repos for the code and possibly maps, not textures and large art. I remember GIT is pretty flexible like that and should easily allow such a thing.

But if we could make use of Github's contribution mechanism, things would prolly be a lot better! I personally tend to support this idea.
Reply

#15
(05-11-2014, 02:43 PM)Halogene Wrote: Default keyboard settings accomodate what new players expect from various other games (wasd movement, jump on space, numbers for weapons, "t" for "talk"). It's just how MANY other games are configured out of the box, regardless of whether that is particularly useful for the specific gameplay of Xonotic (which it is arguably not). But it helps new players to access Xonotic gameplay functions without having to study the binds, which is better than needing to read the entire input configuration and memorizing it lateron.

Well, I have to agree there.

There's another thing I can suggest: split up all the mega-healths and mega-armors into smaller and quicker to respawn pickups, so that pro players who have learned to count seconds to armor can't just snatch them all up and win effortlessly. People come to shooters, well, to shoot things, not to count down seconds.

Also maybe give 50 armor at spawn time to make it harder to spawn kill.

(05-11-2014, 03:23 PM)Mr. Bougo Wrote: a regression in terms of control and freedom (github is not free software)

I'm surprised anyone still cares about that.
Reply

#16
(05-11-2014, 03:58 PM)lamefun Wrote: I'm surprised anyone still cares about that.

I greatly care about that, and (dare I say) so does most of the team.
asyyy^ | are you releated to chuck norris?
Reply

#17
Also reduce damage done by Strength or remove it entirely. Although the game does show how much time's left, pro players manage to take it just as it spawns while running, while new players have to stop by it and become easy targets. x3 damage is crazy and causes players to leave.

PS. It's x3 rather than x4, but I think it's still too big.
Reply

#18
(05-11-2014, 03:43 PM)MirceaKitsune Wrote: The middle way? Create a Github repository, and setup a mirroring system between it and ours. If size is a problem, we could only use GH repos for the code and possibly maps, not textures and large art. I remember GIT is pretty flexible like that and should easily allow such a thing.

That's not a middle way, but rather pretty much GH all the way. What purpose do you think the mirroring system would serve? If GH becomes an entry point for merge requests, then our current system will not coexist with that, as it will not be as accessible (as in permissions) as you want GH pull requests to be.

I would rather be in favor of self-hosting a more user-friendly and interactive frontend such as gitorious or gitlab as mentioned above. It does not have to be github, which we can't selfhost anyway since it's a proprietary platform. The alternatives don't have the popularity and user base of github (but I don't see you mentioning that explicitly as an argument for it anyway), but aside from that I think they offer pretty much the same features.
EDIT: nvm, lamefun seems to imply the advantage of moving to GH would be to benefit from its user base, while MK seems to suggest it's the features and user interface that are interesting.
Reply

#19
(05-11-2014, 05:35 PM)Mr. Bougo Wrote: lamefun seems to imply the advantage of moving to GH would be to benefit from its user base

I think it's a lower entry barrier, as contributors wouldn't have to make separate Xonotic developer accounts, and familiarity with the contribution process.

If the self-hosted frontent that Xonotic chooses offers a simmilar user interface and uses forum accounts (which most of the players who might become contributors probably have), I'd say it'll bring most of the benefits GitHub would bring.
Reply

#20
I would also agree with using a better and more user friendly GIT system from what we currently have too, yes. It doesn't necessarily have to be Github's systems.

If we're talking about Github's user base having an easier time contributing to Xonotic, I think that's considerable too. Even if we don't get a mirrored repository with them, we could for example make our system more accessible so merge requests from Github can be made. Dunno if that would serve much of a purpose, but perhaps some sort of integration with GH could slightly help.
Reply

#21
(05-11-2014, 09:11 AM)lamefun Wrote: I think the development should be moved over to GitHub, it's Facebook of open-source. Many potential contributors already have accounts there and know how to use it, so they won't have to learn Xonotic development infrastrucutre. LMMS moved to GitHub and went from stagnation to 1.0 in a short time.

To get more players, Xonotic devs should make sure that the game is fully playable with default settings (key bindings (assuming standard keyboard), mouse sensitivity (assuming 800 DPI mouse)), add a simple in-game tutorial (like one in Nexuiz), and make movement more intuitive (no strafejumping). If necessary, the game will have to be dumbed down. There's a reason why game companies dumb their games down. It's that, or oblivion.
This would require more effort to switch than it is worth by far, as well as it being a regression in quite many ways.

My answer: No.


As for the rest of the post, I have a forum post i'm planning later.
Do it yourself, or stop complaining.
Reply

#22
I'm not in favor of moving to a walled garden. Plus, the Xonotic development infrastructure can't be completely migrated to Github anyway. It's not like suddenly we'd see a huge influx of new contributions just by virtue of being on Github either.

So to sum this up: no.
asyyy^ | are you releated to chuck norris?
Reply

#23
I'm concerned about what happens to new players in Xonotic.
Follow here - I don't want to detour this thread.
I'm making Liblast - a FOSS online FPS game made with Godot 4 and a 100% open-source toolchain
Reply

#24
rocket jumping , and more so , rocket flying ,just like the old days ... , you people had it , in a popular state (im talking nexuiz times) , we had a very happy state , movement was top notch ,then the fork happened.... , was for good reasons i know.. ,but the tweeks didnt cater for all,no?
you guys did an excellent job making it to what is now , but i kinda feel the cool stuff got dropped when it should of been kept in place.
i think everyone should start from new and plan a new beginning for this game ,then promote it.
ive noticed that everyone was "all in" at the start , but after its dropped like all those other games that we struggle to remember...
you guys are the best and coolest ive ever known in this nerd net and i would love for us to go back in time and be once again , like old times, but we all know that will never happen.. , but we sure can start again like old mates and give this game one last chance to make it like it should be ( or was) (fucking illfonic and that dude that sold us out....)

who is still around anyway????????

divverent?
frutilex?
mr bougo?
doku?
[z]?????????????????
edong?
six?
hew?
turks?
my bro mintox?

chooksta??

hmmm....
t

Ill make tunes for this game if needed. , im busy irl , but ill make time.

t


:^
[Image: 227.png]
Reply

#25
(05-11-2014, 09:11 AM)lamefun Wrote: LMMS moved to GitHub and went from stagnation to 1.0 in a short time.

I actually was there, when that happened - IIRC, the LMMS team got a big dose of positive motivation, and decided to move to Github, because Sourceforge seemed to limit them in some regards, and they didn't like that Sourceforge might add additional adware content to Windows installers (Yahoo! search bar plugins and this kind of crap that you have to uncheck before you install).

Moving to Github was a decision made in the early stage of the new wave of rapid developement, to make it easier, but I wasn't the cause of LMMS getting the new energy. It was decided afterwards.

Unless my memory fails me Wink
I'm making Liblast - a FOSS online FPS game made with Godot 4 and a 100% open-source toolchain
Reply



Possibly Related Threads…
Thread Author Replies Views Last Post
  Xonotic vs Quake 3 development comparison LegendGuard 4 4,252 09-05-2023, 06:10 PM
Last Post: LegendGuard
  Samual's Personal Development Roadmap Samual 40 50,649 11-10-2021, 03:18 AM
Last Post: chooksta
  What was easy for you in development? (Darkplaces and QuakeC programming) LegendGuard 2 2,608 08-08-2020, 05:25 PM
Last Post: LegendGuard
  development and life cycle of a game community BuddyFriendGuy 9 10,728 04-04-2015, 01:58 AM
Last Post: BuddyFriendGuy
Exclamation Development Infrastructure Update divVerent 16 22,862 12-11-2014, 02:11 PM
Last Post: Mr. Bougo
  Xonotic Game Engine, Mapping, Development - General Developer Questions p14r 6 10,218 08-04-2014, 10:24 AM
Last Post: p14r
  q3map2 issues/development vulture 18 26,630 03-04-2014, 11:31 AM
Last Post: Garux
  Limiting factors in Xonotic development & solutions MirceaKitsune 15 14,461 09-12-2013, 03:08 PM
Last Post: poVoq
  Development tutorials Erusavion 7 9,357 05-28-2010, 12:08 AM
Last Post: FruitieX
  Feedback on latest development git Lee_Stricklin 12 12,829 05-05-2010, 04:30 AM
Last Post: divVerent

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-