With a tight deadline to deliver a promotional website for a Twitch Prime partnership deal that exceeded expectations, we allowed players with Twitch accounts to link them to their RuneScape accounts, and through Twitch redeem in-game items. This required updating a bespoke marketing page, and user flows for services linking Twitch and RuneScape accounts via Twitch’s APIs and our internal e-commerce services (including player-support tools for manual redemptions). Like much of the work at Jagex’s web team, this represented bridging a gap between the game and an external service.

The user-flows could become rather complicated, so this required careful planning and rigorous integration testing to prevent abuse from URL manipulation – 

considering that these promotions represent an attack vector for bot accounts who will take advantage of free membership.

Delivering Twitch Prime promotions

I helped upgrade the multi-platform Google Log-in integration for both RuneScape and OldSchool RuneScape following the deprecation of many of Google’s ‘plus’ APIs. This involved significantly overhauling aspects of our legacy architecture for pre-existing social network integrations, and the implementation of a new Java web service supporting an OAuth 2.0 client-credentials flow with Google. In the process, I identified a bug with Google’s fledgeling People API. I also facilitated with the secure migration of hundreds of thousands of account credentials. The work was furthermore extracted into a series of libraries to facilitate the creation of arbitrary future social integrations.

Google log-in integration for RuneScape

Though I had a lot of space for media in my design, I was finding choosing a single feature image for each post challenging, especially with each page placing that image into a different context. I’d also noticed a trend in corporate websites adopting masthead videos to great effect.

I knew I’d have to employ graceful degradation, so image (poster) fallbacks would be necessary. I was also conscious of loading too many assets at once, to the detriment of bandwidth and the creation of ‘

‘, which warranted investigating asynchronous loading and some sort of automatic compression toolchain.

I decided that I would extend the field types in my CMS to incorporate an optional featured video. This way, the few posts being highlighted in the UI could auto-play and appear grandiose, while smaller links to post items could fade-in a video on-hover (similar to YouTube’s video preview).

I use a myriad of screen-capture tools depending on which platform I’m on. Since my site is dynamic, my CMS is hosted, and I can update it from anywhere. If I had the time to investigate some automatic video compression post-submit-hook, I would, but in the end I just used a combination of 

I extended the model for a blog post to include an 

 link, which seems sufficient since they’re both 

 (you’re welcome) to this draft post actually served as a proof-of-concept. In doing so I came across a handy new Chrome feature called 

, which, while nice here, might have resulted in unusual behaviour in the blog-list and cover images, where the videos are being used behind text, for decoration and to supplement it – fortunately this can be disabled using the attribute 

Encountering a strange issue with the video loading but not playing, I found out that 

 – which is great. Since I don’t want sound here, and there’s not any in the videos, I added a 

 when the user hovered over them. In this way, they will have to trigger a specific action to load a specific video after the page itself has loaded, which is more mobile-friendly. The result looks refined, and is a nice surprise.

The last awkward issues were to do with the initial paused snapshot of the video not rendering at the same resolution as the loaded video, but not giving any indication in the DOM as to why.

Visual flair with HTML5 video

I created a series of shaders in GLSL for use with OpenGL in C++ to demonstrate core concepts of vertex, fragment and geometry (tesselation) shading. I also used interpolation between textures, and lightmaps and conditional evaluation to provide transparency.

I gained experience writing shaders, including implementing lighting algorithms (diffuse, specular, phong) to manipulate scene objects in a 3D simulation.

Vertex shader to scale model down with conditional evaluation (for transparency)

Two textures are interpolated between, and positions manipulated

Fragment shader to fade away according to texture lightmap

Geometry shader to make each vertex of the cube split into smaller cubes, with random movement

Tessellation control shader for deformation, with real-time lighting

Tessellation control and evaluation shaders to add detail and smash model

Tessellation and dynamic lighting shaders

I helped deliver Apple Game-Center log-in integration to support the mobile release of OldSchool RuneScape in October 2018. This was a load-balanced Java-based web-service that had to integrate with both our legacy infrastructure for account management, and the iOS game client. The feature enabled us to pass Apple’s curation to be featured at the top of their App Store upon release, and the game ultimately went on to win several awards (BAFTA, Develop). This service facilitated the creation of more than a million game accounts, reducing the barrier-for-entry for new players by implicitly creating a RuneScape account and linking their Game-Center credentials to it, allowing them to “upgrade” their account details via the RuneScape website at a later date. The system continues operating with a significant amount of traffic at any given time.

Apple Game-Center integration for OSRS mobile

I took part in the Ludum Dare Game Jam 38 with the theme 

. This was the first LDJ I completed on my own, and my idea was to create a micro-management puzzle game where you play a lighthouse-keeper in space informing ships sending distress signals from upcoming hazards – flitting between them to give them new information as to what to do next to stay safe.

I managed to model some simple assets in Blender, and create a scale of difficulty for the distress types. Ultimately, the game was too hard, however it had a functional loop, and it was fun to be both the artist and programmer on the same project. I ran out of time to do some things I wanted to do, so I think prioritising functionality over appearance early on is a better strategy for future jams.

Designing a puzzle game for Ludum Dare

The web team at Jagex had been receiving requests from fans for features that demonstrated there was a mismatch in expectations – many of the things they thought we were responsible for, we weren’t! Our annual fan event was approaching, and we had a tradition of contributing to it as a team, but no solid ideas.

I helped deliver a talk and Q&A with fans, on stage at the event. I did some research into our department’s history, and mapped our technology and sites historically from 15 years prior to present-day. You can 

 – it was the best rated talk of the event, and we got some great questions from keen web developers about our APIs.

Community engagement

This took about 5 months of sporadic work to complete, and was written in C++ for Windows machines. It was comprised of a number of subsystems written to industry standards, some of which leveraging middleware, and all drawing from a wealth of theory.

The final gamut of subsystems included resource-management, 3D graphics, 2D physics, file I/O, audio, human-interface, profiling, and an events system to tie them together. You can find an explanation of each below.


After demonstrating of the capabilities of the engine, I went on to add a gameplay subsystem to utilise it, producing a game called ‘Sinball’, an amalgam between a 

Ultimately, I delivered a fully functioning and reasonably polished experience that was a lot of fun to play. The experience tested me on almost all of the skills I had learned during my course , and pushed me to find comfort in architecting complicated systems to unfamiliar archetypes – a long-haul divide-and-conquer with a rich reward at the end.

I had a play around in Unity and came up with the concept for a pinball game where the stage was built from tiles, with the Molyneux-esque twist being that 

, and the idea of aping them seemed both fun and achievable given the deadline. I could already visualise the data format, and I figured it would be more interesting to have to tweak the physics middleware past its out-of-the-box settings to mimic the elasticity and restitution of a pinball.

“Don’t reinvent the wheel” – Every programmer, at least once

‘Middleware’ is ready-made solutions libraries. Without some dependency management jazz like 

 to help me, it was a brute-force exercise in downloading the right 

 files from websites that look like they’d prefer to be left alone (just follow their tutorials).

Gah, I hadn’t expected setting up pathing and versioning for 

 files in Visual Studio would be so finicky! I ended up with some per-build (debug/release) config and a littered resources folder that, despite working, I’m still scared to touch to this day.

I opted to use the in-house graphics library we’d been developing alongside our studies, which relied on OpenGL, supported any regular old shaders and textures, and, pivotally, could be extended to read 

 to design my stage. For physics, since Pinball is typically restricted to two-dimensions by a glass plate, I used the lightweight and well-documented 

, as it was one of the few free options with sensible requirements, capable of spatial sound. Lastly, for Xbox controller support, I used Microsoft’s 

The most atomic unit of a game engine is an ‘entity’. There are some common features of entities that are worth encapsulating for access across subsystems. Mine ended up storing their position in the ‘game world’ as a tuple inside of a 

, along with pointers to extra metadata per-system, such as 

 (their position in the simulation), and 

 (their shaders, textures, mesh). They also had some basic toggles, such as 

. Thus, creating a custom Entity, such as a pinball, was as simple as bootstrapping its own fields, and ergo defining how it should look and act inside of its constructor.

Critical to any game engine is efficient use of memory. Using contiguously malloc’d memory that was strictly indexed necessitated overriding the 

 operator for many managed entities that would end up being spawned and re-used (e.g. game entities such as tiles).

 that held stores of segmented sizes. Each 

 of their states and pointers (free/allocated). These structs came in handy for clarity, and while I was hesitant while writing it, the resulting files were very simple.

Given more time, I would have liked to have also pre-loaded a manifest of static assets – as it stands, the engine hangs on first-load. Nonetheless, manage resources in this way increased the frame-rate drastically, and meant I didn’t have to worry about defragmentation. It also made the process of debugging easier, as snapshots of memory were more orderly.

The final step function ran inside a while loop in 

bool Core::Step()
{
	graphics.Update();
	humanInterface.Update();
	gameplay.Update();

	if (!gameplay.IsPaused() && !gameplay.IsFinished())
	{
		physics.Update();
	}

	if (!gameplay.IsFinished())
	{
		audio.Update();
		profiling.Update();

		eventManager->RemoveFinishedEvents();
	}

	return !(gameplay.IsFinished() || graphics.IsFinished());
}

As you can see, nuances regarding exiting the program aside, each subsystem gets its own turn to update itself, reacting to and potentially creating new events.

In order for each subsystem to function interactively in the game loop, they each needed an abstract way of informing the others of changes. They all stored a reference to a global list of game entities, but needed something to act as a communication channel. To confound the problem, some entities implemented various listeners like 

, inspired by the ‘components’ or ‘nodes’ in other popular game engines – the scope of these functions would be different.

So, using OOP, I created a hierarchy comprising of an 

 objects, whose payloads could be optionally extended by each sub-type and tagged for delivery to a particular other. Extending an abstract 

 class, each system would automatically consume events from the queue intended for it during their 

 step, and circumstantially produce new events for the queue. These events were mapped to internal handler functions using lambdas. Entities themselves could also implement optional interfaces exposing handling methods for certain scenarios, and in them, also produce new events.

It is worth noting that the process of development here was very iterative – I started by seeing if I could press the 

 key, make something somewhere respond by shouting a message to the console, and then built from there

To expound, take the case of the pinball hitting a wall. The physics system would poll its middleware to detect a collision, and then call a handler on the pinball entity:

if (collisionDetected) // Simplified!
{
	Collider * c = dynamic_cast(entityA);
	if (c != nullptr)
	{
		c->OnCollisionStart(entityB);
	}
}

Inside of its handler, it would, among other things, register a 

void PinballEntity::OnCollisionStart(Entity * e)
{
	eventManager->AddEvent(new PlaySoundEvent("./Resources/Audio/collide-wall.wav",
		gameObject->x, gameObject->y));
}

 system as the sole recipient. On the other side, the event would be handled in the audio system by mapping to a function, and acted on in the super call to 

Audio::Audio(EventManager * eventManager) :
	Subsystem("Audio", Event::AUDIO, eventManager)
{
	eventMap[Event::AUDIO_PLAY_SOUND] = [this](Event * e) { HandlePlaySoundEvent(e); };
}

This was a streamlined process very similar to 

, which meant the limitations of the engine’s communication were furthermore only defined by how many different handlers of event types there were. A key-press inside the human-interface system created an 

 that the gameplay system transmuted into a 

 for the physics system to process, etc. Although it relied on the game-loop to operate in a logical order (as it is not multi-threaded), it allowed each subsystem to remain decoupled from the implementation detail of the others.

 graphics. I’d have gotten pretty poor feedback, I’m sure, but the simulation still functions fine without a window. Indeed, it did for a time while I was fleshing things out. I had to set the timestep in such a way that it 

, and balance the number of calculation passes against it (too many -> too slow, too few -> too unpredictable).

Aside from digging through header files, it also took some time to figure out the relative scale between the physics-representation of space and the graphical representation of space. A red-herring, I originally set the force coefficient so disproportionally low that it appeared as though it wasn’t working at all; it took my friend determinedly leaning on the keys for a solid 5 minutes as a pink box eked its way off my platform to convince me otherwise.

I also came across a disparity between the angle of rotation of an object between the physics and graphics systems – one was using radians, and one was not, resulting in some weird spinning cubes. If you’re interested, the the 

I ended up using a small library called 

 to load my meshes. I used the z-axis and some textured quads acting as backgrounds to create a parallax effect. The heavy-lifting here was accomplished in 

Everyone likes to kick-back with a controller now and then. There’s something about adding different kinds of input that gives me a real science-y vibe; I’m only ever a few pints away from adding 

 interface with some more ambiguous types of inputs – ‘up’, ‘enter’, ‘primary’, ‘secondary’. This helped glue the 

 implementations together, and meant I could map multiple redundant keys (e.g. 

, ↑) together for flexibility. The actual system itself polls each connected controller every update, checking for connection/disconnection, and to see if a button had been pressed. I programmed a state map for each input, so it was possible to determine if something had been ‘held’ versus ‘pressed’, and thanks to the aforementioned event payloads analogue input was simply a matter of sending along the extent at which it had been pushed in each direction between 0 and 1, to be used as a multiplier against the pinball’s movement-speed.

Surprisingly, this was my favourite to implement. I enjoy 

, and deciding how to represent the game world felt just like one. There’s no real right-or-wrong here. Some people use in-memory database-dumps (like 

), others use more standard interchange formats (like JSON, YML), and some just use an ASCII file and call it dot-whatever-they-like. Guess which one I chose?

My level files ended up taking the form of a space-delimited array of integers. The first two represented the dimensions of the level. The rest were the stage itself, numbers corresponding to different children of 

. Typing it out using carriage returns actually helped visualise the stage.

. Given more time, it may have been wiser to incorporate the tiles into a 

 function in order to save log output when…

Decidedly the least sexy, but nevertheless important, profiling is a means to measure the performance of a program. Timing the update steps of each subsystem, and keeping a track of the frame-rate seemed to be the most valuable metrics, as they indicated the metaphorical horse-power of my engine.

In a similar vein, I also implemented a basic static logger that supported levels, prefixes and timestamps (like browser dev-tools). This helped during debugging, as each module knew its own name, and I could create a clearer picture of a sequence of actions quicker than trawling over a stack-trace or stepping through breakpoints.

In the end, I decided to allow toggling the profiler on/off at run-time, with mechanisms to enable/disable logging to both the console and local filesystem. Ironically, spewing so many messages to the console actually hampered the performance of the program, creating a self-defeating cycle, so I have some further investigation to do there. I forgot to set it to false by default for release, with the moral to that story being that nothing is ever 100% done, no matter how much time you spend perfecting it.

Often overlooked, there’s a lot more nuance to audio implementation than meets the eye. It’s like shopping for a washing machine – how many kg capacity are you after? How many modes do you need? What rpm spin-speed? Energy rating? Warranty? Monthly maintenance add-on?

On the surface, I wanted to play some sounds, so I downloaded a license free pinball SFX pack. To my horror, when pressing play I was greeted with a cacophony of undulating, grating explosions. I’d programmed the sound event to trigger every collision, but with the ball rolling across a flat surface, it was technically colliding every frame. I fixed this by adding a state to represent the ball either touching a surface or not, and an audio timeout, but I fear I may never be the same. It may be wise to implement some sort of max-polyphony.

Another challenge was music. Different to SFX, background tracks provide great ambience at the cost of much higher file size – therefore, it’s better to stream them in. I had to add functionality to loop them, and support muting all sounds just-in-case.

With a proof-of-concept of the engine’s core functionality, I set about the most rewarding leg of the journey. Having been building towards one specific game, I already had a strong foundation – an untextured ball on an untextured, simple stage, being moved by the keyboard.

First, I decided on all of the different types of tiles, based on images of real pinball machines:

A game engine and game from scratch

 at University. Having just spent a year helping develop games, I wanted to understand the factors influencing the success of early-access products with living development cycles reliant on user-feedback. It was an opportunity to learn more about data-science, and combine my passion for gaming with web development.

My hypothesis was that early-access games with a higher cadence of updates incur higher review scores and player-count prior to full commercial release, creating a positive feedback loop of common success metrics. By validating this information, I could help improve decision-making during development.

I built a data ingest pipeline using Python (Flask), Couchbase and RabbitMQ with which I could scrape information about Steam games tagged as “early-access”. The pipeline drew from a number of public APIs to retrieve information about CCU, user reviews and content-updates. When this was deployed (DigitalOcean), I used Jupyter to explore and graph the data for my paper.

Using this pipeline, I retrieved information about 977 games, with a total of 1,533,188 reviews. In short, although there were some ambiguities noted, with an evidenced understanding of factors influencing the success of previous ‘early access’ products, developers could use the results in order to plan their own release strategy. This may remove uncertainties in the process, e.g.

On average, 8% of reviews per product are submitted by users who have received the product for free, with software and casual game product genres receive the highest proportion of free copies (6% and 4% respectively).

In examining the link between developer engagement and user sentiment

While a higher total of updates is not necessary to achieving a positive user score, products that have a larger number of updates logged receive more positive recommendations. All products with more than 125 updates have a user score higher than 50 (positive), and conversely, products scored negatively rarely reach more than 100 updates.

In examining the link between developer and user engagement

At the end of the project, I presented my findings at a fair and sought feedback from a senior data scientist in the games industry:

To conclude, I met all of my objectives and gained some valuable insights. It appears to present a good springboard for future investigations.

A research paper about the success of early access games

Given a brief of connecting a community through technology, we learned and applied design theory through fieldwork, iterative prototyping and evaluation. Our final proposal was a tactile ride-sharing system for small neighbourhoods in low-income areas.

In a team, I conducted interviews with a target audience, led whiteboarding sessions, created storyboards for user flows, and filmed a video proposal.

Advanced interaction design

This was a part-time contract for Newcastle University to create a kind of living portfolio for students that could represent their progression towards attaining competencies over time, while also showcasing their projects to potential employers.


I opted to create a Jekyll static-site theme in Ruby, Liquid & Bootstrap to interpret data from students’ projects and chart it against their learning objectives, which would visualise their skill progression over time while giving them something easily hosted by something like Github pages and ergo accessible to course leaders.

I spent some time wireframing and understanding the criteria course leaders set forth in order to produce something that would become essential for students and teachers alike. We created a vocabulary – “competencies” were the skills being assessed during projects, “projects” were pre-prepared by course leaders but could be added to by students, and “vignettes” were incremental explorations of their work attached to each project.

The intention was to make it as minimal-effort to use as possible, and allow teachers to automate collecting data from their students; I made it so all they had to do was fork the example site, and replace the information in Markdown with their own. I also added a rudimentary API endpoint, extensive documentation and cross-linking, and the ability to embed Jupyter documents – necessary for their domain.

When a student submitted a project, everybody could see which competencies they had demonstrated against which they were supposed to. The client was happy with the end-result – simple and effective.

Blog

Technological tattle, design documents, and miscellaneous musings written during various projects

It's dusty over here... 🤧