Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

[OpenSource][C#] Nostale Private Server Emulator - Plugins - Microservices - Docker

Status
Not open for further replies.
Newbie Spellweaver
Joined
Aug 28, 2017
Messages
13
Reaction score
2
Hi,

I'd like to present you my project, SaltyEmu.

First of all, this thread is designed to people that are really interested in it.
If you just wanna trashtalk, leave the thread, it's pointless.
We are open to criticism as long as it will help the project growing.


Nothing you can compare to OpenNos or NosCore or any existing Emulator here, my project is totally different from those from goals to implementation.


My goals :

  • Bring a new eye on Nostale Private Server scene.
  • Improving my software designing skills & implementation skills
  • Help the real servers being highlighted by their work and remove all those crappy drag & drop servers that are designed to make money on opensource developer's work.


LINK : https://github.com/BlowaXD/SaltyEmu
Discord : https://discord.gg/7sTFU8d

How does SaltyEmu work ?
/*
A lot of better documentation incoming
*/
Actually, most of the packets are converted into abstracted events that will go through the event pipeline.
As well, there are a lot of micro services you can easily access to manage a lot of things (Sessions around the network, static data (.dat), instanciated data...)


The event pipeline is divided in two big parts :
- EventChecker : Filters event, based on checks, if a requirement check fails, the event is dropped from the pipeline
- EventHandlers : Handles the event, does the expected processing for the given event (like broadcasting a packet on a maplayer, adding item in an inventory...)

You can add as much handlers / checkers as you want to for 1 single event, through dynamically loaded plugins (stored in dynamic libs aka .dll)

Example :
A player send a "chat message"
It's converted to a ChatMessageEvent (we try as much as possible to factorize our code base)
ChatMessageEvent goes in every EventCheckers of the pipeline

Advantages of this architecture :
- Extreme pluggability (you can change the handling of an event during server's runtime)
- Easy Load Balancing (you can easily make one TCP listener that will throw event to handlers in a distributed software)

What we got so far :
- Command Framework (SaltyEmu.Commands)
- RPC Framework (MQTT / AQMP)
- Family (MicroService)
- Friends / Blocked (Micro service)
- Multi channel
- Chat System
- Monsters & NPC's AI
- Battle
- NpcDialogs (still need to implement a lot of specific handling but really easy to add those)
- Guri Handling (same as NpcDialogs)
- Item Usage (same as NpcDialogs)
- Player Walking
- Shops
- Inventory
- Commands
- Items
- Portals
- Skills
- Specialists
- Groups
- Buffs
- Heavy documentation

What we will work on :
- NosBazaar
- More documentation as there is already
- More tests (we try to handle the maximum of scenarios we can)
- Pets / Partners
- Scripting Instances (probably LUA or C# scripting)


PS : This is not a PoC, it has been running on our side since some months now, we reached a point where we'd like to have some external feedback.
 
Joined
Feb 26, 2010
Messages
1,388
Reaction score
784
Why in Gods good name did you implement Event sourcing for an online game. Are you storing them ?!

EDIT: Docker but Dockerfile is in dockerignore ?_?

Seems like the tech was picked here based on buzzwords and not usefulness.
 
Last edited:
Newbie Spellweaver
Joined
Aug 28, 2017
Messages
13
Reaction score
2
Why in Gods good name did you implement Event sourcing for an online game. Are you storing them ?!

EDIT: Docker but Dockerfile is in dockerignore ?_?

Seems like the tech was picked here based on buzzwords and not usefulness.

1/ It's my architectural choice, if you have any better idea, you could give some feedback, I'm still studying and learning but without constructive criticism I can not do what I can not see. And actually, even sourcing fits for my "modularity & pluggability needs"
Btw, the goal of event sourcing in my case is to, at final state of the emu, queue events and workers handles the events.

2/ Yeah, why would I include Dockerfile inside the container's image ?
All the dockerfiles are in scripts/docker, not at the root directory.
 
Joined
Feb 26, 2010
Messages
1,388
Reaction score
784
1/ It's my architectural choice, if you have any better idea, you could give some feedback, I'm still studying and learning but without constructive criticism I can not do what I can not see. And actually, even sourcing fits for my "modularity & pluggability needs"
Btw, the goal of event sourcing in my case is to, at final state of the emu, queue events and workers handles the events.

2/ Yeah, why would I include Dockerfile inside the container's image ?
All the dockerfiles are in scripts/docker, not at the root directory.

The point of event sourcing is to have the ability to switch to any data storage choice u want, based on the events u stored so far, or restore a log of actions from them, as such, the event log is absolute and must be trusted, this is good for a service with big important actions. Not a pserver spammed by players packets, they lose their use if you strip that away. And you can create a packet queue just as well.
 
Newbie Spellweaver
Joined
Aug 28, 2017
Messages
13
Reaction score
2
The point of event sourcing is to have the ability to switch to any data storage choice u want, based on the events u stored so far, or restore a log of actions from them, as such, the event log is absolute and must be trusted, this is good for a service with big important actions. Not a pserver spammed by players packets, they lose their use if you strip that away. And you can create a packet queue just as well.

The point of event sourcing is not only to have the ability to change your data storage, but also to unify the event sources.
If
- I'd like to change the protocol (change packets to another completely different way to serialize packets and have different datas inside) or - I'd like to interact as a "sudo" user (GM controlling a remote user) or - I'd like to use mobile app to interact with my game in real time or - I'd like to use console commands or another type of source for my events

I can use all that with events and just transform my command to an already existing event for a packet or a player interaction.
(If you took a look, I'm using plugins, people can add their own way to interact with the game without only using the game client's protocol)

But I'm not designing my software to be a simple "pserver spammed by player packets" software.
Also, you didn't take a look to Nostale's protocol, otherwise, you would definitely agree on changing the protocol, which is actually terribly designed and not optimized for transmission. (While events i'm using are a way much lighter)
 
Status
Not open for further replies.
Back
Top