B2D2: Box2D Time Dilation Experiment


For the last few weeks, amongst many other things, I’ve been toying with the idea of adding time dilation mechanics to the 2D physics engine Box2D (B2D). I honestly can’t recall what first moved me to think about this, and while I have ideas for game mechanics featuring similar time manipulation, I have none which would require physics simulation. Nevertheless, it’s been an interesting problem, and given me a reason to dig into and understand the internals of a physics engine. You can see a video demonstrating my progress so far below, and scroll down further for more information.

Although the implementation isn’t very far along, a lot of time has gone into exploring the B2D code, thinking about potential problems, and finding the ideal place to apply temporal forces. I am not a physicist (theoretical or otherwise), so my model of time dilation is based upon intuition and practicality of implementation:

The idea is that each object has it’s own temporal velocity (TV) which functions as a multiplier for its passage of time. Therefore, a body with a TV of 2.0 will accelerate twice as quickly, move twice as fast; a motored constraint with a TV of 0.5 will output half as much force. A time dilation field (TDF) is a physical space defined by a B2D body, for which a temporal velocity may be specified separately to the ambient temporal velocity. Bodies are affected by temporal drag (TD) based upon standard fluid dynamics drag calculations, considering their velocity relative to contacted TDFs. Thus a body will gradually adjust TV to match it’s environment.

The drag model is intended as a graceful way to handle overlapping TDFs. I had previously considered a multiplicative model, where the area overlapped by two TDFs (a & b) has a TV of TVa*TVb, but this didn’t seem to make much sense to me, physically, and requires a more complex implementation. Instead, I use the analogy of sticks drifting in a river: the river (TDF) flows at a certain speed (TV), which pushes the stick (body) according to a drag function and a collection of variables. In the case where TDFs overlap, I treat it as the ‘river’ having other currents running through it: the body is affected by drag from both currents, so it’s TV should approach their average.

There is, however, an awkward case in my implementation currently, the logic behind which has become apparent to me as I type this: Two overlapping TDFs, both with a higher TV than a body within will cause the body to experience a positive force from each, accelerating faster than it should. This is true for two fields slower than the body too. This would not be an issue if drag was applied directly to the TV, as the current (relative) TV is part of the drag equation, but as it stands both forces are combined in a temporalForce variable to be applied later in the step.

Another significant obstacle in improving the ‘accuracy’ of this (pure fantasy physics mechanic) is the ability to quickly calculate a reference area for the drag calculation. Ideally, this would be the area of a body which intersects with each field, and then the reference area for ambient TV drag would be the area not intersecting any field. I am not aware, however, of an efficient method to calculate intersection areas, and the ambient reference area calculation is complicated when the body intersects TDF overlaps. Currently, bodies simply experience full drag force from any TDF they contact, and only from the ambient TV when they contact no TDFs. Another alternative would be to consider the intersection of fixture vertices with TDFs, though this would be problematic for large or highly irregular fixtures.

There are, of course, other issues and features yet missing. I have a pretty solid idea what problems I’ll face down the road, and some ideas of how to address a few of them:

  • Constraints are not yet affected by temporal velocity; I believe only their frequency and motor parameters may be affected, and their TV can likely be treated as an average of the associated bodies in most cases.
  • My implementation features an observer TV variable, and all movements are based on the relationship between it and the body TVs. This means that if the observer TV is 2.0, bodies with a TV of 1.0 will appear to move at (1.0 / 2.0 =) 0.5x speed. The catch here is that for accuracy, we need to integrate for the change in body TV between steps, AND for observer TV. Not only do I need to revise some calculus before I can confidently implement the latter, but it also requires that I either cache previous observer TV values, or maintain an observerTemporalForce variable.
  • I need to go over the TOI (Time of Impact) solver code and work out how exactly TV impacts this, as currently this area is untouched. Also, relevant: I need to revisit my old idea of modifying the position and velocity iterations based upon the the current maximum TV in a simulation. My intention there is to maintain stability in accelerated time streams. The problem is that in order to utilize the current maximum TV we would need to either apply temporal forces to TVs in a separate loop prior to island* solving. Alternatively, we can look into the viability of allowing iteration counts to vary between islands, or utilizing the maximum TV from the previous step.
  • By using the standard drag equation, TDFs could potentially be further configurable than they currently are, for example by adding a ‘fluid density’ variable. Currently my implementation uses a (rather high) hard-coded fluid density for temporal drag calculations, to ensure rapid speed adaptation.
  • I’d like to experiment with applying a shader which stretches geometry based upon TV and (spatial) velocity. There’s already a suddenly slowdown upon exiting an accelerated TDF which is reminiscent of warp-in effects from Sci Fi media, and I think this could make it look extra cool.

In all likelihood I’ll soon have to put this on hold indefinitely and focus on some more practical projects, but it’s been fun and informative, regardless.

* Islands are B2D structures into which bodies are clustered prior to solving, based upon their contacts and constraints.

Portfolio Update – AI for The Resistance


A few weeks back I added a page for my dissertation project, a research/development paper on AI for the modern board game The Resistance, found here. I finished the last section about a week ago and have no removed the work in progress tags since I don’t think I need to make any major changes.

I’m not completely satisfied with how it turned out; it’s significantly longer than I had intended and skims over a lot of information. The intention was never to provide an alternative to reading the full paper though, only a summary of the work therein for interested parties to skim over. I generally find abstracts for longer papers to a poor job of this.

Lately I’ve been a little preoccupied with the job hunt, but I’ve been quietly toying with a little programming problem and indulging my other creative interests in art and language too. I recently hit my first exciting milestone in the programming project. It’s not much but it’s the culmination of some hours researching a foreign code base to work out the best approach, and I now have a solid understanding of all of the problems that need to be solved as I move forwards.

Updates soon :)


Portfolio Update – Game Behaviour


I recently put up pages for two projects from the Game Behaviour module undertaken in the final year of my BScH in Computer Games Programming at the University of Derby, which I have now fully completed and received a very pleasant classification for.

You can now head over to the pages for Crispis and DropCakes, and The Frozen Firepits of Generic Dungeon Name for information on these projects, or to download the source code and executables. The former is simply a 2D physics sandbox built upon Box2D and a custom Entity/Component engine, and probably isn’t or much interest to many. The latter, however, you may find interesting if you’re into game design, classic roguelikes, fantasy games, and such.

The Frozen Firepits of Generic Dungeon Name (TFFGDN) was an experimental game design implemented for an artificial intelligence (AI) assignment; it did well, though the AI isn’t too interesting in my opinion. It’s a fusion of turn-based, physics-based mechanics similar to Snooker or Pool, and classic fantasy dungeon-crawler games where a party of adventurers of traditional achetypes such as Warrior, Wizard, Rogue, etc. enter into a monster-infest labyrinth seeking treasure. In its current state it’s not too thrilling; I had intended to implement magic and special abilities for player characters and enemies, which I think would make things a lot more exciting, but I just didn’t have time. I also feel like the physics could be tightened up a lot to increase the pace of gameplay, but I had to do a lot of fiddling with Unity just to get it working in the first place.

Come next week or so I’ll try to have some more information up regarding my dissertation project which was an investigation into AI for Don Eskridge’s The Resistance. Then I can get onto undertaking some small personal projects while I look for work.


Ho! Another delayed post; I said I’d get to this before the semester was up, but this semester hit really hard, and I just haven’t had the time or energy for it. Well, it’s not Christmas yet, so I guess that’s something, no?

The real killer module this semester was Game Development, which consisted of a single group project with three other programmers and seven(!) 3D artists. I started to put a page together for the game we created, “SplashDash”, today; I still need to go over what I’ve written with furrowed brow and fill out the Freerunning Implementation section, but there are already download links for Windows, OSX, and Linux builds, a gameplay trailer, and lots and lots of screenshots to see!


SplashDash is a 3D, freerunning, score attack game, drawing inspiration from games like Jet Set Radio, Tony Hawks Underground, Mirror’s Edge, and de Blob.

Robots have taken over the world and subjected it to their ideals of order and optimisation. They’ve whitewashed all the walls and broken the spirit of the human population, who now go about their daily chores like mindless drones. The player is a teenager gifted with the ability to bring colour into objects with a single touch, and must use it to paint as much of the city as possible in the given time limit to inspire a human revolution.

My main responsibility was the implementation of the player movements, including running, analogue jumps, wallruns, ledgegrabs, vertical wallruns, wallrun jumps, and wall rebounds. I also worked closely with the programmer and artist responsible for the animations to try and make sure things looked as smooth as possible, and though some animation glitches remain I’m pretty pleased with the way things turned out.

The freerunning implementation is, honestly, pretty unrefined, as I’ve never coded such complex 3D movement mechanics, nor used Unity before, and time constraints on the project meant that I could not afford a lot of research or iterate as much as I would have liked. I opted to go with a system which did not require any hints or triggers to be placed into environment, so as to minimize the workload of environment construction. Let’s just say there are a lot of raycasts and a lot of vector maths involved; you can read more about it (once I’ve written it) and my other contributions on the SplashDash page.

We’ve all learnt a lot from this project – mostly about working with Unity, its flaws, quirks, features, limitations, and best practices, but also more transferable skills. We had some communication and organisational issues (which I’ve written about at length for a post-mortem as part of the assessment, and shan’t post online yet) that I think are easily solvable once identified; some simply by picking the right tools and channels, and others by encouraging certain practices. The project was also a good insight into the importance of sorting out your methodology and workflows out early on in a group project – I feel that with time invested in the right places at the start, things would have progressed more quickly, and in a more organised fashion.


Anyway, I think it’s pretty effective as a proof of concept – or not, as the case may be. We all agree that the movement is the most fun part, and that a linear time trial or racing mode, on maps similarly constructed to the tutorial level, would probably be more fun (especially with some nice acceleration mechanics thrown in to reward good freerunning flow). But it is quite fun, all the same, and I think the concept deserves further investigation which, if I ever find the time to experiment with a proper non block-based painting system, I might just be tempted to conduct.

Edit: P.S: Mute the game and go listen to the Jet Set Radio OST while you play :P

A Note of Intent


I decided I wasn’t going to bother posting another update here until I’d settled back into uni and sunken my teeth into some fresh projects I could write about. I suddenly find myself almost two-months into the final year of my degree and I’ve been rather too busy to give it a second thought.

So here’s a note of intent: I will, sooner or later, make a proper post about this semester’s projects, before the semester is concluded, including my dissertation project, which was signed off by my supervisor last week and is now awaiting my full attention…after two more urgent deadlines. For now, I’ll just leave a brief list of what I’m currently working on:

1. An essay on the sufficiency of services provided by modern operating systems for accessing detailed information about gaming peripherals [due two weeks from now – yikes!].

2. A Unity game about parkour and painting. Think Jet Set Radio meets Mirror’s Edge meets Tony Hawks Underground. This is a team project with three other programmers from my course, and seven artists from the University of Derby’s Computer Games Modelling and Animation course [due sometime around the end of the semester].

3. For my dissertation project I am to be investigating the posibility of applying various AI techniques to the board/card game The Resistance. This may include search trees and evolutionary techniques, and I will be using the competition framework and bots provided by AiGameDev.com last year.

These are the things I’ll be posting about and/or creating new pages for here when I get chance. All the other stuff I do I’ll likely post about elsewhere if I even have the time to continue doing things other than eat, sleep, and code.

I cook some nowadays, and bake a little; I still study Korean, and I’m trying to snatch back the graphic design and art skills I used to have. But I’d like to keep this blog focussed more on programming, and the larger projects I undertake.

MARS MIPS Simulator Lockup Hackfix

If you are attempting to use Missouri State University’s rather excellent MIPS Simulator and IDE, MARS, to develop an application which uses the bundled Keyboard and Display Simulator (though it seems  unlikely that you would be doing so seriously today), you may encounter a sporadic bug where the entire MARS application will lock-up, and you have to end-task it.

I personally encountered this while attempting to make a simple Snake clone just over a year ago, during the Console Development 1 module of my (WIP) BScH Computer Games Programming degree and the University of Derby. At that time me and a friend tore open the MARS .jar in order to probe for the cause of this, and were actually able to implement a little work around. Since posting about this project here and putting a video demonstration up on YouTube, I have been asked several times about how we were able to do this, and rather than repeatedly send out links to the email I originally sent to Ken Vollmar, I thought it might be nice to have a decent guide I can direct people to.

Note that the below instructions cover a quick ‘n’ dirty fix, which may introduce other errors (though I haven’t noticed any). This is why I have elected not to just hand out a new .jar, though I could happily do so under the MIT License. I didn’t then have the know-how to properly dig into the problem, and since lengthly debugging of broken applications is my full-time job right now, I’d rather not do so in my free time.

What You Will Need
Java Tools – Likely an IDE like Eclipse
Archiving Tools – 7Zip or a similar application for looking into the .jars
A copy of MARS.jar

I’m going to assume you’re using Eclipse, because that’s all I know, so you may have to dig for some of the options if you’re using something else. I will assume you may never have encountered Eclipse or Java before though. Java is a lot like C#, but Eclipse is a bit different from Visual Studio. If you’re better at Java than me, do please let me know where I’ve done things the hard way round, and feel free skip the easy sections.

As another heads-up, I’m also using Windows, so this experience may be rather different for anyone hailing from the OSX or Linux world (I’m told that the creation of an executable .jar on Linux is free from some of the woes I encountered).

Project Setup
Firstly, create a new folder, open up Eclipse and select this folder as your workspace. I called mine ‘Mars_4_1_Mod’. You then need to create a new project in this workspace (File->New->Java Project). Name your project, and hit ‘Finish’. Note that my JRE is set to JavaSE1-1.7. This setting may be important – I’m not overly familiar with it myself.

Now right-click on the project in the Package Explorer, and select ‘Import’. You want to import the contents of MARS.jar to the project, so select General->Archive File from the dialog, browse to your copy of MARS, and hit ‘Finish. Your Package Explorer should now look something like this.


Finally, you need to make sure that Eclipse can find the source code in the project. To do this, right-click on your project and select ‘Properties’. Go to Java Build Path->Source, click ‘Add Folder’ and select your project root. You can fiddle with exclusions and stuff if you want, but I preferred the shotgun approach for what it’s worth.

The Fix
You should now be able to build and run the project (Run->Run As…->Java Application, select ‘Mars’ and hit ‘OK’). Mars should run normally and freeze as expected. Alternatively, if you run it via Run->Debug As…->Java Application then you will be able to suspend the application from Eclipse when it locks up, and then investigate the lock-up state for yourself from the Debug perspective.

Great, now go to ‘Navigate->Open Type…’ and use it to find your way to KeyboardAndDisplaySimulator.java. Navigate to line 210. It should look like this:


This is our culprit – a threading issue, a deadlock caused by this function call and another from AbstractMarsToolAndApplication.java. To implement the workaround as I have, you simply need to replace this line with the following:

//This call caused a deadlock sometimes when using the keyboard and display simulator.
//The syncronized block below simply plucks out the necessary call from
//updateMMIOControlAndData, which is where this call would take us in the end.
synchronized (Globals.memoryAndRegistersLock) {
   try {
      Globals.memory.setRawWord(RECEIVER_CONTROL, 0);
   } catch (AddressErrorException e) {

Now if you run Mars through either Run or Debug you should find that the freeze-up never happens. Feel free to poke around if you want to know more about the original issue – but if you’re just trying to work with Mars for a personal project, this should be good enough.

If you’re a student working on a project for your studies you may wish to provide your marking tutor with a copy of your modified MARS application alongside your assembly program. Now, after much pain I DO have a working .jar of this, and I will detail it’s creation beneath in case you run into difficulties as well, though it’s probably stupid because I’m not experienced enough with Java to know what exactly prevented me from doing it the normal way.

In the beginning it seems there are two options – you can export a Runnable .jar from Eclipse (File->Export->Java->Runnable JAR File – make sure to select ‘Package required libraries into generated JAR, ignore the warnings), or you can try running the script, ‘CreateMarsJar.bat’ which should be in the root of your project.

For me at least, the script somehow creates a .jar with the same bug as the original, and the exported ‘Runnable’ .jar…won’t run. The way around this is to make a copy of the original Mars.jar, open both it and your Eclipse-exported jar using 7Zip or a similar application, and copy the ‘mars’ folder (contains the compiled .class files) from your version into the copy of the original, replacing it’s own.Delete your exported jar and run the copy of the original – it should now perform as well as the version you launch from Eclipse.

Thanks and Stuff
Thanks go to my friend Bombpersons, without whom I might not originally have bothered to look into this issue. If you have any further information on this issue, any corrections to the information provided here, or struggles in doing this yourself, please do get in touch.

Moley Moley Moley Mole

It occurred to me yesterday that one of my major projects from this year was lacking it’s own page, so I spent a little time today typing up some info. There aren’t pictures yet, because I’m away from my desktop at the moment (actually its in pieces too) and I could never get the Android SDK running on my laptop, but at least there’s something there.

Head over to the new Mega Driller Mole page to check it out, if you like.