One of the big challenges I've had with this project was building it for free. The game runs a lot of APIs and databases to support a massively multiplayer gameworld and clouds aren't (completely) free. I have nightmares about waking up one morning to find this.

At my full-time job, I use AWS and don't really think about the cost. We spend thousands on AWS services, but an AWS bill in the thousands is the cost of doing business and optimising takes time and time is money. So we just create lambdas, EC2 machines, CloudWatch logs as far as the eye can see and just... don't worry... until the bill doubles from the previous month.

For this project, given it's mostly for fun, I don't need to have a monthly invoice for a game that has zero income. So one of the first things I looked at was how far I could get with the AWS free tier. The answer was quite a long way as long as you are prepared to compromise. You can use a lot of Lambdas and DynamoDB every month without it costing anything, so some of the game design was changed to work with the constraints of this. Particularly, the constraints of Dynamo.

Database

As an example, scouting for players would require us to find suitable players in the database, but in DynamoDB, this would likely require scanning the whole database or at least very large queries. The player database would contain thousands of players, so hundreds of users making these requests would likely run up a huge AWS bill quickly, as AWS charges by how much you read and write to the database. The design decision to get around that was to queue up scouting requests and process them all together. This would allow us to make a single database query, getting the list of players and use that result to handle multiple scouting requests at once. This actually works well in the context of the game as sending off scouts to search for players should take some time anyway.

Things quickly started to go off the rails, however. Dynamo was not the right database for the job and it wasn't as free as it seemed it would be. We store large volumes of data for each player and each fixture. These large database documents pushed a single get/set from counting as one request to multiple requests from the AWS billing perspective. Therefore, we'd already exceeded our free tier and there wasn't a huge amount we could do about it. Added to the feeling that the game mechanics were being compromised for DynamoDB led me to a decision to switch to PostgreSQL.

PostgreSQL is a much better fit for a game of this type, where a lot of the data is, by its nature, relational. A manager has a team. A team has players. Players have attributes. Teams take part in fixtures. Fixtures contribute to Leagues. All of this was very inefficient to query in Dynamo. The trouble is, PostgreSQL is not in the free tier on AWS. The next step was to self-host a database on my own VPS. This instantly made things better from a logic point of view, but the cost of this was that my performance tanked. Not because PostgreSQL itself is slow, but self-hosting on a tiny instance with a microserve architecture meant every time a lambda spins up to serve an API request, it has to make a connection, and that was slow before it can even run the query. When we're still in dev with just one user, this is acceptable but as I wanted to move into public testing this had to change.

Event Processing

I also started breaking the free tier limits on SQS. SQS is an event queue that I use to handle processing actions reliably, such as fixture processing. Twice every day, we process around 300 fixtures per gameworld. These process requests are added to a queue where a lambda reads them from the queue, processes them and, if the processing fails, adds them to a "dead letter queue" so they can be reprocessed or investigated. This stops us from being overwhelmed trying to process hundreds of fixtures all at the same time and also adds some resilience. If processing fails, we can capture the event that failed and either fix the bug and replay it or discard it. While SQS itself was fine in the free tier, in order for a lambda to read from it, it needs a subscription. The subscription is an automated polling event that checks the queue every x seconds, and you are allowed 1,000,000 of these a month. It's quite shocking how quickly you can burn through that amount with a few queues and poorly optimised intervals. Unlike the database, this actually is the right tool for the job. Large quantities of data that need to be processed quickly in parallel with good error handling so the best I could do here was increase the batch size and the poll interval so it is invoked less freqently. Some of the events have no rush to process them so a long interval is perfectly acceptable.

CloudWatch

Another thing to balance is monitoring. It's really important that if we start getting errors in our API that I know about it. Especially with events that are triggered on timed intervals, and the user wouldn't see any errors in their app.

AWS CloudWatch offers a number of services that can help here; the most obvious is logging. AWS have a pretty generous free tier for logs but it still needs to be implemented cafrefully. AWS will charge you for a certain number of events logged and also for storage of logs. By default, my infrastructure was being deployed with logs being kept "Forever". This is unnecessary and a rapid way to start running up a big AWS bill. In truth, I don't care about logs much after a week they've been logged so a 2 week retention period is a long enough time to keep these.

I still managed to blow the free tier on logging however. My match engine that computes all of the events that happened between two teams had significant amounts of debug logs in it. Given this runs twice a day for about 300 matches each time, it wasn't long before this got out of hand.

Once you've added logs, though, we need to make sure we get alerted about errors. Here I used CloudWatch alarms and hooked these up to SNS topics that would send an email to me whenever either one of my Dead Letter Queues received a failed event or whenever the word "ERROR" appeared in one of my Lambda logs. AWS will give you 10 free alarms every month, and I have around 100 lambdas producing their own logs so clearly I can't cover everything that way.

I restricted my alarms to just the lambdas that were running from triggers, like the lambda that runs match logic twice a day. For the API endpoints, I used Sentry. This is a 3rd party specialist monitoring service that has its own generous free tier. I've added this to both the mobile app and the backend to catch errors, and it will provide some really in-depth logs of the error and emails me whenever there is a new issue.

Another helpful feature in CloudWatch is Lambda Insights. This provides dozens of datapoints about the performance of the lambdas, including alerts for lambdas that were hitting the maximum memory usage or running longer than their maximum execution time. It is a good way to quickly understand if anything is under or over-provisioned. This helped me, over the space of a couple of days, identify some real silent issues in the performance of my system. Unfortunately, it is very much not free. It sets up a lot of alerts on all of your lambdas, and each one has a small cost so on a hundred lambdas, this got expensive quickly so went in the bin.

Conclusion

So, is it possible to build a game on AWS for free? Well, no. Not this one, at least, but it can be done very cheaply. My AWS bill is currently $15 a month, and this would inevitably go up if that game gets a lot of users, but hopefully, if that happens, then the income from ads and in-app purchases would go up to match that - we'll see. This still isn't costing me anything (yet) thanks to the AWS Activate program. If you're starting out on AWS it's well worth looking at this as it provides $1,000 AWS credits for free. That, with the free tier should be enough to get a project to release and run it for a few months to see if it's viable. It also provides a buffer to make a mistake on costs without hurting your own pocket. This program also gives access to other benefits such as free $300 Supabase credit which is providing me with free database hosting for 12 months,

Thought it might be interesting to record some of the stories and mistakes from making Jumpers for Goalposts because I've made plenty! But every mistake is a learning opportunity so no good pretending they didn't happen.

​The first thing I'll go into is a success story rather than a mistake and it's everyone's favourite buzz word... AI!

Firstly, some background. This game is something I've had in my head for 15 odd years but only recently have I had the skills to ​tackle it on my own. The game is probably 70-80% backend with the frontend mobile app basically being a window into some data. That said, the frontend is the part I was going to find most difficult because I'm predominantly a backend programmer these days. I can use React and I've used Unity a lot but there was no way I was going to build this in Unity. Why? Unity is a heavy game engine that's great for 3D and even 2D games but this is mostly user interface. Despite improvements in this area over the years, Unity is not the tool for a UI based game. It takes an age to load the editor, application sizes are large, and the phone would run way hotter than it should for a UI. So that left React...

At the start of the project I threw together a very simple React dashboard to display the data from the game, making API calls etc. to prove the game worked. Within a few weeks I'd already proved this was something that could work as a game but now I had a problem. I am not going to ship a website for a game. Having looked at other options like Flutter and native Android development, I settled on React Native using the Expo framework. What I found surprising was how different React Native was to Web React. An entity custom set of components were needed to build the UI so switching from my Web dashboard was not as simple as I expected.

This is where AI came in and has been a God send in delivering this project in the time it's taken so far. I played around with a few tools including copilot, Claude, OpenAI but the one that made all this possible was Augment Code. Here was an agentic AI that runs in WebStorm and actually seems to understand project context. This was the biggest issue with all the other tools I tried. They could answer questions, but they didn't fully understand how everything works so would duplicate logic, create components with the wrong frameworks (such as ignoring that I'm using styled components and using in line styles instead). Augment genuinely shocked me on more than one occasion with understanding the things I hadn't mentioned but could be inferred with the right context.

Another thing it was really good at was UI design. I didn't really know what design I wanted in sone areas, so I would explain the things that were important from a UX point of view and its creations were almost always really good! An example: in the training screen, I was sure I wanted drop down combo boxes to select the player and the training area but having created that, it just didn't feel great. I asked Augment for suggestions and it created a modal with scrolling lists and paged sections. It immediately looked better,​ felt intuitive and gave me room to display more relevant content like the star rating and assistant feedback. ​​​​

Another area was the post match fixture details. I knew I wanted to display which players had played but not how to present both teams cleanly in a portrait interface. Augment had it covered with a tab design including some nice accents on the tabs to keep things readable.

Now none of this is perfect. Even Augment seems to struggle as the project gets bigger and the context needed is much greater. I will frequently have to point it towards common components because it has created yet another button style.

It's biggest failing was early on in the project though. I wanted to implement drag and drop for changing your team selection. The problem was, it kept implementing a UI where dragging a row up, would shuffle all the rows down - a common reordering pattern on mobile. ​​​That's not what I wanted though. I want to drag and drop one row on another row and swap those two rows. It could not figure it out. Many many iterations, we would get closer but it would fail with edge cases like dragging and scrolling the view at the same time, one item would animate and another wouldn't etc. Sometimes even going back to the reorder logic it started with. What was worse was that the code it created became an unreadable mess with logic from previous failed implementations confusing things. In the end, I found a tutorial for the common reorder UI and modified it to behave the way I wanted it to work. It was far simpler than I actually thought it would be. Implementation took less than a day, after many days of trying to get AI to do it for me. ​​​​Sometimes you have to know when to do something yourself and I probably misjudged that one. ​In the end I ditched the input method anyway because it was a frustrating and confusing way to change the team on mobile. I went with a tap on one player, tap second player to swap method which is a much better user experience. Here, at least, Augment redeemed itself, converting the input method from one to the other in one or two agent requests, ​​​ in way quicker time than I ever could.

AI is not coming for my job anytime soon and yet, the speed at which it is improving is frightening - both in a good and bad way. To see agentic AI solve problems and create mostly functioning - not just code, but whole applications - in a few minutes is incredible. And it's hard to get your head around it being only a couple of years ago since ChatGPT launched as basically Google on steroids. AI has made this project possible as I don't have the time to learn React Native outside of work the traditional way. Not if I want to make a game, avoid a divorce and my kids hating me. But I've got a good understanding of how it works now and a pretty functional game alongside it. While I'm not ready to call myself a React Native engineer just yet, I do at least have a good grounding in it because I'm understanding what AI is building and why.

AI can be a great learning tool. I've always found learning code from examples easier than reading documentation or even building something from nothing can be quite overwhelming at first. AI can help with that. Generating code and then understanding what it built and why. Asking questions, "why did you do this?" can help understand the thought process or best practices in real time.

We need to beware of total trust in an imperfect tool though. ​An advantage of having coded for over 20 years is recognising code smell. AI will very quickly generate utter garbage if you don't code review what it's building. Recognising when a system has gotten too complex and needs refactoring is really important. There are some scary examples of code written without the oversight of people who know what they're doing and we should be mindful about where this AI craze is taking us. The hype is real. AI is a super helpful development tool that's only going to get more powerful - assuming we don't burn the planet down first - but we need to stay realistic about what is possible right now and how to build safely and sensibly.

Jumpers for Goalposts is now in early access on the Google Play store. I've worked on the game over the last two weeks to improve the experience, fixing bugs and tweaking the UI. One of the big new features is the addition of Guest Login. It was obvious early on people were backing out on the first screen that was prompting the user to sign up. It's obvious with hindsight that not everyone wants to give out their email address for a game they don't know is worth their time yet. Guest login should solve this by getting you straight into the game and nudging you a few times to sign up when you're ready.

I hope you'll join our open testing phase and provide some feedback on what you think so far. There is a lot to do still and I'm trying not to think about how much I still want to do or I might not do any of it. Let me know what you want and it can help prioritise what gets done next.

We have our own Discord channel where I'll post updates (as well as here) and use it to provide a 2 way discussion with anyone playing the app. Join us here.

Join the early access here.

It's nearly here. My massively multiplayer football management game on Android is nearing its first release. To get there, I need 12 testers for two weeks to install the game and run it once or twice then Google will let me release it. If you're interested in trying it out, here's the blurb about the game.

I'm building a massively multiplayer football management game for people who don't have the time for Football Manager and maybe want to buy a player while they're sitting on the bog. Y'know, like real managers do. You don’t have to be a management game nerd. This has more in common with Fantasy Premier League than Football Manager. In the game, you are assigned a pub or village team in a gameworld in one of the bottom two tiers of a 4 tier football pyramid. Your team is a bunch of drunks and village idiots aspiring to be rank amateurs in the world of competitive football. Train your players, pick the team, search for new, less drunk footballers, sell players, buy players and compete to finish top of your league. Then get promoted and try not to go backwards. On the way, you will have to deal with suspensions and injuries to key players. Fixtures are played twice a day and a full season is complete in 7 days (faster than a season of Football Manager!) The game is available on Android at the moment in closed alpha and I'm looking for testers to help me take it into open testing. There are bugs and unfinished things. Like the UI. Looks a bit bland, yeah? I know. It'll go in the bin at some point. The art is AI-generated. I know. I feel dirty. It is intended to preview the style that I want for the game but that should also go in the bin at some point. Click enough ads and I'll have enough money to pay an actual human with fingers and stuff.

To get access to the closed alpha, use the link below to join the Google group and then you should have access to the link on the Play Store.

Google group to join: https://groups.google.com/g/jfg-alpha
Play Store Link: https://play.google.com/store/apps/details?id=com.rwsoftware.jumpersforgoalposts

I also have a Discord channel set up which you can join here.

I started work at the beginning of this year on a mobile game that has been in my head for about 15 years. I've finally got to a point where, with the help of AI and everything I've learnt working in AWS for the last few years that I can actually build it.

It's called Jumpers for Goalposts and I'm hoping to have a playable closed beta available soon. I'll share more details when that happens. I'm really excited about this. I think it could be a lot of fun for a lot of people.

I've been working on a personal project for a while now off and on. It's a computer game version of Ravensburger's "Labyrinth" board game. My kids really enjoy this game. We've got the Harry Potter themed edition but my boys were wishing there was a Lego Ninjago version.

Well, it got me thinking... "how hard can it be". And of course it turns out, harder than I thought of course. My main blocker is time and patience as usual but I'm making some decent progress. The board is setup with some fairly decent artwork (given I'm a programmer and have no 3D or digital art skills)

The game has two states. The first lets you click one of the arrows and a tile will be inserted into the board, pushing out the one at the other side of the board. That becomes the "spare" tile which you can rotate by clicking the tile icon in the top right hand corner.

The second state is the player movement state which I'm fighting with a bit. To find your way from your player to the "treasure" tile you need to click the tile your player is on and drag a line through the maze. The game will highlight your path as you drag. The tricky part is getting the "pathfinding" to respect the walls. It's more tricky because while each tile has a valid set of directions (up and right for example) it can be rotated so up and right becomes right and down and all the logic has to consider that.

Still, it's getting there. Whether I'll figure it all out before my boys grow out of Ninjago, I don't know.

First new update to SIncLib for a while. I've added a new QOL feature that takes the micro management out of stock control. Admittedly, this may defeat the point of a management game but if you want to think less about stock control then this may be helpful! Once a product has been released and you have purchased your first batch of stock, this feature will monitor your stock levels and check if last months sales are greater than your current stock level + x%. You can set the percentage to whatever you want, say 200%. In this example, if you sell 10,000 copies last month, the mod will order enough new stock to take you up to 20,000. If you set the percentage to 50% then the mod will ensure you have 5,000 copies in stock. If you have product printers then it will send a job to the printers, otherwise it will just order copies. This also works for software that you have acquired through takeovers or IP purchases so can be quite useful at making sure you're not missing out on any extra sales! Get the mod on the Steam Workshop, here https://steamcommunity.com/sharedfiles/filedetails/?id=2885461480

My Software Inc. code mod has been updated to be compatible with the Beta 1.3 version of the game. It can be downloaded from Steam Workshop here.

SIncLib (or Software Inc. Library) is a bunch of game play enhancing tools. This is the third release and the first for Alpha 11+. It has two features currently but I have plans to add more over time.

The first feature in this library is Team Manager. This is a tool that will optimise a software team by pulling staff from other teams if they have staff more suited to the current project. So, let's say you have a team developing a game that requires System, Audio and 2D specialised developers. If the team doesn't have those skills your game is going to suck. But what if you have those skills in your company already in other teams but you don't know where. The game currently doesn't make it easy to manage staff and find the right skills and this is where our tool comes in. Simply select the team you want to optimise, the teams you want to draw developers from and whether you want to adjust the HR settings to match. The tool will now move out developers not up to the job and replace them with employees with the right skills and in the right quantities.

The second feature enables out of stock notifications for products you didn't develop, such as products acquired in a takeover or products from an IP trade

Feedback and ideas very much appreciated.

GitHub for the project is here: https://github.com/realworld666/SIncLib