So the Just Cause 2 Multiplayer project had a 48 hour beta test this weekend which I participated in, and as you can imagine if you’ve ever played Just Cause 2, it’s absolute mayhem. However even though there was typically 500-1000 people online at any one time, as soon as you left the spawn areas and some of the more popular spots (like the ever chaotic airport) the numbers started to thin out and the atmosphere really changed. Unlike the single player game there are no NPC’s so things start to take on a post-apocalyptic feel with empty villages and highways punctuated by the occasional roving gang of road warriors or a lunatic in a fighter jet. This got me thinking, what if I took this idea, and tried playing it like a survival horror game, assuming that all the inhabitants (or most of) had been infected with some horrific zombifying affliction that turned them all into psychotics bent on total destruction (not really far from the truth). So began my epic quest to escape from Panau Island…

I started off on a calm evening in a resort nestled at the base of the Berawan Besar Mountains. My initial plan was to find a fast car and follow the coast northwest, tracking around the mountains before turning south and heading into Panau City to see if there was a way off the island at either the international airport, or the city port. However that plan was dashed the moment I set foot in the car park as I was set upon by an attack helicopter.

Dodging the rockets I commandeered a Civadier 999 Cabriolet and tried to shake the helicopter. I figured If I could get onto a highway I could probably outrun the helicopter, or at least make chasing me a boring enough exercise as to divert his attention elsewhere.

However I hadn’t counted on the Civadier’s terribly twitchy handling which meant that on my first high speed turn I ended up hitting a bump in the road and hurtling off a cliff, narrowly avoiding landing in a river. Luckily this misadventure seemed to satisfy the attack helicopter pilots desire for carnage and he moved off in search of other targets.

After swimming across the river, I made my way back to the resort and this time got myself a Titus ZJ cabriolet in British racing green and after hearing the helicopter in the distance patrolling the coast, decided to change my plans and head southwest into the mountains. I figured rather than braving the coastal highways I would encounter less resistance by cutting through the mountains and looping around the southern river delta, before heading north through the Lautan Lama desert and finally crossing Panau Tengah bay to get to Panau City.

I saw a few people in the distance as I made the ascent, but by and large the biggest threat was the mountain roads themselves.

As the afternoon headed toward evening I was approaching the summit. I passed through a couple of deserted alpine villages before finding out why no-one bothered to drive this way through the mountains - I found myself at a ski resort at the top of the mountain with no road down except for the ski slope itself.

After consulting the map it seemed like a high speed burn down a ski slope in a rear wheel drive sports car in failing light might not be such a bad idea after all. It was certainly the most direct route, and it would ensure that I would arrive (assuming I arrived at all) at the base of the ski resort in the dead of night from an unexpected angle, meaning that I would have a better chance of slipping by anyone waiting at the resort complex.

After some masterful driving I found myself near the base of the slope looking down on the ski complex. To my dismay it turns out my paranoia was well founded and there was a faction blockading the road heading out of the ski resort. This situation became somewhat worse when after sitting a little too long on the exposed slope I found out they were the proud owners of a tank and I noticed a barrage of shells heading in my direction. I gunned the Titus down the slope into a high speed slalom to avoid the shells. As I headed toward the village I realized the blockaded road out was to the right of the valley but that it curved across to the left as it snaked its way down. I figured I could go off-road to the left and keep the buildings between me and the tank and meet up with the road at its leftmost edge, bypassing the blockade.

This mostly turned out to be a good plan, except for the part where I flew off an embankment in an uncontrolled spin. After a few mid air somersaults I miraculously landed mostly intact near the road and at such speed that the tank was unable to draw a bead on me before I got back on the tarmac and headed off down the road toward the river valley between the mountains and East Tanah Raya.

It was good to be on flat roads again as I cruised south with the sun rising overhead. Unfortunately this peaceful respite didn’t last long as I soon heard the sound of a distant helicopter closing in. I decided to push my luck, hoping the helicopter would just ignore me and continued my planned course across a narrow bridge that would then allow me to cut across the islands at the southern end of Panau Tengah Bay. The attack helicopter however had other plans, and as soon as I hit the bridge, so did a hail of rockets and gunfire that left my car a slab of flaming wreckage. I managed to leap free and ran into the nearby jungle on the other side of the river. As I sprinted through the jungle the helicopter continued firing, sending trees crashing and exploding around me as I searched for cover. I soon came upon the walls of an abandoned military base, so I scaled the walls and took refuge under the largest building I could find.

As the rockets fell overhead it became apparent that this guy wasn’t going to be satisfied with anything less than a fight to the death, so I began dodging between the buildings and engaging the helicopter with small arms fire. After my counter attack the pilot made a mistake and got too low to the ground trying to get a better shot at me. His tail rotor clipped a tree, which sent the helicopter crashing to the jungle floor. Relieved, I took a moment to get a sense of my surroundings – there were a few military jeeps parked around me, but unfortunately the complex gate was closed meaning I couldn’t take one.

Having no other choice I backtracked my way out of the jungle and made my way back to the river. I didn’t remember seeing any settlements nearby so I hopped in an abandoned fishing boat and continued on my original course.

The next morning, after sheltering the night in a small fishing village, I hiked down the road a couple of miles and found a small airport. Not knowing how to fly a plane (lets keep up the suspension of belief eh?) the light aircraft were not much use to me, so I picked out a Hamaya Cougar 600 road bike and left the area trying not to gain the attention of the locals.

I began heading west toward the river delta at the southern end of the Lautan Lama Desert. I saw the occasional sport scar cartwheeling down the road toward me, and took a couple of tumbles along the narrow jungle roads, but made it to the edge of the desert at the northern end of the Senjakala Islands in one piece.

My bike wasn’t exactly in good shape at this point so I stopped at a small town to get a new ride. Unfortunately as I sat on the side of the road checking my map after acquiring a shiny new Mancini Cavallo, I was rammed at high speed by one of the local road warriors which sent my car flying into the nearby river.

Not satisfied with nearly drowning me he then proceeded to try to run me down in a speedboat before tiring of my continued survival and blasted off down the river. Shaken, I pulled myself from the water and found another car of the same model which had mysteriously appeared in exactly the same location as the one I had just acquired (only this time a different color). This time I had no further encounters as I started my run across the desert.

That is until I had an unfortunate high speed impact with a gas station and had to switch to a Titus ZJ hardtop.

After my last run-in I took great pains to keep my distance from any adversaries, going cross country where necessary until I found myself at the southern end of Panau Tangah bay with the prospect of a scenic night time trip by speed boat north to Panau International airport.

I arrived at the airport early in the morning hopeful that some sort of organized evacuation would be in progress for the non-zombified survivors. Unfortunately what I found was worse than I could have imagined.

All around me planes and helicopters flipped and crashed amid torrents of gunfire. Sports cars power slid across the tarmac and people hung off the wings of planes as they flew into each other. This was definitely not where I wanted to be, which left me with only one more place where I might find escape. The port at Panau City.

To be (probably not) continued…

Anyway, I’ve thought for a while that a long distance road trip game combined avoiding enemies who have superior numbers/weapons by using stealth and knowledge of the terrain would make a really interesting experience. This experiment kind of confirmed for me that the overall pacing can be engaging, and I think with the additional depth of some design-your-own-vehicle/have-to-fix-your-vehicle-when-you-wreck-it mechanics would make for a great game.

*Added to TODO list*

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.

   1: //use your real Twitter API tokens here

   2: string consumerKey = "XXX";

   3: string consumerSecret = "XXX";

   4: string accessToken = "XXX";

   5: string accessTokenSecret = "XXX";

   6:  

   7: TwitterAPI api = new TwitterAPI(

   8:                           consumerKey,

   9:                           consumerSecret,

  10:                           accessToken,

  11:                           accessTokenSecret);

  12:  

  13: //generate a signed http get request for the specified twitter API URL

  14: HttpWebRequest signedRequest = api.GenerateSignedGetRequest(

  15:       "https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=mr_sharpoblunto");

  16:  

  17: //you can now use the signedRequest object to query the twitter API

  18: 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.

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