Contents
How DUNG is Sabotaging You
I was recently reading a review of some game (which will remain nameless). The review was decidedly negative, but the one part that struck me was where the reviewer talked about what happened when he logged in. He joined the game, and was taken to the character creation screen; while still on that screen, another player teleported to his unfinished mob and killed it, displaying a victory message in bold letters to the entire server. This, obviously, wasn't intended by the author of the game, yet it could still be done. To be honest, I see problems like this in almost every game I join on BYOND. Why is BYOND so prone to such weird abuses?
Many years ago, when dinosaurs (and giant rats) walked the earth, the BYOND system was known as "DUNG", and though BYOND has grown and changed into something vastly different, there's still a little bit of DUNG at the center of every BYOND project.
DUNG stands for "Dantom's Universal Network Game", and that's how it started, as one game. Users of DUNG were allowed a high level of freedom in how they could change the MUD (multi-user-dungeon) by uploading new graphics, defining new items and monsters, and all sorts of fantastic possibilities made possible by the fledgling DM language. In the end, however, it was still, at it's core, Dantom's game, and it worked by Dantom's rules. For instance, each client that connected to the MUD had to be connected to a /mob object which the player would then control via the arrow keys. This mob, by default, would be placed into the first empty spot on the map, and the player would have immediate control over it. No fancy title screen, no character creation, no introductory movie or story. Just a mob and the arrow keys right from the get-go, and with that mob came all the verbs and permissions available to the standard mob, such as combat.
BYOND truly has changed since then. Now developers can create almost any type of game, wether that's an arcade fighter, a single player RPG, a board game, or any number of computer utilities not even related to games. However, at it's core, the old DUNG MUD is still running, connecting users to a mob as soon as they log in, and placing that mob somewhere on the map, among other nefarious activities. All a griefing player has to do to cause havoc in a game is to get around all of those "how much red do you want in your hair?" prompts, and use the arrow keys and verbs which DUNG automatically gives to every mob before the developer wanted the player to have them.
TopDiffuse Controls
Everything isn't DUNG's fault, though. BYOND is a powerful tool which allows a developer to harness the full range of input a computer can offer to a user, process that input, and then output it in a variety of ways. Let's think of some of the ways BYOND allows a user to provide input:
- Arrow Keys
- "Verbs" (both typed and in panels)
- Clicking
- Mouse Actions (such as drag/drop)
- Interface controls (such as buttons)
- Client Topics (such as browser links)
Now let's look at how those inputs are defined and handled by BYOND. The arrow keys, by default, are routed to a mob, which then defines it's own movement, most often in its own code file. The verbs could belong to any object at all, and could be defined anywhere. Clicks are, by default, routed to the atom that was clicked, which can define its own behavior in its own code file. Mouse Actions are handled in much the same way. Interface controls are handled by the client and must be defined in a .dmf file. Client Topics are handled by the client and are most often generated by the browser, though they can be generated by anything.
Perhaps you're starting to see how a user interacts with a BYOND program in a vast, potentially confusing, number of ways. What makes planning a program even harder is how a developer doesn't always have direct control over those interactions; we've already talked about how DUNG connects a user to a mob right off the bat, but consider how a user can also interact with a game simply by logging out. BYOND's control scheme is powerful, but diffuse, and if a developer does not take control, DUNG will.
TopA B Select Start ^ > v <
By this point, you should be starting to realize that you, unlike any other game programmer in the short history of gaming, have no control over your players, and that's because you're not restraining the great power of BYOND. BYOND offers a multitude of different inputs, but you don't have to use all of them. Consider the Atari gaming console: games for the Atari only had access to a joystick (four directions) and a button. In all, that's 5 on-off (binary) inputs. The Nintendo Entertainment System (NES) added the start and select buttons, plus a second button (A and B), for a total of 8 binary inputs.
The joystick which held all these inputs together was a sort of input module; the user could only interact with the program through that module, and the programmer could plan for any type of input which could be made by that module. He didn't have to worry about conflicting verb names or source settings, spoofed topics, bad arguments, or malicious text strings. If a developer didn't want the player to move, he simply ignored the joystick's movement commands, he didn't have to do any checks on "can_move" or block the movement keys at the client level.
By limiting the type of inputs that could be made, by placing them all into one input module, and by deciding before-hand exactly how a user will interact with a game, these developers were able to make incredibly stable games. For us to make stable games in BYOND, we need to make our own input modules.
TopInterface, Then Game
Our input module, or "interface" as I call it, will stand between the BYOND system of inputs and our game, taking the inputs we want and routing them to the game, and disregarding all the inputs we don't want. What is most important to our project is that we plan out everything we're going to allow our users to do before we actually start to make the game. As part of the plan for my interface I'll be making for this article, I've decided that all actions will be handled by a "command" proc, and that only two types of objects will be able to receive commands: the walker (the user's on-screen sprite, probably a mob), and the menu system (used in battle, inventory, character creation, etc.). Also, I've decided on the types of inputs available in my game: Movement keys (North, South, East, West, no diagonals), and two buttons ("Primary" and "Secondary"). These movement keys and buttons would probably be defined as macros in a .dmf file. Let's take a look at what the actual interface object might look like, and how it will receive it's commands from the client:
interface
var
client/client
focus
New(client/parent)
client = parent
proc
focus(what)
focus = what
if(istype(what, /atom))
client.eye = what
command(identity, value)
if(hascall(focus,"command"))
call(focus,"command")(identity, value)
client
var
interface/interface
New()
.=..()
interface = new(src)
Center(){ interface.command(PRIMARY)}
North(){ interface.command("move", NORTH)}
South(){ interface.command("move", SOUTH)}
East(){ interface.command("move", EAST)}
West(){ interface.command("move", WEST)}
Northwest(){ interface.command(SECONDARY)}
Northeast(){}
Southwest(){}
Southeast(){}
menu
var
position
proc
command(identity, value)
switch(identity)
if("move")
position = do_position_magic_with(value)
if(PRIMARY)
select(position)
if(SECONDARY)
cancel()
select(which)
yada_yada()
cancel()
yada_yada_yada()
That part was easy and rather straight forward, and the next part is even easier. How do we make sure that those commands, and only those commands, are accepted by our program? Don't define any other commands anywhere else! Don't randomly decide to sabotage the entire interface by defining DblClick() on some random turf. If you need double click events, then run them through the interface, like this:
client
DblClick(object, location, control, params)
interface.command("double click", object)
Journey BYOND, O Developer
Granted, the interface above doesn't solve our problems. We havn't talked about attacking, and nothing there will keep players from attacking mobs as they log in. What it does do is allow us to start to build our own game, independent from DUNG. Yes, all clients need a mob, but that mob doesn't need to do anything. Move it to null in client/New(), then use interface.focus to change the client's eye to something else, like a title screen. Because we're routing movement keys to the focus, we can have a cursor on the title screen, moving between the options, instead of using "click" on some turf-buttons. From there, we can focus on a character creation menu. When the character creation menu is finished, and the user uses the PRIMARY key to select their completed character, that info can then be routed back to the character creation system, which will instantiate a /walker object for the player, and then tell the interface to focus on that. Now your player is walking around in their own custom character, seeing their actions on screen, and it's all separated from the DUNG mob that's floating around wherever null is.
Think of all the things you can do now that you're free of DUNG! Should the player die, we can actually delete the walker object without being afraid of kicking the client out of the program. The walker disappears, and we tell the interface to focus on a new character creation object.
Sure, that walker won't give players access to verbs when it walks next to doors or objects to be picked up, and it won't place those verbs into ugly panels to be clicked and macro'd unscrupulously. Sure, we'll have to find better ways to make combat systems now that we're not tempted to put everything into one giant, broken, attack verb. To be honest, I can think of nothing that holds developers back more than the notion of "verbs". How many games have you ever played, outside BYOND, which used verbs? So why can't we design games without them?
What most new developers don't realize is that the suite produced by Dantom provides two levels of complexity to develop for. For the novice, there's DUNG, with it's mobs, Bump(), and verbs. If you're new to DM, and new to programming, then you can throw a couple of lines of code together and watch as it changes Dantom's Universal Network Game into something cool and new. And then there's the aptly named BYOND, which allows DM programmers the ability to go beyond DUNG and make whatever game they want.
DM programmer, come BYOND.
Top
