Objects in general; mapping with objects.

ID:151839
 
Jan 10 2009, 4:52 pm
I'm recently been programming something for a little while, and I was trying to figure out a way to map out larger objects without meticulously placing each instance where I need it to be (for the sake of argument, a tree, perhaps).

This tree, for example, is comprised of 6 parts, 3 of which are the trunk, middle and top, and other 3 are the opposite sides. The tree itself it an object, not a turf. When I decided that I need these trees in a lot of places, I created a piece of code that happens during run-time that adds the separate parts of the tree next to the the original instance; it creates 5 copies, changing the icon_state, layer, density, and location (obviously, one or two tiles away, depending on the part of the tree) as needed.

My question, however, is if this is a good practice to consider using when making maps so I can create a larger map in a less amount of time, or is the use of that many objects placing an unnecessary workload for the server. Should they instead be a turf? What other options are available?

Thanks for your response, it is greatly appreciated.
Jan 10 2009, 5:32 pm
Generating the full tree at runtime is probably the best approach. Even if you did go with turfs to cut down on your usage of objects, I'd still suggest placing one 'master' turf and have that turf generate the others at runtime (turfs can be created at runtime just like objs).

However you end up placing all the different parts of the tree, you may end up with problems later if you want your players to interact with them (such as chopping them down). For instance, a player walks up to the tree and starts chopping at the tree: Should just that one section disappear when he's done chopping (leaving a very ugly blocky tree)? Or should the entire thing disappear? What I do is I have a master tree object which controls the other parts. This is what the entire system might look like:

master_tree
    // master_tree is a datum, it doesn't exist on the map.
    var
        list/parts
        lumber = 8
    New()
        .=..()
        parts = list()
    proc
        add_part(var/master_tree/part/addition)
            parts.Add(addition)
            addition.parent = src
            // etc.
        destroy()
            for(var/part in parts)
                del part
            // etc.
        /*
            Define other procs here. Procs should belong to
            the master tree object, not to the individual parts.
            */


master_tree/part
    parent_type = /obj
    var
        master_tree/parent
    /* 
        Whenever a player interacts with a part, such as by chopping,
        that interaction should be sent to the parent (the master_tree)
        instead of being handled by the part. That way, the tree acts
        like one object, instead of acting like several parts.
        */


obj/tree_generator
    // This is the object you use in the map editor.
    New()
        . = ..()
        generate_tree()
    proc
        generate_tree()
            var/master_tree/tree = new()
            tree.add_part(new /master_tree/part(locate(somewhere))
            // etc. Build the tree here.
            del src // The player never sees the tree_generator.
Jan 10 2009, 8:45 pm
If trees can't be chopped or anything, it might be a better idea to just use a small PNG as the icon for a tree so the map editor places them all at the same time. You can use icon_state to determine the characteristics of a particular tree section (use the most common settings as default) and this will be a very great workload off the server from the start.

This approach can be easy to adapt to allow for the cutting of trees, though not as efficient in that area. It does save some memory, though. When removing a tree, use get_step() and a for() loop that checks for icon_state to remove all of the appropriate tree sections. This is more flawless than you will originally think.
Jan 11 2009, 3:59 pm
In response to CaptFalcon33035
The trees are non-interactive and they are for scenery only. Perhaps the turf approach may be a little better and using PNGs should save space. Thanks for the input.