Battle Screens in Design Philosophy

ID:426003
 
Mar 2 2012, 7:41 pm
Currently I have a Larger RPG project on my workbench, slowly coming together. The battle system is turn based and will require a custom battle screen for player groups to fight monsters (or each other) in. My first idea was map-instancing where we simply copy the small battle map onto a new z-layer. Several battle maps could be loaded onto a single z-layer before another one would need to be created to house more, but once they aren't in use anymore, they are deleted to conserve memory, of course. My only concern is efficiency. The most I really expect at any time would be ~20 battles at a time, if my project happens to be likable. I've seen battle screens done in client.screen, but have heard such awful things about latency and whatnot, but my concern is that the overhead generated by constant map-area creation and destruction might be too much for a general server to handle.

I would like to know if my map-instancing solution would be more efficient than a client.screen based one. Or if there are any other solutions that would work the same and be just as/more efficient, I would like to hear those too.

Thank you in advance for any feedback given on this query.
#1 Mar 2 2012, 9:09 pm
Well, how i said and the only ways i know are the creating temporary Z-levels or using client.screen (I'm not sure if the latency rumor is right).

I've made my Pokémon Demo by the two ways you've said. (Client Screen with multiple maps and Z-levels). I just have the Client Screen demo if you want to see capabilities (http://db.tt/1gFDmDQK). And it isn't Multiplayer, i've had that planned to stress test.

On-Topic: Well, i think map-instancing would be better. People fights in that Z-Level and then leaves it, but instead of deleting it we keep the level so others may use it so we don't create needless Levels (Unless the other ones are full).

I hope you understand.
#2 Mar 2 2012, 9:11 pm
Basically, a z-level may hold a number of battles, but if it's not in use at all, eg, no battles are fought on it, then it's deleted. I thought this system would work best too, though I just needed a few opinions on it.
#3 Mar 2 2012, 9:56 pm
Well, i'm not sure if it would be possible and if it's the best way but if you want to hold multiple battles in a Z-Level you could check each X (X = amount of turfs for a battle background) turfs to see if there's a player.
#4 Mar 3 2012, 7:48 am
Using instanced maps gives you a lot of flexibility because you're using objects on the map. It's easy to create new objects or make things move. You create an object, it's there for everyone to see it. You don't have to manually add it to everyone's screen. It's also easier to make objects on the map move than it is to make screen objects move.

It really depends on what combat will look like. If it's going to be a fairly static screen (like Dragon Warrior), using screen objects isn't a bad way to do. If it's going to be the slightest bit dynamic (even like old Final Fantasy games, where characters step forward to attack) it will be easier to use instanced maps.
#5 Mar 3 2012, 9:45 am (Edited on Mar 3 2012, 9:52 am)
If I were to use a separate map for battles, then I would just have one battle "area" per battle background, then I would use invisible mobs attached with /images. That way you can still have the normal atomic movement on the map without having to worry about you seeing other players.

Assuming you have multiple map backgrounds, this eliminates the need to have 10 snow battle screens if you have 10 groups fighting in the snow area. Not to mention you don't have to create more areas if the ones you have are full. Or combine the two and use client.screen for battle backgrounds leaving you only needing one battle area.
#6 Mar 3 2012, 9:54 am
Using images might be fine, but for some types of combat it can cause problems. If you had a tactical battle system where mobs can move around, you'd have to make sure that two mobs on the same map but in separate battles can move through each other. All graphical effects would have to be done with images (which can't, as far as I know, be flicked). It can also cause problems if you use procs like oview() because it could list mobs involved in other battles.

I'd just use one battleground per instanced map and place mobs directly on it. If you want to improve things, keep track of which battlegrounds are in use and don't remove them immediately after a battle is complete. If you have 10 players in battles in snowy areas you'll need to create 10 snow battle screens, but you can keep them around and re-use those same 10 screens when those players all get in combat again. You can free up battleground maps a few minutes after battle ends - if 5 players leave the snowy area after a minute or two you can detect that 5 of the snow battlegrounds haven't been used lately and aren't needed. They can be replaced with other battlegrounds you need to create.
#7 Mar 3 2012, 3:15 pm
Thank you, guys, this was wonderfully informative. Tenkuu your idea sparked a system that might work even better. F_A did bring up a legitimate concern in respect to your /image object idea. Here's the idea I formulated as a compromise to both of your idea's and let me know what you think.

Battle maps are static, meaning that there is 1 map for each different area. This will remove the overhead that would be created by constantly creating and deleting maps. When a battle starts, the player's characters themselves will either, A, rendered invisible and non-dense for the duration of the fight, or B, simply be greyed out or something, along with non-density, whichever I chose. The client.eye will be moved to the centered position on the battle map. Each player will have HUD objects for Battle Options. It's already been decided that I'm going to use Battle Icon's and Overlays for each player and monster, so there's no extra work there. /Image objects will be created on their respective area's and output to the players in that particular battle. Since the whole system will be purely visual (Battle icons will move to attack, but no "position getting" will be done), it eliminates the chance for interference with other battles in respect to density and what not. Each player will have a "Battle Dummy" with their own armor overlays and whatnot that will preform the animations for the attacks and such.

I think that this is the overall best method of handling battle screens based on the input given. The battles needn't be more than visual effects anyways, so I see no need to make them anymore than such. I thank both of you for the idea, because without either one of you two's input, I wouldn't have been able to gather the best method that both captured the bare essential of what I needed while still remaining very lightweight and efficient.