Sprites, MMOs and massiveness

Started by
6 comments, last by SymLinked 10 years, 9 months ago

I was talking to my friend last week about the new generation of consoles, he told me there was an MMO anounced for PS4. At first I thought "how weird, consoles mostly don't handle MMOs very well." He told me it would be have totally epic battle, up to 40 vs 40.

My reaction was: "40 vs 40 is epic? Are you $*%# kiding me?"

The fact is that it is rare for any game nowadays to be a huge experience, even an old game like WoW fries your video board when there are a hundred players at screen. I do remember the golden days of Ragnarok Online War of Emperium (a guild vs guild war for castles), those were massive events that literally hundreds of people would participate at the same time, here is a video of a particularly massive fight:

Ragnarok graphics were a mix of 3D scenarios and sprite characters that actually looked pretty cool. It also makes the game scale incredibly well, even by the hardware of the time. The network consuption was a bit problematic (people would lag badly sometimes), but I do believe nowadays this can be handled (Heck, I played at a 128kbps connection those times and lag wasn't common).

Which brings me to my point, do you think that people would still be willing to play an sprite based game or just 3D games have any chances to be popular?

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).

Advertisement

The speed of the internet connection doesn't have much to do with whether 2D or 3D graphics will be performant -- you might have to send a bit more data to describe what's a player's doing, but I can't imagine its much more. Likewise, I don't think 2D vs. 3D drawing is a huge factor either, I would suspect that adjusting the LOD of large groups of players (that is, rendering simpler models with smaller textures and simpler effects when a lot of people are onscreen) would scale nicely.

But sure, there's nothing wrong with 2D games, or mixing sprites with 3D environments, as long as the artwork reaches a high and consistent quality where the 2D elements don't look completely out of place with the 3D elements. You might even render the environment with an orthographic projection that's slightly out-of-skew (you could still let the player switch perspective among the four cardinal directions).

There probably are a few people who dismiss games with 2D elements, but there's at least as many that actually appreciate it, and you'll win over any fence-sitters with the quality of the art and gameplay, not whether its rendered in 2D or 3D.

throw table_exception("(? ???)? ? ???");

The speed of the internet connection doesn't have much to do with whether 2D or 3D graphics will be performant -- you might have to send a bit more data to describe what's a player's doing, but I can't imagine its much more. Likewise, I don't think 2D vs. 3D drawing is a huge factor either, I would suspect that adjusting the LOD of large groups of players (that is, rendering simpler models with smaller textures and simpler effects when a lot of people are onscreen) would scale nicely.

But sure, there's nothing wrong with 2D games, or mixing sprites with 3D environments, as long as the artwork reaches a high and consistent quality where the 2D elements don't look completely out of place with the 3D elements. You might even render the environment with an orthographic projection that's slightly out-of-skew (you could still let the player switch perspective among the four cardinal directions).

There probably are a few people who dismiss games with 2D elements, but there's at least as many that actually appreciate it, and you'll win over any fence-sitters with the quality of the art and gameplay, not whether its rendered in 2D or 3D.

Reducing LoD is a nice strategy to reduce the problem a little, haven't considered it.

What I meant by the network problems was due to the massive amount of players on the screen (keeping clients syncronized is a problem that grows in a square order).

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).

Each packet of info has to have:

* All the customization each player avatar has

* Everything the players have on and equipped

* The direction the players are facing

* All the players' critical stats

* The direction the players are moving

* The speed the players are moving at

* All lighting and particle effects for each player

* All the "extras" each players has, such as pets

* Everything else that's rendered as a result of each player

I remember on Secondlife, in some areas, I was downloading "game state" updates at 50Mb a minute

I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.

~ Ralph Waldo Emerson

I remember when Ryzom saw its (sadly very short) summer, when an outpost battle would have roughly 120-150 people on each side, and when someone accidentially shot a lumper or came too close to a group of kitins, anywhere from between 5 and 30 mobs stampeding through the crowds. That, plus the defender NPCs at the outpost, which were... an awful lot... at higher levels.

This works very well even in 3D with quite detailled graphics and "perceived realtime", if you apply proper LOD both to networking and graphics. What's close to your character must be updated regularly, what happens far away you hardly notice anyway. It's basically the same principle as when doing LOD for graphics.

Most things can be cached or are scripted in a more or less rigid way. For example, once a client knows what armour a character is wearing, you do not need to resend this information until he changes armour, and even so it is very low priority. Nobody will notice if there is a 10 second delay. On the other hand, if that same character comes running at you (to engage in melee) this is an information that must be delivered in fractions of a second.

If someone casts a healing spell at someone else, there is no point in sending information about an animation or about particles. "A casts heal at B" is enough. The animation is the exact same as always (with the exception of facing another direction) and the particles are the same. The client already knows where A and B are on its screen (it does not matter where they really are, what you see on your screen matters, so even if positional updates aren't received yet, this is fine), so it can trivially animate a stream of particles going from A to B without being given this information.

It only needs to look plausible, and that's something the client can deliver with very little information.

There was an article at Gamasutra once (this one is not it, but it's a similar stripped down version) which explained in great detail how they prioritized the network updates (No.4 in the linked article). Sadly, I can't find the one I'm talking about now.


do you think that people would still be willing to play an sprite based game
Yes.

Realm of The Mad God is a 2d, sprite-based cooperative bullet-hell MMO featuring perma-death, and it's very popular. You can read a bit about the design philosophy on Lost Garden. RoTMG is an excellent example of the fact that a well-made game -- 2d or 3d -- can succeed even if it features things that many consider unpopular or unworkable.

- Jason Astle-Adams

Each packet of info has to have:

* The direction the players are moving

* The speed the players are moving at

* All lighting and particle effects for each player

* Everything else that's rendered as a result of each player

I remember on Secondlife, in some areas, I was downloading "game state" updates at 50Mb a minute

Lighting and particle effects are usually created as a result of the simulation, and has nothing to do with networking. Same with rendering. Speed and direction are usually not updated at the same time either, because you can figure out the direction by normalizing the speed.

Each packet of info has to have:

* The direction the players are moving

* The speed the players are moving at

* All lighting and particle effects for each player

* Everything else that's rendered as a result of each player

I remember on Secondlife, in some areas, I was downloading "game state" updates at 50Mb a minute

Lighting and particle effects are usually created as a result of the simulation, and has nothing to do with networking. Same with rendering. Speed and direction are usually not updated at the same time either, because you can figure out the direction by normalizing the speed.

Plus the cosmetic stuff doesn't need to be sent every packet either. Only need to send the characters customizations / weapons / armor when they first connect or change their equipment. Doesn't make sense to send it in every packet.

Each packet of info has to have:

* The direction the players are moving

* The speed the players are moving at

* All lighting and particle effects for each player

* Everything else that's rendered as a result of each player

I remember on Secondlife, in some areas, I was downloading "game state" updates at 50Mb a minute

Lighting and particle effects are usually created as a result of the simulation, and has nothing to do with networking. Same with rendering. Speed and direction are usually not updated at the same time either, because you can figure out the direction by normalizing the speed.

Plus the cosmetic stuff doesn't need to be sent every packet either. Only need to send the characters customizations / weapons / armor when they first connect or change their equipment. Doesn't make sense to send it in every packet.

Yeah, I think he meant "networked" as opposed to "in every packet".

This topic is closed to new replies.

Advertisement