First things first, this IS an MMO I am actually working on, but before you turn away, there are some things I should explain first. 1. I am aware of the hardware requirements of an MMO, both client and server side. To allow for this, I am drastically reducing the amount of data that needs to be sent both ways. For one, in a lot of MMOs these days, movement seems to be pretty complex, with a lot of range of motion (WoW, wtf lol) up to and possibly over 256 different directions. I have 8 different directions the player can move in. While this does really make what comes across as over simplification, I don't exactly have a lot of dedicated resources. Since I don't give the player metric assloads of directions to move in, I can do one of two things now: further decrease server load by lowering the updates per second, or I could keep them the same and implement my next idea: command queuing(sp?), but I'll explain that later in the post. 2. I am aware that, even with all my reductions I have planned, that self-hosting an MMO is highly impractical. I'm not even thinking about hosting this myself. My main plan at the moment is to host a miniature version of it with a player cap of about 30 - 50 just to mess around. Given the size of the world, though, a 30 - 50 player cap would be barely noticeable. What I plan to do with the client and server is basically just toss a download online and let people do what they want with it. Now that my disclaimer is officially over, I can begin the bulk of my post. Basically what I want is help with hammering out a few ideas I'm working with in order to get a better grasp of how to implement them before I begin the bulk of coding. The first of these ideas is "command queuing". COMMAND QUEUING Basically, I thought of this idea as I was trying to further reduce the amount of information that had to be sent to and from the server, and also may allow me to implement a basic combo system. The primary idea is that the player can enter a sequence of commands (probably a maximum of 5) that would then be sent to the server in a single message, as opposed to an individual message per command. Since I'm using a single message, I could havethe game automagically find combos in the sent commands, asllowing for more elaborate attacks. The good: 1. Allows me to reduce server load by sending more information in a single message. 2. Allows me to very easily implement a combo system, furthering my goal for an MMO that rewards skill over levelling. 3. Pretty easy to implement as a whole The bad: 1. I'm using UDP, which means its possible that the message will not be recieved by the server unless I put in some sort of verification system. 2. A verification system would probably increase server load, and is one of the reasons I'm not using TCP. 3. Depending on how much I dedicate to the client, it could be VERY easy to hack. Now, that explains nicely my command queuing system, but I would like other opinions on it, and information on how I can get over some of the shortcomings. Also, if anyone here has any idea on how I can further reduce the need for levels, I'd be glad to hear them.

Quote:Original post by DarkZoulz
Sounds like a pretty neat idea. Though, i'm not sure what you mean by directions. I'm sure most 3D games use vectors for movement. I'm no expert with network programming, but 3 floats for x,y,z = 12 bytes can't be your biggest concern while designing a protocol, or?

Oh shit...

I thin I can see why I was stressing over that so much earlier, I totally fucked up my conversion and got 12 KILObytes.

Me for the win :(

-- this post made no sense --

[Edited by - AnonymousPosterChild on March 12, 2006 1:00:50 PM]

Quote:Original post by Anonymous Poster

Quote:Original post by Steadtler
kinda belong in networking, no?

I dont think this system is feasable for a networked beat-them up. Im having trouble explaining why in words, altough it seems obvious to me. In networked games, only the server knows the real state of the game, every client gets a varied slightly delayed view. If I hit *punch*, the client should not be able to know if the punch landed. It send a 'punch command' message to the server, which updates the game's state and send new info to the clients, who gets to see if the punch landed or not.

So lets say I have a ping of 100ms, and that I need half a second to enter a 5 key combo. That means I will have a least a 600ms delay between hitting the first punch and seeing if it lands or not. That means every combo will have to be done "blindly". That also means that combos can't really be interrupted by the opponent.

So not practicable in a real-time game.

If its Turn-based or pseudo turn-bases, then ok, altough a TB beat-em-up sounds wierd :)

The entire game could be in a Matrix-style slo-mo....

It could be the 'slowest fast game' on the internet!!!!!


The OP needs to consider that the stripping a few bytes out of the communications will be the least of the problems of making an MMO.....

Yeah, because I don't know that already :P

And where did I ever say this was real time? A real time implementation of ANYTHING on an MMO scale is pretty much impossible at my skill level.