random battle system??

Page: 1 2
ID:158974
 
Jun 4 2009, 9:43 am
hey guys

i need some help agen

i am lookin at makin a random battle system similar to the one's you see in pokemon and final fantasy type game where when you take a step it will decide if you have walked into a battle


i thinking you will need a if statement and a rand number statement in there some where but i dont know how to go about it :S

any ideas??

Jun 4 2009, 9:48 am
Make an area with an overridden Entered() proc that will set a player's variable to whatever. Then override the player's Move() proc to check for that variable being true and running an if(prob()) check to decide whether or not to have a pokemon pop up and attack.
Jun 4 2009, 9:57 am
In response to Spunky_Girl
thanx i will try it
Jun 4 2009, 9:58 am
In response to Petza
Forgot to mention that you'll also need to override the are'as Exited() proc to reset the player's variable back to whatever.
Jun 4 2009, 10:04 am
In response to Spunky_Girl
thanx how do you go about using the overridden Entered() proc???
Jun 4 2009, 10:07 am
In response to Petza
 
area/some_area
    Entered(atom/movable/a)
        if(ismob(a))
            var/mob/m = a
            m<<"You've entered an area! :D"


That's how I override the Enter/Exit procs :)
Jun 4 2009, 10:09 am
In response to Spunky_Girl
thanx
Jun 24 2009, 6:55 pm
In response to Spunky_Girl
Spunky_Girl wrote:
Make an area with an overridden Entered() proc that will set a player's variable to whatever. Then override the player's Move() proc to check for that variable being true and running an if(prob()) check to decide whether or not to have a pokemon pop up and attack.

Or try this:
turf
    Mon01
        icon='Area.dmi'
        icon_state="1"
        var/mob/B
        Entered(mob/A)
            if(ismob(A))
                var
                    D1 = rand(0,9)*10
                    D2 = rand(0,9)
                    Dice = D1+D2
                A<<"[Dice]"
                if(Dice <= 10)
                    A.LX=A.x
                    A.LY=A.y
                    A.LZ=A.z
                    A.loc=locate(1,1,2)
                    B = new /mob/bug()
                    B.loc=locate(1,2,2)
                    B.lv = 1
                    B.HP = 50
Jun 24 2009, 7:35 pm
In response to Prf X
Yeah... that won't even compile. Nice try. You cannot define a brand new variable during runtime like that. I'm not sure if I even understand any of that anyways (it's also 1:36am where I am, so I'm tired).
Jun 25 2009, 4:40 pm
In response to Spunky_Girl
Spunky_Girl wrote:
Yeah... that won't even compile. Nice try. You cannot define a brand new variable during runtime like that. I'm not sure if I even understand any of that anyways (it's also 1:36am where I am, so I'm tired).
It compile & runs,
try it & see
Jun 25 2009, 4:52 pm
In response to Prf X
Yeah I re-read it a few times in the morning to make sure, and I did read it wrong the first time. But in either case, what you're doing is a much longer version of what I told him to do, and a "once-per-area" thing rather than a "once-per-step" thing like it should be.

However, now that I think about it, you don't even need to use Entered() and a variable >_> Just use Enter() and a prob() and whatever "monster popping" programming you have going for you.

area/grass_effect
    Enter(atom/movable/a) //every step taken in a grassy area...
        if(ismob(a))
            var/mob/m = a
            if(prob(10)) //10% chance of a monster popping up
                //whatever "monster popping" programming you have, put here
                //remember to use the new() proc's arguments!!! (hint hint, Prf X >_>)


EDIT
I apologize to the OP for my terrible advice in my first post. What was I thinking, eh? Override Entered() and Move() to achieve the same exact effect as a single overridden Enter() could do... Shame on me. x_X
Jun 25 2009, 6:06 pm
In response to Spunky_Girl
Spunky_Girl wrote:
remember to use the new() proc's arguments!!! (hint hint, Prf X >_>)
It on line 17 
B = new /mob/bug()
Jun 25 2009, 6:07 pm
In response to Prf X
Yes. You've demonstrated that you do not use the new() proc's arguments like you should ^-^
Jun 25 2009, 11:43 pm
In response to Spunky_Girl
What were you thinking now? ;P
But seriously, this is getting a little old; you've been specifically told many times already that you should not use Enter() for these kinds of things, so pay a little more attention.
Explanation: Enter() isn't supposed to do any actual, real "action" (that affects something), only determine whether a movable should be allowed to enter the source or not (by its return value). It could also be called by pathfinding and similar functions, so if you do arbitrary stuff in it, Bad Things will happen. You also need to be careful to keep the return value of Enter() intact or proper (which you haven't done).
If you want to do something after a movable has entered a location, use Entered(): 
turf/grass/Entered(mob/M)
   if(ismob(M) && prob(15))
      //(start a battle and stuff)
      M.StartRandomBattle(...)
Jun 26 2009, 3:14 am
In response to Kaioken
That will only do the random battle scenario once per patch of the grass you've entered, rather than once per step taken in any sort of grass, like what the Pokemon gameboy games do.

If there's a patch of grass, 3x3 tiles, then your method will only do the probability of a battle once: that first step taken into the grass. But if you take a second step, and are still in that area, then the probability will not be calculated again, since you've used Entered() and not Enter().

However, since you've said that Enter() is not supposed to do anything other than determine whether or not a movable atom should be allowed to enter it, I guess the OP will have to use my original idea if he would like the probability calculation to happen every step taken within the area, and not just calculated once. :\
Jun 26 2009, 3:22 am
In response to Spunky_Girl
Spunky_Girl wrote:
You cannot define a brand new variable during runtime like that.

Yes. You've demonstrated that you do not use the new() proc's arguments like you should ^-^


You never cease to amaze me with your horrible advice, programming practice, and ridiculous comments.
a) I see nothing overly wrong with defining a "brand new" variable at run time, as was posted.
b) IIRC, the only argument of new() for most things is just the loc, and he sets it right after... hardly worth whining about for 2-3 posts.
Jun 26 2009, 3:37 am
In response to Ephemerality
You never cease to amaze me with your late posts about something that I've already commented about and apologized for. I said that I read it wrong, did I not? I believe I had thought he wasn't defining a new "local" variable, but a new atom|world|client kind of variable, which you can't do at runtime (I admit that I have tried in the past... way in the past).

This may be asking for too much from you, but please read all the posts before thinking about making a reply, please. I've made my share of replies like yours, and I hope to stop that to be honest :\

I also guess that my method of Entered()/Exited() and Move() is bad programming practice. Unless you were talking about my method of Enter(), in which case, Kaioken solved by just turning it into a proc call. Minor correction and hardly constitutes a little temper tantrum from someone like you (also makes it more modular :D).
Jun 26 2009, 3:42 am
In response to Spunky_Girl
Something can't "never cease to amaze" if it's only done once.
I did read all the posts and still felt that it deserved a proper comment, regardless of what you later admitted.

It is certainly asking too much. Bad (read: awful) advice once or twice from you is fine, but you do this all the time. Constantly. Hence my comments.
Jun 26 2009, 3:49 am
In response to Spunky_Girl
Spunky_Girl wrote:
That will only do the random battle scenario once per patch of the grass you've entered, rather than once per step taken in any sort of grass, like what the Pokemon gameboy games do.

No; note I've overridden it on a /turf, not /area. This means it's called every time you enter a grass turf, so if you step into one and then step into another, it's called twice, as desired. Besides, using Entered() instead of Enter() wouldn't really make a difference on this sort of thing.

Also, unfortunately I have to partly agree with Ephemerality there; it's also not the first time you were told such a thing. It'd be a good idea to learn some more and validate things (such as by experimenting and reading the Reference) first if you're going to help people.
Jun 26 2009, 3:50 am
In response to Ephemerality
I don't mean to offend you with the following comment...

That's what I hate about schoolteachers nowadays. When you do something wrong, and you know you did something wrong, the teacher still tells you that you did something wrong -.- (most of the time, many times).

I guess what I'm trying to get at, is that if I'm unaware of the mistake, by all means please tell me about it... once. But if I am aware of the mistake, like Kaioken made me aware of and provided a simple remedy (which I will utilize in the future for sure :D), I don't like being told by many different people about the same mistake. v.v; It's just repetitive and quite frankly annoying when I'm already aware of it. In this case, the Enter() thing.
Page: 1 2