Jump to content
  • Create an account or sign in to use the shoutbox

    You need to be a member in order to be able to chat with other users.

Sign in to follow this  
twostars

Our server

Recommended Posts

Unlike other servers, we've put a lot of work into our server -- several years worth, in fact. Actually, I can safely say that we're the reason that most people are even using source code to develop servers now, rather than messing with the official binaries.

This is why I'd like to go into some detail about our server, since it's not something that's usually talked about outside of bug reports and such.

A brief history

Our server was initially created as a result of our attempts to push open source development in the Knight Online community, in 2012~2013.

The project's intent was to update the official C++ source files (for ~1.06x) to a usable state for community learning purposes.

Although the project ultimately went closed source due to lack of community attention, in the years since then we've made leaps and bounds with the project, rewriting most systems from the ground up to behave in a more logical and optimised fashion, doing our best to respect both DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) principles, as well as updating to support the latest version of Knight Online (2.1xx at the time of writing).

It has been a monumental undertaking, but in doing so, we've learned a lot about how the official server works (and even more about how it doesn't), and have always striven to improve upon it (as well as our own implementation).

Accuracy

While we do deviate in some regards (with good intentions), accuracy is very important to us.

We have spent a great deal of time reversing official server and client binaries, as well as testing behaviour on official and scouring through its packet logs.

As-is, we're confident that in most respects that have any importance (e.g. damage calculations, rates, etc.) our implementations behave the same as (or very, very close to) official's.

Cheat detection

While official and 99% of private servers rely on client checks to detect cheating, we do not believe in playing this easily-bypassable game of cat and mouse. As such, our server is very proactive in its detection of cheat methods to lock them down permanently, i.e. with no means of bypass.

From ensuring we deal with client input in a safe manner to things like verifying every step of the skill casting process, or enforcing tight server-side collision and movement speed checks, we always strive to ensure that players have no vector for abuse. Obviously this is always a work-in-progress and isn't perfect or complete (what is?), and we're introducing new logic to prevent more general cheating behaviour as it pops up, but we're proud of how far we've come - and that we've come so far compared to official (and other private servers) in this regard.

Performance

Aesteris and I have both put years into developing this server (and I'm sure there's many more to come), and at this point I'm confident in saying our server performs - in most respects - better than official. On this note, we've found that many official bugs are caused by design flaws or simply their tendency to copy & paste their logic (and miss things).

During implementation, we are always ever-present of performance concerns, be it in regards to how much time/resources a player request can consume (or anything in general), how costly a database hit will be, or even how much data is being (unnecessarily) sent to players -- performance matters to us, because it matters to players. A server falling under its own weight isn't worth playing.

Zone instances are one interesting example of this. Officially and in 99% of private servers, "instances" are implemented such that when dealing with anyone in an instance, it still has to deal with all players in that zone (i.e. all instances of that zone). So instead of the 16 people we want to deal with in our Border Defense War instance, we deal with the 200 players across all of them.

Here, we implement this system fairly logically: each instance is a self-contained unit attached to a zone. When dealing with players (or NPCs/monsters for that matter) in these instances, we only ever deal with the 16 actually in it.

Similarly, officially we've noticed they tend to scan the entire server when looking for players to affect with skills nearby. As always, this extends to private servers as well, though most will have this (slightly) optimised from when this was open source. Here, of course, we only ever look for those actually near the player.

This extends even to our database implementation. Beyond optimising the database design to avoid unnecessary or overly intensive lookups, we've also moved away from Microsoft SQL Server as - while it's a decent product - in several situations, it doesn't fit our performance needs (we also mostly moved away from Windows in general, which was another reason for dropping it).

While not all are, many of our performance improvements are entirely noticeable by players. For example: unlike official or other private servers, there is close to no delay in logging in and selecting your character (the only delay is your own connection latency; officially and on other private servers, these backend requests take quite some time themselves). Additionally, we optimise our outgoing traffic to avoid congestion on the player side -- which saves you (and us) bandwidth, and means the client isn't bogged down as much processing the traffic.

Events (and timing)

Although fairly common with most of our systems, I feel that our event system (in no small part because of our timed event system) should be pointed out in particular as it is a colossal improvement over the way official implements events (as well as other private servers).

Officially (and again, other private servers -- these go hand in hand), events are scheduled based on specific time checks. That is, if an event is scheduled at 01/02/2017 12:30PM, their game timer will check (every 6 seconds) if the current time matches. That is, it'll check if the day is 1, month is 2, year is 2017, hour is 12 and minutes are 30. Every 6 seconds.

This means that issues with clock changes can easily upset it, not to mention issues with restarts not realising it has yet to run even though the time has passed (because it isn't exactly that time!).

Here, we have a scheduler for timed events. Times scheduled in the past will run immediately, while times in the future will run once that time has passed. As always, we're ever-present of performance concerns, and scheduling in this manner can be very sensitive performance-wise, but in its present state our scheduling system performs wonderfully.

Virtually everything timing-related in our server runs via this system in 1 of 2 ways (again, for performance reasons): in a "precise" mode, where we require a higher granularity (e.g. skill timings), or in a general mode for everything else that matters a lot less (e.g. event scheduling).

From scheduling to running parts of the events, timing is very important with events.

As I've mentioned previously, our implementations aim to behave logically. We also aim to keep features as self-contained as possible, unlike official, where you have random logic strewn about that exists that doesn't have an obvious use until you determine it's for, say, a specific case in an event.

Obviously, when your codebase is littered with random things like this, it's very difficult to maintain, and very prone to bugs. We're all familiar with the bugginess of Knight Online; official servers, particularly. This is why.

In contrast, we keep all of our event logic with the rest of that event's logic. And I don't mean just keeping it in the same source files.

I mean, as a common example, if we need to handle the death of a player or monster in this event, we implement a specialized zone instance class for this event's instance, and override its OnDeath() event. Meaning, it's only ever handled in this event by design and no other logic needs to be aware of it.

As previously said: we aim to implement things logically, in an attempt to keep things readily maintainable and avoid bugs.

Custom behaviour

While accuracy is important to us, so is an improved player experience.

For starters, we're perfectly comfortable with taking features and reworking them into something that can be of use. For example: our in-game Class Transfer feature. This feature doesn't exist officially; it uses the official Nation Transfer feature to accomplish this, as the UI provides the ability to change their desired features -- which is the only time a player needs to make a decision (beyond their desired class, which we accomplish by prompting for that in the NPC -- easy!).

Another example of this is taking their event system and reimplementing the Forgotten Temple and Juraid Mountain events to work with it, so players can now simply use the sign-up feature to access this event, rather than finding and talking to their respective NPCs. This means a much nicer user experience and increased participation to the events.

And how about our clan banks? Their inn UI was easily repurposed for this custom feature that again, does not exist officially. ^_^

And to finish this off...

It's very easy to see this as "another server", but you need to realise that everything implemented in the game -- everything! -- has been written by us, at this point, from scratch. At the beginning of this project (which if memory serves was aiming to get it up and running with 1.8xx), we didn't have things like merchanting, we didn't have upgrades, let alone any type of event (even old events like Forgotten Temple or Bifrost). For a while I personally didn't really think we'd end up getting it anywhere, but continued to work on it in my spare time regardless.

Now we have a fully-featured, highly optimised server implementing almost everything official has to offer.

We've come a very, very long way in this time. We have more work to do (as always), but I hope this at least gives a small glimpse into what's actually involved behind-the-scenes in actual server development and why we're different to other servers. :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×