I'm planning the gameplay of a casual online role-playing game (ORPG). When it comes to the battle system in this game, I've narrowed it down to two types:

1) Turn-Based Battles --> Players take turns using attacks.

Pokemon Mystery Dungeon: Red Rescue Team

and

2) Real-Time Battles --> Players attack in a free-form manner.

The Legend of Zelda: A Link to the Past

Which system should I use, or which system do you prefer?

Here is a bit of information about this game (caution: info dump). It's going to be a browser-based game that's played online with other players. The focus is on forming parties/guilds and doing quests, making them, or just having fun with other game mechanics (crafting items and equipment, exploration, and other features that may be added after the core mechanics are in place). It might have arena-style gameplay (MOBA), where the teams compete to find an item, capture a flag, or engage in some other team-based gameplay. A core feature of this game that might be set in stone is a tournament system. This allows for one-on-one duels in a structured format. Other players can go the arena to watch the competition, there's a tourney tree, players can sign up (in-game) to participate, and there are prizes for each tier of the competition (everyone gets a prize for participating, and those who proceed to the next rounds get prizes for those tiers as well). It's a 2D game with overworld sprites.

The gist is that there are two main types of gameplay: one-on-one, and team-vs-team. In a one-on-one format, the screenshots above may represent how that might be implemented. In a team-vs-team format, the following screenshots represent possible gameplay.

1) Turn-Based

Naruto: Path of the Ninja

2) Real-Time

Naruto: Ninja Council 3

One more thing to consider is gameplay latency (lag). It might be easier to manage with a turn-based game as opposed to a real-time action game, but I don't really know because I've never done a networked game before. What do you think?

How many characters does each player control?

A turn based gameplay is less demanding in terms of latency. Beside webRTC (which is not fully available atm) or Flash based solution (can't use at mobile) , other web based solutions are TCP based, not UDP based.

Using TCP adds an overhead, also in case you use a VPS solution (cost effective reason) even jitter can be problematic.

And though I don't see myself experienced enough to say much about networking, a real time multiplayer game isn't only about broadcasting updates to clients , that would be too naive and resource inefficient. You should also consider interpolation, selective broadcast and running simulation serverside.

So a turn based gameplay means less headache.

casual online role-playing game

I didn't vote, because I don't play any casual games. But I really like turn-based games, even played the turn-based browser advertising game of dragon age, it was fun. Nevertheless, here are some opinion which might be helpful:

1. I'm big fan of turn based planning and strategy, therefor I would prefer it here.

2. I'm not a big fan of waiting in multiplayer games, turn based games tend to include long periods of waiting.

3. Turn based games are a much easier to implement !

If you want to go for a multiplayer turn based game, then you need to be really careful about the general turn design, especially if you have team vs team battles.

Personally, while I like RPGs that try new things and I could envision even a party RPG game that plays in realtime with an RTS like interface (you give commands to your chars that they execute in realtime), I vote for turnbased... I have seen enough bad implementations of realtime RPG and Action adventure systems, and simple realtime ones are usually rather boring button / mouse click mashers. Add in skills with cooldowns mapped to the keyboard, and you need to learn the intricate art of playing piano on your computer keyboard quickly... add in macro keys, and its just another button masher again.

Bleh.

I am more for RPGs that turn their battle systems into something more strategic. And while this can work in realtime, usually realtime strategy needs very careful balance of time constraints vs strategical thinking.

Add to that the already mentioned higher load on the net code due to the realtime system, and it is pretty clear to me that it is much easier comming up with a turnbased system that fits your game and technical limitations.

Thanks for commenting/voting. I might post to the Classifieds in the future for anyone who might be interested in Beta-testing. Is that an appropriate use of that section? I don't really know. If not please tell me where I can post such a thing. Alright...

How many characters does each player control?

Hmm. Well right now, it's just one. Each player creates one character in the game, and can team up with other players to form parties. If players could control more than one character, what sort of implementation would you have in mind?

A turn based gameplay is less demanding in terms of latency. Beside webRTC (which is not fully available atm) or Flash based solution (can't use at mobile) , other web based solutions are TCP based, not UDP based.

Using TCP adds an overhead, also in case you use a VPS solution (cost effective reason) even jitter can be problematic.

And though I don't see myself experienced enough to say much about networking, a real time multiplayer game isn't only about broadcasting updates to clients , that would be too naive and resource inefficient. You should also consider interpolation, selective broadcast and running simulation serverside.

So a turn based gameplay means less headache.

Ok. First, I'll have to look into TCP/UDP to find out what those are. I've heard of them before, though.

What would server-side simulation entail? I was planning to use this method:

1) On the client --> Allow the client to send a request to the server to perform some action (ex. move up), and to draw the graphics to the screen.

2) On the server --> Validate the request (see if the action is possible), do the calculations, send the result back to the client so the sprite can be drawn in the new position.

3) Repeat

I don't have a lot of networking experience. That's probably not the right way to do it.

casual online role-playing game

I didn't vote, because I don't play any casual games. But I really like turn-based games, even played the turn-based browser advertising game of dragon age, it was fun. Nevertheless, here are some opinion which might be helpful:

1. I'm big fan of turn based planning and strategy, therefor I would prefer it here.

2. I'm not a big fan of waiting in multiplayer games, turn based games tend to include long periods of waiting.

3. Turn based games are a much easier to implement !

If you want to go for a multiplayer turn based game, then you need to be really careful about the general turn design, especially if you have team vs team battles.

1. Me too!

2. Same here. One game that handles turn-based online play well is a Poker game I used to play. It was online-only, and I especially liked the way it was handled there. When it was your turn, a filled circle appeared on the screen. It gradually emptied while you decided what to do (hold/fold/raise), like a graphical timer, and that was the set period of time that the player had to make a move. You know how in competitive chess, there's a timer that they have to hit. It guarantees that turns don't exceed a certain time limit. That way, gameplay can progress at a reasonable pace with minimal waiting. If I go the turn-based route, I can define a default action that takes place when the timer runs out and proceed to the next player's turn.

3. You're right about that. One thing I dislike about real-time games is ruthless PK-ing, typically of new players who're just trying to learn how to play. If I use real-time gameplay, I'll have to define areas in which PK-ing is not allowed (no damage taken from attacks).

Personally, while I like RPGs that try new things and I could envision even a party RPG game that plays in realtime with an RTS like interface (you give commands to your chars that they execute in realtime), I vote for turnbased... I have seen enough bad implementations of realtime RPG and Action adventure systems, and simple realtime ones are usually rather boring button / mouse click mashers. Add in skills with cooldowns mapped to the keyboard, and you need to learn the intricate art of playing piano on your computer keyboard quickly... add in macro keys, and its just another button masher again.

Bleh.

I am more for RPGs that turn their battle systems into something more strategic. And while this can work in realtime, usually realtime strategy needs very careful balance of time constraints vs strategical thinking.

Add to that the already mentioned higher load on the net code due to the realtime system, and it is pretty clear to me that it is much easier comming up with a turnbased system that fits your game and technical limitations.

So essentially an online srpg? That sounds interesting. Maybe it can be implemented in a similar fashion to Disgaea 4:

I'm more familiar with turn-based games such as the Pokemon series, the Path of the Ninja series, and Final Fantasy. Also, Dragonball Z Legendary Super Warriors has a very unique turn-based battle style with offense and defense turns (it's a sort of TCG on the GBC). A classic game, for sure.

I really liked the Disgae series, especially the spin-off Makai Kingdoms. Altough I still have to finish Disgaea 4 I bought for my PS3 last year....

Anyway, just a quick thing about the networking:

One obvious problem with your quite simple implementation would be that this introduces some lag into the system. Which is exactly why Unduli suggested going for a turnbased solution because of networking. Lag of up to a second can be completly acceptable in a turnbased game. On the other hand, in a realtime game, that kind of lag would really be bad. One scond from your keypress to the cahracter acting is not going to sit well with players.

There are solutions for that, the most common involves letting clients already update graphics and sound before everything is validated, and "resetting" if needed. That might end in some slight "teleportation" here and there, but should normally hardly be noticable.

Another topic is the synchronization with other players. Because other players cahracter being displayed in your client also face this kind of lag, the client might not want to wait for the actual server input until the other players action are executed. That might make fast characters being displayed meters behind their real position (making it hard to hit them for example), or it might make an attack animation play with a lag, making timing based battle systems very hard to pull off.

You also need some kind of prediction routines here. One solution I heard about was to basically extrapolate movement from the movement of the last few frames. If a character was running in a straight line for a few frames, chances are good he will continue running for a few frames.

Again, you trade some slight choppiness from time to time because the prediction was wrong and has to be corrected (you could lerp the correction somehow in most cases to prevent that), against an almost unplayable game because of the lag.

Gian-Reto:

I see what you mean. I was actually perusing another topic that mentioned using client simulation that's verified and updated by the server. You're right about the pitfalls of using such a method (as I read), because it might cause a jump from one position to another. Just so we're on the same page, which part of my implementation would introduce that sort of lag? After considering all the previous replies, I'm leaning toward creating two gameplay modes: the battle mode and the freeroam mode. The latter is the only one in which real-time inputs would be handled by the server (such as walking through a town, or buying items from a shop). When a battle is triggered, the gameplay will change to turn-based, using timers implemented by the server. Are you referring to that portion of the game, or a real-time battle system?

I've never played Disgaea before, but I've watched Let's Plays of it. Since you've actually played it before, would you prefer that sort of gameplay in battles or the Mystery Dungeon gameplay. Both are turn-based, but I think the main difference is that one changes screens and the other doesn't. Stella Deus is another cool example of turn-based gameplay. Again, I haven't played it myself. Is it weird what I like watching Let's Plays?

Gian-Reto:

I see what you mean. I was actually perusing another topic that mentioned using client simulation that's verified and updated by the server. You're right about the pitfalls of using such a method (as I read), because it might cause a jump from one position to another. Just so we're on the same page, which part of my implementation would introduce that sort of lag? After considering all the previous replies, I'm leaning toward creating two gameplay modes: the battle mode and the freeroam mode. The latter is the only one in which real-time inputs would be handled by the server (such as walking through a town, or buying items from a shop). When a battle is triggered, the gameplay will change to turn-based, using timers implemented by the server. Are you referring to that portion of the game, or a real-time battle system?

I've never played Disgaea before, but I've watched Let's Plays of it. Since you've actually played it before, would you prefer that sort of gameplay in battles or the Mystery Dungeon gameplay. Both are turn-based, but I think the main difference is that one changes screens and the other doesn't. Stella Deus is another cool example of turn-based gameplay. Again, I haven't played it myself. Is it weird what I like watching Let's Plays?

I was referring to the idea of having realtime battles being networked with the method you described above (which omitted any prediction routine, so I though you wanted to go with the most direct way to implement it (delay client action until the action is verified by the server))... as said, the same problems are not as evident in a turnbased approach, as the player does not "feel" the lag as much (as he lacks direct control over his characters).

Control during the overworld sequences is much easier, as it is MOSTLY a one player expierience, with the other players mostly being a sidenote (they might be visible and move around in your client, but it doesn't matter much if their actions are synched with yours, as there will most probably be no collisions between player characters (to prevent griefing), and no way to interact other than chatting).

You will still need to verify things on the server (to prevent cheating players from walking through walls or buying in the shop without paying), but don't have to work as hard because pacing on the overwolrd map usually is slower, and correcting a prediction will look less off (if the player needs to be reset to a position because he tricked the prediction routine into not recognizing the wall and letting the player walk into the wall, you could do that in away that is hardly noticable (how fart into the wall can a character walk in a second?), or maybe even use an animation to hide the fact you are moving the character back (the "hit the head on a wall" animation)... you could even instruct the client to not let the player walk into the same direction as long as he doesn't move from the spot to temporarily harden the prediction routine against cheating).

Cannot really talk about the mystery dungeon series. The Disgea games are quite similar to the Vandal Hearts series from the battle system, and it is a system that is much more akin to chess than classical pen and paper RPGs.

Because your characters move on a map, have a set move and attack distance, positioning becomes the most important factor in battles, more important than slight level differences between opponents. Position in a way so you can strike first, and even better, you can strike with more characters against fewer, and you usually win. Make a mistake, underestimate the AI, and your lone character will be butchered by multiple enemies, even if they are low level grunts.

What I really liked about Makai Kingdoms was how it added vehicles (tanks for example) to give the player further options. Vehhicles usually had more range and superior armour and weaponry, but you only had like one of them, and they needed to be boarded by a character to work. The other Disgea games have mounts as a similar concept.

There is a clear skill component to the battle system, and that is mostly tactical thinking. The hit / damage / evade rolls might still be random like in usual RPGs, but to win a fight you had to utilize some simple yet important strategies concerning positioning. And because positioning is so important, the battlefield itself becomes important. Depending on the terrain and obstacles in the way, you could use the terrain to your advantage, while also needing to make sure to pick the right route for the right character so they would be able to attack the same enemy in the same turn.

Also, because of the alternate activation, you always had to be careful when attacking enemies that weren't activated yet. Setting up three or so of you characters to attack, moving in with your first character to do the first third of the damage to kill that enemy, only to have it move out of harms way before the other two could attack is a sure way to waste two of your characters damage potential for a turn. And depending on how well the AI is written, you might not get a second chance, as the enemy might now be in range of his buddies, and any of your characters that reach him next turn will get stomped by the superior force.

Gian-Reto:

I see what you mean. I was actually perusing another topic that mentioned using client simulation that's verified and updated by the server. You're right about the pitfalls of using such a method (as I read), because it might cause a jump from one position to another. Just so we're on the same page, which part of my implementation would introduce that sort of lag? After considering all the previous replies, I'm leaning toward creating two gameplay modes: the battle mode and the freeroam mode. The latter is the only one in which real-time inputs would be handled by the server (such as walking through a town, or buying items from a shop). When a battle is triggered, the gameplay will change to turn-based, using timers implemented by the server. Are you referring to that portion of the game, or a real-time battle system?

I've never played Disgaea before, but I've watched Let's Plays of it. Since you've actually played it before, would you prefer that sort of gameplay in battles or the Mystery Dungeon gameplay. Both are turn-based, but I think the main difference is that one changes screens and the other doesn't. Stella Deus is another cool example of turn-based gameplay. Again, I haven't played it myself. Is it weird what I like watching Let's Plays?

I was referring to the idea of having realtime battles being networked with the method you described above (which omitted any prediction routine, so I though you wanted to go with the most direct way to implement it (delay client action until the action is verified by the server))... as said, the same problems are not as evident in a turnbased approach, as the player does not "feel" the lag as much (as he lacks direct control over his characters).

Control during the overworld sequences is much easier, as it is MOSTLY a one player expierience, with the other players mostly being a sidenote (they might be visible and move around in your client, but it doesn't matter much if their actions are synched with yours, as there will most probably be no collisions between player characters (to prevent griefing), and no way to interact other than chatting).

You will still need to verify things on the server (to prevent cheating players from walking through walls or buying in the shop without paying), but don't have to work as hard because pacing on the overwolrd map usually is slower, and correcting a prediction will look less off (if the player needs to be reset to a position because he tricked the prediction routine into not recognizing the wall and letting the player walk into the wall, you could do that in away that is hardly noticable (how fart into the wall can a character walk in a second?), or maybe even use an animation to hide the fact you are moving the character back (the "hit the head on a wall" animation)... you could even instruct the client to not let the player walk into the same direction as long as he doesn't move from the spot to temporarily harden the prediction routine against cheating).

Cannot really talk about the mystery dungeon series. The Disgea games are quite similar to the Vandal Hearts series from the battle system, and it is a system that is much more akin to chess than classical pen and paper RPGs.

Because your characters move on a map, have a set move and attack distance, positioning becomes the most important factor in battles, more important than slight level differences between opponents. Position in a way so you can strike first, and even better, you can strike with more characters against fewer, and you usually win. Make a mistake, underestimate the AI, and your lone character will be butchered by multiple enemies, even if they are low level grunts.

What I really liked about Makai Kingdoms was how it added vehicles (tanks for example) to give the player further options. Vehhicles usually had more range and superior armour and weaponry, but you only had like one of them, and they needed to be boarded by a character to work. The other Disgea games have mounts as a similar concept.

There is a clear skill component to the battle system, and that is mostly tactical thinking. The hit / damage / evade rolls might still be random like in usual RPGs, but to win a fight you had to utilize some simple yet important strategies concerning positioning. And because positioning is so important, the battlefield itself becomes important. Depending on the terrain and obstacles in the way, you could use the terrain to your advantage, while also needing to make sure to pick the right route for the right character so they would be able to attack the same enemy in the same turn.

Also, because of the alternate activation, you always had to be careful when attacking enemies that weren't activated yet. Setting up three or so of you characters to attack, moving in with your first character to do the first third of the damage to kill that enemy, only to have it move out of harms way before the other two could attack is a sure way to waste two of your characters damage potential for a turn. And depending on how well the AI is written, you might not get a second chance, as the enemy might now be in range of his buddies, and any of your characters that reach him next turn will get stomped by the superior force.

Ok, I got it. Thanks for the detailed reply. Basically, in a real-time battle system, the client would also simulate the game but the server will correct it if something's off. I was a bit reluctant to do anything more than draw with the clients because so many people mentioned that anything more could be hacked and allow cheating. Not to mention, I'm also trying to decide if I should really do a browser game or make a desktop client. Geez, why can't people just play the game? Anyway, I have a bunch of networking questions now (trying to learn about packets), so I should probably ask those in the Networking forum or scavenge the Internet for some info.