[Oldschool 7.4]Real-time translation.

[grilaud]

Oldschool 7.4​

A TFS 1.5-based server with HD graphics(optional), real-time translation (by request), Bestiary, Charms and performance-focused systems.

Hello everyone,

This is not an advertsing. I would just like to share and discuss some ideas I had to improve what we had in oldschool.

Idk if this is the right place, and there is still alot of work to do, but i need to share what im doing to someone.

This is a project I have been working on: an oldschool Tibia server based on TFS 1.5, focused on the 7.4 era, but with a custom client, modernized systems, performance improvements and several quality-of-life features.


The idea is not just to run another real map server, but to build a solid, stable and polished oldschool experience, using a modern base without losing the classic Tibia feeling.

Real-time Translation​

One of the systems I am most excited about is real-time translation. Communication between players has always been one of the biggest barriers in online games, especially on international servers. The goal is to allow players from different countries to interact much more easily, without depending so much on a shared language.

On the server, messages will be translated directly through the client integration, making communication more accessible between Brazilian, European, Latin American and other communities. The idea is not to replace the original chat experience, but to add an optional accessibility layer that brings players closer together.

The translation is handled server-side, so the player does not need to worry about performance or their own network being used to process translations.
This is basically the first (and only, for now) feature I want to discuss with you guys, but I also wanted to share everything I've been working on so far.

Base and Architecture​

The server uses TFS 1.5 as its foundation, adapted to the 7.4 protocol. One of the main priorities has been keeping the client and server tightly synchronized, instead of treating the client as just a visual layer.

Several systems were adjusted or implemented on both sides, including:

• Custom communication between client and server through extended opcodes.
• Client UI systems connected directly to server-side data.
• Proper handling of oldschool mechanics on a more modern TFS base.
• Compatibility work between the 7.4 protocol, the datapack and the custom client.
• Careful server-side validation of requests sent by the client.

This allows the project to go beyond a basic 7.4 server, keeping the oldschool foundation while supporting more modern systems.

HD Graphics and Custom Client​

One of the most visible parts of the project is the optional graphical upgrade.

The client was adapted to support HD/upscaled graphics, including item sprites, creatures, outfits and map elements. The idea is to make the game look cleaner and more pleasant, without losing the oldschool identity and while keeping performance as close as possible to regular sprites.

The client work includes:

• HD sprite support.
• 64x rendering adjustments.
• Custom UI modules.
• Improved inventory layout.
• Custom character bonus window.
• Bestiary interface.
• Trade/shop interface improvements.
• Client-side sprite and outfit fixes.
• Performance work related to sprite loading and rendering.
• Optional preloading improvements to reduce stutters.

This is not just a sprite replacement project. The client itself was modified to properly support the server systems.

Performance Optimizations​

A lot of time has been spent analyzing and improving performance, especially because oldschool servers can become expensive when many players and creatures are active at the same time.

Some of the optimizations already implemented include:

• Creature movement optimization, focused on supporting a large number of monsters moving simultaneously with low impact on server usage.
• Significant cost reduction in the classic attack speed system.
• Packet optimization when switching attacks between creatures.
• Protection against spam from buttons, interface actions, target switching and other repetitive actions.
• Blocking or discarding unnecessary repeated packets.
• General cleanup of expensive logic paths.

One of the main goals is to keep the server responsive even in situations with many players, monsters and actions happening at the same time.

Bestiary System​

A complete Bestiary system has been implemented and adapted to the oldschool environment.

Current features include:

• Creature overview.
• Creature details.
• Kill progression.
• Loot display.
• Loot rarity classification.
• Server-side creature data loading.
• Integration with the Charm system.

The Bestiary is not only visual. It is connected to character progression and bonus unlocking.

Charm System​

The project also includes a Charm system, starting with Savage Blow.

The first implemented charm adds a critical hit mechanic adapted to oldschool gameplay, with heavily reduced power so it does not break the balance of the version.

Current features include:

• Unlockable charm progression.
• Persistent charm states.
• Active/inactive charm control.
• Charm points obtained through Bestiary progression.
• NPC-based charm activation.
• PvE critical damage.
• PvP-adjusted critical damage with reduced bonus.
• Character bonus interface showing active bonuses.
• Visual feedback for critical hits.

The system was designed to be expandable, allowing new charms and character bonuses to be added in the future. Critical damage is only one example.

NPCs, Shops and Economy​

A large part of the work has also been dedicated to NPCs, shops and the server economy.

The server economy is under constant review. The idea is to take into account that players today have much more knowledge than they had during the classic Tibia era. Because of that, item prices, loot, quests, rewards and gold sinks are being carefully reviewed, with the goal of controlling inflation and keeping the economy healthy for a long time.

Progress includes:

• Reworked merchant NPCs.
• Functional shop interfaces.
• Revised buy and sell prices.
• Clickable keywords to make NPC communication easier.
• Gold sinks in several game activities.
• City-by-city NPC review.
• Planning for travel NPCs.
• Planning for quest-related NPC behavior.
• Safer handling of player names and dialogue variables.

The long-term goal is to have a strong economy, with more consistent prices, healthy item circulation and fewer exploitable gaps.

Actions, Quests and Map Systems​

A lot of work has also been done reviewing map actions, levers, chests, teleports and quest-related mechanics.

This includes:

• Fixing broken or missing action scripts.
• Reviewing important levers.
• Implementing trap mechanics.
• Checking chests and quest rewards.
• Investigating teleports with missing destinations.
• Validating critical map interactions.
• Fixing doors, keys and access-related actions.

Some quests are also being adjusted to better preserve the rarity of certain items. In some cases, very impactful rewards may be replaced with gold, jewels or alternative rewards, preventing rare items from entering the server too easily.

Custom Systems and Quality of Life​

The project also includes several custom or modernized systems, such as:

• Ragnarok/Miracle-style shop interface.
• In-game calculator with minimum/maximum damage calculation.
• Training calculator for all vocations.
• Character bonus panel.
• Improved client UI behavior.
• Server-side open container restoration system.
• Better packet validation.
• More useful debug tools.
• Loot simulation tools.
• Offline tools to test drop rates.
• Cleaner client/server integration.

Some of these systems are small individually, but together they make the server feel much more polished.

Development Philosophy​

The project is being built around a few clear principles:

1. Oldschool feeling first
   The goal is to preserve the gameplay feeling of version 7.4, not to turn the server into either a clone of old Tibia or modern Tibia.
2. Modern technical base
   Using TFS 1.5 allows better maintenance, performance and present/future expansion.
3. Performance matters
   The server needs to be prepared for real multiplayer conditions, not just local testing.
4. Economy matters
   NPC prices, loot rates, progression and item circulation are being handled carefully and reviewed by an economist/programmer.
5. No rushed release
   The project is being reviewed system by system to avoid launching something incomplete or easily exploitable.

Current Status​

There is still work to do, but the core of the project is already solid and moving forward quickly.

My goal is to create a serious oldschool server with modern polish, good performance and long-term potential.

If you had unlimited resources to build an oldschool server, what features or ideas would you like to see? I'm curious to hear what you think would improve the oldschool experience while keeping its original spirit.

 

[Sorky]

I did something like that for my server.

It is MarianMT running 6 language models, PL > BR, BR > EN and so on. It would need way more CPU than the server tho. Didn't test with real players.
Here is what Docker was showing for 10 request/s for a minute.

Note that 122.86% of CPU is 1 whole thread, not that the CPU was overclocked

 

[grilaud]

That's really interesting. :O
Thanks for sharing your experience.

One realy simple idea that came to mind is handling global channels (Trade, Game-Chat, Help, etc.) differently. Since every player receives the same message, the server could translate it once, cache the translated versions, and only send the appropriate cached translation to clients that have translation enabled. That would avoid repeated translation requests for identical messages. You probably thought on this already xD;

Have you experimented with other translation engines or inference backends that might use less CPU or memory than MarianMT? Maybe something optimized for inference, quantized models, or a different runtime?

Another thought: have you considered running the translation service on a separate machine? The game server would simply forward the text, receive the translated result, cache it, and then distribute it to players. That way the game server stays focused on gameplay while the translation workload is isolated.

Have you tried measuring where most of the cost actually comes from? Is it mainly model inference, model loading, tokenization, or communication between the server and the translation service?

Do you think batching multiple translation requests together would make any noticeable difference, or does the added latency outweigh the benefits?

I'd also be curious to know how much memory each loaded language pair consumes. If several language pairs are active at the same time, is memory or CPU the bigger bottleneck in your experience?

I'm really interested in seeing where this idea can go. Real-time translation could make old-school servers much more accessible to players from different countries without changing the original gameplay.

Also, I cached many common phrases in advance to avoid translating redundant things like "hi", "buy bp...", "sell bp...", item names that players are already used to seeing in English (Plate Armor, Crown Armor, MPA, and other common abbreviations).

 

[Sorky]

One realy simple idea that came to mind is handling global channels (Trade, Game-Chat, Help, etc.) differently. Since every player receives the same message, the server could translate it once, cache the translated versions, and only send the appropriate cached translation to clients that have translation enabled. That would avoid repeated translation requests for identical messages. You probably thought on this already xD;

Yeah, there is Polly in my C # app. The cache is kept for 10 minutes.

Have you experimented with other translation engines or inference backends that might use less CPU or memory than MarianMT? Maybe something optimized for inference, quantized models, or a different runtime?

Didn't play with it that much; I was testing something before, but I don't remember what it was called. It was using more CPU, sadly.

Another thought: have you considered running the translation service on a separate machine? The game server would simply forward the text, receive the translated result, cache it, and then distribute it to players. That way the game server stays focused on gameplay while the translation workload is isolated.

Yes, and that's why you see two instances of API on my Docker. One is API handled only for client-side things like login, registration, see ranking, cyclopedia etc.

Have you tried measuring where most of the cost actually comes from? Is it mainly model inference, model loading, tokenization, or communication between the server and the translation service?

The first bottleneck here is model cold start. Second is, sadly, the model doing it work. It takes like 20ms to go client > api > model (where the heavy work is) > api > client. Of course, depending on text size, but the difference between 10 characters and 250 is like 5%.

Do you think batching multiple translation requests together would make any noticeable difference, or does the added latency outweigh the benefits?

Didn't test, propably won't make big difference

I'd also be curious to know how much memory each loaded language pair consumes. If several language pairs are active at the same time, is memory or CPU the bigger bottleneck in your experience?

I was keeping it as it is. Loading the model takes a lot of RAM and CPU. It's better to keep it, even IDLE

 

[grilaud]

That makes a lot of sense. If the API roundtrip is around 20ms and the text size barely changes the cost, then the real issue is clearly the model lifecycle and inference, not the communication layer.

Keeping the model loaded also sounds like the right choice. If cold start is one of the biggest bottlenecks, unloading idle models would probably save RAM but make the user experience much worse when someone suddenly needs a translation.

The 10-minute cache is interesting. Have you considered splitting the cache behavior by message type? For example, global channels could keep translations for much longer, since repeated market/game-chat messages are often similar or identical, while private/player messages could use a shorter cache or even no persistent cache.

Do you think language detection adds any meaningful overhead in your setup, or are you already passing the source/target language directly somehow?

Also, are you loading one model per language pair, or do you have a more general multilingual model somewhere in the pipeline? I wonder if a multilingual model would reduce memory usage compared to several separate models, even if the quality or CPU cost might be worse.

Really useful information, thanks. This gives a much clearer idea of where the actual limits are.

 

[Sorky]

The 10-minute cache is interesting. Have you considered splitting the cache behavior by message type? For example, global channels could keep translations for much longer, since repeated market/game-chat messages are often similar or identical, while private/player messages could use a shorter cache or even no persistent cache.

Not really - it would require more programming. I've kept it as PoC and nothing more.

Do you think language detection adds any meaningful overhead in your setup, or are you already passing the source/target language directly somehow?

It is "auto-detect"; I'm only passing the language it needs to be translated into.

Also, are you loading one model per language pair, or do you have a more general multilingual model somewhere in the pipeline? I wonder if a multilingual model would reduce memory usage compared to several separate models, even if the quality or CPU cost might be worse.

Pair. 6 models total. I think they weigh somewhere around 10GB. A multilingual model would be an overshoot for my purpose as im using a limited-disk laptop for my OTS projects. And quality is much better according to ChatGPT

 

[lukatxd]

That's really interesting. :O
Thanks for sharing your experience.

One realy simple idea that came to mind is handling global channels (Trade, Game-Chat, Help, etc.) differently. Since every player receives the same message, the server could translate it once, cache the translated versions, and only send the appropriate cached translation to clients that have translation enabled. That would avoid repeated translation requests for identical messages. You probably thought on this already xD;

Have you experimented with other translation engines or inference backends that might use less CPU or memory than MarianMT? Maybe something optimized for inference, quantized models, or a different runtime?

Another thought: have you considered running the translation service on a separate machine? The game server would simply forward the text, receive the translated result, cache it, and then distribute it to players. That way the game server stays focused on gameplay while the translation workload is isolated.

Have you tried measuring where most of the cost actually comes from? Is it mainly model inference, model loading, tokenization, or communication between the server and the translation service?

Do you think batching multiple translation requests together would make any noticeable difference, or does the added latency outweigh the benefits?

I'd also be curious to know how much memory each loaded language pair consumes. If several language pairs are active at the same time, is memory or CPU the bigger bottleneck in your experience?

I'm really interested in seeing where this idea can go. Real-time translation could make old-school servers much more accessible to players from different countries without changing the original gameplay.

Also, I cached many common phrases in advance to avoid translating redundant things like "hi", "buy bp...", "sell bp...", item names that players are already used to seeing in English (Plate Armor, Crown Armor, MPA, and other common abbreviations).

yea but what if I DONT want translated messages? I've seen what it has done to twitter lmao.