BYOND Whitepaper
BYOND is a software suite for developing and playing PC games. The software simplifies and streamlines game development:
- BYOND streamlines game development by eliminating the need for boilerplate code. BYOND handles details so you don't have to. You don't have to load maps or images from disk or attach keyboard event listeners to a window. It's all done for you.
- BYOND simplifies game development by providing tools specifically designed for editing all aspects of your game - code, graphics, maps, and interfaces.
The BYOND software, as you'll see, does a lot of the heavy lifting for you. This lets you get right into the meat of game development. You don't have to deal with a graphics engine. You don't have to write any boilerplate code. BYOND takes care of the details for you. Oh, you want your game to be multiplayer? It takes care of that too.
Client-Server Model
When you develop a BYOND game you're actually developing the server. BYOND comes with a customizable game client that works for all games. The client software has the ability to run a BYOND game itself so that anyone can host a game that anyone else can connect to.
You can make a multiplayer game without any additional effort over making a singleplayer game. You don't need to write any networking code and, more importantly, you don't need to debug any networking code :-)
Everything is managed by the server. This is good and bad:
Good: You don't need to develop a game client. BYOND's generic game client (called Dream Seeker) works for all BYOND games.
Good: You don't have to worry about race conditions because everything is handled in a single, central place.
Good: You don't have to worry about synchronizing data across clients. This is completely taken care of for you. If a line of code modifies an object's icon, every client that can see that object will automatically be sent an update. If you aren't familiar with sockets or just don't like them, that's fine — With BYOND you will write absolutely zero networking code.
Bad: Input can be unresponsive because clients can't do much for themselves. For a player to move, their client has to send a message to the server and wait for the server to process the command and send back a position update.
This is a tradeoff, but there's just no way to streamline game development so much without making this trade. The goal is to provide a way to get people right into game development. This isn't realistic if you have to develop your own client-server pair and communication protocol.
Game Development Tools
BYOND's development program is called Dream Maker. It contains a code editor, icon editor, map editor, and interface editor. BYOND has its own formats for these resources, which sounds like a bad thing, but consider the benefits:
- The BYOND software handles loading of resources. Because you use file formats that are known to BYOND, you'll never have to write code that loads maps or images from file. It's all done for you!
- Aside from audio files, you can edit every aspect of your game with the Dream Maker program.
- It's easy to share your work or advice with other BYOND users because everyone is using the same tools.
All graphics are called "icons" and are stored in .dmi files. A single .dmi file is a single icon, but each icon can contain many states. Each state can be animated or multi-directional (1, 4, or 8 directions are natively supported). The .dmi file format is actually the same as the PNG format.
BYOND's map editor lets you place objects in 2D, tile-based maps. With a small amount of code you can define an object, assign it an icon, and the map editor will automatically be aware of it and let you place the object on the map.
Click here for more information about BYOND's game development tools.
The code, icons, maps, and interfaces get compiled into two files: an BYOND executable file (with a .dmb extension) and a resource file (with a .rsc extension). The .dmb file contains the data needed to run the game - either locally or to host a server for others to join. The .rsc file contains what a client needs to join a server. For players to run a game offline they'll need both files.
What You Get for Free
The BYOND software is freely available to download and use with no licensing costs, but that's not the kind of "free" I'm talking about...
The BYOND software does a lot for you. Without writing any code there's a lot of stuff you get for free. BYOND provides you with:
- A 2D tile-based world. You don't have to define a 2D array of "tile" objects and load the map file from disk.
- A game client that can render the graphical display and accept user input.
- Native multiplayer support.
- Basic default input and movement behavior for a 2D tile-based game.
Suppose you write 10 lines of code to define some object types and assign icons to them, place arrange instances of those objects to create a map, and run the game - what happens? Because BYOND provides all games with default input and movement behavior you can walk around the map you made. Let's look at that list again from the other perspective - here's what you don't have to do:
- Write code to load the map into a 2D array.
- Write code to draw the grid of icons to form the graphical output.
- Write code to listen for keyboard input.
- Write code to prevent players from walking through walls.
- Write code to accept client socket connections.
- Write code to accept commands from remote clients.
- Write code to send updates to clients as each player moves.
- Write code to prevent players from walking through each other.
That's a lot of code that you don't have to write! Presumably your passion is game development, not keyboard event listener development or client-server communication protocol development. BYOND takes care of those details so you can get right to the point of game development.
The DM Programming Language
BYOND games are made using a proprietary programming language called DM. Don't worry, there's a good chance you've used at least 3 of the 8 languages it bears a resemblance to :-)
DM is an object-oriented language where inheritance is widely used and indentation really matters. Here's how you'd define three object types: "cat" which is a child of "animal", and "tiger" is a child of "cat":
animal cat tiger
By being mindful of the indentation you can easily define some variables (called "vars") and member functions (called "procs") and override them:
animal var legs cat // set the default value for all objects of type /animal/cat legs = 4 // define a proc for all cats proc meow() tiger // override the meow() proc meow() world << "ROAR!"
The language is dynamically and loosely typed. It's similar to JavaScript in that sense that a var can point to a number, a string, or an object. However, you can specify a type for vars to get some compile-time checking. For example:
// define some stuff var/x = 3 var/player = usr var/mob/m = usr // output some stuff world << player.x // "player" has no type so we get a compile-time error world << m.x // "m" is of type /mob, and mobs have an x variable
If you look at a few examples of DM code you'll get the hang of it.
Default Behavior & Built-in Content
As I mentioned before, BYOND gives your game default behavior. This behavior makes use of predefined objects and is exposed to you through built-in procs. This way you can extend or override all aspects of this behavior.
All mappable objects are derived from the type /atom. There are four basic types of derived objects:
- area: A region that spans many tiles. The contents of an area object is a list of turfs.
- turf: A single tile on the map. The contents of a turf is the list of objs and mobs on that tile.
- obj: An object. The contents of an obj are objs or mobs (ex: the parent obj is a treasure chest and the contents are the treasure).
- mob: A mobile object. Similar to obj, but has some extra built-in vars because clients can be connected to mobs.
Cute sidenote: the first letters of the names area, turf, obj, and mob spell "atom".
There's a base object type, /atom, which these objects extend. Areas are really of the type /atom/area, turfs are /atom/turf. Objs and mobs are really /atom/movable/obj and /atom/movable/mob.
You can override built-in procs to modify the default behavior that BYOND gives you. For example, a turf's Enter() proc is called to check if an object can enter it. When a player tries to move to that turf, if its Enter() proc returns zero, the move isn't allowed. You can override the proc to extend or replace the default behavior. For example:
turf Enter(mob/m) // ghosts can walk through anything if(m.ghost) return 1 // calling ..() runs the default behavior return ..()
BYOND also has a lot of built-in procs that aren't used by the default behavior but are handy for game development. for example:
mob proc explode() view(8, src) << "[src] explodes!" for(var/mob/m in oview(5, src)) step_away(m, src)
Things worth noting here:
- The << operator is used for outputting text.
- Square brackets are used to embed a value in a string. (you'll wish every language had this!)
- The src var refers to the object instance you're in the context of (like this in Java).
- The view() proc is a built-in proc that returns a list of atoms within a certain distance of the specified atom. In this case, within 8 tiles of the exploding mob.
- The oview() proc is similar except it excludes the atom you specified as the center.
- For loops can use the for(var in list) format.
- The step_away() proc is a built-in proc that makes a mob take one step away from another object.
The DM language is very easy to pick up. The catch is that to use it effectively you need to be familiar with its built-in vars and procs.