sharpoblunto

The ‘code poet’ or (shudder) ‘rockstar developer’ terms seem to have caught on because we software developers view ourselves as creative, and that art is seen by many as the highest form of creativity. On the record, I don’t consider myself a code poet. Don’t take this to mean that I am not passionate about what I do – I love software development and I strive to be the best developer I can be. Its just that in my view, poetry is art, and for the most part code is not, cannot be, and should not be considered art.

Despite the notorious difficulty of defining what art is, I’m going to have a stab at a vague definition for the purposes of explaining my position. For me art is something produced for the purpose of encoding an emotional state in a physical form.

What I mean by this is that art represents a class of programs designed to be run inside our minds. The ‘code’ for these programs are written in the form of oil on canvas, music, sculpture, or any number of other forms. The physical artifact when viewed sets the program running which depending on the intention or skill of the artist, will manipulate our emotional state in certain ways.

Under this definition we can see that everything can exist on a spectrum based not just on its emotional effect, but on its purpose. If we think about literature, one could place dictionaries at the far end of the non-art spectrum, as while certain parts of the text may invoke minor emotional responses, it is clearly not a dictionaries primary purpose to do so. At the extreme other end of the spectrum we could place poetry, which while it may have some practical secondary purposes, its primary purpose is to invoke some strong emotion in the reader.

So why do I exclude code from the artistic realm if I’m basically saying that artists are creating programs? The key differences lie in where these programs are executed and the purpose of these programs. Pure art has no other real purpose other than to hack our neural wetware into feeling a certain way. Software is concerned with the much more practical purpose of manipulating bits inside a computer. The output of the software may very well be art (I’m definitely in the games as art camp), but the code that creates the output is not art any more than a paintbrush is art, they are simply intermediaries toward a possible artistic end point.

In addition to my position regarding art, I also think that considering ones self as a code poet or more generally an artist when creating code has potential negative consequences. The reason I say this is that pragmatism and compromise are seen as being undesirable when creating art, however they represent key aspects of effective engineering and I can’t see how you can effectively reconcile the two.

</rant>

Just some quick updates and cross promotionalizing, I’ve been doing a lot of work recently in generating procedural content for Junkship, I’ve written a post on what I’ve been up to on here. Also released a few updates to my gamedev framework MGDF (which coincidentally Junkship is using). Apart from that the main thing sucking up all my time these days is finalizing the details for my move to San Francisco for my new job in January. There really is a huge partially hidden tree of dependencies that have to be satisfied when moving your life halfway across the world, the complexity of which can only become obvious the further down into the details you delve.

Things are happening over at junkship.net for the first time in a long time (Well they will be soon!) I’ve finally got my homebrew game development framework (MGDF) to the point where I think I can release it (as an alpha) and more importantly actually start building a game on top of it.

MGDF is a framework built to focus on a couple of areas that I feel are neglected in most existing frameworks, in particular ease of distribution, updating, and ensuring all the boring but useful stuff gets done properly (logging, initializing DirectX, error reporting etc.) To achieve this, MGDF acts as an IOC (Inversion Of Control) container that loads up your game logic and calls into it at appropriate times during the rendering and game simulation loops (Render, Update, Save, Load, etc.) The advantage of this approach is all the audio, input, file-system, and DirectX rendering objects are set up by the framework. All you have to do is provide the code which actually handles the game logic and rendering (the fun stuff!)

MGDF games are distributed as .mza files which are effectively zip files containing the game logic, the game content (in the form of compiled c++ dll’s), and some metadata that the framework needs. These packages can be published online to an MGDF game source (An online MGDF game repository) which allow users to download the game, and will allow the framework to check for and download updates for that game. Anyone can host or run a game source, and it uses a JSON API to allow easy interoperability and the ability for alternative game source implementations to be written (The reference implementation is written in ASP.NET).

As a developer, pushing out updates to your game is just a matter of uploading the newer version to the online game source (you can also create update packages which contain only the differences between existing versions to allow for smaller update files). For developers wanting to publish non-free games the Game Source API has in built security controls that allow you to restrict access to certain game downloads to a set of authorized users (There are no forms of DRM built into the framework though, and there never will be :))

MGDF also has an optional statistics collection service (which is entirely opt-in by the end-user) which allows developers to collect statistics information on how users play their games. These statistics services also use a JSON API and can be hosted by anyone (there is no centralized stats tracking… no phoning home)

Its all pretty raw at the moment, and while there is a very basic SDK with a few docs that I’ve included, its all very much alpha software. I intend to use MGDF in my upcoming projects, and if there’s any interest by developers out there, I’ll develop the SDK further. MGDF is released under the MIT license and the source code can be downloaded from github.com (see www.matchstickframework.org for more details)

So anyway, after winding our way through the ins and outs of MGDF, back to the original news - the changes over at junkship.net. As you may or may not know Junkship is a project that some friends and I had been working on on and off for some time, though for various reasons there was never really any concrete progress made. However, now that MGDF is in a workable state, it is now my intention to give Junkship a bit of a reboot and actually start some proper development. The main change is that the game is going to have less focus on a pre scripted story and be more heavily based on crafting, procedurally generated content, and hopefully multiplayer. I guess this reflects both my own changing taste in games, but also a sense of pragmatism as to what a small indie team is capable of accomplishing.

Anyway if you want to know more I will be writing up more details on the junkship.net blog, which I plan to use more as a dev-diary from now on (I guess I should also give the Junkship site an bit of a revamp as the content is pretty out of date). Rants and non Junkship stuff will still be posted here though :)

As someone who is keenly interested in all things gamedev and indy gaming related it was pretty much destined that I would end up playing Minecraft, Despite this I tried to stop myself due to its widely noted extreme addictiveness. However in the end the draw to try it out was simply too strong after watching one too many awesome Minecraft adventures on youtube. Below is the video aftermath of my month long Minecraft construction spree.

For me Minecraft represents the first sandbox type game without a strong central narrative that I’ve really ever been interested in, and putting on my gamedev hat it’s also the first game to really sell me on the idea of procedural content and player created narratives. Up until playing Minecraft I’ve always felt that open world games were somewhat lifeless, dull, and pointless (this includes games that try to shoehorn a narrative over the top such as the Grand Theft Auto). Minecraft turns this into a strength rather than a weakness. Minecraft places you in the middle of a desolate, lonely and beautiful world and challenges you to make sense of your surroundings and remake the world as you see fit, and unlike other open world games you are given the tools to do so in a real and meaningful sense.

Do you ever get the feeling that you are a subject in some sort of roundabout moralistic parable that is designed to encourage humility and patience in others? For me the most probable cause for this mindset is when a seemingly reasonable task becomes unreasonably complicated and that in finding a solution for the said task I have forced to become a more rounded, knowledgeable, and enlightened individual. Often in these cases, the cause of the problems is due to someone else’s laziness which further enforces the feeling that the moral of the story is that in a greater cosmic sense, slacking off will only create more work for others, in some form or another, at some point in the future.

Changing tack slightly, I find the worst thing about developing a large piece of software is the nagging feeling that somewhere in the core foundation of your application is a subtle design problem that is going unnoticed (Be it a performance issue, or a platform issue, or simply an incorrect assumption as to what is and isn’t possible) and that at some point in the future it is going to rear its head as a unsolvable problem that is going to render the entire application as a worthless piece of junk. Its more an unfounded nightmare scenario because thinking rationally, I can quite quickly evaluate the probability of this happening as remote. The reason being that up until now I have never experienced such an issue, and in the end every bug I’ve ever had in software was solvable or could be satisfactorily worked around. However, just because something hasn’t happened yet doesn’t mean that it can’t happen.

Now to subtly link the two previous ideas together in a thrilling conclusion filled with sage wisdom, I get onto the problem I had today. I was finding that my game engine was taking over 30 seconds to load when using the Visual Studio 2008 debugger. Of course this made debugging an incredibly frustrating exercise in tedium, and because this is a project that I work on haphazardly in my spare time I wasn’t sure it this was a new issue, or if the engine had simply been getting slower and slower and I had just never noticed. This was this as an incarnation of the nightmare scenario, was my game engine just a slow and bloated piece of shit? Well thankfully no (not yet at least anyway). It turns out that having a bunch of break points set (possibly old invalid ones etc…) causes visual studio to hang for an arbitrarily long time until it gets its shit together and actually loads the program for debugging. Why it does this… no idea (though it reeks of slack coding), but the solution turned out to be simple. Click Debug->Clear all breakpoints and voila, the engine loads up in less than a second.

The ironic thing is is that in wrapping both the problem and solution for this issue in a pile of worthless prose, I have effectively made it much harder for anyone else who is looking for a simple solution to find it, and hence I am perpetuating the very feelings of frustration I was complaining about earlier. A sobering thought indeed, but for better or worse its written now, what would be the point of deleting it?