 (2FA) to the RuneScape website. Prior to this it had only existed in the RuneScape game clients, which presented an attack vector for malicious entities with access to the target’s email – they could bypass the games’ checks using the website and disable the 2FA integration. This came at a time when we had promised security improvements to players as part of an overarching project to prevent accounts from being compromised.

I helped implement this in the website log-in flow – a typical six-digit pin check for accounts with 2FA enabled. This required careful consideration of security implications – we needed to ensure we were not creating another vulnerability by providing automated attacks with more information about a player’s account. We needed to create a short-lived session for users who had successfully logged in using their username and password, but had yet to input their 2FA code; the user may accidentally close their browser, tab, or simply refresh. Ultimately, we balanced an un-intrusive and familiar web paradigm against risk mitigation, and produced something simple and effective that incurred a positive sentiment boost.

Adding 2FA to RuneScape Website Log-Ins

Our department was splitting into domain-focused sub-teams in preparation of adopting Agile SCRUM. Future projects would require cross-team collaboration, and previous projects had faltered when it came to designing services for consumption by eachother. Cross-team stand-ups had helped, but an important bottleneck was our contract design – it was happening in text documents and presentations. We needed a modern way of designing and iterating on APIs, to parallelise work and provide clarity to clients and test engineers.

 design – creating a framework for data interchange prior to implementation. A company called SmartBear had developed a RESTful API documentation tool we had used in the past, but at the time “Swagger” had muddied our controller classes. Now some years on, they provide SaaS solutions for collaborative API design, hinging on an open-source specification format written in JSON/YML: the “

“. This specification is more than declarative; it can be used for code-generation, auto-mocking, and loaded into REST clients like Postman.

I established a relationship with SmartBear, and built a proof-of-concept integration with our Maven-Bitbucket pipeline that would automatically POST documentation to SwaggerHub. I ran training talks on the specification, and used this API-first process in the next project that required a RESTful API to great success – client developers were able to interrogate the input and output models ahead-of-time, leading to no last-minute changes. The philosophies underpinning this way of working have since been adopted by our “tech principles”, and continue to help us design better services.

Improving API design processes

I needed to provide a means to localise a website with static content – ergo, a change to website content would necessitate a code change and redeploy. Furthermore, the localisation team already had a well defined workflow to help them manage requests, and I needed to be considerate of that. Lastly, they always found themselves re-translating the same common strings repeatedly for new sites – “play now”, “sign in” etc.

I created a paradigm for our JSON content files that closely matched that found in our CMS (in case we wanted to upgrade from static to dynamic content). This paradigm included a demarcation for 

 per string field, and ISO language codes per localised value e.g. 

. Then, I created a private NPM package to convert these files to-fro CSV for use by localisation. By communicating with localisation experts early, I was able to create something functional and re-usable quickly; it also worked for images, as we could direct to different URLs. Even though this was not our ideal solution, I reduced quickly removed a blocker and reduced the amount of work necessary in the following weeks to support the launch of new game content.

Static site localisation

Apple announced they were deprecating a method of identifying players via Game Center that we reliant upon in production to help iOS users create RuneScape accounts. While they provided an alternative, they did not announce a cut-off date for the legacy identifiers, and their developer documentation was not updated to reflect this. The new identifiers could not be retrieved unless the user logged in.

Reliance on third-party identity providers was an accepted risk, and we already provided users with ways of securing their accounts with further identifying information, however we needed to undergo a safe and full migration before this unknown end-date or risk losing user’s account details.

I updated our Apple authentication service to begin accepting new credentials, and our dashboards to show progress over time. Simultaneously, we reached out to Apple for further clarification. This work was a preventative measure wherein we reacted to changing circumstance with little notice, and we were able to retrieve the new identifiers.

Dealing with deprecation

With an expanding cloud platform that had so-far been orchestrated manually via Amazon’s web interface, we identified risks of high cognitive load, critical dependencies on individual members of staff and reliance on our provider in regards to the definition and provisioning of its architecture. Despite it being a fledgeling platform, it was already becoming harder to train people, and harder to understand the extent of our services – and 

This is a problem solved by Infrastructure-as-Code, something that had been on our radar for a while but had never presented as a necessity.

We earmarked some time to make significant progress in learning the core concepts of Terraform alongside some external consulting. We chose Terraform after some investigation as it is the most popular declarative framework for this kind of lifecycle management.

I was able to manually transcribe a section of our architecture (a static website in an “environment” with correct network access) into Terraform configuration using their documentation, learning some AWS intricacies along the way. I ran a daily peer-review in order to share knowledge and produce thorough documentation. I furthermore communicated with new dev-ops hires to ensure parity.

As IaC produces re-usable components, I was able to use what I had done to kickstart the next project.

Establishing infrastucture-as-code

I helped create a corporate blog for the Jagex website. As part of the web team, I contributed to the content modelling within our headless-CMS solution 

, which expanded iteratively over time in collaboration with our internal customers to include things commonplace in any blog – authorship, rich-text-content and embedding, timed publication, categorisation and search. Around this, I helped build a content-authoring pipeline using AWS and ElasticSearch that resulted in a highly-available website with content decoupled from its use in the front-end. In this way, editors needn’t worry about how their content would be visually displayed in the context of the website, and we were able to build an API layer to perform caching, filtering, and easily re-use the content elsewhere (i.e. an RSS feed). The blog itself was delivered quickly in a ‘

‘ fashion, and immediately put to use – we additionally implemented modern SEO and preview features to empower sharing.

Building Jagex's corporate blog

I took part in the Ludum Dare Game Jam 44 with the theme "

. This was my first LDJ with a partner – we conceptualised together, and then split responsibilities squarely between programming (Unity, C#) and art. I took advantage of a loaned 

, a dusty old microphone and a whiteboard to design a rhythm fighting game where you are a kaiju monster – a legend in human history being repeatedly attacked. In the down-time between eras, you are given a chance to trade your ever-diminishing health for stronger combos, in a desperate bid to continue surviving…

Every game jam, I try to do something outside of my comfort zone – this time, although we both contributed to all aspects, I was in charge of UI/UX, art and sound assets. It was a reasonably UI heavy game, designed to be plugged chock-full of 

 to add characters, battles and moves. This data-driven approach was inspired by our experience of working with content developers in-industry.

We designed it together, and decided on a hybridisation of the typical rhythm-game formula - instead of hitting buttons on-beat, you had to queue your attack patterns, meaning longer combos for better attacks were higher risk-reward.

jam – we didn’t win any categories, but we produced something that felt polished that we were proud of, and thanks to some charmingly constructive feedback on our submission by members of the LDJ community, we were able to pin-point exactly where it needed improvement: chiefly, the core mechanics were not conveyed well enough to the player, and it could have benefited from some clearer tutorialisation.

Designing a rhythm game for Ludum Dare

Note: You have to make an annual payment to keep your status 'active' on the ScrumAlliance website, so depending on when you visit this page, it may or may not be out of date!

I completed a three day certified SCRUM master course delivered by the SCRUM Alliance. I had used variants of Agile project management frameworks for years, but had never sought any official guidance. My experience in industry had prepared me with many questions, as I had seen where we had struggled so-far – usually when co-ordinating projects across teams operating with different methodologies.

I had chosen the SCRUM master training as I often found myself representing my teams – either presenting work, engaging with customers, or collaborating with others. Being an envoy in this way meant I was already often fulfilling the requirements of a SCRUM master – removing blockers for my teams, and being a proponent of more introspective and adaptive methods of working.

In addition to brushing up on the formal principles of the SCRUM framework and its ceremonies, I gained:

SCRUM master certification

Marketing content produced for our websites was being constrained by the media-types editors were used to and had seen within our previous content management systems. Competing game products were increasingly taking advantage of richer web-based experiences; sites with 3d mastheads and model-viewers, sound and video were providing players with more engaging looks at upcoming content.

We identified an opportunity during a project to explore the feasibility of taking RuneScape game assets and putting them into a web context using WebGL. My idea was to produce a model viewer that would work with an arbitrary model, and could support animations and camera tweening.

I collaborated with a 3D artist, and used 

 to load a character from the game. I made it mobile-responsive, and with the outcome I was able to hold an ideation meeting to progress formalising a pipeline for using these assets in the future.

Since, we have embedded 3D models in our news posts.

Prototyping 3D web assets

I helped design and build a series of bespoke and high-fidelity marketing sites to promote upcoming RuneScape game content. The project represented a chance to demonstrate our technical capabilities as a team, uplift the kinds of requests made to us, and promote collaboration with our creative department. We delivered an engaging experience with repeatable components that accommodated further content updates, giving players a reason to return to the page and “mine” data about upcoming content.

We conducted a short period of prototyping for tweening and spritesheet animations using CSS3D & WebGL – we knew we needed to showcase characters, landscapes, videos and user-generated content from social media. We settled on a landing page that provided an overarching timeline of updates to our subscription-based living game RuneScape, and an enticing zoom-in to explore each further. In the process, we provided a mechanism to localise and compress the content, and bootstrapped it with the usual slew of analytical events (GA, 

) to understand how people were enjoying it.

Marketing microsites for game expansions

We were facing pressure to respond to more requests than our capacity would allow for. In order to maintain our output on projects we cared about, we needed to enable outsourcing by creating a process for external evaluation, however we lacked a centralised source-of-truth for our standards and practices that could be used to vet compatibility with contracting agencies. This coincided with a developer-led initiative to modernise and transfer our team documentation to a more visible, maintainable place.

 to create a documentation site through AWS. This was advantageous as it meant changes could be peer-reviewed in VCS, and immediately visible online when merged thanks to our CI/CD pipeline.

I transferred our prior documentation to it, and then consulted with members of staff who had experience acting in contracting roles, in order to determine what information would be necessary. These were narrowed down to 

. At a technical level, it made sense to divulge:

Blog

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

It's dusty over here... 🤧