I got ncurses working, and managed to get a simple little walk around demo going. However I wanted something a bit deeper than just having the entire map visible from the start, so I poked back at some test code Harkins wrote last year for Ruby (when I had aspirations of learning another language), and read up on Rogue Basin for various examples. In the end I stole Harkin's map, and went with the pseudo code Elig created here.

Without further ado, the code busted apart into a few sections. (Full version can be found here).

 
;;Scheme ray casting/FOV demo
;;Adapted from pseudo code found at
;;http://roguebasin.roguelikedevelopment.org/index.php?title=Eligloscode
 
;;Prep work for 7DLR 2010 (to brush back up on my Scheme)
 
;;Global defines
(define char-x 1) ;;x coordinate for the fake character
(define char-y 1) ;;y coordinate for the fake character
(define VIEW-RADIUS 3) ;;View radius for FOV demo
 
;;List of tiles we don't want to walk through (Walls and water)
(define IMPASSABLE-TILES (list #\# #\~))
;;List of tiles that will break the ray casting (walls)
(define OPAQUE-TILES (list #\#)) 
 
(define test-env (list
                    "###################"
                    "#...#.............#"
                    "#...#...#~~~~~....#"
                    "#.......#~~~~~....#"
                    "###################"))
 

First I set up some variables to work with.

 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;Functions to create the environment;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;Function to create our working environment given an array of strings such as test-env
(define create-env
    (lambda (env)
        (if (null? env)
            '()
            (cons (create-env-row (string->list (car env))) (create-env (cdr env))))))
 
;;Function that helps create-env by creating a given row
(define create-env-row
    (lambda (env-row)
        (if (null? env-row)
            '()
            (cons (create-env-cell (car env-row)) (create-env-row (cdr env-row))))))
 
;;Function to create a given env cell, helps create-env-row
(define create-env-cell
    (lambda (env-cell)
        (list env-cell #f)))
 

Next I define some functions to get a map (which is really a list of strings) to something we can work with (nested lists that act like a two dimensional array).

 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;Functions to display the environment;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;Function to write the env
(define write-env
    (lambda (env)
        (write-env-help env 0 0)))
 
;;Function that does the brunt of the env write
(define write-env-help
    (lambda (env x y)
        (if (null? env)
            (newline)
            (begin
                (write-env-row (car env) x y)
                (write-env-help (cdr env) x (+ y 1))))))
 
;;Function that writes a given row of the env
(define write-env-row
    (lambda (env-row x y)
        (if (null? env-row)
            (newline)
            (begin
                (write-env-cell (car env-row) x y)
                (write-env-row (cdr env-row) (+ x 1) y)))))
 
;;Function that writes out a given cell of the env
(define write-env-cell
    (lambda (env-cell x y)
        (let ((char (car env-cell)) ;;The symbol we'll possibly display
              ;;The boolean bit of the env cell that holds if its visible or not
              (visible (cadr env-cell)))
            (if visible ;;If this cell was marked to be seen
                (if (and (= x char-x) (= y char-y)) ;;Check if its where the character is
                    (print "@") ;;If so, lets show an @ symbol
                    (print char)) ;;Else show whatever character should be displayed
                (print " ")) ;;If this cell wasn't marked to be shown, just put a space
            (print " ")))) ;;Put a space after it for pretty printing
 

Naturally you need some way to nicely see what's going on in your environment. That's what these functions do.

 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;Functions for the FOV demo;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;Function to update the FOV as a whole
(define update-fov
    (lambda (env char-x char-y)
        (update-fov-help env char-x char-y 0 0)))
 
;;Function that does the actual work of updating the FOV
(define update-fov-help
    (lambda (env char-x char-y x y)
        (if (not (null? env))
            (begin
                (update-fov-row (car env) char-x char-y x y)
                (update-fov-help (cdr env) char-x char-y x (+ y 1))))))
 
;;Function that updates the FOV for a given row
(define update-fov-row
    (lambda (env-row char-x char-y x y)
        (if (not (null? env-row))
            (begin
                (update-fov-cell (car env-row) char-x char-y x y)
                (update-fov-row (cdr env-row) char-x char-y (+ x 1) y)))))
 
;;Function that does the real work to update a given cell's FOV
(define update-fov-cell
    (lambda (env-cell char-x char-y x y)
        (set-cell-visible env-cell #f) ;;Set visible to false
        (let* ((dx (- x char-x))
               (dy (- y char-y))
               ;;Get the distance between the character and the cell
               (distance (sqrt (+ (* dx dx) (* dy dy)))))
            (if (< distance VIEW-RADIUS) ;;If we're within out viewing radius
                (set-cell-visible env-cell #t))))) ;;set the cell to be shown
 

Finally we get to the good stuff. This code is for the Field of View demo, which just shows everything within the sight radius. What it does, basically, is loops through every cell on the map, sets it to invisible (aka sets the cdr of the env-cell to be #f), and then checks to see how far from the player it is. If its within our view-radius, it then flips the visibility to true. Slow for big maps, but simple to implement.

 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;Function for the Ray casting demo;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;Function to clear the entire env
(define clear-cells
    (lambda (env)
        (if (not (null? env))
            (begin
                (clear-cells-row (car env))
                (clear-cells (cdr env))))))
 
;;Function that clears a row of the env
(define clear-cells-row
    (lambda (env-row)
        (if (not (null? env-row))
            (begin
                (clear-cells-cell (car env-row))
                (clear-cells-row (cdr env-row))))))
 
;;Function to clear a cell in the env
(define clear-cells-cell
    (lambda (env-cell)
        (set-cell-visible env-cell #f)))
 
;;Function to do the ray-cast
(define cast-rays
    (lambda (env char-x char-y)
        (clear-cells env) ;;Clear everything first
        (cast-rays-help env char-x char-y 0)))
 
;;Function to do the real work of casting some rays
(define cast-rays-help
    (lambda (env char-x char-y i)
        (if (<= i 360)
            (let ((x (cos (* i 0.01745)))
                  (y (sin (* i 0.01745))))
                  (trace-ray env char-x char-y x y (+ char-x .0) (+ char-y .0) 0)
                  (cast-rays-help env char-x char-y (+ i 16))))))
 
;;Function to trace the specific ray to its end
(define trace-ray
    (lambda (env char-x char-y x y dx dy i)
        (if (not (> i VIEW-RADIUS))
            (let* ((cell-x (round dx))
                   (cell-y (round dy))
                   (cell (get-cell env cell-x cell-y)))
                (if cell
                    (begin
                        (set-cell-visible cell #t)
                        (if (cell-opaque? cell)
                            (trace-ray env char-x char-y x y (+ dx x) (+ dy y) (+ i 1)))))))))
 

The first three functions simply clear all the cells on the map. Unlike FOV our work functions aren't visiting every cell (we hope) and so we have to go through ahead of time and clear them out.

The rest of the functions do the ray casting. Starting at the character's position, it draws a line (trace-ray) out in a given direction. If it gets either past the view radius, or to a cell considered opaque, it doesn't recur. Otherwise it calls itself and continues stepping out. Trace-ray is called once per every 16 degrees around the circle. Its not entirely accurate, but its a lot faster than using 1 as the increment and drawing 360 rays.

 
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;Random helper functions;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;Function to get a given cell
(define get-cell
    (lambda (env x y)
        (get-cell-help env x y 0)))
 
;;Function does most of the real work to get a given cell
(define get-cell-help
    (lambda (env new-x new-y y)
        (if (not (null? env))
            (if (= y new-y)
                (get-cell-x (car env) new-x new-y 0)
                (get-cell-help (cdr env) new-x new-y (+ y 1)))
            #f)))
 
;;Final helper to get a given cell
(define get-cell-x
    (lambda (env-row new-x new-y x)
        (if (not (null? env-row))
            (if (= x new-x)
                (car env-row)
                (get-cell-x (cdr env-row) new-x new-y (+ x 1)))
            #f)))
 
;;Function to tell if a cell is passable
(define cell-passable?
    (lambda (cell)
         ;;Check to see if symbol is in our list of impassable tiles
        (not (member (car cell) IMPASSABLE-TILES)))) 
 
;;Function to tell if a cell is opaque
(define cell-opaque?
    (lambda (cell)
        ;;Check to see if symbol is in our list of opaque tiles
        (not (member (car cell) OPAQUE-TILES)))) 
 
;;Function to 'move' our 'character' to another cell
(define move-to
    (lambda (env x y)
        (if (cell-passable? (get-cell env x y)) ;;Check to make sure they can move there
            (begin
                (set! char-x x) ;;'Move' them by changing our global vars
                (set! char-y y)))))
 
;;Function to set a given cell's visibility to the given boolean
(define set-cell-visible
    (lambda (cell bool)
        (set-cdr! cell (list bool))))
 

These functions simply help the above code look prettier. The first make the environment which is really just a list (in true Scheme form) behave more like a two dimensional array. Cell-passable? and opaque? check to see if a cell can be traveled into or seen through. Move-to moves the character, and set-cell-visible helps quickly toggle a cell's visibility.

 
;;;;;;;;;;;;;
;;Test code;;
;;;;;;;;;;;;;
 
;;Setup the environment
(define our-env (create-env test-env))
 
;;Run the fov-demo
(define fov-demo
    (lambda (env)
        (print "FOV demo, use h, j, k, and l to move, q to quit\n")
        (update-fov our-env char-x char-y)
        (write-env our-env)
        (let read-loop ((x (read-char)))
            (if (not (or (char=? x #\q) (char=? x #\newline)))
                (begin
                    (case x
                        [(#\l) (let ((new-x (+ char-x 1))
                                     (new-y char-y))
                                    (move-to our-env new-x new-y))]
                        [(#\k) (let ((new-x char-x)
                                     (new-y (- char-y 1)))
                                    (move-to our-env new-x new-y))]
                        [(#\j) (let ((new-x char-x)
                                     (new-y (+ char-y 1)))
                                    (move-to our-env new-x new-y))]
                        [(#\h) (let ((new-x (- char-x 1))
                                     (new-y char-y))
                                    (move-to our-env new-x new-y))])
                    (update-fov our-env char-x char-y)
                    (write-env our-env)
                    (read-loop (read-char)))
                (case x
                    [(#\q) (print "--End of FOV Demo--\n")]
                    [(#\newline) (read-loop (read-char))])))))
 
;;Run the ray-casting-demo
(define ray-casting-demo
    (lambda (env)
        (print "Ray casting demo, use h, j, k, and l to move, q to quit\n")
        (cast-rays our-env char-x char-y)
        (write-env our-env)
        (let read-loop ((x (read-char)))
            (if (not (or (char=? x #\q) (char=? x #\newline)))
                (begin
                    (case x
                        [(#\l) (let ((new-x (+ char-x 1))
                                     (new-y char-y))
                                    (move-to our-env new-x new-y))]
                        [(#\k) (let ((new-x char-x)
                                     (new-y (- char-y 1)))
                                    (move-to our-env new-x new-y))]
                        [(#\j) (let ((new-x char-x)
                                     (new-y (+ char-y 1)))
                                    (move-to our-env new-x new-y))]
                        [(#\h) (let ((new-x (- char-x 1))
                                     (new-y char-y))
                                    (move-to our-env new-x new-y))])
                    (cast-rays our-env char-x char-y)
                    (write-env our-env)
                    (read-loop (read-char)))
                (case x ;;Enter or q was pressed
                    [(#\q) (print "--End of Ray casting demo--\n")] ;;If q, lets quit
                    ;;If enter just read the next char, it happens
                    [(#\newline) (read-loop (read-char))]))))) 
 
;;Run our demos
(fov-demo our-env)
(ray-casting-demo our-env)
 

And finally the test code. Both of these loops behave the same, they use typical roguelike controls to move up (k), down (j), left (h), and right (l), as well as (q) to quit. You'll notice I also had to catch enter or read-char would spit out the map twice. At the end we call both of these functions so we can show off both types, back to back.

So there you have it, simple ray casting done in Scheme. I'll note that its not exceptionally fast, in fact for my test map the FOV demo was far quicker, but by degrading the accuracy and reducing the number of rays drawn the speed gets back up to something decent. I suspect that may also have to do with drawing it all out to the terminal, and will see what happens when I plug this into my ncurses code at a later point.

Hope that's commented well enough in the code. Enjoy!

Some friends were discussing the upcoming 7 Day Roguelike contest and I thought it'd be a fun thing to do after completing a browser based game in a month contest just a week back. However, I wanted to use something besides something besides the PHP I've been using for so very long, and somehow in the same IRC channel Scheme came up.

Scheme is a LISP language that I learned back in college and very quickly grew a nice love/hate relationship. I love seeing the beauty of recursion expressed so easily, and I just hate to see so many parenthesis all over the place. Seriously they make your eyes bleed. But the idea hit me that it'd be fun to try to do the roguelike in Scheme, and I decided to enter. I most likely won't finish, and I'm not too happy with the idea I have, but it'll be fun nonetheless.

Flavors

To that end, I've been playing in Scheme for the past week to familiarize myself with a language I haven't touched in a few years and which has had some nice advances since that time. First job was getting it installed on Ubuntu. I'd recommend playing with various flavors and seeing what you like best. I tried Mit-Scheme, Chez Scheme, PLT Scheme (Dr Scheme), Tiny Scheme, and Gambit. These can all be installed under Linux (fairly) easily, and all have upsides and downsides.

• MIT Scheme - I had used this a tad during school, but sadly they're not supporting R6RS, and don't have a full implementation of R5RS, so its essentially useless.
• Chez Scheme - What my school used primarily. Has a copy of the Scheme Programming Language Version 4 free on their site which is a big plus. They support all three major OS's and include an RPM/instructions for Debian installation.
• PLT Scheme - The other product we used at school, it comes as a Scheme IDE with the ability to select from a variety of language subsets. The Ubuntu 9.04 package isn't up to date, but the package available on their site includes R6RS, so grab their install script and forgo synaptic. Big plus of being a fully featured IDE.
• Tinyscheme - From the command line I actually liked this flavor the best. Sadly its a subset of the R5RS standard so it won't do everything you need, but for small proof-of-concept or test code, its nice and fast. I know it'd defeat the purpose, but I wish there was an R6RS version.
• Gambit Scheme - This is a flavor I only came across this past week, had no prior experience with it. I love it. Again the version in the 9.04 Ubuntu repos is a bit old, so grab the newest version (4.6 as of now) here. If you just want to use Gambit as an interpreter/REPL you're good to go. If you want to use it to spit out C code as well, you may need to make sure your gambit.h file is in the right location.

Gambit

Yes, I said spit out C, as Gambit-C compiles your Scheme nicely into C files that gcc will then happily compile for you along with real C to use both languages. This is going to play greatly into my 7DRL as I wanted to use the NCurses library to handle my screen output and to I can easily include that now. An example of Hello World in Gambit Scheme with NCurses:

 
;;Hello World example for Gambit/NCurses
 
;;Include our headers
(c-declare "#include <ncurses.h>")
 
;;Define the function
(define hello-world
    ;;C lambda performs c commands, this is a basic ncurses
    ;;example that inits the screen, prints our string, waits
    ;;for input so it stays on the screen, and then kills the window
    (c-lambda () int "initscr(); printw(\"Hello World\"); refresh(); getch(); endwin();" ))
 
;;Gotta remember to call it!
(hello-world)
 

Now link, compile, and run it:

snarky@Reaper$ gsc -link ncurses.scm
snarky@Reaper$ gcc ncurses_.c ncurses.c -lgambc -lncurses -o ncurses
snarky@Reaper$ ./ncurses
Hello World

(Of course, the above output is slightly tweaked as I'm opting not to take a screenshot of a terminal empty save for one string)

It should be noted that once you start including C in your scheme you can no longer use the Gambit Scheme Interpreter to test your code, so I'd recommend breaking those bits out into other files if possible.

There are some other great additions within the Gambit system, such as the ability to have optional arguments in your functions, keyed variables passed to functions, and some random extensions like vector-copy, as well as, obviously, in-lining C in your Scheme. I highly recommend checking our their manual if you're at all interested.

Gotchas

I did get bit by a few things in Gambit, that I feel I should clarify. Even after reading through the manual, I missed that the compiler is spitting out linked files, not actual executables. To make sure you're getting an executable out of it make sure you do something akin to:

snarky@Reaper$ gsc -link file.scm
snarky@Reaper$ gcc file_.c file.c -lgambc

I very quickly just made a make file to handle it to simply forget about what steps go into it.

The big thing that bit me, however, was when I got out of the nice usual functions and into some higher syntax, specifically define-syntax. Gambit has a bunch of functionality turned off by default and requires that you turn it all on to use it. However I didn't feel like the documentation beat that into my head enough, so here's what you have to do:

For the interpreter:

snarky@Reaper$ gsi -:s

And for the compiler:

snarky@Reaper$ gsc -:s -link file.scm

OR

snarky@Reaper$ gsc -link -e '(load "/usr/local/Gambit-C/lib/syntax-case.scm")' file.scm

The top example turns a whole bunch of syntactic sugar on, while the bottom I believe just turns on some of the syntax. I could be wrong there.

I'm quite looking forward to playing with Gambit more and getting to know Scheme as I used to. Hopefully someone else can find a new sadistic language out of this post.

First off, if you want a project done, you can't be getting distracted. Since I've started Thieves Tavern I've also fallen in love with motorcycles and started gun smithing. Both of those have stolen major programming time away from this project. Its only through the weather being downright cold lately, and parts for the gun being on back order that I've had the time to get gung ho on this project again.

Secondly, when dealing with databases, its really easy to tailor the database so that the game works. In fact, that's the whole point of editing the database: To test this bit, or that bit... but not the overall product. Earlier this week I'd reached a point where I thought I could push my code live, and invite some friends to beta test it. I figured, at the time that clearing out my database would make stuff work better, get rid of all the random edge cases I'd built up along the way. Well, after clearing out the database, nothing worked. I couldn't start games, I couldn't chat, nada. This is when I learned that it doesn't get easier after removing test data, only harder. It took another two days of testing, clearing, testing some more, as well as cleaning up my code, before I got it back to the 'working' beta state. Thankfully, now I know its working as intended (minus the obvious beta bugs, of course).

So now its off to beta test Thieves Tavern. I'm kind of excited to be playing this, I had loads of fun while playing myself in local tests, and I can imagine it being even better taking out friends online. If you'd like to help test, get ahold of me (in real life, I'll ask for signups for a public beta later on) and I'll send you an invite.

(And in the 10 minutes it took to write this I already have a laundry list of fixes/stuff I just plumb forgot)

Test.

Test 2...

Big Test

Now we're testing an edit, and adding in a link to the plugin's home.

I just picked up a motorcycle about two months back since one thing I love to do while stuck on some code is drive. Naturally I figured that riding would be an even better escape. It turns out it is, but I'm concentrating too much on the riding to be able to head-code. The upside is, this is probably the most fun activity I've ever found. So, meet Kari:

I realized on Sunday that I've put 1000 miles on her in the month and the week since I got my license, not too shabby considering I probably spent on the low side of $100 of gas for that entire time! Since she's an older bike, I'm doing as much of the maintenance as I can, so that I'll only need a mechanic for major operations. More on that later.

I also (very, very recently) decided to get into Gun smithing. To that end, I'm going to be making an AR-15 over the next month(s), and keeping track of my progress here.

So, what do the two new activities have in common? Both of them stem at least partially from an interest to be reliant upon only myself for work. This comes from the programming I do, where I have chided others for not thinking outside of the box, and really doing anything they want with the code. It finally dawned on me that that goes in all walks of life, and you can even approach it in the same way.

Lets take the Gun smithing, for example. I'm approaching this from a design perspective first. I laid out what I want to use the gun for, then set my constraints (money), and planned out the parts. This is exactly the same method I take for programming: First I'll plan out how I want it to look/act, figure out what corners I have to cut to keep it within my memory/CPU/bandwidth bounds, then start with the functions.

In this case I decided I want something for (eventually) match target shooting, for medium ranges (100-600 yards). My constraints were that I wanted to build it all myself, short of fabricating the parts, and that i didn't want to spend more than $700 on the total cost. So far I've decided on the following:

• DPMS Lower Receiver, stripped (already purchased)
• DPMS Lower Receiver parts (already purchased)
• Advanced Technology 6-position collapsible stock
• Ergonomic pistol grip
• 20" chrome lined barrel (not sure of manufacturer yet)
• Flat top upper receiver with rails
• Generic bolt/bolt carrier, stripped

It should be a really fun project, I look forward to learning a new machine and how it all works. This will also mean that from now on my firearms will be like my computers, completely unique, and I'll have an intimate working knowledge of each and every part.

So why now? Why am I trying to learn all this new stuff once I get out of college, and not while I was in it? The answer here stems from some conversations I've had about why I enjoy firearms, and thoughts I've had after them. The short answer is: "I'd rather learn how to shoot now, when I don't need to, than later when I need to, but don't know how." I don't think carrying rifles in public is necessary, though I am a vocal defender of the 2nd amendment, however I do think it is very short-sighted to assume you'll never need to use a firearm, and therefor write them off. Didn't you learn how to change a tire, even though you may never need to, perform CPR in gym class, or how to balance an equation in science (or for the scientist, write in plain English, or not blow up the world)? Sure, all of those will be needed a whole lot more than shooting, but other than CPR shooting might be the most important to know if any of those situations came up.

Now, I considered myself set once I learned safety, and how to aim properly. But lately I've been thinking that its really short-sighted of me to assume the rifle will work perfectly all the time. More importantly, I don't know when its not working at 100%, because I don't understand it all. Just like the sorority girls whose computers I'd clean up at the end of the school year, I might not realize all the junk that is building up inside my gun. So, I've decided that I need to know at least basic gun smithing, just in case. Knowing this will keep me, and those around me when I shoot, a whole lot safer in the long run, plus save me money!

The motorcycle is the same story. I have no idea what's going on, and if you read up on an inline-4 engine, there's really no excuse for that. So again, I'm teaching myself basic mechanics in order to keep my machines running as smoothly and safely as possible.

And if you think about it, these skills of checking the usual fail points, oiling the squeaky parts, and throwing your own custom parts in, are the same across many fields, not just mechanics, gun smithing, and programming. So get out there, and get yourself head first into a new field today!

So what I'm creating is a PHP/AJAX based version of the game, where players can create games of (so far) between 5 and 8 players. Upon creating the game, a random set of roles (random in terms of which roleset, NOT in terms of a hodge podge of random roles that could be very unfair) is doled out, and it goes immediately into the night phase. Each phase will last 24 hours, if everyone does their actions sooner, it'll end, but if you don't ready yourself before the time is up you'll forfeit your action. Game ends based on the roleset... typically once there's only town, or bad guys left, but in terms of Silent Killers it gets more interesting, but will be checked for after every kill, and after every lynching. Chat will allow for anyone to read it, and once the game is over all messages become public.

Unfortunately work has slowed down a bit since buying my motorcycle a week ago, but I'm still hoping to have a closed beta up in a short(ish) amount of time. I actually could put one up already, but am hoping to have a much higher degree of a product before the beta than I usually do.

The site will go live at Thieves Tavern, a site I got a long time ago for a gaming clan that is appropriately named, I think. Once it goes up, I'll put out a call for about 10-16 closed beta players, and then probably a week later another open invitation for open beta players. once it seems both stable, and a good recreation of the game, based on the opinion of all players, it'll become a public game.

You can follow the development either through Twitter, or in the #thievestavern room on irc.freenode.net, thanks to GitHub.

DRCSL
DRCSL is a php library written using PHP 5 and PHP objects. At its core it is currently just one file, Character.php, that upon its creation fetches the character XML from NCSoft's servers, and stores all the data. Once the data is stored, the Character can spit out its information with just a few commands. What's required to use this library is a web server with PHP 5 on it, along with wget to fetch the XML. A default Linux PHP install works just fine, though if your host blocks exec() callouts you're out of luck. I'm on my first release, so the paths are hard coded for Linux delimiters which will be fixed in the future (of course, the Windows host will still need wget installed).

An example:


<?php
//Include this file to have it include everything ya need.
include "drcsl.php";
//Create a new Character
$billy = new Character("Segfault");
//Store the character's name
$name = $billy->get_char_info("Name");
//Store the character's title
$title = $billy->get_char_info("Title");
//Display some info
echo "$name is a $title\\n";
?>


This would print something to the effect of:
"Segfault is a Coordinated Practiced Poison Ranger"

MediaWiki Extension
The MWE became real easy after I created the DRCSL. Rather than include a ton of the code from my Character Viewer into the Extension, now all I had to do was include drcsl.php and come up with a default view. It looks something like this, by the way. In all it took about an hour from the time I woke up this morning and decided to finally create one to having a test version out for TheTownstons to test.

To use the MWE one just creates a page and includes the drcsl function.

{{ #drcsl: Segfault }}


Further Reading
More details on both of these projects can be found at the DRCSL website. I was going to write more but there's something bugging in my Code Highlighter plugin (hence why the code looks like non-highlighted junk) and I'm fighting the urge to go fix it.