what is teeworlds-community

[ChillerDragon]

why and what

The development at https://github.com/teeworlds/teeworlds slowed down over the years and now basically came to a hold.
The prs are piling up and contributors are moving to other projects such as ddnet.

So I decided to create teeworlds-community/teeworlds. Which is a fork of teeworlds with all the pull requests being mirrored over. So if someone opens a pull request on the official teeworlds repo it can be merged here (the teeworlds community repo).

goals

Stay as close to the official project as possible. Only quality of life pull requests that have no gameplay impact should be merged. The idea is to have a fork of teeworlds that can be used as a drop in replacement but has a passing CI and no deprecation warnings. Ideally at some point the official repository will have active maintainers again and then this community project can be shut down.

how and who

This github repository has a merge queue and requires 3 approvals of maintainers with write access to merge a pull request.

I will be handing out maintainer access to everyone who wants it. With the exception of people I know to be bad actors or accounts I have too little information on.

we need you

If you want to help auditing pull requests let me know and I will give you merge powers. Write a comment under this issue. Or create a new issue to ask for maintainer access. Alternatively you can also find me on the ddnet discord in the #developer channel or in the teeworlds discord in the bridge channel.

[Bamcane]

I would like to help new features of the server part of the project

(Hope this project could get more and more community helps)

[ST-Chara]

I'm quite intrigued in this, despite my uncertainty about how I can, but I want involvement
It is necessary for the wheels of teeworlds to keep rotating

[ChillerDragon]

@ST-Chara I gave you write access so you can approve pull requests

Go to the list of pull requests and pick one that interests you

If 3 people with access approved a pr it can be merged by someone with access. This way everything is ideally carefully checked by at least 4 people.

[Kaffeine]

@ChillerDragon you're quite generous but I'd suggest to reasonably limit the approvers invitation. I mean that normally you 'd want to look at the code/commits and contribution of a candidate instead of going wild.

[0xfaulty]

@ChillerDragon I understand that we could review and merge (or rewrite and merge) all 48 pool requests (maybe except with water and ice features as it change gameplay) we have at the moment, but what to do next? Does it really make sense to write new features based on vanilla Teeworlds? It seems like it would be easier to cut 0.6 support and ddrace features out of DDnet (Why I comparing with DDNet? Because it already has all the graphics driver and controller improvements on the client side and refactoring and optimisations on the server side) and rename it to Teeworlds than it would be to write Teeworlds to be usable as DDnet. Besides, if we don't add anything gameplay-changing, what motivation will new developers have to join the project? Why should they be interested in supporting it if they can't add content to the game? If the goal in fact will be only closing pool requests without further development then such a goal is clear to me, let me know if this is the case.

P.S. By "be usable as DDnet" I mean that player with Teeworlds client could play on DDNet servers (or any other modifications) not less convenient than on DM and CTF servers.

[ChillerDragon]

@ChillerDragon you're quite generous but I'd suggest to reasonably limit the approvers invitation. I mean that normally you 'd want to look at the code/commits and contribution of a candidate instead of going wild.

Yes normally I would agree. I also prefer dictator ship in open source. How it is done in teeworlds and ddnet. With a hand full of people who know what they are doing and they are calling all the shots.

But we do not have that luxury here. There is nobody who wants to maintain teeworlds. Thats why the development slowed down and no competing project appeared yet. All maintainers are at ddnet and want to stay there. So there is no hand full of selected maintainers that would want the job.

So I started this experimental project. Trying to achieve activity by mass. And trying to achieve quality by requiring 3 approvals per pr.

If the project goes out of hand and we have a bunch of trash commits on the main branch then we can think about reducing maintainers or increasing needed approvals. But for now I want to ensure something is happening here. The idea of giving everyone a vote sounds crazy I know. But also kinda cute don't you think?

[ChillerDragon]

Does it really make sense to write new features based on vanilla Teeworlds?

Not in this project no. It should just serve as a base for developers. But if you are asking if developers even should use teeworlds instead of ddnet as base for their mods then my answer is yes. The ddnet project is big. Full of features that pvp based mods do not need. The compile times are way longer at ddnet. There are more dependencies required to get a working build. For example rust and curl. Also ddnet as of right now is not too mod friendly and is not officially supporting pvp gameplay ddnet/ddnet#7777. If one wants quickly hack together a simple 0.7 mod like ICTF or bomb. Then teeworlds is a more fun code base to work with than ddnet.

Besides, if we don't add anything gameplay-changing, what motivation will new developers have to join the project? Why should they be interested in supporting it if they can't add content to the game?

You add the features in your fork/mod. So when while developing your mod you realize that there are some deprecation warnings coming from for example one of the external libraries. Then you can check if someone proposed a fix for that in teeworlds-community and up vote it. If there is none yet you can propose one your self and get a free audit on your changes. And then that problem is solved for all your future mods that you can base on this code.

If the goal in fact will be only closing pool requests without further development then such a goal is clear to me, let me know if this is the case.

Yea closing prs is the primary goal. Further development should only include fixes. Nothing too intrusive that touches gameplay or breaks network protocol.

If there is a big demand for new features and the whole community thing works we could think about a feature branch but that seems a bit complex. Lets try without first.

[tempral]

as you well said

...we could think about a feature branch...

you and others contributors already done the initial effort,
so I really encourage the community to begin this adventure.

Put online "teeworlds.community" website and start engaging new players and creators,
with demos, discussion forum, news, tutorials, etc...
ask for donations to fund project cost

so finally feel free to implement any meaningful feature the developers team agree

[BlaiZephyr]

as you well said

...we could think about a feature branch...

you and others contributors already done the initial effort, so I really encourage the community to begin this adventure.

Put online "teeworlds.community" website and start engaging new players and creators, with demos, discussion forum, news, tutorials, etc... ask for donations to fund project cost

so finally feel free to implement any meaningful feature the developers team agree

as far as i am concerned it was more of a "f*ck it" moment because the inital teeworlds repo died off because Oy disappeared. - the biggest problem is that someone like @ChillerDragon who has a high interest in keeping this as up to date as possible doesnt have any access to the official forums and such ( steam, teeworlds.com ) - imagine you're downloading a game off of steam and the first thing is that you get encouraged to download or build a fork from the original repo to have additional features you dont have immediate access to. - the playerbase went down already - this doesnt seem like a good thing to get new players hooked. at first glance people will look at both the website/steam/github and see that it was last updated 10+ months ago.

[Bamcane]

I think this project didn't let teeworlds be active again.
The players almost download teeworlds from steam or teeworlds.com, also we didn't add some thing that great useful for players.

We could see that DDNet did a good job. If someone want to play teeworlds,
we will advise him to use DDNet client.

If we want to let vanilla be active again, we only have 2 ways:

1. Wait for Oy back.
2. Create a new teeworlds organization.

or wait it dies.

Also there's another problem im mods community.
We could see the mod community is dying down now:
The servers that not DDNet or Gores is less and less.

[CherryEx]

Well let's talk about Teeworlds logically. It has a simpler client with a better GUI than ddnet; it's original.
The server has a lot of potential for mods.
But the client . . . I mean who uses a client that is so old and out of date it even renders images and skins in a lower quality.
It misses main needed features that are already present in ddnet. Such examples are:
Modern renderers, anti ping, zooming, editor bug fixes and improvements, etc.
I think at least the client has no advantage other than having a good looking gui and being light. Also the server doesn't support main features like databases at all. It's not necessary but quite useful.
And considering these stuff, I believe a feature branch will be useful but, the focus should be on upgrades not on new features.

[ChillerDragon]

• Zooming is considered a cheat in teeworlds. It could be added for spectators but it is not supposed to be used during gameplay.

• The server also does not need a database.

• The fact that the upstream stopped accepting bug fixes for the editor in favor of the inactive editor2 is sad yes. But because of that editor features are in scope for teeworlds-community since it will never conflict with upstream.

I believe a feature branch will be useful but, the focus should be on upgrades not on new features.

What is your definition of "upgrades" vs "new features"?

[Bamcane]

Well let's talk about Teeworlds logically. It has a simpler client with a better GUI than ddnet; it's original. The server has a lot of potential for mods. But the client . . . I mean who uses a client that is so old and out of date it even renders images and skins in a lower quality. It misses main needed features that are already present in ddnet. Such examples are: Modern renderers, anti ping, zooming, editor bug fixes and improvements, etc. I think at least the client has no advantage other than having a good looking gui and being light. Also the server doesn't support main features like databases at all. It's not necessary but quite useful. And considering these stuff, I believe a feature branch will be useful but, the focus should be on upgrades not on new features.

We can see that on the one hand, teeworlds has more simpler code, a better GUI, and more. but on the another hand, teeworlds 0.7 cut out a lot of useful things from 0.6. Like online clan changing, server global sound. We can see there were great 0.7 mod, but they still look like the 0.6 mod before. As for players, teeworlds 0.7 mods seemed to nothing changed, even much less. And the main problem is the development of teeworlds 0.7 tooooooooooooooooooooooooooooooooooooooooooo slowly. So I think that's why teeworlds stopped as 0.7.

[CherryEx]

• Zooming is considered a cheat in teeworlds. It could be added for spectators but it is not supposed to be used during gameplay.

  • The server also does not need a database.

  • The fact that the upstream stopped accepting bug fixes for the editor in favor of the inactive editor2 is sad yes. But because of that editor features are in scope for teeworlds-community since it will never conflict with upstream.

I believe a feature branch will be useful but, the focus should be on upgrades not on new features.

What is your definition of "upgrades" vs "new features"?

My definition of upgrades is to improve/extend the features that are already present, but are outdated like the modern renderer support or the emotions which are in a lower quality and (maybe) not smooth enough. or for example 0.7 already support loading background themes but they're not loaded at startup and instead there's the default black and grey theme and it transitions to the selected theme after it has loaded completely.
and also the repo still downloads its dependencies with a python script so (I think) it would be better to change that to a new teeworlds-libs folder and add tw libs as a git submodule. I say this because git looks like a way more stable way to download/update dependencies and also I think the download dependencies script is not working on newer python verisons (not sure)
However on the other hand, some new features are also needed like the anti ping, but definitely "upgrades" should be prioritized as they're more crucial.
And about the zooming, I meant the possibility should be there, and can be restricted to not work when playing a vanilla gametype.