Alathon's site

Wacky ways to mess with DM

Mon, 13 Aug 2012 14:42:54 +0000

Welcome to the proverbial Twilight Zone of DM.

Compiles

Inner classes (Sort of), by DivineTraveller:

data_type
    proc/do_a_thing()
        /cake {
            parent_type=/atom
            var pie=2;
        }

        return new/cake();

Questionmarks ahoy! And a mob that is a list.

mob/proc/Test(?) {
    var/mob/notAMob[3];
    notAMob[1] = 0;
    notAMob[2] = 1;
    notAMob[3] = 0;
    for(. = 1 to notAMob.len) {
        ? = notAMob[.];
        world << "[? ? ? : ?]";
    }
}

Zoidberg!

mob/proc/zoidberg(;;;;;;;;;) {
    var/mob/?[3];
    ?[1] = 0;
    ?[2] = 1;
    ?[3] = 0;
    world << "[?.name] hi";
}

The above actually doesn't crash, it just outputs nothing for ?.name.

Doesn't compile, but throws funny stuff at you

var/mob/bobby/hi[5];
hi[1] = 5;

Gives:
Template.dm:22:error: hi: undefined type: hi
Template.dm:21:warning: hi: variable defined but not used

Without assignment (hi[1] = 5), it compiles. Any reference to the variable, and DM blows up.

var/mob/hi[5];
hi[1] = 5;

Works fine.

Zoidberg returns!

/()

mob/proc/zoidberg(;/()) {
    var/mob/?[3];
    ?[1] = 0;
    ?[2] = 1;
    ?[3] = 0;
    world << "Ready to crash?";
    world << "[?.name] hi";
    world << "[().type]";
    world << "Hm.";
}

Gives:
Template.dm:29:error: bad embedded expression [()]

It seems to compile anyway, and outputs "type]" on the world < "[().type]" line.

Post more quirks, if you can find them / know of any ;)

EA game-bans guy for forum comment

Fri, 11 Mar 2011 10:43:30 +0000

Link to forum thread.

To sum things up: A guy was banned for 3 days for the statement 'So you sold your soul to EA?', based on an auto-ban feature of the forums (Enough people clicking 'Report this post'). This prevents him from registering a store-bought game to his account, meaning he can't play the game.

3 things immediately spring to mind here:

1) Any company that ties forum accounts to verification of games together are just plain stupid. You could avoid situations like this by making sure game authentication is, at the very least, not tied to whether you're allowed to post on the forums. Seriously, who does that?? Hi EA.

2) Blocking a user's access to single-player games they've legally bought, due to almost any concievable occurance, is a no-gain situation for you as a company. So why do it?

3) (Insert long paragraphs about how large game companies are, for the most part, absolute (Insert censored words here))

The game industry as a whole is really taking a wrong turn, and has been for a while. Heres to hoping that the rising popularity and exposure of indie games will help alleviate the pain that is EA/Activision/etc.

Input in the world of telnet

Wed, 09 Feb 2011 15:23:08 +0000

If you're writing a telnet-enabled game on BYOND, you'll probably want to steer away from input(). There are several issues:

1) input() has somewhat of a delay, meaning chained input()'s may get 'missed', causing text to instead be sent to client/Command().

2) input() seems to occasionally cause memory leaks (I can't reproduce this, sadly)

3) input() seems to occasionally cause a 'BUG: TELNET SB malformed' or similar, I don't recall the exact error message.

The benefit to input(), of course, is that it is an easy way to control the flow of the procedure - It'll halt while input() does its thing, and then automatically resume. The same isn't quite possible without input(), not with any sort of sensible API to it.

So I decided to write a replacement system, that works under the assumption that clients can have a 'target' for their commands. If they don't, the regular MUD parser grabs the input the client sent, just like it did before.

If, however, there is a target, it receives the clients input instead. This allowed me to create an Input object, that will wait around and periodically check whether the user has given it input yet. In order to keep the API as simple as possible, it can do a variety of different checks and has a variety of different options to facilitate things.

It supports callbacks (verify input with a function), timing out, verifying repeat input (for passwords, f.ex), restricting valid input to items from a list and more stuff.

The general API to use the Input object looks like this:

var/Input/I = new(player, "Hows about that?!")
var/answer = I.getInput()

The creation of the Input object will block until it has valid input, at which point the second line will run and you will have the input you wanted. Because of this, you're probably always going to want to spawn() before this.

Because there are quite a lot of options, the Input object supports the following syntax:

var/Input/I = new(player, InputSettings object)

This object is a simple object, with procedures to set options individually. As an example of using an InputSettings object:

spawn()
    var/InputSettings/IS = new InputSettings()
    IS.setQuestion("Do you like this new method? (Y/N)")
    IS.setAnswerType(ANSWER_TYPE_LIST)
    IS.setAnswerList(list("y","n"))
    IS.setCaseSensitive(false)

    var/answer = ERROR_INPUT
    while(answer == ERROR_INPUT)
        var/Input/I = new Input(player, IS)
        answer = I.getInput()

Once I'm confident the API is powerful enough to support everything one may reasonably need, and I've tidied up the code, I'll toss it up somewhere where it can be inspected/used.

Right now, my 'form' object uses these to great effect. A form is basically a sequence of questions, that you can exit out of at any time, and go back through if you want to alter an answer. As a complete example of a form that deals with character creation:

            var/form/F = new()

            var/InputSettings/S = new()
            S.setQuestion("\nWhat is your name? (Type #zexit#n to quit)")
            S.setCallback(src, "verify name")
            F.addQuestion("name", S)

            var/InputSettings/S2 = new()
            S2.setQuestion("\nWhat gender would you like to be? \[#zmale#y female#n\] (Hit enter for male)")
            S2.setAnswerList(list("male","female"))
            S2.setAnswerType(ANSWER_TYPE_LIST)
            S2.setDefaultAnswer("male")
            F.addQuestion("gender", S2)

            var/InputSettings/S3 = new()
            S3.setQuestion("\nWhat would you like your password to be?")
            S3.setConfirm("\nPlease confirm by typing password again.")
            S3.setPassword(TRUE)
            S3.setCallback(src, "verify password")
            F.addQuestion("password", S3)

            var/InputSettings/S4 = new()
            S4.setQuestion("\nHit enter to enter the world!")
            F.addQuestion("confirm", S4)

            F.begin(C)
            if(F.isComplete() && C)
                var/char_name = F.getAnswer("name")
                var/char_pass = F.getAnswer("password")
                var/char_gender = F.getAnswer("gender")

Brushing up

Mon, 07 Feb 2011 17:34:08 +0000

So I had the nostalgic urge the other day to start whipping up a MUD. I was looking around on MUDConnector, trying to see if it was still active in some shape, size or form. Much to my not-surprise, almost no one posts on the forums anymore, neither do they post on other would-be websites such as mudfiles.com.

I downloaded a few different sources (vampire wars, masters of hatred and socketmud) and played around a bit with them, and then remembered I had something on here.

After spending a few minutes trying to find the download link (wtb maintained package, please?? Its not as if there is a daily release...), and spending an hour trodding through my own code to figure out how to even log in properly, I finally got it working. I had two conclusions at the end of that session:

1) If you insist on implementing a module system that loads modules so you can segment code into just that, you may want to mention, in documentation, the 'bare minimum' modules. That way you won't spend 35 minutes trying to figure out why nothing comes up until you figure out the config file format and what modules to load; after which you spend 20 minutes more trying to figure out why nothing happens in-game, until you realize that the parser is a module too and should be loaded if you want things, well, parsed.

2) Some of the BYOND bugs related to telnet that originally left the project in the dark back then seem to be gone. (Hit enter to continue) seems to resolve itself for telnet clients, both standard linux telnet and two different MUD clients; ANSI escape-codes no longer seem to count towards the automatic word-wrap (Although it still pains me that one exists).

It still remains to be seen whether characters still idle out by themselves after a time period (Why would you assume someone would want this, with no way to control its behavior?), and whether input() can cause the VM to leak memory.

Fun fun.

BYOND Suggestions

Wed, 26 May 2010 01:42:51 +0000

I stopped by Chatters earlier and someone asked me about the past and future of BYOND and that sort of jazz. I figured I may as well relay my thoughts here instead:

These are suggestions in part as someone looking at BYOND as a community, and in part as someone looking at BYOND as a software platform. As always, the luxury of being on the sidelines is that you don't have to consider the technical implications of implementing features.

Community-related stuff

Merge guilds. All of them. Segregating a diminishing community just kills you faster.
Create a FaceBook app that helps people spread the word about their game.
Get rid of inactive guild leaders, replace them with someone who has the time and inclination to do the work. If one of those goes inactive, find someone new. Stop getting caught in not replacing inactive spots. Someone who is routinely too busy to update something more than once a month, semester or even worse 6 or 12 months is not in a position to lead a guild. If guilds get merged, this is less of an issue
Offer game suggestions based on a balanced amount of each subgenre, internally classified in ways similar to how they are now. This gives genres with a lower number of games more face-time, which helps them. It raises competition in the active areas, which helps spur more development.
Revamp the website. There have been countless suggestions on this, many of which have been viable. The click count is way too high, the color scheme is off, the website needs more fluidity and glitz, etc
Audio/Graphics marketplace where people can share free resources or sell them for cool cash. Take a share of the money there. The idea here isn't to make loads off expensive artists, but to flood the marketplace with free icons and sounds that developers can use as they please.
Stop the stay-at-BYOND incentives. Creating features that cause inbred advertisement hurt you! You want players and developers to go *outside* of BYOND and advertise, not advertise within BYOND. Blogs and way too much hub space are examples of this. You want game developers to put up their own websites, so they will go out and advertise them elsewhere as well.
Consider looking at something like the Steam launcher, that places prominent ads for top-ranking games in the game launcher.
Video advertisement. Get it. Do it.
Contests. Start em. Most creative advertisement banner for a game; best medals for a game; most exotic artwork featured in a game; most creative gameplay feature; most well-reviewed hidden gem(unknown game); etc. etc. - Small prizes. Must be started by BYOND officially or they will not be run with any success. Someone with a key that doesn't represent BYOND (any key other than something starting with 'BYOND', 'Tom' or the 'Lummox Jr' key) will not be able to run these with success.
Stop micromanaging your community too much. The amount of lenience shown to trolls makes moderation useless. Removing ads with scantily-clad girls removes revenue - They generate clicks, they're not worth removing. Ads directly advertising sex or viagra or similar obviously don't fall within that ballpark.
This way of scooping certain individuals out of the public and into closed testing is counterproductive. Its also removed you from posting very much in public forums, compared to what you used to. It simply doesn't work anymore, it barely did back when I started being around there. Plug it, move on, and breathe life back into the public forums.
The 'dont announce it until its done' mantra is bad. Do announce it. Announce it a lot. Ask for lots of feedback. There is a *reason* most websites post up-and-coming changes to the public. Don't post features you haven't decided on implementing, of course - But the public is far more forgiving of delays than silence. And the public WANTS to talk about up and coming features, instead of being whacked in the back of the head with them after they're done.

Technical Features, for Polish or Performance / Other

Key creation API
Custom, small splash screens
Fixed version of link()
Pre-define small loading screen that the splash loader can fetch from hub entry. Overlay a BYOND logo in the bottom right or something.
DLL execution without requiring user authentication
Built-in regex
Built-in text on screen
Ability to overlay primitives in map area
Multiple maps
True, actual full-screen mode
Procedures to query for and more importantly *set* screen resolution as needed
Client-side, compile-time scripts that can interface with the GUI, which trigger on events sent by the server. This allows things like accurate, real-time clocks and other to run fluidly without huge network traffic to update them.

I'm sure there are plenty more technical things, but its late and I don't remember them all. The most important ones deal with resolution/full screen, the key API, primitives and text on screen as well as the client-side stuff.

Re: If your packaged BYOND game is over 2 MB, you suck.

Fri, 07 Aug 2009 10:08:34 +0000

Every once in a while, I browse the Members blogs here to find interesting reads. Sometimes I find hidden gems (nice posts that go unnoticed), and sometimes I find a turd pretending to be a diamond:

The turd in question here is this one, and since I'm banned from SilkWizard's blog, I may as well take up this topic here proper.

However, this isn't about how stupid someone is or isn't. Whats the right thing to be doing, with assets in BYOND?

What sort of file formats should I be using?

For sound: OGG, MIDI, MP3 or properly compressed WAV files depending on the sound in question. Obviously, only compress to the point where there is no audible difference - If you start to experience sound quality loss, then step back up in file size until you don't. Many games use MP3 for longer sounds and compressed WAV for shorter sounds. Bad sound is very noticable, so if theres something you don't want to compress its most likely here.

For graphics: This will vary quite a bit if we're talking outside of BYOND, but in the case of BYOND you should be using PNG's and potentially JPEG files. Obviously, again, only compress to the point where there is no visible difference. This will depend largely on your artistic vision for the game - Palette reduction is better done as an initial choice before assets are drawn, rather than compression.

Is there lossless compression for PNGs?

Short answer: Yes. PNGOut.

Here is a tutorial for PNGOut. The command-line version is free, most of the default options for various values are completely fine.

Short list of the above

1) Compress your PNGs with a lossless compression tool, if possible.
2) Use proper formats for the job at hand (PNG, MP3, OGG, MIDI, compressed WAV)
3) Don't compress or reduce something if it looks worse or sounds worse. Ever.

Now, looking at the Games folder on this computer, here are a few figures:

Barkley Shut Up and Jam Gaiden:
Sound assets: 48.11MB (3MB of Voices, rest MP3s and a few compressed WAV's for sound effects)

Graphical assets: 5.63MB

A note on the graphical assets: Those are only backdrops / backgrounds / tile screens. The characters don't seem to be there, so I'm going to assume they're somewhere I haven't found them or bundled inside the game or something else.

Depths of Peril
Total assets size: 88.1MB

Depths of Peril bundles its assets into zipfiles, and I'm not much into looking inside them all and figuring out how much is sound and how much is graphics.

Galaxy Online
Total assets size: About 90MB

These are all games that have comparable graphics/sound to what BYOND is intended, and all 3 of these games could reliably be re-created in BYOND, with the exception of Galaxy Online, at least if it is to support thousands of simultaneous players as it does.

If you're not developing a game for web play, you don't need to go crazy optimizing a darn thing. People are downloading games regularly that take up in excess of 500-1000MB for smaller games - If your game is 3MB compressed and 6MB uncompressed and the difference in sound/visual quality is noticable, then you shouldn't be compressing at all. You're in such a low ballpark that it doesn't matter. Compress and optimize because its a good habbit to be doing, but not to the point where it has an effect on your intended game vision.

So, taking a look at SilkWizard's 2MB hardcap I really can't do anything except boggle at why you would set such a ridiculously low cap. I agree with Foomer's assessment that doing so only encourages worse-looking, worse-sounding games. If you have other techniques or ideas on how to reduce game size without resorting to reducing the quality of your game, then go ahead and mention them and I'll edit them in. If I'm incorrect somewhere, please point it out =)

Status: Inactive

Sun, 24 May 2009 11:08:50 +0000

Since I joined BYOND back in 2000/2001, I've picked up a wealth of knowledge both from the language and the community. Being a forum moderator taught me patience and respect for differences despite anonymity, amongst other things. As a programmer I grew from a vague understanding of C via text MUDs, to a solid grasp of design principles and object-oriented programming in DM. And as a person I learned to appreciate the small communities that gather online in the presence of games and similar interests; f.ex the people I still talk to now years after I met them online in a game, in Chatters or on the forums.

Nowadays, I don't really find myself with the time or inclination to finish my dream game here, however. As such, and in consideration of the pseudo-responsibilities I've held in the past, I figured I'd give a heads-up to those inclined to care. I suspect I'll still be dropping by Chatters occasionally to insult Haywire or play some CrossFire (or whatever be the fad of the day there), and I'm reachable via MSN.

Have a good one ;)

Life is short: Don't settle

Thu, 07 May 2009 10:27:55 +0000

2 days ago, during some fairly strong wind gusts - an oak tree fell over and smashed into a car driving along the side of the park in question; the driver was killed almost on the spot. Death by falling tree.

Life is too short to settle for not enjoying it, not demanding a slice of happiness just for yourself. And so in light of that (Not the death by tree), I've dropped my internship (which I felt wasn't going anywhere) and will be studying software design at IT University Copenhagen; that, or software engineering at DTU, the Danish Technical University - Come August.

And as I realized thats what I was going to do, I managed to let out a sigh of relief; because settling and barricading yourself in a situation that you know isn't good for you just plain sucks, and drains you of energy that could be used to create, f.ex, the best game in the world!

Most all of this is common sense, and yet so many people (myself included) settle with little or no thought as to the consequence it has on our mind, energy, daily joy and similar - Instead of demanding more for ourselves. Why ? I suppose in my case because I'm so used to not getting what I want that it becomes the daily norm and it starts being okay. Which is terrible, if you think about it - And I have, so I've decided to do away with that notion altogether.

Always always link!

Sun, 19 Apr 2009 09:26:11 +0000

I notice a bunch of blog posts talk about a game, maybe even your own game, but in that post there is not a single link to the game!

I would've checked out the medals for Murder Mansion, but there was no link! Yes, I can go find it in the hub, but I wont - Yet I'd have looked at the game, possibly gotten more interested etc, if there had been a link in the blog post.

I would've downloaded the newest version of Tomb Explorer, maybe even played a game or two, checked out the current standings, etc. - But there was no link to the game in the blog post!

This might make you go, 'Well if you aren't interested enough in the game to go visit the hub, sod you!'; but try not to think like that. This is an attempt to emphasize something: The easier you make it for players to find and get into your game, the more players you'll have. The more times you lure them into viewing your hub entry, the more likely they are to try it out.

So start linking to your games in posts about them, already!

Dilemma about player-created content

Thu, 16 Apr 2009 20:45:16 +0000

My game is based partly on the idea of an evolving world. NPC cities expand, monster colonies roam towards areas they find valuable (due to resources or other) and players can build and expand cities.

This is all fine and dandy, but presents me with somewhat of a problem when it comes to updating and expanding the world. I'm in the process of building a map editor at the moment, and it occured to me that I'm going to run into issues once the game runs live.

The game runs off MySQL, and to support the map editor I'll clone the main database on a weekly basis to a 'test' database, that the map editor can draw from. This means a level editor can make changes as they like, without impacting the game which runs live 24/7 (outside of patch dates). However -- What if Jimmy decides to build a city in an area where a developer is currently editing a map? Or what if a monster colony decides to migrate off a map that a developer is working on, they push their changes live and suddenly it'll warp back to where it was before!

The way I see it, I have 3 choices. Two of which are very hard to implement, one of which I'm going to have a hard time fitting into the game as it is. Lets start with the easy one:

1) All cities become teleporters from a 'world map'. This means players can't influence actual real-estate outside of their own instance, which a developer should never have to edit. The same goes for 'monster colonies', which become 'points of interest' on the world map. This means nothing editable runs the risk of 'intruding' on something else.

2) I try and cook up a system that does the equivelant of an intelligent diff between how the area looked when the developer checked it out, how it looks now in the live version and how it looks for the developer. I'd have to account for a variety of headache-inducing situations here.

3) I scrap the idea of a map editor and move the map editing tools into the game client, allowing the level editors to edit the 'live' world. This means changes can't be pushed periodically, they'll show up right away - Areas can of course be 'closed off', but that might make the game unplayablee.

Because its the only sane option of the above, I am of course mostly considering #1 so far. However, I wonder if someone has an approach I hadn't considered? :/ If the game didn't include a model of frequent changes, this would be a non-issue.