After seeing how much my partner would visit my previous codepen experiment with Nonograms on codepen, I thought it was time to upgrade. Using Next, vercel, postgres and Auth0 I created a platform for her to be able to create and rank new puzzles, with her fastest time being persisted to a database for each one.

I also played around with Next themes to create, not only a light and dark mode but also custom themes that can easily be added to.

"I may be a surgeon but I am on my lunch break and I don’t think I should operate on that family" was made in unity for the 3rd Indie Dev Game Jam. The theme was "one tool, many uses" and out team quickly settled on the humble spork as the ultimate realisation of this.

In the game you are presented with comedic illness that you must scoop, slice and prong out of the patient, using each mouse button for each action. I was responsible for all the code in the game, managing to squeeze the long laundry list of overly optimistic features into the 72 hours we had to make the game. This included:

• Two modes of play, a career mode and arcade mode.
• An Online high score system for each mode.
• 14 different illnesses to cure.
• Tutorials, transitions and options.
• An animated credits scene.

Nonograms are a simple but sometimes fiendishly difficult puzzle that my partner and I have become slightly addicted to. She is much better at them than me so in a desperate attempt to even the odds I thought it might help give me the edge to make them myself.

Conceptually a lot of the algorithms for a nonogram are quite simple. It actually makes for a nice little interview question because the key lies in breaking down the problem into smaller easy to reason parts. However, I hit a stumbling block when I realised there was an edge case where a random generation might not have just one unique solution. This was a problem because when it was generated it would store the "correct" answer it had in mind. This meant you could correctly solve the puzzle but not be awarded for the win; Disaster!!

After staring down the rabbit hole of having to potentially wrestle with holistic ways of approaching a "P vs NP", I came to a much more sensible solution.

Instead of solving for the difficult case of guaranteeing a unique solution, I could just change how the game checked whether it was in the "won" state. This problem seems difficult at first, especially when you consider the original implementation just compared the user's proposed solution with a stored one... but it actually turned out simple in a really pleasing way!

Each horizontal and vertical line of the puzzle has a list of numbers that represent the number of consecutive blocks of colour in that line, these are like "clues" to help you solve the puzzle. If you want to check any arbitrary proposed solution you can simply generate what the clues would be if the solution was a puzzle itself and then use those as your comparison.

I think there something really pleasing about this solution, and it's a great reminder that sometimes you need to stop and just take a minute to consider problems from a completely different angle.

As a professional front-end developer of almost 10 years, it's odd I've never had my own personal website. I'm usually too lost in a project and would rather be exploring something new. However, the increase in popularity of server-side rendering has given me a great excuse to finally have a reason to tackle my own site.

Next.js and React 18 make for an interesting deviation from my usual client-side forte. The technical differences are fairly apparent, but I think the headspace of thinking in terms of keeping things server-side is more nuanced and hard to get used to. This is especially true when all your usual React comforts are there within easy reach with nothing stopping you. When you hit a problem or a suggestion from Next's surprisingly helpful builder, it's easy to take the quick fix and implement the client-side solution. I think so far I've managed to avoid temptation, and this site should be completely static... famous last words.

Good Morning AI is a radio station where the scripts, voices, music, and schedule are completely controlled by AI. It's an idea I've wanted to create for years, but with the huge advancements in AI in the last few years, it finally felt like the right time to make it happen.

It became immediately obvious that working directly in the console to tweak prompts, iterate on outcomes, and stitch together different APIs was tedious at best. To try and make the build process smoother, I created a dashboard powered by Express, React, and Tailwind to quickly build the tools I needed to help me realize my vision.

This project came with a lot of technical hurdles despite the fact that the AI heavy lifting was done for me. I think the most interesting lesson for me was in adapting to a new paradigm of interacting with software. Both in terms of prompt engineering and also the API itself. For instance, being able to present the AI with a TS object and request for its response to fit that definition streamlined the process. Although this would be risky in a production client-facing application, when it came to making quick MVP tools, it allowed me to quickly and easily iterate. If a type needed to change, then the response from the API would automatically update to match it.

I researched, designed, and implemented a smart home system for my house. The system, based on Home Assistant, is tailored to be as hands-off as possible. Instead of replacing physical switches, it augments them, providing multi-functionality. For example, light switches work with a simple on/off button. However, holding them increases or decreases brightness, and double-tapping will adjust the warmth.

Despite Matter/Thread looking promising, I chose to favor Zigbee for the time being. This consistent choice allows me to create a large scale mesh network in my house while impacting the Wi-Fi network as little as possible. This means the smart devices are not temperamental depending on their proximity to the router but instead will bridge through nearby devices if needed.

The system is multi-modal, with a web interface, a mobile app, and voice control, as well as traditional physical switches. This allows for a wide range of control depending on what's convenient. Guest accounts can be created for visitors, and an old mobile phone repurposed as a universal remote.

Although we have had no problems so far (🤞), the new smart switches are mounted on 3D-printed brackets allowing for easy access to the original light switch if needed.

When the New World Trading Company pitched their idea to me as "A bit like the sorting hat from Harry Potter," I was in. Realizing that this meant connecting to an HR API, building an admin dashboard, and exporting everything daily to a third party made me a bit more hesitant!

The most important part of the project was helping to strip back the requirements to create a foundation that covered what the client really needed, leaving plenty of room for future additions. I chose Firebase as the backend, allowing me to quickly create and push features. For the front-end, I utilized a React, TypeScript, and Styled Components template I had created for exactly this purpose.

The hardest part of the project was working with live data that needed to be updated and manipulated daily. The key to tackling this was creating logs of performed operations and regular backups for the worst-case scenario. Writing about this project without using more Harry Potter puns was the real challenge.

How would you sell a 3D food printer? What about a biodegradable toothbrush? Or an easy one: a lovely cup of coffee?

In this social card game, you are tasked to do just that, but with a twist. Players take turns to be a "pitcher" and sell a product from their hand to the rest of the group. However, when they finish their pitch, everyone submits a card, which is then shuffled and shown. Everyone must guess which product they think is the pitcher's and will score points for anyone they trick. The pitcher has the most difficult job, as they will not receive any points if everyone guesses their product.

Pitch Please was a board game that could only exist thanks to the iterative powers of software. Creating a React app to design cards allowed me to quickly dial in the look and feel of the game and prototype different rules and mechanics with ease.

Using AI to generate the imagery fit well with the 'startup' premise of the game. It allowed me to easily create any product, no matter how wacky. The biggest challenge with the implementation of AI was in generating a consistent style so that the game felt cohesive.

"Nano Evolution Bots (N.E.B)" is a Unity game I made in 72 hours for the 24th Score Space Jam. Given the theme "Evolution," I decided to create a game where you try to selectively evolve nanobots to counter a constantly adapting virus.

To play, you must mix physics-based, springy molecule chains to update your nanobots, maintaining a balance between positive effects and unwanted mutations.

Some highlights I took away from this project:

• As this project was a solo endeavor, I had to create the graphics myself. Wanting to be efficient with my time, but also to push myself to experiment in areas I was less comfortable with, I dedicated time to exploring new techniques for the background graphics while using a more familiar style for the foreground elements. I'm happy with the results, which strike a good balance between time and effort, and allow players to easily distinguish between foreground and background elements.
• Using physics as a key element of the game required players to untangle webs of molecules. This led to some interesting and fun gameplay elements and taught me a lot about physics engine edge cases and designing around known limitations.
• I enjoyed creating the molecule name generator that builds a unique name depending on composition, yielding some pleasing and amusing results.

"The British Are Coming!" is a Unity game made for the 50th Ludum Dare game jam. The theme was "Delay the Inevitable," and after some brainstorming, our team quickly settled on the idea of a pirate ship trying to maintain its operations in a world where the British Empire was slowly taking over the seas.

In the game, you set sail and recruit pirates to pillage and raid locations of your choice. Each location has procedural points of interest with variable difficulties and rewards. For each successful raid, you will gain ire from the British Navy and find future destinations better guarded. It starts off with small camps and ramps up to keeps, towns, and even forts.

As the sole programmer on this project, I dove into creating my first 3D game. Our vision was ambitious, and I am still proud of the amount of features we managed to cram into this project in just 72 hours, including:

• Smart pathing to allow for navigation of hundreds of agents around dynamic objects.
• Procedural islands generated on several data points from your current playthrough.
  • For instance, raiding more British-controlled territories would increase the likelihood of military presence on future islands.
• A fully-featured tutorial to help players learn the game.
• A full menu system with UI options.
• Secrets, easter eggs, and side missions.

I cannot take credit for the incredible soundtrack, which, despite hearing it for literally tens of hours during development, I have not gotten bored with! Matt absolutely smashed it out of the park with this one.

Odd Topix is a quick party game of talking and deception. The rules are simple: fulfill your prompt and include your given words. If the other players successfully guess any of your words, you're out!

I created Odd Topix as I wanted to explore the physical manufacturing process. One of the advantages in the world of software is speed to market and iteration. Having spent my career in that world, I thought it was important to gain hands-on experience with a practical project. The lead times and costs involved in physical manufacturing really highlighted the advantages of software, and I quickly realized the benefits of using software to prototype and iterate on the game design before manufacturing the final product.

After all the work of development, the final choices of card stock, packaging type, and printing process were much more nerve-wracking and difficult than I had anticipated. Once the game was in my hands, I was so excited by the result and still find it hard to believe that this real physical product was something I created.

The question is... can you guess the Odd Topix I was given for this post?

"Shout 'Em Out" is a re-envisioning of one of my childhood favorite games. The premise is simple: each card contains a category. The opposing team simply needs to try and guess the top 10 answers to that category... the catch? You're not looking for the right answers, you're looking for the ones LLMs circa GPT-3 think are the right answers.

The game was created to explore LLMs and OpenAI's API. Although far from the models we see now, I was blown away by the demos I was seeing and wanted to experiment with it myself. I created a simple app to propose categories and parse the responses into lists of answers. This tool gave me easy access to regenerate or nudge responses, as well as to correct Americanized spelling or remove duplications.

Once I had my categories and answers, I created a React app to generate the cards using print CSS queries, easily printing off the final version. This was the day I learned that I hate styling print media :). The software allowed me to easily generate over 100 cards and iterate on the design and layout with minimal effort.

The final product was a fun game that I could play with friends and family, but also a great learning experience in the power of AI and the benefits of software in the physical world. It also taught me a valuable lesson in the capabilities and dangers of AI, most importantly the subtle (and sometimes not so subtle) biases that these models have and can represent.

Working in the environmental sector gave me key insights into the importance of creating tools to help large companies reduce their carbon footprint.

However, this involves a completely different and more corporate language than the broader, more general conversation demands. I created this pollution calculator as a tongue-in-cheek way to explore the UI and language of a simplified consumer-targeted app compared to its more dry corporate counterpart.

Although this satirical tool holds no real value and pokes fun at common tropes of the media's representation of the crisis, it does represent a very real issue in software development. When creating a tool, it is more important to engage with the user in a way that resonates with them. Being 'clever', 'technically better', or 'more accurate' is not always the best way to get engagement and adoption. Just ask Zune, Betamax, or HD-DVDs.

As employee number one I created the frontend from scratch working with stakeholders to quickly iterate on the product whilst maintaining a solid technical foundation.

• I was in charge of the architecture and implementation for all front end projects.
• Onboarded and mentored new developers
• Created a design system and component library to easily integrate with the design team
• Created am editor to allow the rest of the team to quickly and easily iterate on our bespoke schema system

When a friend bought his first 3D printer, it sparked his ambition to turn it into a business. He wanted to share the wonder of rapid prototyping with people who didn't have the space, money, or inclination to buy their own printer. When he asked me if I would be interested in helping him build a website to facilitate this, I jumped at the chance, because I had a laundry list of things I wanted to print myself but no means to do it.

We used React and Firebase to create a production app allowing people to upload and view their 3D models, select options, and order prints. Stripe integration facilitated purchases and hooked in with a bespoke backend to help manage orders and print queues. The website was a success, seeing many return customers, and the app facilitated many orders until the business was sadly shuttered for personal reasons.

This project helped me step back and understand the multifaceted benefits of software. The web app had completely different criteria and use cases than the backend tools, but both had to seamlessly work together to support the process from start to finish.

Analytics, hosting, and testing were key areas to get right in a production system to allow us to iterate quickly and safely. I'm proud to say the system supported all its transactions with no major outages or issues. I attribute this to the robustness of the tools we used and the care we took in testing the system in a specific non-production environment.

This is a product I used myself many times and still have the chopping board holder, plant pots, and frog models to prove it.

"PIBE" is a game made in Unity for the 48th Ludum Dare game jam. The theme was "Deeper and Deeper," and I collaborated with my wonderful partner (now wife). After some initial challenges, we resonated with the idea of a diver exploring for treasure and using it to upgrade their equipment to dive deeper and deeper.

I was responsible for the code and level design. What I learned from this project includes:

• The ease of designing a large map on paper compared to implementing it in code, and the value of iterative refinement.
• The power of parallax in adding polish and depth to a scene, making a world come alive.
• Creating dynamic terrain with sprite shapes along a spline.
• The significant impact of small polish elements, like the music transitioning from land to underwater with a breath sound effect.

Although we entered purely for fun I am proud of the scores we achieved with the most prestigious being voted #32 out of 3866 entries in "theme" and #239 overall!

I am also so blown away by Ami's ability to rise up to a challenge in an area she had no experience in and create such beautiful art assets in such a short time frame. Without her help this project would not have been possible.

I worked at Goodlord for 6 months as a senior frontend developer. Although I learned a lot from my experience, I ultimately realized it wasn't the right fit for me. Capable of the work, I didn’t feel either party was getting the most out of the relationship.

My responsibilities included:

• Updating legacy jQuery code to modern standards.
• Incident triage and support.
• Maintaining and improving the build process.
• Building out the self-verification process, including integrating Onfido to identify users.

This was my first official role as a senior developer, and it is where I realized how much I enjoyed mentoring and helping others. During my employment, I focused on building genuine rapport with junior developers, helping to build their confidence, providing pragmatic advice and support, as well as advocating on their behalf in senior meetings.

"Sushi INK" was a game developed in Unity for the 47th Ludum Dare game jam. The theme was "Stuck in a Loop," and I worked as the sole developer in a team of friends.

We aimed to deviate from traditional interpretations of the theme. The concept of being stuck on a sushi conveyor belt emerged and resonated with us all. This evolved into controlling an octopus making sushi with its tentacles, leading to the unique idea of a "sushi and tentacle management game."

In "Sushi INK," you control one tentacle at a time to pick, place, chop, and cook ingredients, fulfilling customer orders. The game's simplicity belies the challenge of limited reach and counter space, leading to juggling orders and tentacle tangles.

The technical heart of the project lay in tentacle movement and control, alongside creating a convincing conveyor belt. Tentacles were implemented using connected rigid bodies and joints, complemented by a line renderer for a realistic effect. Additionally, I created a tool for building conveyor belts from splines and prefabs, allowing quick visualization and generation.

I'm proud of the outcome of this game. The team's collective effort added substantial polish and finishing touches, including dynamic screen transitions, an animated score screen, and a gameplay-mechanics-driven main menu.

Matt also went above beyond by not just creating one absolute banger for a soundtrack, but an entire OST of 5 unique and varied tracks.

Anibubbles was a physics-based connect game. The objective was to connect animals of the same type in the longest possible string, with bigger combos awarding more points. The twist was that the animals were dynamic, physics-based objects that would bounce and move as more were added.

I developed this game to learn about deploying Unity to various platforms, particularly Android. What I learned was that deploying to Android can be challenging. The combination of differing Unity versions and the fragmented Android ecosystem meant that building an APK took longer than developing the game itself!

This experience taught me valuable lessons about the complexities of building for different platforms and the importance of understanding the deployment process beforehand.

"Slasher" was a game made with a friend for a self-hosted Halloween game jam. With our only limitation being to make it Halloween appropriate we quickly took inspiration from classic horror movies to make a 'slasher' game that we cleverly named "Slasher".

In this game you must pick off the holiday goers one by one without being seen. You can hide in the shadows and use the environment to your advantage.

The game included several things that were new to me at the time:

• Tilemap based level design
• Building a generic interaction system as a unity tool
• Dynamic 2d lighting
• A homemade ray-casting AI system for navigation and player detection
• Dynamic music that changes based on your actions and location

One of the biggest things we both learnt from this project was how to deal with scope creep. We had a whole slew of features and mechanics that we quickly realised needed to be cut in order to get the game finished in time. Although looking back at it, I am taken aback at just how much we managed to achieve in such a short time frame.

The music still creeps me out a little bit....

Booze bot was a collaborative project with me and Matt. The idea was simple: make a robot that could pour the perfect drink. The execution was a little more complicated. combining software, hardware, and mechanical engineering meant the challenges were near endless. From broken tubes to erratic webpages we battled our way through the obstacles and the resulting pour tasted all the better for it.

Although just a fun project with a friend, Boozebot really taught me about the implications of a cross disciplinary project. Each additional part is an entirely new surface are to go wrong and so the approach needs to be more methodical and considered.

Responsible for upkeep and implementation of new features for the webapp from ideation to implementation.

• Introduced and implemented React hooks across the product.
• set up Cypress.JS as part of Gitlab pipeline to run automated E2E tests

Smiley Slots is a slot machine I built on CodePen. I was intrigued by the challenge of using available tools in unique ways.

The idea of using emojis as graphics came to me, and I decided on a slot machine concept using CSS animations for blurring and motion. I also used the Web Audio API for simple sound effects.

One big challenge was working without the IDE features I'm accustomed to. It was a refreshing return to more basic, vanilla concepts that get abstracted in frameworks and advanced editor functions.

The experiment was a hit with friends and coworkers, and I was surprised by the high scores they achieved.

Dynamic audio always excited me, but I felt overwhelmed about where to start. This CodePen was my simple, fun attempt to explore audio generation.

Focusing on a familiar sound effect - the 'puzzle solved' or 'secret found' from games like Zelda, I broke it down into two simple rules for creating a 'curious' sound: the notes should climb and resolve higher than the first note.

This basic setup yielded surprisingly effective results. It demystified dynamic audio for me, leading to more exploration in the field.

"Press-up Coach" is an Alexa skill I created to help me get back into fitness. I wanted something that would encourage me to do press-ups every day.

A big challenge with Alexa development is optimizing voice over visuals/touch/type. Many skills don’t leverage the platform’s strengths, trying to replicate other mediums' experiences.

When considering voice-first use cases, I thought about where traditional interfaces, like phone apps, are cumbersome. For example, in the gym, constantly putting my phone in and out of my pocket was inconvenient. Though a smart speaker in the gym seemed unlikely, it inspired me to use voice for tracking spontaneous workouts like press-ups, ideal for morning exercises or work breaks.

So Press-up Coach became a virtual coach always ready to record your reps, offer encouragement, and inform you about your progress.

Exploring the web audio API and making my first bleeps and bloops on an oscillator immediately brought me back to my childhood playing with the ringtone composer on my Nokia 3310. I figured that memory would make a great way to explore this API and so I set about making a ringtone composer of my own.

Using the same Ring Tone Text Transfer Language (RTTTL) I had memories of scouring the internet for, I created a simple interface to play them.

Even years later with HD ringtones and the ability to play any song you want, there is something so satisfying about the old school bleeps and bloops of a classic ringtone.

and for extra nostalgia points (bpm 60):

8e2 8e2 8d2 8d2 2c2 8d2 4e2 2a1 8a1 4b1 4g1 4e2 8d2 4c2 8d2 2e2 4- 8e2 8e2 8d2 8d2 2c2 8d2 4f2 2a1 8a1 4b1 4g1 4e2 8d2 2c2

When making games, I stumbled across a video talking about making a game feel 'juicy'. The idea was that 80% of the work was in the polish of the game, making things shake, stretch, bounce, pop, and generally feel good to interact with. This concept immediately resonated with me, and I started trying to implement it in my games straight away.

As I saw the fruits of this labor, I started thinking about its application in areas outside game development and realized the same principles applied pretty much anywhere but were obvious in the world of web development. Not everything needed to shake and beep, but crafting a UI that was satisfying to use is the holy grail of UX.

I started looking for libraries I could reach for and documented them in a public Github repo called "Pulp" (despite hating juice with bits, I couldn't resist the pun).

When Hacktoberfest rolled around, I realized it was an excellent, low-pressure candidate for people new to the Git process to collaborate on. Not only could people get a feel for open-source contribution in an easy to implement way, but they would also be encouraged to explore new libraries that might help them in the future.

I created and gave a talk about the future of AI in business to over 400 people on the main stage at the IAFN conference. At the time, most people's experience with AI was hugely limited compared to the GPT-powered world of today. Instead of diving into the technical aspects, I focused on presenting an approachable look at how we have historically interacted with technology and worked symbiotically, instead of destructively, with it. The idea was that no one is scared of Excel, but they are glad they don't need to do as many manual tedious calculations as before and can instead focus on the bigger picture.

Using humour and lots of visuals, I guided people through a brief history of technology's innovative relationship with business and how the company of tomorrow should welcome the chance to supercharge their workforce. I ended the session with a live example and demo of tools I had made to help demonstrate these ideas and that I had implemented at my workplace.

The talk was well received, and I was invited to give it at other conferences too.

I made "World Changers" as an entry into an Amazon Alexa skills hackathon. The theme was education and inspiration. My idea was that the unique voice interface provided a great opportunity to reinforce the idea that you can't judge the impact someone will have based on trivial things like their appearance or background.

This game was a relatively simple trivia game where you had to guess the person based on a series of clues. However, each clue started with something simple like date of birth or country of origin and then gradually became more specific to their achievements. The hope was that it would paint a picture that, although those first clues could narrow it down if you had prior knowledge, on their own, they said absolutely nothing about the field, impact, or type of change they would make.

This project was a great opportunity to really focus on how we present information, the biases we all hold, and how important it is to tackle them head on.

Pet Bot was an Alexa skill I created for myself. I have a terrible memory and a lot of cats. I found myself often worried about what they could and couldn't eat and whether sharing a small piece of my food with them was ok. This always happened when eating, clearing, or preparing food when it wasn't ideal to look it up. So, instead, I created a skill that would let me ask Alexa if a certain food was safe for cats.

I also added a few other features like a cat fact and a cat name generator, and information on social habits for your pets. I then extended it to other common pets like dogs, rabbits, and hamsters.

At this time, some of my friends were really into the quiz platform Sporcle. In particular, quizzes around countries and capitals (a trend that has weirdly endured moving on to things like Globle).

Wanting to join in with this interest but being absolutely terrible at geography, I created an Alexa skill to answer once and for all who was the capital master. Even after development, I could barely tell my countries and capitals apart, but it went down a treat with the group who would switch places taking the crown every few days.

Having been working on Splain for a while, I wanted a way to showcase its power to less technical friends. And in the spirit of camaraderie, this manifested as an Alexa app called "The Opinion Minion" which would insult (or compliment) them on command.

Sitting as a thin layer of abstraction on top of a "Splain" dictionary, it was able to generate a huge variety of weird, cutting, and sometimes downright hilarious insults, as well as a few heartfelt compliments.

Here are some favorites:

"Do you think it's ok to smile like that?"

"Your life is unsightly; please stop trying."

"I don't think you should feel good about the way you walk, it's not good and makes you look awkward. Is it really a good idea to make those choices?"

"You look like someone who would be a good shoulder to cry on; I think you would make a good boss. Things would be better if you lived with me."

Living through the 2008 financial crisis and subsequently reading The Big Short, Flash Boys and Liar's Poker, I was shocked. Shocked not just by the despicable actions, functions, and mechanics on show when you peeked behind the curtain, but also by my own (and, by my estimation, quite a few others') complete opposite understanding belief of the rules and regulations in place.

I made the party game "Let's Commit Fraud!?" as a direct response to these feelings, trying to capture the absurdity of how blatant problems were by using a satirical card game to make my point.

The game loosely mirrors one of the big factors in the 2008 crash. Players are dealt a hand of cards that can consist of 'resources' and 'effects'. Resources have a value, a type, and a risk rating.

Each round, players place as many cards face-down as they want into a central pot (CDO). Players are free to add or remove cards until they come to a consensus, after which all the cards are revealed.

First, all the effect cards in the pot are activated. These might return resources to a player's hand, protect a certain type of resource, or make a player exempt from any consequences.

After that, all the remaining resources' risk factors are totaled, and if they exceed a certain threshold, the CDO is 'toxic' and will blow up, forcing any player without protection to draw a consequence card. These consequence cards affect all players' assets, even banked ones, often wiping people completely out.

When all players' cards are gone, the financial year is over, and banked assets are added to the players' score.

This gameplay provides a tantalizing opportunity to bluff, lie, and cheat your way to victory and aims to mirror the risk vs. reward mentality that was so prevalent in the real world. The obvious answer is to work together, but with the ever-looming pressure to win and the constant threat of a backstab, can you be trusted not to lawyer up and go for the jugular?

Splain holds a special place in my heart as my first real public project. It was way too ambitious for me at the time, but over a few years, I persisted and iterated until I saw the results I wanted. Although now completely superseded by LLMs, I am still proud of tackling something so unthinkably big to me at the time.

Splain is a template library to create varied and dynamic text. The basic idea is to build a dictionary of phrases correlating to tags. These could then be used recursively to build more complicated language.

(The following examples are heavily inspired by the Sims loading messages that I thought were just the funniest when I was younger.)

For example:

let Splain = require("./splain");

Splain.addEntry({
    loading: {
        message: [`loading {{loading.media}}`, `extracting {{loading.media}}`, `compiling {{loading.media}}`, `signing in`],
        media: [`assets`, `images`, `effects`, `music`]
    }

});

function showLoadingMessage() {
    console.log(Splain.process(`{{loading.message}}`));
}

setInterval(showLoadingMessage, 5000);

The output of this could be something like loading assets or extracting media, and even in this simplified case, we gain the power of permutations to turn a few words into tens of different phrases.

This can then be built on to create more complicated language. For example:

Splain.addEntry({
    message: [`{{loading.prefix?4loading.content loading.suffix?5}}`],
    content: [`{{loading.verb loading.media}}`, `signing in`],
    prefix: [`currently `, `please hold `, `skipping `],
    suffix: [`, this is the tricky part!`, `...not much longer now`, `and failing`],
    media: [`assets`, `images`, `effects`, `music`],
    verb: [`loading`, `compiling`, `extracting`]
});

Splain grew with me as an operator, being re-written in TypeScript and used to explore build tools and collaboration. Right now, it gathers dust in my GitHub history, but I look back at it fondly and see its influence in my later projects. For example, the idea for Good Morning AI was born from seeing the outputs of Splain

The examples here come from this tutorial.

You can see more examples of Splain in action:

• As a loading screen like the tutorial
• As a conspiracy generator
• As a Dr Who episode generator
• As a cult name generator
• As an alexa skill to insult or compliment you
• As a legal mastermind

As the sole representative of the innovation lab, I created software to demonstrate and explore new technologies. From VR to AI I had to assess a technology, build a proof of concept, prove a business case and present to clients.

• I represented the company giving talks to over 400 members of the IAFN and FLA.
• Created a Virtual Reality showroom for use at events and conferences.
• Built an AI powered chatbot development suite to allow clients to easily create their own chatbots.

DXJS is my first ever public library. I made it to help learn the process of publishing to NPM and gain experience with the entire development process from start to finish.

The library allows you to easily roll any arbitrary TTRPG dice, from a common d20 to a bespoke "weather" dice.

By utilizing an intermediary Abstract Syntax Tree (AST), the library can parse a string into individual dice rolls and breakdown the output.

This allows users to perform simple actions like roll("d20") or more complicated ones like roll("2d6+4d4+2") and get the results in a structured format.

Users can even add their own dice: javascript new Dice("weather", ["sun", "rain", "snow", "wind", "fog", "hail", "thunder", "lightning", "clouds", "clear skies"]); roll("weather")

Over the years it had features added including weightings and modifiers and has recently had a complete rewrite in Typescript.

Ring of Fire is a drinking game that has been around for a long time. It's a game with a lot of different rulesets and variations. I wanted to create a place where people could share their unique variants and build, share, and comment.

This was the first project where I really started to dive into front-end development. Although still PHP-based, this was my first personal project that engaged with JS as more than just an AJAX call or a simple form submission. This included a drag-and-drop interface and live previews of the rulesets

I studied engineering at the University of Nottingham with a focus on software and electronics. I graduated with a first class honours degree.

In my third year, I partnered with peers to create a report on the feasibility of wireless transmission of energy to personal devices. I was responsible for creating modelling software that helped you visualize the role and effect of structural components on electromagnetic waves. This allowed you to place devices within a virtual home and see how the signal strength was affected by the walls and furniture.

For my thesis, I partnered with Parker Hannifin to create a web-enabled control system for their drives. This user dashboard would read and write real-time data to the individual drives and allow the user to control them remotely and have a quick and convenient overview of the system and its health.

Then I Woke Up was a PHP-based website I used as my first foray into web development. Trying to ride on the coat tails of the popular "FML" formula, the site was a place for people to share their weird, bizarre or just plain bad dreams.

Although long dead, the Wayback Machine caught a glimpse of it during testing, naked without any of its styling or interactivity.

I'm falling was a simple arcade game for the Windows phone. despite its simple premise it utilised a lot of the phones features, like the accelerometer for movement and an online high score.

I'm falling was my most successful mobile game being featured in the app store in several countries.

Pop was my first foray into making a paid app. It was a simple arcade game for Windows phone but offered lots of different game modes and unlockables.

Designing a paid game presented a lot of unique challenges like maintaining two builds (one free and one paid) and making sure the free version was still fun to play. It also brought a lot of unique marketing challenges, especially on a (then fledgling) store like the Windows phone store.

Escape from bacon bay prison was my first ever entry into a game jam. It was for the Bacon game jam whose theme was "lights". Working in a pair with an artist names Josh, we decided that we wanted to make something with a unique interpretation of the theme as we were sure most entries would interpret it as light and shadow.

We chose "Lights out", the phrase used in media and popular culture for when they would switch all the lights out for the night in a prison. This manifested as a psuedo memory/action game where you spent the day period planning your escape and then the lights out period executing your plan and avoiding the guards.

Sharkbait was a small game I made in Flash. I had experience with XNA and the Microsoft platform, so I wanted to try something new and explore the difference, strengths and weaknesses of new options.

The world of Flash, Actionscript and animation was a far cry from what I was used to, but gave me a lot of perspective on different tools and the importance of selecting the right language, framework and platform for the job.

Reaction chains was my first commercially successful Windows phone game. It was an arcade game where you had a certain amount of chances to tap the screen to cause a chain reaction of explosions. The more explosions you caused the more points you got.

The game had a lot of replayability and was featured on a few Windows Phone app stores. Seeing user engagement was inspiring, and it felt like persistence in learning and honing my skills from previous projects was paying off.

Having gotten to grips with the tooling for Windows phone development I wanted to challenge myself to make something with what I'd learnt withing a constrained time frame. I decided to make a version of higher or lower as the game mechanics were simple and I could focus on the tooling and polish.

Having just watched "juice it or lose it" I was keen to spend as much time learning how to give the project the best game feel I could. This also helped me stretch my new-found skills in different ways by having to shift my perspective to see how they could be applied.

Reaction thumbs was my first ever published project. Players were tasked with tapping lights as they appeared on screen before they turned off and seeing how long they could maintain it.

Although the game had a simple and weirdly addicting charm, the goal wasn't to make the best game but to learn how to finish a project and deal with all the admin surrounding launching a product.

I still remember my nerves as I submitted the game to the store and the rush of excitement when I saw over 100 people had downloaded my little demo game. No matter what the reviews, plays or views on anything subsequent, nothing will mean as much as those 100 people did to me back then.