Fuck Seabiscuit

I swear, that is the boringest snoringest movie I have ever seen in my mercifully short life. I mean, yes, the sets are very beautiful, but the fucking movie is about a horse. It's like the living, sweating equivalent of NASCAR. Hey Gary Ross, you need to make it clearer to people why a horse is interesting, especially to people like me who do not give a shit about how fast things can go around in a circle. Like, what about Jeff Bridges' dead son and his fucked-up marriage? What about the fucking jockey who's blind and has scabies? What ever happens to his parents? What about Chris Cooper's character? What about depression-era America? What a bunch of shit. God bless you, Seabiscuit. We didn't fix you, you fixed us. And the Work Projects Administration. That also fixed us. Come to think of it, you are just a fucking horse.

The more I read these IT trade magazines, the more hideously depressing they sound. People are inventing all these languages and platforms and blah blah blah and they all sound so stupid. I mean, who the fuck Christ needs another god-damn virtual machine, much less one based on Windows -- as if Windows gave you a reasonable abstraction of your computer. It won't even let you kill your own processes. It must be that all these creeps get hired as economists or Financial Professionals or some bullshit like that and then they have to learn how to program, and this is what they come up with. The World needs more actual by-choice Software Engineers writing software that is consistent with good ideas about the way computer systems ought to behave, and not about a billion more C++ export macros that make your palm pilot work with your Blackberry or another custom C++ compiler for Windows that encourages you to make unbelievably stupid design mistakes but comes with a Macromedia Flah IDE. I swear, the syntax is so shitty and the library overhead so huge in C++ I'm amazed that anyone gets anything done in it, ever.

How awesome is this, by the way? Also, how long before we set up strategic war bases on every planet in the solar system. Then we'll finally be Safe from a bunch of malnourished Arabs with box-cutters.

I've been tearing my few remaining hairs out over software design for the past week. Basically, all my client-server talking functionality was based around this XML DTD called "openrpg_message," which was an encapsulation for a bunch of type / value pairs. So a sample transmission from the client to the server might look something like:

<openrpg_message>
<content type="foo" value="bar" />
<content type="jibber" value="jubber" />
</openrpg_message>

Unfortunately, this format is insufficient for a lot of functionality that still should be using this type of messaging. For example, when the client sends an administrative command to the server -- a non-game command, like "send a private message to this user" or "show me who else is logged in" -- it should use the openrpg_message format, and so should the response. However, using the current DTD, there's no way to express an arbitrarily large set of discretely-indexable data. That is, suppose a user asks for a list of something, like a list of help commands or a list of other users on the server -- there's no good way to return that data, except as a comma-delimited list of values within a content tag. And what if each item in the set needs to have a corresponding item in another set. Extending the DTD is not a huge deal, except that I've written a bunch of functions that convert the incoming message to a hash (of all the type / values pairs), so that adding data types to the DTD would require a change in how I handle hashes. I was getting real depressed about having to do something that just didn't seem right, like adding a "list" field to my hash struct. Then it hit me -- I should be wrapping the entire message in its own struct. So now I have something like:

struct openrpg_common_message {
struct openrpg_common_hash *hash
struct openrpg_common_list *list

And in the future...

struct openrpg_common_object *object
};

So every message that gets sent will at least have a hash, since it is required to have at least one content element, but it might also have a list of values and/or an object -- so it's now suitable for "add_object" messages sent to the client. Not a 100% beautiful fix, but a fix. No doubt I'll have to revise it all again later.