Quote:
Originally Posted by alexander337
Thank you so much for the advice and I'm a noob in programming but not completely clueless about it , but I'm not gonna say I'm capable of creating a full system on my own but i can read and edit a few parts of the code i can also search for hrlp or solutions etc but I'm nit an advanced programmer that's why i used the ai and asked in here for people who can help me , so far i figured out how the old official server files work they didn't hardcoded everything into the files but rather made the server files heavily dependent on the database and producers and that's the same i did but with the latest updated codes and tools to make it more advanced and more improved and also faster also the lua script for thr events and quests etc are eliminated i created a producer that fatch quest info from a table like the lua script and another for events so this will allow for much more customization in those parts , did the same for all cool downs including potions since you can't modify that timer easily, also i made the ai create and admin panel that can literally control everything in the database and the emulator easily with auto generate scrools potions weapons and quests abd almost everything else with 1 click so yeah im just refining the last pits and i will open a game to test how it goes ,but i need the experts opinion on a lot of things also i used a lot of logics and functions from esro/ZelosKSROV1710 and go-sro and other emulators to make it work hopefully it will...
|
thank you for explaining your project in more detail. From what you described, it seems that you already understand one of the most important principles behind old Silkroad server files: the game server itself is only the core logic, while most of the game content is driven by the database.
in official server files, many systems such as NPCs, shops, quests, skills, events, and even some gameplay rules are not hardcoded directly into the source code. Instead, the server loads and processes data from SQL tables during runtime. This approach makes customization much easier without recompiling the server every time.
what you are doing by replacing Lua scripts with database-driven producers is actually a very common design pattern in modern game servers. As long as the architecture is clean and the producers only handle data loading while the game server handles the actual game logic, it can become very powerful and flexible.
a game server generally works with the database in three layers:
1. Data Layer:
Responsible for reading and writing information from SQL Server (characters, items, quests, cooldowns, events, etc.).
2. game Logic Layer:
Processes all gameplay rules such as combat, movement, AI, quest progression, damage calculation, and validations.
3. network Layer:
Handles packet communication between the client and the server.
The database should store data and configurations, while the game server should execute the rules and validations. Keeping these responsibilities separated will make the emulator easier to maintain and much faster.
using references from projects like eSRO, ZelosKSRO, and go-sro is also a good approach because every emulator solved different problems. The difficult part is integrating those ideas into a consistent architecture.
from what you described, you're already beyond the beginner stage. The best thing now is extensive testing: stress tests, packet validation, memory usage checks, concurrency tests, exploit prevention, and performance profiling. These are usually the areas where private server emulators succeed or fail.
i would be interested to see how your architecture handles things like multi-threading, packet security, AI processing, and large-scale events once you begin testing.
if you'd like, feel free to send me the project or some parts of it. I'd be happy to take a look and share my thoughts. No problem at all. Sometimes having another developer review the architecture can help identify potential improvements or issues before testing.