Geek-o-Philiac

US Cellular POSTer

2006-12-09T15:52:00.000-05:00

Sometime over the past two weeks one of my coworkers sent me a text message via US Cellular's text message sender. After thinking about it, I wanted to write a program that could do the same thing. Now, I know I could simply write an email client to send to a US Cellular email address, but where's the fun in that?
So, I began my journey. My first suspicion (and hope) was that the US Cellular page used HTTP POST to transmit its information. I fired up Ethereal (now called WireShark) and began sniffing packets. Sure enough, there was a POST to usc.ztango.com:
POST /uscwmss HTTP/1.1

Host: usc.ztango.com

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Accept: text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://usc.ztango.com/uscwmss

Content-Type: application/x-www-form-urlencoded

Content-Length: 148

sesId=10F6896FF1DE72C40A
&MSG=From%3A+**********%0D%0AHey+buddy.
&ADDRESSES=**********
&FROMADDRESS=**********
&MSG_TMP=Hey+buddy.&count=122
&tc_agree=on
HTTP/1.1 302 Moved Temporarily

(NOTE: I added linebreaks to the above body for clarity. In actuality the parameters are al in one line.)

Really what we're interested in is the body of the POST message, which I'll copy and paste to make things clearer:

sesId=10F6896FF1DE72C40A
&MSG=From%3A+**********%0D%0AHey+buddy.
&ADDRESSES=**********
&FROMADDRESS=**********
&MSG_TMP=Hey+buddy.
&count=122
&tc_agree=on

(

NOTE

: I have erased the phone number in the request for confidentiality reasons. This number can be any 10-digit US Cellular number)

Looking at the text, we can break out the parameters of the request:

sesId
MSG
ADDRESSES
FROMADDRESS
MSG_TMP
count
tc_agree

I can't claim to know what all this means, but here's what I've been able to decipher:

sesId - A session id generated by US Cellular to determine delivery status of the message. If you send a message from the US Cellular page, a resultant page will display showing the delivery status of the message. This is more of a guess than anything. For the purposes of this program I'm just going to keep using the sesId I grabbed from the sniffed packet.

MSG - Ahh, the interesting part. This is the actual message to be transmitted. Tthere's some code on the page to automatically prepend the message with the string "From:**********" This is one of the things I didn't like about the page, and we'll just leave it out of our messages entirely.

ADDRESSES: The US Cellular number to send this message to. Note the parameter name is ADDRESSES, plural. I'm assuming there's a way to send the message to multiple phone numbers, but I've never tried it.

FROMADDRESS: For all intents and purposes this field is worthless. It is used in the page code to generate the "From: **********" header on the message. When you receive a message from the US Cellular gateway, however, it always has the same default from number (0001114444). Again, this is a bit of guesswork on my part. We'll continue to include this parameter simply because I've never checked to see if its absolutely necessary (I guess US Cellular may check to ensure this is a valid phone number).

MSG_TEMP: Again, I believe this is another worthless parameter. My theory is that this parameter is passed along to the results page after the message is sent to display the message to the user. We'll continue to send this field along as well, for posterity's sake.

count: This is the number of free characters left in the message, with a maximum of 132. Basically, this parameter should be 132 - (number of characters in your message). Again, I think this is for the results webpage that gets displayed after the message is sent (and therefore probably not necessary).

tc_agree: This is the Terms and Conditions checkbox flag. If you don't check it, then you can't send a message. Again, we'll keep this always set as true.

Really, that's it. Its relatively simple. So now all that needs done is to write a client that can send HTTP POST messages to a given address with specified content. I wrote my first client in .NET with C#. .NET provides a class to do HTTP POST messages, so I literally wrote like 15 lines of code to get it to work. This was with everything hard-coded, but the proof-of-concept was there.
So, about a week later I decided to re-write the client in Cocoa for OSX, and add a GUI. If you've never written for OSX before, GUIs are drop-dead-easy (just like .NET with Visual Studio). So creating a window with a button, two fields and a text-box took maybe two minutes. The gotcha, however, is that OSX provides no HTTP POST message classes. There's a generic HTTP class, but no specific way to do POST. Therefore, you need to fill out the headers and create the message yourself.
I'm really lazy, so the idea didn't appeal to me. I Googled around for something that would do POST for me, and it didn't take long before I had a winner. Fritz Anderson (author of Step into XCode, and contributor to MacTech) had a sample article covering this exact issue. So, after reading that article and the prior as well, I heinously stole Fritz's FAWebPostQuery class to use in the client.
The rest is history. I have a desktop client I can use to send messages to any US Cellular customer. I don't have to pay 10 cents per message, nor use the keypad to punch in numbers. I've toyed with the idea of integrating with Address Book, but I don't know if this project has sparked my interest enough to warrant the added energy. At any rate, it was a fun little app to write (especially since I didn't have to do any of the POST wrangling).

72HGDC: Day 2

2006-11-19T19:53:00.000-05:00

Things are going pretty well, which I think is illustrated by the next two screenshots.

You see that nifty radial shine effect going on? I don't want to brag, but I think more technology expertise went into that then anything anyone has ever entered into the competition.

Also, I've managed to finish two stellar songs:
Song 1: Lilac Devotion
Song 2: Rogue Veterinarian

I think you'll like what you hear.

72HGDC: Day 1

2006-11-18T14:57:00.000-05:00

Things got off to a rough start this time around.

I think I solved the problems, though.

One of them, anyway.

Ah, that's better.

Looks like it'll just be me now. Before that little... incident, though, I managed to salvage this.

Lookin' good.

Months Later

2006-11-03T01:01:00.000-05:00

I am a filthy liar. No more than a handful of days after I announced - with great resolve - a rigid update schedule, I stopped updating completely for well over a month.

You see, I've been really depressed ever since the Titanic sank. It left a mark on me that has changed all my relationships and how I live my life. To think that an unsinkable ship would fold to a slow-moving, single block of ice completely devestated my world view. I haven't been able to eat or sleep since then. It's like I'm a completely different person.

I'm trying to push through it, though. I'm running another 72 Hour Game Dev Competition on November 17th. I'm coming up with film ideas. I'm getting the Guitar Hero guitar to work properly on the PC, paving the way for an editable clone. I'm being displeased with the recent "additions" to the XNA framework. I'm doing a lot of the same old stuff.

In the interests of not providing a contentless update, I will talk about why I'm disliking XNA as its development unfolds. It's not that the system is bad (I'm still pretty happy with it overall), but I expected more significant improvements with the introduction of Beta 2. It just looks like they reorganized some stuff and renamed a few methods; there were no real additions. I've had a wishlist of things I would like to see implemented - cleaner input handling mechanisms and a vastly different sound system, to name two - and I'm not too confident I'll ever see those ideas materialize. I feel like I'm going to have to spend a lot of time arguing with some of the systems, much in the same way that I had to battle early versions of Allegro to get an image on the screen.

I'm curious to see how the content pipeline plays out. I've only seen preliminary information, but cleaning up resources seems to be a pain with it. I really hope I'm not yet seeing the bigger picture here and that things will be more seemless than they seem, because I really want to believe this will be a good addition.

Process Management: Basic Implementation

2006-09-27T13:47:00.000-04:00

Here's some psuedo-code for an abstract class Process which all other processes inherit from.


abstract class Process inherits GameEventSubscriber
{
    //Keep a list of all this Process's children
    private List mChildren;

    //Determines whether the Process is alive or not
    private bool mIsAlive;

    //Called automatically when the Process starts.  This
    //is where initialization for the Process should begin.
    //This is in contrast to putting the initialization in
    //the constructor, since we want to wait until the Process
    //is actually running before starting up some of its
    //functionality.
    //All Processes should call the base Process's Start
    //to provide some necessary functionality.
    public virtual void Start()
    {
        mIsAlive = true;
        post event (process started)
    }

    //Called automatically when the Process stops.
    //This allows you to free up resources or perform
    //certain functionality immediately when the Process
    //stops running as opposed to waiting until the
    //Process is destroyed.
    //This method does not stop all of the children
    //of this Process, which may be a possible
    //improvement.
    //All Process's should call the base's Stop to
    //provide some necessary functionality.
    public virtual void Stop()
    {
        mIsAlive = false;
        post event (process stopped)
    }

    //Handles events sent to the Process.
    public abstract void OnEvent(GameEvent e);

    //Marks the Process as dead.  This is how a Process
    //signifies that it's finished with its functionality and can
    //be stopped.  However, it won't be stopped immediately.
    //Would stopping it immediately be better?
    //I'm not sure. ^_^
    public void Kill()
    {
       mIsAlive = false;
    }

    //Returns whether the Process has been marked
    //as dead or not.
    public bool IsAlive()
    {
        return mIsAlive;
    }

    //Adds a child of this Process, automatically calling
    //the child's Start method.
    public void AddChild(Process child)
    {
        mChildren.Add(child);
        child.Start();
    }

    //Removes all the children of this Process,
    //stopping them appropriately.  Any children
    //of the removed children will also be stopped at this
    //point.
    public void RemoveAllChildren()
    {
        for each child in mChildren
            child.RemoveAllChildren();
            child.Stop();
            mChildren.Remove(child);
    }

    //Removes all the dead children of this Process.
    //This function will search through all children,
    //grandchildren, etc, looking for dead Processes
    //to remove.  Thus, it is only necessary to call
    //this method for the top-level Process for
    //all the dead Processes to be removed properly.
    //When a Process is removed in this manner,
    //all of its children will be stopped appropriately.
    //Ideally, this should be called at least once per
    //frame to ensure that Processes do not linger
    //around.
    public void RemoveDeadChildren()
    {
        for each child in mChildren
            if (not child.IsAlive())
                child.RemoveAllChildren();
                child.Stop();
                mChildren.Remove(child);
            else
                child.RemoveDeadChildren();
    }
}

There - that's everything. It resembles C# to some extent, but I assure you that the code won't compile as it stands. I won't claim that it's bullet-proof or even the most ideal implementation, but it's been treating me pretty well. I included possible improvements within the comments.

Now to create a Process which actually does something, we inherit from this base Process and override the necessary methods. So here's an example of a Process I've written which simply waits until a certain amount of time has passed.


class ProcessWait inherits from Process
{
    private long mTime;
    private long mTimeStart;
 
    ProcessWait(long time)
    {
        mTime = time;
    }

    public override void Start()
    {
        base.Start();

        //Get the time this Process started.
        mTimeStart = GetTickCount();

        //Tell the global GameEventService that this process
        //will listen for game events of type GameEventFrame,
        //which is an event that is fired each frame.  Obviously,
        //how you do this depends on your event-passing scheme.
       GameEventService.Subscribe(this, GameEventFrame);
    }

    public override void Stop()
    {
        //Unregister this Process so that it no longer receives
        //events while it is stopped.
        GameEventService.Unsubscribe(this, GameEventFrame);
    }

    public override void OnEvent(GameEvent e)
    {
        //Each frame, do something
        if (e is GameEventFrame)
        {
            //Check if mTime amount of time has passed since the
            //Process started, and if so, the Process is finished. Thus,
            //we go ahead and Kill it.
            if (GetTickCount() - mTimeStart >= mTime)
            {
                Kill();
            }
        }
    }
}

Simple, yea? You can make a bunch of little Processes just like that one which perform small pieces of functionality, and then those pieces can be combined to form bigger Processes that perform much larger tasks until, eventually, you can run the entire game through a series of well put-together Processes.

I've bombarded you with enough code for now. Next time I get on this topic, I'll talk about the top-level Process and how we actually put these Processes together. You'll be surprised at its elegance.

Engine Architecture

2006-09-25T11:23:00.000-04:00

The big picture of major game engine design has always been somewhat elusive to me. I previously explained how I view it as an operating system, but that analogy of course is not always appropriate. Entity management, complex environments, and collision/physics all serve to make the problem unique.

Yesterday, I realized I was trying to abstract far too many things away, which ultimately gave me inadequate control over my system or spawned technical 'solutions' that were less than stellar. One of my biggest problems was that of managing my scene with all its various entities moving around and GUI elements.

Initially, I tried to have one generic SceneManager which kept a list of Drawable objects and would handle drawing them accordingly in a very naive fashion. I would keep a separate World or Level object to control the various entity interactions. This tightly coupled two subsystems to the Drawables and did not provide me with much flexibility over how they should be drawn. Lately, I've been seeing that I need to merge the two - I need one master Scene object which would handle both entity interactions and drawing the entities. Having a much fuller knowledge of the entities, it can provide certain optimizations and give greater flexibility. Of course, it doesn't come without cost - it's a lot less generic and becomes a lot less reusable, which is why I'm still very hesitant about switching.

Another implication of this is that I have to split my GUI and Scene information. Again, before, I could just shove everything into the SceneManager including GUI widgets, since it was responsible for drawing and nothing else. But this requires special, non-general information in the Drawable class to differentiate between those objects which must move with the scene and those that must not. An ugly hack, basically - one which I didn't need when I was using OpenGL because I could rely on the matrix stack to handle these problems, but now that I'm using XNA's 2D functionality, it becomes essential.

I still haven't settled on the merge of SceneManager and World. It seems cleaner in some respects but less robust in others. I think I'm just going to have to play with both methods more until I settle on one.

Process Management

2006-09-22T22:57:00.000-04:00

When developing my games, I find it convenient to perceive a game much like an operating system. Both have many things in common - they both have a centralized kernel (or core), they have strict performance requirements which must be met in real-time, they must manage myriad resources, and they both have a series of loosely coupled processes to perform various tasks.

In operating systems, process management has been very thoroughly researched. Resource allocation, scheduling, concurrency, intercommunication - all of these things have been studied to for years.

In video game development, process management is not so well understood. If you talk to ten different people about how to manage the state of a game, you will get ten different management strategies. And I've never been presented with one I liked. Until I looked at operating systems.

I prefer to handle my game states with a process tree. That is, I have a series of processes that each have some small, indivisible task to perform. Each process can have any number of children and each one has its own resources. A process has full control over its children - it can add, kill, or manipulate them at leisure, but a process can not manipulate its ancestors or siblings. Most importantly, each process can receive and handle system events however necessary.

Part of what differentiates this system from an operating system process is that these processes can only respond to events - they are not always running concurrently in the background. In this respect, they moreso resemble interrupt handlers. I prefer to think of them as processes though, since they can have children and they have a large influence over the state of the system. Also, my processes are unprioritized; in operating systems you can assign a process a priority to determine how often it executes and you can also give processes fixed time limits before they must give up control, but in my system each process is guaranteed to receive every event it is interested in and can perform its operation in full before giving up control.

Intercommunication between game processes is done through typical event passing. Thus it is, by its nature, asynchronous and non-blocking. Further, since processes are guaranteed to finish executing without interruption, we do not have to worry about race conditions. However, I could easily envision an advancement for multicore architectures where processes could run with true concurrency - increasing performance, but potentially complicating the system.

That's most of the introductory material for this system. I've implemented it for past C++ games, and I've finished migrating it to my XNA projects. Over the course of the next few posts, I will probably go more in depth discussing implementation details and example usage.

Porting to XNA

2006-09-20T18:23:00.000-04:00

I made the decision to port a lot of my framework over to XNA, and it's progressing remarkably smoothly. I don't have any fancy graphics on the screen, but I do have my process tree and event management systems in. I was also easily able to switch from input polling to input event passing, with the next step being abstracting things out a little bit further so that I can switch between the XBox controller and the keyboard seemlessly. Not a hard modification, but not a fun one either.

I've been trying really hard to avoid some of my C++ methods while writing in C#. Reflection is helping a lot, and I've practically eliminated a lot of unsafe type casting. My event management system has become a whole lot cleaner, but I will admit that it does not adhere to the common C# practice involving the use of delegates. Though I had legitimate reasons for doing this, it still feels a bit dirty.

I did buckle and introduce the Singleton in my code. I had great reservations about doing this - it's regarded by many as an anti-pattern for good reason - but a whole lot of my modules need access to core modules, and it would be cumbersome (and in many cases illogical) to pass those modules around to make sure they get where they're needed. I'm still looking for a better way, but until I do I'm hoping that I will not have reason to regret my decision.

StreamParser

2006-09-18T23:04:00.000-04:00

Here is a simple utility class designed to mimic Java's Scanner class for the purpose of reading in files. It can be easily expanded to be more generic, but for my purposes confining it to reading files is sufficient.

public class StreamParser

{

public StreamParser(string fileName)

{

using (StreamReader streamReader = new StreamReader(fileName))

{

mData = streamReader.ReadToEnd();

mTokens = mData.Split(mDelimiters);

}

public string NextString()

{

mCurrToken++;

return mTokens[mCurrToken];

}

public int NextInt()

{

mCurrToken++;

return int.Parse(mTokens[mCurrToken]);

}

public float NextFloat()

{

mCurrToken++;

return float.Parse(mTokens[mCurrToken]);

}

public double NextDouble()

{

mCurrToken++;

return double.Parse(mTokens[mCurrToken]);

}

private bool HasNext()

{

if (mCurrToken >= mTokens.Length)

{

return false;

}

else

{

return true;

}

private string mData;

private string[] mTokens;

private char[] mDelimiters = new char[] { ' ', '\n', '\t' };

private int mCurrToken = -1;

}

C# File Reading

2006-09-17T18:04:00.000-04:00

In writing my tile map class for a map editor/Parodica, I ran into a nifty little quirk of .NET: there's no clean way to read numbers from files.

In C++, the process is pretty painless. ifstream is designed in such a way that it will seemlessly parse strings, ints, floats, or even your own user defined types. In C#, the process is not so straight forward. First you have to read the file in as a string and then you have to tokenize it and then you have to convert those string tokens into the appropriate data types. Not only is this less efficient, but it's also just plain ugly.

I can't imagine why there was such an oversight. My only guess is that the .NET language designers envisioned a world where everyone was using XML to store data. But I'll contend - to my grave - that XML is not the best option here since it is not really suitable for storing large arrays of data and it's overkill since my data is in no way heirarchical.

The Duelist Goes Gold!

2006-09-15T01:49:00.000-04:00

It is done.

I had a lot of fun and a fair number of sleep-deprived nights developing this game. I've already provided a full post-mortem, but here are a few addendums:

Polish is What Separates Indy from Pro
I could think of 100 things to add to this game. A few more minigames, a few tweaks, an extra game mode or two, some more intermediary screens, extra graphical effects and flare, and a bit more polish. And while I was thinking of all the stuff I would have to leave out because of time, I realized that this is what differentiates the professional games from the small hobby games - those little graphical effects count, and those extra game modes had better be there, and that content better show up.
If your game has a lot of depth, people will appreciate that and keep finding ways to have fun. I tossed in about as much as I could get around to, and I think my entry shines a little because of that.

Fonts Suck
Seriously. I tolerated sub-standard graphics in a few instances because (a) I'm not an artist and (b) I'm not a good photo editor and (c) I didn't have time to fool around with that nonsense. But the original font looked prohibitively bad. The second font was unreadable. The third font was not displaying well as a series of textured quads in OpenGL. The fourth font was, again, not readable. I finally got it decent on the fifth font - not pretty, but decent.

I'm Terrible at Guitar
Even if I win and even if I get an internship at RedOctane, they'll never let me get near Guitar Hero because of the insult I bring to the instrument. I spent so much time trying to get decent music, and eventually I buckled and used a synth program for 50% (read: 1 out of 2) of my tracks.

Data Driven Systems Rock Hard
I didn't stress this enough in my post-mortem. It got to the point where to add things in later in the game, I didn't have to look at the code anymore - I just banged together a few text files and I was ready to rock. I still looked at the code, of course - there was constant tweaking and editing and cleaning up - but none of that was related to adding content.

Event Driven Systems Rock Hard Too
I've reemphasized this over and over on this blog, and I'm going to do that again. Nothing satisfies me more than the level of sophistication that introducing event management has added to my code.

Memory Management Systems Rock Hard... Three
I remember a day when I used to argue with pointers - when memory leaks and seg faults were common and hard to track down. When a man could run his program and be almost certain that it would crash at some point, even if that point took some time to get to.
And then I look back and wonder why the hell I hadn't implemented a Smart Pointer. It has to be one of the most beneficial additions that I curse myself for not adding to my C++ games sooner. By no means is it the end-all solution to memory management, but it certainly alleviates 90% of all memory-related headaches.

Writing Things Quickly is Nice, but Writing Them Good is Better
There were a few times when I was tempted to put a quick, dirty hack into my code to get something to work. I always argued with myself, and I won't lie - in one or two instances, that hack made it into the code. But for the large majority of cases, I resisted the urge, and I'm glad I did.
Hacking typically makes things complicated. Debugging gets complicated and understanding code gets complicated and sometimes even writing the hack itself is complicated. And in the end, you've caused more problems then the hack was intended to solve.
Because I avoided adding craziness to my code, it was a lot easier to maintain. Bugs were less frequent and easier to find, and everything just seemed prettier. Had I tried to rush through the development, I could have very easily backed myself into a wall that just required more hacks to get around until eventually adding a simple feature took forever.

When You're Not Coding, You're Thinking About It
Programming is interesting in that it often does not require you to be programming. There were times when I was fed up with looking at my laptop and needed to get away, and so I took a walk or went to the local coffee shop to heckle baristas. And what was I really doing?
Working out code in my head. Working out logic and conditions and requirements. And when I finally got back to my computer, I had the problem so thought-out that I could bang out a solution - a process which, comparatively, takes a much shorter amount of time than thinking through the problem.

Thinking Is No Substitution for Development
This runs somewhat in contrast to my point above. Sometimes I could spend a little too much time at that coffee shop. There comes a point when just thinking is too appealing, and you have to force yourself in front of that computer to start typing. And you have to cut off distractions and resist the urge to 'get up and think some more.' In the end, that code has to get written somehow. While you can work out a lot of problems away from the computer, and it can definitely be a welcome change, you'll invariably work out a lot more when you're actually in the thick of it - creating, debugging, testing, and creating some more.

Finish the Game
It's easy to leave a game in a half-finished state. Neglecting content or leaving obvious deficiencies is tempting sometimes. Hell, I nearly called that font 'finished' at iteration 3 - something which would have clearly hurt me. My game nearly lacked a lot of player feedback which, during testing, I found to be essential to actually playing the game. But they were glaring flaws, and if I wanted any chance of a halfway decent game, they had to be fixed. It's easy to call something 'good enough,' but you must determine if it's actually good enough before you call your game finished.

Finish the Game, I Said
There's a point in development when you realize that your game isn't going to get much better than it is with the time you have left. At this point, it's time to say enough is enough and focus more on tweaking, testing/debugging, and general polish than on cramming in a few half-finished twiddly bits. Near the end of development, I was tinkering with the idea of adding a new duel type or two, but I knew I couldn't get them up to par and still have time to fix that damn font. So I focused on what was important - making my game more presentable and polished.

Make Hundreds of Friends
I can't possibly bring this across more clearly - the people I know are the reason this game got finished. When I was looking for confirmation that my idea had merit, I needed only to look at a comment left on this very blog. When I realized that I couldn't possibly make 20 different high-quality images for the various duelists, my friends were there to back me up and in the process embarrass themselves a bit by being featured in the game. When I was scrambling for a method to create music, my roommate helped me out by letting me use his amp and electric guitar (which didn't actually make it into the game). When I needed expert opinions, I had a friend I could count on to playtest and tell me where I needed improvement, not hesitating to put me in my place when something sucked. When I needed uplifting or motivating, I could send a screenshot over to someone and get a "that's awesome."

Don't Reinvent the Wheel, and Don't Use Square Wheels
Writing your own linked list is great for learning purposes, but the STL's list is usually just as good or even better. Creating your own window is fine, but SDL can do the same thing in about 1/50th the lines of code. DirectSound/DirectMusic may be a great technology, but FMOD is quick and easy.
There a bunch of tools to help you with any job, and you should use the right tool for the right job. In my case, the job was 'finish a small game quick and make it as good as possible.' Obviously, if there was something that could do the same job in less time and fit all my needs, I wanted to use it. I didn't need that extra 1% speed boost or the low level control that some libraries provide. So why spend more time to get it when I could spend that time making the game?

Keep That Toolbox Big
Using glut was not the right decision from the start. It just didn't work properly with the pad. I had to change solutions, and I couldn't waste time moping. Luckily, I knew enough about SDL to switch over relatively painlessly, and if SDL didn't work out, I knew how to create my own windows and use DirectInput.
The point here is this: if I only knew glut, I would've been finished before I even started. I knew enough that if one solution failed me, I had backups. With everything from graphics to sound, I had alternatives available. This is good and should be practiced whenever possible. And if you find out that what you know isn't working but you don't know an alternative, hopefully you're good enough to pick up new technologies fast.

Wow, I think this might have turned out longer than the original post-mortem. I hope I provided some useful information. I could keep going on, but this has already taken me quite a long time to write.

So I'll wrap this up with these short words:
Play the game. Have fun. I was pleased with how it turned out, and I had a great time making it. I hope you enjoy it.

Web Comics Day 7: A Miracle of Science

2006-09-13T03:32:00.000-04:00

It seems as though many of the comics I've talked about have some defining criteria that deviates themselves from the rest, and A Miracle of Science continues this trend by being one of the few comics I read that actual focuses on the telling of a single, mostly serious story from start to finish. It's also the only sci-fi offering among the pack.

AMOS follows the story of Benjamin Prester and Caprice Quevillion, two police officers trekking through the galaxy on the trail of a genuine mad scientist named Haas. Along the way, we are witness to relevations on Benjamin's past, the growing bond between Benjamin and Caprice, and Haas's maniacism as he succumbs to the disease which makes him a mad scientist.

The creators really go a long way in the telling of a story, creating an emotional pull toward the characters and their actions. Everything flows smoothly and progresses the story along. The various story arcs are all well put together and all contribute to a solid whole.

The characters making up this story are all great. Despite having a cliche romance between the two partners, the two play off each other really well and things never get corny. Haas is also a spectacle as we watch his plans unfold. Even the supporting cast, from Prester's captain to Haas robot assistants, all have unique qualities that make them endearing in some fashion.

There are flaws, of course. The art is nothing to write home about, even when such writing can travel instantaneously via our World Wide Web. It's not horrible and never detracts from the action, but it typically doesn't add much (there are some notable exceptions in a few panels).

When I said there were flaws, I lied - there's just the one.

Overall, the comic is excellent. The story is rapidly approaching the finale, so I advise you catch up quick.

The Duelist: Continued

2006-09-11T15:36:00.000-04:00

I posted a post-mortem for The Duelist not 24 hours before they extended the deadline. I'm not too happy about this, not because I prematurely posted a post-mortem, but because I'm ready to be done with this game. I have other things I want to focus on (XNA, Parodica, David Baraff's papers on physically based modeling, Half-Life 2 modding, C#), but I can't just sit idly and not do anything with an entire week. So, yet again, XNA & Parodica updates are put on temporary hold until (hopefully) the end of the week.

But this did cause me to think of an area where event passing clearly wins over input polling. The dance pads didn't arrive until late - over a full week into the competition for me and longer for others. Thus, I found it necessary to begin development without the pads. As I mentioned in my post-mortem, this was good because it allowed me to get a head start and also made debugging a great deal faster.

When the pad arrived, I needed to integrate it quickly. Had I used polling I would've needed to find every instance where I polled for input and retro-fitted it to poll for and handle joystick input as well. Not only tedious, but error prone and code-uglifying. But since I was using event management, I needed to make a change in one place - I simply incorporated a 'joystick translator' that took joystick inputs, converted them to the appropriate keyboard characters I was already using for input, and then sent that through the event system as though they were keyboard events. It was clean, it was elegant, and it was easy.

Ideally, it's not the most elegant solution. Since my code is bound to the keyboard keys, it makes remapping keys (to user preferences) difficult. A better route would have been to translate both keyboard keys and joystick input into a common 'game action' type of event, which could easily be remapped as the user wanted. But my solution works well enough for these purposes.

The Duelist: Post-Mortem

2006-09-08T02:59:00.000-04:00

The Duelist is nearly complete. All that's left is some AI programming, sound implementation, and the addition of a little bit of content. I should be doing all of that right now since the deadline is in about 24 hours. However, I've decided to take a small break to write a summary of my experiences while creating the game.

The Evolution of the Idea
The original concept for The Duelist was embarrassingly simple. It consisted of a Simon-like game where two players would go back and forth hitting a constantly growing series of steps until a player messed up. You might recognize this as the Mind Hack duel technique that went into the final design.

I quickly realized that the idea was too shallow. It might be fun for five or ten minutes, but more was needed. Thinking of more was a struggle. It hit me in the shower sometime. Why not make a bunch of simple little games where players could face off against each other?
With the right dynamic, this could be a lot of fun. At the very least, you could trash talk with your friends.

The minigame ideas came relatively quickly. I wanted them to be simple, fast, and fun. I wanted the players to constantly be moving (so long as that was possible), and I wanted things to be varied enough that things didn't stagnate too quickly. However, I also wanted things to be simple - no complicated art, little complicated programming. With these requirements in mind, it wasn't long before I had my original set of 6 games.

And then I hit a snag. Again, the idea seemed a little bit too shallow. Just multiplayer? Just a minigame at a time? No, I wasn't happy with any of that. So I started slamming my head against the ceiling (a difficult task considering the height of our ceiling) trying to think of more to add.

In parallel to doing all of this, I was working my way through Revolutionary Girl Utena - an anime where a high school student has duels with her peers for, well, the reason isn't important (and it's awfully weird and ruins the street cred I have built up). Further, I was thinking a lot about telekinesis. I had also watched Volcano High a few weeks prior, where school students fight each other with super powers.

And - again, in the shower (I spend a lot of time in there) - I came up with my idea. The player would be a student attending a university where the only way to graduate would be to beat everyone in telekinetic duels. The duels would be setup in multiple turns, where each turn would be a minigame (or, to follow our theme, would be a battle in a certain telekinetic technique). Players win by winning three more duels than their opponents have won. That is to say, it's not a 'best out of 5' system where one player can just barely win; you have to clearly come out on top to be proven the victor. Thus, there can be a bit of a struggle to come out on top. To top that off, when the player isn't dueling, he can go around the university and talk to the students.

I had my idea, and I was happy with it. Now to submit it and hope.

Course of Development
The first week went slow. I spent most of my time waiting for the DDR pad to arrive. I could have easily setup a temporary solution wherein I use keyboard keys for input. But I didn't. I was stubborn and wanted to wait, and thus I burned a lot of time here. In lieu of programming actual content, I built up my framework and made sure everything was bug-free.

The second week went somewhat better. Realizing that the pad may come the very last day, I decided it would be best if I went ahead and implemented the temporary solution. In retrospect, this was a great idea - not only did it make testing much easier, but it was easily convertible when the pad arrived (in fact, when I did finally get my pad, I just mapped the pad buttons to keyboard keys and kept the same code in place). I got a quick proof-of-concept minigame working and setup the infrastructure that would allow easy university navigation. I also came to one very grim realization.

I'm not an artist. My friends know this. Anyone who's ever visited any of my sites know this. I knew this, but I ignored it. The game required art - a pretty sizeable amount. I bought a sketch book prior to being accepted and started practicing the craft more heavily. But when it finally came to content generation, I knew I wasn't going to cut it - my drawings looked bad and took too long to produce. A compromise needed to be made.

The compromise was actually pretty straight-forward. My game takes place in a university. Why not take pictures of actual people, apply some fancy image filters, and let those be the graphics? That just leaves me with some simple GUI stuff and the buildings, which I could create easily enough using Google Sketchup.

The third week is when everything came together and I kicked myself into high gear. I got the code functionally complete - it was missing some of the bells & whistles I would've liked, but it was a recognizable game. I got pictures of my friends and doctored them for in-game use, and I made the scenery that the game would take place in. My time was being juggled between content generation and intense coding, and surprisingly everything was going relatively smoothly.

Strangely enough, most of the game came together in the last few days. There was a lot there before that, but it wasn't recognizable as a cohesive whole; there were just a series of fragmented pieces waiting to be glued together. It took a lot of work and a few late nights, but I was able to get most everything together.

When it was finally over, I had actually done pretty well. I did have to cut one of my listed features (multiplayer using only 1 pad) because I failed to make my code in such a way that it would be as easy to implement as I had hoped. But I was also able to add one extra minigame and get things looking pretty good.

What Went Right
The Framework
I'm happy with my framework. I've got this great process manager that helps me write some very modular, very robust code that's easy to modify and tweak as I go. I've also got a nice event passing mechanism. With these systems in place, I was able to quickly see the results of my development, and I was able to quickly track down and edit bugs. I won't say it's the greatest system around, but for small games, it's definitely handy.

The People
I was a bit hesitant to ask people if they'd want their picture in the game. In the end, most everyone seemed excited about it. I'm really glad they helped out - the game wouldn't look anywhere near as decent without them.

Memory Management
I remember a time before I coded a Smart Pointer class, and I remember how many memory leaks and problems this caused. Even with it there, things weren't flawless. I'm to the point where I just don't enjoy wrestling pointers anymore. Truth be told, the XNA Framework came out mid-development, and I was tempted to port everything over to it just to get that automatic memory management.

The Concept
I like my game idea. I think there was a lot of potential for fun there (even more than I managed to bring out), and the general simplicity really helped to move things along. I could see results fast, and I never really got bogged down in my code.

Data-Driven Development
I setup my game in such a way where I could drop in a few text files and immediately see changes to the course of the game. This is essential. There's nothing worse than having to go in and change your code every time you want to see something change in your game. Having the ability to edit a few files and immediately see the changes makes things go orders of magnitude faster, and it feels a whole lot easier.

What Went Wrong
Time Management
I could've spent my first week a lot better, and even that second week could've been more productive. This lead to me feeling pretty rushed near the end, which is both good and bad - good because I got a lot done and my mind was in the constant 'game development mindset', but bad because I had a few really late nights.

Feature Creep
I'm not talking about 'feature creep' in the sense that I kept thinking of features I wanted to add. I'm talking about feature creep in the sense that I kept thinking of features I needed to add that I hadn't really accounted for. Player feedback was the biggest one. A few of the minigames are noticeably missing in messages to the players - you just see who wins/loses, and you might not be entirely apparent why. If I had a little more time, this would've been fixed, but other features took priority.

Cut/Unimplemented Features
I got really disappointed when I realized that I would have to cut out the 1 pad multiplayer, since it was one of the better features my game advertised. The game also could've used some more user-friendly features, like a configuration screen or even a credits screen. In the end, though, this again came down to the time factor - I had to decide what I could implement that gave me the most for the least amount of work.

What I Learned
I'm Not a Professional Game Developer
I'm not bagging myself or being self-deprecating here. There is one fundamental difference (aside from experience) that separates me from a professional: time. A professional is paid to work at least (hah) 8 hours a day 5 days a week. I'm a college student working on a Master's in CS. I can't work that much on a game. It just isn't possible for me to hold down school, do my job, and keep the kind of game development schedule I'd like. So in the end, I have to make compromises on how much time I can spend developing and how much sleep I can bare to lose.
As an aside, I lost a good deal of sleep trying to get this game finished on time.

Event Passing Rules
This post-mortem has been relatively non-technical thus far, but allow me to say this: communicating between modules via event passing is a really, really nice. It often allows you to drop modules in or take modules out without anything breaking or needing modified. It should be a serious consideration for anyone developing a game of any size.

Fighting Distractions is Hard
If your job isn't game development, you're always making compromises. But sometimes, the game development has to come first. And that is when everything else seems to call for your attention. There's no easy way to get around that - sometimes you just have to tell your friend to shove off or push that school paper aside for a few hours.

What I Knew and was Happy I Used
Code Reuse is Your Friend
I can't stress this enough - make your code reusable. Break things into functions and modules. If you find yourself repeating something over and over, it's time to refactor. I had a great infrastructure to support this, and it saved me a whole lot of time.

Data is Your Friend
This goes hand-in-hand with my section on data-driven development. Make your game as modifiable outside of the game code as humanly possible. Scripting is good. Specifying object data with data files is excellent. You'll be able to swap these in and out quickly, and your game development will move so much faster. Also, if you want to add the ability to modify your game later, it's a whole lot easier.

What I Knew and Shoul've Used
Get the Right Set of Tools, and if They Aren't Around, Make Them
Often I'd find myself waist deep in text files trying to make sense of some numbers I used that would break when in some place but would work perfectly other places. This could've been easily alleviated by slapping together a quick tool. .NET makes creating a lot of tools trivial.

Conclusions
There's a whole lot more to say about The Duelist and game development in general, but it is not for this post-mortem. In general, I'm happy with the course the development took - I wish I could've used some of my time more effectively, but overall I'm happy with the outcomes.
Now, it's time for me to go put the finishing touches on this.

The Duelist: Progress Report

2006-09-06T21:35:00.000-04:00

XNA development has been postponed until Friday since that is the deadline for The Duelist, and I really have to focus on finishing this.

My progress on The Duelist has been somewhat mixed. I burned a lot of time in the beginning when I could have been doing meaningful development, and thus I know things aren't as complete as they could be. However, over the last few days, I've implemented all the minigame ideas and even included an extra one. Functionally, nearly everything is there - there's still a good bit of tweaking to do, but that's just a process of manipulating the components which already exist. Artistically, I'm in a lot better shape than I thought I was going to be in - I still need to make a few models and get a few pictures, but things are looking pretty good. I'm feeling confident that I'll have something decent to show off, and it's going to be one of my better games.

So here's the schedule until completion:
Tonight I'm editing art assets and putting the final touches on a good deal of the coding, sans AI.
Tomorrow I'm finishing the art and content and implementing all of the AI.
Friday is dedicated entirely to sound generation and implementation.

And finally, I leave you with a pretty awesome screenshot:

Web Comics Day 6: Rob and Elliot

2006-09-06T00:39:00.000-04:00

Rob and Elliot does not have a compelling story. It's not always updated on time. It doesn't fall into any niche markets, and it doesn't make itself noticeable by shocking/offending/surprising its readers. But by God, it's charming.

And therein lies the beauty of Rob and Elliot. It's just simply charming. The humor is always silly and asinine, and it never takes itself too seriously. It's not trying to tell a story or involve you emotionally with characters or make a point. It's just trying to have fun. And it has fun in a big way.

This is all helped by the art, which is golden. Color is vibrant, characters are defined and expressive, scenery is pretty. Clay really brings his A-Game in on this every strip, and his work pays off.

I don't have a lot to say about Rob and Elliot because there's just not a lot to say. It's just good, pure fun. They've just recently finished their 200th strip. Which means you've got some catch up to do.

In non-comic related news, I've changed it so my posts are signed with my name instead of GenesisGenocide. Not particularly important, but I want to make sure everyone knows who's saying what. Also, apologies for the post on the texture cache. I realize how poorly formatted it looks, and Blogger has somehow made me incapable of deleting it. Which is a little weird, but oh well.

Web Comics Day 5: Megatokyo

2006-09-04T01:47:00.000-04:00

I don't know why Megatokyo is in my Favorites. I don't know why I still read it.

I'll start this discussion by talking about the art, which to my mind is the only thing Megatokyo does right. This is where the artist, Fred Gallagher, shines. You can tell he puts a lot of work into this - every character is detailed and expressive, and even the backgrounds have a lot going on. There's always a lot of care given to subtleties here. Facial expressions and stances and panel layouts are always very articulate.

And that's about the only good thing I have to say.

The content of the comic is another story entirely. Initially, it had some humor to it. It was never excessively funny, but it could be whacky and inventive. Then things got serious. Dead serious. Boring serious. It's not that I'm opposed to the elimination of comedy in favor of more serious material, but I am opposed to the elimination of comedy without replacing it with anything.

It's a problem of pacing, I think. There's stuff that happens, but it's so long and drawn out and typically unimportant that you get the impression that nothing is happening. Everything seems so static. The characters aren't changing, the character relationships are hardly progressing, story arcs don't seem to have any real substance. It's just this big mess of... bleh... and I look back, and there's not a single bit of it that stands out as memorable.

There's also the matter of how often the comic gets updated. Which might be twice a week if you're lucky. Gallagher is the absolute worst at keeping any kind of regular schedule. Theoretically the comic updates every Monday, Wednesday, and Friday. But if you consider Dead Piro Days, Shirt Guy Dom Days, and days where Piro right-out says that nothing is going to come, you end up with quite a lot of nothing. And it's always a huge disappointment.

And that leads me to this final bit: for whatever reason, I still read this. There's a quality about Megatokyo that can't really be captured - or at least that I can't capture - that compels people to go forward. For all the bad I have to say about it, I still check that site hopeful that Gallagher has put up something interesting. So go ahead and read it. Peruse the archives, and maybe you'll be able to figure out what keeps me reading.

Services/Subscribers

2006-09-03T21:12:00.000-04:00

This isn't so much XNA as it is .NET in general, but I feel it's pertinent since it's related to me trying to get XNA to treat input in an event-driven way as opposed to using a polling mechanism.

I've been struggling a bit with delegates and the whole service/subscriber paradigm as used in .NET. Not the implementation - that's trivial - but the true benefits of their method versus my old habits. I'm used to having a service provider which is responsible for registering and unregistering subscribers and then sending events to the subscriber via calling an interfaced method. I'm not used to the subscribers registering/unregistering themselves by adding a delegate to the service provider. At first, I thought this second method would increase coupling by binding the subscriber to the service and then binding the service to the subscriber, but that's not really what's happening here. The provider doesn't care about the nature of the subscriber so long as the delegate has been added to it - any changes to the internals of the subscriber will be completely transparent. It seems that changes to the internals of the provider may require a change in the subscriber, and thus you've simply reversed the nature of your coupling from the first method, where a change in the provider was transparent to the subscriber but the opposite may not be true.
So I've been banging my head against a wall, trying to figure out why exactly everyone seems to prefer the .NET method. It could be simply that that's how the .NET documentation recommends developers so that they conform to the .NET standard of doing things, or there could be some clear benefit I'm missing. Clarification would be appreciated.

I've found one scenario where I can't find a simple implementation in .NET, and I have thus gone to my method. The problem is that I'd like to have one service provider that is speed-efficient and can easily handle multiple types of events. Having to add a new event type to my provider each time I recognized a new game event sounded extremely cumbersome. Further, having one event type store all my delegates did not seem efficient - the event would end up being sent to all listeners, even if those listeners were not interested in the specific type of event. My solution is to have a Dictionary mapping a Type to a List of GameEventSubscribers. When a subscriber is subscribed, it subscribes to a specific Type. When an event is posted, only that list of GameEventSubscribers that is actually listening for the specific event type gets notified.
The system has one apparent flaw, and that is it's not 100% type safe when registering/unregistering a listener. You can register a listener to any type, not just types that derive from GameEvent. PostEvent only takes a GameEvent, so those listeners will never receive something else, but it would be nice to prevent them ever registering themselves to, say, System.Generic (because some stupid programmer will try it). A simple solution I can see is to just throw an exception when someone tries something like that, which is easy enough, I suppose.

I know my meaning is not entirely apparent, and it'd be a lot easier to explain with source code. I did look for methods to post source code here, but I still haven't found anything good yet. Hopefully some golden knight will appear and offer a solution, and these updates can be a little clearer/more informative.

And Then There Was Pong

2006-09-01T17:55:00.000-04:00

After getting "familiar" with the XNA input methods, I banged up a quick little version of Pong to play around. The process went something like this:

First, I imported all the graphics into the project and told XNA to copy them to the appropriate location. I used some Parodica graphics I had lyring around - Alex and Bekah were the paddles and Schmee was the ball.

Second, I put together a quick little texture cache class so that I didn't have to manage everything on my own and so I wouldn't have to create a new variable for every texture. I then discovered that the XNA Starter Kit Spacewar came with a slightly better version. I imagine both won't be all that useful once the Content Pipeline is integrated, but that remains to be seen.

Third, I made a quick Entity class to handle my (very) basic sprites. It was a hacked together class that is absolutely not meant for serious use, but programming Pong isn't a serious task.

Fourth, I wrote the code to handle the input. This was the ugliest stuff I've ever written. Not only am I unfond of the polling system found in XNA, but I'm further unfond of how these results are returned. Instead of being able to easily find out whether a key was down or not, I had to search through an array of pressed keys to find if the button I was interested in was located in the array. Very shabby stuff. I expect the next thing I'm going to do is write my own event management for input.

Fifth, I wrote some quick collision detection. Very typical stuff using bounding boxes. Nothing new here. XNA made the process simple enough via providing a BoundingBox class, but it's really not a lot of work to write one anyway.

I then called the project finished. The only remaining step was to add some sort of score display. Unfortunately, I didn't find any font support in the XNA 2D library, which is a pretty glaring omission that I'm not looking forward to implementing myself. It's not hard, but it's terribly uninteresting.

I'm pretty pleased thus far. Pong took me almost no time to develop, and most of that non-time was spent learning how to handle input. XNA isn't perfect, but it's also only in Beta. Based around comments in the XNA Team Blog, I expect that they will be adding a great deal of functionality. I'm interested to see how this library matures.

I was hoping to provide some code with this update, but I could not insert it without my formatting being mangled. If anyone could tell me how to work around that, I'd be appreciative.

XNA - In the Beginning

2006-09-01T00:28:00.000-04:00

For anyone with experience in game development, the XNA Game Studio starts off rather refreshingly. You see, one of the biggest barriers to starting game development in Windows is learning Windows. MFC and Win32 and integrating DirectX/OpenGL and showing a window and processing window events and managing all the little things that can (and will) go wrong is daunting. There are libraries like glut and SDL to help out, but they don't make the process entirely painless. Even in .NET, the process isn't streamlined - Tao makes things easy on the OpenGL end with some handy controls, but DirectX isn't something you just 'pick up and roll with' in my experiences. So when I started up a brand new XNA project and hit F5 and saw a window already there, I was pleasantly surprised. Sure, there is code that went into that, but it was already written for me; I was ready to go without any work. Nice. Very nice.

And things only went uphill from there. I focused on 2D development, because I'm not quite ready to dive into Direct3D. I can say this - the 2D development was easier than everything I've ever experienced. I didn't have to write any texture loaders or fool around with any memory. I didn't even have to copy the images to an appropriate directory - XNA did that for me. All I did was load the texture using the fancy-schmancy Texture2D class and draw it using the SpriteBatch class. Five lines of code total. Again, nice.

I haven't messed with input yet, but I can already see this is going to be the source of my first complaint. I've become quite fond of doing input by processing events - it keeps things very clean and expandable in my experiences. The library, however, only seems to have support for polling the states of the various input devices. I will probably have to write my own class to handle taking the polled states and converting them into messages to get passed around to my various objects.

I'll leave you with this screenshot. It's just a basic window with one of the characters from Parodica in it. I won't say this hints at a possible port from the C++/OpenGL version, but don't be surprised if I decide to take that route.

Web Comics Day 4: Something Positive

2006-08-31T18:40:00.000-04:00

Something Positive by R.K. Milholland differentiates itself from most of my routine comics by being the most vulgar thing I've ever read. This is not a child's comic. It's not even an adult's comic. It falls neatly in the realm of 'depraved college student' humor. That's not to say that other audiences won't enjoy it, but you've been warned: if there's something that can offend you, it will be dropped around in this comic like dirty laundry.

If, however, you're harder to disgust, you may enjoy the comic. It can be somewhat formulaic at times - a lot of the punch-lines are similar and executed in the same way, and a good deal of dialog feels like it's rehashed. Otherwise, there is some clever stuff in here. At the least, you'll definitely find new ways to insult someone.

One of the other things I greatly appreciate about this comic is that, even when it's being crude or outright mean, it does not shy away from drama and character development. Important characters will die. People will lose their babies. Hearts will be broken. Hearts will be mended. Characters will evolve radically. Everything is constantly changing, and it's all very well put together. The storylines are all excellent, and there are a few shockers that had me reeling. Even if you can't appreciate the humor, there are still some good stories in here.

The art is decent. Characters are well designed and show expression well. The backgrounds are entirely negligible, but as I've said before, this is too common to care much about. While nothing strikes me as remarkable about this art, it's definitely solid and well put-together.

The comic updates a lot, as advertised. This comes in bursts - sometimes there will be lulls where you might have a day or two off, and sometimes you'll get ten comics in the course of a week. With that much content, there's a lot here to like, and if you find yourself enjoying the comic, you'll certainly be pleased.

Geek Kung-Fu, Shaolin Style

2006-08-30T23:29:00.000-04:00

While Ricky is doing his thing in regards to development and improving his software engineering talents, I too have my own goals which I would like to chronicle as they progress. I don't know that my methods will, in fact, be regarded as the Shaolin Style of Geek Kung-Fu - I've never been to China, nor have I ever met a Shaolin monk - but they will at least further my own personal development. Any martial arts developed through the process are a pleasant biproduct.

So here's what I'm going to do. I'm going to lay this on the line right here, and if I fail to meet the standards I have set, you as the community are free to berate me until I am emotionally exhausted.

(a) C#. It's time I learned it properly. And I'm not going to learn it by writing a "Hello World" application. I'm going to learn it by making a 2d tile map editor and a basic 3d scene editor. I'm also going to learn my way around Tao during this process. This is a secondary project which will not have my full attention, but I will reserve at least one post a week to it.

(b) The Duelist. My DDR pad came in today, and I have exactly 9 days to finish this game. The large majority of this development will be done in C++/OpenGL/FMOD, and since I'm already intimately familiar with all of these technologies and the course the game development will take, I will not provide many details during development. I will, however, write a full post-mortem. You can expect to have this in your cache by the end of September 10th.

(c) The XNA Game Studio. I intend to become quite proficient in developing with this before the XBox portability feature is introduced. Thus, I am going to dedicate 2 hours per night to learning this technology. And I fully intend to report on what I've learned every other night.

(d) Parodica. For those unfamiliar, it's an RPG I've been working on since early last semester. Once the Duelist is finished, I want to put development on this on the forefront of my priorities - quite simply, I want this game finished. This is something I intend to update on on the nights when I am not updating on the XNA Game Studio.

(e) A film project. Typically there is a film festival close to Halloween where anyone can submit a film. I will have something for this festival. And I will detail the entire creation process here. But that too will not start until The Duelist is finished.

Those are my goals for right now. As I said, I intend to provide regular reports on all of these for both your benefit and mine; hopefully I will have useful information to pass on, and feeling obligated to update here will put added pressure on me to avoid slacking off. I'm looking forward to it.

Web Comics Day 3: Shortpacked!

2006-08-29T22:07:00.000-04:00

Finally a comic involving original art: Shortpacked!

This comic is awesome. Let me tell you why, starting with this point of interest: the artwork is good. Every panel is clean and well-drawn. The characters all have a unique look without being horribly exaggerated. There's typically not much happening in the background, but this is an affliction very common among all comics. Since everything else is solid, I take no points off. I won't say this is the prettiest comic ever, but it's definitely not a burden on the eyes.

Shortpacked goes out of its way to be funny. There may be some dramatic story arc going on, but if David Willis decides it's time to interject with a Batman gag, you can bet that story will wait a day for the Dark Knight. Speaking of the story arcs, they're all good. They're all very real-ish - things never get too outlandish as to belong in Sluggy Freelance (not knocking Sluggy there), but they're never so serious that there won't be humor. And the pacing is absolutely perfect.

Shortpacked is fresh. I dare you to find a better webcomic about toys. It won't happen. Nobody mixes real life with Megatron the way this comic does. I don't know when this comic updates exactly (a lot, but I can't pin down a schedule), but I find myself looking forward to every new edition.

Give it a Name

2006-08-29T21:32:00.000-04:00

I'm currently amazed at how important it is to give your projects a name (at least for me). I've read several articles, of which I have no concrete references or links, that detail the importance of naming your projects. Personally, I've always thought this border-line silly, and detest the number of "management pun" acronym projects we have at work. However, I may be on the brink of a change of heart, at least on the small.

As mentioned in my previous post, I'm working on a personal project to test out some theoretical waters. To say these waters are a pool of Agile practices would not be a lie. I started this project three or four weeks ago, with the idea growing in my brain for some time before that. However, my motivation and desire to produce has been somewhat lacking; some might describe it as non-existant.

The other evening I had a very small bout of motivation, so I began working on my project. I got tired of calling it Pluggable Ray Tracer, so I did the "dirty" and shortened it to PRT. And then I chuckled. For those of you not from north-central West Virginia, or not a student at West Virginia University, this may be mundane. However, there is a certain mechanical monstrosity that carries students and townies to their approximate destinations. Sometimes.

Cutting straight to the chase, I found myself writing simple requirements with the phrase "PRT will...," "PRT shall...," and so-on and so-on. The point is I was no longer avoiding the work. It may seem stupid, and I don't advocate shortening everything in God's existence to an acronym, but something about creating the name for that little project prodded me into working on it, with less motivational investment.

So I guess the final word here is, if you have a project you're working on and you can't bring yourself to produce, try bestowing a little creative thought upon your creation. You may (or may not) be surprised.

Web Comics Day 2: 8-bit Theater

2006-08-28T20:41:00.000-04:00

Ah, 8-bit Theater. The sprite comic. Oh, there are others, of course. But none which have held my interest as long as this one.

Some think that the use of Final Fantasy sprites in lieu of original artwork cheapens a comic - an argument which I understand fully. But I also understand (even more fully) that non-artists would like a chance to flex their story-telling muscles in the comic format. These non-artists are left with only a handful of options, and using someone else's already existing artwork is often the most feasible.

I don't know if Clevinger wanted all along to use sprites or if he was forced to out of a genuine lack of artistic ability, but since he does not have his unique visual style to play off of, he is forced to make his comic appealing almost solely through the content. And to this end, 8-bit Theater succeeds... usually.

The story follows (in some similar fashion) the same storyline that Final Fantasy 1 followed, using the same characters that were available as party members in FF1. They weren't even given original names - the black mage is named Black Mage, the red mage Red Mage, and, well, I think you see where I'm going here. There are a few characters which were given names only out of necessity. Each character was, however, given a very individual personality - usually defined by a single dominant trait (Black Mage is murderous, Fighter is stupid, and Red Mage is... a D&D manual? I don't know what the word would be). The story merely serves as a backdrop to highlight the exchanges between these different personalities.

And the exchanges are funny. Typically. The comic is best in the beginning, when characters are being introduced and they're still very fresh and interesting. As things progress, though, things start becoming predictable and the comedy becomes repetitve. There are still a good number of funny lines (the reason I haven't stopped reading), but it's certainly not as inventive as it was. This is probably the reason a lot of people I know stop reading the comic after a while.

The pacing suffers sometimes, too. Every so often, Clevinger will stick around in a story arc longer than it is interesting. For the most part this isn't a problem, but sometimes it will be very noticeable. The slightly bigger problem is that the story frequently returns to characters/gags that weren't interesting in the first place. Thus, even the repetition isn't as interesting as it could be.

It feels like I've said a lot of bad about 8-bit, but the comic has remained in my Favorites for a reason. It's got a nice charm about it, and I enjoy the dialog and humor even if things do sometimes trudge along. With over 700 strips, it makes for an entertaining read. It also adds to the Tuesday, Thursday, Saturday lineup quite respectably.

.NET and Tao

2006-08-28T13:48:00.000-04:00

In preparation for the release of the XNA Game Studio, I have been taking a serious look at .NET. Thus far, I'm very pleased. The introduction of memory management is always a welcome change along with the ability to create robust GUI's almost effortlessly. There are a few things that I find mildly distasteful (the get/set paradigm as presented in .NET), but those are stylistic quibbles that have no place in real language analysis.

I began with two rudimentary exercises: the first was to port select bits of my C++ game engine over, and the second was to get an application using the Tao framework running. Aside from some minor syntax struggles, the first task went relatively painlessly. In fact, I found that I was reinventing functionality that .NET already had built in - .NET comes with a fairly robust event management system that I had to implement myself in C++. The second task was finished before I realized I had started. Five minutes after downloading the Tao framework, I had an OpenGL window running that behaved quite nicely with my external GUI widgets. Never again will I have to fight with GTK or FOX to put a GUI over my OpenGL applications.

I have a few more things I want to do before I dive into serious application development with .NET. First, I want to make some form of editor - probably a map editor for Parodica. Second, I need to become familiar with DirectX - something that will be necessary when the XNA Game Studio hits. I'm really starting to like this language, though.

Web Comics Day 1: Concerned

2006-08-27T13:09:00.000-04:00

Over the course of the next few weeks, I'm going to provide an overview of the web comics I read regularly. Today we'll kick things off with Concerned: The Half-Life and death of Gordon Frohman.

The moment you look at the comic, you'll realize one thing immediately: every panel looks like a Half-Life 2 screenshot. You'll realize this because that is exactly what's happening. On the back-end, Concerned uses Garry's MOD to pose the models of Half-Life 2 any way the artist (Christopher Livingston) wishes. This offers a relatively unique flavor to the comic and reinforces that the comic takes place in the Half-Life 2 universe.

The story follows the tale of Gordon Frohman, an honest, hard-working citizen of City 17 who gets thrown around the world and mixed up in the affairs of Gordon Freeman. As expected, Frohman is an anti-Freeman - a hapless, bumbling, ignorant fool who fully supports the Combine efforts and feels friendly with Dr. Breen. While this is something of a cliche comic hero role, Frohman still entertains and brings some great comedy.

Unfortunately, there is no real supporting cast to speak of. You'll see some of the characters from the game, but they mostly play bit roles and don't last more than a few strips. Gordon's brother has just been introduced, and he seems like a very interesting character - hopefully one that lasts a while.

The pacing is excellent. Everything flows well, and you hardly notice that Gordon's been through most of the world when he winds up back in the city just in time for Freeman's arrival. Practically every strip has a clearly defined punch-line, and they are generally all chuckle-worthy if not better. You never get bogged down in a boring story arc, and things are always fun and fresh. The comic updates every Tuesday and Thursday and rarely misses on updates.

I strongly recommend this comic. It has been an excellent piece of work, and I look forward to whenever it gets updated. Go read it.

An Experimental Exercise in Good Development (or Geek Kung-Fu)

2006-08-24T01:23:00.000-04:00

This post is about exactly what the title describes. I'm starting an experimental project in development. I'll outline below the sort of techniques I'd like to exercise during the experiment, as well as the conclusions I hope to draw from this "project." I plan to start a new (actually, an old) software project. The medium for this experiment is the creation of a raytracer. This however is just the medium for the requirements I hope to exercise. By the end of this project I hope to have tried the following:

Create and use a subversion repository for source control
Configure and use Cruise Control as a continuous integration (CI) server
Utilize a dynamic plugin architecture in the design
Design a display agnostic renderer (e.g., no dependency on OpenGL, Quartz, etc.)
Speaking of Quartz, let's write this baby in Objective-C for OSX
If at all possible, make use of Core Data
Adopt Test-Driven-Development methodologies for all development
Document the architecture during the TDD process

As you can see, these are obviously developer requirements aimed at orienting myself with new technology and development methodologies, not real requirements for a product. Essentially, this project is just an excuse for me to practice a more agile type of software development. And, to be a better blogger, I plan to share my progress in as much detail as possible here.

I also hope to document the organizational process I plan to follow. For example, I capture a lot of quick thoughts on paper, and that paper ends up being scattered about my desk at work. I'd like to keep an "inbox" on my desk that all ideas get tossed into, even if I would normally just throw them away. Then, at the end of the coding session I'll inspect all these documents to create a coherent statement of my progress at that point. I don't know if its going to work out, but that's why this is an experiment.

I have cheated slightly. I decided to start out yesterday evening, and get the SVN and CruiseControl configurations set up. Originally I wanted to have Cruise and SVN set up on my Linux box, leaving the entire CI process to it. However, while planning this out I realized that "Nothing Works with a Mac," meaning that I won't be able to compile my Objective-C code on a non-Mac platform. I technically have my G4 box lying around that has the Apple Foundation framework on it, but I don't easily have a network connection for it. So, for now, I think I'm going to rule out the continuous integration.

Anyway, I hope to have a post up soon describing my first small, informal design session.

Top Honors

2006-08-17T14:15:00.000-04:00

The Duelist has made it into round two of the Experimental Gameplay Competition! This has two important implications: (1) I will be receiving a free RedOctane DDR dance pad, and (2) I will have approximately two weeks to create The Duelist utilizing that pad. Between programming, art, sound, and content generation, it's not going to be an easy task - especially since classes start up soon - but I have no intention of letting silly things like "obligations" or "sleep" get in my way.

The Duelist

2006-08-05T12:24:00.000-04:00

Here is the design I submitted for the RedOctane competition over at the Experimental Gameplay Project. Keep in mind that it's supposed to be brief (otherwise I would have gone much more in depth). Tell me what you think.

Game Title: “The Duelist”

Background:
Welcome to Sententia University, a school which focuses on training telekinetic power while offering 'normal' classes to disguise itself from the public. The school has one simple policy: to graduate, you must defeat the Dean in a battle of the mind.

A duel takes place over a series of multiple turns. Each turn, a telekinetic technique is revealed. The player must best his opponent with this technique to win that turn. When a player has won two more turns than his opponent, that player wins the duel.

However, you do not start out knowing all the telekinetic techniques. To learn techniques, you must beat the professors at the university. You can also go around challenging other students to practice, or you can simply talk to them to learn all the gossip about the school. Only when you have learned all the techniques can you challenge the Dean.

Use of the pad:
While not dueling, the player uses the pad to navigate the school in a menu-like fashion, where the player chooses which hall he wants to visit and which student/professor he wishes to speak with or challenge. Up/Down choose between menu items, and Circle selects an item.
While dueling, each turn is essentially a fast-paced mini-game which requires a different use of the pad to triumph. Potential techniques follow:

Mind Hack (learned from the Computer Science professor): The first player completes a sequence of steps. The second player then must match this and add a step to the end. Then the first player must match this and add a new step. This back-forth continues until either a player missteps or a player cannot complete the sequence within the specified time limit (approximately 5 seconds, though this number will be tweaked as gameplay is tested).

Lightning (learned from English professor): Two buttons are shown. Each player must press these buttons in succession as fast as possible for a given length of time. The player who presses the fastest wins.

Total Recall (learned from the History professor): A random sequence of steps is revealed for a short time and then hidden. The players must then hit as many of the steps as they can remember. The player who hits the most steps wins.

Speed Demon (learned from the Phys Ed professor): Approximately 30 steps are shown. The player who completes all the steps first wins. In the event of a mis-step, the player must start over.

Precision (learned from the Art professor): Each player has a meter that starts to rise and fall at varying speeds. The player can hit on any button to stop the meter. The player who stops the meter closest to the top wins.

Quick Draw (learned from the Math professor): Players must wait until a certain button pops up on the screen. The player who hits that button first wins.

(note: the above use the term 'each player', but in Single Player, the 2nd player will be the computer).

Modes of play:
Normal versus Extreme mode (available for all the following modes): In normal mode, only the 4 direction buttons are used. In extreme mode, all 8 buttons can be used.

Story mode: Talk to students, challenge professors, and eventually take on the Dean himself.

Multiplayer 1: The Mind Hack, Lightning, Total Recall, Speed Demon, and Precision duel types can easily be adapted to using one pad, in most cases by simply adding a timer to determine who completes what task the fastest. In this case, players take turns using the pad.

Multiplayer 2: The game easily facilitates multiplayer challenges where two players (each having his own pad) can duel against each other.

Experimental Gameplay

2006-07-29T02:25:00.000-04:00

The Experimental Gameplay Project has announced a RedOctane competition challenging competitors to come up with a non-dance game that utilizes the DDR mats. I'm rather interested in trying this, but I have thus far been incapable of coming up with good ideas.

While we're on the topic, I'm a big fan of what the Experimental Gameplay Project is about. It started at Carnegie Mellon as a project where the participants would attempt to create a new, original game each week for a semester. It has since grown to showcase games by other people and get more community involvement.

72HGDC Status: Complete

2006-07-17T23:55:00.000-04:00

The 72 Hour Game Development Competition recently concluded. The theme for this competition was "Retro," meaning that each game had to incorporate something retro into it somehow. Although the judging has not completed yet, I feel it appropriate to summarize the results.

First, my entry: trash. There's no way to sugarcoat it. The concept had potential, but schedules got crossed, morale declined, work ethic dropped - that old chestnut. The finished result was not only less than the original goal - it was less than a game. I provide that link only for reasons of completeness. Don't play it.

Now on to entries that matter. For my money, TimeTrax submitted the best entry - a terribly unoriginal Breakout clone that still manages to break out the style and flare. The GameDev Guys, a typically stellar group, submitted a racing game which had a lot of style. It was not up to their usual standards of excellence, but it was still fairly fun to play for a while. On the other hand, Team Calypson submitted an awfully good racing game (we got a few of those for some reason) which turned out to be one of the best entries by far. It comes highly recommended. Teams Kompression and M.E. both submitted two old-school games that used vector art to get that retro feel. They are also both extremely difficult, and M.E.'s in particular is addictive.

Those are the only ones I'm going to highlight in this space, although there were over twenty entries which all deserve some attention.

Paul Robertson

2006-07-13T22:56:00.000-04:00

If you are unfamiliar with the works of Paul Robertson, you ought educate yourself. The man can arrange pixels in ways that are majestic.

Why bother...

2006-07-11T20:19:00.000-04:00

trying to play guitar?

72 Hour Game Development Competition

2006-07-08T20:10:00.000-04:00

We're less than a week away from the next 72 Hour Game Development Competition, a competition that challenges contestants to create the best game they can in a 72 hour timeframe. Originally a product of my boredom one lonely weekend, the competition has lasted over three years and inpsired well over 100 small games. I've had to sit out the last two competitions, but I'm looking forward to finally creating something again.

To give you an idea of how the competition works: for the next week, participants vote on a theme that the game will have to follow. When that week ends, the theme is announced, which signals the beginning of the actual competition. Participants then have 72 hours to create a game - starting from scratch - that follows that theme. At the end of that time, all entries (finished or not) must be submitted for peer judging, and the results are later announced.

We typically have between ten and thirty teams participating, and this time we're looking to have about fifteen. Originally, most of the participants came from Pixelation (which no longer exists, but most of its members moved to Pixelopolis). Now we get contestants from all over - GameDev, DevMasters, LudumDare, and wherever else we can think to advertise. All are welcome, and we always have a healthy mix of programmers, artists, and musicians.

It's a whole lot of fun, and I welcome anyone who has the time to participate. Barring that, you really oughtta check out the entries we get. We've had some truly fantastic games submitted.

Safe Cracking

2006-07-07T22:17:00.000-04:00

It was my rather dubious task to break into a computer at work so that I could make that computer accessible to a new employee. There was no password available, so the only options were to either reformat the computer, retrieve a password, or clear the current passwords.

Reformatting the computer was not an option, which is unfortunate not only because it was the simplest route, but also because the computer is running Windows 2000 when it should be running XP. Retrieving the password proved difficult. The original computer's owner had completely forgotten the old password, and the administrator password was not consistent with all the other administrator passwords in the lab. I was left with the task of either cracking the password or simply clearing the old passwords.

Clearing the old passwords ended up being my solution, and I largely recommend Emergency Boot CD for the task. This program has many other purposes - backing up data, changing settings so that a computer can be fixed - but I can't say anything about that. For clearing old passwords, it worked beautifully. The only snag occured when I realized that Windows 2000 does not store its registry data in Windows/System32/config; instead, the path is Winnt/System32/config. After overcoming that problem, I was able to reset the user passwords and grant myself administrator access.

And then I went on a power trip and proclaimed myself king of the lab, which only got worse when I decided the lab was not grand enough. King of all creation has an awfully nice melody to it.

ePSXe

2006-07-06T22:49:00.000-04:00

In the interest of establishing street cred in this illustrious space, I'm-a kick things off old school: ePSXe.

ePSXe is a fully functioning Playstation emulator that allows you to play PS1 games (even those copied illegitimately) on your PC. Its best feature is that it allows me to turn my laptop into a portable PS1. Couple it with some PSX->USB controller adapters, and the experience is complete.

Of course, the emulator isn't without its problems. Initial setup can be a pain, requiring you to download a few plugins and play around with settings before things work. Even then, the program does not close properly on my system. I have to close it manually via the task manager. A small price to play for such a handy toy.

Speaking of PSX->USB controller adapters, I don't know that I can recommend the Radio Shack variety. First, they won't work acceptably with a DDR pad - the way they handle input makes them incapable of registering when you step in two opposite directions at the same time. Second, we've had some problems getting two to work at once in Linux. Granted, this is probably our own fault, but I have no significant cause to blame myself when Radio Shack is a monstrous corporate entity just begging to be hated.

Two Turntables and a Set of Headphones

2006-07-06T12:22:00.000-04:00

I love music. I love listening to music. Thus, I have an iPod. I really can't recommend the little gadget more. I know a lot of people recommend other Portable Media Devices (PMDs, foo) for less money that have more features, but I'm a bit of an Apple fan-boy.

Also, I had an issue about a year ago. My iPod went wonky, but the service was excellent. I simply visited a somewhat-nearby Apple Store, ran the diagnostic test to show the customer service rep there was an issue, and was handed a new iPod on the spot. No additional questions.

However, I didn't get a new set of headphones. And after countless trips (to work everyday, two trips to Japan, two trips to Las Vegas, etc.) the little white suckers finally died. Actually the cable frayed and I lost signal to the left earbud, but they're dead to me. I've read a lot of articles where people are openly hostile to the iPod earbuds, but they were adequate for my listening preferences. However, I didn't feel like shelling out $40 for the Apple replacements, nor did I find it worth the money.

After suffering several days without my iPod I finally made a trip to Wal-Mart to buy some cheap headphones. I saw several on the shelf, but finally decided on a $5 pair of Koss earbuds. I returned to work after lunch excited to listen to my stash of mobile music once again. This was not the case.

I attempted to place the audio delivery mechanisms into my ears, only to find they were the worst crafted piece of equipment ever designed. I said it. Ever. Imagine trying to ram two 50 gallon drums of oil into your admittedly smaller ear canal, then you'll begin to feel my pain. So deprived was I of my music that I continued my attempts. Only to achieve very sore ears and a pissed off attitude. The pain in my ear was only rivaled by the aching of my soul for my tuneage.

At that moment I was ready to drop upwards of $50 on a new pair of earbuds. However, I was damn well going to do my research on earbuds if I was plunking down that much scrill. To my surprise, there was a definite lack of low to mid-range earbud reviews. There were plenty of reviews on the ridiculous Shure earbuds, but $100 and more was a little excessive.

After several diligent Google searches to no avail I came to the conclusion that I still hold to be true; low to mid-range earbuds are all about the same quality. For a cheap set of headphones with such small components, there's only so much you can do. Except for Koss, they can still manager to fuck up hardcore.

When I purchased the aforementioned demonseed headphones I also saw a pair of $10 Sonys, but decided to pass on them since I was probably going to buy a more expensive pair of Sonys. But, after I had my epihpany I decided to just drop the $10 on the earbuds and see what happens. That was a good idea.

The earbuds I picked up look similar to this, without the volume control:

These little $10 earbuds were well-worth the price. I think they even sound better than the iPod headphones I had before (not that I was claiming they were all that great). My friend that recommended the Sonys before was pushing me to get the Shures for his own personal agenda. Since his efforts failed, he decided to pick them up on his own. The judgement? The Shures do sound better, but the improved quality doesn't justify the price. So, this isn't really a case of "you get what you pay for," but more "do your homework."

Your Own Personal G-Dub

2006-07-06T09:48:00.000-04:00

Trubie showed me the way.