Quote:Original post by Antheus
But perhaps more importantly, emulators and similar software enjoys a luxury more projects never have - the requirements never change. All the assets and design don't nor can change. This leaves a lot of room for optimization.
That is true only when you have completed the emulator and have all the data you need to run it. [wink] Until then, any change the retail game server makes could essentially set you back months in your development cycle. Some games are more server driven than others, so for some games, it will always be the case where you have to constantly update your code to be able to keep developing the emulator. I've actually seen a number of games that have implemented game-changing patches to where any work you'd have done would be rendered useless. Hope that team would have a good risk management plan haha!
Games that are not updated frequently or have reached their end of development cycle are much easier to write emulators for since you do not have to worry about such changes, but from what I've seen in the free mmorpg market, there are not many of those. Older mature stable games are the main exception and more to what I'd agree with your comment on.
Quote:And there's little emphasis or need for data integrity or reliability, or any of back-end features, account and payment system integration, logging, patching and build system, the development time and resource consuming stuff basically.
I respectfully disagree with this point. I've been looking around at others' emulator code on RageZone and was simply appalled by how badly implemented their server code was. The goal of an emulator is not that much different than the goal of the original developers. If the developers ignore the aspects of data integrity or reliability, then their servers will get owned, easily. I would say there is a general lack of understanding overall of those points, but there is an important need for it.
I've seen projects that process single packets at a time (talk about a real bottleneck when you make your code receive one packets worth of data at a time in a TCP stream), have absolutely no memory cleanup (i.e. the project would leak memory so badly it wouldn't be able to run for very long if a lot of players got on), improper sprintf calls coupled with mysql code (just begging for sql injections / buffer overruns), and painstakingly poorly design code to send packets to players (one example I saw would allocate 65kb on the stack N times and compute the packet N times for a send to N clients when only a single stack allocation / packet computation would be needed)
There's just so much to a server that is easily overlooked in these projects that if they were ever able to become a functional server, they would not be able to stay online too long due to how easily exploitable they would be. Retail servers often suffer from the same thing and those are written by "professionals", you can only imagine how an "amateurs" server would be like [lol]. That of course is not to say all emu projects are bad and poorly implemented, because they are not, but I'm talking about a large percentage of them that have opened their code.
My advice would be this. Get something that actually works first, get your emulator going, and only after you have it working should you worry about the "performance" metrics of the core components you are using. From what I've seen personally, most projects do not even get over that hump of getting it all working in the first place, so I think you should worry about a solid core later once you know for sure your project is going to work.
I myself have been working on a C++ based emulator server framework and the network code I feel is solid now, but that in itself was quite a long project and I'm still finding things to fix in it to make it "correct". Using a good solid networking library might be the best approach to handle that aspect on your server. That way, you only have to worry about the server logic, which in itself is a whole other story development wise.
I know the long term effects of my design, it won't be pretty or scale well for a large number of people. However, it allows for very rapid development and takes a unique perspective at how to prototype out a game server. The truth of the matter is, why should I worry about spending a lot of time trying to write an industrial grade architecture that can supports thousands of players, when I can write a much more simple one that can support a few hundred easily and actually have the time to write the emu logic.
When you go and share your project with others, or even if you do not, there are good chances it will be leaked / hacked, so your investment in the 'best' architecture possibly is now lost and in the hands of everyone else. If you write simple, but solid, working code and dedicate on getting things working, then you can go back later on and improve upon the setup to make it better.
Ok, I'm done droning on and on [lol] Just want to say, use what you are most productive with, get it working, and don't worry about performance until you actually have to worry about performance. This is a fun project for yourself and in the process of doing it you will learn a lot, it won't be perfect first few times around.
