Teeworlds - development

[teeworlds/teeworlds] Pull request opened: #2885 Handle SIGINT in server to properly shutdown everything

The signal handler is registered as soon as the server is starting to initialize, to make sure that it properly shuts down even when you press Ctrl+C before the server loop is running. Closes #2856.

wow

5-8% play with Teeworlds client. And its are still alive. nice nice

A release is overdue

only 5-8% of teeworlds player play with teeworlds client? doubt

Depends on your definition of teeworlds players I guess

*definition of teeworlds client

custom clients are somewhat unpopular in 0.7

time to write one

Dune

custom clients are somewhat unpopular in 0.7

I think the 0.7 isn't very popular

that's unrelated

It might be related since more servers are becoming cross protocol now. (edited)

Dune

custom clients are somewhat unpopular in 0.7

"within 0.7"

^I think this was sarcasm of Dune

no sarcasm (edited)

~~Cross topics~~

With more players interested in 0.7 more modders will be interested in it

@Assa, did you make an API?

again, that's orthogonal

18:32

players that are on 0.7 are there because they have little interest in mod-heavy clients

I wonder if you did it as an inclusion of scripts in the layout of the libraries to connect them in the future to the final file?

@Kurosio no I got lost in a side project

0.7 players still plays zCatch, gctf and stuff tho.

Kurosio

@Assa, did you make an API?

What kind of API are we talking about

TsFreddie

What kind of API are we talking about

The structure from which mods are built

I tried to make one for server mods

18:36

But it quickly became janky.

TsFreddie

I tried to make one for server mods

Me, too. Through the assembly of individual components. Which are then included through config to the final file.

I just tried to make everything a gamecontroller abstract method, not exactly an API I guess.

18:40

Btw, some chinese company is making a mobile ddnet rip-off. And I somehow got contacted and they wanted to hire me

(edited)

18:41

It feels really weird.

TsFreddie

I just tried to make everything a gamecontroller abstract method, not exactly an API I guess.

I tried to do something like Native API and Loader

Ye that sounds cooler

TsFreddie

Ye that sounds cooler

But that's not practical for an open source project. If only for convenience, but that is also a question of who is more comfortable

i'd suggest to disable compressed textures for either alpha textures or completly remove it before release ^^

TsFreddie

Btw, some chinese company is making a mobile ddnet rip-off. And I somehow got contacted and they wanted to hire me

(edited)

sounds kinda classic.

well I'm more weirded out be company actively talking to hire me rather than the ripoff part.

19:16

Also I don't know if a ddrace type mobile game would be popular among the general public. Which is essential for a mobile game to get picked up by a game service provider.

19:18

I feel like you are almost guaranteed to fail if you run a game as service in-house in China.

I might actually consider it tho, if they can offer what I've asked for

19:38

If teeworlds is the reason that I have a job out of all things. That might be a epic gamer moment.

hmm, I am already annoyed by a teeworlds api where I would have to link against teeworlds.dll

Assa

time to write one

F-Client :p

Designing a modding API at this stage of the game is basically impossible. You could never fulfill all requirements of the modders and most of them would never even adapt to a new standard as most peolple use ddnet anyway. No matter whether one used lua, wasm, js/ts, a native interface or whatever, there would always be someone who (thinks he) knows better, or misses some feature and implements it on his own. The game would need an extensible protocol, flexible physics code, a scripting interface and a modifiable UI to be really useful for modding. I still love to play vanilla from time to time, but besides a few people who play the game for over a decade now, it is basically dead. But even getting back to a common codebase is unrealistic, since ddnet depends on countless physics bugs in their code...

@redix I agree it is unrealistic as a mod collaboration project, but it could get some traction if it was an official API?

21:48

Teeworlds isn't some sort of game engine, so of course there would be some restrictions, but that encourages creativity anyway

Yeah teeworlds is not a game engine, but due to its very static coding style it has a lot of restrictions which could definitely be relaxed a bit. At the moment both projects are getting contributions, though on tw side its mostly Robyt3 against an army of people on ddnet side. Both projects are missing fixes and improvements that were added to the other one years ago... A standardised API would probably get some attraction but due to the different policies of ddnet and tw I would not bet on it, and implementing an API without the support of ddnet is not worth the effort imo.