Topic: Extra major complaint
R E L U C T A N C E O F P L A Y E R S T O T R Y N E W T H I N G S
This is THE source of all the problems of Teeworlds. That is why Teeworlds is currently stagnating.
This is why noobs get trapped in "noob" gametypes. They just don't want to reach out, because if they join any gametype with steeper learning curve they'll regularly get killed in one second until they gain skill.
Pros are prone to this too. They don't play any maps except for ctf1, ctf2, ctf3 and (rarely)ctf5 because of their reluctance to learn new movement patterns. This is understandable, since if they try new maps, they'll most likely move like slugs until they get familiar with them. This is most seen on ctf4 and ctf6, since movement on them is nothing like movement on most maps.
Don't belive me? Have you ever seen serious clans that play ctf6 and ctf4? Have you seen any active standard or instagib server that runs a custom map?
Here are some solutions I came up with:
[MAPS, GAMETYPES] Make Teeworlds proprietary, legally prohibit modding and enforce map rotation
It'll kill Teeworlds. No Teeworlds, no problems.
[MAPS] Make a new set of official maps
I don't know how effective will it be. Most likely it will only help temporarily. In the best case, players will sooner or later select a few maps from those new official maps as the new "king" maps and the rest of the maps will be neglected. In the worst case, players will just continue to play the old maps.
[MAPS] Make a new set of official maps every release
This could work, since noobs who didn't disable standard maps will play new maps. Players that have already developed a preference to play some fixed set of maps will get an incentive to play new maps because they are official. Active servers will emerge, noobs will gain skill. Of course each generation of players will have their own preferred maps, but these generations will sometimes play together. Players will understand that trying new maps is fun.
[GAMETYPES] Ban noob trap gametypes
"Noob trap gametype" is highly subjective, so all mods will be in danger. Who wants to mod if your mod can be banned?
[GAMETYPES] Leave it as it is
We can't really force anyone to play any particular gametype.
----------------------------------------------------
B A D M O D D I N G S U P P O R T
Teeworlds engine doesn't allow modding beyond limits set by protocol. Nodes - died, StarWars - never released, WaterMod - laggy, Aviator - laggy. It's impossible to augment the protocol, add new entities for example or new tuning parameters. Last time I tried to do my Aviator I made a custom client with correct prediction for jetpack but then I realized that no one will download it. C++ programs have full access to computer, so people worry about viruses in custom clients. Custom clients also need to be compiled for different platforms (since most people don't know how to compile C++ code). And they take much effort and a long time to download (one needs to close Teeworlds, go to mod web page, click download, accept, save, unpack, ...). It's very hard to get users to download custom clients. That's why Nodes, the mod that could be very popular and potentially soften the damage done by DDRace, died.
Don't underestimate modding. Client mods that are easily and safely downloadable could be our nursery for new experimental powerups, gametypes and weapons. Nursery that every single Teeworlds player can visit (not just the ones who know how to compile C++ code). This can really save Teeworld from stagnation.
Here are all the possibilities for better modding support I could come up with:
JavaScript
I don't propose to make Teeworlds a browser game (but we could optionally add HTML5 engine backend). I want to create an engine that loads and executes mods (something like a little Teeworlds-only browser without HTML and CSS cruft and only features Teeworlds needs).
+ Garbage collected, dynamic language
+ Prescribed for people by the Global Government
+ Very popular (Web, Windows 8 Metro, KDE 5, GNOME 3, Node.js, ...)
+ Fast due to JIT
+ Supported by Google®, Microsoft® and Apple®
+ Safe untrusted code execution (since execution of untrusted code is precisely what JavaScript is made for)
+ Stable, new versions are generally backwards-compatible (since making new versions incompatible would ruin many large Web Apps)
+ We could implement engine interfaces in HTML5, effectively making Teeworlds run in Web browsers. That'll bring us many more new players.
- Considerably slower than C++
- Some bad language design decisions
- Need major porting effort
LuaJIT
Same as in JavaScript, but with Lua instead.
+ Garbage collected, dynamic language
+ Fast due to JIT
+ Exceptionally good language design
+/- Safe untrusted code execution requires some manual work
- Considerably slower than C++
- Unstable, new versions are usually backwards-incompatible (since it's usually used in proprietary games that, once released, are never updated and scripts are usually small and easy to update and they don't have to worry about breaking large applications with new versions (like the whole Teeworlds game login I plan to port onto it))
- JIT interpreter is a one-man project, so it can just stop being developed, since it's not much needed by companies anyway. Speed of the standard Lua interpreter is usually enough for small game scripts, but won't be enough for the whole Teeworlds game logic.
- Not as popular as JavaScript
- Need major porting effort
C++ sandbox
Operating systems actually CAN place restrictions on native code (how do you think they limit non-administrator users from removing C:/WINDOWS/system32). We could use OS abilities to restrict downloaded C++ mods from doing harm to the player's systems. As C++ is not an interpreted language, we will need to ship a C++ compiler to compile mods in-place though.
+ No performance loss in the official client/server, since we could just link game code and engine code into one executable, like we do it now
+ Downloaded mods will probably be slower than official client but still faster than dynamic languages
- C++ is a static language with manual memory management. The fact that Teeworlds doesn't use STL makes the code even harder to understand for most people.
- Need to ship a C++ compiler with Teeworlds
- Proper native code sandboxing support is available in Linux only since kernel 3.5 (even Fedora doesn't ship it yet)
- Need to investigate native code sandboxing support in Windows and Mac OS X