Pixel based movement - costs ?

[desmonda]

i am looking for the feature: pixel based movement in eclipse.
for a start i used "skywyre custom engine" and customized a bit to learn some general aspects.
yet i fall over the barrier of fixed tile based movement. which seems to be in every eclipse engine.

so my question is, how much would an implementation cost, that allows smooth movement (client/Server) that is not tiled based?
one that doesnt break the combat system / the collision system.
one where the server is authorative and the client simulates/predicts, but in the end the server holds the state.
and still allow about 30clients to move concurrently without wasting all network/server ressources.

any experience programmer can give a hint?
am willing to spend some money, but if its out of reach, then i dont bother investigating any further.

there are not many alternatives in indy 2d ORPG/mmo engines. i only found netgore with pixel movement, but its not continued for a long while.

background:
as an it professional i design business applications. for free time I programmed on different engines for a while, but my time is limited.
(e.g. esenthel c+, hero engine, some java engines). Never released sth final that is multiplayer.
i did finish single player games. i have understanding of architectures and challenges that come with network coding.
so i am open for discussion about implementation details. even if it means talking about prediction methods, lag compensation.

ressources, that explain aspects of network mechanism, good for understand general aspects:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://www.lucedigitale.com/blog/unity3d-tutorials-multiplayer-latency-compensating-methods/
http://hewiki.heroengine.com/wiki/Replication_Tutorial

[Exception]

**I highly doubt there is anybody else who can do this effectively for you on this site.**

EDIT: just saw your addendum, so this explanation is probably redundant for you, but I'll leave it up for somebody else to read.

>! tldr: read the damn valve source multiplayer wiki, it's much more informative than this conjecture.
>! **Preface**: there are WAYYYYYYY better implementations than the following (see: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking) but having never tried to do any more than the below (which was entirely based on guesswork and conjecture), I couldn't begin to explain any other method anywhere near as concisely as this.
>! I have no interest in opening up VB6 again, but I did attempt pixel movement in the past (like, 2/3 years ago. The result was alright, the implementation was less than desirable), and I almost got it to a decent working state (I never finished combat for it). While this has its flaws and probably isn't an ideal implementation, it did work generally, so I can try provide some theory on what I did (ie. _not correct to reiterate again_) to get you started:
>! * When the player presses a direction, you send the server a flag to indicate they have started moving. The server then sends to the other clients that the player has started moving, alongside with their position.
* When the clients receive this indication, they process movement and move positions themselves.
* When the player releases the button for the direction, they send the server a flag to indicate they have stopped moving. The server sends this to other clients, and does a check to see whether the distance moved is correct (as you know the speed and the time taken, it's a simple case of calculated distance = speed * time. If their distance is out of your calculated distance [with a specified tolerance], it indicates that it should be corrected). If not, the server will fix that. The position is sent to the other clients. Because the speed is set, it's possible for the server to extrapolate where they will be at any time during the movement.
>! For collision, I let the client do the work (simple bounding boxes for each blocked tile. Could probably have done it better) and have the server verify if that was the case.
>! For battling, in theory, it's another case of letting the client do the work (I gave attacks a radius and an arc range, so players could swing in front and it would check within that sector if the opponent was there) and, again, having the server verify and actually execute the attack. I only got as far as having the client do that, no server checks were made, so battling was…interesting.
>! Flaws:
>! * By letting the client do most of the work, it's relatively easy to circumvent the checks and, well, do anything, for somebody who knows what they are doing.
* In an ideal networking environment, this works fine. In a typical networking environment (I did test this), it works fairly well with some occasional jumping from the server fixing the position. In a bad networking environment (ie. lag), in theory, this pretty much falls apart.
* lol i wrote this in one go when i had no clue what i was doing and didn't do anything to improve it, it likely sucks.
>! Again, to reiterate: there are WAYYYYYYY better implementations than this (see: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking) but having never tried to do any more than the above which was entirely based on guesswork and conjecture, I couldn't begin to explain any other method anywhere near as concisely as this.

In the event you can't find anybody, you're better off working with the constraints you have. You _could_ reduce the tile size to, say, 16x16 and work from there.

[Mohenjo Daro]

Umm, well, you could be lazy and just add more frames to movement, otherwise you'll have to shrink the tiles from 32x32 to something like 16x16, go through the code and double the view area (since you can see more smaller tiles), make sure the attributes are the right size (I think they are just put on a tile), and the mouse clicks on the right tile and not somewhere else

[Link]

Message Sherwin, last time I checked he got pixel based movement working.

[jcsnider]

Someone tell me I am wrong. But I think in order to get this working effectively you would want movement packets running in the UDP protocol. That would a secondary connection or large rewrite of the current networking system to even begin with.

[Growlith1223]

you could do a packet to the server to tell that you are moving and only send it once, when you stop moving, send another packet to say that you've stopped! that's just my thinking tho!