Coding in DM -For noobies like me.

Discussion in 'General' started by Legato_frio, Jan 14, 2013.


Was this Forum useful?

  1. Yes

    3 vote(s)
  2. No

    1 vote(s)
  3. Legato_frio just stop. (Any reason)

    2 vote(s)
  1. Legato_frio

    Legato_frio Public Relations

    Hello Libertys Last Army,

    I am not a master of DM ('s graphical coding engine) but I figured I have to make a start somewhere. I would like to get an on-going thread created by fellow members of LLA that provides useful code for people learning DM for the first time.

    Before I start I would like to set a couple guidelines.
    1. Do not JUST copy and paste code from sources.
    - If you want to use a code from a source copy and paste then edit terms in a general sense.
    2. Add all pieces of the code. If the code calls a proc add the proc also
    3. Keep code on a noob level nothing so advanced that it may confuse some of our player base.
    4. Use the code button between ''Media'' and ''Quote'' for code so that the forum doesn't become messy.

    Those rules in addition to the Community rules are all I ask.
    I will provide my first example since Pepsi_Blue_Fan requested it.
    /* The request of :Show me how to add a hud!
    Ok, ok. Adding a hud is as simple as creating an object with
    certain characteristics and spawning it when necessary. These
    "characteristics" would be defining the fact that it is only
    for the client to see and no one else.
    We'll start simple by creating an object. If you don't know
    how to do that, close this window immediately.
    I'll call the object Bar.
            icon_state="bar hud"
    Good, now we have an object. Next thing to do is tell it to
    only spawn on the client's screen. This can be done with
    two lines of code.
    Add that to the bottom and it will only spawn on the client's
    screen. What those two lines of code basically say is, "When
    a client makes a new Bar object, add the Bar (src) to the
    client's screen."
    We're not done yet, though! We still need to decide where to
    place the Bar on the client's screen. This requires you to
    know how big the client's view is.
    That code makes the client's view 10 tiles by 10 tiles. Now
    that we know that, we can decide where to place it. If we want
    the Bar in the upper-left corner, we can place it at 1,10.
    Now 1,10 is not a number on the map, it's on number on your
    screen. Be sure to remember that fact.
    Now for the code to decide where to place it:
    screen_loc = "1,10"
    It's that simple. Once it's all done, it should look
    something like this:
            icon_state="bar hud"
                screen_loc = "1,10"
    We can then define for the object to be made with this code:
    new/obj/Bar(usr.client) */
  2. Legato_frio

    Legato_frio Public Relations

    This is something I have been wanting in SS13 for a long time since I hate Byond's default arrangement it would be nice to change the interface a bit. I will put this in here.
    mob/proc/align()// This procedure will align the game window
        spawn(1) src.align()
    // Use a semi transparent color for backing
        screen_loc="1,1 to 17,5"
    //Any of the chat procs can be called into src.align() 
    This is a just an idea take it or leave it.
  3. AquaDraco

    AquaDraco Active Member

    Coding in SS13: File Syntax

    Consider the following files:

    If I had a single object in every file, I could just go to the file containing the object I want (say, mob/ and find exactly what I want.

    However, because SS13 doesn't have only one object in every file, looking for an item using the format in "" is much harder if it's referenced multiple times (especially if it's referenced multiple times in a single file). SS13's terrible file organization (as shown in "") allows me to use find (ctrl + f) on "client/New()" and get the proc I'm looking for on my first try. This would take much longer if I were to just search for "client" or "New()" unless I know, for a fact, that there's a file called with all the stuff I want in it.

    tl;dr If you're programming in general, have one object (like mob or mob/player) in every file. If you're programming for SS13, make sure to use the format used in "" for all your procs/verbs rather than the format in ""
  4. AquaDraco

    AquaDraco Active Member

    Coding in General: Commenting

    Comments are incredibly important because they make reading code much easier.

    Consider the following confusing code:
    We know we have a car with the variables "gas", "wheel", "driver", and "passenger," but we now have several questions to ask ourselves:
    • What is gas measured in? If gas is just 5, does that mean 5 gallons, 5 liters, or 5 amount-of-liquids-in-Legato-Frio's-body? Do we want gas to be a string ("5 gallons") or an integer (5)?
    • What is wheel? Is it the steering wheel? Is it one of the tires? Or is it possibly the status of the wheels?
    • What is driver? Is it the status of the driver? The driver's health points? The driver as a person?
    • What is passenger? The person sitting besides the driver? What if there's multiple? Is it the person you kidnapped and put in the trunk?
    So what can we do about this? What if you wrote this code months ago, and you don't remember what any of this is? Do you want to re-read every line in every file just to make sure you know exactly what everything does in your car object? No, because then coding would take forever (or it'll end up with millions of bugs). So what do you do?

    We add in comments:
    /* This object represents a generic car. The car can drive around and stuff.*/
        // gas is the gasoline in the gas tank.
        // gas is measured in integers and liters.
        // For example, if gas was 5, then we know there are 5 liters.
        // wheel is the status of the tires.
        // wheel is a string that can be either "normal" or "damaged"
        // driver is the health points of the person driving the car.
        // driver is an integer that can range from 0 to 100
        // If driver's health is 100, then the driver is unhurt.
        // If the driver's health is 0, then the driver is dead.
        // passenger is the status of the passenger bag
        // passenger is a boolean value
        // passenger is true if the passenger bag is ready to be used
        // passenger is false if the passenger bag cannot be used for any reason
    And now we have gotten rid of any ambiguity when we declared (a fancy way of saying "introduced") our variables. We know exactly how to use each variable without having to guess or having to look at other uses of the variable. More importantly, other people can use our code safely without accidentally using the variables in a way that may crash the program.
  5. AquaDraco

    AquaDraco Active Member

    Coding in General: Object-Oriented Programming

    Dream Maker should be considered to be an Object-Oriented Programming Language (or OOP, if you're hip). A language is considered to be object-oriented is if the language's structure mainly relies on the concept of objects.
    Other languages that use objects are Java, Python, C# (arguably a copy of Java), C++, Ruby, and pretty much every other major programming language.

    So what's an object?
    For starters, everyone and everything around you can be considered an object (except women, because I think you can get sued in some cases if you try calling them objects). The chair/bed/throne you're sitting on is an object. The laptop/computer/tablet/phone you're using is an object. Your lunch was an object. The digesting mess in your stomach is an object. Electrons whizzing through your digital device are objects. The atoms that comprise every piece of matter in the universe is an object. Heck, even the universe is an object.

    In programming, an object can be considered a collection of data.
    Imagine you're assigned to write down an extremely detailed description of a house and stick it in a text file. What we'll end up with is a wall of text that'll be more painful than reading through Apple's Terms of Service. But what if we split this horrendous text file into multiple text files? What if we had a file called "house_color.txt" and all it said was "red"? What if we had another file called "door.txt" with nothing but the description of the door? We'll have multiple text files, but organized in a single folder called "House". If our boss wanted to know what the door looked like for this house, our boss can just open the "House" folder and then click "door.txt" to directly read the description of the door without having to read through the million-character-long description of the garage.

    The same strategy is applied to objects. In our scenario, the "House" folder is our object and files like "house_color.txt" and "door.txt" are pieces of data about our object. However, in most languages, we don't store information about a single object in folders or multiple files. We simply put it in a single file that is the name of our object.

    For example, suppose Zombee came up to you and said, "Buzz. Ey, you. Buzz. Program me a beehive for SS13 (and it better not be better than the beehive I made)! Buzz. Flowers. Buzz. Pollen." What do you do? Well, we want to create a single object called beehive, so we'll create a file called (which is essentially a text file). Then we'll try to give the file information about the bees inside the beehive, the color of the beehive, the queen of the beehive, the shape of the beehive, the icon of the beehive, and other pieces of necessary information about this beehive. Then we upload it to DM (the program) and voila, we have a beehive object that can be used in game.

    But we're programmers, so we're lazy (so we cheat by using classes).
    What would happen if our boss in our first scenario wanted us to write down the descriptions of every house in the neighborhood? We could spent hours re-writing house information over and over and create folders for every new house we make, but we won't (because you're a strong, independent, object-oriented thinker who don't need no manual labor). We know that every house in the neighborhood looks exactly the same except for the house number, so we'll just copy and paste the original house folder. Then we go inside each house folder and change the file "house_number.txt" to the correct number. Maximum efficiency, minimum effort!

    Then a thought occurs to you: What if you could create a prototype? A blueprint? A template? Something you can use to copy and paste in order to create clones of the original? If your boss ever asked you to write a description again, you can just copy and paste from this blueprint and then make changes if necessary. I smell a promotion (or a demotion once your boss realizes that he'll make more money if he fires you and hires someone cheaper to just copy, paste, and make changes if necessary). Either way, you have to do less work!

    This template is called a class. Instead of having to create objects over and over again, you can just clone this class to get multiple objects (and, of course, you can make changes as necessary). Each "clone" of the class is called an instance. If you play World of Warcraft, you can think about instances as in how World of Warcraft uses clones (or "instances") of the same dungeon for players to raid (or something along those lines; I don't actually play World of Warcraft). If the same dungeon was raided by every party, then there wouldn't be anything for other players to fight. Creating a new instance of this class is called "instantiating" the class. Please use the word instance and instantiate instead of clone from now on. Instance and instantiate are the proper programming words to use!

    Suddenly, Zombee comes along and says, "Buzz, good work, buzz. Your beehive sucked. Buzz. It was killed by the gray tide almost instantly. Buzz. You need more! MORE! MOOOORE! BUUUUUUZZ!" And, as the lazy yet ingenious programmer you are, you decided not to copy and paste the same file over and over again (because that would take forever). Instead, you realize that the information in the file doesn't create an object. Instead, the whole thing is a class! Yes, I lied to you earlier when I said you created a beehive object. You actually created a beehive class. What does this mean? It means you can now instantiate (or "clone") this class over and over again. The best part is that this only takes a single line of code. This beats creating new files and pasting the same information over and over any day!

    You may now flood the station with beehives.
  6. AquaDraco

    AquaDraco Active Member

    Coding in Dream Maker: Inheritance

    This guide will make the following assumptions:
    • You have a general idea of what classes and objects are.
    Every object has a parent. Every object is a child. Except ATOM and Eve.
    Whenever you instantiate a class, the class will copy its information into the instance. For example, if I wanted to create a billion copies of a hat I created in Dream Maker, then I would create instances of the hat class. Each instance of the hat class would have all the information contained in the hat class. Each instance of a hat would have the same color, shape, design, size, etc. as the hat class.

    But what if you didn't want a bunch of generic hats? What if you wanted thousands of ushankas and thousands of ball caps? Notice that both ushankas and ball caps are a type of hat, so you can create a bunch of instances of the hat class and edit each one individually, but that would take forever! You ask, "Why can't we just create an ushanka class and a ball cap classes and then instantiate those instead?" Good observation, wary reader, because we can! And we'll do it with a shortcut that's similar to instantiating classes. We will create a child class of the hat class, which can be thought of an instance of the hat class that is also a class.

    Here's a modest diagram that kinda explains what a child class is. Note that this is NOT how it works inside the computer!
    <hat class> --instantiate--> (instance of hat class) --turn it into a class--> <child class of hat class> --edit a bunch of stuff--> <ushanka class>

    And so we have an ushanka class that is a child class of the hat class. It has every piece of information that hat class has, except the information has been edited to make sense for an ushanka instead of a generic hat. We also have a ball cap class that is also a child class of the hat class. The hat class is a parent class of the ushanka class and the ball cap class. You know how people inherit genetic information from their parents? Well, the ushanka class and ball cap class are said to inherit the information from the hat class. In programming, this passing of digital information from parent class to child class is called inheritance!

    We can now instantiate the ushanka class or the ball cap class to get a bunch of copies of them, just like the hat class.

    Now what if we wanted to create a Yankee (it's a baseball team) ball cap class or some other team ball cap class? We can just use the ball cap class to create a child class for each team the same way we did before when we wanted to create a ball cap class. As you can probably guess, the newly created Yankee ball cap class is a child class of the ball cap class and the ball cap class is a parent class of the child class.

    Here's an interesting question. If the Yankee ball cap class is a child of the ball cap class, and the ball cap class is a child of the hat class, then is the hat class a child of any class? The answer is yes! Every class in Dream Maker is usually a child of one of the ATOM classes: area, turf, obj, mob. And each of the ATOM classes are children of the atom class! So in a sense, the atom class is the root of all the other classes (roots are where a thing starts growing)!

    What are the ATOM classes?
    When you create a class in Dream Maker, you will have to specify whether it's a child of area, turf, obj, mob, atom, or another class (like the hat class). The four classes you will use most often are area, turf, obj, and mob.

    area is used to describe the general area of a certain place. For example, the brig is in an area called the brig, clown planet is in an area called the clown planet, Research and Development is in an area called Research and Development, and so on. Another example is if you're creating a game that involves a player running around the Earth, then potential areas you can create are geographic regions like Africa, the United States, New York, Antarctica, and so on.

    turf is simply something you can stand on (Oi! Get off my turf!). You can basically think of it as every tile. For example, every single tile in SS13 is considered a turf.

    obj is any inanimate object. For example, wrenches, chairs, garbage cans, and bananas should be considered obj's. In SS13, guns, lockers, machines, computers, and chairs are all obj's. Make sure not to confused this with the "object" used in the term object-oriented programming! Programming in Dream Maker does not focus on obj's like wrenches! Instead, programming in Dream Maker focuses on objects in general, including classes of area, turf, obj, and mob!

    mob is derived from the term "mobile". You should think of these as animate objects, like humans, sheep, bats, dragons, zombies, etc. As you can imagine, the main difference between a mob and an obj is that mobs can easily be configured to be playable.

    Note: You should not use atom to create child classes very often because it contains very few information compared to its four direct children classes (area, turf, obj, mob), which means you have less tools to work with and you'll have more work to do! You should only use the atom class to create child classes if there is no reason for a class to be an area, turf, object, or mob.

Share This Page