Axe Ghost: Tomasz Kaye on building his card-based spatial tactics game with a buff ghost
I recently had the chance to chat with indie developer Tomasz Kaye about his recent Godot project Axe Ghost - an unforgiving turn-based spatial battle against an advancing monster horde.
In this interview, we had the chance to discuss lessons learnt from early collaborations, why marketing can't simply be bolted onto the end of development and why he feels "It's OK" to make use of LLMs to help improve the quality of his codebase.
Jared: Hey good morning Tomasz, I hope you're well! First things first, can you tell us a bit about yourself and your journey into game development?
Tomasz: My name's Tomasz Kaye. I'm from the UK, but I've been living for a long time in the Netherlands with my family. I studied painting, then worked in web development, then independent animation, then game development. I shared a studio with Richard Boeser, a good friend now, he was making ibb & obb at the time. He asked me if I wanted to do the sound design. That was a lot of fun! We worked together on Chalo Chalo after that, a slow abstract local multiplayer racing game. That's how I got started doing game stuff.
Jared: I'm just taking a look at the games you worked on with Richard now, the work is aesthetically beautiful with a really strong visual identity. Did these initial projects inform the types of game you wanted to make yourself?
ibb & obb (left) and Chalo Chalo (right)
Tomasz: It was more that working with Richard was a good match because I think our tastes are quite similar; his background before game dev was in industrial design; I appreciate his visual design sensibilities, and we both value economical design in the context of game design, meaning you look for what you can take away, and add things only conservatively and carefully if they really reinforce the ‘core’ of the thing you're making. We both enjoy the sports-like possibilities in games; games as competition between humans, in quite a pure sense.
Jared: I think that's a great philosophy to have to ensure that you deliver a focused experience rather than adding features for features’ sake. How have you been applying these ideas when coming up with the concept for Axe Ghost?
Tomasz: So the starting point for Axe Ghost was the question: What can I make on my own, that I'd enjoy playing myself, that I can make from start to finish in less than a year? What's the smallest game that satisfies all that? So I guess that added an extra layer of constraint on top; I knew I wanted it to be a short project - well, relatively short in game dev timelines at least. Going a bit further back, the idea of the advancing 'horde', and the task of keeping them at bay came first. Initially they were all dots. I made a little prototype without the card system. You had a couple of things you could do to destroy or push the dots back, and they advanced at the end of each turn. The idea was it would get harder and harder and eventually you'd die. Ruthless score-attack kind of thing. I thought, ‘That might be nice to develop out into a full game’... and then put it away for months.
Tomasz: I eventually added the boss Garnemar, and with him the closure of being able to win a run. I was sceptical about that at first, it felt a bit like a concession to a (extremely bare bones!) narrative, which went against the grain of this very focused thing I thought I was making. But by then, I already had the absurd buff ghost, which was doing... some kind of narrative work? And it just felt much better when your run didn't always have to end in dying!
Tomasz: Richard was one of the first players of Axe Ghost, and currently the record holder. It was good to get validation early on that this was fun for other people.
In-game screenshots from Axe Ghost
Tomasz: After sitting on the prototype for a good while, I started development in earnest after ChatGPT became a thing. I knew I wanted a leaderboard with some custom logic, which meant a backend. And the idea of slogging through building that was a big damper on my enthusiasm for making it! So when I noticed that the LLMs, even back then, could just cut through this kind of work, it felt like the right time to go for it.
Jared: It's interesting that you bring up LLMs as a tool that enabled you to get stuck into some of the less glamorous parts of the game's development. There's obviously a lot of discourse in the community (from both developers and players) relating to the use of generative AI. Not even GOTY contenders like Clair Obscure escaped scrutiny for including AI placeholder art as part of their workflow. Where do you personally land on where and when it is or isn't OK to make use of generative tools?
Tomasz: Yeah, an LLM, especially the more powerful models today, can really tear through jobs that - for me at least - have always been pretty miserable to do 'by hand'. In the case of Axe Ghost that meant Amazon's AWS service. I knew AWS could do what I needed, and I knew I could figure it out myself if I banged my head against the errors and help forums for long enough, but who wants to actually do that? Figuring out the abstractions of a whole system that you need a couple of small parts of to get back on track doing what actually matters to you, it feels bad! So during Axe Ghost development I was still copy/pasting code between a web chat interface and code editors, now, a few months later it's much more convenient again; you have Claude Code or Codex do the thing. Other non-glamorous parts of game dev where LLMs shine are code review and testing. LLMs love to write tests. I use GDUnit for my Godot projects, and today my code has better test coverage than it ever had before. The models are brilliant, but far from flawless, and issue tracking and tests are critical anchor points that help enormously in keeping them on track. With red/green test driven development directives 'baked in' to the hooks an agent uses, the likelihood of things breaking shrinks dramatically. It's funny that there's this idea that LLMs mean brittle and unreliable code, while I have the most robust and well tested codebase that I've ever worked with in my career now, thanks to the ability of LLMs to just grind through the boring stuff. If a big refactor seems like a good idea to make a whole project more maintainable, I won't think twice about having that happen now. A few years ago that was a terrifying prospect, and I'd often work around the existing (not quite right) shape of the architecture instead.
Tomasz: Like anyone else, I appreciate when things have been made with skill and care. I use LLMs; I don't use image or audio generation AI, I can get better results in those areas either by doing things by hand, or hiring others who do. Things can be made with care, or carelessly, whether or not AI is in the workflow. But because AI makes it cheaper and easier to create any given software product, it's much easier to publish something carelessly now. Power tools make it easier to put up buildings. They don't inherently create structurally unsound scaffolds, but they do make it easier to build things that might collapse. We're sensible enough not to blame power tools, or power tool users, for that state of affairs.
Tomasz: So when we're talking about OK vs not OK, it's a conversation about norms. There are two common claims:
- LLMs are environmentally harmful
The environmental impact of end-user LLM use is likely lower than the impact of watching streaming video, even if you amortise the training costs over those end users [1][2]. - LLMs are based on theft
When we put an image or piece of text out into the world, that work can be analysed, no one needs our permission. That's how culture has worked for as long as culture has existed. We learn from existing works and build on them. Analysis doesn't become illegitimate because a computer is doing it. For those who care about the legal dimension, the charge against AI training hinges on copyright infringement, that's not a variety of theft. Courts have been split on even that; two recent rulings found LLM training falls under fair use, one found it didn't [3].
Tomasz: Both of these arguments fail. Until better arguments appear (I didn't hear one yet) the default "It's OK" seems sensible.
Jared: Are you personally worried about any backlash from your audience regarding AI usage within Axe Ghost?
Tomasz: Worried isn't the right word. Wearily accepting maybe? I'm not going to self-censor, I understand that some will dislike my choices, for reasons I believe are mistaken. From private conversations I know several people who use AI routinely and never mention it publicly, because they've seen what happens when someone does: the dog-piling, the witch-hunts. Extrapolating, I expect there are a great many in that situation, particularly in the indie game dev scene. The bullying is half-effective: it doesn't stop people using AI, it stops many from talking openly about it.
Jared: From the conversations I've had with other devs, there seems to be a very clear line that shouldn't be crossed in terms of using AI to replace artistic output (i.e. graphical assets, sound effects, voice acting, etc.), Whereas, its use in tasks that won't be 'player facing' seems to be more widely accepted. Things like initial ideation, project planning, debugging/code-review. Would you agree with this?
Tomasz: The hard distinction is fake, there's no clear line because all of a game shades into 'player facing' (optimising draw calls for better fps, rearranging code to be async so that the UI remains responsive). I don't use AI for visuals and sounds because it's not good enough for that yet. Or I'm not yet good enough at using it to get what i want that way.
Jared: While you were making Axe Ghost, is there anything that you wished you could have done differently?
Tomasz: So one thing I got wrong with Axe Ghost was that I treated marketing as some distinct stage that happens close to the end of development. What I should have been doing is taking an expansive view of marketing (I think The Indie Game Clinic takes this view) that says, ‘You’re busy with marketing any time you’re making a decision that has some bearing on how your potential player will respond to the game’. The radical implication of this is that you need to have a marketing brain right at the start of development, when you're designing and evaluating a prototype. The most fundamental game design decisions matter enormously to how the game will land with players. Though I'm proud of Axe Ghost, and personally enjoy playing it, it's extremely difficult to communicate what it is to potential players. When people do give it a chance, they usually like it a lot, but getting to that stage is a big hurdle. On one hand this is kind of expected; I designed from first principles, which meant that there wasn't a ready genre short-hand for explaining what it was. On the other hand this is murder for having people actually try your game; people need at least some vague but correct idea about what it is they're getting into! Axe Ghost looks like a forgiving arcade-y thing (I like that look), but it's a cerebral thing and very unforgiving, but it's also based around a daily challenge. It misses the 'marketability' ring in every dimension! I wouldn't say "don't do this", because it was lots of fun to work this way. I will say "Be aware that this makes selling your game extremely difficult".
Jared: Is this something that you realised with the launch of the game itself? What was the initial response to the game like?
Tomasz: I realised it properly after launch. I could have realised it sooner, when the demo was launched. But, I guess by then my options were limited anyway! As to response: Those who tried it were very positive, the reviews were enthusiastic, for instance:
AXE GHOST is just that unique of an experience. I even have trouble trying to ascribe a genre to it." MASTERPIECE! - Tiny Gaming
Hubert Spala
Tomasz: But very few tried it, it currently sits at just ten reviews. I expected from the start that its appeal would be niche, but not quite this niche.
Jared: Let's talk about the development process itself, when you were planning this project why did you reach for Godot?
Tomasz: I'd used Godot for a few prototypes before. I especially like how small the framework is, that no subscription is required. And to me the abstractions are more elegant, they make more sense than those of Unity, the other engine I had experience with (used it for Chalo Chalo).
Tomasz: It gives peace of mind too that it's a FOSS project, you're less exposed to risk that the parent company does something questionable that ends up impacting your daily workflow.
Jared: You're certainly not the first person to bring up a game engine's parent company making questionable choices... Thinking about how Godot projects are structured, were there any parts of Axe Ghost which gelled nicely with the 'Godot' way of doing things? Conversely, were there any features within Axe Ghost that you had to really fight the engine to get in place the way you wanted?
Tomasz: It all felt pretty comfortable. I'd just gotten into the habit of relying on a signal bus, firing Godot's events, so that helped the various parts stay relatively clean. I'd built a little sound manager system, also event based, so I could request sound effects to play from anywhere in the codebase. The sound manager is a scene with lots of nested nodes, each group responsible for one named sound effect for the game, but each one has a different node hierarchy of children. For instance an explosion would layer three sounds, each drawn from a pool of 6, avoiding repetitions. This was a quick way to give a lot of richness sonically.
Tomasz: There are areas where the Axe Ghost code isn't great too. If I were doing it over, I'd use a pattern where a single object was the authoritative holder of game state, and that object dispatched 'visual update' requests to a visual update player, which would queue them up and dispatch in sequence. Instead of having state spread through objects that shouldn't really have that responsibility. This last thing isn't a Godot shortcoming, purely my own! But it is the case that there are relatively few good Godot tutorials dealing with good architecture for turn-based games, lots for more action orientated designs.
Jared: I think that's a common feeling at the end of most major software projects. It works as I want it to, but there are parts I want to completely rip out and build again!
Jared: So what's next for you? Will you be continuing to support Axe Ghost? Is there another project lined up? What does the road ahead look like?
Tomasz: If interest were to pick up for Axe Ghost there are a couple of small things I'd like to improve. But I've been searching around for the next thing since. Because speed of execution has increased so much I've been able to make four prototypes since Axe Ghost, this time keeping marketability more closely in mind right from the start. It's a fine line to walk! Two of the prototypes felt too derivative. It's easy to get pulled into the 'gravity well' of existing titles, where they seem to have solved all issues in the neighbourhood in such a great way that it'd be silly to do that particular thing differently. Maybe for game sales it's fine to make games very similar to existing ones, but that's not something that would motivate me. The most recent prototype is the most promising, a speedrun platformer this time.
Screenshots from Tomasz's current prototypes and experiments
Tomasz: Next to that I'm making a video editor - not ever a thing I thought I'd try - tired of the expensive subscription based things out there, and the free stuff doesn't quite work how I want.
Jared: Building a video editor sounds like a really interesting technical challenge, is that purely being built as a personal tool or something that may be realised more broadly?
Tomasz: Initially it’s for me, my wife, and brother, and if it remains reasonably non-janky once it’s feature-complete, I’ll likely make it more broadly available. It’s a grab bag of UI patterns from software I like: the magnetic timeline of Final Cut Pro, the combined zoom-and-pan draggable timeline ruler of Ableton Live, and a bunch of idiosyncratic features that are helpful for working with pixel-art footage in the way I often end up doing. For example, Shift-dragging in the viewer re-centers the footage so the clicked point becomes the centre, then enters scale mode. In every editor I’ve used, that would take a few separate operations. There'll be an integrated LUFS-based loudness targeting system. It won’t be as feature-rich as the big editors, but it will have its own identity.
Jared: It sounds really promising, and I think there's definitely a gap in the market for tools that offer a bit more than the basics without being nearly as complex as the big players. For example Canva has carved out a really big slice of the graphic design/publishing space.
Jared: Before we finish, where can people find you if they want to learn more about Axe Ghost or follow you on social media?
Tomasz: You can find Axe Ghost on Steam (there's a free demo too). For social media, I'm most active on Bluesky (@axeghostgame.bsky.social).
Axe Ghost is developed and published by Tomasz Kaye. It was released on 02/06/2025 and is available for purchase on Steam now.
Tomasz will also be taking Axe Ghost to GODOTCON in Amsterdam from the 23rd - 24th April.
References
- [1] - Using ChatGPT is not bad for the environment, Andy Masley
https://blog.andymasley.com/p/individual-ai-use-is-not-bad-for - [2] - What's the carbon footprint of using ChatGPT or Gemini? [August 2025 update], Hannah Ritchie
https://hannahritchie.substack.com/p/ai-footprint-august-2025 - [3] - Copyright and AI Collide: Three Key Decisions on AI Training and Copyrighted Content from 2025, Laura Smalley and Brendan M. Palfreyman
https://ipwatchdog.com/2025/12/23/copyright-ai-collide-three-key-decisions-ai-training-copyrighted-content-2025/
Member discussion