im so excited for this project. Great work trying to bring this back.
Is there documentation on the structure of the server (or the design you have decided to go for) and the packets the client needs and the flow of (say) talking to a contact, getting a mission, spawning and entering an instance, fighting bosses etc. or do we have to dig through the code?
I havnt had much of a chance to look at the source/design but id just like to add a few decades of hard fought and foolishly gain experience and suggest:
1) dont optimise prematurely (it just adds complexity and most of the time you dont end up optimising the bit you really needed optimal)
2) dont build a monolithic server app (just write something that does the minimum packet work required to talk to the client and the smallest amount of game logic and boots as much as possible to other 'modules' which do the work)
You are stuck with a client that you cant change so it seems to me, your server should be the smallest server you can manage and it should push all the more complex work off to other services (either via network connections/dll loading or any other method).
Id be assuming that your server is going to have to manage player movement, npc updates, combat/damage tracking, triggering effects, effects timing, map collision.
Stuff that id (personally) just write an remote interface for (which will be mostly based on the needs of the client for info and what the server has to track to provide that) would be things like: auth, villian spawns, trades, inventory control, missions etc. The missions for example, the server triggers the mission service when a player clicks a contact, the mission server works out the contact, talks to the player store (also by a defined interface) to work out where they are upto, and sends back to the server a message saying "put up this text 'xyz' with options 'abc', 'def'", the server then triggers the client to do that and hands back the players choices, the mission server then sends the mission info to the server in terms of where the instance is etc (Im making assumptions about what the client needs here). The server shouldnt be doing sql requests itself, it should hand it off to a service to do it (which can later be replaced by a pool of workers if needed or moved to another machine etc)
Doing it this way lets you break all the mission code out from the server so the mission-dev team can write the mission server in whatever language they want and they dont have to deal with *any* server stuff at all, except for the defined flow of a request through the interfaces that you design. It simplifies both the mission server and the main server. The mission-dev team could then work on missions without the server at all by just writing a simple front end to allow testing (click contact xyz, shows text, takes replies, prints out map and spawn info, asks for a mission result (done/timed out/failed) then generates the resultant message to the player. You can then develop that mission service without needing a working server to spawn monsters or map instances so when the server *can* do that stuff the mission service is ready.
You could even split the main server into a 'per player' server which talks to all a server for each area and any spawned for instances (which is how i assume the real one did it). IPC does add a lot of overhead but it makes more testable platform with more simple components.
(If you want further pointers on this then look up the unix philosophy https://en.wikipedia.org/wiki/Unix_philosophy or things like this rant on amazon vs google services (as a platform) https://plus.google.com/+RipRowan/posts ... 3678331987 )
re client api, i did find this viewtopic.php?f=10&t=8031
but i guess im asking is there any better docs or info on the flow of these requests or is it still being discovered by trial and error?
Here we speak about Code and Design.
2 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest