The Sourcerer

Glorified

My High School friend Bob Ennis got in touch with me again recently. Bob and I shared German classes. While I'd love to take credit for this, Bob's antics were likely the primary cause Frau Gunn's loss of sanity. Bob later worked on "The Bunny Movie" project, playing the role of Darth Hare.

So, Bob has gotten into graphic design. Bob offered a free sample of his work, a "glorification". This is the result:

Player Driven Content

Ryan Paul has posted an article for arstechnica.com about player driven content in games. I find it highly relevant to some projects I'm working on. Anybody who faces a decission about how to develop content for their game should read the article.

Meanwhile, the MUD project has taken on a new name. We're still calling the world engine and game service project MAGE, but now it stands for the generic "Multi-user Advanced Game Engine", thanks to Ryan Paul's ingenuity when originally divining the acronym. We're going to call the content project and our particular release of the game "Tale". We, at this time, have the game running at https://cixar.com:2343 and we plan to keep it running throughout the development process.

Tale runs in an autonomous AJAX client (Asynchronous Javascript and XML). AJAX is the label for a paradigm shift in web programming, which amounts to the creative uses of the Javascript XMLHttpRequest. Similarly DHTML described the paradigm of combining HTML, CSS, and Javascript. So, Tale, top to bottom, involves HTML, Javascript, CSS, discrete XMLHttpRequests, XML, SVG, SSL, Python, and possibly Java :-). A veritible alphabet soup.

Ryan's article leaves me wondering to what exetent Tale can harness "player-driven" content. One way to do this is to encourage players to participate in the development process. However, to really harness all the power of player driven content, we really must make the game's content drivable from within. To that end, I think that developers should cultivate some history for the game to ignite the imaginations of the player base, but provide features that put the storyline in the hands of the players. By this I mean that the players should have intimate control over the shape of the world. Players should create bastions to protect their hoard, which will naturally provide other players the challenge to defeat them. The challenge for us is writing algorithms of gameplay that make the struggle of the game always a fine edge between success and failure for all parties involved.

Licensing Swil

I finished my term paper [pdf] for Professional Responsibilities (ethics in software development, Cal Poly CSC 300). Here's the abstract:

Software developers have a gamut of options for software licensing. These options range from propriety to permissiveness, including many open source options. This article introduces the attributes and categories of common licenses and presents their strengths and weaknesses. There follows an analysis of how each license attribute and licensing model would serve the author, the public, and authors of derivative works. In particu- lar, this article addresses the licensing needs of a programming language called Swil. The article concludes that a dual licensing scheme including a commercial license and a viral free software license would provide the best compromise for all parties.

Leithian

I've posted my term project for Music Theory I (Cal Poly MU 104). This is a short, four-part choir piece in chorale style to demonstrate that I've learned something about counter-point this quarter (meaning, I can produce random, Bach-formula 1 chorales). The lyrics come from "The Lay of Leithian", an epic poem by J.R.R. Tolkien. Fingolfin, an elf lord, bangs on the gate of Hell and summons Morgoth (Satan) to engage in single combat.

So, here is a MIDI file, and a TIF image of the manuscript.

• leithian.mid
• leithian.tif

Will Google Return My Calls - Part 3

Well, summarily, they did.

I applied for a Full Time Cluster System Administrator position. I've had three phone interviews now.

The first phone interview was conversational. The second required coding Perl off the cuff, and reciting the code over the phone, which was fun but tricky. I messed up twice and had to proceed from a hint to get it right. The third phone call... well, I don't think I did too well. The interviewer asked a bunch of networking questions that I didn't know answers to, and I bungled around on a large scale sorting algorithm problem.

Well, summarily, I hope they call again.