If you people will indulge me in sharing some more or less concrete ideas, for getting some common sense feedback, I hope you will find it interesting although the things I have in mind probably would be overly ambitious due to the size and complexity of the game I can imagine.
Keywords: Persistent world, sandbox, fantasy, MMORPG, single realm.
Having played Eve online for a long time, I have come to realize that creating and running a MMO game is probably quite challenging, with customer support, future development, stability and performance problems, security issues and player shenanigans exploiting everything that can be exploited.
I am not sure what this thread will come to, but I have dabbled in game design issues from time to time for fun and hope that this will be interesting and that I might learn a thing or two.
I had in mind to write about a variety of issues in no particular order and hope that people, if they have the time and interest, can offer some comments on primarily technical issues and not so much being opinionated about whether or not an idea is deemed good or not as such. Any opinions are of course welcome, it is just that nay-sayer in my experience rarely provide interesting and compelling arguments against any particular idea.
1.0 World size
Disregarding any particular problems with having a massive multiplayer game to serve thousands of players, I am fascinated by the idea of having a persistent landscape spanning kilometers of landscape for people to travel through.
An island with a diameter of 500km would be the size of bottom half of Norway, or a little larger than Iceland. A player walking at a speed of 5km/hour would spend about 48 hours walking across the island in the game. Riding a horse would be an obvious advantage for such distances, and flying mounts even more so.
1.01 (Development) Developing a landscape the size of Iceland would seem really laborious, however I imagine that it would be doable with some preplanning. Else I imagine that a procedural model and placement of objects ought to lighten the work load.
1.02 (Amount of players) With a given size of the world, one can imagine that a place will become overcrowded with thousands players, leading to a practical limit of how many subscribers the game could end up with. Comparing a number with Iceland, I imagine that 50.000 online players and even more subscribers like with Eve, would create a healthy profit from subscription and maybe some sensible microtransaction ideas.
1.03 (Hardware limitation) I guess it is fair to wonder if maybe a 500 x 500km area might lead to unforseen practical problems, when thinking of the installer size for the game.
1.04 (Updates and outdated design) It seem obvious that one ought to have plans to deal with future development and not leave such challenges to coincidences.
1.05 (Game lifetime) Hm, what to do with future development, if one imagined a game to stick around for more than 10 years. Seem like a good idea to have such a problem worked out, without inferring some kind of feature freeze along the way, based on some freak 10 year plan leaving no room for improvisations and improvements.
I want to add some further ideas (more concrete) with time and I hope this thread is not found inappropriate, given the (for me) rather unrealistic prospect of actually designing a MMO game.
2.0 In game aesthetics/realism
Having played Eve online, I believe I was amazed at how well that game seem to offer an engagement in the world with ones presence without the help of fantasy gimmickry. Imo, the tools and options for moving about and the GUI made the engagement a smooth and pervasive experience.
Leaving out the problems regarding combat systems, I would much like to make for a game that offers a powerful sense of presence, insofar as such a sense imply an awareness of ones surroundings and ones part in it beyond ones immediate location and point in time. A game of this kind would not really act as an escapism as much as simply being a good game with its own qualities as a game, offering a compelling adventure that is supposed to be worth your while with whatever motivations you bring to it.
Although any supposed problem of escapism might have some limited relevance to each individual, I will argue that neither prolonged playing nor an avid appreciation of a game is problematic by itself. Blaming games on the basis of psychological models for explaining human behaviour or its supposed motivations is really not fair imo, based on a commonsensical and a philosophical approach to relating to such problems about supposed addictions.
In my experience, games seem to rely solely on a figurative way to go about providing a compelling environment to play in, and I would want to do something about it. I recall one time some guy in class somewhere wondered why Le corbusier used to draw in airplanes on the perspective drawings of buildings. It occurred to me right away that having that airplane drawn on the sky made for a powerful illusion where the nothingness of the sky turned into a sense of space nonetheless, with the airplane effectively demanding your attention to this fact.
So I envision a game-world relying heavily on the use of sound effects and little things that incessantly gives a cue to the player about the environment in its current state. I think a seasonal cycle with spring, summer, autumn and winter would be really compelling, adding opportunities for pacing the game and for adding immersion into the world and the game mechanics.
2.01 (Seasonal cycle) Achieving a cycle of the seasons seem easy enough though I guess it would be tricky to arrange for having players both see and interact with snow.
2.02 (Footprints) I think it would be really nice to be able to have players make imprints in the game, for a limited duration in time. Footprints in the snow would be fun to see, even if in some abstracted manner. I imagine that some curve path system could perhaps make the visual effect of imprints less complicated.
Effects: Fog, snow falling, rain falling, dust storms, dust from walking, smoke, fire, water droplets falling, river flowing, water particle spray, distorted line of sight from heated air, basic physics simulations for rope and cloth to react to the wind, frost breath, soaked/moist clothing, "godrays", day/night cycle, seasonal cycles, cloud system, direct sounds.
Implied/indirect: Sounds, odors, temperature, visual observations, own health status, weather status.
I think main problem of the Very Large World Game is not developing (mapping, modelling) of such a world, but storage, processing and networking. There are several possible realizations of the VLWG:
1) Store full map on the server (or several interconnecting servers) and send visible part of the world to clients. Map must reside in server operating memory, so map size limited to \~8G per server node. Also clever update network protocol and sufficient bandwidth required. Storing of such a map in client side is not an option (otherwise it is not VLWG).
2) Use fully procedural world. Cheapest solution but with limited world appearance and without any possibility of map updating.
3) Combined approach. Given previous LOD level generate next level with following: spline interpolate previous LOD + deterministic noise + adjustment. Adjustment stored in the map (and resulting map much smaller than in ). This map can reside in the server and transfered to clients through network or stored in clients. Server maps have advantage of possibility of dynamic updates. Downside of this approach is that it is required complex algorithms and hard to program.
Overcrowding can be resolved with multinode server, where each server node handles different map region or subset of all players.
Procedural landscapes dont have to look plain, I was stuffing around with procedural landscapes for a little while, I was actually raytracing it, I was getting overhangs and grass powdered on top of ledges, it looked pretty cool, I imagine you could get caves, mountains, forests, plains, rivers all down to a really tiny detail level, roads all procedurally generated. It actually could look nice if you took that option.
Would a world generator be any use to you? i could write one I bet, something pretty nice. It all depends on how you want to visualize it, as raytracing sorta suits procedural generated stuff, maybe it would be a little trickier to get it to work with a rasterer.
I thought more on it, and you could use a vectoral displacement map, build the area around the camera in the pixel shader, then just pass a grid of points to the vertex shader, read the vectors (and colours) off the procedurally generated map, then it should work, and anything could be possible. 100% procedurally generated terrain up to infinite size with 0 store.
you probably could get it to work for indoor caves (with a floor and cieling) and maybe more man made dungeons too, if you twist the idea a little.
I appreciate all your comments, and I hope that you dont take offence to me not trying to resolve any ideas here and now. Those technical things are abit over my head I can assure you. I do try to wrap my head around what has been mentioned.
I am not even by far qualified to provide opinions on how to actually solve technical problems around how one would run a game, regarding the world geometry and the various types of interraction between the world and the players, and everything between the players themselves, so I will simply try to sum up what I think I know to be a reasonable way to go about it in a general way.
Not trusting the client
From what I have read sometime earlier about game design, everything that happens shoud be decided by the server, and not allow a client to create items by exploits or hacks, or otherwise break the game design in any way that is not predictable and rather obvious.
I had in mind to prohibit any kind of map or "radar" that usually allows a player to quickly and with certainty, have an overview from which to make plans. Trying to keep "things" secret from a player sounds a little risky, because people will probably try hard to overcome any obstacles or annoyances they find in a game. So if the game does not have an accurate world map, someone will probably try to make one. If arranging for having a world utterly large I guess a major concern could be cybercrimes against a corporation or anything to do with the game servers, or perhaps simply the risk of mistakes or experiencing employees that are naughtly disclosing information they should not divulge to others.
Secrets and privileged information
I have been fascinated by having "real" secrets in a game, but an obvious concern would be the online world with so called walkthroughs, maps and knowledge about exploits. If a player were to take pride in finding a secret passage, anyone making a map or a set of instructions would be able to make things less exciting. Perhaps some clever and hopefully somewhat plausible way of allowing players to have secrets could work despite the risk of such information becoming worthless. A server could plausably allow a certain player to spawn an instanced shortcut. It would be something other than an obvious and large opening in a mountain side, and something hidden beneath grime or bush. Allowing a player to create some kind of map/token could allow anyone to utilize a hidden shortcut through an area, or entry to some hidden place. It would be an option to allow or deny mass copying of such a map. Creating fake maps sounds like fun, being a market commodity. Heh, I played Eve online for too long to not appreciate the frequent acts of or attempts at shenanigans, even though I was the one having been duped a few times.
Secret/undisclosed/non-existing world map?
I am fascinated by the notion of keeping a world map inaccessible to players, primarily to not debase immersion factors and pacing, but I also imagine that map making features could be fun and an important part of such a large world.
I wonder how bots work. Perhaps the lack of a map could make bots hopelessly difficult to work.
Oh, I almost forgot, I guess a limiting feature with MMO's are reaction times between the server and the clients. To be honest, I am not sure how fast people can interract with eachother, could it be split second accuracy at best?
I also realize that mass combat would be tricky. I have an idea about creating a dynamic slow-motion combat system, that would allow better pacing for combat with players having beetter time to react in melee combat while also being allowed greater complexity in combat, where there (as I imagine) would be better room/time to have players interract with eachother if the combat was slowed down a little.
From what I have read years ago, some developer from Age of Conan claimed that network technology prevented complex interractions between players. I would be happy to learn about those kind of limitations. I guess there are perhaps primarily two problems, one being a limit to how fast one player can react to another player in optimal network conditions, and the other being delays in how data is transferred between the server and the clients.
The client and world generation
Perhaps encryption could work to have a client store and process data without the gamer ever being able to tamper with the data?. Sounds risky though, if anything were to fail or if someone one day made a mistake somewhere.
Some fun numbers: With a world 500km in diameter, it would take a player approximately 4 real days to walk cross. If the area was circular shaped, it would contain almost 200.000 patches of 1x1km sized areas.
Instead of having developers place trees one by one or procedurally in one process, I guess one could simply create oval areas to quickly fill out a terrain, areas that could be filled out procedurally in the next step, filling the areas with a mix of different trees for example, and then finally having designers inspect the result and correct things casually from the start and for as long as the MMO game lives.
Eve online has npc's as an isk fountain with its bounties and agent missions, I imagine that timber and other natural resources could create a living economy with nature replenishing itself (trees growing back) and timber potentially rot or otherwise deteriorate. I imagine that npc's could optionally be set to work for a player, so that the game does not turn into some laborious wood-chopping-simulator.
A while ago I also thinking about disclosing map to players. It is possible only in the scenarios where map is sending to clients over network (this eliminates fully procedural world). Server must determine map area visible to the player and send distorted map coordinates of visible area with distortion varies over time. Server map itself must be irregular. But I cannot invent concrete algorithm to do so without introducing visible artifacts.
Without dynamic distortion disclosing game map is impossible. While you can (in theory) disclosure corporate map, smart players write tools to determine player absolute coordinates and soon coordinates of city X or even secret village Y will be known.
It is possible to make secrets even in the open map world. This secrets must be dynamic and deteriorate through use, encouraging players to disclosure knowledge of such secrets. Good thing will be to make mechanism for players to make their own secrets (i.e. bury chest of gold).
Slow reaction time in MMO is not due to MMO itself, rather to laziness of developers. Most MMO use TCP protocol, which introduces high latency and lags in case of packet loss. It is possible to use properly designed update protocol over UDP with client side prediction and get FPS-like behaviour (for mass combat it is more tricky, protocol must prioritize near players over far).
For the VLWG working with individual trees is not an option. Artist determine only forest thickness and tree types, and individual trees generated by procedural algorithm based on artist's values. Trees generated on the fly when needed and never stored by server. Procedural algorithm can be depending on time allowing forest to grow. In contrary, chopped trees can be stored on server individually cause its count proportional to player count and deteriorates over time (new thees grow over).
Any protocol encryption works only against network interceptors. Clients break any protocol encryption in days. All bot "protectors" works mostly against legal players. I think that bots are not so evil, they automate repetitive and unintelligent tasks which players don't want to do themselves. For example, to not turn game to wood-chopping-simulator one can introduce in-game bot (part of the game itself), so player can assign his/her character to chopping and logout while character remains in the game and supports game economy.
']...TCP protocol, which introduces high latency and lags in case of packet loss...
Wait for it...
For one thing, practically-speaking, busy routers generally drop UDP before TCP. (And, by routers, I don't just mean the home unit, but any other along the way to the server.)
Between TCP and UDP, the main difference is that TCP has many built-in flow/congestion controls, some of which you may wish weren't there when you don't care about packet loss, or have peculiar networking requirements, or some other esoteric needs. However, in an MMO, you'll likely have to code some of what TCP does: packet ordering, duplicate detection, compensation for missing packets, etc.
Stepping back from the UDP vs. TCP conundrum, if you have a client/line where packet loss is high, and you use UDP, you have to make sure that kind of high packet loss is okay in your game. If you lose lots of packets over UDP, are you affecting playability anyways because packet loss is high? TCP has lots of overhead that can pile up upon packet loss, but using UDP may not be the answer. The answer may be not allowing players with sh**ty connections.
For an MMORPG, it doesn't really matter what you pick. In fact, with lots of game world state, you'll find TCP helps you more. For an online FPS, it will likely be better to maintain fine-grained control over UDP. Or, you get a library like RakNet that implements a few of TCP's flow control over basic UDP, or look for another protocol such as RUDP that you can implement yourself.
Well, in my country internet is not very good so it is matter for me which protocol is used. It is common for me when the game (on TCP) renders absolutely unplayable while in the same time voice chat program (on UDP) hardly notices packet loss. My point is: while using UDP protocol it is possible to achieve seamless low latency playing with moderate packet loss, it is impossible to do with TCP. Even if some routers drop more UDP packets than TCP that doesn't matter cause typical UDP application can sustain several percent of packet loss while TCP cannot survive even single packet drops.
You cannot compare a UDP-based voice app with a TCP-based game. You can sustain high packet loss (upwards of 5%) in a UDP-based voice app, given that with minor jitter, the voice is still understandable. You may not be able sustain that level of packet loss in a game, TCP or UDP, depending on the data being transmitted.
I'm not saying TCP is always better than UDP. It's just not as simple as many make it to be...