• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Creating a Tibia Client from Scratch

Evil Mark

Active Member
Joined
Nov 23, 2008
Messages
1,707
Reaction score
32
I basically have no experience in C++ to read the sources I'm assuming the way to go about this would be through the client where one would reverse engineer it?

Could someone experienced comment on this?
 
bots like elfbot, ibot would work in this client?
a big part of otservers players are full of botters
They won't. All of those bots are made for the specific official Tibia clients, they're not going to work on any new client.
 
bots like elfbot, ibot would work in this client?
a big part of otservers players are full of botters
anyways with this stuff you can easily create a new bot for your own client, that would be cool af
 
I didn't really receive the feedback I was hoping for so I'm going to rephrase my question.

If I don't know the source code behind the server, then in order to create a client. I would have to reverse engineer a client in order to understand it better right?

But if I do have a server, how would I know what to place inside the client?

The dream is to have a server and client written in C#. Higher level programming language which would run the game without any unforeseen troubles as it doesn't accept any half measures where C++ will just let you compile if the solution works "kind of"
 
I didn't really receive the feedback I was hoping for so I'm going to rephrase my question.

If I don't know the source code behind the server, then in order to create a client. I would have to reverse engineer a client in order to understand it better right?

But if I do have a server, how would I know what to place inside the client?

The dream is to have a server and client written in C#. Higher level programming language which would run the game without any unforeseen troubles as it doesn't accept any half measures where C++ will just let you compile if the solution works "kind of"
Simply explained, you only need to know about the protocol. The protocol is the abstraction of the messages between client and server, ideally you only need to know that, only in specific cases you need to look at how tfs/the server works(it will help you to know why/how the messages are build).
Luckly for you there is atleast two opensource projects that implements a otserver in C#.
 
bots like elfbot, ibot would work in this client?
a big part of otservers players are full of botters
No, they wouldn't be working(at least official ones), also I don't care about botters.

I didn't really receive the feedback I was hoping for so I'm going to rephrase my question.

If I don't know the source code behind the server, then in order to create a client. I would have to reverse engineer a client in order to understand it better right?

But if I do have a server, how would I know what to place inside the client?

The dream is to have a server and client written in C#. Higher level programming language which would run the game without any unforeseen troubles as it doesn't accept any half measures where C++ will just let you compile if the solution works "kind of"
If you want to create Tibia Client/Server then you need to understand few things:
  • Tibia sends data by using TCP/IP protocol for it's reliability
  • Protocol that cipsoft wrote for Tibia(you can get these by looking at protocolgame.cpp/protocollogin.cpp, flash client sources or by reverse engineering doesn't matter how you get information about these packets, what matters is that it needs to be exactly the same)
  • Tibia.dat and Tibia.spr structures for pre-11 clients or appearances[...].dat and sprite[...].bmp.lzma structures for post-11 clients(Tibia.dat is binary format, Tibia.spr is RLE-encoded sprites, appearances[...].dat is google protobuf compiled file, sprite[...].bmp.lzma is simple bmp file compressed by lzma)
How you write code depends on you the only thing you need to manage the same is network protocol.
Also if you're asking about how to know about these things without any source behind then yes reverse engineering is the only way(like how the first OTS engines were writed) or you can hack into game company machines and stole their work(xD).
 
You may learn tibia protocol/sprite system from working projects like OTClient/TFS. I think it's easiest way to learn how to make own client from scratch.
Code rewrite from C++ to C# may give you beginning knowledge who may help you in future use reverse engineering in Tibia client.

For example (OTC):
Protocol: protocolgameparse.cpp
Sprite: spritemanager.cpp
 
Reversing Tibia Client network stuff isn't a big challenge. What i suggest to you is read the tfs protocol sources and understand from protocollogin to protocolgame.

Choose a simple version (like 8.6) and start from him, is better for developing socket stuff.
If you want i can send you a good stuff about connection of cipsoft client 8.6 xD
In C# you can do all you need, just need some libraries for encrypting RSA, encrypting XTEA and TCP Socket (like TCPClient).

When you are done with all the connection, you can start understanding the .spr and .dat structure, with that you can get the sprites 32x32 and build them correctly.
And the last step is rendering, you can speed up reading the OTClient algorithm about rendering, moving creatures, adding/removing things, everything. (or in the hard way => reverse the Tibia Client, use your own logic at games development, etc.)

That's all i have done in my game using Monogame Framework (C#)
(just a demo video showing the game running, the sprites are not mine, using for test purposes)
 
As a matter of simple practical advice, everything else having already been answered, you should probably actually learn a language like C++/C# first if you're trying to make anything remotely close to a serious Tibia client.
Writing a client seems much harder than writing a server as far as I can tell, having written a semi-functional server from scratch myself.
That said, you could always start out with something simpler like making a simple graphical application, scripting a small game using anything from GameMaker to Python, Java, or any modern game engine.
On the plus side, if you start out learning Unity there's always the Open Tibia Unity project out there for study and to help you get started.
 
A client is nothing more than an OpenGL window and a bunch of controllers. In simple terms, the OpenGL window runs a "main" function that never stops refreshing (at a rate of X frames per second). The application will have one or more separate C++ data structures keeping track of the OpenGL primitives being displayed (triangles, quads etc), as well as their (X, Y) screen positions.

OpenGL, like any other C++ Object-Oriented language will provide the classes/objects and a set of methods, which the user is supposed to manipulate by linking the OpenGL library files to his C++ application in the compiler. OpenGL is an industry standard so there are several tutorials on the internet on how to download/install it and link it to your application.

Note: this is a common misconception, but OpenGL does not "display" anything to your screen (that'd be the job of the graphics card). OpenGL is simply an intermediary between the user and the graphcs card, and will parse human-readable instructions (aka C++ code) into a raw data buffer, in a format the graphics card can actually read an pass on to the screen. As such, it is heavily optimized for speed, and has to have strictly defined and efficient C++ data structures/methods based on the physical constraints imposed by the hardware/graphics card.

The controllers in a game are basically "Macros", that is simple if/else loops that run before the "main" function in your application updates and will detect things like keyboard presses and mouse clicks. OpenGL Windows can detect keypresses, and even change primitives like tris/quads position. Those are methods provided by the language that the user does not have to implement. However 2D controller macros and logic have to be implemented by the user, based on these methods.

You could try writing a simple OpenGL application that draws an 800x600 window with a black background and draws a single white/red quad at the center of the screen. Once that is successful, you can proceed to try to implement WASD controllers (a "Macro") that runs before the main function updates, and that will move the quad's position a fixed amount of pixels to the North/South/East/West depending on the WASD key that was pressed at the start of the update. This is a good ~4-5 hour exercise if you've never programmed in this language to get your feet wet with GL, and could be beneficial if you are trying to understand how a 2D game client works.

3D clients are also programmed using GL (or variants), but have to take the extra step of keeping track of both 3D and 2D object representations. Controllers in this case actually affect the 3D object representation, which then gets converted into 2D output/OpenGL primitives (colored tris/quads) in real time. This 2D output then gets processed by the language normally, just like it would be if you were programming a strictly 2D application. 2D games are easier to program because you don't need to bother with this auxiliary 3D representation. Programming that can be extremely hard and is basically 90% of what a modern 3D engine does. The process of converting:
-> 3D scene
-> 2D OpenGL primitives
-> list of pixels and their colors
is called "rasterization". That's a 3-step (sometimes 4) process that's computationally intensive and can involve a decent amount of linear algebra/mathematics.
 
Last edited:
Back
Top