Cowleyfornia Studios

Introducing Eyot - A programming language where the GPU is just another thread

Sun, 08 Mar 2026 00:00:00 +0000

Eyot is a new language I’m building to make offloading work to the GPU as seamless as spawning a background thread.

Eyot source code is transparently compiled for both CPU and GPU, with communication between the two handled by the runtime. Traditional GPU programming expects you to handle many tasks, such as memory allocation, compiling the kernel, scheduling work, etc. These have long been handled by a language runtime when writing code for the CPU, and Eyot extends that convenience to code destined for the GPU as well.

The intended users are those in areas where the GPU or other accelerators are used heavily, e.g. game development, numerical analysis and AI.

It is early days for Eyot. It is not ready for real work, but you can experiment with it, and if you do, I’d love to hear your thoughts. To take a simple example (available in the playground)

fn square(value i64) i64 {
   print_ln("square(", value, ")")
   return value * value
}

cpu fn main() {
    // 1. call it directly
    print_ln("square(2) on cpu = ", square(2))

    // 2. call it as a worker running on cpu
    let cpu_worker = cpu square
    send(cpu_worker, [i64]{ 3 })
    print_ln(receive(cpu_worker))

    // 3. call it as a worker running on the gpu
    let gpu_worker = gpu square
    send(gpu_worker, [i64]{ 4, 5, 6 })
    print_ln(receive(gpu_worker))
}

First, this declares the square function which takes and returns a 64 bit integer. main then calls this in 3 different ways that illustrate Eyot’s distinguishing feature

The square function is called as you’d expect, directly, and on the CPU
A CPU worker is created from the square function (let cpu_worker = cpu square). This worker processes values sent to it with the send function on a background CPU thread. After squaring the number, the worker returns it through the call to receive
This time a GPU worker is created rather than a CPU worker (let gpu_worker = gpu square). This causes the square function to be compiled as a kernel, and run on the GPU, otherwise it acts identically. As you can see Eyot’s print_ln works GPU-side

Motivation

I’ve worked on many projects where shifting computation to the GPU presented an obvious path to better performance that got ignored due to the difficulty of doing so. These projects were not just in obvious areas like computer vision or game development, but also in unlikely matches for GPU programming, like desktop application development.

For example, back when I worked on Texifier, a macOS LaTeX editor, I adjusted the venerable TeX typesetting system to output polygons directly into GPU memory, rather than writing a PDF. This reduced latency far enough that we could update the output in real time. The feature was popular, but the difficulty of making it work left me questioning if the project was worth it.

With Eyot I want to build a language where working on the GPU is ingrained so deeply in the language’s design that it becomes trivial. For a long time we have thought about the CPU/OS combination as something that runs our code, rather than a device to be manipulated. Eyot simply extends this to the GPU. Options like CUDA exist already, but with Eyot the intention is to build the entire language around that model of GPU concurrency.

Current status

Progress is slow as I work on this in my spare time (sponsors appreciated!), and I’ve recently had a break with the arrival of a new baby, but my major roadmap items are:

Rendering Eyot facilitates access to the GPU for computational purposes only at this stage. Game development is a big target for this project, so rendering support is high on my wishlist. I’m hoping to do this using Vulkan, and simultaneously replace OpenCL in favour of Vulkan compute
Syntax I’ve deferred development of Eyot’s syntax so I can experiment with the CPU/GPU interaction without adding language features that would not be viable in both cases. Major missing syntax features for me are Algebraic Data Types, Lambdas and some form of interface/trait style polymorphism
GPU Memory management There is a lot of work here. Vectors and strings can only be allocated CPU-side, this is something that should work on the GPU, I’d also like the memory manager to be able to transparently shift allocations to shared buffers when appropriate
Performance Following the principle of Make it work, make it right, make it fast mantra, I will probably leave this for the immediate future, but it would be nice to throw real workloads at Eyot soon and get them up to speed
Standard library This doesn’t need improving, I have only a handful of functions, it needs starting…

It is also useful to state some things I will not be working on

Automatic parallelisation Eyot does not, and will not, automatically parallelise work across CPU/GPU cores. The intention is to be a convenient option for distributing work across processors, not reduce control.
Theoretically optimal performance Eyot is not intended as a total replacement for current GPGPU libraries any more than C and C++ are intended as a total replacements for Assembly. I would consider significant performance deviations between Eyot code and equivalent C/Vulkan code to be a bug, but for me ease of use is an acceptable price to pay for some performance penalties
Being the next great general purpose language There will be as few syntax differences between GPU and CPU as possible, so the language design will be bound by the GPU capabilities, which may restrict what I can add to Eyot’s syntax

Thanks for reading. You can learn more about Eyot from its documentation and source code. If you want to try it, there is the playground, or you can install Eyot on your machine.

Why I wrote a commercial game in C in 2025

Mon, 20 Jan 2025 00:00:00 +0000

For the last few years we’ve been working on a train management game, Iron Roads, which we released to Early Access today. Somewhat atypically for a game releasing in 2025, Iron Roads is written in pure C, not C++, pure C99. As a choice it has had its ups and downs, which I wanted to share in this post.

The TLDR for why I chose C is that I wanted easy portability and simplicity, but most importantly I wanted clarity over what my code was doing. I wanted to know where it was allocating memory, where performance problems were likely to arise, and I was willing to pay a considerable price to work in a language that doesn’t obscure those details at all.

The requirements, i.e. the game

Clearly any technical decision should be a function of the game being written.

Iron roads is a 2D train simulation game. Our focus when developing has been the gameplay arising from optimising a complex network of tracks with a large number of trains. Additionally, we’ve always wanted this to be a game that is portable to all platforms, and accessible to a wide range of players. Technically, this means:

The graphics code would be simple. Unlike a 3D game there would be no need for linear algebra, or the operator overloading that tends to be useful in in that case
The simulation code would not be as simple. The pathfinding calculations are complex, run frequently, and I knew I would spend a lot of time optimising the engine to support large numbers of trains
It would need to be portable to a wide range of platforms. An unfortunate quirk of developing games is that the SDKs for some of the platforms you target lie beyond an NDA. This has the unfortunate effect that most programming languages that are popular choices on desktop platforms, have not been ported

Other languages I tried

In a technical sense Iron Roads has followed a winding path to its final form, starting from a series of partial prototypes. In total there were four in three languages: Go, Haskell and Rust.

Haskell was the most interesting of these experiments, and worth a blog post of its own. Personally, I wish it had worked out because it was a lot of fun to work on. Unfortunately the requirements of a high frequency game loop seemed to be too much at odds with idiomatic Haskell code to work out for me. Before long every function I wrote seemed to be over the IO monad, and it stopped feeling like Haskell code at all.

Go and Rust were more viable choices, and it is not hard to see myself having written Iron Roads in either of them. Unfortunately they share with Haskell the difficulty of porting the language runtime to a console, and no ports seem to be publicly available. As mentioned above, the NDAs mean that very few languages have first class support for console platforms, and Go, Rust and Haskell are not among those that do.

There are cases where a language has been ported by some energetic individual. To get access you would need to persuade that individual you have also signed the NDA. Often you get access, but the upstream project likely wouldn’t, so there is no guarantee that breaking changes won’t appear upstream at any time, leaving the NDAd fork behind.

C/C++ are provided by all platform owners, so they are safe choices, and C# has enough corporate momentum behind it to more or less guarantee a port, but beyond that the only languages I felt confident I could rely on being available were those that embed in C, like Lua, or those that compile to it, like Nim (aka the prototype I regret not writing!).

Lua

I should come clean that saying I wrote Iron Roads in C is a lie. Iron Roads is written in C and Lua.

Lua, for those who are not familiar with it, is a scripting language designed to be easily embeddable in other applications, and is commonly used in games for that purpose. I wrote the lower level code that runs every video or simulation tick in C (approx 40k sloc), but a lot of higher level game logic, including all the level specific code, is in Lua (approx 8k sloc).

This structure seems almost an inevitable outcome for a game written in C. Greenspun’s tenth rule states that any sufficiently complex C program contains a partial implementation of Common Lisp, but in the gamedev world it would be more accurate to say that any sufficiently complex game in C/C++ contains Lua, and Iron Roads is no exception.

Why not C++?

An immediate question for someone working in C is why they are not working in C++?

Given that I always knew I’d be writing the “content” in Lua, my priority for the C code was to build a highly efficient and reliable engine for routing trains, ticking their positions, and rendering it all. The routing engine especially is a non-trivial piece of logic, and from the start I have been worried about its efficiency.

When profiling previous games I wrote in C++ to improve their performance I would often find STL containers as the root of a performance issue, only to have to rewrite those segments of code to an optimised pure C equivalent.

There is nothing wrong with those containers, or their implementation, but they hide the dynamic memory allocation and de-allocation they carry out for you. It is their greatest feature, however it becomes easy to write code that looks like it should be efficient, but is not. I personally found working in C to help with this problem!

I was also tired of the compilation speed of C++. I’ve never worked with a C++ codebase that is quick to compile.

When writing a game, especially when covering the roles of both designer and programmer, a lot of my time is spent in a loop of playing the game, finding something to change, changing it, and playing again. I strongly believe that speeding up this iteration loop improves my process enough to have an observable effect on the quality of the game I am writing.

Generalisations are never accurate, but I find that idiomatic C++ tends to take longer to compile than the equivalent idiomatic C code. This was a huge vote in favour of C for me for Iron Roads.

Finally, C’s struct literals are incredible. I have no explanation for why they never made it to C++.

Successes

Fast Compilation Iron Roads builds quickly, so I can iterate fast, and in this way C has helped my workflow a lot
Optimisation is easy In general I found the performance of the code I wrote to be “unsurprising”. There are very few “invisible” side effects in C, so it was easy to understand what would incur a performance or memory penalty, and avoid it
Minimal issues porting It is not that C is perfectly cross-platform. Clearly it isn’t, and the many shims in codebase attest to that. However I’ve never run into any platform where it is impossible to port C, which is great

The real success though, is that for me choosing C was part of a broader pattern of choosing the most straightforward tech possible to build Iron Roads. Possibly I just can’t be trusted to write C++, but this has been great for readability and performance of the codebase, and great for keeping me focussed on the game I am writing rather than the technology I am using to write it.

Failures

Serialisation Compared to serialisation in almost any modern language, serialising state in C (or C++) is excruciating. There are no reflection capabilities in C, and minimal capabilities in C++, so you need to manually specify each and every field when serialising or deserialising the game state
Boilerplate This seems almost too obvious to point out, but strings, arrays, dictionaries, etc in C require a lot of boilerplate. This strings problem was mildly annoying when the game was only in English, but it become more serious when we localised the game to Chinese
Runtime issues Valgrind and asan are amazing, and it is hard to imagine having written the game without them, but they pick up issues at runtime that other languages flag at compile time

Conclusion

In truth I’m not sold on writing games in C, and I don’t think I’d repeat the process. I’m happy with the outcome both codewise, and designwise, but the process of getting there was needlessly difficult.

I don’t see much point in returning to C++, but I am very interested in experimenting with modern, higher level languages that compile to C. I think the first prototype of my next game will be written in Nim!

Perceivable consequence, or why we reworked Iron Roads' new townscreen

Sat, 09 Mar 2024 00:00:00 +0000

Iron Roads has seen influx of new testers recently, and with them have arrived new perspectives and feedback. This feedback has kicked off a new cycle of worrying, analysing and fixing as we described in our last blog. This time we aren’t worried so much about the systems in the game, so much as we are worried about whether we are communicating those systems to players effectively.

A lot of the feedback has been of the form “I had fun playing, but can you explain why X happened when I did Y”.

This represents an issue we need to address.

Perceivable Consequence is the formal term for this concept. It was defined by Doug Church as “A clear reaction from the game world to the action of the player” (Errant Signal made a good video essay about it). It is important because for a player’s choice to feel meaningful, it must to be obvious what the consequences of that choice would be. So, without Perceivable Consequence there can be no meaningful choices on the part of the player, and their agency in the world is reduced.

To be clear: I am only discussing management/simulation games here. There are many reasons why one may wish to break this rule in other genres, but they are not relevant here. In management/simulation games, the core loop consists of players observing the state of the game’s system with some goal in mind, thinking about how to achieve that goal, and then making changes resulting from their analysis. It is a design based on the idea that players are able to predict the results of their actions. If not, the game loop falls apart.

This isn’t to say it should always be easy to achieve goals, or that there should never be surprises, but ideally any surprise arises due to players’ not yet knowing the game’s full systems, rather than a lack of predictability in the game.

To take a non-management game example: anyone who has played Dark Souls has likely been pushed off a ledge by a hidden enemy. It is annoying when it happens the first time, but you respawn, return to that point, avoid the enemy this time, collect the souls you lost and continue - no harm done. However if that enemy were randomly placed, or you weren’t able to recollect your souls, your death would be unpredictable, unavoidable and unfixable. The game would cease to be fun, and instead it would be random and annoying.

This is all well and good, but what does it mean for Iron Roads? We are slowly reworking UI screens, trying to bring all the information you might need about your train network to the surface in a consistent way. If you are struggling to achieve a task, we want you to know why.

For example, this week we worked on town growth.

Very early testers might remember the Economic activity bar on the town information screen. It showed how much was going on in the town, and when it the bar became full, the town would grow. The problem was that it was not at all obvious where these numbers came from. It was a complex equation I was very proud of, and that I thought provided a good growth model for the town. Whether or not this is true was moot. It was far too complex to explain via the UI, so we didn’t explain it at all. Players asked what the bar meant, we had no simple answer, so we doubled down on our mistake and hid it.

Clearly this was not our finest hour.

In this update we’ve replaced the town growth system with something simpler and clearer. The town screen displays the number of passengers and cargo units that arrived in the last hour. Alongside this is a target number of units / hour. When you achieve this rate, the town grows, and a new, higher target is shown. It may not be as sophisticated a growth model as before, but it is more understandable, and hopefully it could be said to be “A clear reaction from the game world to the action of the player”. You can see it below.

There is a lot more to do on this front, but it has been a while since we pushed an update, so we’ve collected this along with some bugfixes, new scenario level selector art, and other UI tweaks into a release. It is a big change, so as always, feedback is always appreciated!

A new theme and a new mode

Mon, 18 Dec 2023 00:00:00 +0000

Our update cycles seem to begin with us worrying about Iron Roads, pinpointing the source of our uneasiness, worrying some more, working on changes to assuage our concerns, sharing the result with play-testers and iterating based on feedback. This time was no different, and stemmed from a new worry - does Iron Roads have a thematic identity of its own? - and an old worry we wrote about back in August - have we effectively teased out gameplay that focusses on optimisation of networks.

Thematic update

When analysing the state of Iron Roads, we were happy with the progress we made on gameplay, but less so with how we had neglected theme and storytelling in the game. Thematically we felt Iron Roads lacked a strong identity/narrative hook.

We’ve wanted to tackle themes of development in Iron Roads for a while, after reflecting early on that we’d made a game that rewarded bulldozing the countryside and covering it in concrete and metal. This isn’t to say we want to make a game that discourages all development, but one that asks the player to balance the needs of the society with the needs of the ecosystem that society relies on.

Iron Roads is now set in a world where humans have driven themselves to extinction, leaving behind a planet being repopulated by erudite animals seeking to rebuild in way that spares them the same fate as the humans that preceded them. Your job is to connect society again, balancing competing needs as you do so. This fit naturally with the offbeat tone Iron Roads already had, requiring only minor updates to the contracts, artwork and descriptions.

The second step is adding gameplay elements to relate this theme. It is easy to make a game in this genre that rewards smart choices about how you build. However, many problems with over-development are not solved by smart building, but by not building. And it is harder to create a game in this genre that rewards that!

To this end, the archaeological remains some may remember from the Horseshoe Isle are back. You will also notice fields scattered throughout the maps. Building on top of these will sometimes, but not always, damage the town relying on these features. It is only a start, but it has added an element of strategy about how you route your tracks, that we hope adds to both the gameplay and narrative.

Challenge mode

We’ve long felt that the strongest gameplay in Iron Roads was to be found iterating on an established network, and trying to optimise it towards some goal. For this reason we added graphs, and moved from emails to long strings of increasingly hard contracts to encourage this style of playing. However, graphs are only useful as a tool to help the player complete an objective; they don’t encourage that objective themselves. So we’re pretty excited to have finally added a challenge mode to Iron Roads. You are given a fixed period of (in-game) time to transport as many passengers or cargo as possible in that time.

It took us a few tries to find a challenge that worked. We even experimented with a “roguelite” survival mechanic before settling on a fixed period of in-game time. The ‘countdown’ mechanic is easy to communicate, works well with graphs, encourages optimisation and doesn’t have the negative feeling of failing our roguelite version had. Most importantly, we both agreed that it was fun. We love how much weight this change adds to each choice you make, and the interaction with the development mechanics discussed above: Each field destroyed is potentially a loss of customers (we say potentially because there is an element of chance or luck), and each field you choose to preserve makes it harder to build an efficient network and beat your score.

We’ve set up a high score board and linked it to Iron Road’s Discord so you can compete against yourself, us as the developers, and each other on these challenges. There are two fixed challenges in the demo, and a randomly-generated weekly challenge that rotates on Friday mornings.

Steam Capitalism and Economy fest

Other notable changes in this update cycle

We’ve begun work on a random map generator. Currently we are using this to generate the weekly challenges, but at some point we will enable the endless mode in which you can play however you wish
We’ve begun testing the mobile version. Thanks to those who have given us feedback already, and if you wish to join them please drop by the #mobile channel in our Discord
UI updates. The smaller screen size of the mobile version forced us to confront some inefficiencies in our UI design. Although mobile and desktop will not be identical in all ways, we felt that most of the changes we made on mobile were improvements on the desktop version as well, and switched on both platforms. You will notice a more consistent design to dialogue boxes, a new top bar, and less reliance on tooltips to document the UI

Our next event with Iron Roads is Steam’s Capitalism and Economy fest in January, and it is with the hope of gathering feedback on the changes mentioned above before this event that we are pushing 0.2.0 of the demo now.

As always, we’d love to hear your thoughts, positive or negative. Especially the latter. With some luck your comments will worry us enough that our objective for the next update becomes clearer!

Emails are dead - long live contracts!

Sat, 16 Sep 2023 00:00:00 +0000

The upcoming update will remove emails from the game and replace them with a similar, but different, concept of contracts. As much as we liked the whimsy and storytelling of the emails, in practice they have some issues in Iron Roads:

Accepting an email is busywork for a player We had a system of on one email for every task. We had reasoned that more than one email for a task is unnecessary reading, and no email leading to a task is confusing. However testers noted that the process of clicking through even this single mandatory email to view the task added nothing, and became especially irritating the second time through a scenario
Hard to refuse In principle you can ignore an email or not accept that task. However the personalised nature of an email nudges players to accept each associated task. This has led the scenarios down a more linear direction than we intended, and it has inhibited us from adding really challenging optional tasks
Emails don’t display the task list they link to very well This could be solved by improving emails rather than removing them, but it is an issue. Conversely, there is no way to associate a task with the story text that led to it

Our proposed solution to these issues is to merge the emails system and the tasks system into a single contracts system. The old email screen becomes the contracts screen, showing a list of contracts available to the player at that point in time in the left column. Clicking on a contract will display the contract details in the right column, showing the tasks associated with that contract, the reward, and contextual text for those who are interested in the narrative aspect.

With this UI we can show a choice of contracts that a player may want to accept and, critically, it allows a player to opt out of a contract they are not enjoying. The more optional nature allows larger groups of contracts, specialising in specific areas of the game, and including harder challenges for advanced players.

All of this links back to the observation in our previous post that Iron Roads seems to play best when it is viewed as an optimisation game. Setting up the network and getting the first few passengers moving is rewarding, and helps us tell a story, but the mechanics seem to be at their strongest when you are improving your network Contracts place more emphasis on this phase of each scenario.

Dare I say it, this update is proving to be easier to implement than the cargo update, so if all goes well it will be in your hands within the week!

As always, if this interests you, join us on Discord to give it a try.

Summer updates for Iron Roads: cargo scenario, a proper tutorial, and what the game actually is

Wed, 30 Aug 2023 00:00:00 +0000

We’ve had a busy summer with Iron Roads, with the first pre-alpha playtest in May, and Steam’s NextFest in June.

After those we trawled through our Discord, Steam, Twitter messages and YouTube playthroughs to understand what was and wasn’t working with Iron Roads. Based on that, we’ve been working towards the 0.1.0 update, which is looking to be a significant overhaul.

Two key insights we identified were problems with onboarding players, and communicating what kind of game Iron Roads sets out to be.

The tutorial was not nearly good enough

Watching streamers and Youtubers playing Iron Roads is very useful playtesting for us, as it not only lets us see everything they do, but their discussion with their chat spells out their thought process as they play.

There were some great long playthroughs of Iron Roads, for example this or this, but there were also a number of videos where a player tried it and gave up after a few minutes when they got stuck.

The problem is that the tutorial in the demo, which in hindsight was a rushed, last-minute addition, was not very good. It didn’t cover close to enough of the game mechanics, and it failed to familiarise the player with more complex aspects of Iron Roads, such as no stop zones and waypoints.

How did this happen? We think this blind-spot came about as many of our initial testers were from the Open TTD community, and for them Iron Roads’ minimal interface and train mechanics needed no explanation. There is a lesson in there about selection bias when people sign up to test a game: playtesters do not necessarily represent the average gamer, and feedback should be interpreted with this in mind. It is not the fault of testers of course, so the second lesson is to just write a good tutorial for your game!

Anyhow, 0.1.0 will ship with what we hope is a much improved tutorial.

What is the game?

Another issue we picked up on from feedback is that it isn’t clear what kind of game Iron Roads wants to be. Is it a chill game? An optimisation game? A puzzle game?

Marina and I talked a lot in the early days about a train simulation with the “accessibility of Mini Metro” and the “depth of Open TTD”, but we hadn’t thought about this for a while, and we certainly hadn’t spent time articulating exactly how we’d achieve that “depth”.

It took some thinking and playing, but we came to the conclusion that the greatest joy in Iron Roads is optimising networks to carry passengers faster, cheaper and in ever greater numbers.

In other words: the game we had spent the last year working on was in fact an optimisation game.

Looking at Iron Roads through this lens, we’ve added graphs to help players track how their network is performing. We’ve also altered the challenges in the scenarios to focus on optimisation-type tasks, and we’ve rebalanced to make it easier to edit networks without losing money.

We realised we needed to do a much better job communicating this depth and optimisation-as-the-mainstay-of-the-game when describing it. Presented with Iron Roads’ minimal interface and cute graphics, players can well be forgiven for thinking it is an overly-simplistic train game unworthy of their time, and painfully for us, a few did.

A good example is the welcome screen, which shows a single train moving on a single line around three towns in a loop. This is hardly an advertisement of the depth lurking beneath Iron Roads’ minimal UI. This, along with the Steam page, press-kit, etc will all be revamped.

New Content

So far I’ve described the issues we’ve fixed, but we’ve also been adding new content.

A common request in the Discord has been to add cargo to the game, so 0.1.0 comes with a new scenario, set in a new biome (desert this time) that does just that. The difficulties of managing a production chain have worked well with our focus on Iron Roads as an optimisation game. You make a change to your network, stare at the production graph to see the result, and repeat until you’ve hit your target.

With so many different tasks it has been a big update, and our TODO lists are not empty yet. We hope to have things wrapped up soon though so we can send it out into the world, find out what we missed and get going on fixing it all over again!

If you haven’t already, do join us on Discord and give it a try.

Just the ticket

Mon, 19 Jun 2023 00:00:00 +0000

Something very exciting happened last month: Iron Roads was released into the big scary world and onto the screens of the first batch of alpha testers. What a ride it’s been (please excuse the train puns).

We’ve had an enthusiastic, and unexpected, response to our call for testers. We are grateful to the lovely folks who put up with the bugs and major quality of life issues, joined our fledgling Discord community and shared their thoughts. Their feedback has changed both our short-term and longer-term roadmap, but I’ll get to that in a bit.

The question of ‘will people play and enjoy my game?’ haunts every developer’s mind and until you have a playable prototype, you can never know the answer. At the same time you don’t want your early testers to get derailed (I promise I’ll stop!) from your vision because your prototype has too many placeholders and missing content. It’s a tricky balance, but we reasoned that if we wanted to create a game people wanted to play, we would need to involve them as early as possible, even though it meant putting something out there we were not entirely happy with.

We aimed for a complete (ha!) version of a small slice of gameplay and posted about it on Reddit, and had a really positive response. It’s not there yet, and there’s a lot to fix, but we were particularly thrilled to find out that some people have played the demo for over eight hours. This is all very promising and makes us think that we’re on the right track (I’ll see myself out…). Below is a particularly intricate layout created during this testing (thanks to Kaigoni, who kindly gave us permission to exhibit this wonderful layout).

So, back to the feedback and what we got up to in the last few weeks. On Discord, players can vote for features they would like, which helps us decide if an idea is popular and what to prioritise. After Duncan had fixed some gnarly bugs we missed when playtesting internally, we addressed some quality of life issues brought to our attention by the community. This included improving the WASD controls, adding edge scrolling, cleaning up UI issues, adding a tutorial and fixing typos. More serious changes were changing no entry zones into no-stop zones (this still needs more work) and adding waypoints to give players more control over the precise routes taken by their trains.

Interestingly, there is very little overlap between what our to-do list looked like before we got tester feedback, and after. The former list veered towards tasks that are more fun for us to do, but are less of a priority for players. Things like animations, new towns and reducing train speed around corners. We will still add these, but the external voices have made us more objective with how we prioritise our time.

We’ve also tried to increase Iron Roads’ visibility during the Steam Next Fest that starts today. We’ve updated our trailer and made a ‘watch devs play’ video. If you are a streamer, journalist, or just someone who would like to play Iron Roads and talk about it somewhere - even at the pub with your mates, please do get in touch. Anyone can playtest by downloading the demo on Steam and joining our Discord. And consider wishlisting Iron Roads, because, you know, algorithms.

Once we have recover from Next Fest, we’ll continue ticking off player requests, fixing bugs and more excitingly, developing new scenarios and generally adding new content to Iron Roads.

Introducing Iron Roads

Fri, 14 Apr 2023 00:00:00 +0000

We have been working on a train management game called Iron Roads over the past few months. Now that it is beyond the prototype phase and approaching its public debut at Steam’s summer NextFest, we thought it would be a good time to start a devlog.

Iron Roads is a train management game in which players lay tracks, buy trains and set their routes to establish train networks that connect people and cargo to the towns and places they need to be. Our initial focus will be on PC platforms, but if all goes well, we hope to release on mobile platforms and, if the stars really align, consoles.

With Iron Roads we are aiming to create a train management game with the deep sandboxy nature of OpenTTD that is as easy to pick up as a game like Mini Metro.

Given all the train management games out there, why have we decided to add to the collection? We love the depth of games like OpenTTD and Simutrans, and the creative possibilities their sandboxes give players, but we wanted to create a game that is easier to learn while still maintaining their depth. Mini Metro’s beauty and immediate accessibilty was an influence on this aspect of our design.

A final inspiration for Iron Roads is the humour and whimsy of the Bullfrog management games, a torch carried today by games like Lets Build a Zoo, Overcrowd: A commute ‘em up, or the excellent Two Point games.

Progress so far

The version of Iron Roads we have now is developed from the second prototype we built.

The first prototype had a hexagonal grid, isometric art, a wave function collapse-style constraint solver to lay out art, and it was written in Golang. We initially tried to cram everything we had learned from making our previous games into this early prototype, without considering whether it really benefitted the game. This resulted in a somewhat player-unfriendly prototype buckling under the weight of its complexity.

We loved how the art looked (shown above), but the isometric perspective resulted in some sprites occluding tiles behind them, making it less clear what tile a click corresponded to. Hex tiles also lead naturally to six directions on the board, which proved inferior for building layouts to square tiles, which naturally allow eight directions. Technically, Golang is a fantastic language to write games in, and we were sad to leave it behind, but getting a version of that prototype running on mobile was becoming very time-consuming. More worryingly it wasn’t clear consoles would be a possibility at all. In general, our enthusiasm had gotten the better of us, we had added unnecessary complexity everywhere, and it hampered both development and gameplay.

After making the painful decision to ditch our work entirely, we started from scratch on the second (and current) incarnation of Iron Roads as a top-down game, with square non-overlapping tiles, written in C, and with a straightforward manual process for laying out art. Freed from the unnecessary complexity, it didn’t take long to functionally catch up with the previous prototype. More importantly, iterating on systems was quicker, and we could focus on building a game players would enjoy.

What next?

Right now we are playtesting internally, iterating systems to perfect the balance, and improving on the user interface. We have finished most of the tutorial ‘level’ (we need to decide whether these will be called campaigns / scenarios / maps / levels, but you get the idea), and we’ve started on a second larger one that allows for more complex train networks.

Incidentally, we have found Jesse Schell’s book, The Art of Game Design, an invaluable prompt to make us look at Iron Roads from different perspectives (lenses as they’re referred to in the book).

These first two maps will form the demo of Iron Roads that will be part of Steam’s NextFest in June. In preparation for this we will be playtesting with willing volunteers. Please get in touch if this is something you’d like to be involved with, we’d be forever grateful! The best way to do so is to email us or drop by our Discord.

2022 in review

Tue, 03 Jan 2023 00:00:00 +0000

Happy New Year!

Inspired by the excellent 8,760 hours guide we’ve written a recap of last year: what went well, what didn’t, where we tried hard and where we didn’t.

What went well?

We’ll always have Paris was the project that dominated our 2022. It was an artistic project, undertaken purely for the joy of making it. We loved developing it, and got to see many people play it and understand what we were trying to achieve, so it goes on this part of the list.

We’ll always have Paris was our second project, and looking back we are happy that we didn’t repeat the mistakes from our first project, Sarawak. Reusing the engine saved a lot of time. As well as that we were careful to think ahead more carefully, which shortened the development period and yielded a leaner, better-focussed game.

We’ll always have Paris was the first game we released on mobile. We developed it from the outset to work on both mobile and desktop, but I personally think that the phone platform suits the single-session experience better. A highlight of the mobile release for me was being selected as Game of the Day for both the UK and US App Stores.

Because of the niche themes explored in We’ll always have Paris, we spent a lot of energy making sure it reached the right audience. We are grateful for everyone who took the time to play the game and wrote thoughtful reviews.

Towards the end of the year, we exhibited We’ll always have Paris at the AdventureX narrative games convention. It was a tremendously fun and validating experience, that we wrote about here.

What didn’t go well?

On a personal level, extensive home renovations took over most of 2022. Working in a construction site is conducive to neither focus nor creativity. We’re glad that’s all done and we can replace the time that ate up with developing games once again.

We’ll always have Paris sold well compared to our expectations, but realistically it wasn’t profitable. Profitability was never an goal for this project, but we would like our future games to sell enough to enable us to work full time on them.

Where did we try hard?

We put effort into working smarter, by simplifying and improving our processes. When building games it is easy to add tools and steps to the development process, but it is hard to take them away, and the creeping complexity can cause larger problems than those you were trying to solve. This year we greatly simplified our systems. Process-wise, we committed to weekly progress discussions to keep development on track. Still lots to improve with both of these.

We both worked to improve our skills, and learn more about our respective crafts.

We spent significant time understanding our combined strengths and interests - which have shifted since we started working on Sarawak many years ago - and planned our upcoming project, Iron Roads, with this in mind.

Where did we not try hard enough?

We need to delineate work and leisure time better. It is not sustainable, or realistic, to be fixing bugs late on Sunday night and expecting to wake up fresh and inspired on Monday morning. This is of course a problem shared by many, so any ideas on how to tackle this are most welcome!

Our original plan for the first part of 2022 was to release Sarawak on mobile. We quickly realised that porting Sarawak to mobile was going to take a very long time due to the way it was written. We’ve not second guessed our decision, but if Sarawak had been designed from the start with portability in mind, we wouldn’t have had to cancel it, and Sarawak mobile would be out there. The upside is that we did not repeat the mistake, and Paris released on all platforms from day one.

This one is possibly a consequence to the single-playthrough nature of our previous two games, but we didn’t try hard enough to build and engage a community around our work. We hope to improve this with Iron Roads.

For time and motivation reasons, I didn’t add many new artworks and listings to the Etsy shop.

2023

So, what lies ahead for us? We’ll be working hard on Iron Roads and posting regular updates on that. We also hope to increase the frequency of these long-form posts here - so do get in touch if you have any comments or ideas.

Wishing you all the best for 2023

1.0.5 update for We'll always have Paris

Thu, 22 Dec 2022 00:00:00 +0000

We just sent out the 1.0.5 update of We’ll always have Paris. There are no big changes, it just fixes a small typo, and a crash that could occur if the game could find no sound devices. We’ve only managed to reproduce the crash on Windows, but it may have affected other systems as well.

Happy Holidays!