Topic: [TeeUniverse] Devlog
TeeUniverse is a free and open source game that offers you various gamemode and playground designed by the community. It was made to be fully compatible with TeeWorlds as well as some of its famous mods.
This topic concerns the progression in development of TeeUniverse.
The project is separated in three parts: the editor, the game client and the server. Actually, only the editor is available for testing. The editor is already available on the repository, and we move forward to a official beta test release.
GitHub project: teeuniverse/teeuniverse
IRC: irc.quakenet.org#teeuniverse
The former name of this game was "ModAPI".
==================================================
Initial message:
Since some mods are trying to code non-compatible-with-vanilla servers to overcome the lack of possibilities with TeeWorlds 0.7, I thinks this is the moment to talk about what we wants as moders. Then, we should talk about implementation and compatibility with the vanilla 0.7.
I'm aware that TeeworldsNetwork arleady start this, but I think it's more important to talk between us first, and then see for implementation. But TeeworldsNetwork seems a very good start (and I don't care about who did it, I'm not possessive :-) I just want good quality)
We all know that by doing this, we can loose a lot of vanilla players. This is why we always wanted compatibility with the vanilla version. But sometimes, it's just not possible. So the Mod API must be compatible, in the sense that vanilla can still connect the server, but in a sort of "low-res" game.
Proposition 1:
The server has an options to accept or reject vanilla players. The new master server can also indicate this information.Proprosition 2:
The server can detect the protocol of the player and store it. Depending of the protocol, the server send the appropriate packet to clients. This allows to send "laser" packets with colors for non-vanilla clients, and normal lasers to vanilla clients. We can discuss packet per packet what we can change. The laser is just an example.Proposition 3:
By creating sort a fork of the game, we will loose some players. To attract some others players, mods must be of good quality. This mean graphics, and why not, sounds. The proposition is to send, like maps, a file that contains graphics, options and sounds. The options file allow to describe how to use the graphics file. He can specifies for example a weapon list with ID. Then, the server can just send the appropriate WEAPON_ID and the client will display the weapon.
Here is an example of file :{ "serverSidedSkin" : 1, "newGraphicsList" : { { "name" : "bomb" "id" : 128 "graphic" : {"./graphics.png", 0,0,2,1}, }, }, "newWeaponList" : { { "name" : "ak47" "id" : 10 "weapon_graphic" : {"./weapons.png", 0,0,2,1}, "reticula_graphic" : {"./weapons.png", 2,0,3,1} }, { "name" : "stormrifl" "id" : 10 "weapon_graphic" : {"TEEWORLDS", 0,0,2,1} //Use the default game.png file "reticula_graphic" : {"TEEWORLDS_MOD", 3,0,4,1} //Use a new default game_mod.png file that provide commons graphics made by the community (high quality needed) } } }
The serverSidedSkin is an option to let the server choose the skin of all players, even in team based games.
TEEWORLDS and TEEWORLDS_MOD are files provided with the client and containing graphics.
This file is very important and we must discuss what he can do. This file must also be generated by the server, because of the vanilla compatibility.A command like AddNewWeapon(WEAPON_STORMRIFLE, WEAPON_RIFLE, "stormrifle", ...) must add a line in the file, and keep in mind that WEAPON_RIFLE must be send to vanilla client instead of WEAPON_STORMRIFLE.Proposition 4:
Improve the prediction of the client. On important case is the freeze effect used in openFNG, DDRace and InfectionClass. If the client know that his character can move, he can disable the strange flickering effect. This is very important to improve the quality of mods. But this needs that we agree about what to predict.Please share your opinion and lets make together a Mod API for TeeWorlds.