Posted in Announcements
by Ron on September 13, 2020
Game Technology


Welcome back Dev Logs!

We have been quiet lately, but we’re happy to say progress is still going strong. The bad news is we don’t have much new visual content to show you yet. The good news is this log will explain why.

Today we’re covering some aspects of the technology behind the game, and how this tech will help us provide an entirely new game experience. We will also touch on a few aspects which make RFC different from any other version of RF Online.

Sometimes you just have to get through the boring parts to help build a foundation that will work as you need it to. Starting off with a bad foundation contributes to a lot of the problems players still see in RF Online 15 years after its initial release. So, needless to say, these parts are pretty critical to the success of our goals.

Let’s jump right in. We’ll try not to bore you too much!

Game Data in MySQL

Traditionally, RF Online game data is stored in the form of binary files on disk. These files have a specific data structure the game utilizes to read and store the data in memory on startup. Editing these files can be quite tedious and time consuming.

In an effort to streamline game data modifications, all game data has been loaded into MySQL. All of our items, classes, skills, item drops, and more, are all now loading from a proper relational database. Gone are our days of utilizing hex editors and other proprietary programs to understand RF game data.

We can now run a few simple queries through MySQL to review and modify any game data on the fly, and the server loads the changes directly from the database! This also helps us out a lot when it comes to streamlining client patch generation and sending updated data to game clients. We will also be able to stream all of this data directly to the website with adding little to no additional overhead, finally providing players with a proper ever-evolving game database which is always in sync with the latest game. This gives us the power to create all kinds of crazy game data features and integrations on the community website.

Why MySQL?

First and foremost, MySQL is portable, lightweight, and very powerful, especially with the introduction of MySQL 8. MySQL may be installed and all features fully utilized without licensing constraints. Documentation is vast and connection drivers for MySQL are widely supported.

Configuration of MySQL is also much more straightforward than configuration of Microsoft SQL Server (MSSQL), which is the database technology used in the original game. Less overhead means a better performing database under load and at scale. More streamlined service configuration means it is easier for us to review database performance and quickly apply optimizations where needed with little to no downtime.

We have a few other significant reasons for choosing MySQL, but we’re saving those for a future dev log. What you should take away from this for now is MySQL is one of the pieces giving us the ability to create game infrastructure which has never been possible before in RF Online. Now, everything is changing, all the way to the database technology empowering the game.

Dynamic Portals

Another drawback of traditional RF is the map data format. Part of the map files includes data which define how portals are loaded in the game. The format of the portals are convoluted and not easily modified, and require quite a few different parts to work together the right way.

A benefit of utilizing MySQL databases is streamlining management of the portal data. Rather than having to locate and modify portal data in an extremely proprietary format, we can simply run MySQL queries to manage portal data. This also allows us to easily stream information regarding portal locations directly to our website to help new players learn the game!

We use a couple database tables to accomplish this. The main database table is our portal table. We use this table to define where portals are located throughout the game. We store a human friendly label along with the map name, coordinates, and race permission data.

The second table we use is called portal links. Portal links allow us to define which portals connect to each other. Through the power of utilizing a relational database, we can link portals using specific portal IDs and define a theoretically unlimited amount of portal links all with a few simple database queries.

We utilize the portal and portal links tables to spawn portal game objects. Where traditional RF uses a local static map data file for the game client to know when and where to load portals, we are able to stream this data directly and dynamically to the client. The game client doesn’t know anything about where portals are located until you approach a defined portal location in a map in the form of a portal game object. The server informs the client of the required portal window data as you approach the portal location, and the player is presented with a list of locations based on dynamic portal links rather than a known local static data file.

Dynamic Portal Management

This unique method of managing portals allows us to not only streamline adding portals into the game, but it also lets us dynamically define portals without needing to restart the server. This opens the possibility of applying portal adjustments in real-time and even creating timed or otherwise limited portals for in-game events.

We can even create a GM command to define and save new portals as we run around in-game, effectively giving us the power to configure the game while playing the game. How cool is that?!

This way of thinking will be applied to other areas of the game as we progress. The flexibility is limitless and we can’t wait to show you what else we have planned which will utilize similar dynamic data formats.

Network Encryption

Security is a big concern for us. I know we say that a lot, but it rings true in everything we are doing. After all, what is the point of providing a game environment if it isn’t secure? If you can’t have confidence in your fair progress versus other players, there isn’t much of a point in playing the game.

You can say “well, I’m having fun anyway”, but at the end of the day, a fair game environment is critical to longevity of a game. Providing confidence in player progress not only retains longer term players, but this helps contribute to a higher quality game which helps inspire confidence in players new to RF Online trying it out for the first time.

One factor of game level security is network encryption. Traditional RF Online sends packets in their raw data form. Packet data may be examined with various packet logging tools as well as hex editors to determine what data is being sent between the server and the client.

All you need to know is the structure of that data, which is easily found in most RF Online server files and has been largely unchanged since release, minus the addition of a few new columns here and there. Cheaters can easily intercept and modify this data to trick the server into thinking something happened, when in reality it could be someone manually modifying that data in unexpected ways. This leads to exploits, and in some cases, server crashes!

There are some protections built into the traditional game logic, but this of course only goes so far. Most games of this era utilize a basic XOR cipher method, but RF didn’t even do this. Instead the packets are left wide open for anyone to view, and in some cases, easily capture and resend. One can argue C++ developers of the late 90’s didn’t have the foresight to really be aware of the massive hacking potential and capability of players, but this turned into an incredibly huge mistake in the game’s design regardless.

Solving Network Security

All network traffic for our renewed game is encrypted through a specific algorithm as well as a dynamic key exchange. Feel free to utilize packet logging utilities in similar ways as traditional RF. You can try, but you won’t be getting very far as you will only see gibberish data. On top of this, we are implementing additional security measures in the core network communication which will prevent re-sending of packets.

This doesn’t block all cheat possibilities in RF, but it definitely takes us a large step forward. The best anti-cheat capability utilizes a combination of different solutions. This is only the first step we are taking in providing you with a more secure and confident gameplay experience.

Next Generation Lobby

If you’ve made it this far, firstly I would like to just say “thank you”. The team is putting in a lot of hard work, and the fact even a subset of players are interested in the more technical aspects is exciting to us. We love talking tech and we love even more that players are interested in following the boring details.

That being said, it’s time to show you something a little more exciting. Welcome to the first visual you will see when starting the game for the first time!

New Lobby


Why Change the Lobby?

I can’t think of any players who have come to us and said they hate the original lobby. The RF lobby for its time was incredibly unique and beautiful. Sadly, they ran with this a little too long, and the result is a game lobby which hasn’t changed in over 15 years.

While the traditional lobby is beautiful and timeless, this ended up feeling very stagnant to us. Providing an entirely new feel is essential. We want players to embark on a new experience in every aspect of the game. We determined this includes the lobby and character selection experience, so we made a very ambitious decision to change what you see when entering the game.

Not only will this allow us to refresh the game entry experience, changing the lobby allows us more flexibility when it comes to the character limit. The existing lobby is largely designed around three character slots. Introducing a new lobby will let us play with the possibility of more cleanly extending available character slots.

An Evolving Lobby

Going a little into the future here, we also made the decision to provide a more dynamic lobby. We want the lobby to evolve and grow as the game evolves. Some games follow a model of changing the login screen throughout new expansions…

While we like that idea, we want the lobby to be more dynamic throughout the game life. We’ll save any more spoilers and let the game speak for itself as players are able to enter for the first time.

Monster Density

The fun this period didn’t stop there. We can’t go too into detail yet, but we are certainly already deep into exploring what is required to optimize graphics and rendering. One fun test we use to pull this off is spawning large amounts of monsters on screen.

Flems at a Distance Flem Swarm Monster Swarm


While it is a trivial test, it does provide us some basic benchmark data without requiring many player characters on screen. More data sets to compare to is what helps us confirm the changes we are making are improvements and are not impacting the game in negative ways. So while some data sets may be trivial, we still obtain incredibly useful information from these types of tests.

Where is the Transport Ship?

If you’re not on Discord, you probably missed Adroit, a community member, spotting the lack of a transport ship in Bellato HQ.

Nice spot! You’re right on the money.

Bellato HQ Transport Ship


Lack of the transport ship ties in with how we will be introducing the game during alpha. We are re-growing the game from its roots and we want to bring players along through that experience. Certain “missing features” don’t exactly mean they aren’t ready yet. Perhaps those features are missing on purpose...

Another community member and developer in the RF scene, jdag, chimed into the discussion with other subtle changes he noticed. We won’t be spoiling those. You’ll just have to join us on Discord and see for yourself!

Beauty in the Details

Take note that every screenshot we release is very planned and coordinated. We’re letting some unexplained easter eggs slip through intentionally, so pay close attention! If you didn’t catch the one within this dev log, scroll back up and take a closer look at those screenshots!

Feature Requests & Community Activity

Thanks to everyone who has submitted, voted on, and replied to feature requests! The community has such amazing ideas, some of which even line up with our own vision. While it is still too early to talk about the possibility of implementation of various ideas, we are paying very close attention to all discussions.

To date, the community has submitted 47 total feature requests with 88 votes spread across them. You have also replied to feature requests 78 times, and those replies have a total of 21 votes.

We are up to 89 registered game accounts with 162 members on Discord. That’s not bad considering all our website has available is an ambiguous feature request system with little content about the game itself! Players are still a little confused about the scope of the project and that is completely understandable. Combine this with infrequent updates and you don’t exactly have a recipe for a thriving community quite yet.

More features will come into the website over time to give players more of a reason and incentive to join, but we ultimately don’t expect to see crazy activity until the alpha test phase. Special thanks to everyone who has made the decision to join the community in this extremely early stage.

That being said, various incentives will be available over time for website registered members. Your registration date will also be shown on future public community profiles. So if you want to feel that “old school cool”, register now to secure your spot as some of our original and oldest community members!

We hope you enjoyed the log! Thanks for your patience as we continue to work through game development. As we progress through finalizing all of the boring stuff, upcoming dev logs will become much more visual and much more frequent.

Thanks to everyone for your support so far. We can’t do this without you.