sharpoblunto

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?

Public transport provides a unique and mostly missed opportunity to engage in meditative contemplation and compile strange internal narratives. Obviously some trips are more interesting than others, and trips on dark rainy nights are the most interesting of all.

This trip starts with one of those oddly insignificant and yet poignant moments, a goodbye to a pre-friend. When I say a pre-friend, I mean someone who you meet during a social activity or obligation where you don’t really know anyone else, someone who after said activity you are unlikely to ever see again. During this brief time you get just enough time to get past some of the initial formalities of talking to someone, the who are you’s, what do you do’s etc. and strike up somewhat of a pre-friendship, have a few laughs before going your separate ways shortly after. Its more than a quick chat to a stranger, but its not enough to register as anything more significant. Now goodbyes are always anticlimactic, but these are particularly so. You exchange a few pleasantries and have one of those awkward well, this is it, see you around… kind of moments, and its all over.

Its an interesting microcosm of a real friendship, but the goodbye has quite a different feeling. The emotions of a real goodbye are much stronger and seem to weigh the experience down. The feeling of these goodbyes leaves one feeling surrounded by a vague halo of positivity, that unmistakable feeling that the world is a pretty good place.

Then you don your headphones and hit the play button, isolating yourself from the sounds of the real world, isolating that feeling - that moment in time for a little while longer. You ride slowly through the neon rain washed streets and let your thoughts wander with the mood of your music, music which you’ve heard before but now seems to sound a little different. Like all things, the feeling will eventually fade away, but its imprint will remain in the music, and in future, every time you listen to it you’ll always be taken back to that unique place and time.