Keeth's site

Cut down on duplicate posts with stickies!

Wed, 25 Jan 2012 13:48:03 +0000

I think it might be worthwhile to compile a list of super common errors new developers (or old developers) often experience when working in DM. I think it's probably apparent that a lot of our users use the same reference material when they're learning, which is why we have so many similar posts on the code problems/developer how-to sections asking about the exact same problems every year for the past who knows how long.

Trying to work with an uninitialized list.

Setting an atom's x/y/z values individually simply not working under a great deal of circumstances.

Saving your mob wholesale and then loading it back up doing things you don't understand (due to how the key value works).

I think it'd probably be most beneficial to simply have a single sticky post that'd act as a repository, and then just have the list of common problems and links to satisfactorily resolved examples of said problems. Preferably the simplest resolutions that explain the entire problem. That way we don't have 1 sticky per common problem.

I don't know how well this would work, since you can't really rely on people's code being the same as other people's, but I think if focus on properly explaining the principles behind what was wrong with the code rather than just posting the proper code, we can at least cut down on the "spam" by a decent margin.

Volfoss Game Music

Sat, 03 Dec 2011 19:22:25 +0000

Volfoss OST Playlist (Incomplete)
I took some liberties with naming, as there are no track names.

This is music from a game called Volfoss, which I recently purchased. So far, a pretty cool turn-based strategy RPG game (like Final Fantasy Tactics), set in a post-apocalyptic world, with alien-seeming monsters and structures abound. The combat and character advancement stuff is pretty cool. It looks like there are a number of mutant-type creatures in the world, and then the main characters. You seem to recruit the mutants, and each of them has a set of abilities unique to them. The Junicorn, for example, can launch his horn to hurt enemies from afar. (Here's a more complete mutant set, with other characters near the bottom.)

ANYWAY...

I personally ripped this, after some trouble finding out how to rip them from the XA files. Eventually I got it though, and I've taken the liberty of uploading a couple of the notable songs from the set. It's pretty unique in that it sports some pretty awesome heavy metal guitar riffs in most every song on the damn thing. The reason I only uploaded the few I did was because most of the songs are pretty similar, and most of them are used for combat situations.

I might upload the rest in RAR/ZIP format to some hosting service later, if anyone is interested. There are some nice songs in there other than the few I uploaded.

I'll also upload the 5 ending movies once I get a chance.

Combat (D): Predictable Combat as a Foundation

Fri, 25 Nov 2011 03:06:56 +0000

We're going to start with a slightly different approach than most of you have probably taken... we're not going to start with any attributes! No weapons! No armor! Flat rates for everything, no modifiers or nuffin'. Creatures will have health, and in combat, they will do a flat amount of damage, at a flat rate of attack.

Before we even decide what we want these numbers to be, I'm going to decide something else. I want combat to last only 10 seconds. So two creatures, completely equal, will kill one another in 10 seconds flat.

So, now that we have that single parameter, let's get some figures to use. If we assume mobs have 100 health, there are only so many formulas we can use to ensure combat ends in 10 seconds. We could do 10 hits/second for 1 damage, 5 hits/second for 2 damage, 1 hit/second for 10 damage, 0.5 hits/second (1 hit every 2 seconds) for 20 damage, and so on. In the interest of simplicity, we're going to use 1 hit per second, 10 damage a hit. Simple, no? I think everyone can follow this.

So now, considering we have designed all of the elements that go into combat, combat should always, always look something like this:

Mob A attacks Mob B for 10 damage.
Mob B attacks Mob A for 10 damage.
...1 second...
Mob A attacks Mob B for 10 damage.
Mob B attacks Mob A for 10 damage.
...1 second...
[repeat 8 more times]
Mob A kills Mob B!

Wallah. We have our basic combat with no attributes. It works perfectly according to plan -- combat ends in 10 seconds (that's my story and I'm sticking to it), and nothing ever happens that we can't really predict.

Some smarty pants might have noticed that this isn't actually 10 seconds. It's 9 seconds. Or maybe more accurately, 9.001~ seconds. Basically, only 9 delays occur (only 9 delays have a chance to occur), but 10 attacks occur. This is because we are attacking at the instant a second begins.

To demonstrate this point, here's a pretty awesome graph:

Basically, the problem is that we are attacking before a second actually passes. Because of this, we are attacking, essentially, twice within a second. If you start counting from 0, we are attacking at the first instant of 0, and the first instant of of 1. The difference between the exact instance 0 ends and the exact instance 1 begins is something you can't really differentiate, so we can call it something like two hits per 1.001~ seconds.

This will even out exactly every time a second ends. It's something that is unavoidable. So for the sake of consistency in this text, we're going to ignore this fact, and say 10 hits with a 1 second delay is 10 seconds. We'll just secretly count out the rest of the second in our heads, so combat never ends at 9.001~ seconds, only 10.

Now let's start adding attributes that tweak the mechanics a bit. Not too much, just a bit. For starters, let's add a strength attribute. One point in our strength attribute accounts for 2 damage for our attacks. Therefore, everyone starts with 5 strength, to make it consistent with our system. On top of that, let's add vitality, which will give us 20 health per point. If you noticed the pattern, that means we're going to start with 5 vitality, to remain consistent with our combat mockup.

So now all mobs start with 5 strength -> 10 damage, and 5 vitality -> 100 health. With our system in play, we can safely say every point of strength decreases combat length by 20%-ish, and that every point of vitality increases the length of combat by 20%-ish. With this system in play, you can pretty much just compare two fighter's attributes, and we know how long a fight will last, and who will win depending on who hits first (sometimes not at all depending on who hits first).

Here are some simulations:

If you want to run a few simulations yourself, it's not too hard. You can grab the snippets from the previous entry, make a little combat loop that makes two mobs attack, based on our rules, with the proper delays. See if you can accurately predict the outcomes.

Combat (P): Modularity Makes Life Easier

Sat, 19 Nov 2011 10:41:05 +0000

Like anything else you're designing, we want to make sure that the combat system conforms to a strict set of rules. I'm starting with this combat system because I seem to find more and more people using the same badly implemented combat system. I don't expect this to reduce that count any, but I like writing, and I like programming, and it's something I haven't done in awhile. So here we go.

Starting out first, the most important thing when designing anything is consistency. What seems to be one of the most common implementations of combat, according to the developer forums, is something gross like this:

mob
    proc
        deathCheck(mob/killer)
            if(health < 1)
                world << "[killer] killed [src]."
                if(client)
                    loc = locate(1,1,1) // etc...
                else
                    del src // lol

    verb
        punch(mob/target in oview(1))
            target.health -= rand(1,100)
            target.deathCheck(src)

There are a couple of problems with this implementation. Mostly, it's redundant. Every time we reduce the enemy's health, we have to manually call deathCheck for them. Not to mention that if in the future you wanted to add something like damage reduction, you end up having to do a lot of extra work on top of what we're already doing. Instead we should sum up all of this stuff in one single function. Since all of them are directly related and there is probably no situation, or very few, where the exact same process isn't going to be repeated for every instance of damage taking, a single function approach will suit us just fine.

mob
    proc
        getHurt(damage, mob/attacker)
            health -= damage
            if(health < 1)
                // death stuff

Now instead of lowing their health and doing a death check every time, we'll just call mob.getHurt() when we want a mob to take damage, and eventually die. Since everything is confined to the one function, changing how we take damage, and how we die, or what defines death, just takes a couple of lines. For example, if we want to add something like "damage resistance," we could just do something like:

mob
    proc
        getHurt(damage, mob/attacker)
            var/damageResistance = getDamageResistance() // some value representing how much damage needs to be mitigated, as a percentage, like 60% (0.6).
            if(damageResistance)
                damage *= 1-damageResistance // reduce the damage by the given percentage. 1 - 0.6 = 0.4, 40% of what we originally had.

            health -= damage
            if(health<1)
                // etc...

Now, in the spirit of modularity (removing as much redundant code, and making things that we want to repeat a lot, maybe in other places in code, into individual functions), we can end up with quite a few nifty functions that, maybe right now we don't have much use for, but later on could be pretty nice to have around.

Edited to include the variables we use, added isDying(), which determines if we should die now (health<1, etc...), and isDead() now checks if we're currently dead (added a death-state for mobs). Also added live() for making creatures "live" again, which is used by respawn().

mob
    var
        health      = 100
        maxHealth   = 100

        // boolean indicating we've died
        dead        = FALSE

    proc
        // take some hurt.
        // optional attacker can be provided, for when someone is killing us.
        getHurt(damage, mob/attacker)
            if(isDead()) // nothing to be done if we're already dead.
                return

            health -= damage

            if(isDying())
                die(attacker)

        // should we die? can we even die? let's check.
        isDying()
            //if(isModerator())
            //  return FALSE
            return (health < 1) // by default, <1 should be impending death for all

        // are we currently dead?
        // this is for games where death does not instantly result in returning to the game.
        // you could have an in-between state where the character is a ghost and has to find
        // their body, or they go to hell or heaven, or something fancy like that.
        isDead()
            return (dead == TRUE)

        // do some dying.
        die(mob/killer)
            dead = TRUE // we're dead now.
            //deathAnnounce(src, killer || null)
            //deathCry()
            if(client)
                //dropCorpse()
                respawn()

            else
                //killer.getKillExperience(src) -- instead of putting the formula here, we can do it over there... another useful trick
                //dropCorpse()
                del src

        // if we have anything special we need to do to make this character
        // become "alive" again, do it here. like losing our halo, restoring our
        // normal icon (maybe we became a ghost?), or anything like that. might also
        // be wise to restore our health here instead of respawn().
        live()
            dead = FALSE
            //restoreHealth()

        // throw us to our graveyard.
        // unlike live(), respawn() is meant to restore us to life
        // and then move us to a proper respawn point.
        respawn()
            live() // we're back alive now. woo.
            //Move(getGraveyard())

Now we have a nifty way of determing if people should die, and a way to instantly kill someone. Now the act of dying is not dependant on the player losing their health; since we've separated the function of dying from simply getting hurt, we can, with absolutely certainty, kill someone with one function call. Ignoring any type of damage mitigation, any type of inability to die (immortals, zombies, whatever). Pretty cool, right? Now you can add like, a slay command that doesn't have to do like... damage(mob, 99999999999999999999999999999999). Which is the most important command in a game, right?

We've also partitioned the act of respawning, which doesn't have much use right now, but it does separate the act of respawning from dying, which will make our code a lot easier to read, where everyone can tell what every line of code is doing based on just the name of the function being called.

Now we have a framework that we can build on. It is consistent with itself, and there is never a time during combat when we are going to be unsure about the status of the combatants. They die when they are supposed to, and we can kill them if we need to. Or move them back to the graveyard with full health. Or whatever.

Modified and Moved

Fri, 05 Aug 2011 17:14:00 +0000

Alright, I've released my text handling library for the second time here. I've gone to great lengths to document it and stuff (haha, cause it was hard).

I've also decided to implement the library a bit differently. Instead of including everything on the global scale, everything is defined on a datum (in this case, called kText). This includes functions and other globally available variables.

To give access to the functionality, I include a variable containing an instance of this datum, with the same name as the library, on the global scale.

This means to access the library's global functionality, you will be calling kText.blah() instead of just blah(), or even k_blah(). I think this makes code a bit less gross to read, and in cases where you will have to access a lot of data from the library, it's not as obscure; KTEXT_BLAH_BLAH, as opposed to kText.BLAH_BLAH. I think this is a bit more comfortable, since people will read it as "we're accessing kText's BLAH_BLAH variable!", as opposed to "we're accessing this big huge obnoxious variable named KTEXT_BLAH_BLAH."

I'll be re-releasing my two other libraries using this same setup, after rewriting them as well (haha).

versioning

Thu, 03 Mar 2011 04:22:45 +0000

Versioning format: 0.0.0.0

The first digit is the major version, which is really just an indication of what I have deemed a big enough change to necessitate a number change. This is generally reserved for a process where I decide which features I want to implement to get it up to version X. For example, for the beginning phase of a project I just started, I have a set of features necessary before I will consider the game version 1. Once all of these have been implemented, the major version will be 1.

The second digit is the minor version, which is an indication of a somewhat major feature implementation, but doesn't necessarily facilitate increasing the major version (which, like I explained above, is reserved for certain things). For example, maybe I decide, after I implement all of the game features in version 1, that the players want a system for writing letters to each other. After implementing the letter writing system, I would increase the minor version by 1.

I am also wondering whether or not I should just consider the revision in which I release the updated features to the public the "next minor version," or if I should increment the minor version once for EVERY feature added. I am thinking I'll do the first one, probably. It might get hectic otherwise.

The third digit is the development stage (I knicked this concept off of wikipedia, sue me). The numbers here go from 0 to 3.

0	alpha	Features being implemented. Closed (usually) testing.
1	beta	Feature complete. Open or closed testing.
2	release candidate	Thoroughly tested for bugs. Further testing to weed out any lingering bugs. On its way to a full release.
3	public release	No more changes to be made to the source. Ready for production.

The fourth digit is the revision number. Basically, this indicates which release number we're at for this version. What constitutes a "release" or "revision" would be any modification to the source, followed by publication.

I'm thinking that this number should reset with every major version update, maybe with every minor version update as well. I have also considered never reseting it. I'm not really sure at this point, so I'll probably just go with what feels right.

version = 0.1.0.1
pretty  = 0.1-a1

true colors (seizure inducing) vs. greyish (underexposed) colors?

Sat, 26 Feb 2011 01:12:18 +0000

Scanned vs. Leveled

My current problem right now is that, I believe the leveled version here represents the true colors of the image (blacks are black, whites are white, and the reds are red), but at the same time, when representing it on a computer screen, the image is unbelievably bright. If you look at the leveled version, your eyes will probably explode due to the image being surrounded by white...

The scanned version is underexposed, I think? The whites and blacks are greyer, the reds are noticeably greyer as well. They definitely do not as accurately represent the actual image.

Being that the intent of this is to show digital copies of the image, I'm wondering if it would be beneficial to meet somewhere in between the two...

EDIT

Back side:
Scanned - Leveled - In Between

EDIT #2

I just realized there are horrible artifacts in these images hosted on tinypic...

wtf tinypic?

Repop() handled via areas?

Mon, 29 Jun 2009 12:44:48 +0000

Would it be possible to break down the Repop() (world) function so it repops AREAS? That is to say, make it so we can Repop() one area (/area) on the map without repopulating every part of the map at once.

I'm using the BYOND maps (obviously), and I'd like to make it so areas repop faster the longer players stay out of them. Right now the only alternative would be to create my own system of resets (I'd have to list all of the mobs and/or objects that respawn at which points, etc...). It'd just make everything a lot easier if we could do this by areas.

Of course it's not necessary, but it would be nice. Not sure how many people would use it, but whatever.

Player count; telnet user count?

Sun, 04 Jan 2009 06:57:07 +0000

Just a small request... would it be possible to make the hub record telnet users as well?
I don't mean report their IP address or anything, but maybe just a little counter like it has for guests.

"X Telnet Users; X Guests; X Players: [list of BYOND keys connected]"

Or maybe just add to the player counter without listing anything.

I'd just like some kind of official counter so people don't see that the game has nobody connected because they're all from telnet.

Assocating someone with a key

Fri, 02 Jan 2009 06:49:33 +0000

I was wondering if it was possible to associate someone OUTSIDE of BYOND with a BYOND key. Like a way to ask them for a key, and a password, and then it'd send it to the BYOND and verify it was correct, and then I could confirm that they're associated with it.

This is so I can award people with BYOND subscriptions.
Of course, it is related to BYOND.