Major ServUO changes coming - Please take the time to review this.

nibbio

Citizen
Aug 12, 2014
16
5
3
Donate
Donate money to this user
Are you planning to rewrite the emulator architecture or only to delete the old code?
Some problems and limitations are related to some architectural aspects, and the language have been evolved since the .NET 2.0 (maybe a migration to .NET Core 3)
 

Tasanar

Admin
ServUO Developer
Oct 16, 2014
4,663
177
63
33
trueuo.com
Shard Name
Heritage
Donate
Donate money to this user
@nibbio got an example of where we can change the architectural aspects?

ServUO is also currently deployed on .net framework 4.8 I believe. We have talked about moving to .net core.
 

nibbio

Citizen
Aug 12, 2014
16
5
3
Donate
Donate money to this user
I am not a game developer but I found few aspects that could be handled differently than now:
  • Async: the emulator was born when the async programming was hard and not common. Now it's almost the standard way in order to use the multicore CPUs. Even in game development where the single threaded programming is often the preferable way to build a game engine (due to its semplicity) there are a bunch of systems that could be moved to the async way (like the network handling or some timed systems that doesn't depend to user interaction)
  • Couling: the emulator was born using the inheritance tecnique in order to define all the entities that interacts into the world. Often it's better to use the composition over inheritance; this allow us to decouple entities aspects and related systems and should be increase the ability to add, modify or remove systems in a "plug-in" way. Vorspire starts to use this pattern through a list of components attached to Mobile and Item main entry points.
  • Core / Scripts separation: this was born from the cloused source period of the emulator and causes some code duplication and workaraund in order to add some functionality in the script project without modifying the core project
I never was on of the "follow OSI publishes" school but I prefer to develop a standard emulator where the mechanic is pluggable and separated from the architecture: the emulator should offer the capacity to inject some mechanics and not include them directly inside itself, but this is only my opinion.

One of the long-lived shard in my country is very distant from the OSI implementation and thanks to this can keep up the user satifaction and curiosity.
 
  • Like
Reactions: cmileto and TheArt