# What is the cost of commercial MMO libraries ?

This topic is 3789 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Id love to hear about currently available MMO libraries and what is their cost / licensing price. Im looking for something small-scale - 2000 players at most (if I ever manage to get that many people tied to my game, that is). My goal would be to reach 1000-2000 subscribers, so Id guess that the maximum actual number of players [at any time] would be around 700. Im planning on "adding" the MMO component into my own 3D engine (C++ and DirectX), that Ive been developing over the course of last ~6 years. I definitely dont plan on writing the networking component from scratch. Id rather buy one, if it was affordable. Ive gone through the hell during developing of my engine, so Id rather avoid this hell with the MMO component. Unfortunately, since the full single-player game (that I already made and am in search for potential distributors) is RPG (quests/statistics/Inventory handling/Upgrading players characteristics), the MMO game in question would therefore have to be - MMORPG. I think I know what youre thinking about right now, but please understand that Im not willing to scrap the whole codebase, just because there are hundreds of MMORPGs out there. Ill rather reuse/refactor any code that I have [from the single-player gameplay] than spend another year creating a different type of game that would transfer well into MMO (gameplay-wise). Also, I assume it will affect the choice of the MMO library, if I mention that my engine streams the terrain (no levels), and I have about ~3 km visibility currently (though plan on raising this value to at least 5-6 km, with whole terrain being at least 16x16 km). So, it should be able to cope well with 500-1000 players at once (e.g. autonomly deciding what info to send depending on distance from player), since its very probable that those 500-1000 players will be in nearby area of the player. Also, if you know that some library should be finished by early 2008, Id love to hear that too - so I can put it into my bookmarks and check back later.

##### Share on other sites
The only one I honestly know of is HeroEngine.

www.heroengine.net

##### Share on other sites
Thanks, however I see 2 problems with it:
1. Bioware uses it, so it must be extremely expensive - I assume easily >$100k 2. Its a complete environment, where MMO component is just a small feature; I already have my own 3D engine / tools pipeline and dont need those. Besides, their MMO component shall be tied to their engine/tools (since theyre selling whole package) and I need something that is general so I can plug it into my own engine. Either way, Thanks for idea and if you have any other, just post it here ;-) #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by joe1024where MMO component is just a small feature You're joking right? The "MMO component" is a huge, massive, incredibly complex feature. It's so massive, in fact, that you can't just plug a 3D engine into something and make it an MMO; the entire engine has to be written specifically to make the "MMO component" work correctly. How your objects are created, architected, stored, etc; everything is about making it feasible in an MMO. Perhaps you are just talking about a "multiplayer component". i.e. 16-64 players online (instead of MMO which means thousands of people online in a persistent world) -me #### Share this post ##### Link to post ##### Share on other sites I think that you will find Sun's Project Darkstar interesting. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by AhnfeltI think that you will find Sun's Project Darkstar interesting. Darkstar is untested on anything but a few small multiplayer games. Quote:  visibility currently (though plan on raising this value to at least 5-6 km, with whole terrain being at least 16x16 km). The visibility tests are better performed the other way round - you determine how far an object is visible. This is done so that a large tower will be sent to client sooner than a tiny mouse. Quote:  Im planning on "adding" the MMO component into my own 3D engine (C++ and DirectX), that Ive been developing over the course of last ~6 years. The problem with MMO is that client is just a dumb terminal that does some rendering. It's the "small MMO component" that makes things difficult. Things work the same when you have small number of players. But when you start considering the size of a seamless world MMO, things change a lot. Client is just a renderer that doesn't do anything interesting outside of displaying and animating models. Everything else happens on server. Quote:  Unfortunately, since the full single-player game (that I already made and am in search for potential distributors) is RPG (quests/statistics/Inventory handling/Upgrading players characteristics) You'll need to move all of that from client completely on server, so that client doesn't know a single thing about logic. Otherwise, your game state will be hacked in 3 minutes. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by PalidineThe "MMO component" is a huge, massive, incredibly complex feature I was referring to "small feature" in regards to being just one feature of their solution. Have you been to their site and downloaded the PDF ? Theyre offering whole engine and the complete infrastructure around MMO games (or at least thats what it seems to be from first reading). If you took the time to read my first post in full, youd understand that I am well aware of what goes into MMO programming (namely from books like "Massively Multiplayer Game Development"). Im just looking for available alternatives. Quote:  Original post by Palidinethe entire engine has to be written specifically to make the "MMO component" work correctly. I already said that Ill be refactoring/rewriting whatever is necessary. Of course, Im not that naive that I would think that just buying some MMO library solves the problem ! But if I wrote all that into first post, it would be 10 pages long and no one would read it. Whats more funny, its less than one page and you didnt read it either, just took the sentences out of the context. Quote:  Original post by PalidinePerhaps you are just talking about a "multiplayer component". i.e. 16-64 players online (instead of MMO which means thousands of people online in a persistent world) How many times have I said in my first post the actual numbers of players ? Its even in first sentence ! So, you didnt bother to read just first sentence of my post, yet somehow it seems OK to you to attack me ? Hmmmm.... #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by AntheusThe problem with MMO is that client is just a dumb terminal that does some rendering. It's the "small MMO component" that makes things difficult.Client is just a renderer that doesn't do anything interesting outside of displaying and animating models. Everything else happens on server.You'll need to move all of that from client completely on server, so that client doesn't know a single thing about logic. Otherwise, your game state will be hacked in 3 minutes. Considering the low number of players in question (~700 at any time, up to 2000 max), would it be extremely risky to let clients handle game logic ? I mean, how many hackers is my game going to attract ? Those few could be handled manually (by IP/user name), probably. Id rather let each client handle game logic, if possible. #### Share this post ##### Link to post ##### Share on other sites Quote:  I already said that Ill be refactoring/rewriting whatever is necessary. Of course, Im not that naive that I would think that just buying some MMO library solves the problem !But if I wrote all that into first post, it would be 10 pages long and no one would read it.Whats more funny, its less than one page and you didnt read it either, just took the sentences out of the context. You're missing the point. Design of MMO logic and the environment will usually be completely different from that of client-side games. The tools that Hero engine provides are designed to do exactly that - starting with object definitions. There are 3 budget libraries (should be listed in FAQ): Turbine, Multiverse, and NEL. Multiverse isn't proven yet, other two have real games running. Multiverse is effectively free. But if you look at it, you'll find it's written in Java/Python hybrid, and is completely publisher/subscriber oriented with custom messaging solution. So re-factoring isn't just patching a bit of client logic, but rewriting it completely, including entire world design to fit with their world model. Other two have similar constraints. Part of the problem here is seamless world. There aren't really any games out there that would have that. Just about all are zoned with very tight constraints on world sizes (512mx512m, for example, with player knowing about 9 zones max). Zoned games support several thousand players on a cluster - but only 100-200 per zone, since they run single-client mode on server. Truly scalable solutions are such as BigWorld (bigworldtech.com), or OLIVE (forterrainc.com). But those too are middleware. Quote:  Considering the low number of players in question (~700 at any time, up to 2000 max), would it be extremely risky to let clients handle game logic ? I mean, how many hackers is my game going to attract ? Those few could be handled manually (by IP/user name), probably.Id rather let each client handle game logic, if possible. Um.... Um... No.... Period. 700 players max isn't small. 2-4 players is small. Anything above 100 is HUGE. And the degree of security you need in such worlds is incredible. 500 in same area is considered unmanagable (including WoW, around 100 players per zone, around 3000 per entire cluster). You'd be surprised how insanely hard problems get once you get to that level. And truly scalable world with even basic physics involving over 500 players is still mostly unreachable for all practical purposes. For online games, not a single byte of logic may reside on client-side. Then there's other problems - DoS attacks, deliberate crash attacks, item duping, peer harrasment, flooding, sniffing for remote information and other clients, and more, including account theft. Then there's database integrity problems, crashes, and thousand more problems. Even if your server is responsible for everything, you're still facing insanely huge problems. To date, no general purpose (general audience) peer-to-peer MMO has been developed, despite a lot of effort. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by joe1024Considering the low number of players in question (~700 at any time, up to 2000 max), would it be extremely risky to let clients handle game logic ? Yes. If you trust the client with anything at all, you are asking for your game to get hacked. As Antheus stated, your client shouldn't do anything but render the scene, and gather input to send to the server (even this has to be done carefully. You shouldn't tell the server what the user had just input, but rather ask the server if a particular input was valid). Quote:  I mean, how many hackers is my game going to attract ? Those few could be handled manually (by IP/user name), probably.Id rather let each client handle game logic, if possible. How many hackers does it take to ruin the game? If there are any PvP aspects, just one would be enough. Even in just a PvM MMO, a small group of hackers could easily trash the economy and make the game considerably less fun for your users. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by joe1024Id rather let each client handle game logic, if possible. Well, conceivably, if you wanted to ignore security concerns, you could have each client handle the player logic (i.e. each client is the authorotative source for where the player is). However, having the server simulate everything isn't completely about security. It also can make your life a little easier for certain things: World logic like Mob AI has to be centrally driven. Otherwise 2 clients could very easily report 2 different positions and behaviors for a given mob. In that case you can't resolve which represents the "true" game state; your clients then de-sync, and the game ends. Similar consistency problems exist for things like: loot pickup, item trading, etc. That aside, even with the clients being authoritative over their respective users, you still need to store all that information on the server. 1,000 clients can't do P2P information transfer without latency death and isn't convenient anyway because of NATs and firewalls. So you'll at least need to re-architect enough so that clients report data to the server and then also query the server for other user information. In other words, you'll probably need to re-architect to the point where only the local user is authoritative to the client and the server is storing the full world-state. At that point, the only game logic the client is in charge of is it's local user. Once you're at that point you're not really saving much refactoring time by having the client simulate the player and meanwhile you're opening yourself up to that one user who's going to ruin the game for everyone else. -me #### Share this post ##### Link to post ##### Share on other sites Realistically - what are the chances that of those 1000-2000 people there will be somebody willing to loose time creating troubles ? This is not going to have publicity of WoW or Everquest. Id dare to say, that getting 1000 subscribers will be almost unreachable goal. Plus, it would have to be actual competent hacker to be able to dissasemble the game code and bypass any security checks. And even if he would manage to change his stats (or whatever), the server would still have to validate the changes to store them. There would be double checks to make sure, that unrealistic advancements arent approved. And good luck getting to my server and changing the data there. Seems pretty absurd for an indie MMO to get such an attention. Either way, if its true that there arent any PvP libraries (with authentication through central server), then I have to let the server handle everything, thus go the "zone" route and forget everything I said above. #### Share this post ##### Link to post ##### Share on other sites If you give the clients any athority, I don't have to be a "hacker" to cause huge problems in the game. Since you are now writing the same logic into both the client and server, you just have to screw up one validation check on either end, and then whoops, by moving items around right i trick the server into letting me doupe items. Or, i drink some stat boost potions, and disconnect but you forgot to keep simulating state on your end, so when I relog in and dont tell you that the potions wore off, the server never removes my stat bonus. The point is that the logic doesn't belong anywhere where random chance can cause something to happen to you. The point is that, no "one" hacker doesn't mean anything, but people are greedy, and when they find out about little tricks you can do without effort you will see everyone "hacking". Since you are intent on keeping your current engine, you would probably be best served by getting a copy of some freeware MMO type engine, and either ripping out the code you need (prolly not going to work well) or using their code base as a learning tool to show you what code you need to write into your game. There are 3 main things that you are going to run into issues with: 1) "Atomic transactions" - All your game logic needs to take place as a set of "atomic" state changes, so you can roll back lost packets and invalid command chains. It also means that you probably need to tag everything in the game with unique ID's when it gets created so as to stop douping and other such issues. 2) "MMO" - You need LOTS of processing power and LOTS of bandwidth. Probably meaning multithreading your game logic on some level. Figuring out what objects REALLY need updates, and which ones noone is going to even see, so dont bother with em. 3) "Steep Bugs" - Your server is going to be up a LONG time. Things that may not cauze errors in a singleplayer game you run for a few hours may just start to show up when you let the game 'steep' for a while. This is things like integer overflows, floatingpoint error buildup, memory leaks, memory fragmentation, and missing logic. I dont think anyone here is trying to say "NOOOOOooo dont do it!" to you. We are just trying to get the point across that there is no "MMO componet" that you can just plug in. There is LOTS of logic behind the scenes that is directly tied to everything else. You probably can use your 3d engine, and game logic, but you also have to think that everything you have will need some refactoring. #### Share this post ##### Link to post ##### Share on other sites 3km visibility (radius or diameter??) is a substantial part of the world (16x16) and you might consider having the Client permanently cache to disk and better keeping it entirely in memory (as its getting cheaper...). It could still be streamed (initially anyway) but caching the parts that dont change (terrain mesh/textures/models, prop objects...) would free up bandwidth (parts that change could be delta patched along with the more dynamic bits that are constantly updated). Once the player had been in all parts of the world, then the static parts would no longer have to be streamed (and there may be substantially more dynamic parts which WILL require that bandwidth). As for trying to use a commercial Server component when you already have your own game mechanics, entity mechanisms and client rendering etc.., you will face massive rebuilding to adapt your system to the existing MMO mechanisms (which usually already have their mechanisms specificly integrated). The Seamless aspect would likely decrease the candidates and increase the price (the difficulty is why most/many commercial MMO games stick to the bubble zone nodes...) Some may advertise seamless as a feature, but it may not work very well inder real use. Someone mentioned Python scripts to be use for servers (logic..). I couldnt think of anything slower to use when server performance/resources are most needed/at a premium. More intricate game mnechanics and more interactivity (multitudes of simple reactive objects -- not just better AI) continues to expand the need for server processing power so that you cannot just assume that Moore's Law will compensate. I would think that the testing process done on a MMO's scripts would need to be quite rigorous/controlled and thus invalidate most of the reasons for using a 'scripting' language like Python. You should discard the idea of using Client side authoritative logic (for all the reasons already given by others), but there may be more pressing needs for client CPU cycles, like: Speech recognition, Lackey(minion) AI, prevalidation (blocking impossible actions before sending them to the server to be revalidated and nullified), better 'smart' animation/action combination planning/execution (validation would still be done on server..), Physics simulation for small details (ex- server says rock falls, but neat animations would be particle rendered locally to make a realistic effect), etc.... #### Share this post ##### Link to post ##### Share on other sites How many people playing your game will be bored teenagers with a summer/spring/winter break? It only takes one bad apple in a game with that few players to ruin it and chase everyone away. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by joe1024Considering the low number of players in question (~700 at any time, up to 2000 max), would it be extremely risky to let clients handle game logic ? I mean, how many hackers is my game going to attract ? Those few could be handled manually (by IP/user name), probably.Id rather let each client handle game logic, if possible. Experience with Eternal Lands: A game with only 200 concurrent players (at the time of a small imbalance) can screw up the entire economy. Now, imagine what could happen if, instead of exploiting a small server bug, they could inject packets and mess with the server itself. Even at the current max 867 players ever online, and everything controlled server side, moderation is spread among roughly 25 people to keep from getting swamped. I can only imagine that cracks would become commonplace on a game with a small-medium user base and client-side logic. It doesn't necessarily mean changing stats, but can affect combat, and cause 'jittering' or teleporting, etc, to give other advantages. #### Share this post ##### Link to post ##### Share on other sites Quote:  "Someone mentioned Python scripts to be use for servers (logic..). I couldnt think of anything slower to use when server performance/resources are most needed/at a premium. More intricate game mnechanics and more interactivity (multitudes of simple reactive objects -- not just better AI) continues to expand the need for server processing power so that you cannot just assume that Moore's Law will compensate. I would think that the testing process done on a MMO's scripts would need to be quite rigorous/controlled and thus invalidate most of the reasons for using a 'scripting' language like Python." EVE online uses exclusively "stackless python" for game logic, and they manage 30K+ people on their single shard at one time. I think that easily constitutes "fast enough". And I know there are differences between "regular" and "stackless" python, but they are still enough the same to be called "python". #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by wodinoneeye3km visibility (radius or diameter??) is a substantial part of the world (16x16) and you might consider having the Client permanently cache to disk and better keeping it entirely in memory (as its getting cheaper...). It could still be streamed (initially anyway) but caching the parts that dont change (terrain mesh/textures/models, prop objects...) would free up bandwidth (parts that change could be delta patched along with the more dynamic bits that are constantly updated). Once the player had been in all parts of the world, then the static parts would no longer have to be streamed (and there may be substantially more dynamic parts which WILL require that bandwidth). Yeah, the radius of 3 km is substantial part of the 16x16km area, but those 16x16 were just an example. It could be 64x64 or 128x128, since its generated procedurally in gfx SW and populated with vegetation automatically. The engine really doesnt care and since Id be rendering only nearby players (using LOD/billboards), the landscape renderer takes care of itself without the aid of the server. Obviously, the 3D data (landscape/textures/characters) wouldnt be streamed from server but from HDD. I hope theres no problem (editing terrain landscape/textures by players) with that. Or is there ? Quote:  Original post by KulSeranThe point is that the logic doesn't belong anywhere where random chance can cause something to happen to you.The point is that, no "one" hacker doesn't mean anything, but people are greedy, and when they find out about little tricks youcan do without effort you will see everyone "hacking". I admit that I hoped that situation has changed in this regard during last few years and that the initial troubles were overcome (by others). I havent watched MMO area for last few years and hoped for similar advances that are in SP area, technology-wise. But it seems this is a conceptual issue, so theres no way around this. Oh, well ... Quote:  Original post by KulSeranSince you are intent on keeping your current engine, you would probably be best served by getting a copy of some freeware MMO type engine, and either ripping out the code you need (prolly not going to work well) or using their code baseas a learning tool to show you what code you need to write into your game. That was plan C, originally. Now its plan A. But wait, with so many engines out there, it seems weird there arent equivalent amount of MMO engines. Sure, Ill have to search thoroughly. Quote:  Original post by KulSeranThere are 3 main things that you are going to run into issues with: No. Actually, there are about 1372 other things. Because if Im going with the route C (server-side handling), then I have to do everything that books like "Massively Multiplayer Game Development 1,2" describe. And thats what I wanted to avoid, in the first place, by using some library that would save me months of low-level coding. Quote:  Original post by KulSeranI dont think anyone here is trying to say "NOOOOOooo dont do it!" to you. We are just trying to get the point across that there is no "MMO componet" that you can just plug in. There is LOTS of logic behind the scenes that is directly tied to everything else.You probably can use your 3d engine, and game logic, but you also have to think that everything you have will need some refactoring. You know, its funny, how everyones telling you - "Dont reinvent the wheel", "Just save the time using engines that are out there - just reach out for them". But here, with such a massive issue, as MMO is, now all I hear is "Dude, just write it yourself". Its gonna take me 1-2 years until my game is MMO, if Ill be coding the MMO myself and from the scratch ! Most probably, Ill end up with completely revamped engine, with several completely overhauled components and many of them completely rewritten. Which is like coding MMORPG from scratch, only I have a relevant experience - i.e, few finished games on my belt, plus 6 years of DirectX/C++ coding. Thats just plain absurd, IMHO. But if thats the way to go, well, what can I do ? EDIT: Id be grateful if someone would advise what to do to save as much time [recoding] as possible [Edited by - joe1024 on August 6, 2007 2:19:59 AM] #### Share this post ##### Link to post ##### Share on other sites Quote:  You know, its funny, how everyones telling you - "Dont reinvent the wheel", "Just save the time using engines that are out there - just reach out for them". But here, with such a massive issue, as MMO is, now all I hear is "Dude, just write it yourself".Its gonna take me 1-2 years until my game is MMO, if Ill be coding the MMO myself and from the scratch !Most probably, Ill end up with completely revamped engine, with several completely overhauled components and many of them completely rewritten.Which is like coding MMORPG from scratch, only I have a relevant experience - i.e, few finished games on my belt, plus 6 years of DirectX/C++ coding. Thats just plain absurd, IMHO. But if thats the way to go, well, what can I do ? There are two types of multi-player games. One is the regular online multiplayer, the other is persistent MMO. It may seem like a minor difference, but it's like talking about mowing a garden, or building city-wide road infrastructure. When you go persistent world MMO, a whole new world of problems arises you've never even thought of before. In an MO, if client crashes, forgets to save, hacks the client, nothing happens. In MMO setting, if you misplace one single item, or forget a single gold-piece, hell will break loose. Look at it this way: Your regular single-player game has 1 in 1000 chance of something going wrong during single gameplay session. In MMO, this means, that every game, one player will lose some progress or experience some other problem. The problems involved have been solved in world of business applications. Unfortunately, their solutions are incredibly complex, and prohibitively expensive, on top of it, they don't scale to real-time use without some incredibly bulky hardware. If you go through suggestions listed above, you will find a small number of third-party solutions which take care of everything. Unfortunately, they come as all-or-nothing deal. That means, look at them, decide on the one you like, then subject your engine to that. When it comes to MMO, the entire process is led by technical limitations of server-side. (D2 is only AAA MMO-ish game with client-side logic, and it has been hacked since day one). As mentioned before, you have approximately 3 options: Turbine, Multiverse or NEL. Look through them, see which is applicable. An MMO application server is (ideally) a real-time, unreliable massively distributed, ACID-compliant database server. This alone is a hugely complex set of requirements which are only achievable through incredible amount of compromises - and in order to make it work in the first place, corners need to be cut. And the whole implementation is there to make sure everything works. There is another option. Don't worry about server software. Change existing code to run server-side, then provide a database to take care of everything else. Unfortunately, you'll then need to scale in hardware. You bring in several machines with fail-over hardware, put on distributed database, provide virtualization for your logic (one game per thread). This is perfectly viable - but can you afford the cost of hardware then (at least 4 machines for database cluster, plus 1 machine for every 4-64 players, depends on how much logic you have)? Multi-player games are challenging. MMO - very difficult. The reason why companies provide the whole deal is for this very reason - they understand all the real problems you'll face, and give you tools to solve them. At very least go through the free engines available to see how programming of such server looks and what all is involved. That should give you an estimate on how much work it would take to convert things. Quote:  I admit that I hoped that situation has changed in this regard during last few years and that the initial troubles were overcome (by others). I havent watched MMO area for last few years and hoped for similar advances that are in SP area, technology-wise. Things have changed. But just like you don't download Oracle's database source, and pull out 3 files to include them in your application, you need the whole shebang for it to work. A lot of experience has been gathered, and it's provided as a package deal. #### Share this post ##### Link to post ##### Share on other sites Quote:  what are the chances that of those 1000-2000 people there will be somebody willing to loose time creating troubles ? My guess is about 100%, give or take. A friend runs Synthetic Reality (http://www.synthetic-reality.net/) in his spare time, and has for many years. It's a really simple multi-user game kind of community, and his two biggest problems (recurring) are: 1) people hacking the game for advantage within the game 2) people using fake credit card addresses to donate with PayPal (!) The first thing to realize is that, if you already have an RPG with a world, characters, skills, etc, then you're pretty well off. The hardest part in an MMO is not the code; it's all the massive amounts of assets and game content that needs to be created. The second hardest part is care and feeding of the community, and customer service. The code only comes in third in hard-ness (although good code can of course help with the top two). The MMO engines that are "real" that I know about, and won't need too much work to allow you to let characters move around a world with server-side verification, include: - NeL (nevrax.org) - Multiverse.net - Hero Engine (heroengine.net) - THERE (thereinc.com) - BigWorld (bigworldtech.com) Our platform, OLIVE, does not serve entertainment; instead, we let the THERE sub-licensee take care of that market, btw. I didn't know Turbine was available on the current market, but if it is, then feel free to add that to the list. What you should do to save as much work as possible is to get an evaluation of each of the platforms, assuming you like their technology approach and cost. Then try each of them for a week, and see how far you get. Whichever has the best fit to your current art path and development methodology should be the one you choose. #### Share this post ##### Link to post ##### Share on other sites Quote:  I didn't know Turbine was available on the current market, but if it is, then feel free to add that to the list. Sorry, Torque #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by joe1024Id love to hear about currently available MMO libraries and what is their cost / licensing price. Im looking for something small-scale - 2000 players at most (if I ever manage to get that many people tied to my game, that is). My goal would be to reach 1000-2000 subscribers, so Id guess that the maximum actual number of players [at any time] would be around 700. Standard pricing: around$0.5 - $1 million per game. Sorry. Best discounts I've heard, for a game with a 2k concurrency, you could get a license as low as$50,000 plus royalties.

Quote:
 Im planning on "adding" the MMO component into my own 3D engine (C++ and DirectX), that I`ve been developing over the course of last ~6 years.

If you're a good coder, good at planning, willing to learn a lot first, and do some experiments by writing net + server code from scratch (make a "mini-mmorpg" first), and do a lot of unit testing, this is perfectly feasible.

Quote:
 Also, I assume it will affect the choice of the MMO library, if I mention that my engine streams the terrain (no levels)

This could be helpful in getting the basic game running. Streaming is always good for mmo's, done properly.

##### Share on other sites
Torque is an FPS engine, not an MMO engine. There is an "MMO Kit" for Torque, but it appears to be written by enthusiasts who have not actually shipped any MMO before, and I'm aware of no shipping game on top of MMO Kit + Torque. In that same category is Realm Crafter (written on Dark Basic).

##### Share on other sites
Define MMO.

If you consider 128 players MMO, then Torque is useful. Calling it an FPS engine doesn't mean that it's not an MMO engine, but in this case it's true. You need to do some heavy refactoring to get it even near that.

##### Share on other sites
Quote:
Original post by KulSeran
Quote:
 "Someone mentioned Python scripts to be use for servers (logic..). I couldnt think of anything slower to use when server performance/resources are most needed/at a premium. More intricate game mnechanics and more interactivity (multitudes of simple reactive objects -- not just better AI) continues to expand the need for server processing power so that you cannot just assume that Moore's Law will compensate. I would think that the testing process done on a MMO's scripts would need to be quite rigorous/controlled and thus invalidate most of the reasons for using a 'scripting' language like Python."

EVE online uses exclusively "stackless python" for game logic, and they manage 30K+ people on their single shard at one time.
I think that easily constitutes "fast enough". And I know there are differences between "regular" and "stackless" python, but they are still enough the same
to be called "python".

How complex is their 'game logic' and how high level are the primitives that are invoked ??? I wouldnt doubt that most of the 'logic' is imbedded in the engine (prob C++) and only superficial 'scripting' is made use of. (30000 users on a single shard on how large a cluster???)

More reactive/interactive Worlds with a much larger load of script execution (real logic - not just script sequencers) would drown X times sooner than a server written in native code. With Python I think its the reliance on the constant namespace lookups for variables (every variable and method call).
I seem to recall that LUA gets a 2 fold increase in speed (or something significant like that) because they can use arrays (fixed mem offsets) to similate STRUCTs.

Too much Ad Hoc scripting can be the death of a server (and they often have to impose severe restrictions on such projects), and the advantages
that people in simpler projects look to 'scripting languages' for could be had with better tools (and proper primitive construction) that would turn out fast native compiled code.

[Edited by - wodinoneeye on August 7, 2007 1:11:15 AM]