Caged Birds Don’t Sing

One of the very first bits of advice I was given on my BYOND page was a snarky remark based off of a recent advice post which basically said, “If you announce what you’re working on, you’re going to be robbed of the motivation to do it.”

I scoffed at that on the grounds that I couldn’t see that as being all that concrete. However, as of late, motivation flagging, I’m thinking perhaps there’s something to it after all. In taking it seriously, the brain cogs started turning, I decided that it probably has to do with the idea that caged birds shouldn’t sing.

Continue reading

Learning BYOND #11: The Power Of Modular Programming

Though I think of it as being a couple weeks off, this is in mostly counting minor dabbling: the actual amount of time I spent away from hardcore BYOND development is more like a month.  I’ve spent the pretty much the entire weekend (in which I had four days) hammering BYOND, and I think I’ve finally caught up with my lost knowledge.  This, and more.

I’ve picked up and dusted off my old Learning BYOND series for a special installment about the power of modular programming.

Continue reading

Crunch Time: The end of the Learning BYOND series

So ends my ‘Learning BYOND” series (though I’ll probably go back and edit those entries – for brevity, if nothing else). Ten days of “Learning BYOND” is probably enough to say that I’m past learning it, and am now simply using it.

What does use of BYOND produce? If the title is to believed, it allows you to Build Your Own Net Dream. Does BYOND live up to its name? Well, it definitely cuts down the toil of creating an online game tremendously, and I’m very much in debt to Dantom for providing it: it made building my online game accessible. Yet, I’m finding that a game is only as good as you’re willing to put the effort into.

In the end, BYOND is a canvas and brush to wield with whatever skill you’re capable – not a spigot that need only be twist to realize your dream game. (This hardly surprises the realists among us.)

Two weeks after starting, I’m staring down the barrel of a school semester 3 days from now without a completed game to show for it. That’s fine – I can continue using BYOND to further refine my Own Net Dream during the school semester — I’ve only a half-time schedule. I’ve little doubt that I’ll be able to produce something playable within a month soon.

Besides… I’ve always thought it interesting when I read a game credit (such as at the end of Quest for Glory 3) that says, “we hope you had as much fun playing our game as we had making it.” Sure enough, right now, it seems that making games is more fun for me than playing them. Thanks, continuous crappy quality of games leading to burnout. (Or is that a chicken and the egg scenario where burnout makes good games seem crappy?) If nothing else, when I’m building my own game and feel the balance is off, I’m able to fix it myself: that kind of freedom is awesome.

As for details on the particular game I’m making now, I’m hesitant to show my cards early. It’s not that I’m worried people are going to steal my idea — if you could do this and do it better than me, that’d save me a lot of work! It’s just that if I start talking about my game before people play it my words become hype. Hype kills games: I’d rather players judge it for themselves.

In future entries, I might drop a few hints by writing a few pieces of fiction that take place within the game universe. This would handily double as good background material.

Learning BYOND, Day 9: Purposeful Toil

With the focus placed on my Graphical User Interface from Day 8, I’ve pretty much created the game. The GUI is the game, after all. At least that’s what I quoted yesterday… but, I have to concur from personal experience that once you’ve got the basics of the GUI ironed out, the game itself materializes.

My GUI will have three separate play modes. A sensible first-time BYOND Dream Maker user would develop one game, but I’m a fickle gamer, I apparently want my first game to be three games in one. (This is to say nothing for the dynamic content focus.) The specifics (such as balancing the individual pieces) have yet to be worked out, but I now know enough to build the basic skeleton I’ll be using and tweaking to project completion. I wouldn’t have been able to do so without knowing both the BYOND 4.0 skin features and the screen objects discussed in yesterday’s blog entry.

Whether it’s my over-ambition or simply a sign of inexperience, it’s been difficult to get my code synced up right. I’ve tried putting an entire design on paper, but I’m afraid I can’t visualize the underlying mechanics well enough. Instead, I’ve been somewhat forced to build piece by piece, creating individual aspects of the game and seeing how well they stand before moving on to the next.

Perhaps this is the way all newbies start out, but the consequence is having to rebuild or re-arrange my code when previous implementations fail, to the point where it seems I’m no closer to my final product now than I was a few days ago. It’s a bit discouraging, but I shoulder on knowing a few things:

First, learning BYOND coding is an excellent self-improvement mechanism. Second, the code I create will be doing the work for me once it’s done properly (it’ll be a joy once I can stop coding and start world-building). Third, as I get better at using BYOND, the difficulty of putting together more content like this should lessen – design and coding are learned through practice like any other applied skill.

Finally, whether or not my games are ever popular or if I ever get paid for making them, this is essentially the birth of a game designer. Perhaps a game designer whose games only entertain himself, but a game designer nonetheless.

Well, enough slacking on today’s blog entry. Back to the grindstone.

Learning BYOND, Day 8: Is The Game

It’s hot and it’s a Saturday, but I don’t care. I’ve only got another 9 days until the school semester starts. Plus, I’ve developed a relatively good design in my head, now it’s time to see it through. Back to work, slacker.

Today, the Graphical User Interface was on the agenda. A reoccurring theme I picked up many time from “Game Design: Secrets of the Sages” (merely a compilation of developer quotes and pictures, but not without some insights): “The GUI is the game.” The saying means that what the user plays is actually the graphical user interface and therefore literally is the game. No wonder some consider it the hardest part of making a game.

I’ve learned about three powerful elements that I’m looking into right now.

  1. The newly introduced (as of BYOND 4.0) skin creator.

    This is a really nice suite that lets you set up your GUI configuration however you like. It’s a graphical interface creator not unlike one I’ve already been introduced to when using Visual Basic.

    It seems pretty complicated, but a good tutorial on that can be found here: Making skins in BYOND 4.0: A Lesson

    BYOND’s 4.0 GUI customization is both extensive and remarkably user-friendly, but I’ve still got to figure out how the code interfaces with the GUI elements added. It seems as though all you really need to do is manipulate them via their tags using the “winset” procedure. Could it really be so easy?

  2. Menu ItemsI figured this one out on my own. After opening up the same file where the macros and menus, and windows are defined (the .dmf file), go into the “menu” menu. There, it’s quite easy to add additional commands by recognizing the format is the standard column>>command format that’s likely at the top of your browser as you read it. In the “command” section is simply a verb that’s passed to the parser. So, define that “verb” on your client object just like any other verb and the functionality will go through.
  3. Objects assigned to the client.screen list.In a way, the “screen” variable on the client object is similar to the “image” variable (the same I discussed at length at Day 7) in that it is a list of things that are continually displayed to the user on the client level. (Meaning other users won’t see what this user is seeing.)

    However, it differs considerably in that what’s being displayed are interaction-capable, atom-style objects. This is really cool because you can define all sorts of interactive verbs on objects, while images can’t be clicked at all (though I’m sure an imitator could be jury-rigged).

    Assigning fully manipulatable objects to be used is actually remarkably easy. I recommend this simple tutorial on the BYOND developers section. It’s quite basic and does not cover more complicated tricks, such as adding mouse interaction by defining the MouseDrag() and Click() functions on the objects you’re adding to the screen, but if you’ve been using BYOND for awhile those things are self-evident.

The skin editor is undeniably more powerful, but the client.screen object list is still a valuable tool for adding things such as on-map controls. I’ll be learning them both. As for pull-down menus, it’s hard to say what use I’ll get out of that — it doesn’t seem very immersive for a RPG-like game.

After learning these methods, I can pretty much make any point-and-click windows-based interface I can imagine (at least so long as I don’t mind that the core of the game is a 2d tile-based one… and actually, I think I prefer it). However, just because BYOND makes it easy to create and display half-dozen panes at once doesn’t mean I should. My years of game-playing experience tells me that a very simple interface is much easier for the user to handle. Perhaps the difference between a good designer and a bad one is just how much complication you can get across in a user-friendly manner.

Learning BYOND, Day 7: All About Image

Seriously, today really was all about the image for me… the BYOND image object and how it is used, that is. It turned out to be a rather long and agonizing day: I wish I had known now what I did when I started. Sit back, read, and enjoy the butter without the churning I did today.

The image object refers to an image that is not actually part of the game world, but rather is a custom image specifically made to be drawn on the screen of any specifically specified users’ client.  Such objects have many potential applications, such presenting a custom GUI or applying special effects beyond what the world engine is normally capable.

The official instructions on images is quite short. It’s not mentioned at all in the client chapter and (as we’re about to discover) that’s a major omission. The Dream Maker help mechanic and BYOND developer community are the best reference I’m aware of for image objects.

The brevity of the help is probably because image objects are actually pretty easy to use… provided you stick to one image object reference variable at a time: However, I wasn’t content with that: I wanted to do a whole image list at a time. There lay madness.

Finally, I figured out the one thing they don’t flat out tell you (unless you very carefully read the BYOND dream maker help in the “image var (client)” section):

“The key to displaying images is a specially handled client object list. The “client.images” variable is directly called by the hardcode every update to display any and all image objects involved for that client.”

Edit (Sept 8th, 08): Originally, I wrote this Blog entry with an understanding that client.images was very arbitrarily handled for a list.  This is because, in my code dabbling, it exhibited unusual behavior.  Trying to call image.len (to get the length of the image list) did not work, nor did using a “for variable in images” call.

Zac pointed out in the comments that actually you can do this without trouble, leading me to wonder if perhaps I was stumping myself with a simple typo or perhaps trying to call client.images without the proper references from another procedure.

What remains below are the few truths I know to be true and unusual about the client.images list.

  1. Images must be passed to the client.images variable one at a time.

    If I try to use the << operator to pass a list of images to the client, it handles it like a string and spams “/list” to the user’s screen.

    If I try to use the images.Add() operator to pass a list of images, nothing happens.  The image list is not added and there’s no explained reason why, it just doesn’t work.

    Fortunately, it’s not too hard to simply break down any list of images you have an add them one at a time to client images. That was ultimately the solution that ended a day of misery and woe for me.

  2. You cannot delete the client.images object.

    If you try, you get a “bad del” error.  This must be because the client (not the client object but the user’s actual client program) relies too much on the client.images variable to allow it to be cleared and reference to null.

    Instead, what you must do is delete each image from the client.images list manually.  If you want to clear out the whole thing, you can (contrary to my earlier beliefs) perform a simple loop like this:

    for (var/deleteThisImage in images)
    del deleteThisImage

    And it will work.  However, if you want to delete a specific image from that list of images, you need to be able to find it first, and that can be really hard to do if you have no reference variable to that image.  Thus, maintaining reference variables (or even lists of reference variables) is a good idea.

    The requirement to keep a reference to added images strikes me as an unfriendly feature for BYOND designers: Never should there be a point you’ve added something that impacts the user which you can’t take away. Still, I suppose I can appreciate the logic: if the BYOND game designer did their job right, and kept a reference to every image they’ve added, this should never happen in the first place. It may not be as user friendly, but it’s the more powerful implementation, and I can appreciate that.


Progress Check

Speaking of using BYOND Dream Maker, here we are, one week later, and I’m still working out the foundations of my extravagant game world.

That’s okay, I recall I read somewhere that Richard Garriott himself said that’s the best way to go about it: build what you want the engine to do first, then worry about the story/game (I forget which). Richard Garriott (a.k.a. Lord British) practically invented the tile-based engine, the first 8 Ultima games were presented in tile-based engines built from the ground up, so (like em’ or hate em’ for a certain clean slate’s WoW imitation) I think Garriott’s advice can be trusted on this matter!

Besides, I’m not really on day 7. Looking back to day 6, I created the system that handles all the moves done by the game pieces on a one turn per second system yesterday, and that was the closest thing I did to genuine progress. All days before that, I was mostly learning BYOND… am still learning BYOND judging by today’s entry. If I already knew how to program BYOND from the start as well as I do now, I’d probably be polishing a finished prototype by now. Rather than let that discourage me, I should chalk it up to a sign of how much I’ve learned since then.

By Design

While I have been busy learning BYOND lately, that’s no excuse to not have a design document. Design documents need little working knowledge of the BYOND engine or DM code, all the game designer really needs to know is that BYOND is a real-time, tile-based engine with implicit multiplayer support (so you should factor in there will be some network lag between moves that is, fortunately, handled automatically). It’s only after a design document is done that one need take off their designer hat and wear the coder hat. (Granted, each coder hat needs has a code design section, but you need to start knowing what you’re planning on doing.)

At this point in my own BYOND project, it’s clearer than ever that I need a target to shoot for. Because I’m lacking the kind of forethought a design doc exists for, my efforts to develop a game are very unfocused. For example, I created an action queue handler, yes. However, I haven’t thought through what kind of actions need to be handled, and so now I’m encountering a problem of what happens when a creature is interrupted and needs to stop moving and start defending itself.

I’m wearing the wrong hat to move this project forward: I really need to force myself to take a break from coding. As much as I apparently enjoy it given how easy the BYOND engine makes it to produce results, I’m at the point where I don’t know what result I’m trying to produce. It’s time to do some brainstorming and designing.

(Granted, if I was making a simple game, I could eyeball it. A simple overall design document could be easily generated in my head and that would work fine. However, after 25 years of gaming, I’m far from being a simple gamer at heart.)

Learning BYOND, Day 6: Open Heart Surgery

I’m probably going to go back and severely edit those “Learning BYOND” entires. Right now they’re a somewhat rambling collection that probably contain a number of inadvertent lies said out of code-newbie innocence. I’m not sure anyone finds those entries particularly interesting… at the very least, I should throw in some helpful diagrams!

Diagrams like so.

Diagrams like so. Funny enough, knowing how to answer the Pythagorean Theorem is actually quite useful for aspiring BYOND users (although the get_dist() function performs much the same way).


Oh well, this entry will be somewhat more interesting, I hope. Today, I talk about what goes into coding a force that drives a virtual universe.


The heart of my game is the actionqueue procedure. This is activated when the world first boots up and stays running for the duration. Every second, it cycles through a list of designated “alive” mobs and checks the action queue on each. Each mob in the game can only execute one action per turn. In this way, BYOND’s flexible engine has been shaped into a simulated turn-based roleplaying game engine.

Controlling the use of the actionqueue is tricky because (thanks to the sleep() proc within it) it is waiting while other procedures are occurring at the same time. To protect against the conflicts that may occur, the actionqueue only performs the first action in the queue. No other procedure should manipulate that first action. Otherwise, if the timing is just right (or just wrong) then something’s going to break. If something needs to be inserted before that first action, the actionqueue procedure is the one to handle this.

The actionqueue procedure must be very efficient. I’ve tested that my computer can run about 50,000 lines per second. If I have 50 objects and the ActionQueue wants to go through 1000 lines each, it’ll bog down the server. If, on the other hand, each object only processes 10 lines then I can support up to 5000 idling objects. (Give or take — this is a bit of a shot in the dark.) If the server’s lagging, there will be a visible hitch every second when the actionqueue goes through its list.

Sorry Q-Bot, Ive made my own.

Sorry Q-Bot, I've made my own.


How many “living” objects will I need? It’s hard to say. Though my plan is not set in stone, currently I want to do an epic 1000×1000 2d tile-based world. That’s huge – traveling at one second per square, it’ll take about 16 1/2 minutes to cross the length of it. (I’ll probably add quicker means to travel.)

However, on such a large map, will there will always be something fairly meaningful going on with the players will be in the thick of it? This brings us to the central point: a huge world is pointless in game mechanic terms. Where the player is is not half as important as what I give them to do.

With the implementation of the actionqueue, I’ve harnessed BYOND’s flexible event model into a powerful virtual heart that drives my ideal game. In the coming days, I’ll have to design and implement the virtual soul that engages the player. It’s a pretty tall order – hopefully my 25 years of playing games will grant some insight there.