Create & develop an Open Tibia server

Understand the parts

Engine: the program that runs your world. Data pack: maps, monsters, NPCs and scripts. Database: accounts, characters and saved progress. Client: the application players use to connect. AAC: an optional account-management website.

Start on your own computer with one engine, its matching data pack and supported client. Move to a VPS or dedicated host after your local test works. You need a trusted matching build or source code, a database service and permission to use your chosen assets.

Which engine should I choose?

Choose your world and client protocol first. Then choose a release that explicitly supports them. TFS 1.4.2 is an engine version; 8.60 is a client version.

TFS setup documentation ↗ · Canary project ↗

Download, extract and build

1. Get the selected release from its repository. Save its tag/version name for support.
2. Follow that release’s Windows or Linux build instructions and install its required dependencies. Use an official prebuilt executable only when the project supplies one for your environment.
3. Keep the matching data folders, map and database schema. Create your working config.lua from the supplied example, often config.lua.dist.
4. Back up this clean installation before changing maps or scripts. Test one change at a time.

For TFS, start with Running your first OT server ↗. Canary users can follow the matching release instructions in OpenTibiaBR documentation ↗. Build commands differ between releases.

Create the database and configure the engine

1. Install the database service required by your release, commonly MariaDB or MySQL. Create an empty database and a dedicated game-server user.
2. Import the schema supplied with that exact engine. The OtservAds website schema is not your game schema.
3. Enter its database host, name, user and password in the game configuration. Many TFS releases use mysqlHost, mysqlDatabase, mysqlUser and mysqlPass; confirm the keys in your example file.
4. Set your server name, map/data-pack options, login address and ports. Keep credentials private and the database off the public internet.

If you see an unknown setting or schema mismatch, check your release’s documentation instead of copying another engine’s configuration.

Log in locally first

1. Start the engine from its expected working directory. Read the console until the database, map and network services load successfully.
2. Create a test account and character with your release’s documented account tools. Account schemas differ; there is no universal SQL insert for all engines.
3. Use a supported client and its documented login settings. A same-machine test may use 127.0.0.1; a different device needs the host’s LAN address.
4. Log in, move, fight, save and reconnect. Check that progress survives a clean restart.

Make the server reachable

1. Install your tested engine, data and database on your chosen host. Repeat the connection test there.
2. Point a domain/subdomain to its public address. Enter a login host such as login.example.org without a URL protocol or path.
3. Configure the engine’s public login address and ports. TCP 7171 for login/status and 7172 for the game are common examples; use your actual settings.
4. Allow the required services in the host/provider firewall. Home hosting may also require router forwarding to the server’s LAN address. CGNAT may require a public IP or hosted server.
5. Have someone outside your network test both logging in and entering the game.

OtservAds needs a valid TSQP status response. An open TCP port alone is not enough. Use the engine’s status port in the listing; an HTTPS login webservice is a separate service. Keep status-query protections enabled.

Do I need a website?

A public website is optional for an OtservAds listing. You can continue without one after the form’s warning. Your engine may still require a separate login webservice for its client.

If you want an AAC website, choose one compatible with your engine’s schema and login flow. Follow its installation instructions, configure HTTPS and test account creation. Enter the real working website in the listing; it must belong to the login address’s domain under the current website rules.

Add your server to OtservAds

1. Create an account or sign in. Verify your email when email verification is enabled.
2. Accept the server rules. Use honest player counts, location, version and features.
3. Open Add server. Enter its name, public login host, status port, hosting country, client version, world type and experience multiplier.
4. Add an optional working website and a useful description. The form checks the connection and any supplied website before publishing.
5. Inspect the published detail page. Monitoring normally checks status every 3 minutes.

Need Unique Players? Open the engine-specific setup guide and choose your engine/version. Canary and some other engines already send it.

Build your skills in a practical order

1. Learn the data pack first. Find its configuration, monsters, spells, actions and events. Folder names and registration formats differ between engines, so follow the examples shipped with your release.
2. Start with Lua. Change a small spell or add a simple action on a private test server. Read an existing working script, make one change, restart or reload as documented, and check the console.
3. Learn basic SQL. Understand tables, keys and backups before changing accounts or character data. Practise with a copy of the database.
4. Work on maps and content. Use a map editor and asset versions compatible with your data pack. Test spawns, quests, entrances and saves.
5. Use Git. Save a clean baseline, commit each working change and keep a way to roll back. Keep passwords, private keys and live player data out of the repository.
6. Move to C++ when needed. Learn to compile the unchanged engine first. Change source only when the feature cannot be implemented through the supported Lua/configuration interfaces.
7. Test before release. Check permissions, rewards, disconnects, restarts and interactions with existing systems. Keep development separate from the live world.

Useful first project: make one small quest, test it with two characters, verify rewards cannot be claimed twice and confirm progress survives a restart. Then move on to a larger system.

Maintenance and backups

Test with real players before launch. Keep off-host database/data backups, test restoring them, watch crash logs and maintain the engine and account website. Tell players about maintenance and planned resets.

Introduce your world in our community. Optional featured cards, highlights, banners and countdowns can advertise your launch; they do not change player counts or guarantee visitors.

Forums, tutorials and help

Engine / release:
Operating system:
Client protocol:
Exact error:
Steps to reproduce:
What I already tried:

These external communities are independent of OtservAds. Check each tutorial’s date and engine version before using its instructions.