DM Newb Tutorial 1: Ninja RPG: DM Environment and Logging In!

ID:119423
 
Oct 3 2011, 9:21 am (Edited on Oct 3 2011, 1:19 pm)
Keywords: tutorial
DM Newb Tutorial 1: Ninja RPG: DM Environment and Logging In!

So today, obviously by the title, I am going to be showing you how to make a simple RPG with the theme of ninjas. Why? Cause everyone generally likes ninjas, plus it allows us to add some cool stuff.

--Layout
I have two sections of everything. I show the newb way, and then if you have dabbed a little here and there, there's the other way. If you think you may already know a section, there should be something in italics under the sections title which will just explain in a few sentences what to do so you can skip to the next section. Note! Some stuff might be optional to read, so if you feel like you understand things pretty well, then you can skip them.

--Sections!
-Setting Up A DM Environment
-The Preset Coding (optional)
-World!
-Comments In Your Coding (optional)
-Login()!
-Mob and the Object Tree (optional)
-Variables and Output!
-Compiling and Running the Game! (optional)
-Changing Variables!
-Switch and Input Procs
-If()!
-What We Have Done!

--Setting Up A DM Environment
-Talks about how to create a new game environment!
If you already know what to do, make a new environment, call it Ninja RPG. Make the code files name “Movement.dm”.

Setting up a DM environment:
1) Open Dream Maker
2) File -> New Environment
3) Directory should be wherever you want your files to be. (I choose desktop)
4) Make the Name "Ninja RPG"
5) Another box should pop up asking about a .dm file, and naming it the name that we just chose, we want to name it "Movement.dmi" and save it.
6) You now have a code file and a game environment set up!


--The Preset Coding
-This is just an optional read

Now in this coding, you should see some code already in there, it should look like this:

/*
    These are simple defaults for your project.
 */

world
    fps = 25      // 25 frames per second
    icon_size = 32    // 32x32 icon size by default

    view = 6     // show up to 6 tiles outward from center (13x13 view)


// Make objects move 8 pixels per tick when walking

mob
    step_size = 8

obj
    step_size = 8


Just don't worry about it. :D

--World!
-Explains the different types of files and how to make a new code file. You also learn how name your world and give it a hub.
If you know it, create a new code file, call it World and copy the coding into it.

Alright! The first thing we have to do with a new game is give program it's name in and whatnot!
So...
1) File -> New...
2) Now, you see a drop down box that shows code file, icon file, map file, interface file, and script file. These are different files that contain different things. The code file (.dm) contains the coding of the game, the icon file (.dmi) contains the art, the map file (.dmm) contains the maps that you play on, the interface (.dmf) is the skin, GUI, graphical interface, or any other term you have for it, script file (.dms) is... well... I don't really know. I never use it, and when I have, it was way back in BYOND version 3.5. So... I'd imagine it's not going to be important in this RPG. But anyways, click "Code File"
3) Name it "World". NOTE: There is not need to put the extension (.dm) because we've chosen it to be a code file.
4) Click "OK"

Now we have just created a code file! Hurray! Now to the cool stuff. Write this in the coding (Don't forget to use the tabs!):

world
    name="Ninja RPG"
    hub="yourkey.NinjaRPG"


Now let me explain what you just did (I hope you put your key in there...). You can use world for many things! Here, we just used it for 2 things. We used it to name the game “Ninja RPG” and to set it's hub path that we connect to.

--Comments In Your Coding
-Optional. Explains how to use comments.

// is a comment in the language. Anything you write in // will be skipped over whenever you compile. /* */ is used for larger sums of text such as paragraphs. In this example, I explain what name and hub do with comments.

world
    name="Ninja RPG" //This is the name of the game. Whenever you run the game, this is what will be shown at the top left corner of the screen
    hub="yourkey.NinjaRPG" //This is the hub, the place your game will try to connect to whenever you host it.
 /*
 Remember that these terms:
 -name
 -hub
 are both already defined, so you won't be able to give them different meanings!
 */


--Login()!
-How to call Login()!
If you already know this: Create a new code file called Login. Copy the code below.

Let's begin now on what happens when you log in the game! Let's create a new code file (.dm) and call it "Login". You might be telling me that I forgot the space between log and in, but you'll find out. We are going to use what's called a proc. Yay! Terminology! Proc stands for procedure. There are defined procedures in the DM code just how world and name are defined, Login() is one of them! Now you are probably wondering why I put the () at the end of the proc, Login. This is because () is what's called an operator. It's used to call a proc or verb. So here's how we call our Login() proc!

mob
    Login()
/*
Note! This could also be written as mob/Login(). / is a path operator!
For example:
world
    name="Ninja RPG"
could be written as:
world/name="Ninja RPG"

They both mean the exact same thing, but I think it's all based on how you want to do it, I prefer the "stacking" way.
*/


--Mob and the Object Tree
-Optional. Explanation about objects and mobs.

Mob stands for "Mobile Object"¯. Human players are known as mobs when they log in (Although this can actually be changed! But that's more advanced than what we are doing here). But this is why we call mob/Login(), so this how we control what happens when someone connects to the game! I like to think of mobs as humans, NPCs, monsters, anything that would "have life"¯ in the real world. There are three other objects like mob that I will explain below.

The three objects are area, obj, and turf. Now just like how mob kinda resembles what it generally is, these do too! Area is kind of used for making regions on the map and mainly things that deal with... well... area! Turf is basically what it means! Turf! Ground! Examples of turf would be: grass, dirt, sand, water, buildings, trees, ect. Basically things that won't move, will always stay where they are, and are basically... just there. Obj stands for object. I like to think of these as items as anything that will move, but is not human, or will not be generally on the map. Pots, stoves, swords, shields, guns, fireballs, spells, bullets, and more, are generally coded as obj. So these are the four objects of dm: area, turf, obj, and mob. Together, they make up atom (first letter of each object).

--Variables and Output!
If you already know this, just copy the code and move on

Let's make it so that you get a welcome message and then it will ask you what kind of class you want to be! Here's the coding for a welcome message:

mob
    var/class="None"
    Login()
        src << "Welcome to [world.name]"


Oh snap! Did he just throw in some other stuff?! Yes he did! First let's talk about the statement:src << "Welcome to [world.name]". Src is a variable. What is a variable? Well as you ca see in the coding, there is a little line called var/class="None". I'll explain more about it, but just as an example, class is indicated a variable for mob. Src is a variable for the object that contains the verb or proc. So basically, src is YOU! << is another operator. It's an output operator that outputs whatever's on the right side to whomever's on the left! So here it's outputing "Welcome to [world.name]" to src! You might notice that I put the sentence in quotation marks. This is to define it as a string of text. Anything you put between those quotation marks will be outputted. Now for the final part of the line, [world.name]. This will ouput the world's name as we defined it (remember world/name="Ninja RPG"? That's what it will output!). This is how you will access any variables!

--Compiling and Running The Game!
-Explains how to compile and run the game!
Optional.

Let's run the game so you can see what you've done so far!
1) Build ā†’ Compile (Compiling puts the code together so you may run it!)
NOTE! You should get this at the bottom output box:

loading Ninja RPG.dme
saving Ninja RPG.dmb (DEBUG mode)

Ninja RPG.dmb - 0 errors, 0 warnings

If you didn't, you must have made a spelling error or something. Make sure your code is identical to mine.
2) Build -> Run (Runs the game)
3) Gaze upon your creation!

Don't worry, eventually we will get this looking good!

--Changing Variables!
-Explains how to change what data is in a variable
If you know this, just copy the code and move on.

Here's a better example of variables. As you can see in the coding, I put mob/var/class="None". Think of it this way, "Mob's class equals None". Now why use variables? We can make them equal anything in the coding! Let's make some variables and have them change in the coding!

mob
    var/class="None"
    var/weapon="Nothing"
    Login()
        src << "Welcome to [world.name]"
        src.class="Villager"
        src.weapon="Dagger"


So as you can see, I made a new variable for mob called weapon. If you notice near the end of the code, we did what is called defining a variable. We gave them a new meaning. Now src's class is Villager and src's weapon is Dagger, he's mighty tough. So this is how you can define variables in your game. You can make the weapon equal sword, staff, shield, anything! You can make the class equal sage, ninja, or Lummox Jr! It just don't matter! But let's make it so the player can choose what his class is, which will determine his weapon!

--Switch and Input Procs
-Explains and shows switch() and input() procs as well as how to allow the player to select what class they want.
If you know this, just copy the code and go on.

mob
    var/class="None"
    var/weapon="Nothing"
    Login()
        src << "Welcome to [world.name]"
        src.class="Villager"
        src.weapon="Dagger"
        switch(input("What class do you want?","Choose Class") in list ("Fire Ninja","Warrior Ninja","Fearless Ninja"))
//NOTE THIS IS INCOMPLETE CODE AND WILL RESULT IN AN ERROR IF YOU COMPILE!


The reason why I didn't finish the code is because I want to explain the line I just typed. Switch() is a proc used to find something that equals what's in it's parenthesis. Cool huh? The input() proc is used (in this situation) to output a message asking the user through a little box what choice do they want to choose. The "What class do you want?" part of input() is the message part, basically what's the question going to be. The "Choose Class" part is the title of the box that will show in it's top left corner. The in list ("","","") is basically a list of the decisions they can choose. You can make as many as you want. Just add more commas and quotation marks. Now onto the next part!

--If()!
-Explains how to use the if() statement and what it does!
If you know this, copy the code and move on.

mob
    var/class="None"
    var/weapon="Nothing"
    Login()
        src << "Welcome to [world.name]"
        src.class="Villager"
        src.weapon="Dagger"
        switch(input("What class do you want?","Choose Class") in list ("Fire Ninja","Warrior Ninja","Fearless Ninja"))
            if("Fire Ninja")
                src.class="Fire Ninja"
                src.weapon="Staff"


Now here, I've added what's called an if() statement. It checks if what is inside it is what was chosen by the player. And then under it, I have the variables of the player being changed to define what he had chosen! Now let's finish it up for warrior ninja, and fearless ninja classes!

mob
    var/class="None"
    var/weapon="Nothing"
    Login()
        src << "Welcome to [world.name]"
        src.class="Villager"
        src.weapon="Dagger"
        switch(input("What class do you want?","Choose Class") in list ("Fire Ninja","Warrior Ninja","Fearless Ninja"))
            if("Fire Ninja")
                src.class="Fire Ninja"
                src.weapon="Staff"
            if("Warrior Ninja")
                src.class="Warrior Ninja"
                src.weapon="Sword"
            if("Fearless Ninja")
                src.class="Fearless Ninja"
                src.weapon="Club"
        src<<"You are now known as [src.name] the [src.class] who wields the [src.weapon]!"


What We Have Done!

Alright! Now we've made it where the player can choose what his class is, but his weapon is decided on what class he chose. At the end, I put another output line so it will say that you are you, the class you are, who wields the weapon your class has!

I hope this helped you gain the basics of DM programming. I'll be making more to add to the Ninja RPG series of tutorials. The next one will be mainly based on maps and icons! Woohoo!

Note: If for some reason you are getting an error, make sure you coding is the same as mine. If you have checked and you still can't get it right, you can download the source of what we did today here and compare and make sure everything is right.(If link doesn't work, click this: http://files.byondhome.com/Ganing/Ninja%20RPG.zip )

I hope to do this at least once every two weeks. (This took roughly 3.5 hours to do >.<) Time to get some sleep! Questions, critique, and suggestions greatly accepted! I hope this wasn't oversimplified, I just really wanted to have a very detailed explanation of how to make a game for newbs who are still having problems truly grasping the language!!</<>
Oct 3 2011, 9:21 am
I think having 2 tutorial "editorials" is kind of interesting... lets see how this goes.
Oct 3 2011, 9:39 am
I hope you have the icons ready for the rest of the tutorials.
Oct 3 2011, 9:54 am
EnigmaticGallivanter wrote:
I think having 2 tutorial "editorials" is kind of interesting... lets see how this goes.

Me too! It should be fun!

ShadeCyberPlatinum wrote:
I hope you have the icons ready for the rest of the tutorials.

I haven't got that far yet, but I hope to just get some out of the reference because I suck really bad at iconning. lol
Oct 3 2011, 10:30 am
This reminds me of the tutorials that Kyle_ZX was writing - there's way too much text, it's very basic, and not that organized.

It's a very basic topic so most people will be able to figure out 50-90% of what you've said on their own. Because it's a long narrative (do this, now do this, now do this, etc.) it's hard for people to jump ahead if there's something they already know. People can't scan the section headings (because there are none) to see a topic and think "oh, I don't know how to do that", so instead they'll tend to assume that the tutorial is too basic for them, they already know it all, and they'll stop reading.

A good tutorial finds the shortest, simplest way to explain a concept to the most people. Not only is this tutorial long, but I'm not sure it'd reach a lot of people. Most DM tutorials have this mistake - the author says what they'd want to hear if they were pretending to be a newbie. This tends to result in tutorials that are only useful to the past version of your current self, but until time travel is possible it doesn't help =)

I think if you tried to write a tutorial on a more complicated topic it'd come out a lot better. When the topic is so simple it's easy to just plop down a ton of text in 3 hours and call it a tutorial. For a more complex topic you'd occasionally have to stop and think about how to explain things - you'd spend more time thinking about how to explain things and less time just mindlessly banging out paragraphs so the explanations would automatically be more clear and concise.

Also, when you pick a more complex topic the tutorial is much more useful. I'm not sure why people like to write such basic tutorials (fear of being wrong? I'm not sure...) but they're not that useful because they don't cover much. When you write a more advanced tutorial you can more safely assume the reader can figure things out on their own (so the tutorial is bound to cover more material with less text). If you write a tutorial like this every two weeks, you'll have to spend 5,000 weeks writing 2,500 tutorials before the set of tutorials is comprehensive enough that it takes someone from "newbie" to "intermediate". I'm sure there are better ways you can spend the next 5,000 weeks =)
Oct 3 2011, 10:47 am
If I was a newbie, I wouldn't've read any of that.
Seems F_a covered most of my concerns, though.
Oct 3 2011, 12:01 pm
Forum_account wrote:
Text

I understand whatcha mean, but I did this actually thinking of my friend who wants to learn to program so bad, but he can't find any good tutorials that start off real basic. He has no programming experience, and when I mention the word var I gotta explain it to him every time.

I do understand whatcha mean. I think I was too descriptive at too many parts. What I think I will do is I will put a term list at the beginning and say we will be going over -topic- here are the terms you will hear and what they mean. That way I don't have to explain them in the tutorial. I plan to start off basically just introducing all the parts of the DM language. What you can do, how you can do it, ect. But indeed, I will revise this and clean it up.
Oct 3 2011, 12:50 pm
Actually, I decided against the terms thing, but I will go through and organize this. I just decided to be really descriptive with it. To some this may seems like a lot of text, and I admit it is. I will cut it down some and take out unnecessary sentences. But things will get shorter down the line. I'm trying to explain all of the new things to the brand new coder. I decided under each topic I make, I'll put a description of what will be in the topic, and if it's optional to read. This is for the brand new noob, and will go on into harder topics when they come along. We have enough tutorials about different topics, but not enough to help a brand new person out. That's what I want to make. Something they can follow.
Oct 4 2011, 12:22 am
Forum_account wrote:
Text

Let a noob complain, not you.

Oct 4 2011, 3:07 am
Ganing wrote:
Actually, I decided against the terms thing, but I will go through and organize this. I just decided to be really descriptive with it. To some this may seems like a lot of text, and I admit it is. I will cut it down some and take out unnecessary sentences. But things will get shorter down the line. I'm trying to explain all of the new things to the brand new coder. I decided under each topic I make, I'll put a description of what will be in the topic, and if it's optional to read.

Look at a programming text book (even something terrible like those "Learn ____ in 21 Days" kind of books). They are very descriptive, but also very organized. The problem is that all of your text looks the same.

Having titles before each section helps, but it's still mostly just paragraphs of text inside each section. Use blockquotes or something to contain the more-detailed explanations. That way the reader can read the simple, short description and skip the extra-detailed explanation if they don't need it.

This would also help to isolate two types of information that you have here:

1. Things that people who are new to programming won't know.
2. Things that people who have programming experience but are new to BYOND won't know.

The explanations of how to use Dream Maker, explanations of object types (turf, mob, etc.), explanations of file types, etc. are useful to people who are familiar with programming but just haven't used BYOND before.

This is for the brand new noob, and will go on into harder topics when they come along. We have enough tutorials about different topics, but not enough to help a brand new person out. That's what I want to make. Something they can follow.

The problem is that these super basic newbie tutorials just don't cover enough material to turn complete newbies into intermediate coders. They turn complete newbies into complete newbies with 30 minutes of experience. It sounds harsh, but not all newbies can or will become programmers. If people can't figure out most of this for themselves, they won't make it. There's so much between "novice" and "intermediate" that people need to be able to figure things out on their own.

The other problem with these tutorials is that they often given people the wrong idea about things. How many people will read this and then think "Ok, that's how if() statements work, now why doesn't this work:"

mob/verb/attack()
    if("Fire Ninja")
        world << "[src] uses the fire attack!"
    if("Warrior Ninja")
        world << "[src] uses the warrior attack!"


You can see how someone might expect this to work (I'm sure I can find many similar questions on the developer forum). Or, suppose you make a mistake in the tutorial. In a basic tutorial where the reader has very little experience it's not likely that they'll catch your mistake. They could base their initial understanding of DM around a typo!

It's very hard to explain basic topics well. It's counter-intuitive, but it's easier to explain more difficult topics. I think that people write basic tutorials primarily because they think it'll be quick and easy but the opposite is actually true - because this is so basic you should spend even more time working on it. If you're going to stick with basic tutorials, keep this in mind.
Oct 4 2011, 8:58 am
Forum_account wrote:
Text.

Indeed I understand. I don't want to be the persons only guide and I make sure that my code works 100 percent. It's really tough organizing this stuff, you're right. But I just decided to keep going like this because I feel it may at least help one person.

It's very hard to explain basic topics well. It's counter-intuitive, but it's easier to explain more difficult topics. I think that people write basic tutorials primarily because they think it'll be quick and easy but the opposite is actually true - because this is so basic you should spend even more time working on it. If you're going to stick with basic tutorials, keep this in mind.

I will. Thanks for the information.


Why don't you make your own column of tutorials? You are very skilled in the DM language. I've been trying to get people to do tutorials for a while, Magnum got the idea to do when we were posting comments on a previous blog. You should do one too! Maybe you'll make one that will help me. You could do those tricky subjects that people don't use a lot like Topic() or invisible and shtuff.
Oct 4 2011, 9:48 am (Edited on Oct 4 2011, 10:00 am)
I genuinely think we don't need more 'beginner' tutorials than we already have, and any addition thereof serves only to clutter the existing resources, making it harder to separate the good from the bad. The only response I have seen to these kind of tutorials lately is (mostly constructive) criticism from more experienced developers who don't need them anyhow.

Even if we do need more beginner tutorials, I would like to see the material written by more experienced developers. No offence to the column writers (I know you have good intentions), but they are not much more than a beginner themselves.

Pedagogically, what we do need more of, are tutorials explaining how to use our better existing libraries, and also more good libraries that come with tutorials in general.
Oct 4 2011, 2:47 pm
Toadfish wrote:
I genuinely think we don't need more 'beginner' tutorials than we already have, and any addition thereof serves only to clutter the existing resources, making it harder to separate the good from the bad. The only response I have seen to these kind of tutorials lately is (mostly constructive) criticism from more experienced developers who don't need them anyhow.

Even if we do need more beginner tutorials, I would like to see the material written by more experienced developers. No offence to the column writers (I know you have good intentions), but they are not much more than a beginner themselves.

Pedagogically, what we do need more of, are tutorials explaining how to use our better existing libraries, and also more good libraries that come with tutorials in general.

Indeed we do need more tutorials. But no one ever wants to do any. And if they do, they do like one and that's it. What happened to a central station you could go to to find out stuff? What happened a guide that was updated to AT LEAST 3.0? Just saying, we need a lot done around here on BYOND. But no one wants to do it.
Oct 4 2011, 3:27 pm
Toadfish wrote:
Pedagogically, what we do need more of, are tutorials explaining how to use our better existing libraries, and also more good libraries that come with tutorials in general.

This sounds familiar, I think we've talked about that before.

Ganing wrote:
But I just decided to keep going like this because I feel it may at least help one person.

These tutorials are helpful, but the problem is that it's hard to make a basic tutorial that's helpful enough to warrant the effort it took to make it.

Why don't you make your own column of tutorials?

I try to write tutorials whenever I have the time and an idea. I've written a few tutorials and some other articles (and there are a few more I have planned). I wouldn't write a regular column because I don't regularly have the free time for it.
Oct 4 2011, 3:48 pm
I've never used the new native pixel movement before, so this was somewhat helpful for me because I didn't know how simple it was.
Oct 4 2011, 5:38 pm (Edited on Oct 4 2011, 5:43 pm)
This sounds familiar, I think we've talked about that before.

Yeeeeep. I think you were the first to bring it up - with the frameworks and such (I'm still very supportive of that idea). Or perhaps a different context.

Now that pixel movement has been covered pretty well (though there's still juice to squeeze), should think what other things the developer community has trouble with/could benefit from, and create a set of libraries/tutorials for that. I believe there's lately been an interest in dynamic lighting.
Oct 5 2011, 3:10 am
Toadfish wrote:
Yeeeeep. I think you were the first to bring it up - with the frameworks and such (I'm still very supportive of that idea). Or perhaps a different context.

I think it makes a lot of sense to build tutorials around libraries. A tutorial about how to use BYOND has already been done and, in the strictest sense, there's not much to cover (it's mostly just syntax). Once you've got the syntax down people will either:

1. Have prior programming or game development experience and will be ready to make a game because DM's syntax was the only thing they needed to learn.

2. Have no prior programming experience and won't be ready to make a BYOND game from scratch because they still don't fully understand how to use DM.

In either case, tutorials about libraries are useful. Users in the first group might not need the libraries, but they may be curious to see what libraries can do for them. Users in the second group will need to use libraries and will need some help figuring out how to use them. The libraries and tutorials about them will also serve as examples of how to program to the users in the second group.

I believe there's lately been an interest in dynamic lighting.

Are there any other topics you can think of? Dynamic lighting is a useful feature but it should be handled primarily on the client and the only way to do that is if it's a built-in feature. Though, if there was some way to know that the staff had no intention of adding this, then it would be worthwhile.
Oct 5 2011, 5:38 am (Edited on Oct 5 2011, 5:54 am)
Are there any other topics you can think of?

I'm having a hard time to think of something in high demand. Maybe a library-tutorial set for server to server communication, and a tutorial for BYOND's Dantom.DB library (the tutorial would ideally explain what databases and MySQL are all about too - Nadrew's tutorial is not very accessible in that regard). The tools already exist, but not many people are capable of using them.

One other thing that might be useful is a 'user dialogue' library, which would assist in creating (HTML?) forms the user could fill. A good example is the character creation sheet form in your Spies!. In my experience, a lot of BYOND games, even successful ones, still use the default input() and alert() for a lot of user feedback, or otherwise a very plain and ugly HTML window. Now, I believe there's a library called Dantom.htmllib which seems to do this, so the question is whether just a tutorial is needed, or the library is infeasible and should be rewritten (I leave the verdict to the guy who writes this thing!).