Your indentation mislead me.
What are you talking about i simply quoted his code?
Hey guys, one more thing, would it be possible to make some sort of voting system, something like every 60 minutes, each faction has to vote for a new faction leader.
|
I see.. something like this perhaps
mob/ |
That is sort of the idea, but this is more what I mean:
mob And even further, you can combine all of the faction message outputs into a single universal proc as well, and just pass into that procedure call a new variable that will tell it which faction to output the message to: FactionMessage(faction as num, message as text) Your Donate verb can then be simplified by adjusting it like so: verb In the above, note that the use of switch() will be very handy. |
Ohh i get ya! so something of this nature
mob/verb/donate(n as num) |
J-Zed wrote:
Ohh i get ya! so something of this nature mob/verb/donate(n as num) Very close to that, yes. I would make a slight improvement to how you're attaching the player's faction, though (and I believe this was mention by another response earlier in this thread) Instead of giving the players several variables (faction1, faction2, faction3, etc.) and then turning those "on" (by setting their value to 1), it would be simpler to just give the player a single "faction" variable, and just set it to the faction number they are in. Players in faction 1 will have faction=1, players in faction 2 will have faction=2, etc. |
SuperSaiyanGokuX wrote:
J-Zed wrote: mob/verb/donate(n as num) Very close to that, yes. I would make a slight improvement to how you're attaching the player's faction, though (and I believe this was mention by another response earlier in this thread) I tried telling that to him he just ignored me. |
You fixed the previous issue and i thanked you for it, and SuperSaiyanGokuX offered another solution with the same concept as yours.
|
You seem to have everything sorted, but I'll elaborate on my previous comment about using datums to handle this sort of thing. For a much more in-depth look at datums, read Lummox Jr's post Datums Are Our Friends.
I'll comment the code as best I can. First off, we will have to create a list to hold our three factions, then make the actual Faction datum. //This list will hold of all the current factions There we go, but those procs don't actually do anything yet, so lets sort that out. Faction Now we have our Faction datums, but we havn't actually created them yet. We should do that when the world starts up, so lets throw that in there. I'm going to call them the Red,Green and Blue factions. world Now the world has started, and the factions are created. Time to work on our mob, we'll to give him some currency so he can donate, and also a variable to keep track of which faction he is in. mob Great, now we let him decide which faction he wants to join. We'll do that when he logs into the game. While we're at it, we will remove him from the faction when he logs out. mob Almost set up now, but the players are generous and would like to donate to their faction, so we'll let them do that. mob And there you have it, a nice little Faction system. Keep in mind that if you want players to permanently choose a faction when they create a new character, you will only have to let them choose once, and that's when savefiles come into play. |
Wow, i never knew you can have so much from just 1 var. I'll definately be checking out Lummox Jr's guide about Datums now. Thanks for opening my eyes to yet another new way to do thing Danny Roe.
|
:o Thanks Danny. I'll also check out that guide. Interesting thing, Datums. I just didnt understand why the code [Faction/faction] was put there. Does it enable the mob to utilize the Faction datum?
|
It does indeed, in the same way that one would use var/mob/Player. Faction (capital F) references the Faction datum, and faction (lower f) is the name of the variable.
|
Datums are great (even though I don't use them as often as I could)
Lummox's guide points this out, but a datum is the most basic data type (in fact, "datum" is the singular form of "data", TA-DA!). All other data types in DM are derived from it, including all of the atoms. What this means is that a datum has all of the basic capabilities of the more specialized data types (it can have variables and procedures defined on it), but it doesn't have all of the "overhead" that comes with the other types. Every level as you go down has an extra layer of stuff (variables and built-in procedures) tied to it that give it its special properties on top of whatever it inherits from the level above, so since the datum is the base type, it doesn't have all of the baggage. All of this is just a rambling way to say that a datum is perfect for holding and manipulating abstract data. Anything that doesn't need to carry with it any of the junk that comes with the other types (the movement procs and variables built into movable atoms, or the contents list, etc.) can just be handled by a datum, instead of wasting resources and time on using one of the atom types. I tend to use /obj for a lot of things that could simply be datums, but that habit goes back to earlier days before I knew better. |
However, I think that an important design choice needs to be made before we go too far with this.
If each faction will have virtually identical functions (like each faction will have its own donation verb, and they'll all work the same way), then the better programmming practice would be to program one universal proc that all factions have access to, and then place restrictions within the proc to prevent members of one faction from interacting with other factions.
You would write one verb under a common ancestor (probably just /mob), then add in checks to compare the faction of the source, and the faction of the target, and only carry out the transaction if they match.
All other shared types of functions can be handled this way.