ID:265976
 
It's long been debated, at least to my knowledge, the feasibility of a multiplayer game running based off of pixel based movement.

Is it possible, if written condensely to run well with a server of 20 players, and 200-300 mobs with archaic/basic AI.
You'll have to be more specific about the needs of your game.

The new netcode allows for pretty good pixel movement across the 'net, but it degrades pretty quick as the number of players increases. The network update is pretty new, and I haven't played with it much, so I can't offer any estimates as to how many players the average server can support while still offering a fidelity that makes pixel movement worthwhile. That said, I've heard Decadence runs pretty well with 8 players, but I haven't gotten around to trying it.

On the other side of the coin is of course processor usage, which I'm guessing is what you're more concerned about. As I said earlier, we'll need to know more about your plans to offer any specific suggestions.

Generally, collision detection is the biggest bottleneck of a pixel-based system. This can be mitigated by designing the game to limit or manage how many things are moving at once. For example, those 200-300 mobs probably don't need to be moving and running collision checks when there aren't any players in view. Not checking for collisions with other mobs and limiting all "collidable" objects to full tiles are other possible optimizations if your gameplay allows for them. If you're allowing 360° movement, you should optimize your trig functions by caching the necessary results and limiting the angles mobs can move at (and of course cache any directional icons generated).

I can't really offer any more help without knowing more about the needs of the gameplay.

Is it possible? Yea, if you design the game around the constraints. But you have to be willing to cut any grandiose ideas down to a more manageable size.
In response to DarkCampainger
RE: collision detection, be sure you know of and use appropriate optimisations. Specifically, some sort of hierarchical collision detection system, likely including some form of BSP tree or quadtree, will significantly reduce the amount of processing required.
In response to DarkCampainger
Here are the stats from the last series of Decadence beta sessions. Chatters is what's normally hosted on the server, you can see the huge spikes in bandwidth usage whenever Decadence went up.

Before the network update online play was choppy. You almost never saw pixel projectiles in the air for more than a tick, movement wasn't as responsive as it should be, and any animation which wasn't using flick() was almost always cut off. After the network update online play became almost identical to offline play. Movement became precise, pixel projectiles could be seen flying all over the place, and animations not using flick() were displayed correctly.

There were a few global slowdowns, but I believe those were just caused by the server itself. Anyone who's ever been in Chatters knows the server has a history of suddenly lagging for no reason. The 8 player limit was for gameplay purposes, seeing as how the maps weren't designed for 40 people.

Some people did experience lag, but it was on a case by case basis. If one person was playing on 56k, he was the only person lagging. It didn't seem like one person could slow down the whole server, they just complained a lot. During the first few days of testing the server seemed to get slower and slower and the only way to fix it was by relogging. This wasn't BYOND's fault, it was my own bug. After correcting the bug players could play indefinitely, the game didn't need to reboot and players didn't need to relog.

I haven't had a chance to sit and record bandwidth usage with RetroGame. Hosting from my home computer seemed fine with about 6 people logged in. I've yet to do any extensive testing with it. I really wish BYOND had a built-in packet profiler to monitor these sorts of things on its own.
Mr.Tophat wrote:
It's long been debated, at least to my knowledge, the feasibility of a multiplayer game running based off of pixel based movement.

Is it possible, if written condensely to run well with a server of 20 players, and 200-300 mobs with archaic/basic AI.

I'm currently using pixel movement with the 'bounding box' collision method, with around 5 people logged in, and 30 or so AI running around, the game was still running smooth and the CPU never reached over 15 for over 2 seconds. This was due to a ton of gun fire and all of the AI suddenly noticing my presence. Of course, I am sure the AI could be made more efficient and the CPU would drastically decrease.

So overall, I believe 20 players and 200-300 mobs could work, if those 200-300 mobs are not moving constantly when no one is around.
In response to Calus CoRPS
I'm also using a "bounding box"-esque algorithim. However, I run it for when movement is demanded it checks the contents of all the squares it will be moving into. (With objects and mobs as the content) each "content" comes with with a set of two coordinates (if it's blocked is true) (x1,y1) and (x2,y2) so that if the attempted movement is blocked by these relative coordinates in the contents of the boxes it will be violating it doesn't allow movement to happen. However, if movement does succed; then the object is removed from the contents of squares it does not belong in, and is added to the squares it is currently in.

Movement should be static from mobs, unless noticed by players; so that's reassuring.

Um, I'm revamping my system to work this way, I'll post a demo later in this thread, with AI charging the player to see how it runs... Project for the evening :D

Sorry if i was ambiguous with my explanation, if you need further explanation; I'm happy to respond to any questions.

PS Movement happens from players and mobs every 1 to 2 deciseconds. (It's random for AI between 1 and 2 to help keep them not as potentially fast.)
In response to SuperAntx
Thank yew!
In response to Jp
Link? This went over my head, but I'd love to learn.
I'd say network usage would be least of your problems, you'd have to overwrite all collision detections, including walk_to(wards), step_to(wards) and etc.
In response to Mr.Tophat
Well, you can always look up quadtree and BSP tree on Wikipedia.

But basically, you're splitting space up into regions - you can use a quadtree as a sort of 'spatial index' of the data. In this context, by 'quadtree', I mean 'a tree data structure in which every child has four nodes, and those four nodes split up the space occupied by the parent into quarters'.

You subdivide your map into these regions, and then when testing what you collide with, you test against the quadtree. If you intersect, the quadtree node tests each child of it against the object, and so on down to the leaf nodes of the quadtree, which have a list of all the things inside of it.

A simpler solution is just to overlay a coarse grid over the top of your map - so a grid with cells ten map squares wide or whatever, depends on your map - and then only test things in your grid cell and neighbouring cells.
In response to DarkCampainger
My favorite way to discriminate make collision more efficient is to only check what needs to be checked. For example, if none of my turfs are dense, I won't check them. Or, a better example is my current project, in which enemies can't collide with each other, and as such, I only check if enemies are colliding with the player.