Actually, porting between the PC and the Xbox seems to be a real problem for developers. DICE worked on a port for Battlefield 1942 for the Xbox but killed it to spend their resources on the sequels to the PC-version of the game instead, so porting definitely wasn’t a trivial task.
[quote]O You want a complete games solution that carries the Java brand?
[/quote]
Have you considered the possiblity of creating such a solution based on Java technology without actually using the Java brand?
It wouldn’t be the first time a company creates a new name to sell the same technology to different markets (Toyota/Lexus, Honda/Acura etc.).
Yes, I’ve read that, too. It will be even more of a problem when the Xbox2 comes out, which doesn’t base on PC tech but on PowerPC chips and so on. I read that MS ships to Xbox2-developers a development-toolkit which runs on Mac. Funny.
Okay now your messing with my baby so your gonna get ME to speak up.
I can’t. Not the way this stack does. Show me a system where you could take the etnire online population of Everquest and put tjem in one shard and allow unfettered access to any region. A system that uses all its available CPU power all the time and still can have ANY of those CPUs fail without the clients noticing.
Add orthongonal persistance that makes the entire world dynamic and ensures the entire game state is always recoverable within a few moments of total system failure, gauranteed referrential integrity that eliminates dupe bugs (all of which it does) and you’ve got the answer to just about every need of MM games today.
Show me a system that does all that and is actually functioning somepalce I can see a demo. Then we’ll talk.
ROLFLOL. I’m sorry but you are pulling my leg right? The response times of J2EE are TOTALLy inappropriate for writing anything beyond puzzle or slow turn based games. And programming EJBs is a nightmare.
It shares some very superficial simialrities with J2EE in that (a) its a container solution and (b) it allows many different apps (read games) to share resoruces and thsu expenses. But thas abotu it.
This is a stack that has as an outside limit for entire message turn around, entry to exit, in the 10s of ms. SImualtion obejcts have to be serializable and otherwise are instances standard Java Classes.
Saying “J2EE could do that” frankly is like saying your VW bug can pull a semi trailer because, hey, it has wheels too!
Or you just dont have a clue what we’ve developed, not having been at CGDC and not even having seen the white paper yet. And/or maybe you don’t know why its improtant because, unliek virtually every actual serious MM developer we talked to at the show (who are all excited as hell by the tech) you have never actually built such a game.
I’m afraid Jeff edited his post whilst I was replying, so if this seems weird at points it’s probably because I was replying to the original :).
Now that I know there’s a whitepaper coming, I’ll wait till I’ve read it before saying anything on your tech in particular. Note that I don’t in any way mean to belittle what you’ve achieved; I just feel that Chris was wrongly (and knowingly) stating that no-one else had done similar (possibly identical) things. Note also that I made no comment on the effectiveness or otherwise of your work (and indeed I’m not sure where you got that impression: why do you think I’m “messing with [your] baby”?).
This is the third attempt to respond to this particular comment without replying in the same (or worse) tone. I read your words to imply (and I may be misunderstanding you here?) that you think a few problems such as duping, failover, and efficient processing power usage are the be-all and end-all of what makes MMOG development hard. I certainly don’t swear by Gordon’s 10 reasons (GDC03), but they’re quite good as a starting point. How many of them does your solution solve?
If I’ve understood correctly, I personally feel you are missing the bigger picture; most of what you describe has such a tiny effect on the bottom line of MMOG development that in overall percentage terms a “not good but not bad” first stab at each of those problems generally is enough to never need to worry about them again. I’ll say it again: none of them are the classic “big, hard problems” of MMOG development, perhaps with the exception of preventing dupes - but that’s as much a side-effect of bad design and architecutre as a problem in it’s own right. Getting them very efficient is no easy feat (and you’re achievements here indeed sound impressive), but I can’t help thinking of your old mantra about performance: find out what the bottleneck is before optimizing. I’ve never seen or heard of a system where the things you described were fatal bottlenecks; they’re nice features to have, but are far from being “the answer to just about every MM game today”.
But please, prove me wrong: show me a cost breakdown for MMOG development, deployment, and maintenance which justifies your belief. Even better, lay out for me (in simple terms so I don’t misunderstand) examples of games that have suffered irreparable harm from them.
You’ve read into my words something I didn’t say nor imply. I never mentioned response times, nor had Chris. You’ve only now introduced that to this discussion. To re-iterate: the point I was making there was that the features Chris was touting could even be done with J2EE. I couldn’t have been more explicit, in fact: I named them in the sentence you quoted!
Despite many attempts, you (not personally) wouldn’t even allow me to sign an NDA to talk to you. For more than a year. I’m sure it would be interesting, and we could have some very stimulating conversations, but after rebuff after rebuff after rebuff I’ve realised we’ve got better things to do with that time. Hence I’m not going to say anything about how our tech works, or how other techs we’ve seen work, interesting as it would be - it would take significant time to do each justice (I have a good idea of this because we have internal research reports for various competing technologies; most run to about 5 pages for the core analysis. Even just summarising that for each would take considerable time - and besides, it’s an additional revenue stream for us, so I’d be loathe to just give it away free here).
As I said, I will certainly wait until I can read it before commenting on the tech (which I so far haven’t done; you appear to be defending against an attack on your work that I didn’t actually make? My apologies for the misunderstanding. I think I’ve said before that if you think I’m attacking you then you should feel free to email me and check - it was probably accidental)
[quote]This is the third attempt to respond to this particular comment without replying in the same (or worse) tone. I read your words to imply (and I may be misunderstanding you here?) that you think a few problems such as duping, failover, and efficient processing power usage are the be-all and end-all of what makes MMOG development hard. I certainly don’t swear by Gordon’s 10 reasons (GDC03), but they’re quite good as a starting point. How many of them does your solution solve?
[/quote]
Yes, I think beign able to scale is the #1 issue with designign MMGs. Most of the other problems (such as the absuridities of regions and shards) derive from this single problem.
For a user perspective the 4 biggest issues are player isolation (regions/sharding) , back end reliability (which is crud) , performance and bugginess/lost gameplay. Ask any user.
From a developer pesrpsective the biggest isues are programming scaling reliably (no races, deadlocks, dupes etc), persisting and acessing data, and handling user load reliably in cost effective manner. Secondary issues derive from the challenges, splitting your user base being a big problem.
This is why we get such a fantastic response from BOTH communities when they see the system in action. It addresses both their needs.
I don’t know this particualr list you mentioned, there are certainly many out there. Thre are abour as many theories on good MM game deisgn as there are attendees at CGDC. I suspect howevre that many of his problems are either higher level ones (how to create functional communities) or secondary effects from the primary ones I’ve listed.
The design issues in general will be adressed as the tech issues get easier to solve, which is what the Sim Server is all about. Other then that the system is purposefully game design neutral to allow these things to be addressed as a game designer sees fit.
As for the others, give me the list and I’ll respond to it.
Ok, here’s a freebie: from sales talks with an excessive number of commercial games studios over the past 5 years, from 5-man indies, to internationals, and bestselling studios in between, I can assure you that the majority of games developers don’t mind shards.
Most studios are trying to make enough money to stay profitable. The sad truth is that the user perspective is only indirectly relevant. And, incidentally, off the top of my head I can think of two other showstoppers for the players that you missed.
That’s interesting. I’ve been visiting the conferences (even speaking at them), talking to the designers developers and producers, and selling to first-timers, and I’ve hardly seen any theories on MMOG design. We have a database of literally thousands of background documents (research, articles, surveys, etc) and the MMOG design section is almost empty (disregarding our own reports). Where have we not been looking?
[quote]a few problems such as duping, failover, and efficient processing power usage are the be-all and end-all of what makes MMOG development hard. I certainly don’t swear by Gordon’s 10 reasons (GDC03), but they’re quite good as a starting point. How many of them does your solution solve?
[/quote]
I have a question about this. What is the problem with duping? Seems a relatively easy way to get around this is to use objects ( this is Java, right?) and build in a serial number to every object. When you pick something up, it checks the serial. When you log on to a system, it does a serial check against all your items. It doesn’t have to be a really big number or character string. And you use that to build your comparable interface at the same time.
I can see where this might cause the system to slow down, what with doing serial checks every time a player picks up an object. But you will have to do something along these lines anyways. As far as system resources go, start a comparable thread, let it run. If a player tries to dupe something, he/she might get away with it until the thread returns. Then add more processors.
Ok, now shoot me for talking about something I understand only superficially.
[quote]beign able to scale is the #1 issue with designign MMGs.
[/quote]
I believe that issue #0 (hah, I’m a programmer) is designing the games in the first place. How do you make a game that’s fun? Shards are not necessarily in use because of technical limitations at all - shards may be intrinsic to the problem that a huge online persistent world just might get boring. The more these “games” end up being “life simulations”, the more like life they have to become, and the less interesting as games they are to the mainstream player.
That, at least, is an entirely non-technical, non-marketing perspective on the whole issue.
How much of what he talks about is solved by technology? Mmhhhm. Perhaps some cool headed non-technical discussion is warranted to thrash out the problem domain for which the various pimped techical packages provide a solution before any lengthy exchanges of ignorance occur.
That’s probably because you’re someone trying to write games, not a Sun dept trying to break into an industry. FWIW, about 1/3 of games developers we speak to bring up the same issue as their number one problem (although that doesn’t necessarily mean it IS their number one problem, just that it’s the one that bothers them most at the start).
Indeed. Had the GTG been watching carefully, this has been debated at length for at least 2 years in public. I can think of many reasons both for and against the desirability of using shards. Shrug. I’ve even had (on occasion) a tough time persuading commercial studios that - from a technical perspective - they really don’t want a sharded system.
He may be wrong on a lot of points, but along with LTM, waterthread, HDCS and the Laws, Mu is widely considered required reading for anyone in this market.
[quote]Shards are not necessarily in use because of technical limitations at all - shards may be intrinsic to the problem that a huge online persistent world just might get boring.
[/quote]
I agree. The posts I’ve seen from MMORPG developers about scalability tend to be about the problem of scaling the content. Unless Jeff’s platform also creates content, the work required to build and populate a big world for 50k players instead of making 25 copies of a small 2k-player world still makes sharding attractive.
Then again, Anarchy Online did try the 50k player world option and they failed mainly because of technical reasons. It was simply the buggiest AAA-level game that I’ve ever played, even a year after its release, so maybe Sun can sell the platform to Funcom.
Seems to me the most unsurmountable problem isn’t technical at all, but rather the ability to provide dynamic, engaging content.
But merging the dynamic and engaging content is what makes MMO games so difficult. This is not a technical issue.
And I think that is not the real problem.
A better way to state the problem is this: Keeping players interested in the plot that you are feeding them.
But that isn’t an exact definition of the problem either. It is getting closer to the real problem though.
The real problem, and it has parallels in the real world, is a control issue.
There is not a single game out there, to my knowledge, that disassociates player freedom with game rules.
Let me step back to paper and pen RPGs for a moment.
I loved playing starwars. Even a beginning character could hose a stormtrooper, no problem. The reason? Player characters are SPECIAL.
Now, your real issue is making each and every one of your 50,000 online players feel unique and special.
There are several routes to this, Most of them don’t work for very long.
Have plot missions that characters can fill. The effectiveness of this is limited in a chat environment, where players will ask “How do you complete missions x?” Everyone does the same cookie cutter mission. Such fun. Kinda like a puzzle filled FPS…with lag!
Put lots of detail and things in your game. Hundreds of skills, skill levels, points, attributes, objects, manufacturing thingies, etc. make them pluggable so that you can just keep adding more and more and more and more. “My Super Wanda Sword beats your Vorpal Sword iX!” “No, I no longer use the IX, I have a Super Wanda 2!” My virtual sword is bigger than yours! This gets tiring, but not as quickly as reason 1 stated above.
Obfuscate the plot. Obfuscate the high end gadgets that the players can get. This is supposed to work towards adding a level of suspense. Yeah, right. THis is dreadfully annoying for anyone that isn’t a noob player.
Add real, INDIVIDUAL, dynamic content.
This is not truly a technical issue. THis is a “we don’t give a @#$% about the players” issue. This is a “My game, my plot, MY CREATION” issue. To my knowledge, even though it is possible, no one has built a persistent online world that each player has the capability to rise to power, overthrow the head honcho NPC characters, and get knifed in the back by his/her buddy who wants to run things now.
If you build a system where the players drive the plot, instead of act like ancilliary extras on a large movie set, you will have a game that blows the competition away.
This is not a technically challenging thing. Yet no one does this. The only people that can truly provide your game with 100% dynamic content is your players. Set up the game play, initialize a basic plot, and let the players take control of your world. The basic plot dies, but is replaced with your players struggling to create their own world-spanning empire. When one faction gets too powerful, send in your alien/goblin invasion, bash everyone mercilessly, reward the best ten players with a new desktop computer system, and take control of their characters, turn them int oNPCs for the next wave of players to overcome, etc.
You have some interesting ideas. I suggest you subscribe to MUD-DEV (visit kanga.nu for details) you’ll find a very large number of ex pen-n-paper roleplayers talking about online games development.
This is incredibly difficult to do. No, really. As it happens, it’s one of the areas where we’ve concentrated on adding value, and is one of the reasons why I’m unexcited by Sun producing a technology that’s all about things like preventing the need for shards.
Would you like to see my design layout for this? It would take me a few days to put it together, as it is still mostly on notepaper currently. But I would be happy to share my grandoise and megalomaniacal ideas…
[quote] 4) Add real, INDIVIDUAL, dynamic content.
This is not truly a technical issue. THis is a “we don’t give a @#$% about the players” issue. This is a “My game, my plot, MY CREATION” issue. To my knowledge, even though it is possible, no one has built a persistent online world that each player has the capability to rise to power, overthrow the head honcho NPC characters, and get knifed in the back by his/her buddy who wants to run things now.
[/quote]
Doesn’t Shadowbane let you do this? You can supposedly build and own the cities only to have your guildmates betray you. Never really got into the endgame so I’m not sure…
MS is sure investing a lot to XNA tools. They give a simple and easy to start tools + APIs + good documentation. No wonder XNA is used in many universities as a teaching platform.
Yeah, I’ve been tinkering with XNA this week and while the API is nice, it’s the VS intergration that really makes it shine. You can go from nothing to a display with a sprite on it in about a minute.
