Dream Makers' site

Logrolling and Other Extreme Sports

Fri, 31 Dec 2010 03:09:33 +0000

Since people began using BYOND, many games have been plagued with an information problem. Is yours one of them?

The problem is not a lack of information, but rather too much of it. It arises from an idea that is innocent enough - a game developer just wants to know what's going on in his game. Maybe, for example, to keep track of each battle that happens. So let's say our developer's first idea is to send out a message whenever someone performs an attack.

mob/verb/attack(mob/M as mob in oview(1))
            usr << "You attack [M]!"
            var/damage = rand(1,10)
            world << "[usr] attacks [M] for [damage] damage!"
            M.HP -= damage

He tests out the code with some friends and is delighted to see that he finds out every time someone is attacked. But soon players start complaining that their chat window is being filled up with useless information about other player's battles! Even the developer realizes that most of the time, he doesn't care about the battle. And annoyingly, whenever he logs out, he loses the whole record!

Once he realizes that there must be a better solution, our developer - being the diligent and studious programmer that he is - goes straight to the DM Reference. There he finds information on a useful var - world.log. With this, he can record a message along with the messages the BYOND may send (like runtime errors) without sending it to the whole world!

mob/verb/attack(mob/M as mob in oview(1))
            usr << "You attack [M]!"
            var/damage = rand(1,10)
            world.log << "[usr] attacks [M] for [damage] damage!"
            M.HP -= damage

As a bonus, he can set world.log to a file name and have all the messages saved to a file to be read later even if he leaves the game.

world.log = "log.txt"

This works so well that the developer forgets about it for a while and goes about adding more features to his game. One morning, however, he logs into his game's ad-infested, eyeache-inducing, free PhpBB forums and finds that one player is very upset because another one has been calling him horrid names. The other player denies it. The owner decides that the second player can't be punished because there's no proof he did anything wrong. But he thinks it would be best to keep a chat log to prevent this from happening again. So, he has the game write to the log again, just like he did for the battle log:

mob/verb/say(msg as text)
            world << "[usr]: [msg]"
            world.log << "[usr]: [msg]"

That solves that problem, but soon he hears reports of 10 different admins (nearly a quarter of them!) abusing their powers. To keep track of what they're doing, the developer also writes to the log whenever they perform an administrative action - like banning, kicking, or muting.

This alls seemed like it would work fine, but eventually he takes a look at the log file. It looks something like this:


someGuy logged in.
naruto930284738302392032893820490283 attacked naruto930284738302392032893820490284 for 1 damage!
xXYoMamaXx logged in.
lulz kicked someGuy.
someGuy logged in.
naruto930284738302392032893820490284 attacked naruto930284738302392032893820490283 for 2 damage!
runtime error: No put usr in proc. Ungh.
proc name: GiveSuperPowers (/mob/proc/GiveSuperPowers)
  source file: naruto.dm,70
  usr: null
  src: lulz (/mob)
  call stack:
lulz (/mob): GiveSuperPowers()
lulz kicked someGuy.
someGuy logged in.
naruto930284738302392032893820490283 attacked naruto930284738302392032893820490284 for 3 damage!
someGuy: hey stop it.
bleach930284738302392032893820490285 attacked naruto930284738302392032893820490283 for 4 damage!
lulz kicked someGuy.
SuperGoku9001 logged in.
xXYoMamaXx: stop abusing!
lulz banned xXYoMamaXx.
naruto930284738302392032893820490284 attacked naruto930284738302392032893820490283 for 5 damage!
someGuy logged in.
someOtherGuy logged in.
someOtherGuy attacked SuperGoku9001 for 0 damage!
someGuy: hey
naruto930284738302392032893820490283 attacked bleach930284738302392032893820490285 for 6 damage!
someOtherGuy: hi
lulz banned someGuy.
SuperGoku9001 attacked someOtherguy for 99999999999999999999999 damage!
lulz banned bleach930284738302392032893820490285.
naruto930284738302392032893820490284 attacked naruto930284738302392032893820490283 for 7 damage!
lulz banned naruto930284738302392032893820490283.
runtime error: No put usr in proc. Ungh.
proc name: GiveSuperPowers (/mob/proc/GiveSuperPowers)
  source file: naruto.dm,70
  usr: null
  src: SuperGoku9001 (/mob)
  call stack:
SuperGoku9001 (/mob): GiveSuperPowers()
lulz banned someOtherGuy.
SuperGoku9001 banned lulz.
naruto930284738302392032893820490284 attacked the sheep for 8 damage!
SuperGoku9001 unbanned someGuy
The cat attacked naruto930284738302392032893820490284 for 9 damage!
naruto930284738302392032893820490284: darn it
SuperGoku9001 unbanned someOtherGuy.
naruto930284738302392032893820490284 logged out.
someGuy logged in.
SuperGoku9001: wb
The sheep attacked someGuy for 10 damage!
someOtherGuy logged in.

You get the idea - it's not the easiest thing to read through. Plus, wouldn't it be nice to know when all of this happened? The game developer decided that he needed a better way to organize his log in order to be able to find out what happened, when, and who did it to whom.

An Introduction to n_Log (Finally!)

So by now (assuming you were good and didn't skip the first section of the article) you're probably wondering how to solve this information plague. The answer (or at least one answer) lies with the n_Log library. What does it do? A few things actually. First it provides procedures that let you easily write to and categorize a log. Things like the date and time are automatically recorded so you don't have to worry about them. Second, by default, it writes your log entries to a structured XML file. If you don't know what that is, don't worry! The library comes with a windows application that will let you view the log - without making your eyes bleed!

Rolling Logs

The library is pretty simple to use. To log a message, just do this:

record(notes = "Hello, world!")

Now let's go back to an example of a say verb.

mob/verb/say(msg as text)
            msg = html_encode(msg) // prevent the user from messing with the log... or other users!
            world << "[usr]: [msg]"
            record( action = ACTION_SAY,
                    user   = usr.key,
                    notes  = msg )

ACTION_SAY just categorizes the log message. See the library's documentation for other built-in actions. The user argument logs which user did the speaking. This might seem like a little extra unnecessary code right now, but don't worry - it will pay off later.
For one more example, consider the attack verb. There is no ACTION_ATTACK - what do we do? This isn't a problem, an action is actually just text. So we can just pass "Attack".

mob/verb/attack(mob/M as mob in oview(1))
            usr << "You attack [M]!"
            var/damage = rand(1,10)
            record( action = "Attack",
                    user   = usr.key,
                    target = M.key,
                    notes  = "[damage] damage" )
            M.HP -= damage

Notice that the record() proc takes a target parameter for logging which player something happened to, but all four parameters are optional.
If you get these examples running and do some fighting and talking, you'll notice a 'log.xml' file in the dmb folder. When you open it up, it might look even worse than the log you saw earlier! But that's just because you don't have the right tool yet...

The Log Viewer Application

In order to use the Log Viewer program, go and download n_Log if you haven't already. In Dream Maker, make sure the 'Show All Files' checkbox is checked, expand the 'LogViewer' folder, and double-click 'LogViewer.exe'. Then select File > Open, and find the log.xml file that the library created. The viewer should load the file and look similar to this:

You can hide and reorder columns to your liking by using the Options menu and by clicking and dragging the headers. Notice that the library logged the date and time for every event automatically. Also notice that now you can sort through all of the events by left-clicking a column header. You can already see how it's a great deal more flexible than an ordinary log file. Finally, you can right-click the top of a column to make a textbox appear at the bottom of the window. There, you can filter the columns. For example, if you right-click 'User' and type your key into the box, you will see only the actions that were performed by you. Also the * character is a wildcard, so entering *om* will show Tom, Dantom, Tommy, Mom, etc.

You can have more than one column filtered at a time. So if you filter the Action column for 'Ban' and the User column for 'Dan', you will see all of the times Dan banned someone (similarly if you filter the Target column instead of the User column, you can see all of the times Dan has been banned). See the program's help menu for more information on the Log Viewer app.

Advanced Functionality

The n_Log library holds a few more secrets. For example, you don't have to log to an XML file. Of course, if you don't then you'll lose the ability to read the logs with the Log Viewer.

// For some outrageous reason, /output/default is not (usually) the output type used by default!
logger.SetOutput(new/output/default(world))

The code above makes the record() proc log to the world basically as if you were doing world << "message".

One last problem to solve: have you ever sent debug messages out to the world for debugging, and then accidently forgotten to remove them before having players try your game? The n_Log library provides a debug() proc for this purpose:

debug("message")

But the catch is that it is only defined when the game is compiled in DEBUG mode. Otherwise you'll get a compiler error telling you to get rid of your debugging message!

Creating a Platformer With BYOND

Thu, 11 Nov 2010 21:18:46 +0000

Creating a Platformer With BYOND

BYOND gives you a default movement system. If you open Dream Maker, create a new project, make icons, declare turfs, build a map, and run the game you can walk around. You don't have to program how the movement works, the behavior is built in. My Sidescroller library does the same thing except it provides you with a movement system for sidescrolling action/platform games.

This article explains how the library works and how you can use it to create a game. If you're familiar with Dream Maker and can make a simple game then you can use this library to make a platformer.

1. Object Sizes
2. Ladders
3. Icon States
4. Bounding Boxes and Centered Icons
5. Jumping
6. Ramps

Using the Library

The library is very easy to set up. Here are step-by-step instructions for setting up the library. If you're familiar with the Dream Maker program you can have a working sidescroller in just a few minutes. This tutorial assumes you've completed those steps to set up the library and create a basic game. If you want to follow along with this tutorial and try code snippets out you should complete those steps now.

We'll now look at how you can utilize more features of the library and add some new features of your own.

Object Sizes

In the world you've created all objects are 32x32 boxes. In a real game your mob's icon will probably be a picture of a person. The mob's icon is 32x32 but the mob only occupies part of that box. To handle this we can modify the mob's pwidth and pheight vars.

Open up mob.dmi and change the icon state. Instead of being a 32x32 blue box make it a 24x24 blue box, like this:

Then add this to the code:

mob
    pwidth = 24
    pheight = 24

Now run the game. The mob now occupies a smaller space than before.

Ladders

The library has support for ladders. A ladder is a non-dense tile that a mob can climb. To create a ladder you need to draw an icon state for it, then add this code:

turf
    ladder
        is_ladder = 1
        icon_state = "ladder"

The is_ladder variable tells the library that the turf can be climbed. Place some ladders on the map and run the game:

Use the up and down arrow keys to climb ladders.

Icon States

With BYOND's default movement system it's often sufficient for a mob to have a single, 4-directional icon state. When the player moves the direction is updated so the proper image is shown. In an action/platform game you can perform different kinds of actions, like running or jumping, so you need different icon states. The library handles this for you.

You set the mob's icon var and the library will automatically update the mob's icon_state based on what the mob is doing. If you're standing still your icon_state will be set to "standing". If you're moving (on the ground) it'll be set to "moving". If you're hanging on a ladder it'll be set to "climbing". And if you're in the air (but not on a ladder) it'll be set to "jumping".

Let's create these icon states (or you can download this icon, you might need to right click the link and pick "Save As..."):

Note: These states are all 4-directional. The library automatically sets your direction to EAST or WEST so you need to make sure those states have images. For reference, here's what the standing state looks like:

You don't need to add any code. When you run the demo your mob will use these new icon states.

Bounding Boxes and Centered Icons

A mob's bounding box is the space that the mob occupies. The size of the box is determined by the pwidth and pheight variables. The position of the box is assumed to be in the lower-left corner of the mob's icon. However, this isn't always the case. Consider this poorly drawn person:

The mob is roughly 16 pixels wide. If we set the mob's pwidth var to 16, here's what happens:

The mob appears to be partially inside the wall. This is because the mob's bounding box is assumed to be in the lower left corner of the icon but we drew the mob in the center of the icon. To compensate for this we need to shift the mob's icon to the left 8 pixels when the game is running so that the part of the icon that represents the mob is inside the bounding box. We can do this with the mob's pixel_x var:

mob
    pwidth = 16
    pheight = 19
    pixel_x = -8

Now here's what you'll see when you run the game:

The icon is shifted to the left so the mob cannot appear to be inside walls anymore.

Jumping

The library keeps track of the mob's motion as a velocity. A velocity is like a speed but it also has a direction assigned to it. Saying that the mob is moving four pixels per second is a speed, but saying that it's moving upwards at four pixels per second is a velocity. The library uses the vel_x and vel_y vars to keep track of the mob's velocity in the x (horizontal) and y (vertical) directions.

This sounds complicated but it actually makes things easy. When you jump, all that happens is your upwards velocity (vel_y) is increased. To handle jumping the library calls the mob's jump proc, here's the default behavior:

jump()
    vel_y = 10

This means that when you jump your mob will move upwards at a rate of 10 pixels per second. Due to gravity it'll slow down and begin to fall. If we wanted to make the mob jump higher we can override the jump proc to create a different behavior. We can add this to our code:

mob
    jump()
        vel_y = 12

An upwards velocity of 12 is enough to jump two tiles high. Don't get too carried away - the height of the jump increases a lot with each increase to the velocity. Setting vel_y = 14 is enough to jump three tiles high and 16 is enough to jump four tiles high.

Ramps

You can also create ramps. Open turfs.dmi and make an icon that looks like this:

Call it "ramp". Then add this code:

turf
    ramp
        pleft = 0
        pright = 32
        density = 1
        icon_state = "ramp"

The pleft and pright vars are used to define ramps. The pleft var tells the library the height of the turf at its left side. The pright var tells the library the height of the turf at its right side. We drew the ramp as being low on the left side and high on the right side so we set its pleft and pright to match. The height at its right side is 32 because the tiles are 32 pixels tall.

Place the ramp on the map and run the game.

Web Service: Mediator server for BYOND authentication

Tue, 26 Oct 2010 21:11:19 +0000

In the past, authentication with a BYOND key was only possible if you used DMCGI to do it. There was simply no way to get the login details any other way. Some people have requested a new feature to allow any program to authenticate BYOND keys.

That feature might not be here, but I offer the next best thing: authentication using a mediator server (which is pretty much what the feature request suggests anyway, so I guess I did the work for them!).

Without further ado I would like to present:

The McKay-Carter Intergalactic Bridge dta_auth BYOND authentication system

Let's get on with the technical details, as I'm sure most of you are looking straight for it.

The following steps are taken to authenticate a user:

The user arrives at http://www.yoursite.com/login.php.
At this point your script redirects the user to http://home.androiddata.net/auth.cgi and passes along two variables:
- A session id which is a variable only your server and the real client share. Upon receival this is immediately taken out of the loop to minimize the possibility of eavesdropping. In my example it is derived from the current time.
- A return URL which is usually back to your script. In my example it will be http://www.yoursite.com/login.php.
The user is taken to http://secure.byond.com where they can login..
Once the user successfully logs in with a valid BYOND key they are redirected back to http://home.androiddata.net/auth.cgi where the magic happens.
My script redirects the user back to http://www.yoursite.com/login.php where you receive a certificate ID. You then pass this value back and confirm the validity of the certificate, after which the authentication is completed.

The security measures taken:

A unique ID pinpoints the exact certificate that contains the authentication request.
A session ID verifies that the certificate was indeed requested by your server.
A hash is sent with the client to ensure that they have access to that certificate and to ensure other domains can't read your certificates.
The BYOND key and ckey are both stored in the certificate and cross-referenced with what you receive to prevent spoofing of keys.
You may optionally specify an IP address (or other unique means of verification) to verify that as well.
Finally, the certificate is destroyed immediately after you've checked it to prevent it from being re-used in the future.

In addition to the above clients are expected to always log-in with a new set of credentials, so it's not possible for a client to re-use someone else's log-in on your site.

And now a code sample (because nobody on BYOND listens to you unless you post one!):

index.php

<?php session_start();



if(isset($_SESSION['byond_key'])){

    echo 'You are logged in as ' . $_SESSION['byond_key'] . '! <a href="login.php?logout=1">Logout</a>';

}else{

    echo 'You are NOT logged in. <a href="login.php">Login</a>';

}
 ?>

login.php

<?php session_start();


 //the URL that the mediator server should reroute the user to once authentication finishes goes here
 define('URL', 'http://www.cowed.org/auth/login.php');



if(!isset($_SESSION['byond_key'])){ //we are not logged in

    if(isset($_GET['id']) && isset($_GET['key']) && isset($_GET['ckey']) && isset($_GET['hash'])){

        //looks like we received a response

        $crl = curl_init();

        curl_setopt($crl, CURLOPT_URL, 'http://home.androiddata.net/auth.cgi?id=' . $_GET['id'] . '&sid=' . $_SESSION['sid'] . '&hash=' . $_GET['hash'] . '&ckey=' . $_GET['ckey'] . '&key=' . $_GET['key']);

        curl_setopt($crl, CURLOPT_RETURNTRANSFER, 1);

        curl_setopt($crl, CURLOPT_CONNECTTIMEOUT, 5);

        $ret = curl_exec($crl);

        curl_close($crl);

        

        if($ret == 0){

            $_SESSION['byond_key'] = $_GET['key'];

            header('Location: index.php');

        }else{

            echo 'ERROR: Received return code ' . $ret . ' from the mediator server.';

        }

    }else{

        //redirect the user to the mediator server

        $_SESSION['sid'] = time();

        header('Location: http://home.androiddata.net/auth.cgi?sid=' . $_SESSION['sid'] . '&returnurl=' . URL);

    }

}else{

    //we're already logged in, so continue unless explicitly instructed to logout

    if(isset($_GET['logout'])){

        $_SESSION = array();

        session_destroy();

    }

    

    header('Location: index.php');

}


 ?>

Please note: The example requires that you have the "curl" extension installed for PHP and assumes an installation of PHP5.2 or higher. If it doesn't work for you try these instructions.

I hope that this web service will open up more BYOND-powered websites and services.

Thanks!
-D

JRUtils - Numbers

Wed, 01 Sep 2010 04:53:48 +0000

A few weeks ago I saw a library floating around that claimed to convert numbers to their spelled-out form. Having done this before, I was curious how the author went about implementing it themselves. As it turned out, the result wasn't all that great. But since I already happened to have Perl code lying around for just such an occasion, I thought, why not convert it to DM?

JRUtils - Numbers was born out of a plugin I wrote for the Movable Type blog system several years ago. The original plugin was designed to do several things: Change a word to its plural form depending on a number it was given, spell out numbers, and add commas as desired. In a blog environment this was a nice thing to have. Movable Type, at least at the time, was based all around setting up templates and it used pseudo-HTML tags to do its work. My plugin created some new tags to use, so if someone wanted their posts to show "three comments" they could do so, but "3 lunches" would have been just as easy. This gave a lot of stylistic freedom to blog authors.

This library can be used in a variety of different games, but will fit in particularly well in board games, MUDs, strategy games, etc. And as a bonus, it's one of the libraries on the no-penalty list for the Cartridge Classic II.

Plurals

The DM language already includes a very handy macro for pluralizing words, the \s macro. But as I discovered in Incursion, this isn't always ideal. Not every word has a plural form ending in -s. Some have unusual plural forms, like "deer", but most words follow a few basic rules.

If a word ends in s, ch, sh, or x, the plural should have -es added.
If a word ends in z, the plural should have -es added, but the z should be doubled if it isn't already.
If a word ends in y, and the y is not preceded by a vowel, the -y should be replaced with -ies.
All other words, with only specific exceptions, should have -s added.

A common rule, but one that does not apply to every such word, is that words ending in -o also get an -es instead of just an -s. But even though this is more than norm than the exception, it isn't applied here. A few other common but not universal rules, like -lf to -lves, and -is to -es, are also left out. You're on your own with those.

Now there's a proc that follows those rules, and it leaves the capitalization of the original word intact (as best it can).

jru_Pluralize(word, n=0)

If you pass in a word and a number, you'll get the plural version of the word. You don't have to pass in a number; it's just there so that if the number is 1, the word doesn't get changed.

If the word you want to pluralize doesn't have a "normal" plural form, you can add it to the jru_plurals list at runtime like so:

jru_plurals["cactus"] = "cacti"
jru_plurals["half"] = "halves"
jru_plurals["person"] = "people"

Always add the words to the list in lowercase form. Any word in this associative list will be pluralized to the correct form you supply, but with its original capitalization intact.

There's one other bonus here, which is that the number n may be a text string. It doesn't have to be a "true" number.

For longer stretches of text, there is another proc available:

jru_PlurlizeText(txt)

This proc will look for any instance of "[number] [word]" in a block of text and try to pluralize the word if necessary.

Commas

It's common to see commas inserted into numbers in formal writing, like 1,000 for a thousand instead of the blunt 1000 that is spit out if you just stick the number directly into the output. Even worse, if you're using large numbers they may just look like "1.0e6" instead of 1000000 or 1,000,000.

While this is easy to soft-code by yourself, why reinvent the wheel?

jru_Commafy(n)

This proc returns n with commas inserted. The number n may be a number, or it may be a number in text form like "1234" instead of 1234. Decimal points and negatives are left intact.

jru_CommafyText(txt)

This applies the commafication to a whole block of text, converting any numbers within to comma form.

Spelling out

Converting numbers to their spelled-out, textual representation is a tricky business because there are so many rules to follow. Fortunately, this routine takes all the guesswork out.

jru_NumberText(n, th)

This returns the number n (which again, may be represented as a text string instead of a true number) in a spelled-out format. If the th argument is true, the result will be in an ordinal form (e.g., "first" instead of "one"). The routine only works with whole, positive numbers, so it will discard everything after a decimal point and turn negatives to positives.

Here are some examples:

`n`	result (`th=0`)	result (`th=1`)
1	one	first
13	thirteen	thirteenth
25	twenty-five	twenty-fifth
100	one hundred	hundredth
140	one hundred forty	one hundred fortieth
1234	one thousand, two hundred thirty-four	one thousand, two hundred thirty-fourth
9001	nine thousand one	nine thousand first
1000000	one million	millionth
1000002	one million two	one million second

The routine is smart enough to throw away unnecessary commas, as in "nine thousand one" instead of "nine thousand, one". Also in an ordinal form, it will omit a leading "one" if there is only one other word, like "hundredth".

proc/jru_NumbersText(txt)

This routine will convert all numbers in a block of text to their spelled-out equivalents. If the number is followed by st, nd, rd, or th, it will be converted to ordinal form. So "My 1st victory earned 9 points!" would become "My first victory earned nine points!" instead.

Utility

A few other routines are included for various helpful purposes.

jru_Leading(n, places=1, fill="0")

Takes a number n, in numerical or string format, and pads it out to the number of places you want with a leading digit or character. This is good for timers, for instance, so you can call "[hours]:[jru_Leading(minutes,2)]:[jru_Leading(seconds,2)]" to output to your timer display.

jru_SplitText(txt, delimit="/")

This splits a line of text into a list. It's used internally to reduce the number of strings that get compiled with your project. Unlike params2list() it will work well with duplicate values, since the result is not an associative list.

jru_SanitizeNum(n, no_negative=0, no_decimal=0)

The number n, in numerical or string format, is converted to a string. If negatives or decimals are not allowed they can be removed. Unlike just using "[n]", this will correctly output a number like 1e6 as "1000000". It's like a version of text2num() that always gets all the digits it can, but it also can take bogus input and clean it up.

Rule Your Numbers!

Hopefully this library will provide just the routines you need to tame numbers in your games, providing classier output and jazzing up your statpanels, grids, and text. What can you do with numbers once they're tamed down?

It works, so it must be right!

Wed, 12 May 2010 19:56:23 +0000

You're Wrong.

There's a certain mentality that I've noticed a lot of users within our ranks have. This is mostly common to inexperienced programmers who have managed to throw out what can be considered barely passable games and who now suddenly think they're top dog because they've done so.

The mentality I'm referring too is pretty much summed up in the title of this post, if at any time recently you've said: "it works, so I'm doing it right", "you do it differently than I do, that doesn't make you right" or any variation there of, then chances are you fall into this category. And this post is aimed directly between your eyes.

You see, there are many ways to do lots of things. And anyone with any life experience can tell you, even though they work, it doesn't make them safe, advisable and least of all, correct.

For a quick analogy: I can drive the wrong way down a motorway. By the logic of those targeted at this post, I'm doing it right, because I'm still getting to my desired destination. By the logic of all other experienced motorists not on any form of narcotic, I'm being an absolute tool by driving recklessly and putting the lives of other people in my obviously foolish hands.

In a real life scenario, I'd probably get my license revoked for dangerous driving and there might also be some jail time depending on my reaction towards the judge. If programming required a license, everyone this post is targeted at would by theory, also get their licenses revoked and no longer be allowed to make games. And I dare say a few of you would also be looking at jail time for your reactions towards those who attempt to help you by telling you you're doing it wrong.

Now lets move onto a code example. One Garthor corrected me on recently; just to show that even I am not infallible when it comes to programming. You can view the thread here. Please note my reaction, or lack there of, as that is pretty much what this entire post is about. Instead of arguing that I'm correct because it works, I conferred with my colleagues and then accepted the words of a superior programmer silently, and am now no longer making that mistake.

Wrong:

#define SECOND 10
#define MINUTE (SECOND * 60)
#define HOUR (MINUTE * 60)
#define DAY (HOUR * 24)

client
    proc
        SaveProc()
            //Some random save proc for clients.

proc
    recursive_save_or_something()
        for(var/client/C) C.SaveProc()
        sleep(HOUR) 
        .()

Better:

#define SECOND 10
#define MINUTE (SECOND * 60)
#define HOUR (MINUTE * 60)
#define DAY (HOUR * 24)

client
    proc
        SaveProc()
            //Some random save proc for clients.

proc
    recursive_save_or_something()
        while(TRUE)
            for(var/client/C) C.SaveProc()
            sleep(HOUR)

(Come to think of it, that proc should probably have a set background = TRUE in it.)

As you can see, my original example still worked, but that didn't mean I was right, at the end of the line, a place you can't reach in two minute testing sessions of new features, I'd have eventually crashed my game entirely. And we all know what that means.

I'd have gone running to the developer forums crying: "why oh why sweet merciful gods of programming does my game fail so?" They would have eventually given me an answer if anyone cared enough to stick around long enough to debug it, and I'd have been left with a lot of reworking to do, simply because I never learned my lesson and undoubtedly made lots more of these mistakes.

Now let's take a trip down memory lane, way back in 2005 when I was a way more inexperienced programmer than I am now and dared to ask the question a lot of you refuse to ask and stick to your "I'm right" mentality: Why does which way matter?. This thread should explain to you why we go out of our way to tell you why your examples are incorrect. Don't let the attitude a lot of us have fool you, our goal is to help you. But we're not certified teachers and a lot of us don't have the patience to hold your hand through everything. Which is why we often link to reference material that we hope you will read and understand.

I hope this article has been enlightening for you. And I also hope that it's also opened a few peoples eyes. You don't learn by getting it right first time every time, but if you're doing it wrong, you will learn by simply asking the right questions and learning from what better programmers have to say. If I had not listened to Lummox JR, Wizkidd0123, Xooxer, Crispy, YMIHere or Garthor, I'd still be making horrendous mistakes that would ultimately cost me the stability of my game.

That's not to say I'm still not making mistakes, as humans, we are doomed to forever make mistakes. Hell, the previous example I used in this post probably has a better way to go about it (ten points for someone who comes up with a working theory as to why). Which is precisely what Design Philosophy is for: Asking people if how you're doing something is right, and whether or not there's a better method to go about it.

If this post reminds you of yourself, I also recommend reading How to Fail at Game Programming by Deadron. Well worth it, if only for the entertainment value.

Novice Programmer Guide To Success #1

Wed, 14 Apr 2010 02:00:08 +0000

Introduction...

Taking the step from simply being a gamer, and going into the world of programming and development is a large step. It requires the willingness to learn, experiment, and take advice and criticism. It may be confusing at first, but as you learn you will be able to look back at your previous attempts and laugh. One of the most important things for the new programmer is how to ask for help, and learn from it. You should only ask for help after you have checked for examples of what you want to do in the resources section.

I need the code...

When asking for help you want to explain what you are trying to do, and what parts you are having trouble with. Below are examples of the right and wrong way to ask for something. This is a common question I have come across, along with a snippet of code I would provide to each question.

(R = Right, W = Wrong)

W: I want a GM code.

// The GM code.
GM

R: I would like to know how to give certain people in my game special verbs and stats.

// A global list containing the keys of our game masters, separated by commas.
var/list/GMs=list("Ulterior Motives")

// A global list of out players, GMs should not be in this list.
var/list/players=list()

// Create a datum type to hold all of our special verbs.
GM
  
  // Kick people out of your world.
  verb/Boot()
    
    // Let the person using the verb pick a player out of our list. 
    del(input("Which player would you like to boot?","Boot") in (players))

// The mob type of our human players.
mob/player
    
  //Give them some variables.
  var
    health = 10
    strength = 3
  
  //When they connect to a mob, this is not the same as New().
  Login()

    //Place them on the first non-dense tile.
    ..()

    //If they are an admin give them our special verbs and stats.
    if(src.key in GMs)
      src.verbs += typesof(/GM/verb)
      src.health += 20
      src.strength += 10
      
    //Otherwise add them to the list players.
    else
      players.Add(src)

As you can see explaining what you want, instead of asking for the code gives you much better results. This goes beyond just getting some snippet of code however. Now that you have "the code" what are you going to do with it? Typically the new programmer will copy and paste the code into their project. This is wrong, and you won't learn anything, nor will you be able to change it to fit your needs. Most of the time when asking for help you will get examples of how to do something, so you can learn how to do it yourself.

What are those double slashes for...?

Every programming language provides a way for programmer to add comments to their code to explain how it works. Why would they do such a crazy thing if they already know what it does? Sometimes programmers might forget how something works after going back to look at it later, but this isn't their only use. In the example the comments are used to help you learn what the code does. I can guarantee if you read these comments, and try to understand what the code does and write your own you will learn how to program much faster.

When I first started learning and asking for help, comments helped me more than anything. Gathor is the one who typically helped me with my problems on the forums, and reading his comments made learning how to program much easier. If I didn't understand something I would ask how it works, this is how to succeed at asking for help and learning from it.

Projects and goals...

Most new programmers read a tutorial like one of the great ZBTs, and they think they can jump in and create and start on a large RPG or some other massive project. This is an extremely terrible idea. You need to start small, and build on to that. Create a variety of small games to advance your skills and learn new techniques and ways of programming. Release this to the general BYOND community and announce it on the forums. Now people can comment on what you have done, and give you more ideas to add on. This way you can keep adding to this small project, and learn new things along the way.

Always set goals to achieve when starting a project(see also Functional Specifications for designing your project). For instance if you read ZBT #1 about creating RPGs, she has goals at the end for you to add onto the project. Try to complete these goals, then add your own. The more things to do the more you will learn, after doing this your programming problem solving skills will increase. Goals for ZBT #1 could include, making an NPC walk around, making an enemy drop a random item only 25% of the time when they are killed, creating random server messages that go to the players, or anything. Just stick with that one goal until it is completed.

Summary...

How fast or slow you learn to program, and how well you learn to program all depends on you. If you are willing to learn and don't get discouraged you will learn quickly. If you use the resources provided to you and take help as a learning experience you will learn how to do this the right way.

Just remember one of the most basic rules of programming, if you are repeatedly doing the same thing over and over with if statements and what not, then you are doing something wrong. This is where your programing problem solving should kick in. The more you know the easier this will be to do. At first though you might need to post it in the developer how-to and ask how to take out the repetitiveness. After a few weeks to a month you should be able to look at it and learn on your own how to do this.

If this helps even one newcomer break away from the typical fate of the new programmer, then my goal was successful. I will be around to help any new programmer as long as they are trying to learn and following this guide. Programming can be very fun and rewarding once you get the hang of it. Breathing air into and creating a project yourself is a good feeling.

I'll leave you with a quote by a very inspirational man that explains what I'm trying to say.

"When the race gets hard to run. It means you just can't take the pace." -- Bob Marley

Decent Game Design, Part 1 - Player Entry

Fri, 12 Feb 2010 10:48:53 +0000

Welcome to part one of the decent game design series. This series expects you to have a basic knowledge of the BYOND Interface, and to have read the Making skins in BYOND 4.0 series by Lummox JR.

Please keep in mind, the integrity of the series may be undermined by the fact I'm absolutely horrible at graphics. Just be aware that where my graphics are terrible, hopefully, others wont be, and thus the tricks and tips that so very few people seem to know and use will not only help you advertise within BYOND, but also outside of BYOND.

First and foremost, let's look at at what most games that aren't taking advantage of the skins look like to the casual new user. To avoid offending users, I've recreated the look I get when I joined the better most of games.

As you can see, rushed appearance of my graphics aside, that is pretty poor. There's a lot of information on that which really doesn't need to be there. If I was some random new player who found your game outside of BYOND, I probably wouldn't give it the time of day. Let's break down what's wrong with it.

Unnecessary Stat() Tabs:
Let's face it, I haven't made or loaded a character yet. So there's absolutely no reason why I should be able to see it's name, race, inventory and other stats (hp, mp, exp etc). This stuff is utterly useless. Remove it.

Unnecessary Verbs:
Much like the stats, I'm not in a character, so I shouldn't have access to verbs like "Chop Wood" or even, "say". You can argue the OOC tab possibly, but to be honest, how many games have you played outside of BYOND that allow you communicate with the users before you've entered the game. None I'm aware of (there's probably a small few, but we're going with majorities here). This just looks tacky and, if you haven't actually protected any of your verbs from misuse, can lead to bugs in your games.

Load/Create/Delete/Quit Verbs:
These are buttons on the map itself. Completely pointless having these in view like that. You might as well have not included the splash screen itself, all it appears to be is a pretty (ugly...) face to an otherwise ugly layout.

So, let's work on improving this. Firstly, what does that interface screen actually have? A background picture and three buttons. Seems easy enough. To give you an example, we'll make this work in a new project, you can later adapt it to your own projects if you want.

So, make an interface file. We're given a set of default marcos, a default menu and a default window. The default window is where the tricky stuff is going to happen.

Setting up your default window:

Rename the default window to window_default.
Place a child control on very top left of the window, name it "child_main" and use the "Fill Window" button. Also set it's anchors to Top Left and Bottom Right.

Now we have the basis of our main window done. Now we need to make two new windows in the interface, we're going to set them their ids "pane_splash" and "pane_main" respectively, do this now. Remember to check the "This is a pane" checkbox.

Setting up your splash pane:

Edit the pane and set it's background image to our splash screen image.
Add a button to the splash pane. Give it the ID "button_new_character" and set it's text to "New Character". Change the button type to "Push Box" and check the box "Flat". Then set it's command to "NewCharacter". Be sure to set any background images necessary.
Copy the above button and past it two more times. Editing the values of the pasted buttons to "button_load_character", "button_load_quit" and add their respective text values and commands.

Setting up the main pane:

Add an output control to the pane and set it's id "output_default" and check the "default" check box. Resize it to take up a majority of the window and set it's anchors to "Top Left" and "Bottom Right"
Add an input control to the pane and set it's id to "input_default" and check the default check box. Resize it to take up the minority of the bottom of the pane and set it's anchors to "Bottom Left" and "Bottom Right".

Now we have our splash screen and main pane done.

Now it's time to write the code for this little beauty. We'll need two code files (well, one, but I believe in being neat). These will be named "datum_entry.dm" and "client". Each one reflects what they're going to contain. "datum_entry.dm" will contain the code to make this splash screen stuff work and "client.dm" will contain any code relating to the client.

To setup the code files, they'll look like this:

// client.dm
client
    New()
        . = ..()

// datum_entry.dm
player_entry
    verb
        NewCharacter()
        
        LoadCharacter()
        
        QuitGame()

For starters, we need to edit the client file so they can view the splash screen and set the proper window specifics as we want. To do this, we'll use winset(). For starters, we don't want the user to resize the window, nor do we want it to have a title bar, a status bar, any menus or any macros. We also want the user to have access to the verbs we made (or will make) for player entry.

This is all pretty basic stuff:

client
    New()
        . = ..()
        winset(src, null, {"
            window_default.child_main.left  = "pane_splash";
            window_default.can-resize       = "false";
            window_default.statusbar        = "false";
            window_default.titlebar     = "false";
            window_default.macro        = null;
            window_default.menu         = null
        "})
        src.verbs += typesof(/player_entry/verb)

Now we want to configure the datum_entry.dm to handle the logins of player mobs and whatnot. As well as change the splash screen. Character handling comes in Part 2 of this series, so we can pretty much skip this part and just use some generic interface altering code.

player_entry
    verb
        NewCharacter()
            generic_interface_changing_code(usr.client)
        
        LoadCharacter()
            generic_interface_changing_code(usr.client)
            
        QuitGame()
            del usr
        
proc
    generic_interface_changing_code(client/C)
        winset(C, null, {"
            window_default.child_main.left  = "pane_main";
            window_default.can-resize       = "true";
            window_default.statusbar        = "true";
            window_default.titlebar     = "true";
            window_default.macro        = "macro";
            window_default.menu         = "menu";
        "})

When this is executed, we get the following result:

Both the New Character and Load Character buttons do the same thing at the moment, mostly because I wanted to beak this tutorial up into parts.

Now you have a basic understanding of writing a splash screen in BYOND. Your tasks for the end of this lesson is a rather simple one: Centre the window. Who ever heard of a splash screen appearing in some random place on the users screen? As such, your job is to centre the window using whatever means you deem necessary and wherever you find necessary.

Part 2 will contain methods to handle character creation. For a clue at what I'm getting at, think of every game that uses input() to create characters, and imagine how much you hated that process.

Introducing dta_admin

Mon, 25 Jan 2010 21:30:38 +0000

I've been lurking in the shadows for quite some time but I believe it's time to come forward with a new initiative: creating a new system to help administrate your game.

The goal of this library is to replace the old "s_admin" by Spuzzum which was made in the stone age, back when we were ecstatic that we could play MIDI files and we were happy if we could find a Javascript exploit for our browser windows.

Introducing dta_admin

dta_admin is a new library created and maintained by me. It aims to create an easy-to-use, extensible administrator panel so you can focus on your game instead of having to finish a system most of your players won't ever get to see apart from perhaps the trolls.

What makes dta_admin so different from any other admin library created is that it's built for BYOND 4.0 and it's modular, meaning you can extend its functionality easily.

Modules

dta_admin starts out with a simple "show panel" verb. This brings up a panel which - if no modules are present - will appear to be empty.

However it is with the modules that this library gains its true power. You can define new modules within your project without ever having to touch the the libraries' code. Granted, this is the bonafide intention of any good library, but I haven't seen any libraries around for BYOND4+ that allow you to administrate your game and allow you to extend it easily for whatever you've got cooked up in that game of yours.

Not only can you define modules for your project, but you can also help out by creating extensions (modules) that can be implemented in future versions of dta_admin. Not only can you extend the library for your own game, but you can also help me the community by ~~doing my work for me~~ writing useful modules.

Features

The basics of the library work: you can create modules, mess with permissions and there exists a few samples to help you get started.

However the library does not have a lot of modules yet, and that's where you come in: if you're feeling up to it, you may want to help out writing modules for this library to make it even better!

See the hub entry of this library at hub://AndroidData.dta_admin!
Documentation for dta_admin

Distributing your game outside of BYOND.

Sat, 23 Jan 2010 06:09:58 +0000

So you've finally made your game, what a feeling of triumph you must have burning deep inside you. With your game complete, you're ready to distribute it to the masses of potentially interested players both inside, and outside of BYOND.

You might remember another article by one cunning young programmer entitled: "Get a hold of your target audience". Since that covered methods of gaining interest in your game within the BYOND site, lets discuss ways of getting people outside of BYOND to be interested.

As of BYOND 461, we've been able to distribute BYOND without the installation of the program, but undoubtedly, a lot of people have been asking how to do that. So let's discuss this now.

First and foremost, the release notes say if we place a folder named "byond" in our distribution, the program will default to that. So lets set up out folder. Go to your desktop and make a new folder with the same name as your game. Then download and unzip the latest BYOND zip. Cut the "byond" folder from the zip location, and paste it into your new folder. Now we have the game folder ready.

Back in Dream Maker, we need to prepare our game. First, we need to go to "Build" then "Make EXE". By default the executable will be the same name as your .DME file, so there's no need to change that. The Hub/Command ID is what we need to focus on.

Seeing as we're distributing outside of BYOND, chances are, none (or very, very few) of the people we hand the game out too will have a BYOND Key. With this in mind, first we need to set the Hub/Command ID to the name of our .DMB file. In my case, I'll link it to "file://MyGame.dmb". Then, we need to append ##guest. This will deliberately bypass the BYOND Pager, and automatically log the user in as a guest. If you want to add a touch of professionalism to it, you can add an Icon file to the executable. (The icon files are limited to .ICO. If you don't have a converter or don't wish to look for one, you can use this handy tool to convert from PNG to ICO via a web interface, neat yeah?)

Once you've received the message confirming your .EXE was built, we need to copy the necessary files out of our game folder (.exe, .dmb and .rsc). We'll paste these in the new folder we made on our desktop.

There, now we have everything we need to freely distribute our game to users who don't have BYOND installed. All you have to do is Zip the folder, and send it in the direction of people who might be interested.

For the fun of it, I've released the zipped version of my test project. Try it on a computer that doesn't have BYOND installed and see how you fair. =)

--

Make EXE also has a few other tricks up it's sleeve. You're not limited to just distributing the DMB and RSC of your game for the user to play locally. The user is also able to play on your 24/7 server (if you have one). Provided of course your game allows the use of guest keys.

To do this, just change "file://MyGame.dmb##guest" to "byond://server_ip:port##guest". This also removes the need for you to distribute the DMB and RSC with your executable (you'll still need the byond folder, however). There's no sense in including the host files if the user isn't going to need them, right?

--

For other tips and tricks concerning Make EXE, you can review the article A Beginners' Guide to Publishing BYOND Games. Which contains a list and description of all possible appendices to the command URL. (##local, ##host, ##hub, ##remote, ##live, ##info, ##guest and ##version=X).

Your First Isometric World

Wed, 11 Nov 2009 22:22:14 +0000

Isometric is a type of projection that gives the illusion of 3D without actually using true 3D. BYOND lets you make isometric games while taking out a lot of the hassle of determining how to arrange the graphics and draw them in the right order. That's a big help because the math and logic involved can be complex, and it just gets in the way of making the best game you can.

In BYOND's isometric system, north points toward the upper right of the player's screen, and east points to the lower right. It's as if the whole map was rotated 45° clockwise, and then instead of looking at it straight down you're looking at it at only a slight downward angle of 30°. This makes every map square into a squashed diamond shape. BYOND uses 2:1 isometric graphics, meaning that the angle the map is "tilted" makes every diamond half as tall as it is wide.

The first step to using isometric graphics is to set up your project by defining world.map_format and world.icon_size.

world
    map_format = ISOMETRIC_MAP
    icon_size = 64

I picked an icon_size of 64, which means we'll be using 64×64-pixel icons, because it's a good size to work with in isometric. The width of the diamond tiles is always the same as the width of the icons we use, so each diamond will be 64×32, and there will be 32 pixels left over at the top of each icon for vertical structures. Whatever size you choose for an isometric game, be sure the width is always a multiple of 4--otherwise the math will be subject to some rounding errors and you'll see seams between the tiles.

In Dream Maker, create a new icon and give it a size of 64×64. Create a new pixmap, and choose a color for the base tile, let's say a nice shade of gray. Then you'll see a menu option called Icon | Create isometric tile. Select that, and you'll see a diamond shape appear at the bottom half of the icon.

Take a look at that diamond and you'll notice a few things. The pixels on the very left and very right are blank. This is because of the way the diamonds will be fitted together. The lines along the edges however follow a perfect 2:1 ratio, with 2 pixels horizontally for every 1 pixel vertically. Select the line tool and then draw in some lighter and darker lines along the edges for shading. This will be a good base tile.

Now let's create a new icon for a wall. Let's say we want the walls to be red blocks, about 24 pixels high. Make a new icon and follow the same steps to make a plain diamond shape, in a light shade of red. Now use the selection tool to move that up to near the top of the icon. There should be 8 pixels of space above the diamond and 24 below. This will be the top of the wall. Hit Ctrl+X to cut this image and put it on the clipboard. Now choose a neutral color like white and create a diamond again, but leave it where it is. Hit Ctrl+V to paste the red diamond back over it.

Next, choose a medium red and draw a vertical line from just to the left of the top diamond (1,40) to just left of the bottom diamond (1,17). Draw another line like this at just left of the center, from 32,1 to 32,24. Switch to the fill tool and fill in everything between the two vertical lines so there's a solid color face there. Now repeat the process on the right, in a darker shade of red. Bingo; we have a red block. You can decorate it further if you like.

If you're wondering why the wall has the far left and far right pixels filled in, which wasn't the case for the floor or for the top of the wall, it's because gaps would show up if two of these walls were right next to each other. Notice that by doing it this way, the left side of the block is 32 pixels wide, as is the right side. By placing two walls next to each other they should form a solid unbroken surface.

Finally we'll need a mob icon, so just draw a circle about 32×32 and put it in the center of the icon. If it's 16 pixels from the bottom it will look like it's touching the ground at the middle of the diamond tile, which is perfect. Add some quick smiley features and there's a basic mob icon.

Now we can define some objects in the world.

turf
    icon = 'floor.dmi'

turf/wall
    density = 1
    icon = 'wall.dmi'

mob
    icon = 'player.dmi'
    pixel_step_size = 16

That's enough to get started, so let's build a map. Create a new map--nothing fancy, maybe just a 10×10×1. You'll notice the map editor has already laid out everything in isometric form--that's because world.map_format was set to ISOMETRIC_MAP earlier. Plunk down some of those red walls, then hit Ctrl+R to compile and run your project.

Try moving around for a bit. Probably the first thing you'll see is that hitting the up arrow actually moves your mob up and to the right; that's normal. Remember, that's the way north faces, and you're moving north. If this seems a little weird at first, don't worry about it--you and your players will get used to this quickly, and this control scheme has actually been around since Q*Bert.

The other thing you'll see that if the mob stands behind a wall, the wall will be drawn in front. This could also seem odd if you're used to thinking top-down, because in a topdown map the lower layers are always drawn behind the higher ones. But in isometric maps, you have to think in three dimensions even though the map isn't truly 3D. Tiles that are nearer to the viewer should always be drawn over tiles that are farther away regardless of their layer, right? So layers only matter for things that are on the same tile.

Moving around in this system should look pretty fluid, with one exception. If you move diagonally behind a wall, you'll see your mob temporarily drawn on top of the wall.

Like I said at the beginning, BYOND is only giving you an illusion of 3D. In order to draw everything properly it has to make some calculations and educated guesses about which order to draw tiles in. Nearer tiles get drawn on top of tiles that are further away, but what happens when your mob is between two tiles? In those cases, it has to be drawn in front of the nearer tile so that the floor of the near tile won't cover it up. So the reason you see the mob on top of the wall while moving diagonally behind it is that, as far as BYOND's isometric engine is concerned, the mob is temporarily on the same tile as the wall.

There are two ways to deal with this. One is to not allow players to "cut corners". After all if you did this in a topdown game, mobs would temporarily appear on top of wall icons while squeezing through a corner, and that looks bad too. Another way is to simply give the wall a layer that's higher than the mob. The layer will matter only when the mob and the wall are on the same tile, so it will cover up those visual gaffes nicely.

With a simple 10×10 map, the whole thing should show up on your map at any given time, since by default world.view is 6, which covers 13×13 tiles. For bigger maps, world.view or client.view (whichever you use) will determine the minimum number of tiles you'll see, with other tiles filling in to pad out the whole viewing area. This means two things: You can probably get away with using a smaller world.view, and if you use a HUD it's going to be smaller than it would be in a topdown game. The HUD is only as big as it has to be. In this tutorial the map is 10x10 and fills the whole screen. That makes a diamond 640 pixels wide, and 320 pixels high--plus there will be an extra 32 pixels for vertical stuff like the walls, so it's 352 pixels high in total. Every icon in the HUD is a 64×64 tile, so the HUD will be 10 tiles wide, and 6 tiles high. The Reference has a formula for calculating this if you need to, but with a HUD you can always use a relative screen_loc like "EAST,NORTH-1", so for most games you won't have to worry about that.

Now you know the basics of making an isometric game. There are more issues out there to explore, like how to handle big icons (and how not to), and the fact that you can use pixel_z to give your icons some vertical height. But the basics covered here should be enough for you to make a board game, strategy game, or RPG without any trouble. If you want to learn more about making isometric graphics, visit the BYOND Art Society or read some of the many pixel art tutorials available online.

The source files for this tutorial are available to download.

Dream Makers' site

Logrolling and Other Extreme Sports

An Introduction to n_Log (Finally!)

Rolling Logs

The Log Viewer Application

Advanced Functionality

Creating a Platformer With BYOND

Creating a Platformer With BYOND

Contents

Using the Library

Object Sizes

Ladders

Icon States

Bounding Boxes and Centered Icons

Jumping

Ramps

Web Service: Mediator server for BYOND authentication

The McKay-Carter Intergalactic Bridge dta_auth BYOND authentication system

JRUtils - Numbers

Plurals

Commas

Spelling out

Utility

Rule Your Numbers!

It works, so it must be right!

Novice Programmer Guide To Success #1

Decent Game Design, Part 1 - Player Entry

Introducing dta_admin

Introducing dta_admin

Modules

Features

Distributing your game outside of BYOND.

Your First Isometric World