Ah, some fine points.
Coop DM would require specially modfied maps, cause there would be far too many 'choke-points' where the one party would seal off the second one.
Not necessarily. If a character takes up only a small portion of a tile (one quarter), then as a practical matter you could allow him to pass through up to three characters on any given tile. Working out the specific mechanics for this would be . . . interesting, let's say, but doable.
This would require some diagrams to visualize. I don't feel like mussing in Photoshop right now. Bottom line: when a player moves onto another player's tile, he occupies the first free quadrant closest to his present quadrant (so mages can stay in the back row if there are any back row slots free). Tile occupant retains precedence and will never be pushed out of his position; visitors must take the back seat until they leave the tile.
Players can change position if they're in agreement. Simply drag your icon to the desired spot, and the player there will be notified. He can then drag his own tile to your spot, and the switch is made. Or something like that. The specifics of how this mechanic is implemented are left to the designer's imagination.
The question is... how to cut down the data being/sent recieved to make modem play enjoyable while maintaining all of the DM functions?
Two words: relevant data. Send only what each client absolutely needs. One more word: compression. Both these practices are in wide-spread use and have become
de facto for network programming. Again, we're left with the problem of implementing it.
Shoot me, but people like eye-candy.
Agreed. I'd definitely want to have separate bitmaps for each character. I was merely pointing out that it's avoidable.
Keeping the games synchronized.
Not an issue. Keeping computers in sync is the easy part. Doing it in a timely manner is where the problem lies. The lock-step approach you described is called a peer-to-peer mechanism, as you probably know. It's what the original Diablo used and in general is a really bad idea. (The sync problems in that game were horrendous.)
What about other considerations, like a party with a light spell--
Always a concern of mine, only because you'd need a relatively sophisticated lighting engine. In a true 3-D engine this is simply a matter of adding a couple more lights to the scene, but in two dimensions the algorithms become ugly. It falls in the same category as rendering more than three or four cells out, which is a DM limitation I'm forever eager to circumvent. I like being able to see.
Out of curiosity though, if a DM clone was to implement multiplayer, just how would people envision it to work?
We've discussed this before. The possibilities here are endless. This depends entirely on how you want your game played.
Purely cooperative: there's only one set of objectives, and everyone is striving to complete them at the same pace. One key for each locked door; when it's unlocked, the key disappears, and everyone can move through it. No matter who completes what objective, no one risks being left behind.
E.G., Most co-op games are like this. Halo was like this, plus it conveniently teleported you.
Loosely cooperative: there's one set of objectives, and an instanced copy of each item for every player. Only one player need find the key for a particular door, but if he/she decides to lock the door after moving through it (not possible in DM, but it is possible in DM2), other players will have to find the same key, most likely in the same spot. Instancing has been pretty popular in online games lately, but I think it detracts from the cooperative feel.
E.G., Serious Sam had instanced power-ups, which was really awesome, but otherwise was a purely cooperative game. Guild Wars is 100 percent instanced.
Loosely competitive: there are two or more sets of objectives, with each player or "team" of players competing to finish them all first. The objectives for each team are similar if not identical. Players may or may not interact within the dungeon itself, depending on how it's designed.
E.G., Think of two players running side-by-side copies of DM to see who can fuse Chaos fastest.
Purely competitive: same as above, but objectives contradict and possibly overlap each other. When one team completes an objective, this results in failure for the other team, and both teams move on to the next objective. Only the winning team scores loot, points, etc., for completing the objective, thus improving its standing in the game. Players may or may not interact in the dungeon itself, though in a purely competitive environment, interaction is the operative word.
E.G., This is the mode that most closely resembles good ol' deathmatch, though better examples are: CTF, Assault, Onslaught.
Of course there are other possibilities. These seem most pratical to me. Personally, I'd opt for a hybrid with pure co-op and pure competitive, with completely different dungeons for each mode.
E.G., I can't think of any pure examples for this type of hybrid. The closest I can come is No One Lives Forever 2, which had a single-player campaign and a co-op campaign that mirrored the SP levels but with very different objectives. It also had deathmatch, of course.
Cows and I seem to be on the same page regarding the relevant data set and sending only delta updates rather than absolute values (another standard in network programming).
your engine only needs to interpret the few characters sent to it.
When considering the size of your data for network latency issues, it's important that you don't send minuscule packets. They're more likely to get lost and slow your network down. I don't know what the minimum effective packet size is, and it changes with each system, but I think it's somewhere around 4000 bytes. Yes, you want to send deltas whenever possible, and compress them whenever possible, but you also want to cram as much data as possible into each and every packet, or you're suffocating your bandwidth.
hmm.. but random thought here..
You could implement a grace period before demise, where a "dying" player can drink a potion and heal himself before his ultimate demise. Thus if the server receives both messages within, say, one second, the player will end up with +10 health, thus being alive. In this case, how
quickly you deal damage is as important as the amount you're dealing.
The zombie in Quake was like that, remember? You had to take it to -50 health within one-tenth of a second (one game tick), which could be done
without rockets or grenades if two players were shooting it at the same time.
Something in between would have to be figured out, and the issue of where to make the compromise is always the big question...
The players wouldn`t even notice that. How would you know if another player wears 6 torches or not? How would you know if he uses a light spell or wears illumulet at the moment? If I was playing mpDM, I wouldn`t care about it. I would just assume that he`s got identical light factor as me.