Art of Gunpowder [Part I: var/owner] in Design Philosophy

ID:151340
 
Jun 24 2011, 6:51 pm
For reasons unknown I cannot quite conceptualize how to move past a huge glaring flaw one of my projects had a few months ago that I've yet to fix.

Each explosive, projectile, and structure (all of which are /objs) had a variable called owner. It contained a reference to the mob that created them. It was through this variable that these things inferred what to do if say... the owner was on red team, and a blue team guy attacked a structure he made.

if(owner.team != team) etc.

A problem that arose that I never considered was the fact if a player logged out, that reference vanished, so any interaction with something that needed to refer to owner or a variable of owner's would just spew runtime errors.

Another HUGE problem was that players could switch teams mid-round, which just swapped their icon colour and added them to the other team. It did not however make any difference towards owner; I could be on red team and build a bunch of stuff, plant a few mines, then join blue team and be immune to the red mines that I made and be able to interact with the red buildings, which was not the intended behaviour.

After the fact I considered a few ways to fix this, though none of them seemed applicable. Among those were deleting everything that mob made if they left/switched teams, but this had severe implications on balance and possible griefing.

For the life of me I can't figure out a better way to handle this at all. The idea is that lasers and bombs do damage to things based on if they're on the same team, and structures can only be damaged by people on the opposite team.
#1 Jun 24 2011, 7:05 pm
If you don't want to just destroy the objects, or give them a team variable of their own, you could just "distribute" a players stuff to the other players on their old team when they logout/switch.

Starcraft 2 and Warcraft 3 do something similar, iirc.
#2 Jun 24 2011, 9:10 pm
If owner of object has exactly same rights as his team members, then there's no reason even to know owner, only team is enough.
But , you could also store ckey or name to tell difference if owner is interacting with object (but you'd still have to check if he's on the same team as object is).
#3 Jun 24 2011, 10:52 pm
Use a datum to represent each player position.
#4 Jun 25 2011, 10:31 am
In response to Zaoshi (#2)
None of the structures have exclusivity towards the one who made it, so I guess making it just belong to the team instead is probably the best way.

But should I just simply define a team variable for structures? Or, ontop of the variable, add them to a list belonging to the /team datum. Hrm.
#5 Jun 25 2011, 10:54 am
Gameplay in Gunpowder is divided amongst two teams, red and blue. Quite simple really. The teams are completely identical except for one fact: the colour of the icons used for the various things they do. There is an icon for...

Each of the five classes (Tank.dmi, Medic.dmi, etc), the HUD, projectiles, explosives, structures, class portraits, and the title screen. These icons are all in grayscale, and coloured based on what team you pick. While the advent of client-sided icon manipulation has made colouring icons pretty much use up no CPU, I can't help but feel some form of caching should be used.

But how do I handle colouring icons? Should I just colour them as they're used? Or colour them once and store them in a variable in the /team datum. Colouring the player icons when a new player joins probably isn't a big deal, but considering the gameplay involves shooting lots of lasers which are coloured based on team, applying those colours every time they fire one is... probably not ideal at all.

Below is the team datum I have now, though it doesn't have colouring yet applied to it.

team
    var
        name = null

        score = 0

        list/members = list()

    proc
        Join(mob/M)
            if(M.team)
                M << "You're already on a team."

            else
                members.Add(M)

                M.team = src

                world << "[M] joins [src]."

        Leave(mob/M)
            if(M.team)
                members.Remove(M)

                M.team = null

                world << "[M] leaves [src]."

            else
                M << "You aren't on a team."

    New(n)
        name = n