"Randomized" battle.

ID:273056
 
Aug 9 2009, 1:14 am
Okay, working on a system of battle similar to Final Fantasy. That is to say, walk around on the main map and then randomly you are put into a battle. However, I also need to accommodate for multiple players. I was thinking of using the /dmp_reader to do this. Is this a good idea?

For the actual deciding of when to battle, I was thinking of something like this:

area
    Entered(atom/A)
        .=..()
        if(!ismob(A)) return .
        if(istype(/mob/player1,A))
            switch(rand(1,4))
                if(1)//enemy 1 here
                if(2)//enemy 2 here
                if(3)//enemy 3 here
                if(4) return .
        if(istype(/mob/player2,A))
            switch(rand(1,3))
                if(1)//enemy 1 here
                if(2)//enemy 2 here
                if(3) return .

Is this a good way to handle what I am looking for?

If no for either, what would be a better way?
Aug 9 2009, 1:20 am
Demon_F0rce wrote:
Okay, working on a system of battle similar to Final Fantasy. That is to say, walk around on the main map and then randomly you are put into a battle. However, I also need to accommodate for multiple players. I was thinking of using the /dmp_reader to do this. Is this a good idea?

It could work. If I was to code something similar I'd create the combat maps on a different Z level then check to see if they are all in use (and if so--> create a new one). No point in constantly recreating maps, when you can leave them there for the next time they are used.

Is this a good way to handle what I am looking for?
No.

Why? Cuz. You only get area/Entered() called once, when you enter the outside border of the area. While you walk around inside the area, it wont rand anything. If you're trying to create a static monster encounter point, then what you're doing would work, but I'd advise against that unless it is a boss.

If no for either, what would be a better way?

I'd use mob/Player/Move()
Check first to see if they are in a no battle zone or already in a battle. Then check to see if the roll comes up for a battle. Then check to see which opponent they will get. You could specify WHICH opponents you can encounter using areas, and that'd be fine. But for the actual random combat probably not a good idea.
Aug 9 2009, 2:36 am
In response to AJX
I'm curious.

So you're saying that if:

A = Area1
B = Area2
M = Mob

If I move from:

AAA
MAA
AAA

to:

AAA
AMA
AAA

Entered() won't be called? But if I move from:

AAA
MBA
AAA

to:

AAA
AMA
AAA

Entered() will be called? Also to clarify, does this count for all atom's, or just area's?
Aug 9 2009, 2:08 pm
In response to Demon_F0rce
Demon_F0rce wrote:
Entered() will be called? Also to clarify, does this count for all atom's, or just area's?

Correct.

Only areas. So you could use this functionality with turfs and it'd work every time you took a step.

Aug 9 2009, 3:32 pm
Demon_F0rce wrote:
Is this a good way to handle what I am looking for?

Nope (BTW, you've got istype() args backwards there - lucky it's just hypothetical code, eh =P). First there's what AJX mentioned, which I will clarify for you - apparently you don't understand how areas work. Unlike any other atom, an /area can span over many tiles (turfs, in essence). In fact, if you haven't done anything in particular with areas in your project (so their setup remains the default), your entire map (all the turfs) is contained by a single area instance.
Logically, when something moves inside an area, Entered()/Exited() aren't called. For example, if your current location is a turf which is a part of Area A, and you move into another turf which is also a part of Area A, then Entered() or Exited() won't be called in the process (after all, you didn't enter anything - you were already in the area, and you haven't left it, either). They would be, however, if you had moved into a turf which was a part of Area B.
There's more to areas than just that, but I'm not going to cover everything about them in this post. You can always utilize the various resources (Ref, Guide, Dream Makers guild, forum search...) if you want more info about em.

Something else which isn't a good idea is how you handle which enemy to battle (and if a battle should take place, for that matter). Using switch() like that is a pretty horrible way - that means you'd be essentialy 'hardcoding' things like the enemies and as such, which leads to code duplication, bad manageability and [insert more Bad Things here]. You should do it in a more dynamic way, like an object oriented one - you could be making use of areas here. You'd split the battle-relevant map into different /areas, each representing a different 'battle zone', and each of those areas would have a list of enemy types that could be battled there (potentially with probability of encountering them as an associated value). Each area could also have other parameters. Then when a player steps into a turf and it's decided that a battle is started, you'd use that list, of course. It could look like this (unoptimized code for the sake of clarity): 
area/wilderness
   var/battle_chance = 20 //the percent chance of a battle starting after a step
   var/list/enemies //you could set this list either in subtypes, or through the map editor's Instance Editor
turf/Entered(mob/player/M) //you could also use mob/Move() - I prefer this
   ..()
   if(istype(M))
      if(istype(src.loc,/area/wilderness)) //check if we're in a 'fightable' area by checking the turf's loc
         var/area/wilderness/A = src.loc //typecast
         if(A.enemies) //if it was given an enemies list...
            if(prob(A.battle_chance))
               M.StartBattle(pick(A.enemies)) //start a battle with a randomly-picked-from-the-list enemy

Of course, the implementation (or design for that matter) may vary depending on your game and as such. For one, you have those istype(/mob/playerN)s checks in your example design which I haven't accounted for; I can only guess what you're trying to do there.