click and click again

ID:162171
 
Feb 18 2008, 11:41 pm
How can I make it so you can click to select a mob then click to select the enemy the mob should attack

If I put a click command inside a click command I get a error saying proc definition not allowed inside another proc
Feb 19 2008, 5:04 am
 
mob
    var
        controlling

    dummy
        var
            owner
            target
            
        Click()
            if(src.owner)
                if(src.owner == usr)
                    usr.controlling = null
                    src.owner = null
                    usr <<"[src] is no longer under your command!"
                    for(var/mob/monster/M in world)
                        if(M.attacker == src)
                            M.attacker = null
                else
                    usr <<"[src] is being controlled by someone else!"
            else
                for(var/mob/dummy/D in world)
                    if(D.owner == usr)
                        D.owner = null
                        D.target = null
                usr.controlling = src
                src.owner = usr
                usr <<"[src] is now under your command!"
                
    monster
        var
            attacker
            
        Click()
            if(usr.controlling)
                if(!src.attacker)
                    for(var/mob/dummy/D in world)
                        if(D.owner == usr)
                            D.target = src
                            src.attacker = D
                            // ATTACK PROC
                            
                else
                    usr <<"[src] is already under attack!"
                
            return


Test it, because I quickly wrote it and tossed it up here.
Feb 19 2008, 8:36 am
 
proc
    do_combat(villian as mob,victim as mob)
        // put code to handle the battle here

mob
    var
        attacker
    Login()
        attacker = null
        usr << "Click a mob to select the villian"
        ..()
    Click()
        if( usr.attacker )
            usr << "You told [usr.attacker] to fight [src]"
            spawn() do_combat(usr.attacker,src)
            usr.attacker = null
            usr << "Click a mob to select the next villian"
        else
            usr.attacker = src
            usr << "Now click a victim for [src] to attack"
        ..()


In the above example, any mob can be a player, a villian, or a victim. It can even be all 3! You can filter out unwanted situations with more if's.

Edit: forgot () after spawn. I don't know if there are other bugs in the code...sorry
Feb 19 2008, 2:28 pm
In response to Siientxx
So there is no way to have a click command inside a click command?

This code does open my eyes to a few new options, but
The player creates mobs (so there could be lots of them on the screen some his some other players)
When player clicks on a mob then clicks on a enemy it should attack, if he clicks a mob then clicks a turf he should move there
This code could do that, but when he clicks his mob and clicks another one of his mob the first one is not deselected furthermore if he cicks an enemy the code is only looking at one dummy mob when there could be 10 next to enemy some his some not his and only one should be under his control
I will mess with your idea a bit but hoping for a better way about this,

I was thinking would be similar to a clickable chess game
Feb 19 2008, 4:42 pm
In response to Warriormax
Don't expect me to code your entire game, or specifics in extreme detail. I gave you what you wanted.
Feb 19 2008, 5:19 pm
In response to Siientxx
Lol, not what expecting :) just mainly wondering how the enemy will know which players mob is attacking it. To me looked like enemy only was checking one mob/dummy I guess my main question was how do I make it so it checks any in an area

Sorry if not specific
Feb 20 2008, 8:35 am
In response to Warriormax
I wonder if you just need a way to organize your problems so that they start to form into conditions for coding?

So let's step back a bit from the code and look at the problems and solutions.

Here's how I do it:

Problem: How do objects know who owns them?

Anytime I want an object to "know" something, I have to give it a variable. This is like giving the strawman a brain. Now it can remember something.

So stick a var on the mob so each records their owner, such as var/mob/owner.

How does the system let me only select friendly mobs? Well, what does "select" mean? It means "remember the friendly mob I last clicked" Who am "I"? My logged in mob.

So I need another var so that if it is logged in it can remember which owned mob it last selected, such as var/mob/lastpetselected. I use the term 'pet' because that is what they are usually called in muds.

When I click on a mob, sometimes I am selecting it as a friend. Sometimes I am selecting it as an enemy. How can I deal with this?

Well whenever "sometimes" comes up in a problem, I need to organize it into each different condition. How do I identify the condition and what do I do about it?

The way I do this is to organize the conditions into a flow of thought that is like a tree.

Questions for mob/Click()
Is src.owned==usr ?
yes: usr.lastpetselected=src
no: usr.lastselected attacks src

In the above, if I select a pet, my mob remembers that it was last selected. If I select anything else, the last remembered mob attacks it.

But what if I don't have any pets? Can I still click on my logged in mob to select it? Nope! So I better set up the login so that players always own their logged in mob:

To-do's for mob/Login()
1. src.owned=src

Now even if I don't own a pet, I at least own myself.

Back to the Click() thought flow... we still have a problem. What if I never clicked on my mob? Then lastpetselected is just null. I am asking a null to attack src! That isn't good, so I should put that condition in my thought flow.

Is src.owned==usr ?
yes: usr.lastpetselected=src
no: Is usr.lastpetselected true ?
yes: usr.lastpetselected attacks src
no: usr << "Click on a pet 1st"

A note on whether or not usr.lastpetselected is true: anything null, "" (empty string), or 0 is considered false by the if() command. The rest is true.

That's one way to do it. Another way is to make sure usr.lastpetselected always has something in it. Why not set it to my logged in mob whenever I connect?

To-do's for mob/Login()
1. src.owned=src
2. src.lastpetselected=src

Then I can go back to the simpler thought flow for click:

Questions for mob/Click()
Is src.owned==usr ?
yes: usr.lastpetselected=src
no: usr.lastselected attacks src

That's part of the design process. Sometimes the solution to handle a situation is overcomplicated and it is better to just make sure the situation never happens.

Now, what is the user going to see when they click on a pet? Nothing. So maybe I want to have 2 icon_states. One is a version of the icon when I click it, another when I don't. Now instead of usr.lastselected=src, I have to do a few things. Well if I itemize all of those tasks in the decision tree, it starts to get cluttered. How about keep it simple and move the details into a separate procedure? I like this approach because when I am debugging a bunch of if/else stuff I just want the conditions to be the main focus of thought. So unless there are very few things to do in each condition, I'd rather put the details elsewhere to keep the conditions uncluttered.

Questions for mob/Click()
Is src.owned==usr ?
yes: selectpet(usr,src)
no: usr.lastselected attacks src

To-do's for mob/selectpet(U as usr,S as src)
1. change usr.lastpetselected.icon_state to unselected
2. change usr.lastpetselected to src
3. change src.icon_state to selected

This is assuming I made 2 states in my icon editor called selected and unselected, of course.

Now we have a problem: when I login, my mob won't look selected yet. Need to add that to the list.

To-do's for mob/Login()
1. src.owned=src
2. src.lastpetselected=src
3. src.icon_state=selected

I guess when I run this game with other players, I can see which mobs they select. Not the best solution. I just did the icon_state because it was easy and I can get on with getting the game-play to work. Since I put the details in a procedure, I can come up with a better solution later.

So moving on... what if the user clicks on a turf. So far, nothing happens because turf/Click() is different from mob/Click(). We don't have to handle that in mob/Click(). What do we know? Well, in mob/Login() and mob/Click() we have set it up so there is always a lastpetselected.

To-dos for turf/Click()
1. move usr.lastpetselected to src

Now, how do I get pets? Do I summon them? If so, then I'll need to make new mobs in a mob/verb or something. I'll need to figure out where to put them and make sure to set their owner to usr. Make a to-do list for the verb.

But what if there are mobs roaming around free. As long as nobody else owns them, I can charm them. Well then, just add that situation to my mob/Click() thought flow:

Questions for mob/Click()
Is src.owned==usr ?
yes: usr.lastpetselected=src
no: is src.owned true?
yes: usr.lastselected attacks src
no: usr.lastselected charms src

What should charm do? Well it could be something like:
1. move usr.lastselected to src
2. roll dice
3. if roll is good: set src.owner=usr; usr << "you did it"
4. if roll is bad: usr << "you failed"

So since it has a lot of details, I would make it another procedure.

Of course, the same can be said about "attack". It is a series of steps.

Replace charm with whatever concept matches your motif: recruit? enslave? seduce?

Every solution can have problems.
- Attack... What if my pet is losing? Can I stop the attack and run away?
- Charm... Do I want to allow pets to charm pets or can only my logged in mob charm them? If the charm fails, does the mob get mad annd attack me?

Any "what-if" becomes a new decision tree or part of one you already have. Organize it and then you can convert it to if/else code in the appropriate procedure.

So in summary, if you can organize the flow of thoughts into problems and solutions, you can make a decision tree and to-do list. If you can do that, then you can turn it into code. Then you can adjust your game to handle most of what you think of.

Hope that helps...