Since we last spoke

Posted on Nov 4, 2012 dotnet MGDF programming

I wrote recently on junkship.net about porting Junkship to use DirectX 11. In order to do this I also had to port my game framework MGDF to use DirectX 11 as well. I’m happy to announce that the latest MGDF SDK is now available from matchstickframework.org (you can also download the source from GitHub if you’re so inclined). In addition to DX11 support to this I added a whole bunch of fixes and new features including:

  • An improved Save game API that makes it impossible to corrupt existing save games if a save fails partway through.
  • An upgraded input system using RawInput for mouse and keyboard input
  • Now using JSON for all configuration files
  • Game updates now specify when they want to upgrade the base framework version (framework updates are no longer centralized – each game decides for itself what framework version it wants to use)
  • MSAA settings are now split into two separate settings, the back buffer MSAA level, and the recommended render target MSAA level. This allows more flexibility for applying MSAA specially when doing post processing effects.

NOTE: The old DirectX 9 version is still on GitHub but on the DX9 branch of the MGDF repo. This version is now deprecated and will not receive any further updates.

In other news, twitter announced a few months ago that with the release of their 1.1 API that the 1.0 API is officially deprecated and will be shut off early next year. In addition to this all requests to the new API have to be signed using oauth 1.0. In order to ensure that the twitter control above continues to work I had to update the code to use the new API and to generate signed requests. In doing so I wrote a small C# library to generate signed requests to the twitter API, its available on GitHub for anyone who’s interested in checking it out. Using the library is pretty straightforward as shown in the example below.

//use your real Twitter API tokens here

string consumerKey = "XXX";
string consumerSecret = "XXX";
string accessToken = "XXX";
string accessTokenSecret = "XXX";

TwitterAPI api = new TwitterAPI(consumerKey,consumerSecret,accessToken, accessTokenSecret);

//generate a signed http get request for the specified twitter API URL
HttpWebRequest signedRequest = api.GenerateSignedGetRequest("https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=mr_sharpoblunto");

//you can now use the signedRequest object to query the twitter API
HttpResponse = (HttpWebResponse)request.GetResponse();

I also took the liberty over the last couple of months of moving the source code for most of the apps hosted on this site (along with some other random bits and pieces) over to GitHub. They range from a Lua based web MVC framework prototype, to remote automation servers, to website monitoring tools. Check out my GitHub page if you’re interested.

I’m not a rockstar or a poet (at least while coding)

Posted on Aug 15, 2012 ramblings

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>

Strange times

Posted on Nov 13, 2011 ramblings

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.

Coloring the void

Posted on Jun 21, 2011 ramblings programming

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 :)

Welcome to sky Valley (otherwise known as what I spent last month doing in Minecraft)

Posted on Dec 12, 2010

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.

Latest tweet