1 (edited by necropotame 2016-11-27 17:02:38)

Topic: [TeeUniverse] Devlog

http://orig10.deviantart.net/a5c9/f/2016/272/e/c/tee_universes_by_android272-dajarm4.png

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.

https://s22.postimg.org/rfw4ulmyp/teeuniverses_screeshot.png

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:

necropotame wrote:

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.

2

Re: [TeeUniverse] Devlog

I purposed Recamp Guns a while back.  Maybe you could use this for weapons.

Jesus is my Lord and Savior. Praise be unto God for giving us a way to live with him.

Check out my DeviantArt for all my TeeWorlds art and ideas for Teeoworlds

3 (edited by necropotame 2015-12-18 11:31:50)

Re: [TeeUniverse] Devlog

This is exactly what I has thinking about when I talked about TEEWORLDS_MOD ;-) Thanks to provide the link.

EDIT : Sorry, I never seen this topic, only the picture. Your proposition is close to mine (for the weapon part). The only difference is that my version contains only informations about what the client need to know. The number of ammo or the reload time is server sided, so it should no be included in the file.

4

Re: [TeeUniverse] Devlog

But... what happens? 2016 is the year of the fork? tongue

5

Re: [TeeUniverse] Devlog

Apparently :-p

Well, I was surprise me too see two forks appear in same time (NetGUI and TeeWorldsNetworks). This is mainly due to the deletion of the Broadcast command, I guess. In same time, 0.7 will be released at the end of this year, so some peoples maybe thinks that forks can replace the official teeworlds during the transition. This is the wrong way to do, in my opinion.

However, I see that my mod can't be ported to 0.7 since it is impossible to change the skin of a player during a game session. So I join the movement :-) But if we want to "fork" TeeWorlds, it must be done with a purpose and a collective point of view. Not from someone that do it alone just because it's cool. This is why it's very important that we agree about a specification of what this "fork" must do. The Git repository must be accessible to multiple persons, the code must be open source without credits everywhere, and focused on server sided modification. Client only modification like new skins or aim line are out of the concept and must be done from this fork, not in this fork.

6

Re: [TeeUniverse] Devlog

But.. the community can't decide in that direction grows Teeworlds? Or the community is only good for chopping code? Perhaps need a seriusly discussion about this point....

7

Re: [TeeUniverse] Devlog

Depends of what do you consider as community. Moders ? Players ? Players that play only vanilla version ? All of them ?

Actually, the devs don't want to add any single line of code to help moders. In fact, they remove some useful function. They did that to provide a better vanilla version, with less internet trafic and translation support for server messages. But it's not at all usefull for moders.

8

Re: [TeeUniverse] Devlog

I only know that the commuty aren't three or four guys.... xDD

Yeah i know... i tell it when remove "onChat" for server mods... And for me Teeworlds its a game.. not a protocol for send and receive data.... if like improve this.. can start with maps send by server... i not understand why uses UDP..... for reimplement TCP? :\

9

Re: [TeeUniverse] Devlog

@unsigned char*: I think becuz' the UDP is a lot faster than the TCP. TCP has a "Is the packet received?"-Check and an active connection. You knoow?

10

Re: [TeeUniverse] Devlog

So basically to vanilla-protocol/not-your-protocol clients would not have movement data sent to clients from from frozen tees, fixing an antiping bug without client modification? fng'gonna love this. smile

Clan: Riot (I'm one of three leaders: Mile, Deku, pie)
Host teeworlds maps on a fng/ctf/dm/ddrace server for testing:http://riotproductions.tk/teewo/ broken-need reinstall nginx http://riotproductions.tk/bounce?whatEven, Teeworlds NA Discord chat

11

Re: [TeeUniverse] Devlog

Toast wrote:

@unsigned char*: I think becuz' the UDP is a lot faster than the TCP. TCP has a "Is the packet received?"-Check and an active connection. You knoow?

Teeworld's usage of UDP kind of emulates TCP. They use sequence numbers and retransmissions. I'm not even sure if UDP is faster in this scenario.

12

Re: [TeeUniverse] Devlog

pielover88888 wrote:

So basically to vanilla-protocol/not-your-protocol clients would not have movement data sent to clients from from frozen tees, fixing an antiping bug without client modification? fng'gonna love this. smile

I'm not sure to understand what you say, but all "data" must have both versions : a vanilla one, and a ModApi one. If you use vanilla, you get only vanilla data, if you use ApiMod based client, you get only ApiMod data.

This is an exemple of a class that must be declared when the gametype is initialized. This class contains coordinates of the sprite, and how to send an alternative version to vanilla client.

class MyNewSprite : CSprite
{
     MyNewSprite(int ID, int ImageLayer, int x0, int x1, int y0, int y1) //Initialization of the class, and update of the mod file

     void Snap(int SnappingClient, vec2 Pos, float Angle); //Decide to send using vanilla or ApiMod 
     void SendApiModMsg(int SnappingClient, vec2 Pos, float Angle); //Inhereted implementation of how to send a sprite
     void SnapVanilla(int SnappingClient, vec2 Pos) //Alternative version for vanilla client
     {
    CNetObj_Flag *pFlag = (CNetObj_Flag *)Server()->SnapNewItem(NETOBJTYPE_FLAG, m_Team, sizeof(CNetObj_Flag));
    if(!pFlag)
        return;

    pFlag->m_X = (int)Pos.x;
    pFlag->m_Y = (int)Pos.y;
    pFlag->m_Team = m_Team;
     }
}

Then, in an entity, you just have to call GameServer()->GetSprite(SPRITE_MYSPRITE)->Snap(SnappingClient, MyPos, MyAngle);

13

Re: [TeeUniverse] Devlog

Toast wrote:

@unsigned char*: I think becuz' the UDP is a lot faster than the TCP. TCP has a "Is the packet received?"-Check and an active connection. You knoow?

Teeworlds uses UDP for map download because it already uses UDP elsewhere. TCP would be the better choice here if it wouldn't mean using another protocol.

14

Re: [TeeUniverse] Devlog

Hmm... I'm not really sure how to understand this idea...
Making a new teeworlds? Replacing the old, mod-hating one? "community-teeworlds" against "teeworlds-teeworlds"?
Whatever you are planning, it cannot go along with the original game and would even create the need of hosting an own "community-teeworlds-master-server" from what I got. I don't know if these are the right weapons to fight the lack of mod-support. If you think of ddnet and what it did to the game... and it was even compatible with vanilla.
I know, 0.7 takes us much possibilities, but shouldn't we rather use what we have and be happy with that?
I didn't create NetGUI as a "fork" like you said... I even didn't think that it may work. Though, it's pretty awesome wink And yes, the incompatibility really sucks and yes, it cannot be circumvented by just faking the nethash like it used to be in former days. But I'd want to solve that issue somehow else instead of pooping onto teeworlds and it's devs.

But if we could get this into a appropriate windows of common sense, I would be with you wink

15 (edited by 2015-12-18 20:25:39)

Re: [TeeUniverse] Devlog

Oh, I'm not pooping :-D Like I said, I understand why they did that. And I don't want to leave TeeWorlds by making a fork. I use the word "fork" just because what I want is not compatible with the vanilla client. But as you see, I want to maintain sort of compatibility.

With my proposition, moders can make good mods with graphics and GUI, and in same time provide some compatibility with vanilla client. Some times, moders will not add the compatibility layer, but it's a choice.

I start a concrete proposition : Sprite
NetObject name : Sprite
Content :
{
     int m_ID;
     int m_X;
     int m_Y;
     int m_Angle; //Of float, but we have to create this type
}
The ID i correspond to the i-th element in the ModApi file description, for exemple like this :
{
     int image; // 0 for game.png, 1 for game_modapi.png and 2 for the one dowloaded by the client
     int x0, x1, y0, y1; // Part of the image to print as sprite
}

One can imagine also adding the NetObject CharacterSprite to spectify that the sprite is attached to a player. Then, the prediction will be better.

16

Re: [TeeUniverse] Devlog

Ah ok, now I got you. But wouldn't change stuff like that the nethash aswell? I mean, making changes to the NetObjects is the same like making changes to the NetMessages…

17

Re: [TeeUniverse] Devlog

If you are interested in some more 'advanced' 2d rendering possibilites, spine might be interesting.
I have a basic implementation on my repository https://github.com/cinaera/teeworlds/tree/spine if you are interested (texture atlas, skinning, bone animations, mesh transformation).

I have no interest in these forks but just wanted to notify you if you might want to implement sth similiar (:

18 (edited by Siile 2015-12-19 00:33:56)

Re: [TeeUniverse] Devlog

Hi BeaR! I'm going to use that once 0.7 is out. ^^

http://ninslash.com/img/rullaattori.gif

19 (edited by necropotame 2015-12-19 10:11:46)

Re: [TeeUniverse] Devlog

Thanks BeaR. But I don't want something that complicated for now smile

I've thinking about MosApi and the trick to maintain compatibility with vanilla 0.7. I think we can do the same and also provide compatibility for 0.6. I will try to build a prototype.

The server would be able to accepte players from 0.6, 0.7 and 0.7 ModApi. Ans the client whould ne able to play these three version also. I'm not sure about the technical difficulties about that. The prediction part could fail if 0.7 differs too much.

20

Re: [TeeUniverse] Devlog

With 0.7, the global_sound messagr no longer exist. I will add it to ModApi.

21

Re: [TeeUniverse] Devlog

Btw, is there some kind of repo set up yet?

22

Re: [TeeUniverse] Devlog

Not yet. For now, I'm working to make the ModApi client compatible with the protocol of TeeWorlds 0.6 and 0.7. Right now, I can connect the client to 0.6 servers and see the map, but the snapshot must be "translated" from 0.6 to 0.7.

When this work is done, I will add a GitHub repository and start to implement the protocol of ModApi. You can also join the project to include what you did with NetGUI and contribute to the protocol of ModApi.

According to me, all modifications that change the teeworlds protocol must be done in ModApi. If not, the diffusion of mod-friendly client could be difficult. And I hope that the compatibility with 0.6 for the client and the fact that ModApi servers can allow vanilla 0.7 clients to join, will help to made this client "popular".

23

Re: [TeeUniverse] Devlog

Oh, I'd actually like to join the project to help you developing such a client. Additionally, I need protocol compatibility for NetGUI wink
I'm really looking forward to have a look at you repository when you've set it up.

24 (edited by east 2015-12-22 12:22:28)

Re: [TeeUniverse] Devlog

Why don't you guys team up with TeeworldsNetwork? They are still working on it and It would be bad to have two different forks with nearly the same goal to make 0.7 mod-friendly. (The Mod API discussed in this thread is far more difficult to implement, though)

In the end both clients will lack of compatibility to each other and it won't be clear which base to use for new modifications.

25

Re: [TeeUniverse] Devlog

I agree, but the approach taken by TeeworldsNetworks is different. They don't ask to make standard protocol, they just start a complete fork. The idea behind ModApi is focused on keeping compatibility with 0.7 (and why not 0.6) and in same time, provide new interesting options for mods. It's about on protocol, and should be the initial building block of any mod.