Jtgibson's DM Page

A pie chart

Mon, 24 Nov 2008 14:38:34 GMT

http://www.graphjam.com/

A random thought on online life simulation games

Wed, 15 Oct 2008 11:34:52 GMT

After thinking about life simulation games online (e.g., Wurm Online), I realised that one of the fundamental problems with online RPGs in general is that a player has no sense of what exactly s/he's getting into before jumping into the game. Players who join MORPGs typically have a character concept in mind based on what they've picked up from the website or what looks the coolest in the character creation system. However, if the game tends towards life simulation instead of adventure/fantasy (e.g., Hedgerow Hall), it is possible that the character that a player chose can prove uncompetitive at best or totally unviable at worst.

This got me to thinking: what if a player could join the game and explore the game world as a sort of "tourist" in order to check things out? As a tourist, the character would be unable to attack anyone and would have nothing of value, but could still be attacked (esp. by monsters). The goal is two-fold:

1) Playing as a tourist allows the player to survey the existing establishments in the game and see what industries are lacking. Casual conversations with the game's residents would also serve to let the player know what's in demand and what isn't.

2) The player gets a "wolfing tutorial" of sorts which puts him into real danger and warns him/her to stick to the safer areas. As the player ventures around and explores, s/he'll inevitably discover the areas that are most dangerous (the hard way) and will thus be able to measure the most settled areas versus the frontier areas.

The ultimate goal after learning these two pieces of information is to be able to design a character that would be more able to conduct a profitable business for a service that is in demand in the game.

Everyone in Hedgerow Hall wanted to be a smith, and because of this the smith occupation was balanced towards being more difficult (so the better smiths would turn a profit) when in essence the real problem was the overabundance of smith characters (too much supply, not enough demand).

If characters could go into a game in advance and see what exactly they might be able to play as, the play experience could be that much more fun.

Still another peek into the inner workings of my mind

Mon, 28 Jul 2008 09:22:38 GMT

    Omnicant //Spiders
        //Wordplay on "Omniscient" -- omni- for all (Spiders have lots of limbs),
        // cant for language.  Spiders are the know-it-alls of Newtopia.

The description is worse:

"The ability to speak and understand Omnicant, the language of the Spiders. Under cogitation Omnicant is perceived by nearly every sapient biological entity on Newtopia to epitomise as a unilateral archetype the eminently most-utterly complex and obfuscated linguistic communications instrument at one's dispensation."

Simple server-side Wiki

Wed, 18 Jun 2008 08:31:47 GMT

I'm presently engaged in the task of trying to find a self-contained Wiki which:

1) uses MediaWiki syntax, which is infinitely better than C2Wiki, Wikidot, or most other Wiki syntaxes,
2) requires almost no installation; resides in a single self-editing file or resides in a pair of files (a script and a database), and
3) resides server-side, meaning that users wouldn't ordinarily be able to edit the Wiki.

I'm so used to documenting in MediaWiki format now that just about everything I write is in MediaWiki syntax. It bothers me because to display it to an end user, I have to: 1) parse the file manually and convert it to HTML, or 2) create a whole Wiki, which is silly when I'm writing just one page for a project.

If all else fails, I wonder if there's a simple parser which takes a file with MediaWiki markup and spits out a static .htm corresponding to it (e.g., <h2> for every ==, <hr/> for every -----, <b> for every ''', etc.).

I'm almost tempted to get back into finishing my DM-format MediaWiki parser. I previously abandoned the parser as "possible but unfeasible", which doesn't bode well for my motivation.

Why hello Mr. Scope, how shall I exceed you today?

Fri, 13 Jun 2008 13:35:16 GMT

Last night, I was browsing around ThinkGeek for all of the gadgets, and I started transcribing one or two down something like this:

Photographic Eyewear:
        A "pair of glasses" which can take a picture of what is currently being
        seen by the user when triggered, using a small camera embedded in the
        bridge.  No internal memory, must be connected to an external permanent
        memory by wire lead or a wireless network.

        Parts:
        
        (Frame)
        + Micro Photo Camera
        / Trigger Mechanism
                | Audio/Verbal Trigger
                | Button Trigger
                | Expression Trigger
                | Neural Trigger
                | Wire Input
                | Wireless Receiver
        / Output Link
                | Wire Output
                | Wireless Transmitter
        / Power Source
                | Electrical Input
                | Micro Power Cell
        * Eyeglass Lenses
        
        The lenses are optional; they can be any make of eyeglass lens, such as
        those curing myopia or hyperopia or those obscuring harmful ultraviolet
        radiation, or may simply be left out to allow the device to act as a
        portable and convenient camera only.
        
        As with optional parts in any other item, lenses are not included by
        default.  A purchaser of photographic eyewear should contact an
        ophthamologist for manufacturing a proper set of lenses.
        
        The device has no processor and thus cannot be used as smartglasses.
        
        Specific behaviour is as follows:
        
        ==Audio/Verbal trigger==
        
                Device takes and transmits a photo whenever it hears a certain
                noise.  Most users program it to the sound of a code word or a
                simple physical noise like a cluck or a snap of the fingers.

        ==Button Trigger==
        
                Device takes and transmits a photo whenever a small button on
                the frame is pressed.  This allows silent photo-taking, but
                requires a free hand.

        ==Neural Trigger==
        
                Device takes and transmits a photo whenever the user
                concentrates on the activity.  This is silent and does not
                require hands free, but requires practice and can result in
                missed photographs or accidental photographs.

        ==Expression Trigger==
        
                Device takes and transmits a photo whenever the user makes a
                certain expression for a certain amount of time.  The device
                uses small lasers to detect the contortions of the face.
                Typical gesture is a three-second wink, as if scrutinising an
                object.

        ==Wireless Trigger==
        
                Device takes and transmits a photo whenever the device receives
                a certain signal.  Continuous receipt of the signal will cause
                the device to repeatedly take photographs after a short delay
                each time.
        
        ==Wire Trigger==
        
                Device takes and transmits a photo whenever the device receives
                a pulse along an electronic circuit.  Continuous flow of the
                circuit will cause the device to repeatedly take photographs
                after a short delay each time.
                
                Usually the wire trigger is fed by a handheld button or switch.

I looked at it and looked at it and looked at it and thought, "Wow, that's actually a really good documentation format."

Then I got stupid:

/*
Name of the item or part:
        If a line includes no leading formatting, it is descriptive only.
                   Leading whitespace is ignored, but it is recommended to
                        make the format human-readable.
        
        If a description line ends in a period, the next line is considered
        part of the same paragraph and is led with a double-space.
        I always thought it was lazy how W3C recommends trimming everything
        to a single-space when it is improper grammar and improper typography
        to do so.
        
        A list of parts is handled with a certain syntax by using a special
        markup.  Whitespace leading up to the symbol and after the symbol is
        ignored.

        (Integral part, for display/repair purposes only)
        #Not interchangeable with other parts
        + Part that must be included for item to work (included by default)
        * Part that may optionally be included (not included by default)
        / Sub-inventory and is not an actual part itself
                | One of the possible parts that must be selected from
                | Second possible part that must be selected from
                | ...
                | Last possible part that must be selected from
                //Sub-Subinventory
                        || One of the possible parts in the sub-subinventory
                        || ...
                        || Last possible part in the sub-subinventory
                //Second sub-subinventory
                        ++ Mandatory part in the sub-subinventory
                        ** Optional part in the sub-subinventory
        * Another optional part at normal depth
        
        #It is not mandatory to list parts in a single block -- they should be
        # compiled from the whole item -- but it is strongly recommended to
        # ensure ease of readability.

        Each part in the item is created when the item is parsed, unless a
        part by that name already exists.  Parts of the same name are thus
        interchangeable between all items that use them.

        Parts cannot be installed or uninstalled while the item is being used
        or worn.  The item must be removed from the body and handled at a work
        bench (usually in a Machine Shop).

        All descriptions are compiled
        into a single string.  Two or
        more line breaks are considered
        syntax, but line breaks are not
        and are considered part of the
        same paragraph.
        
        #Lines prefixed with a pound are comments and are ignored.
        
        Items are normally handheld.  If they can be worn, they use a certain
        syntax to indicate all of the locations they may be worn in.  Each
        line of the syntax indicates one possible wear position, and each
        location in the syntax indicates the body parts that are covered by
        the object.
        
        #This example would say "Wear on Face" as a possible action for the
        # object, handled by the game engine.

        #Syntax:
        #Opening brace
        #Name displayed to player, followed by a colon
        #One or more of:
        # One of 'covers', 'layers', 'touches', followed by a hyphen, followed
        #  by a comma-separated list of location names.
        # A semi-colon is necessary unless the next symbol is a closing brace
        #Closing brace
        
        #Internal whitespace and linebreaks are ignored, but the first line
        # ignoring leading whitespace must start with a brace.
        
        #Example:       
        {Face: covers - human eyes; touches - human nose, human left ear,
        human right ear}
        
        #covers - list of locations that the object is worn on top of
        # (cannot have anything else over top)
        
        #layers - list of locations that the object is worn on top of
        # (but can still have something else over top)
        
        #touches - list of locations that the object rests against
        # (but cannot be equipped there if something is covering them or if
        #  too many layers are used)
        
        Special features are built-in symbols that determine what the object
        can do.  Special features are part of the game engine, and the parsing
        of each special feature line should also be handled by the game engine
        to determine what special properties the object should have.
        
        %Powersource
        %ElectricalAttachment(powersource, poweroutput)
        
        Scripts are the meat and potatoes of the item and are used to handle
        how the object behaves.

        
        ~Script label
        #Script labels can be called from the script as functions, or called by
        # the engine if they use certain hard-coded names.
        :line of script
        :line of script
        :line of script

        #A line beginning with a $ is a "verb" of this item that the player can
        # activate.
        $action
        :line of script
        :line of script
        #Lines prefixed with pound in the script are comments.
        #Lines of script must always be prefixed with colons.

        #Whitespace in a script is ignored.
        :#Lines prefixed with both a colon and a pound are also comments.

        #This is still considered part of the user-action, regardless of
        # intervening whitespace or comments!
        :lval = rval
        :condition {
        :       line of script
        :       line of script
        :       condition { #Inline comment
        :               nested line of script
        :               nested line of script
        :               #Infinite nesting should be fine.
        :       }

        Disabling an item in this file is done by surrounding the item with
        multiline Slash-Star and Star-Slash C-style comments.  Do not be
        tempted to use the C++-style Slash-Slash comments, as this indicates
        a sub-subdirectory.
*/

A self-documenting object definition language.

Estimated time to release: 14 years (assuming no setbacks)

Less yellow, more mellow

Mon, 26 May 2008 19:16:11 GMT

On a whim, I went ahead and adjusted the CSS of the site a little, mainly because the brown-ink that looks so good on my parchment background looks so terrible on the default blue forum background. I still need to tweak the contrast of the boxes that make up the Blogwatch and the Favourites, since those are way too dark for my tastes.

Another DM feature that I didn't know about

Sun, 27 Apr 2008 12:38:41 GMT

It is possible to make simple initializations when you want variables to have values other than the default for the particular type you are creating.

Example:

mob/contents = newlist(
   /obj/scroll/readme {
      name = "Introduction"
      desc = "The fate of Bracolia depends on you ..."
   }
)

This is the most common use of "modified types", but it is not specific to the newlist instruction. Anywhere a type value may be used in DM, it may be followed by a list of initializations. The general syntax for a modified types is:

path {var1 = val1; var2 = val2}

The semicolon is necessary if you put several variable assignments on the same line. The braces are necessary, even though they are generally optional in DM (since the compiler looks at your indentation). The reason is that the path + initializations must be parsed as a single expression, which is a different context from the usual use of braces in DM when you are defining a true type. Also, indentation inside of an argument list is always ignored anyway.

http://www.byond.com/docs/ref/info.html#/proc/newlist

I knew about the newlist proc, but had no idea it could be used to make modified instances, nor did I have any idea that the same syntax can be used elsewhere in DM!

Go forth and multiply!

An important reminder

Tue, 11 Mar 2008 12:43:50 GMT

Just 288 shopping days until Christmas!

[edit]Since this is long gone from the front page, I'll include the blurb right here too:

"The dangers of being bait-and-switched on the internet are very real; Jtgibson bars no holds in this tell-all exposé."

jt_options

Fri, 29 Feb 2008 19:50:25 GMT

From this:

option/Test_Checkbox
    desc = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vivamus \
                vulputate libero nec ante. Cras tristique suscipit ipsum. Class aptent \
                taciti sociosqu ad litora torquent per conubia nostra, per inceptos \
                hymenaeos. Morbi dignissim purus sed turpis. Suspendisse rhoncus eros id \
                erat venenatis dignissim."

option/Test_Radio
    desc = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla \
                lacus mauris, lobortis et, pellentesque a, lacinia vel, justo. Proin \
                feugiat. Maecenas odio lorem, condimentum nec, euismod vitae, cursus \
                in, nisl. Sed consectetuer vehicula nunc. Etiam eget dolor. Morbi a dui."

    input_type = OPTION_RADIO

    choices = list("Option 1", "Option 2", "Option 3")
    choice_descs = list(
        "Lorem ipsum dolor sit amet, consectetuer adipiscing elit",
        "Lorem ipsum dolor sit amet, consectetuer adipiscing elit",
        "Lorem ipsum dolor sit amet, consectetuer adipiscing elit")

option/Test_Slider
    desc = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed sit \
                amet enim quis velit dictum rhoncus. Donec dictum risus nec turpis. \
                Donec tempus, urna a feugiat congue, risus dolor semper leo, iaculis \
                facilisis purus lorem in felis. Maecenas pellentesque."

    input_type = OPTION_SLIDER

    min_bound = "Low"
    middle_bound = "Mid"
    max_bound = "High"

To this:

More forthcoming!

Language is a scalpel, not a bludgeon

Thu, 07 Feb 2008 14:46:00 GMT

The use of "coder" and "codes" and "iconer" and various other brain-dead language has to stop. Use real words, dagnabbit. =P