Bart's small website | Arcade.ly | Blog

arcade.ly now has an MCP server

2026-10-27T18:00:00Z

arcade.ly now has an MCP server. If you use an AI assistant or agent that supports MCP you can point it at https://arcade.ly/mcp and ask it about the site directly: which games there are, how to play them, who’s top of the hiscore tables, and what I’ve been writing about on here.

It’s free, read-only, and there’s no sign-up or authentication required. Everything you need to connect is on the MCP server page, which you’ll also find in the links at the bottom of every page.

Why bother?

I mean, honestly, it’s just a bit of fun really. There is no serious value to having an MCP server for this site, but not everything needs to be serious.

More and more people are finding things by using AI assistants and asking LLMs rather than searching, so I figured why not make it easy for them to find stuff on here. Whether anyone will actually use it or not, whether or not it’s useful for a small web personal site, is an entirely different matter.

But I’m a tinkerer, I like to experiment with things and, ultimately, this is just a bit of fun. Just like my plan to create a gopherspace version of the arcade.ly site is as well.

What can it do?

The server has four tools, all read-only:

list_games lists the games - currently Shoot The Rocks and Star Citadel - with what each is an homage to, where to play it, and its keyboard and touch controls.
get_hiscores returns the best scores on a game’s hiscore table, for either its Modern or its Classic variant.
list_blog_posts lists the posts on this blog, newest first, optionally only those with a particular tag.
get_blog_post returns a post in full, as Markdown.

So you can ask things like “What’s the top score in Star Citadel?”, “How do I hyperspace in Shoot The Rocks?” or “What has Bart written about perceived performance?”, and get an answer that comes straight from the site, rather than from whatever a model happened to pick up in training.

In Claude Code, for example, connecting takes one command:

claude mcp add --transport http arcadely https://arcade.ly/mcp

Making sure it can’t slow the site down

My main concern has been ensuring the MCP server, or attempts to abuse it, don’t impact the rest of the site. In particular, nobody reading my blog or playing games should ever notice the MCP server exists. arcade.ly runs on a single, modest host, and the last thing I want is an enthusiastic agent somewhere hammering an endpoint while somebody’s trying to load Shoot The Rocks so they can beat their high score.

So the server is built to cost as little as possible:

It answers everything from memory. The site already keeps each game’s hiscore table in memory, so the MCP server reads those, and never asks the backing database for anything. The blog posts come from an index that’s generated every time the site is built, and loaded once when the server starts. None of the tool calls touch storage volumes or the database, although I do count them just to see if anyone is using the MCP (I DO NOT record any personally identifiable information or do any tracking though - it’s literally just counting them).
It’s stateless. Every request gets a fresh server instance and a single JSON response. There are no sessions, no cookies, and no long-lived streams.
It’s rate limited twice: 30 requests a minute from any one address, and a separate limit across all clients together, so even in the unlikely event of loads of clients connecting at once, and assuing they’re all behaving politely and sticking within the rate limit, they can’t add up to a problem in aggregate.

I also rebuild the content index every deploy, so the server never goes stale: new posts appear immediately.

Not just MCP

While I was at it I made the rest of the site a bit friendlier to LLMs too:

There’s now an llms.txt, following the llms.txt convention: a plain summary of what the site is and where to find things. The blog has its own, listing every post, which is regenerated on every build. This isn’t a widely used standard at present so we’ll see where it goes: maybe it’ll get some traction, maybe it’ll die and I’ll remove support for it in future.
The sitemap is now regenerated on every build as well. This is something that I somehow broke some time ago when updating the build and CI processes.
robots.txt now names the AI crawlers explicitly, separating assistants that fetch a page because someone asked about it from crawlers that collect training data. I treat them the same at the moment, but that might change in future.

I’m somewhat ambivalent about what to do about the training crawlers as I haven’t fully understood whether, if the site content is in a model’s training data, that makes it more likely to be recommended by an assistant or not (and bearing in mind there’s no way to directly link something an LLM spits out due to its training back to its source). So for now I’m still allowing them to access the site but, if the load becomes too heavy, I might change that.

Try it

Add https://arcade.ly/mcp to your assistant of choice, and ask it something. If something doesn’t work, or there’s something you’d like it to do that it doesn’t, please get in touch.

Agentic Software Delivery & The End Of Source Code As We Know It

2026-09-25T12:43:17Z

Last night I went out for drinks and pizza with colleagues. As we were chatting away one person said to the group that the logical conclusion of progress in agentic development, with direct human interaction with code ever decreasing, is the complete elimination of source code. Instead agents would work directly with binary machine-readable forms because, after all, if the code will never be read by humans, why would it need to be human-readable?

An imperfect, and in some aspects debatable, view of the hierarchy of abstraction layers at which programming languages operate. Much progress in programming languages over the decades has been at higher levels of abstraction that have helped software engineers become more productive. However, when the use case justifies it, we still use languages at lower levels of abstraction. So the question is, in the era of AI, LLMs, and agents, do we still need those higher levels or will agents work more effectively if they operate directly at the binary or machine code level?

I’ve heard similar things before and they’ve never sat quite right with me. But, for various reasons, I’ve never given them much serious thought. Last night was no exception: I was several drinks in, feeling relaxed and happy, and didn’t feel like getting into an argument that I couldn’t even articulate beyond a vague sense of unease with the position. And so the conversation quickly moved on.

Today I’m sat on a train, heading home, for five hours. I’ve been re-reading The Mythical Man Month by Fred Brooks to pass the time. In doing so I’ve just encountered the reason for my unvoiced discomfort printed plain as day in the midst of chapter 16:

What does a high-level language accomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual constructs: operations, datatypes, sequences, and communication. The concrete machine program is concerned with bits, registers, conditions, branches, channels, disks, and such. To the extent that the high-level language embodies the constructs wanted in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all.

It’s that “whole level of complexity”: if we fail to eliminate it from the input to our agents, how is the cost counted?

Unless there’s a compelling reason to, reverting to a lower level of abstraction from a higher level and taking on the complexity that goes with that - feeding all of that additional information into our agent - pollutes our reasoning space. It literally enlarges the state space that reasoning has to operate within. In doing so it increases the risk of hallucination and lowers the quality and relevance of generated output because all of the additional irrelevant information competes for attention with the details and concepts that are directly relevant to the problem we’re solving.

For example, if I want an agent to change rules governing invoice approval for a certain class of supplier, what I want it to think about is approval rules, invariants, permissions, business rules and outcomes: I don’t want it to think about register allocation, memory layout, or the mechanics of marshalling and parsing HTTP requests and responses. The latter are all things that might need to happen to enable the former, but they’re not relevant to solving the business problem I have: to modify my invoice approval process to meet some new business requirement.

The same simplified invoice approval logic at three levels of abstraction, with the lines that actually express the rule highlighted. In this isolated example it seems like Python is a good match for the level of abstraction we need to work with our business rules, whereas the x86-64 code brings in all manner of extraneous detail relating to stack management and a bunch of other stuff that, whilst necessary, we don't care about so much for the problems we're considering.

If I force the agent to work at a lower level and ingest lots of extra unnecessary detail, that costs more in terms of reasoning, tokens (or their future equivalent), and time. It causes false starts, mistakes, and dead ends. Reasoning is degraded. Worse, it results in additional compaction cycles which themselves risk losing relevant information, thus accelerating reasoning degradation. That degradation translates into both financial and compute costs that are simply wasted.

As Fred Brooks pointed out in the quote above, abstracting to a higher level is beneficial because it constrains what needs to be considered. It removes all the unnecessary lower-level concepts and their details and instead allows us to focus on the core concepts and details of the problem we’re trying to solve.

That’s just as relevant for LLMs and AI agents as it is for humans.

Removing the lower-level detail cuts the complexity with which reasoning has to contend. That leads to better reasoning and higher-quality code generation. In an AI-SDLC¹ that will contribute to improved downstream reasoning and interventions, which in turn will translate into improved quality in the delivered software.

I’d argue that agentic development rewards abstraction and increases the value of patterns and practices that we’ve historically treated as aids to our own understanding and reasoning:

meaningful names
modularity
explicit contracts
strong interfaces
declarative representations
separation of concerns
local reasoning
high-level languages

These constrain and communicate intent to whoever or whatever is working on our system, whether that’s a human being or an agent.

AI doesn’t make software engineering abstractions obsolete. Instead, it shows they do more than simply overcome human limitations in understanding and cognition. Agents will be more productive using language representations and tooling at a level of abstraction that matches the problems and domains they’re working in. For many use cases that will be a higher level. This is very similar to the situation for humans.

What might happen with time is that we – or perhaps AI agents under our direction – will develop new high-level languages, along with perhaps shorthand symbolic forms, that express intent in a way that works better with those agents. That I could certainly see.

4GL ideas have long since been incorporated into programming languages that are popular today, like Python and Ruby, and that will no doubt continue. What I think is more interesting is that the field has been opened up for not just the development but the day-to-day realisation of 5GL ideas. Arguably agentic development is itself a 5GL manifestation. And much of today’s discussion and research on AI-SDLC and AI governance touches on or incorporates 5GL ideas. For example, it’s not hard to see the connection between the concept of acceptance criteria and the idea of programming by constraint. Taking things further, we might start to see higher-level representations that don’t follow the typical linear, bloated, syntax-heavy, explicit nature of many programming languages so far developed for human use. Instead we might develop alternative high-level representations that are more suitable for ingestion, reasoning, and transformation by agents. These might be constraint-based, declarative, graph-like, relational, or specification-heavy.

None of this precludes representations that are also human-readable², or human-readable projections of those representations. But the point is that we might be able to move to higher-level representations of “code” than we’ve previously been able to make effective use of, and could see rapid progress and evolution in language development to enable more effective use by agents.

Obviously this won’t impact all domains or scenarios equally: there will remain cases where lower-level languages still have relevance, such as in operating systems and embedded development. That will continue to be true regardless of whether humans or agents are writing the code.

There are also plenty of reasons why human readability will remain an important facet of source code, especially in verticals like banking, healthcare, aviation, government, defence, and infrastructure. These are all heavily regulated, and systems developed within them are often highly consequential - incorrect operation can result in financial ruin, legal jeopardy, or sometimes even physical disaster.

If humans and human-administered organisations are going to take responsibility for software and be held accountable for the consequences of its misbehaviour, then humans are going to need to be able to inspect its source representation (or a projection of it): to investigate, to understand, to audit, to govern, and to regulate.

Nobody will accept “the agent gets it” as final assurance.

Software also encodes organisational knowledge in its source code. Its version history, along with the latest snapshot, constitutes institutional memory. Software contains the results of countless decisions made about the business it operates in, the domain it models, and the wider world that it integrates with. For example, a customer cannot transfer more than X between accounts in a single transaction without triggering AML procedures. Software is an executable specification that models and reflects some part of the reality in which it runs.

We worry about loss of organisational knowledge, which can happen for many reasons: staff turnover, data loss (including loss of source code), changing supplier relationships, unforeseen disaster, or a combination of factors. Many organisations take steps to prevent such loss. Still, many of us have worked with organisations that have lost knowledge of some part of their own systems and operations, and have helped them reconstitute that knowledge. At a very basic level, when I worked on .NET Reflector I helped several customers use it during source code reconstructions for systems where the original source code had been lost - and you’ll no doubt recognise that decompilation is only the first step on that journey. Full recovery of lost knowledge is challenging and expensive work. So there’s a strong argument against making institutional knowledge inaccessible by rendering it illegible to humans simply to benefit machines: I think we can create authoritative source representations that benefit both.

However, we should avoid assuming that there’s a 1:1 correspondence between human readability and agentic tractability. It’s quite possible there will be agent-friendly representations that work incredibly well for the agents but are a real headache for us humans. In some situations it’s possible the benefits of tolerating those headaches will outweigh the costs. We’ll have to find ways to deal with that: perhaps with some form of projection, as I’ve already suggested, even if that’s not the canonical source of truth but “merely” a presentation layer for our benefit. Possibly that’s OK as long as we retain the ability for humans to inspect and understand the authoritative representation of the system.

Human readability and agentic tractability aren't necessarily the same thing, so it's not a given that what works well for humans will also work well for agents, and vice versa. But there is likely to be a sweet spot that offers benefits to both that make the trade-offs worthwhile. I suspect that sweet spot may not be so far removed from the kind of high level engineering artefacts we work with today.

I confess to a certain amount of scepticism here. I think we’ll prefer to avoid the machine-readable form as the source of truth because it could leave us having to reverse-engineer it if we find we can no longer trust that the human-readable projection represents the system accurately. I think it’s likelier that we’ll find more efficient ways to present high-level human-readable forms to agents, but that the human-readable form will remain authoritative. Tools such as compilers will continue to operate on the human-readable forms, thus preserving those forms as the source of truth.

So my overall conclusion is this: as with human software development, agentic software development argues for operating at a level of abstraction that matches the problem domain. For most software delivery scenarios, this will be at a higher level, rather than a regression to the lower-level abstractions that we worked with in the past when we had little other choice. Moreover, the need for authoritative human-readable representations of systems and their behaviour remains as strong as ever.

Footnotes

1
AI-driven Software Development Lifecycle (sometimes AI-native or AI-powered Software Development Lifecycle, or other similar variants), abbreviated to AI-SDLC, is still an emerging and immature field - so much so that even the meaning of the acronym hasn’t fully coalesced yet.

What this means is that whilst there are plenty of good resources available online, they tend to be on company websites and therefore push a version of AI-SDLC framed from the point of view of a particular organisation. They’re still valuable, but it’s obviously a good idea to draw from multiple sources. Here are a few that I’ve found useful:
2
I’m perhaps being slightly loose in my terminology when I say “human-readable”. A human can read x86 or 6502 assembler (or even a stream of hex op codes if they’ve been doing it long enough); SQL is human-readable, JSON is human-readable, a dump of an AST is human-readable (relevant from when I worked on SQL Prompt), Brainfuck is technically human-readable. But they’re not all equally pleasant or easy to read or reason about. When I say human-readable, what I mean is that a human can understand it at an appropriate level of abstraction. Going back to our invoice approval example, we’ll find that code a lot easier to understand and reason about if it’s written in Python than we will if it’s written in x86 assembler.

Why is Agentic Coding so Tiring? An Incomplete Hypothesis

2026-08-29T19:09:00Z

When AI powered coding was in its infancy - a mere 4 years ago - with the first release of GitHub Copilot, I started to use it on a Python project or two, and I kind of found it to be a sort of Intellisense++. Despite the problems it was definitely a bit better than what had gone before, but perhaps not revolutionary.

During the mania of 2023 I was leading development more than doing development, as Savanta looked to accelerate various elements of its platform and workflows with AI - from survey design and creation, fieldwork and data collection, and then through to analysis and delivery - and most of my use of LLMs was for activities other than coding.

Fast forward to 2024 and I was working at a startup using a mix of the Claude Code agent in VS Code, and then Claude/ChatGPT chat sessions. We were also using CodeRabbit for code reviews. Honestly, it was all sort of OKish, but really not that great. But even then, I started to think maybe I understand how Welsh coal miners felt in Thatcher’s Britain in the early and mid-1980s. I felt like I was about to be made obsolete. I felt like it was the end of my career.

In reality, due to reasons I’m not going to get into here, I was severely burned out and depressed. I took most of 2025 off as a result, and didn’t do much: some DIY, helping organise a local CTO group. At the end of the year I started a fractional CTO role with another startup, which I got really into for a few months from January 2026 to help get things off the ground.

In the interim a lot had changed. AI agents had got good at coding. Not flawless, but really, really good. I remember the feeling the first time I got Claude to one-shot creation of a new feature, plus tests. It probably rolled in at 1500 lines of Ruby on Rails code, and it worked almost perfectly straight away. I found about 10 bugs, many of which were UX/interactivity issues, that needed to be fixed, but I was pretty happy.

But the bigger and more important change was in me: I wasn’t burned out and uninterested any more. I was energetic, engaged, and eager to get my teeth into something. And Claude meant that I could create as fast as I could think of what I wanted to create, or so it felt. I’d still have in my mind a clear idea of the problem and how I wanted it to be solved, but I wouldn’t have to do all the typing in myself.

And that was amazing. It really helped to reignite my passion and enjoyment of building software. I thought it was great, and I still think it’s great. But 8 months in I’ve had perhaps more time to reflect on the experience and, quite simply, had more experience.

A lot of people have talked about how agentic development can be exhausting because, with a team of people, you can create far faster than you can understand everything you need to, especially when you think in terms of keeping your architecture clean and consistent so you can continue to move forward. It’s very easy to feel incredibly productive with agentic coding on an individual level whilst, at a team level, the combined effort is creating a giant mess of technical debt at extraordinary speed.

There’s definitely something to that, and I’ve experienced it. It can feel like the real danger is with engineers who weren’t the best before agentic coding because, when you add that agent, the effect seems to be to magnify all their worst tendencies - like handing a loaded machine gun to a chimpanzee. But actually AI allows people to move so quickly that even amongst teams of very able engineers, slight misalignments can rapidly amplify. The biggest challenge in many softare organisations at the moment is probably scaling agentic developing effectively whilst avoiding those pitfalls.

I think all this does credibly provide at least a partial picture that helps answer why agentic software development can feel weirdly exhausting, but I don’t think it’s the whole story.

There are at least a couple of other reasons.

The first is entirely prosaic: agentic development is still very new. Adoption is uneven and there are still plenty of engineers out there with little to no exposure because there are still plenty of organisations who haven’t adopted any level of AI as part of their software delivery practice. As with anything new, proficiency takes effort and effort is tiring, particularly when the field keeps evolving so rapidly, necessitating further effort to keep up with that evolution.

The other reason I think is legitimately true, but I don’t know to what extent this is due to the way I personally work with coding agents versus other approachs, and therefore whether or not its a common experience.

It boils down to this: I think I find agentic coding tiring because I still have to put in the effort to solve the problem in my mind, and I have to express that solution quite precisely in English (which can take anywhere from a few minutes to an hour depending on what I’m doing), but then I don’t get the sort of meditative flow state pay off of several hours or days of coding before I have to move onto the hard thinking that goes into solving the next problem. I.e., the frequency of those hard thinking sessions has increased significantly. And it also turns out that expressing requirements precisely, so that you get the results you really want, is quite a demanding and skilled discipline in its own right as well. Whereas, of course, whilst code that will execute and deliver the expected result needs to be very precise, a lot of that precision is repetitive, and the domain specific chunks of precision are spread throughout the code generated over a long session as opposed to a shorter, more focussed writing session.

As I say, this might just be the way I use agents. I can believe that any pure vibe coder would read the above and be completely unable to identify with any shred of its sentiment.

Maybe they’re right and I’m doing it all wrong. Who knows this early in the game?

But for me the process is something like:

Understand the problem and why it’s worth solving (and picking the right problems to solve is one of the most important acts in any software business that wants to succeed).
Figure out how to solve it, which might involve picking technologies, discussing different approaches with LLMs or humans (more the former for me in recent months), and deciding how to proceed.
Prompting and building a plan with the agent: expressing with fairly high precision the desired solution to the problem. Asking the agent to come up with an implementation plan, and iterating on that plan until I’m happy with it. This can sometimes take an hour or two, and involves reviewing all the changes it’s proposing to make.
Implementation: I just let the agent run in auto mode (because I’ve already reviewed its proposed changes), and have it build out the solution plus all tests.
Testing, bug fixing: here I’m using the solution myself, making sure it works the way I want, looking for any flaws, bugs, deviations in expected behaviour, and - particularly - UX snafus that haven’t been caught by tests. Also, ensuring CI runs locally without any issues.
Push, open PR and code review: whilst Copilot is reviewing the code for me, I’ll also read through it myself and make sure all the changes make sense. This obviously is more challenging the bigger the PR. I find I can digest up to about 2,000 lines of code without too much difficulty, but beyond this I start to struggle and I’m more looking at structure of changes and where those changes are than reading every line in detail (here I’m relying on the LLM code review to spot any serious problems).
Finally, once the review stage is complete, and CI passes, then we can merge. And in my world the ideal to aim for is always green CI on main === the software is ready to be deployed to production. (Note that I said ideal: making that a reality can be a long and demanding road in many situations.)

Very rarely will I say to an LLM: this is my problem, I want you to go and solve it, without having given some thought as to how I want it solved. Occasionally, when I’m tired, and/or when I’m being experimental or exploratory and there’s not too much riding on the outcome. If the outcome really matters then I tend to keep my agent on quite a short leash in terms of decision-making and really only use it as a way to do the typing out of the solution and tests, but very quickly.

I’m glossing over a lot of details here as well: pre-commit hooks, pre-push hooks, any automated checks or scans you might perform as part of your pipeline (CI is doing a lot of heavy lifting here), traceability (a massive concern in regulated industries), security, and plenty else besides.

I know these things are important but that’s not the point here. The point here is that losing the coding part of software development does, somewhat, rob us of the meditative period of typing in code that, in some ways, I always found somewhat restorative.

Maybe it’s just a case of getting used to it. I suppose time will tell.

Thank You Joan Stark

2026-08-10T03:07:41Z

I wanted to take a brief moment to thank Joan G Stark and give her the credit she deserves for her contributions to the arcade.ly site header.

Joan is a prolific ASCII artist who was very active in the early years of the web - from what I can find starting around 1996, and then up until roughly 2004. She’s been and remains hugely influential within the internet ASCII art community and is still popular to this day.

Whilst her original website(s) are long since offline, you can still find her work at:

There are lots of different styles of ASCII art and, more generally, character art, and a ton of sites dedicated to ASCII and character art. These warrant a post in their own right, and maybe one day I’ll do that.

But I wanted specifically to talk about Joan here because her style of ASCII art fits very well with the kind of aesthetic I am aiming for with this site.

The basic arcade.ly logo hasn’t changed much since 2015 or 2017, whenever I first put the site online. I used an online text to ASCII art font generator to create the logo, which gave me this:

                                 .___     .__
_____ _______   ____ _____     __| _/____ |  | ___.__.
\__  \\_  __ \_/ ___\\__  \   / __ |/ __ \|  |<   |  |
 / __ \|  | \/\  \___ / __ \_/ /_/ \  ___/|  |_\___  |
(____  /__|    \___  >____  /\____ |\___  >____/ ____|
     \/            \/     \/      \/    \/     \/

I was pretty happy with this and added a blue to green gradient that was inspired by the blue/green reflective text in the Ultimate Play the Game logo from the 1980s.

I did experiment with a pure ASCII art version of this logo on the website but I was getting frustrated with wrangling CSS, so in the end I grabbed an old Netflix template from GitHub and used that for a long time, along with a Hexo blog.

But I was never really happy with either so recently I’ve spent some time retheming the site. It’s taken longer than I’d like to get it looking the way I want it to. Being a hacker who grew up in a certain era that means a sort of hyperreal neon-soaked 1980s terminal interface pastiche (obviously). It goes with the vector games I’ve so far built. But, also, Miami Vice remains one of my favourite TV shows. I’ve always loved the way that show was lit, and many of the interior designs (particularly after dark). Cowboy Bebop and Firefly are also influences. Anything that’s set in the future but a lot of the technology is kind of antique I really enjoy.

I wanted to do more with the logo and header and I’d recently stumbled across Joan’s ASCII art gallery site via Parimal Satyal’s fun piece on Rediscovering the Small Web.

Joan’s art style fits really well with the kind of neon vibe I’m going for here because she’s quite economical. She avoids dense character fills and in favour of emphasizing outlines and contours.

She also mostly presented her work in white on black which is, (a) a great starting point given the background colours used here, and (b) makes it easy to experiment with adding my own colours to see how that looks.

So I’ve used a couple of her beach scenes from https://web.archive.org/web/20010501170149/http://www.geocities.com/spunk1111/nature.htm#beach, and have adapted them slightly for use in my header.

The first thing I wanted was some palm leaves or palm trees. I started down the leaves route, but I was struggling to either make or to find decent looking palm leaves that would fit in the space I had available. However, I really like this beach scene from Joan:

           |
         \ _ /
       -= (_) =-
         /   \         _\/_
           |           //o\  _\/_
    _____ _ __ __ ____ _ | __/o\\ _
  =-=-_-__=_-= _=_=-=_,-'|"'""-|-,_
   =- _=-=- -_=-=_,-"          |
 jgs =- =- -=.--"

I think the palm trees work well and I like the sand dune, so I wanted to keep both aspects. The water and the sun also look good, but I have a water effect - with reflections and ripples (Firefox compatible, no less!) - already, and the header scene is meant to be at night, so I removed both.

This gave me:

          _\/_
          //o\  _\/_
            |   /o\\ 
        _,-'|"'""-|-,_
    _,-"          |
.--"

From there I’ve made a couple more tweaks (added a bit more dune, added a couple more pieces of beach grass), and I’ve used that tweaked version, plus its reflection, to frame the main logo. I’ve also added colours, which I think work pretty well, and I’ve made the palm leaves occasionally wave a little bit in the breeze.

Then I wanted some twinkling stars and maybe the moon, so I turned to another one of Joan’s beach scenes. In this case a night-time scene:

            *      .         .                   .
    .                                      *         .         *
                      *            *           .-.
        *        *         .                  ( (       * 
                    .                   *      '-'
  ,\//,.\//\/.         ,\/,   ,\/.//,                       .
  //o\\/o//o\\ ,.,.,   //o\   /o\\o\\         *     .      
    |   |  |  /###/#\    |     |  |      .                 *
    |   |  |  |' '|:|    |`=.='|  |                      
jgs^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^""""""""""~~~~~~~~~~~~~~~~~~

There’s a lot I like about this - the hammock is a particularly fun detail - but I just needed the moon and some stars so I trimmed down to a couple of chunks for the left- and right-hand sides of the header:

Left:

            *      .         .
    .
                      *
        *        * 
                    .

Right:

                   .
             *         .
     *           .-.
                ( (       * 
          *      '-'

Again, I’ve made a couple of additional tweaks from there, repositioning some of the stars, adding colours, and implementing some twinkling, but this is very much a jgs creation.

I also added a sort of dimming/sparking neon effect on mouse cursor that I’m 100% sure almost nobody will notice - but I like it - and that gave me my finished header.

And now, having got it all working - and taking into account the reduced motion preference, where set - I “just” need to optimise the performance.

Thanks again Joan!

Postscript: Where is Joan now?

I don’t know. Not really.

Joan and her work were still referenced in the FAQ of the alt.ascii-art newsgroup until at least 2023. The 2023 date might simply coincide with when Google stopped archiving usenet posts, so I’d bet she’s still referenced in the FAQ today, in 2026.

Back in 2013 somebody in the same group said that she still posted ASCII art from time to time - whether that was to her website, to the group, or both isn’t clear to me. With that being said, her most recent activity that I’ve been able to find dates from 2004, and I haven’t been able to find anything later than that.

So it looks like she’s been mostly quiet online for more than 20 years. Both her Wikipedia article and her website talk about her children, who will all be grown by now, but there’s no more recent information.

Sometimes people have enough of being online, and that’s fine. I like to think that Joan is living and enjoying her life, and I’m grateful that we all still get to enjoy her art.

Not many people are mourning for Stack Overflow

2026-07-23T23:46:31Z

The other day the topic of LLMs killing Stack Overflow came up again on Hacker News. Not for the first time, and not the only place it’s been discussed - it’s been talked about a lot in different forums and channels.

And what’s notable about these discussions - given how beloved Stack Overflow used to be amongst software engineers - is the ambivalence, and sometimes the outright hostility of the conversations.

And this obviously got me thinking about my own use and experience of Stack Overflow over the roughly 18 years of its existence, and how that changed over the period.

So let me start at the beginning.

It’s hard to overstate what a breath of fresh air Stack Overflow was when it arrived on the scene in late 2008. Prior to this support and knowledge sharing was spread across a variety of channels of varying quality and effectiveness:

Usenet: ubiquitous in the pre-web 1980s, and still popular through the 1990s, but increasingly overrun by spam and bots as the 2000s wore on. I barely touched it after about 2004.
Mailing lists: still used today - for example, by Apache - and have remained popular within their niches. Lots of the archives have been lost over the years though.
IRC: for decades the standard for interactive help and discussion, now supplanted by the likes of Slack and Discord
Web forums: a real mixed bag from the likes of the paywalled (but easy to bypass) Experts Exchange, to vendor run sites like the MSDN forums, along with (then, at least) independent and community efforts like SQL Server Central, CodeGuru, DevShed, and the likes
Blogs: engineers would write about the weird issues they’d run into, and how they’d fixed them, and people would sometimes discuss in the comments (although comment spam became a real issue as the 2000s wore on) - if you were lucky, your Google search would throw up one of these posts in its results and you’d find the answer you needed

Other sources of help included standard debugging and profiling tools, the documentation (the quality of MSDN and Java documentation 20+ years ago was such that very rarely did I need the online sources), bloody minded trial and error, and your colleagues and friends.

Stack Overflow was different. I remember the launch marketing being very effective because, almost immediately it felt like, there was a strong community of smart, knowledgeable, and engaged developers on the site. It meant that even posts within the days after launch were getting plenty of answers and engagement.

And then there was the usability: for a Q&A site, Stack Overflow trounced the other options. No scrolling through posts and flipping pages in a long running support forum discussion to get the nugget of information you needed. No trawling through endless newsgroup or email discussions. The answer would be just right there at the top, immediately below the question, marked as the answer by the person who asked it.

And if you were submitting a question or a response it had a nice interface with simple to use formatting options.

Overall the presentation was clean and uncluttered, and the gamification through points and voting kept quality and relevancy high.

It felt like overnight it killed the support forum, particularly the phpBB/vBulletin style support forum, at least for widely used technologies. I barely used anything other than Stack Overflow from the moment it was launched, and I remember that sinking feeling when occasionally I’d Google something and the results would force me towards MSDN - or wherever - rather than Stack Overflow.

For the first few years it was genuinely great.

I guess I noticed things starting to change around 2013 or 2014, and the darker and more dysfunctional side of the gamification, as well as its more prosaic limitations, started to show.

I first noticed what was basically karma farming activity by a portion of the sites users. I don’t know how widespread this was but one factor that stoked this was some employers started looking at Stack Overflow scores as part of assessing job applicants for interview. I mean, great, if you want to employ someone who’s going to spend more time on garnering internet points than they’re going to spend on working for you, I suppose. But, also (and bluntly), screw you for amplifying the negative effects of gamification on Stack Overflow and helping to make it an overall less attractive place to contribute, and a less useful site to visit.

But then I also increasingly ran across questions where the accepted answer either wasn’t the best answer amongst those that had been submitted (e.g., didn’t generalise well, not future proof, fragile/hacky, etc.), or had been at one time correct but the evolution of technology had rendered it out of date and no longer best practice, or sometimes just flat wrong.

As time wore on the concentration of mod powers amongst a relatively small cadre of users, who’d amassed tens or hundreds of thousands of points, led to an elitism that made the site incredibly unwelcoming for newcomers. It engendered something that felt like a throwback to the RTFM culture of software engineering and IT from the 1980s and 1990s.

You got issues like:

superficially similar questions being closed as duplicates despite the presence of key differences that warranted separate treatment,
legitimate questions that were closed for being too subjective or opinion-based, too broad, not reproducible, even though site users wanted to discuss them,
pedantry, bikeshedding, and nitpicking - along with fighting/flaming in the comments - over often superficial issues that didn’t make a valuable contribution to the technical content of the site, or the help people received from it,
inconsistent moderation as how your question was treated depended on which “powerful” user(s) spotted it first.

Blogs like this - a relatively early piece from Stack Overflow themselves - whilst well intentioned and meant to mitigate the excesses of low effort posting, certainly contributed to the situation.

Here, for example, is a key quote from that post:

We believe asking questions on our site is a privilege, not a right. If, after a few fair attempts, you haven’t been able to prove that your contributions to Stack Overflow make it at least … not-worse … then we reserve the right to refuse your questions. If we don’t do our part to cull the bad questions, then we risk alienating the true experts who provide what really matters: the answers!

(Emphasis theirs, not mine!)

So the site became increasingly frustrating to use. It felt like it existed more to curate content than to help people, which is weird for a Q&A site. It was still useful: I found myself happy enough to refer to it, despite having to do more digging and vetting of answers. But I also found myself not wanting to actively contribute because it wasn’t worth the hassle and negativity.

Here’s a story from 2015 - I think the last time I posted - that shows how toxic and frustrating the site had become to contribute to…

I’d always been someone who found more answers on Stack Overflow than I ever posted. Even more rarely I’d ask a question. But, when I did, I’d always try and follow the spirit of the old netiquette rules of yore, do my research first, and think in terms of, if I was a support engineer trying to help with this, what would I need to know?

Because I have supported products, and we’ve all seen enough bug reports and questions come in where we can straight away tell when someone is going to be easy to help - even if they have a particularly tricky problem - versus someone who’s going to prove more challenging to help.

So I had this question about Elasticsearch. I forget exactly what it was: I think it was something to do with sort order and pagination, and we had some fairly gnarly requirements on how to prioritise matches and fields in our search results. This was at a time when the Elasticsearch documentation wasn’t great, and in fact you were actively encouraged to post on Stack Overflow and tag your question to get help if you couldn’t find an answer to your question.

So I wrote out in detail what I’d done, where I’d got stuck, what I’d read and tried to get unstuck, etc. I put in code samples, and queries - all this sort of stuff. It probably took me 30 minutes or more to pull all the information I had together into a coherent post. Then I spent some time checking it over pretty thoroughly and editing for clarity before I submitted.

So what do you think happened?

The very first comment I received was from some insufferable prick saying words to the effect of, “Oh, so you want us to do your work for you, are you going to pay us too?”

Literally, WTF dude? Why even post that? You might not want to help, and that’s fine, but if that’s the case the option to simply move on and go about your day without getting involved is always available. Especially because I had done exactly what I’d been instructed to do by Elasticsearch, and I’d followed the guidance for posting questions from Stack Overflow, and this kind of snippy smartarse no value response is what I get?

As you can probably tell, it still irritates me today (11 years later!), although I think at the time I managed to respond with relatively good grace.

Anyway, I don’t remember what the specific outcome was, other than I didn’t get a sufficiently satisfactory answer from Stack Overflow. As a result, lacking other channels or forums to find help, nor having anyone else in the organisation I was working for - or friends, former colleagues, or associates - with any knowledge of Elasticsearch, and lacking a clear picture from the documentation… I spent roughly a day layering some godawful and somewhat baroque hack on top of Elasticsearch to get the results into the shape we needed. It wasn’t the “right” way to solve the problem: I should have been able to get what I wanted using the Elasticsearch’s query syntax. But I knew it would work (and it did), and I had other high priority work I needed to move onto. The business concerned has continued to be very successful since then so, for all I know, that hack is still the working, in production solution for that search function (because I don’t think anyone would be particularly keen to roll up their sleeves and get any more deeply involved unless they really had to).

So, as I say, I think that might have been the last question I posted on Stack Overflow, and it might be my last contribution to Stack Overflow full stop.

Over the years, because of the issues above, I simply started finding Stack Overflow less and less useful. I’d find I was getting information from other sources: GitHub issues particularly, but even occasionally sites like Reddit. And then of course more and more projects started using Discord for support and discussion. I’ve never really been a big fan of Discord for this because I don’t like walled gardens and, whilst Stack Overflow is a proprietary platform, all of the information on that platform is public, indexed by search engines, and now (of course) in the training datasets of every frontier LLM provider.

Stack Overflow launched so well, and worked so well for its first few years. As I said, it was absolutely a breath of fresh air. But as time went on it felt like Stack Overflow thought their model was the last word in online Q&A and they didn’t want to evolve to address the flaws in their model. Even just making the site a bit more friendly and positive, particularly towards newcomers, would have gone a long way.

Would that have changed the outcome in the face of AI?

Perhaps. Perhaps not. But I wonder if, without all that frustration and resentment that had built up over the years in the community that were at least nominally Stack Overflow’s target audience, whether the collapse would have been so complete. If you look at the graph of new questions per day on Stack Overflow you can see that from the beginning of 2023 AI simply accelerated a downward trend that had begun maybe even as early as 2016 or 2017. And, even without that AI acceleration, if you draw a trendline along the prior decline, it looks like Stack Overflow would have been dead by 2030 or maybe 2031. That’s what makes me think there’s more than just AI at play: the rot, in terms of the attitude and cultural issues, had become entrenched 10 years ago to a point where it started to hurt that site.

In fact the site peaked in 2014, which is weird when you consider that between 2014 and now, there’s been huge growth in the number of software engineers globally (something like 2.5x growth between 2014 and 2026 according to Google), huge growth in the variety and sheer number of technologies we use (some maturation of course), including lots of new technologies, and then also massive evolution of even mature technologies. So there’s lots of questions still to be asked.

Stack Overflow is now - and the more I look at that graph the more I think it perhaps has been for a long time - a site that, like the dinosaur in A Sound of Thunder, is dead but maybe hasn’t realised it yet. It does still get a few hundred questions rolling in each day, but that’s less than 1% of its peak between 2014 and 2017.

So do I feel about Stack Overflow?

Well, as much as I’m in some ways sad to say this, there’s a part of me that sort of feels like good riddance, actually. They kind of did it to themselves. It feels a bit like just deserts.

OK. So that’s true, but it’s not the whole truth - it’s not the way I feel in the round. It’s me thumbing my nose at the vanity of the haughtily arrogant and high-handed mods who abused their fleeting powers for a time.

On the more positive side, Stack Overflow had a good run, they were very successful for a good long while (which is something many technology businesses never achieve at all, never mind sustain for year after year), and I know that the people who founded the site deservedly did very well from it - and I hope (although I don’t know) that the early employees similarly benefitted. Critically, they also - objectively - help a lot of people, probably millions of engineers all told have benefitted from what Stack Overflow built and what Stack Overflow was. And Stack Overflow continued to help them for years and years. I used it almost every day at work for probably 10 years, and was still a pretty regular user for another 3 or 4 years on top of that.

All good things come to an end. Everything we build as human beings will one day disappear. Most of it will disappear within our own lifetimes. Relatively few of us will create anything that outlasts us, except for our children. And, honestly, we need to stop feeling bad about that because it is the very nature of our existence. More than that: it is the very nature of the universe within which we exist.

Today I learned: destructuring assignment in JavaScript

2020-05-01T11:57:31Z

Today I learned a really nice piece of syntactic sugar from ECMAScript 2015 (formerly known as ES6) that I don’t believe I’ve made use of before: destructuring assignment. This breaks up a complex structure into simpler component parts. It can be used as a shorthand way of breaking up an objects members into a set of local variables that can increase legibility of your code. It also allows you to assign default values for parts that might be missing from the original structure.

Background

For arcade.ly I don’t tend to make much use of libraries on the client side. This is because, as I’ve said elsewhere, when I started building these arcade games I wanted to see how far I could get using only the APIs built directly in to web browsers. I wanted to become more familiar with the capabilities built directly into browsers.

The server is a different story: I’ve made significant use of libraries because it’s tricky to build a Node back-end of any substance without them. Also, who really wants to write services for HTTP2 support, logging, and database access themselves?

I’ve also allowed myself to slip a bit when it comes to pages that aren’t hosting games: bootstrap’s snuck in there, I’m using the AlphaDust theme for Hexo - although the blog itself is all precompiled to static HTML - and so on. For me these aren’t the fun bits to build so I defer to the excellent work of others.

When it comes to the games I only use lodash, plus Beyonk’s excellent gdpr-cookie-consent-banner. For the latter I just wanted something that would work well across all pages and, because it’s kind of fiddly and for me not that interesting, I was happy enough to use something built by others. I’ve made a few tweaks to the behaviour, but nothing major, and just load it in as a separate bundle at the very bottom of every page so it doesn’t slow down rendering.

Recently, after a friend reported a bug that I couldn’t reproduce relating to this library, I added a global error handler that simply fires error messages, line numbers, and source files wrapped up in events to Google Analytics.

What I discovered is that I had been a bit unwary in pulling the library in without looking at it in a bit more detail because its use of ES6 (and later) JavaScript syntax wasn’t playing well with Internet Explorer 11. Unbelievably IE11 still accounts for anywhere up to 2% of site users who actually play games and, whilst many of the errors wouldn’t stop them, there’s been the odd one that would, which I’ve wanted to fix. Plus, of course, I want to ensure the GDPR consent banner appears for everyone (so far I’m not bothering to hide it automatically for people outside the EU, or not covered by CCPA), and that cookies are allowed/denied accordingly.

Destructuring assignment example

IE11 was pretty unhappy about this line of code:

var { delay = 0, duration = 300, easing = identity, tick: tick$$1 = noop, css } = config;

And whilst IE11 does support some of ES2015 (see https://caniuse.com/#feat=es6), apparently destructuring assignment isn’t covered. Easy enough to fix.

Getting back to the code, what does the above line actually do? Quite a bit:

It assigns a number of local variables based on members of config
It drills in to one of those members (tick) and assigns the value of its tick$$1 field to a local variable (also called tick$$1)
It assigns default values to all local variables except css
Defaults can be any type of value: delay and duration are set to integers; easing and tick$$1 are set to functions

This short line of code is therefore equivalent to the much more verbose, and much harder to read:

var delay = config.delay || 0,
    duration = config.duration || 300,
    easing = config.easing || identity,
    tick$$1 = (config.tick ? config.tick.tick$$1 : noop) || noop,
    css = config.css;

I know which I prefer, but IE11 doesn’t agree with me unfortunately.

Some obvious and not so obvious points:

We haven’t defined identity and noop. For our purposes their values aren’t really important but, for the sake of completeness, I’ve provided definitions below
Note that the local variable names generally need to match the names of fields/members in the object being destructured: any variables that don’t will just be set to undefined unless defaults are specified (this behaviour can prove very useful though!)
It’s also possible to destructure the values in an array: see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment for an example
There’s absolutely no requirement to destructure all fields in an object or all members of an array: you can take as many or as few of them as you like

Here’s an example showing what our config object might look like to make the situation clearer:

var config = {
    delay: 200,
    duration: 500,
    easing: function gimmeSomeEase(thingummy) {
        var aResult = ...;
        // Maybe do some stuff here
        return aResult;
    },
    tick: {
        tick$$1: function () {
            // Do some other stuff here
        }
    },
    css: 'foreground-color: #AAAAAA'
};

And, as promised, here are the definitions for identity and noop functions, which we’re using as default values for easing and tick$$1:

    function noop() { }

    function identity(x) { return x; };

As you can see, destructuring assignments are a powerful technique for reducing bloat and making code more readable: enjoy using them!

JavaScript: Microbenchmarks and their pitfalls - trig, random numbers, sqrt, and lookups

2020-04-02T09:50:43Z

In the midst of all the depressing news about coronavirus what better way to cheer everybody up than with a post about JavaScript microbenchmarks. That’ll never start a flamewar, will it? But whilst I was doing some work on arcade.ly recently I thought it was worth revisiting my decision to go with lookup tables for trig functions and the like, and see if perhaps I shouldn’t instead be using functions provided by JavaScript’s global Math object instead.

Before we get into it, let’s get this out of the way: I know microbenchmarks are fraught with pitfalls. It’s super-easy to write a microbenchmark, particularly if a tight loop is involved, that any half-competent compiler or JIT will be able to optimise away to pretty much nothing, and thereby end up with incredibly skewed results.

Other people know this as well. Here’s a comment on a recent Hacker News discussion about an article that claimed "JITs are un-ergonomic":

Absolutely spot on: as pizlonator says, the antipattern is real. A few years back I read a blog post - that I wish I could still find find - that covers a similar topic as it relates to C++.

So why am I bothering to write this?

Well, because I suppose my position is that as with many things in software development and life, it’s not so simple.

A few years ago, when I first started working on arcade.ly, I made the decision to use lookup tables for common trig functions (sine, cosine, tangent), along with square roots, rather than use the built-in Math.sin(), Math.cos(), Math.tan() and Math.sqrt() functions.

(N.B., I also avoided `Math.transform()`, but I think that one's worthy of another post because this one is already going to be quite long enough!)

This made sense at the time (2015) because, back then, JavaScript performance across the different browsers and platforms varied wildly.

Chrome’s V8 engine absolutely whupped Firefox’s JS runtime (I forget the name), holding a steady 60fps for Star Citadel, where Firefox could barely manage 30fps. Safari was also capable of a smooth 60fps, as were both IE11 and Edge.

And in early 2016 when it came to the prototype version of Shoot The Rocks, whilst both IE11 and Edge were capable of running the game at 60fps (unlike Firefox), all browsers other than Chrome and Safari took forever to generate the rotated asteroid bitmaps from their vector definitions when the game started up.

The reasons for these differences go far beyond trig functions (e.g., render performance), but I was searching for any edge I could find to get better performance.

Four years later is this decision justified? Is it faster to use lookup tables? And even if it is, is it enough of a difference to make a difference?

Well, not everybody thinks so, and Darren B didn’t think so all the way back in 2012:

Taken from: https://stackoverflow.com/questions/9082040/optimization-using-a-lookup-table

Given the differences in JavaScript performance across browsers in 2012, this was demonstrably incorrect, even though it’s the accepted answer.

Note that there is some credence to the comment about cache misses, which we’ll come back to later. Still, even here, at least for some scenarios - and certainly for JavaScript - the case is overstated.

Some people even claim to have found that pre-computing is slower than using Math.sin() although in at least some cases that’s because of problems with the benchmark they’ve created. See, for example:
https://stackoverflow.com/questions/45896703/why-is-precomputing-sinx-slower-than-using-math-sin-in-javascript.

Let’s get down to business: a naïve microbenchmark

Years ago I had a copy of the 11th Edition of Scott Mueller’s excellent Upgrading and Repairing PCs (TODO: AMAZON AFFILIATE LINK HERE):

I’m not sure exactly what happened to it but I wish I’d kept it because although the hardware is long out of date (published in 1999) the philosophy behind the processes isn’t.

In particular Scott talks extensively about performance figures and specifications, and whilst these are all well and good, he points out that the only way to know how much benefit you’ll gain from a given upgrade is to install it and then measure the performance.

Another way of looking at this is that there is a gap between theory and practice, and this holds as true for software as it does for hardware.

One of the issues that this throws up - as do the comments I highlighted above - is that you need to be careful what it is you’re measuring. Even in this relatively naive example, I want to measure something that reflects the reality of my use case. So let’s look at that:

Both Shoot the Rocks and Star Citadel are versions of early vector arcade games: Asteroids and Star Castle, respectively. Such games don’t generally involve bitmap graphics - certainly not in their original incarnations - instead using vectors, which can be freely rotated and scaled, to render objects in the games.
Both use trigonometry extensively for:
- Rotating game objects, such as the player’s spaceship, asteroids, and enemies such as the cannon at the centre of the Star Sastle, or the satellites that chase down the player in Asteroids,
- Calculating and adjusting attack trajectories for enemies such as the rotating cannon, flying saucers, satellites, and homing mines,
- Controlling the maximum speed of in game objects such as the player’s spaceship, mines, flying saucers, and satellites,
- Implementing gravity effects for the black hole in Shoot The Rocks (Spacewar! inspired, rather than something from Asteroids),
- Calculating particle trajectories from rocket exhaust and explosions.
Because these are simple arcade games rather than simulations, we don’t need a great deal of precision. Still, any self-respecting Asteroids game or Star Castle clone needs to allow objects to rotate relatively smoothly, so we need a decent number of values in our lookup table. I therefore chose to support integer angles in the range 0 - 359 degrees. This is enough for smooth rotation in an arcade game but obviously nowhwere near enough for any kind of simulation or more serious use. Any non-integer values are rounded down to their nearest integer. This is something we apply to all trig operations in both games. You could even reduce precision further by, for example, using a smaller lookup table. For example, you might not need particularly high fidelity rotation and be able to get away with only storing trig function values for every 10 degrees: 0, 10, 20, 30 … 350. This would mean your array lengths would all be 36 which, even at 64-bit precision, only requires 288 bytes to cache values for each trig function. This equates to 3, 5 or 9 cache lines in your processor’s cache, depending on the size of a cache line. We’ll come back to this point later. Suffice to say for my purposes this is too much of a loss of fidelity, because I want some objects to rotate very slowly - but still smoothly - which is impossible with a small number of "stops" around the circle.
We don’t use radians because, although mathematically significant, angles expressed in radians with any precision are almost never whole numbers, and therefore do not make good candidates for array lookup indices even in JavaScript where array indices do not need to be integers. This is because modern JavaScript runtimes generally include optimised handling of arrays with integer indices. However, if we were looking at trig functions as a potential new optimisation, as opposed to re-evaluating an optimisation I put in place years ago, we might choose to evaluate the performance of radian angles versus degree angles versus degree angles with lookup tables for sin, cos, etc.

Actually the original 1979 Asteroids arcade game did *not* rotate the asteroids at all. Asteroids Deluxe, released in 1981, did add rotation but it wasn't particularly smooth. I haven't looked into the arcade code for Asteroids Deluxe enough to know whether it used a set of pre-rotated coordinates to render each rotated frame of the asteroids, or whether it calculated those coordinates on the fly using trig lookup tables. I *can* guarantee an arcade game of this vintage, with a 6502 CPU, would have used lookup tables rather than calculate trig functions on the fly!

So what we’re going to to is benchmark the performance of Math.sin versus a lookup table for every integer degree value around the whole circle. And to ensure we can actually measure elapsed time with some confidence, we’re going to go around the circle 1,000,000 times. In other words, we’re going to do 360,000,000 calculations or lookups, measure the time taken, and use the times to compare the performance.

Here’s the code:

'use strict';

(function (){
    const RADIANS_IN_A_CIRCLE = 2 * Math.PI;
    const ONE_DEGREE = RADIANS_IN_A_CIRCLE / 360;

    let lookup = [];

    for (let index = 0; index < 360; ++index) {
        lookup[index] = Math.sin(index * ONE_DEGREE);
    }

    doOneMillionLookupsAroundWholeCircle();
    doOneMillionLookupsAroundWholeCircle();

    doOneMillionCalculationsAroundWholeCircle();
    doOneMillionCalculationsAroundWholeCircle();

    function doOneMillionLookupsAroundWholeCircle() {
        let start = new Date();
        let result = 0;
        for (
            let count = 0;
            count < 1000000;
            ++count
        ) {
            for (
                let angleDegrees = 0;
                angleDegrees < 360;
                ++angleDegrees
            ) {
                result = result + lookup[angleDegrees];
            }
        }

        let end = new Date();

        let diff = end - start;

        console.log(`Sin lookup (ES2015+) result: ${result}`);
        console.log(`Sin lookup (ES2015+) time: ${diff}`);
    }

    function doOneMillionCalculationsAroundWholeCircle() {
        let start = new Date();
        let result = 0;
        for (
            let count = 0;
            count < 1000000;
            ++count
        ) {
            for (
                let angleDegrees = 0;
                angleDegrees < 360;
                ++angleDegrees
            ) {
                result = result + Math.sin(angleDegrees * ONE_DEGREE);
            }
        }

        let end = new Date();

        let diff = end - start;

        console.log(`Math.sin (ES2015+) result: ${result}`);
        console.log(`Math.sin (ES2015+) time: ${diff}`);
    }
}());

This is pretty easy to run in node or in any web browser, and I’ll provide a link to a web page that does exactly that at the bottom, once we’ve got all our benchmarks in place.

Before we go any further, note the additions on lines 32 and 57. These are present just to ensure that the loops aren’t optimised away to nothing by the runtime.

And here’s the ES5 version of the same code:

'use strict';

(function () {
    var RADIANS_IN_A_CIRCLE = 2 * Math.PI;
    var ONE_DEGREE = RADIANS_IN_A_CIRCLE / 360;

    var lookup = [];

    for (var index = 0; index < 360; ++index) {
        lookup[index] = Math.sin(index * ONE_DEGREE);
    }

    doOneMillionLookupsAroundWholeCircle();
    doOneMillionLookupsAroundWholeCircle();

    doOneMillionCalculationsAroundWholeCircle();
    doOneMillionCalculationsAroundWholeCircle();

    function doOneMillionLookupsAroundWholeCircle() {
        var start = new Date();
        var result = 0;
        for (
            var count = 0;
            count < 1000000;
            ++count
        ) {
            for (
                var angleDegrees = 0;
                angleDegrees < 360;
                ++angleDegrees
            ) {
                result = result + lookup[angleDegrees];
            }
        }

        var end = new Date();

        var diff = end - start;

        console.log(`Sin lookup (ES5) result: ${result}`);
        console.log(`Sin lookup (ES5) time: ${diff}`);
    }

    function doOneMillionCalculationsAroundWholeCircle() {
        var start = new Date();
        var result = 0;
        for (
            var count = 0;
            count < 1000000;
            ++count
        ) {
            for (
                var angleDegrees = 0;
                angleDegrees < 360;
                ++angleDegrees
            ) {
                result = result + Math.sin(angleDegrees * ONE_DEGREE);
            }
        }

        var end = new Date();

        var diff = end - start;

        console.log(`Math.sin (ES5) result: ${result}`);
        console.log(`Math.sin (ES5) time: ${diff}`);
    }
}());

As you can see, the only substantive difference is the use of var rather than let.

The reason I’ve separated ES2015+ and ES5 versions is that when I started collecting measurements I was seeting a significant discrepancy in perforance between the two syntaxes when running in node. In fact the ES2015+ version with let was something like 20x slower than the ES5 version with var when using a lookup table, and 2x slower when calling Math.sin.

I use nvm and so it turned out I was being an idiot: I was running an older version of node and just needed to switch to the latest version (13.12.0 at the time of writing) to fix that discrepancy. Happily browser performance is consistent between both syntaxes as well so there’s little reason not to use the newer syntax.

Still, I decided to include benchmarks for both syntaxes, simply for completeness.

N.B., Note the use of strict mode in both cases. I have found only small, if any, difference between running these benchmarks in strict mode versus running them in "sloppy mode". Where there were differences at all, strict mode tends to be very slightly faster. All my production code for arcade.ly uses strict mode, so for the sake of brevity (ha!), all benchmarks in this post use strict mode.

I’ve also implemented versions of these benchmarks for Math.cos and Math.tan but, to avoid scrolling blindness, I haven’t reproduced the code here. You can find it at:

Math.cos versus lookup (ES2015+): https://gist.github.com/bartread/f1160621a59fc8e2fb97be72a04094a0
Math.cos versus lookup (ES5): https://gist.github.com/bartread/69ce0b25bf0e247856cab7a420843dee
Math.tan versus lookup (ES2015+): https://gist.github.com/bartread/f72be52be74fafb9feff70560b42b8b5
Math.tan versus lookup (ES5): https://gist.github.com/bartread/47135e9f5437259d1df60bcb72262024

And here are the results of all these benchmarks:

Benchmark	Node.js / ms	Chrome / ms	Firefox / ms	Safari / ms
Sin lookup table (ES2015+)	296	321	365	297
Sin lookup table (ES5)	294	312	368	296
Math.sin function call (ES2015+)	5114	5576	4538	3605
Math.sin function call (ES5)	5163	5599	4534	3833
Cos lookup table (ES2015+)	293	323	369	297
Cos lookup table (ES5)	296	323	375	298
Math.cos function call (ES2015+)	5128	5884	4577	3818
Math.cos function call (ES5)	5134	6302	4559	4001
Tan lookup table (ES2015+)	294	340	364	304
Tan lookup table (ES5)	294	336	371	296
Math.tan function call (ES2015+)	8103	9204	5879	5358
Math.tan function call (ES5)	8086	9735	5912	5276

As we can see, depending on the trig operation being performed the lookup beats using the trig function by a factor of 12 - 29x, so lookup tables are the obvious winner, right?

No, not at all.

This benchmark is absolute nonsense: it’s incredibly naïve and deeply flawed. Let’s look at this in more detail.

Unpacking the problems with our naïve microbenchmark

The obvious is that our microbenchmark doesn’t reflect reality of our use case. Let me explain.

It does millions of sequential array lookups, which modern CPUs are very good at optimising. In particular the processor can ensure that any time we need to do the next array lookup the memory we need to read is already in the L1 cache waiting for us so we don’t need to go out to the L2 or L3 caches or, worst of all, main memory when we do our array lookups.

Moreover, our entire array of 360 64-bit floating point numbers in theory takes up less than 3K so the whole thing will easily fit into L1 cache. The memory profiler in Chrome Dev Tools suggests it’s actually a bit more than this: 4.5K, but still nowhere near enough to overflow the cache which, as an example, is 32KB (data) per core on an Intel Core i7.

This means that when we go back around to iterate over the lookup table again (and again, and again), most likely all of it is still sat in the L1 cache, since cache lines are evicted using a least-recently-used algorithm.

So of course this is going to be way faster than the browser trig functions which, after all, have to do actual work.

But our use case is video games, specifically vector arcade games, and this isn’t anything like how we’re going to access our lookup table in our game code.

We have enemies, projectiles, particles, the player’s ship, and all kinds of following and tracking behaviour between these objects all happening in every single frame, 60 times per second. All of these objects and behaviours need trig, either when they spawn, or when they move, or both. There are tons of trig lookups, or calls to trig functions, but not in a sequential fashion. In fact they’re much closer to completely random. This is much harder for the processor to optimise because its caching logic can’t predict which memory locations it will need to pull into cache next.

Now with our small lookup table in isolation that may not matter too much. But, of course, it’s not being used in isolation: plenty of other data will be flying in and out of the cache on each frame:

We two trig lookup tables - both sin and cos - not just one of them for every one of our trig calculations,
There might be hundreds of live objects on screen at any one time in our games, and data relating to all of them will flow through the cache on every frame,
More data relates to the state of the overall game, as well as controlling the behaviour of classes of objects: level, score, lives left, timestamps, metadata used to configure newly created game objects.

It’s therefore highly unlikely that our lookup tables will be able to sit undisturbed in L1 cache: there’s a good chance they’ll be evicted. This will mean cache misses the next time we use them, meaning we’ll need to go out to the L2 or L3 caches, or even perhaps main memory, to get the data we need.

That introduces much more latency.

How much? Well, as an example, here are the figures for Intel Core I7 Xeon 5500 Series processors:

Source: https://software.intel.com/en-us/forums/intel-manycore-testing-lab/topic/287236
Data source	Latency (approximate)s
L1 cache hit	~4 cycles
L2 cache hit	~10 cycles
L3 cache hit, line unshared	~40 cycles
L3 cache hit, shared line in another core	~65 cycles
L3 cache hit, modified in another core	~75 cycles
Remote L3 cache	~100 - 300 cycles
Local DRAM	~60ns (~216 cycles on 3.6GHz processor)
Remote DRAM	~100ns (~360 cycles on 3.6GHz processor)

We’re running single-threaded JavaScript so you’d hope we don’t run into too many issues with shared cache lines or remote L3 caches and DRAM but, still, you can see that the latency escalates significantly at each step as we move out through caches and then into main memory.

For the lookup our benchmark’s tight inner loop is running 360,000,000 times in 290 - 375ms. This means a single iteration runs in 0.8 - 1.04ns. This translates to 3 - 4 CPU clock cycles at 3.6GHz. Looking at the operations being performed (incrementing a count, bounds checking, and adding a value that’s probably in L1 cache to a value that’s probably in a register by the time the JIT has done its magic) I reckon that’s pretty close to as fast as a single CPU core at 3.6GHz can do 360,000,000 lookups and additions without resorting to SIMD instructions, which we don’t have access to in JavaScript. That’s discounting experimental support, of course.

By contrast the function calls for Math.sin and Math.cos bump the time for a single iteration to anywhere from 12.6ns to 17.5ns, or 45 to 63 clock cycles at 3.6GHz. Note that in this case we’re also multiplying our angle by RADIANS_IN_ONE_DEGREE to convert from degrees to radians when we call Math.sin and Math.cos. However this additional multiplication is a 1 cycle operation on modern Intel CPUs, so it will only contribute 100 - 130ms to the total runtime for the function based benchmark.

(Note that in all cases Math.tan cases takes considerably longer but isn’t actually used within any of arcade.ly’s games at present so I’ve only included it for the sake of completeness.)

In neither case are we doing anything realistic, but the lack of reality is such that it unfairly skews the results in favour of the lookup table approach. Based on the discussion above, then, we need to improve our benchmark to take into account the factors we’ve been talking about:

The fact that at runtime lookups, and calls to Math.sin and Math.cos, will occur with non-sequential angles.
The need that some use cases will have for a larger (quite possibly much larger) lookup table.
The likelihood of our lookup table being evicted from L1 cache, and possibly L2 and L3 caches as well.

We’ll deal with (1) first since it’s pretty simple to remedy.

It’s also worth bearing in mind that we’re using quite small lookup tables: 360 values is nowhere near enough where real precision is required. We can only get away with it because we’re talking about arcade games, not a simulation of our solar system (for example). If you want to do something that requires a lot more precision you’re either going to have to use the trig functions, or allocate a much bigger lookup table. How much bigger depends on the precision you need, but think thousands, hundreds of thousands, or even millions of values. What would happen to your performance if you needed a really big lookup table?

How to debug NaN and NaN propagation bugs in JavaScript

2020-02-23T09:50:43Z

Debugging NaN (not a number) related bugs in JavaScript can be frustrating. NaNs propagate, which means they can spread themselves around your data structures very quickly under some circumstances, and it can be time-consuming and somewhat tedious to track down the root cause. If you’re just building CRUD apps you may never encounter any NaN related issues, but the moment you start working on apps that involves a reasonable amount of numerical manipulation they can start to appear much more regularly. In this post I’ll share what I’ve learned through debugging numerous NaN related issues I’ve encountered whilst building games for arcade.ly.

In this post I’m going to outline some basics (e.g., what is NaN?), then work through common causes and manifestations of NaN related bugs, describe NaN propagation with an example, show how you can verify that you do have a NaN bug, and then look at three different strategies for debugging that you may find helpful.

So let’s start with the basics: what is NaN?

NaN is a special global property value in JavaScript whose value means “not a number”.

Any time you use a variable whose value is NaN in an expression, the result of that expression with be NaN, or false if it was any kind of comparison. You also can’t really do meaningful comparisons with NaN: for example, the expression NaN === NaN will always return false.

Fortunately you can check for NaN by calling isNaN(expression), which will return true if and only if the value of expression is NaN. This will come in handy later on when we look at debugging strategies.

In a typical CRUD app you may never encounter NaN, but as soon as you get into any form of numerical manipulation it’s pretty likely you’re going to run into it sooner or later.

Examples of such apps are:

Games
- Particularly anything real-time: arcade games, shooters, platformers - anything that involves real-time movement or collision detection
- Turn-based games can also experience NaN issues where numeric data is involved (RPGs, RTS games, etc.), but their slower pace tends to mean that these bugs are often easier to reproduce and debug: you can often isolate an exact sequence of steps required to reproduce a bug, especially if you can replicate a particular state in the game
- I’ve run into NaN issues in both my games, Star Citadel (a version of Star Castle), and Shoot The Rocks (a version of Asteroids) which make extensive use of arithmetic, trigonometry, along with basic mechanics and some matrices
Data visualisation
- Such apps will often take a feed of data from the back end, either on demand or in real-time: if that data is manipulated in any way beyond just throwing it at a charting library the possibility of NaN bugs creeping in exists (in theory it still exists with the library, but the probability of problems arising is much lower), and especially where custom visualisations are used

In some sense there are innumerable sources of NaN bugs but in my experience they tend to fall into a few common classes:

Divide by zero
Looking something up in an array using an index value that doesn’t exist, like a non-integral for looking up corresponding values that are approximated for their integral indices, or using a negative index rather than forcing it to positive (e.g., by adding 360 degrees)
Using an object in arithmetic rather than one of its properties (check the commit log for examples!)

1. Divide by zero

You attempted to divide a number by zero, and since the result of division by zero is undefined, the result of your division is NaN.

In some languages and platforms - notably those that are “strongly typed” - you’d see something like a DivideByZeroExeption thrown here. For example, the .NET runtime will throw a DivideByZeroException but only for integral or decimal types. It will not throw it for arithmetic involving 32-bit (float) or 64-bit (double) floating point numbers, since these have special values representing NaN as defined by the IEEE.

JavaScript is “weakly typed”, which means that any variable can be of any type, and can even change its type. For example, defining a variable as var myVariable = 1; and then following up with an assignment like myVariable = 'wibblefarb'; is entirely acceptable.

In terms of numbers therefore, JavaScript doesn’t have any distinction between integer and floating point values: strictly speaking all numbers are represented as 64-bit floating point values. These of course have that special representation for NaN. Hence, as aggravating as it may be, there is no exception or error if you do something like dividing by zero that results in a NaN.

(Worth pointing out that there’s nothing stopping JavaScript runtimes, such as Google’s V8 or Mozilla’s SpiderMonkey, from representing numbers as integers under the hood as an optimization, but exposing them as 64-bit floats when needed, but this isn’t something visible to you as a programmer.)

Nobody intentionally divides by zero, but there are plenty of ways it can happen inadvertently, so let’s look at a simple trigonometry example based on a common scenario in many games.

In both of my online arcade games there are enemies that need to track the player’s spaceship and rotate to face the player, either so they can chase the player down, or fire directly at them.

In both cases we know where the enemy is, and we know where the player is, and we need to use these facts to determine the angle of rotation required for the enemy to point directly at the player.

Here, in Shoot The Rocks (Asteroids), the flying saucer needs to know the angle it should fire at to hit the player’s space ship.

We need to know the angle A, relative to straight up, so that the flying saucer can fire at the player. In reality we’re going to add some random error to this, otherwise the game would be too hard, but we start with knowing where we should shoot. Note that Shoot The Rocks isn’t very sophisticated, so there’s no sense of the flying saucers shooting at where the player is most likely to be when the bullet reaches them: they just target where the player is now.

In the next shot, again from Shoot The Rocks/Asteroids, the satellites home in the player, so the satellite needs to know which direction to head in to eventually collide with the player’s spaceship.

TODO: SCREENSHOT HERE

Again, the angle A shows the direction, relative to straight up, that our satellite needs to be headed in.

TODO: SCREENSHOT HERE

Finally, in Star Citadel (Star Castle) the central cannon needs to track the player’s spaceship so that it can fire at the player whenever it gets a clear line of sight.

TODO: SCREENSHOT HERE

These behaviours are all slightly different, and I might talk about them in more detail in future, but the key point is finding that angle A, and this is where the trigonometry comes in.

To work out A we actually need to know both the sine of A, and the cosine of A. This is because the values of both sine and cosine are periodic oscillations: they repeat every 360 degrees and, for most values of both, there are two possible matching angles.

As you can see from the following diagram, sine is 0.5 at both 30° and 150°:

As the chart also shows, sine and cosine are out of phase by 90 degrees, so if we have the values of both functions we can unambiguously resolve the corresponding angle. In fact we really only need to know if the cosine is positive, negative or zero to be able to pick the correct angle that matches the sine.

You might remember, from a mnemonic or rhymn at school (SOHCAHTOA, or whatever), that sine and cosine are defined for angle A as follows:

\[sin A = \frac{Opposite}{Hypotenuse}\]

\[cos A = \frac{Adjacent}{Hypotenuse}\]

Both of these equations can lead to instances of division by zero where the length of $Hypotenuse$ is 0.

This will occur when the coordinates of, say, the flying saucer and the player’s ship, or the cannon and the player’s ship, are the same, because the length of the $Hypotenuse$ is defined by Pythagoras’ theorem:

\[Hypotenuse^2 = Opposite^2 + Adjacent^2\]

which rearranges to:

\[Hypotenuse = \sqrt{Opposite^2 + Adjacent^2}\]

Hopefully your collision detection will have kicked in but you can’t guarantee that this will be the case if both objects are moving fast and, of course, depending on the order in which you choose to detect collisions and select firing solutions.

Talk about classes that TypeScript can help avoid

What is NaN propagation and how does it occur?

How do you tell objectively when you have a NaN bug?

Shoot The Rocks: tips and tricks for dealing with black holes in my version of Asteroids

2020-02-01T11:26:05Z

There are a few things about the modern variant of Shoot The Rocks that aren’t really reflective of the original arcade games on which it’s based.

Shoot The Rocks is perhaps most similar to Asteroids Deluxe, which is a fairly basic evolution of the original Asteroids. We still don’t have the satellites in Shoot The Rocks yet: I do intend to add them, it’s just a case of finding the time.

The greater use of colour is reminiscent of Space Duel, and the (soon to be implemented) availability of power-ups is somewhat reminiscent of Blasteroids - although my power-ups are very much focussed on fairly simple weapons upgrades only.

I suppose I do like to think that Shoot The Rocks has its own character though, particularly when the modern variant is played. The graphics, whilst similar and very much tipping a hat to the original vector games, are different from the original, as are the game dynamics and some of the features.

For example, something that doesn’t appear in any of the arcade games or their ports, as far as I’m aware, are black holes.

Note the black hole (yes, admittedly it's blue, but I felt like it needed to be visible to keep the game fair!) below the player's ship. Note also that it's drawn a number of asteroids towards it. It took me several attempts to get this screenshot as my ship kept getting destroyed by asteroids that were being sucked in towards the black hole (see tips below).

These are very much based on the star that appeared in the grandsire of all shooters, Spacewar!, in that they implement a gravity well that influences the movement of all other objects in the game.

They add another dimension to the game, which you can either use to your advantage, or which can be your undoing, depending upon how you deal with them.

So here are some tips and tricks:

Your ship is fitted with intertial stabilisers: this is why it will eventually come to a halt when no thrust is applied. It also means that, unlike most other game objects, your ship has some capacity to resist the pull of black holes. Eventually, when that pull becomes too much, your ship will get sucked towards the black hole. You’ll notice that flying saucers are also less affected by black holes than, for example, asteroids, because they too are fitted with inertial stabilisers.
Contact with black holes is not in itself fatal, however if you get too close your ship can either be captured (albeit temporarily), or more likely accelerated around the black hole and slingshotted off unpredictably. This can leave you in the direct path of other hazards, such as asteroids or flying saucers, and lead very quickly to your demise.
It’s advisable to give black holes a wide birth, both because of their tendency to cause your ship to accelerate unpredictably, and also because they draw other objects - particularly inanimate objects such as asteroids - towards themselves. This means that you can find yourself in the middle of a vortex of coalescing rocks from which you won’t be able to escape, except by using your always risky hyperspace capability.
If a black hole is around, having fewer other objects on the screen is generally better due to the tendency for the black hole to slingshot these objects around in unpredictable ways. I.e., try to avoid a situation in which you have shot all the larger asteroids and turned them into a much larger number of smaller asteroids, otherwise you’re probably going to be quickly annihilated in a collision. Similarly, if you only have a few smaller asteroids left at the end of a level, perhaps draw out completion of that level for as long as possible, or avoid shooting too many larger asteroids when the next level begins.
If you see lots of asteroids being drawn towards the black hole at once this can be a good opportunity to quickly clean up by shooting rapidly directly at the black hole. Hopefully your shots and the asteroids will be drawn together in the black hole’s gravity well leading to mass destruction. Do keep yourself at a safe distance so you have some chance of avoiding any errant rocks that are thrown out of the gravity well towards you.

Hopefully these tips will help you effectively take advantage of the presence of black holes, without falling foul of their dangers.
Play Shoot The Rocks now to try them out.

Making gravity fun: adding black holes to Shoot The Rocks, my version of Asteroids

2020-01-25T22:15:17Z

Well, it’s been a while (!) since my last blog post here but, you know, life intervenes. Still, I’ve started working on the site and improving the games again.

I had this idea that I wanted to inject a little chaos and variety into Shoot The Rocks by adding black holes with associated gravity effects. This is something the original Asteroids didn’t have, and I don’t believe they’re in Asteroids Deluxe either. Still, I thought they might make for a fun addition.

If you want to jump straight in an see what effect this has all had on the game, just click here to play.

I want the classic version of the game to be quite close to the original arcade game so black holes only appear in the modern game variant. (I’ll probably add satellites to both classic and modern variants though because Shoot The Rocks is more like Asteroids Deluxe than the original Asteroids!)

Whilst black holes didn’t take ages to implement - really only a couple of afternoons - the road wasn’t totally straight. Much of the time was spent tweaking behaviour until it felt right: it’s more important for any game mechanic I add to be fun than it is for it to be realistic.

Gravity is obviously a real phenomenon so I did start off with a fairly realistic model, in the form of Newton’s Law of Universal Gravitation:

\[F = G\frac{m_1m_2}{r^2}\]

Where:

$F$ is the force in Newtons
$G$ is the gravitational constant
$m_1$ is the mass of our black hole
$m_2$ is the mass of whatever other game object we’re interested in
$r$ is the distance between the black hole and the other object (Strictly, I believe, it’s the radius of the circle whose origin is the centre of mass of the black hole and whose edge would intersect the centre of mass of the other object, or vice versa. Details, details, etc.)

In simple terms, the gravitational force between two objects:

Is proportional to both their masses (actually to the product of their masses)
Gets weaker the further apart the objects are: i.e., it’s inversely proportional to the square of the distance between them (known as an inverse square law)

Granted, I could have gone more realistic, but worrying about relativity or quantum gravity in a game based on something as inherently unrealistic as an homage to Atari’s Asteroids is clearly ludicrous, and Newton’s law has the advantage of being simple to get to grips with.

Also, I kind of knew from the outset that any changes to increase the fun factor would most likely to simplifications and corners cut, so it makes sense to start off with something simple to begin with. We need to get to the point where gravity effects feel like they fit in with the rest of the game which, to begin with, has very simple mechanics.

The main things to grasp are that the heavier objects are, the stronger the gravitational force between them, and the closer together they are the stronger the force is. The reverse is also true.

Hopefully that’s fairly intuitive and, as you’ll see, the specifics of the equation aren’t really that important from a playability and fun perspective.

Something else to mention is that I want gravity to affect most, if not all, objects on screen when a black hole is present:

The player’s ship
Asteroids
Bullets
Flying saucers (and other enemy craft that we might eventually implement)
Particles
Any power-up collectables we implement

Let’s get down to business and talk about how I made this work.

Simplification, simplification, simplification

Firstly, we’re going to assume that the mass of every object other than the black hole is 1. This simplifies Newton’s law to:

\[F = G\frac{m_1}{r^2}\]

Secondly, we’re going to assume that the gravitational effect of these objects on the black holes, and on eachother, is zero. I.e., black holes are the only objects that exert any gravitational influence. This massively reduces the number of calculations we need to perform.

Thirdly, as I mentioned, G is the gravitional constant. This is a very small number indeed: approximately $6.674\times10^{-11} m{^3}\cdot kg^{-1}\cdot s^{-2}$. It’s kind of aggro so we’re just going to throw it away and pretend it never existed, which yields:

\[F = \frac{m_1}{r^2}\]

We’re also going to bin off the concept of force, and substitute acceleration straight in there.

\[A = \frac{m_1}{r^2}\]

And this is really where I started with my implementation. I also precalculated everything and chucked it in a lookup table because, of course, we need to separate acceleration along the x and y axes, which requires some trigonometry.

Still, what I found sticking strictly to the inverse square law from Newton is that the gravitational influence of the black holes fell off too quickly. I could, of course, increase the mass of the black holes, but this led to absolutely out of control acceleration of objects very close to them, which also wasn’t what I wanted.

This meant I tried the following:

\[A = \frac{m_1}{r}\]

I.e., rather than an inverse square law, I simplified to a basic inverse law. Unfortunately this now meant that the gravitational effects were felt too strongly on more distant objects, which in practice was equally undesirable, and felt kind of weird.

In the end, after a bit more fiddling around, I settled on the following:

\[A = \frac{m_1}{r^{1.5}}\]

I.e., an inverse square law is an instance of a more general inverse power law, and what I’ve done here is simply to reduce the power to a level where for our purposes it gives a nice balance of stronger affect at close range versus still having some effect at greater distances.

And that means we now have some sort of pseudo-gravity effect that injects some chaos and fun, whilst also working well with the three sizes of black hole I’ve implemented (small, medium, and large). Large black holes are now just about powerful enough to capture flying saucers, but not powerful enough to permanently capture the player’s ship, which is really what I wanted.

They also exert a pleasing, but not out of control ridiculous influence on all other game objects.

As I write this I’m sat approximately 12 miles from Trinity College in Cambridge where Newton was a fellow. Were he still alive, and aware of what I’ve done here (especially given the computing power available even within the average smartphone), I imagine he might have a few stern words to say to me the next time I venture into town.

Still, if you’re of a more forgiving bent and want to have some fun by playing the game and seeing how this has all worked out then click here to play.

Enjoy!

Perceived performance part 2: load assets asynchronously or on-demand

2017-03-06T13:28:41Z

When I started my arcade.ly side-project, for such it is, I had a variety of motivations. One of them was that I was a bit fed up of all these low-rent Flash versions of classic arcade games that I’d loved as a kid tarnishing my nostalgia with their long load times, pages covered with ads (yes, there are ads on this site, because I want it to pay for itself, but I try to keep things tasteful), and generally sub-par experience.

I even felt pretty smug and superior about the idea of building games with HTML5, CSS, and JavaScript that would load instantly, or pretty close to, compared with their bloated Flash equivalents with their interminable loading progress bars. Then, of course, reality came calling, complete with its usual payload of disappointment - something I posted about in a comment on Hacker News. There I identified some fairly obvious reasons why games can take a while to load that go some way beyond “Flash is an awful nineties/noughties horrendo-tech abortion that should be blown into charred corpse fragments with dynamite”:

Loading games assets takes time, particularly on slower connections (like mobile)
- Graphics (background images, sprites, textures, logos, etc.)
- Sound effects
- Music
- Fonts
- Maps and other metadata (game objects, etc.)
Creating procedurally generated content can take a while

Now this is frustrating, because it turns out these are big problems for me in that I have a combination of downloaded assets and procedurally generated content. So how do I get around this?

It’s really a combination of two techniques:

Asynchronous loading of non-essential large assets after DOM content has loaded, and the page has rendered, which happens immediately after.
Immediate feedback to the user that something is happening upon page rendering.

Neither of these results in anything being loaded any quicker, but it does get the loading "out of the way", and at least shows the user that something is going on whilst the procedurally generated content is being created. I’ll talk about (1) in detail below, and address (2) in a follow-up post.

Now both Star Castle and Asteroids are vector based arcade games so in my versions, Star Citadel or Shoot The Rocks, we don’t need to worry about downloading any bitmaps or textures for either. The graphics for all the game objects - spaceships, asteroids, flying saucers, mines, etc. - are specified using a simple vector-based notification as JavaScript objects, so they’re just part of the source code. These specifications are just based on designs I knocked up quickly in OmniGraffle.

Using JavaScript objects is not really super-efficient in terms of space but uglify does a good-enough job of compressing them, and they’re not very large or complex anyway. The player’s ship in Star Castle is 8 blue lines, for crying out loud!

If I did have a lot of bitmaps, textures, pixel art, 3D models, or whatever, I’d probably have to load a lot of them upfront because they’d be needed to actually play the game, and there’s not much avoiding that. The one thing I could do, if I were using different graphics for different levels, for example, is load only a minimal set of graphics up front, and then load the rest on demand later on.

I also don’t have to worry about maps, which are another potentially sizeable asset. Again though, I could load them on demand for each level or area as required rather than all in one go.

This deferred loading is a big advantage over Flash games which, at least in most of the cases I see, tend to load most of their assets in one go upfront. I’m not sure if this is a necessity or just a case of bad architecture. Given my somewhat snarky "low-rent" comment earlier I’d guess at bad architectural choice. I don’t know Flash at all, but it’s quite hard to imagine that Adobe wouldn’t have included some equivalent of JavaScript’s XHR in it somewhere, to allow content to be downloaded in the background.

What I do have in terms of large assets are sound effects and music. These are obviously compressed, and I use MP3s because they have the best across-the-board browser compatibility of any compressed audio format. They also work with both the HTML5 <audo> element, required for IE11 compatibility, and the Web Audio API, which is well supported across other browsers. I’d prefer to use Ogg Vorbis because it’s more efficient but the browser support just isn’t there unfortunately.

Sound effects don’t take up much room, currently weighing in at less than 200K for both games, although that’s set to increase because I haven’t created all the sound effects I need yet.

Sadly music is a different story. Both games use three tracks: one for the title/main menu screen, another whilst playing the game, and a final track for the game over screen. These weigh in at 6-7MB total for each game on desktop, or 4-6MB for the lower quality mono versions I serve to mobile devices and tablets.

_**BEST PRACTICE: To improve REAL performance of your website across a range of devices you should consider serving more optimised assets to mobile users.**_

This is obviously problematic, particularly over lower bandwidth mobile connections. Still, whilst sound effects and music add to the experience of playing a game, they’re not actually essential: you can play the game without them. Therefore I load sound effects and music asynchronously in order of priority as follows:

Sound effects.
In-game music.
All other music.

The priority is just about the order the requests are submitted in and is most beneficial over slower connections, and those using HTTP 1.1 as opposed to HTTP2. Fortunately nowadays I only have to worry about serving HTTP 1.1 to IE11 on Windows 8.1 and earlier, and Opera Mini (which I don’t care about anyway). I decided to drop support for IE10 because, although games are/were playable, I have no reliable way to test against IE10 (and Microsoft themselves dropped support for it some time ago).

The prioritisation is somewhat obvious: sound effects are clearly the most important for the game-playing experience so it makes sense to load them first, but why load the in-game music before the title screen/main menu music?

Simply because on iOS devices web audio is disabled until it gets triggered by a user interaction, like tapping a button. I have all my buttons set up to enable audio, in addition to whatever other action they trigger. Since the first thing a player is likely to do is tap the Play button, I load the in-game music before any other music even though the title screen appears first.

This all leads to what I’d suggest is another best practice:

_**BEST PRACTICE: Any asset that isn't absolutely essential to use your website should be loaded later, or not loaded at all.**_

This shot of Chrome Dev Tools’ Network tab shows how this plays out in practice:

I’ve used Star Citadel as the example here, simply because Shoot The Rocks does a lot of image creation, and these images show up as resources in the Network tab even though they’re generated locally.

Now this is over a fairly slow WiFi connection in the Swiss Alps, which has lower bandwidth (and is somewhat laggier) than my broadband connection back home. But you can see that the DOM content is loaded, and the page rendered, in under 600ms (at home this would be less than 200ms). You can see that we don’t start loading sound effects (the bottom five rows) until after the render.

I mentioned in my previous post that I’d highlight areas where improvement is still needed, and this is one of them.

In all games it’s possible to enable or disable music and sound effects, and this can be done independently, as you can see from this screenshot of the main menu in Shoot The Rocks:

![Shoot The Rocks main menu showing sound and music configuration, with a few leftover asteroids from the previous game still floating around](/images/blog/asteroids-game-music-sfx-configuration.jpg)

Sound configuration in Shoot The Rocks - note the two toggle buttons at the bottom of the menu. In this case sound effects are enabled and music is disabled. (You can clearly tell I've been playing a game when I should have been writing this post because there are asteroids flying around behind the menu. Busted!)

Now this is grand but I really should load sound effects and music only when the corresponding setting is enabled, whereas at the moment I just load them anyway, which isn’t so great. This is particularly important for mobile users, who might be on capped or metered data plans.

Moving on, let’s take a look at some code to see how I’ve achieved this deferred loading.

Firstly, sound effects and music are just configured directly in the source code as a bunch of descriptors, which look like this:

(function () {
    'use strict';

    pinjector
        .module('starCastle')
        .factory(
            'soundConfiguration',
            [
                'baseAsteroidsStarcastleSoundConfiguration',
                soundConfiguration
            ]);

    function soundConfiguration(baseAsteroidsStarcastleSoundConfiguration) {
        var config = {
            sounds: [{
                id: 'cannonThrust',
                src: '/sounds/starcastle/CannonThrust.mp3',
                volume: 0.1
            }, {
                id: 'cannonFire',
                src: '/sounds/starcastle/CannonFire.mp3',
                volume: 1.0
            }, {
                id: 'cannonLock',
                src: '/sounds/starcastle/CannonLock.mp3',
                volume: 0.4
            }, {
                id: 'mineRelease',
                src: '/sounds/starcastle/MineRelease.mp3',
                volume: 1.0,
                rapidRepeat: true
            }, {
                id: 'mineCapture',
                src: '/sounds/starcastle/MineCapture.mp3',
                volume: 1.0,
                rapidRepeat: true
            }, {
                id: 'alienScream',
                src: '/sounds/starcastle/AlienScream.mp3',
                volume: 1.0,
                rapidRepeat: true
            }],
            music: [{
                id: 'titleMusic',
                src: '/music/starcastle/179_full_arrested-for-driving-while-mad_0159.mp3',
                srcLowQuality: '/music/starcastle/179_full_arrested-for-driving-while-mad_0159_lowquality.mp3',
                volume: 1.0,
                autoplay: true
            }, {
                id: 'levelMusic',
                src: '/music/starcastle/179_full_a-naked-gun-bank-assault_0100.mp3',
                srcLowQuality: '/music/starcastle/179_full_a-naked-gun-bank-assault_0100_lowquality.mp3',
                volume: 1.0
            }, {
                id: 'gameOverMusic',
                src: '/music/starcastle/156_full_good-ol-western_0123.mp3',
                srcLowQuality: '/music/starcastle/156_full_good-ol-western_0123_lowquality.mp3',
                volume: 1.0
            }]
        };

        baseAsteroidsStarcastleSoundConfiguration.mergeIntoMaster(config);

        return baseAsteroidsStarcastleSoundConfiguration;
    }
}());

/*
This code is licensed under the terms of the MIT License as described
in LICENSE.txt.

Copyright (c) 2015 - 2017 Bart Read, arcade.ly (https://arcade.ly),
and bartread.com Ltd (http://www.bartread.com/)

The soundConfiguration service is a per-game service, implemented by
games at https://arcade.ly, that provides configuration for sound
effects and music to the sfx service, thus allowing them to be played.
*/

Each game has its own version of this configuration.

You see the config object has two array members, sounds and music. Each of these is a collection of descriptors, most of which are hopefully pretty self-explanatory. Note that music can (but does not have to) have two sources, one of which is a lower quality file for mobile devices. Sound effects have so far been small enough that I haven’t bothered with lower quality versions, although I might support them in future.

Apart from the overall prioritisation I’ve described above, XHRs to load sounds are fired off in the order they appear in this lists, so if some sounds are more important than others they should just be listed first.

(Btw, if you’re wondering what pinjector is, it’s a very simple, and rather cruddy injector I wrote that behaves somewhat like the Angular 1.x injector. The reason for its existence is simple: when I started writing Star Citadel I was, for literally no good reason, using Angular. I quickly realised this was madness, so ditched Angular but couldn’t be bothered to rewrite all the service boilerplate. This is a decision I now regret. If you really want the source code for it you can find it here.)

And, using these descriptors, we load the sounds with something like this:

function _initialiseSoundEffects() {
    _loadSounds(soundConfiguration.sounds, true);
    _loadSounds(soundConfiguration.music, false);
}

function _loadSounds(sounds, areSfx) {
    for (var soundIndex = 0, soundCount = sounds.length; soundIndex < soundCount; ++soundIndex) {
        var sound = sounds[soundIndex];

        if (areSfx) {
            sound.elementIndex = 0;                        
        }

        service[sound.id] = sound;
        sound.gain = context.createGain();
        sound.gain.gain.value = sound.volume * soundConfiguration.sfxMasterVolume;
        sound.gain.connect(context.destination);

        _loadSound(sound);
    }
}

function _loadSound(sound) {
    var request = new XMLHttpRequest();
    request.open(
        'GET',
        os.isPhone && sound.srcLowQuality
            ? sound.srcLowQuality
            : sound.src,
        true);
    request.responseType = 'arraybuffer';
    request.onload = function () {
        context.decodeAudioData(request.response, function(buffer) {
            sound.buffer = buffer;
        });
    };
    request.send();
}

/*
This code is licensed under the terms of the MIT License as described
in LICENSE.txt.

Copyright (c) 2015 - 2017 Bart Read, arcade.ly (https://arcade.ly),
and bartread.com Ltd (http://www.bartread.com/)

The soundConfiguration service is a per-game service, implemented by
games at https://arcade.ly, that provides configuration for sound
effects and music to the sfx service, thus allowing them to be played.
*/

This is perhaps a bit more code than we need for this example (I literally copied and pasted it verbatim from the arcade.ly source) but the key point to take away is that each descriptor is populated with a gain module, which is connected to the sound destination, and then a buffer containing the sound itself, which is loaded asynchronously via XHR.

We can then play sound effects using these functions:

function _play(effect) {
    if (!areSfxEnabledFlag || !effect) {
        return;
    }

    var buffer = effect.buffer;
    if (!buffer) {
        return;
    }

    var source = context.createBufferSource();
    source.buffer = buffer;
    effect.mediaSource = source;
    source.connect(effect.gain);
    if (!source.start) {
        source.start = source.noteOn;
    }
    source.start(0);
}

/*
This code is licensed under the terms of the MIT License as described
in LICENSE.txt.

Copyright (c) 2015 - 2017 Bart Read, arcade.ly (https://arcade.ly),
and bartread.com Ltd (http://www.bartread.com/)

The soundConfiguration service is a per-game service, implemented by
games at https://arcade.ly, that provides configuration for sound
effects and music to the sfx service, thus allowing them to be played.
*/

function _playByName(name) {
    _play(service[name]);
}

Note how, if sound effects are disabled, the effect doesn’t exist, or the effect doesn’t contain a buffer (i.e., the sound effect hasn’t yet been loaded) we simply return without doing anything.

I posted a shot from the Network tab in Chrome Dev Tools showing how this all behaves, but what’s quite cool is that you can test out what happens for yourself. It really becomes much clearer if you apply throttling to simulate a slow connection, because then you can see that the games still work without sound effects and music being completely loaded. To do this, open up Chrome Dev Tools and so the following:

Switch to the Network tab.
In the Throttling dropdown towards the right of the toolbar select GPRS (500ms, 50kb/s).
Point your browser window at one of the following URLs:
- Star Citadel (Star Castle) - https://arcade.ly/games/starcastle/
- Shoot the Rocks (Asteroids) - https://arcade.ly/games/asteroids/
When the game’s menu eventually appears (which will take a while - possibly 10 seconds or more whilst the game’s JavaScript loads), click the Play button. (Btw, you may notice some JS errors in Adsense code whilst you do this; it seems that ads don’t necessarily play well with really slow connections.)

Assuming you have both sound effects and music enabled you’ll probably find that the game plays fine, but there’s no music to start off with (and it takes quite some time before you hear any). It should also be obvious that some of the sounds are missing. As you carry on playing you’ll start to hear more and more of the different sound effects as they gradually load.

So the end result is that, as much as the sound effects and music taken together are quite large assets, deferring their loading allows for a much more satisfactory experience for the user, because they can start playing the game straight away. This is despite the fact that complete loading of the game and all assets is measurably no faster than if I loaded them all upfront.

In my next post I’ll talk about how to get that key above the fold content loaded and rendered as quickly as possible so that, even though there’s still quite a lot of work to do before the page is fully loaded and interactive, the user has the impression that content has loaded and that something is at least happening.

Read the rest of this series on perceived performance:

PREVIOUS: Perceived performance part 1: what is perceived performance?

THIS POST: Perceived performance part 2: load assets asynchronously or on-demand

COMING SOON: Perceived performance part 3: load key content first and give the user immediate feedback

Perceived performance part 1: what is perceived performance?

2017-03-04T10:04:23Z

I have this talk I first gave late last year called Client-side performance for back-end developers, of which those slides are just the first iteration. A notable topic I haven’t included, is the importance of perceived performance. Yet it’s something I’m very conscious of, and I’ve been working continuously to improve it for arcade.ly. My basic question is always, “How does it feel to use this?” And this is a principle that cuts across the whole site, especially the games. I want it to feel great: I want it to feel slick, fast, responsive on all devices and browsers.

Running across this piece by Brian Jackson (formerly of keycdn) the other day brought the topic of perceived performance back to the forefront of my mind, and reminded me was something I should write about. So in this series of posts I want to cover what perceived performance is, and how I’ve improved it on arcade.ly.

OK, so let’s start off with perhaps the most important question: what is perceived performance?

Well, one way to look at it is it’s the answer to the question, “How fast does this feel?” So, it’s not about how fast some process really is, but about how fast a user perceives it as being. And so it can sometimes be surprising when real, objective, measurable performance and perceived performance don’t always correlate. Now with that being said, it should be obvious that in many cases improving real performance can often help with the perception of performance too, but sometimes you can improve perceived performance significantly without improving real performance in any way (and sometimes whilst making it slightly worse).

You might legitimately wonder why this matters but, when it comes to the web, the fact is that slower websites lead to dissatisfied visitors who don’t hang around, and fewer conversions (however you define conversion for your site). And never mind how fast it is or isn’t, if your website even feels slow, you’re going to lose out. People will vote with their attention by directing it elsewhere.

The key point I’d like to make - and I hope this isn’t too controversial - is that your users’ perception of your web app’s performance is actually more important than its real, measured performance. Like I say, perceived performance is key to a great user experience.

How have I approached this for arcade.ly? Well the first thing to say is that I have, and continue to, expend effort on making everything actually, measurably, really faster, and these are things that I’ll talk about in other posts. Beyond that, and it’s really something you do when you’re out of options for making something measurably faster, I’ve used a few tricks and techniques to improve perception:

Load assets resources out of band/asynchronously or on demand.
Load key above the fold content as quickly as possible, and give the user immediate feedback that something is happening.
Gracefully degrade the experience on slower devices to keep performance up.
Load and render key above the fold content first, delay everything else, even if this means the page load takes multiple seconds overall.

I’m going to talk about each of these techniques in more detail in the follow-up posts, so you can see exactly what I’ve done. I’ll also highlight areas where improvement is still needed (I’m nothing if not honest!).

For now though, I’m just going to leave you with this take home…

_**PRINCIPLE: Improving real performance will generally improve users' perception of performance. Where real performance improvements are not possible, selectively loading and displaying content, or otherwise indicating that activity is taking place, can improve their perception of performance even at a small cost to real performance.**_

Read the rest of this series on perceived performance:

THIS POST: Perceived performance part 1: what is perceived performance?

NEXT: Perceived performance part 2: load assets asynchronously or on-demand

COMING SOON: Perceived performance part 3: load key content first and give the user immediate feedback

Is that Star Castle in The Expanse on Netflix?

2017-02-09T19:15:56Z

A few days ago I started watching the excellent new series, The Expanse, on Netflix. They claim it as a Netflix Original, but both IMDB and Wikipedia claim it’s an Alcon Entertainment and Sean Daniel Company production, originally for SyFy, so I don’t know.

Anyway, I don’t want to say too much about it for fear of revealing spoilers. Suffice to say back in the day I was a big fan of series like Cowboy Bebop, Firefly (and, of course, Serenity), and Battlestar Galactica, and The Expanse goes some way toward scratching that itch in a way that hasn’t really happened since BSG ended. If you’re a fan of sci-fi or space opera with a bit of an edge to it I’d highly recommend you check it out.

Anyway, I’ve been watching this in the evenings for a few days, and towards the end of episode 8 I spotted something interesting on a holo-display. Here’s the shot with enough of the dialogue to set the scene:

Oh, really?

Well, you can call it whatever you like but it looks to me like your boss just busted you enjoying a good old fashioned game of Star Castle when you should have been working.

Still, it was probably worth it, don’t you think? And if you fancy a game yourself just click here.

How good is Cloudflare's Always Online™ technology?

2017-01-22T19:50:18Z

If your site goes down, exactly how good is Cloudflare’s Always Online™ technology at bailing you out?

Rather good. But…

We’ll get to the “but” in a minute. Let’s deal with the “rather good” first. Here’s arcade.ly’s homepage when the site is down:

By down, in this case I mean the service that runs the site is down, although the instance it normally runs on is up.

Now apart from that banner, which is basically an ad that says, “Cloudflare is awesome and you should use it!”, everything looks normal. I could probably get rid of that by giving Cloudflare more money, and maybe one day I will. Nevertheless, my dodgy web design skills aside (and this page is going to get a makeover), everything that should be on the homepage has loaded and is working fine because Cloudflare has been able to serve it up from its cache.

So can I play the games?

Yes, I can. My Asteroids remake, Shoot the Rocks, works fine. Here you can see it loading as if nothing is amiss:

The main menu looks a bit gimpy because the banner messes with the layout a bit, which might be more problematic on iOS than on desktop or Android, but everything still works:

And the game itself runs flawlessly, and weirdly without the banner:

Well, bless Cloudflare is all I can say to that.

There was that “but” though, so we should take a look at that because it doesn’t always work out so well. Here’s what happened when I tried to run Star Citadel, my take on Star Castle:

That’s a less happy, although completely understandable, outcome: Cloudflare simply didn’t have the page in its cache. If your site was up for a while before it went down, or you get a decent amount of traffic around the world, hopefully this doesn’t happen.

I say all around the world because, being a CDN, Cloudflare can cache your site on edge servers all over the globe but won’t cache it anywhere until somebody accesses it. This means that pages will be cached on servers located geographically nearer to people who use them (in general), but not on servers located geographically further away.

Thus in places where your site gets used a lot, hopefully people get to carry on using it even whilst your back end services or infrastructure are burning, but people in other areas won’t get the same experience, and will instead see an error.

Again, if I paid more I think could probably replace the above with some sort of branded custom error page, so choose an appropriate plan for your use case.

What will and won’t work offline?

So this all works because of the way I’ve architected the site. Almost everything you see when you visit a page or play a game on arcade.ly is static content served up by my web server or, more likely, Cloudflare. As little as possible happens on the server, which is why Cloudflare can bail me out.

If all my content were dynamically generated server side it would be a different story: I might still see a static version of the pages as last seen by Cloudflare, but nothing would really work.

In reality most sites sit somewhere in between these two extremes, and even for arcade.ly, there are things that wouldn’t work.

For example, the as yet publicly unavailable hiscore service where you can record your performance in each game for posterity and bragging rights to your friends? Totally not going to work because there’s back end infrastructure in there:

A service to record high scores - in fact ideally I’d record scores from all games and build up a gigantic league table for each game, as played in modern and classic modes, split by device, and so on,
A data store to put all of this in: right now I’m thinking SQL Azure because we’re talking about a big table of data, for which SQL is absolutely perfect (this definitely is not a document shaped problem at any rate),
A service to expose that hiscore data, or a league table if you like (or possibly we’re talking about two different views on the same data), to clients, which might be the games themselves, or other stats pages on the site, possibly in the future even dedicated mobile apps.

If the two services are deployed separately to the main website they might still be available but, if not, or if there’s a problem with the hosting infrastructure not in a million years will the above work.

That doesn’t mean you can’t record a player’s score in the meantime. There is, of course, LocalStorage or IndexedDB, so if you’ve built your site for an offline first experience, your user’s might not even notice that there’s a problem, particularly if hiscore data was loaded before the site/service went down. You can just record the player’s score and submit it later when the site is back online.

There are, of course, caveats. Any data you put into LocalStorage as plain text is incredibly easy to tamper with using tools such as the HTML5 Storage Manager All In One Chrome extension. You can use a library like lz-string to compress any data you add to LocalStorage to render it no longer human-readable, but somebody who’s committed can always copy and paste it out, decompress, edit, recompress, and then paste it back in to LocalStorage. How much you’re worried about that is something you should consider.

You can also encrypt the data using, for example, this JavaScript AES implementation. This will certainly discourage the casual hacker, but remember that the merits of cryptography in JavaScript are extremely questionable (see also here for a slightly more recent perspective). JS encryption certainly isn’t going to stop somebody who’s committed to tampering with the data.

As far as I know there’s no (supported) mechanism for accessing IndexedDB except by the site that wrote the data but, remember, this is data stored on the client so you may want to consider it suspect anyway.

LocalStorage and IndexedDB work well when whatever you store in them will eventually undergo strong validation on the server-side. It does not work so well when this isn’t the case - perhaps because the data is collected or generated in such a way that validation is very hard - and you can’t trust your users (because they want a ludicrously high score for bragging rights, for example).

Anyway, to drag this back to the point: you can offer a decent offline experience, and this will prove especially useful in scenarios where strong validation later on, when your web client can once again connect to your services, is suitable.

In some situations you’re just going to have to tell the user that certain functionality isn’t available at the moment but it will be back online soon. For example, I’d like to offer some sort of player history and stats service. I’d really like to offer people the ability to compare with their friends, and perhaps compete directly with them. Clearly, this won’t work offline, but graceful failure is an option I’ll happily embrace.

So, the verdict on Cloudflare Always Online™? Pretty good - just be aware of the limitations:

Consider where your users are: will they be able to access the pages they need? Can you use a service such as pingdom to ensure Cloudflare caches the necessary pages? (Actually, thinking about it, maybe this is something Cloudflare already offer in their Business or Enterprise plans.)
Consider how you can build an offline first experience for functionality with online requirements: can you hold data for later? Or perhaps limit functionality? Or can you at least make it unavailable gracefully by telling the user what’s going on, rather than just breaking?

And that’s it. As always, hope this was useful, and please do leave questions or comments below.

Thanks for reading!

How to run a Node.js app as a service on Ubuntu

2017-01-21T21:07:52Z

One of the things I’ve needed to do with arcade.ly for a while is start running node as a service.

It’s easy enough to run background tasks directly from bash with a command like:

sudo nohup node index.js &> /dev/null &

And if you run that command and log out of your ssh session, node will carry on running just fine in the background. But what happens if node falls over? For arcade.ly this has never happened, but that’s likely because the site hasn’t been under much stress up to now.

(By the way, if you want a detailed discussion of running bash commands in the background it’s definitely worth checking out Running Bash Commands in the Background the Right Way.)

Realistically at some point the site is going to go down, and whilst Cloudflare will to some extent bail me out, I’d like it to come back up again without a manual intervention, especially if it’s due to something as simple as the node process crapping out.

Here you can see the effect of Cloudflare’s assistance. It’s not bad but that banner (basically an advert) at the top isn’t ideal. I suspect I could get rid of that by paying for a more expensive plan.

The great thing is that you can still play the games so if you need a fix of Asteroids or Star Castle you can go ahead and fire up Shoot the Rocks or Star Citadel and they’ll (probably) still run. (I’ll blog on this topic in due course as well.)

So how do we make sure it runs as a service and recovers without intervention?

I’m running the site on an instance spun up from a bog standard Ubuntu AMI in EC2, and deploying is just a case of cloning my git repo into a new instance and running a script. Nothing fancy either: just a shell script that installs a few things, runs gulp, and copies some files around. (That’s right: no Docker. I’ll post about why later.)

These days I’m much more familiar with Windows than Linux, so had to do a bit of digging around on how to run a process as a service, but it turns out to be quite straightforward, albeit that there are a couple of gotchas, and there are two different ways of doing it, depending upon which version of Ubuntu you’re using.

Pre Ubuntu 15.04 - upstart

Due to the inevitable lag as Google’s ranking algorithm catches up with today’s technological landscape the material you’ll most likely run across first suggests going down the upstart route, which involves writing a .conf file into /etc/init. However, whilst that’s fine if you’re running an older version of Ubuntu - and as of this writing I believe Ubuntu 14 is still widespread - upstart was deprecated in 15.04 in favour of systemd and if, like me, you’re running 16.x, well, you’re out of luck. If you’ve been keeping more up to date with Ubuntu developments than I have you probably already know about this.

In theory you can still use apt-get to install upstart on later versions of Ubuntu but this isn’t something I’d recommend due to reports of serious problems after doing so.

Still, if you are in the old world you can use upstart, and I’d recommend this gist from Jobsamuel Núñez as a guide.

I followed these instructions and the only thing I did differently was to redirect to /dev/null because all my logging is sent to loggly because I don’t want to manually manage log files. You can see this under the script section here:

description "Arcade.ly node.js server"
author      "Bart Read"

# used to be: start on startup
# until we found some mounts weren't ready yet while booting

start on started mountall
stop on shutdown

# automatically respawn

respawn
respawn limit 99 5

script
    
    export HOME="/root"
    exec /usr/bin/node /home/ubuntu/arcade/build/production/index.js >> /dev/null 2>&1

end script

post-start script
   
   # optionally put a script here that will notifiy you node has (re)started
   # /root/bin/hoptoad.sh "node.js has started!"
   
end script

Note the respawn settings. This tells upstart to try and respawn the process up to 99 times at 5 second intervals. If the service can’t be restarted after 99 tries, upstart will give up.

Ubuntu 15.04 and later - systemd

This is no more difficult that using upstart. In fact, in some ways it’s a bit easier. Full instructions at https://www.axllent.org/docs/view/nodejs-service-with-systemd/. Just skip over the node server section at the top and start reading the systemd section. I had only two issues.

The first was simple: I needed to prefix all the systemctl commands with sudo, otherwise it would ask me for a password, which I don’t have because I log in with ssh. Here’s an example:

sudo systemctl enable arcadely.service

The second was that when I first started the service, whilst all my 301 permanent redirects were working fine, none of the site content would load - everything was coming back with 404 - Not Found. This turned out to be because the working directory of the service process is set to / by default, and thus when express.js tried to serve up content relative to this folder it inevitably failed. This is easily fixed by setting the WorkingDirectory property in the descriptor, as you can see here:

[Unit]
Description=Arcade.ly Node.js Server
#Requires=After=mysql.service       # Requires the mysql service to run first

[Service]
ExecStart=/usr/bin/node /home/ubuntu/arcade/build/production/index.js
Restart=always
RestartSec=10                       # Restart service after 10 seconds if node service crashes
StandardOutput=syslog               # Output to syslog
StandardError=syslog                # Output to syslog
SyslogIdentifier=arcadely-nodejs-server
#User=<alternate user>
#Group=<alternate group>
#Environment=NODE_ENV=production PORT=1337
WorkingDirectory=/home/ubuntu/arcade/build/production

[Install]
WantedBy=multi-user.target

Note also the restart settings - this is what tells systemd to bring the service back up again if it fails.

The following bash fragment shows how I’m installing the service.

#! /bin/sh

# Other deployment actions here. Want to install (or bounce) service last.

if [ -f /etc/systemd/system/arcadely.service ]; then
    sudo systemctl stop arcadely.service
    sudo systemctl disable arcadely.service
else
    sudo \cp -f ./arcadely.service /etc/systemd/system/arcadely.service
fi

sudo systemctl enable arcadely.service
sudo systemctl start arcadely.service

You can see that after I’ve installed it once, I don’t bother installing it again (which is just a file copy), but I do bounce it so that node picks up any changes that have just been deployed. I could use nodemon for this, and not bother with the bounce, but I’ve found that sometimes nodemon can sometimes get stuck and require manual intervention if the app it’s monitoring crashes due to restarting in the midst of a deployment, which can easily happen if the deployment takes longer than usual, for some reason. I do still use nodemon during development, in concert with a gulp watch task.

I might change this so that it copies the service descriptor every time, in case there are changes. This is likely to be infrequent but it means I never have to think about it again, which is a bonus.

The only thing is, when the service descriptor changes you generally need to do a reload of the systemctl daemon:

sudo systemctl daemon-reload

Don’t worry - if this is necessary you’ll be prompted. There’s no guesswork. In any case, I’ll probably automate this away by adding it to the script.

Anyway, I’m now in a position where I can reliably deploy to a vanilla Ubuntu AMI with all dependencies in just a couple of minutes. This includes time to compile Python 2.7.13, which is the lengthiest operation.

I hope the above tips come in useful!

EDIT - 24 Jan 2017: systemd local root exploit in v228

There’s been some noise today about a local root exploit in systemd v228. I first picked this up on HackerNews, and you can find the original report here.

This has been fixed in later releases (and note the controversy about the stealthy way that happened), but you can check if your systems are vulnerable using one of the following commands to check your systemd version. Which command you use depends on which distro you’re using:

init --version
systemd --version (Ubuntu, at least v16.04; Debian Jessie; Mint 18)
systemctl --version (Fedora)

For example, here’s the output for arcade.ly’s production instance:

ubuntu@HOSTNAME:~$ systemd --version
systemd 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

If in doubt just try them all until you find the one that works.

Welcome to the arcade.ly blog

2017-01-20T21:00:00Z

Welcome to the arcade.ly blog, where we’ll be talking about games, game dev, and web performance.

All our games are built with HTML5, JavaScript, and CSS. That’s right: no Flash. Which means they work on mobile and tablet, as well as desktop and laptop.

So far we only have a couple of games:

Shoot the Rocks! - our take on the 1979 arcade classic, Asteroids
Star Citadel - an homage to another vector classic from 1980, this time Cinematronics’ Star Castle

We hope you enjoy playing them!

For anyone who’s interested, our behind the scenes tech stack is express.js and node.js running on Bitnami, currently in Amazon Web Services’ with Cloudflare as CDN. The blog is generated by Hexo using the excellent alpha-dust theme from Jonathan Klughertz.

We recommend you subscribe to our Atom feed for posts and updates on new game releases.

Licensing and attributions

2017-01-01T00:00:02Z

Licensing arcade.ly games

You MUST license the use of arcade.ly games if you wish to do any of the following:

Host, embed, or otherwise include any arcade.ly games in a website other than arcade.ly,
Provide access to arcade.ly’s games in any public venue or as part of any commercial enterprise,
Build or offer any product or service for sale that includes any arcade.ly games,
Use arcade.ly games or footage of arcade.ly games in any kind of media or presentation intended for consumption by anyone other than yourself,
Use arcade.ly games in any other commercial context.

You MUST also get permission for any public, party, or group use even in a non-commercial context.

Please contact the webmaster with a brief description of how you intend to use the games for more information.

Credits and attributions

For all games

Game Design, Graphics, Sound Effects, Programming and Infrastructure - Bart Read
Additional Sound Effects
- NewWallSwitchON by cbakos used under the terms of the Creative Commons Attribution License. The original sound effect from Freesound is a WAV: for the purpose of browser compatibility arcade.ly has re-encoded it as an MP3.
Hiscore name filtering
- Uses the List of Dirty, Naughty, Obscene, and Otherwise Bad Words by Shutterstock and its contributors, used under the terms of the Creative Commons Attribution 4.0 International License. arcade.ly uses a subset of its languages, leaves out some terms that are ordinary words in other languages, and adds lists of its own.

Star Citadel

Music
- Title Music: Arrested for Driving While Mad by Francesco D’Andrea, licensed from PremiumBeat
- In Game Music: A Naked Gun: Bank Assault! by Francesco D’Andrea, licensed from PremiumBeat
- Game Over Music: Good Ol’ Western by Haim Mazar, licensed from PremiumBeat

Shoot The Rocks

Music
- Title Music: Renegade by Gyom, licensed from PremiumBeat
- In Game Music: Ready to Strike by Brightside Studio, licensed from PremiumBeat
- Game Over Music: Lonely Days by The Commandeers, licensed from PremiumBeat

Privacy and compliance

2017-01-01T00:00:01Z

Privacy notice

arcade.ly respects your privacy. All information you give us is held with the utmost care and security.

Please take time to review this privacy policy as it sets out our privacy practices and tells you how your personal information will be treated by us. We do not sell, rent or loan any identifiable information regarding our users or customers to any third party. Only in the circumstances described within this Privacy Policy would we share your information with any third party.

Our use of personal data is in accordance with the General Data Protection Regulations 2016 (GDPR).

How arcade.ly uses your information

arcade.ly will not collect any personal information about individuals except as set out in this privacy policy.

When you play our games, the personal information we collect and keep with each score you submit is:

the game you played and your score
the name shown alongside your score: either the randomly generated nickname we assign to your session or, if you choose one, a name of your own (we always keep the generated nickname with the score, even if you change the name shown)
the country you submitted the score from, as determined from your IP address by our content delivery network, Cloudflare - we store only the two-letter country code with your score, never your IP address itself
the browser and device you were playing on (your browser’s user agent string and platform)

Our hiscore tables are public: anyone can see the name, score, country flag, type of device (computer, phone, or tablet), and date of each score in them. Because they’re public, names are checked automatically for profanity (in English and many European languages): a name that fails the check is replaced with your generated nickname, and we may hide any hiscore whose name is offensive.

We will use the personal information provided to us in order to:

present you with information regarding games you’ve played, such as hiscore tables for each game
monitor usage patterns, errors and performance of the site across different geographies, browsers and form factors to help us diagnose problems with the site and make improvements that offer you a better experience

Certain information is collected automatically, as described later in this privacy policy.

Third-parties and their sites

Points covering all third parties

arcade.ly is served through Cloudflare’s content delivery network, which, as part of handling each request, tells us the country it came from - see “Specifics of handling log files and IP addresses”, below, for how we use that.

Where our services make use of hosted tools, hosted data storage and payment services provided by third parties any of your personal information stored by such third parties shall be subject to their privacy provisions.

Whilst we choose our business partners carefully, unfortunately we cannot be responsible for their privacy policies and practices or those of other sites that you access using links from our site. Therefore we recommend that you check the policy of each site you visit.

The following is a list of links to the privacy policies of partner sites and services we use:

GoatCounter: https://www.goatcounter.com/help/privacy
Loggly: https://www.loggly.com/about/privacy-policy/
Cloudflare: https://www.cloudflare.com/privacypolicy/

In addition, if you linked to arcade.ly from a third party site, we cannot be responsible for the privacy policies and practices of the owners or operators of that third party site and recommend that you check the policy of that third party site and contact its owner or operator if you have any concerns or questions.

How arcade.ly uses analytics

arcade.ly uses GoatCounter to monitor usage of the site and games, replacing the Google Analytics service we used previously. We use the data it collects to improve your experience, and to help diagnose and fix user experience issues and bugs.

GoatCounter is designed with privacy in mind: per its own published privacy policy, it doesn’t use cookies to track you, and it doesn’t store your IP address, full User-Agent header, or any other tracker ID. GoatCounter’s own position is that it “probably doesn’t require a GDPR consent notice” for this reason, though this isn’t a legal conclusion we’re making ourselves - see their privacy policy, linked above, for the full detail.

We also use GoatCounter’s event-tracking feature to record specific interactions within our games (e.g. starting a game, completing a level, submitting a hiscore) so that we can understand whether players are able to play and complete our games properly.

Our MCP server counts its tool calls (e.g. looking up a game’s hiscores, or reading a blog post) as GoatCounter events too, so that we can see whether, and how, it’s used. These are sent from our server, not your browser, and never include your IP address or User-Agent header. Each records only which tool was called, what for (e.g. which game, or which post), and the name of the MCP client that called it (e.g. the AI assistant). The same details go in our server logs.

Specifics of handling log files and IP addresses

When you visit our website, we automatically log your IP address, which is recognized by our web server.

We use IP addresses:

To help us administer arcade.ly sites - specifically to ensure we provide a good service to users across the globe - and to collect broad demographic information for aggregate use and to track your engagement with us,
To isolate and prevent abuse of our website that might compromise security or degrade the experience we can offer to legitimate users,
To record the country each score in our hiscore tables was submitted from. Cloudflare determines the country from your IP address and passes us only a two-letter country code: that code is all we store with your score - your IP address is never stored in our hiscore database.

In the case of (1) and (2) records may be stored for up to 7 days. In the case of (3), the country code is kept with your score, along with the rest of its record, indefinitely.

Non personal information

arcade.ly may share non-personal aggregate or summary information regarding its customers with partners or other third parties, such as information relating to the number of users linking to our website from their sites but arcade.ly does not sell or share any information at the individual level.

We also use non-personal aggregate or summary information to monitor use of the site, which helps us to identify and fix problems as they occur.

Cookies

Introduction to cookies

Cookies are very small text files saved to your computer and used to track session information and user navigation around a website. However, from a legislative point of view the term “cookies” covers the following

Cookies: very small text files stored on computer, as described above
Web storage (formerly known as isolated storage): another storage mechanism that allows storage of data on your computer in the form of key/value pairs
IndexedDB: allows storage of more complex, structured data on your computer

Many website still just use cookies, but more complex websites and web applications will often use web storage or IndexedDB to store information about the state of the site or application, or to support offline operation.

arcade.ly uses a mixture of cookies and web storage for a variety of purposes, described below, but from the point of view or PECR and similar legislation, both mechanisms fall into the category of “cookies”.

arcade.ly only uses essential cookies, and doesn’t use cookies for advertising, tracking or analytics.

How arcade.ly uses essential cookies

Essential cookies are those that are absolutely required for the site to work properly. Without them the site would malfunction in ways that would make it very difficult or frustrating to use.

arcade.ly uses three types of essential cookie:

A session cookie that is used to keep track of information related to your session: your games, hiscores, and validation/anti-cheating functionality.
A cookie that records that you’ve seen and agreed to our cookie notice. If we didn’t do this we’d have to show it to you every time you visit the site, which would get pretty annoying.
Your site and game preferences: whether music and sound effects are enabled, and the visual settings you choose on our settings page. These are only stored when you change a setting, and stay on your device: they’re never sent to us or anyone else. Strictly, arcade.ly uses web storage for this but, as previously stated, from a legislative perspective web storage falls into the “cookie” category.

Because these only remember the choices you make, they count as essential and can’t be turned off. If you’d rather they weren’t kept, you can clear this site’s data in your browser at any time: everything will go back to its default settings.

Your rights

Under the GDPR, you have rights as an individual which you can exercise in relation to the information we hold about you:

Confirmation of personal data that is being processed
Access to your personal data
Other supplementary information as referred to (the information provided in our privacy policy)

If you object to the way we are processing your data, or would like us to erase your personal data, contact webmaster@arcade.ly.

Complaints and queries

arcade.ly tries to meet the highest standards when collecting and using personal information. We take complaints very seriously. If you feel our collection or use of information is unfair, misleading or inappropriate, we encourage you to bring this to our attention. We also welcome any suggestions for improving our procedures.

If you have any questions regarding this policy, or wish to make a complaint about the way we’ve handled your personal information, contact webmaster@arcade.ly.

If you are unhappy with how we have used your data, you can complain to a supervisory authority. In the UK, this is the Information Comissioner’s Office.

Reporting security issues

We have implemented technology and policies to help safeguard your privacy from unauthorized access and improper use. For example, arcade.ly itself exclusively communicates over HTTPS, and our servers are firewalled and protected appropriately.

If you become aware of a security vulnerability in any of arcade.ly’s services or websites, contact webmaster@arcade.ly.

We encourage the responsible disclosure of security issues, and will act quickly on any vulnerabilities reported. We will not take legal action against you if you:

Provide us with the information needed to reproduce and validate the vulnerability
Avoid violating the privacy of our customers, staff and other users
Avoid the destruction of data, or degradation of our services
Do not modify or access data that is not your own
Give us a reasonable time to address the issue before making any information public

Changes to this privacy policy

We regularly review our privacy policy. This policy was last updated on 27th October 2026.

Questions about data privacy

arcade.ly is the data controller for the information you provide unless otherwise stated. If you have any queries about the process or how we handle your information, contact webmaster@arcade.ly.

Bart's small website | Arcade.ly | Blog

arcade.ly now has an MCP server

Why bother?

What can it do?

Making sure it can’t slow the site down

Not just MCP

Try it

Agentic Software Delivery & The End Of Source Code As We Know It

Footnotes

Why is Agentic Coding so Tiring? An Incomplete Hypothesis

Thank You Joan Stark

Postscript: Where is Joan now?

Not many people are mourning for Stack Overflow

Today I learned: destructuring assignment in JavaScript

Contents

Background

Destructuring assignment example

JavaScript: Microbenchmarks and their pitfalls - trig, random numbers, sqrt, and lookups

Let’s get down to business: a naïve microbenchmark

Unpacking the problems with our naïve microbenchmark

How to debug NaN and NaN propagation bugs in JavaScript

Common causes of NaN related bugs

1. Divide by zero

Common manifestations of NaN related bugs experienced by users

What is NaN propagation and how does it occur?

How do you tell objectively when you have a NaN bug?

Strategies for debugging NaN related bugs (only one of which I have been able to use successfully)

Shoot The Rocks: tips and tricks for dealing with black holes in my version of Asteroids

Making gravity fun: adding black holes to Shoot The Rocks, my version of Asteroids

Simplification, simplification, simplification

Perceived performance part 2: load assets asynchronously or on-demand

Read the rest of this series on perceived performance:

Perceived performance part 1: what is perceived performance?

Read the rest of this series on perceived performance:

Is that Star Castle in The Expanse on Netflix?

How good is Cloudflare's Always Online™ technology?

What will and won’t work offline?

How to run a Node.js app as a service on Ubuntu

Pre Ubuntu 15.04 - upstart

Ubuntu 15.04 and later - systemd

EDIT - 24 Jan 2017: systemd local root exploit in v228

Welcome to the arcade.ly blog

Licensing and attributions

Contents

Licensing arcade.ly games

Credits and attributions

For all games

Star Citadel

Shoot The Rocks

Privacy and compliance

Contents

Privacy notice

How arcade.ly uses your information

Third-parties and their sites

Points covering all third parties

How arcade.ly uses analytics

Specifics of handling log files and IP addresses

Non personal information

Cookies

Introduction to cookies

How arcade.ly uses essential cookies

Your rights

Complaints and queries

Reporting security issues

Changes to this privacy policy

Questions about data privacy