Interview about Sushi On Wheels: Taking a Food Truck Around Izu

For Neil, Sushi On Wheels started with a place rather than a game mechanic. After spending time living in Japan and travelling outside Tokyo, he found himself drawn to the smaller towns and communities that don’t get nearly as much attention in games. The Izu Peninsula was one of those places. It became the setting for his first proper commercial game as a solo developer.

In Sushi On Wheels, players take over their grandmother’s sushi truck and travel around Izu, serving customers, improving the truck and working towards her dream of opening a permanent restaurant. Neil has more than five years of experience working in the games industry, but making the game on his own has also meant taking on areas of development that were much less familiar to him.

Neil didn’t want to create another fictional version of Japan. He wanted to bring his own experience of Izu into a game, while still having enough freedom to make the map and gameplay work. We talked to him about that decision, the problems that come with recreating a real place, the realities of solo development, and some of the lessons he’s picked up along the way.

Why Izu?

There are plenty of games that use Japan as their setting, but Neil felt that many of them focused on a very specific image of the country. Travelling further away from Tokyo showed him something quite different.

It really came from travelling outside of Tokyo and seeing parts of Japan that I hadn’t seen represented very much in games.

Tokyo obviously gets a huge amount of attention, but once you start travelling further out you see these smaller towns and communities where populations are declining and younger people are moving towards the major cities. There are places that are a little more run down or quieter, but they still have so much character.

I felt that particularly strongly when visiting Izu. It didn’t feel like the big, polished image of Japan that you often see internationally, but in some ways it felt much more representative of everyday Japan for a lot of people who actually grew up there.

That was probably the point where I started thinking that this was a place I really wanted to represent in a game.

Once Neil decided to use Izu, he found there was already plenty there to work with. Real landmarks, festivals, markets and smaller communities all fit naturally with the idea of a food truck travelling around the peninsula.

One of the big reasons was simply that Izu already had so much character that I didn’t feel like I needed to invent it.

There are places like Mount Omuro, Shirahama, and the different coastal towns and landmarks around the peninsula that immediately felt like interesting game locations to me. There are also real festivals, markets and tourist spots where food and local businesses are an important part of bringing people into those communities.

That fitted naturally with the idea of running a sushi truck. The player is travelling around to these different places, meeting people and gradually becoming part of the community.

The people I met there influenced the tone of the game as well. I found people incredibly kind and welcoming, and there was a sense of familiarity to smaller communities that actually reminded me a little of rural Ireland. It felt very different from living in Tokyo.

That community aspect became quite important to the game. You’re building your own business, but you’re also helping bring people out to these locations and supporting the wider community around you.

A Real Place Doesn’t Always Make a Good Game Map

Using a real location sounds straightforward until you actually have to turn it into a game world. Real places don’t necessarily put everything where a game designer would want it.

That has meant Neil has had to make some compromises with Izu, and sometimes even change parts of the map after doing more research.

Finding the balance between the real geography and what works best for the game has probably been one of the trickier parts.

The game is inspired by Izu rather than being a one-to-one recreation, so I’ve always allowed myself to move things around or create fictional locations where it makes sense. But because I’m using real landmarks as well, sometimes learning more about the area means having to rethink decisions I’ve already made.

For example, I originally placed a lighthouse landmark in one part of the game map simply because I thought it worked well there. Later, while doing more research, I realised there was an actual iconic lighthouse in Izu, but on the opposite side of the peninsula. I wanted to use the real landmark instead, so I ended up rearranging parts of the map to accommodate it.

That’s been an interesting challenge throughout development: deciding when it’s worth changing the game to better reflect the real place, and when it’s better to bend the geography for gameplay. I want someone familiar with Izu to recognise it, but it still has to function as a good game world.

That approach carries over to the way the major landmarks are placed. They are recognisable, but the game isn’t trying to be a literal recreation of the peninsula.

I started with the major landmarks and tried to keep their general relationship to one another recognisable.

Mount Omuro is roughly where you would expect Mount Omuro to be, Shirahama is in the right part of the peninsula, the mine is where the mine should be, and the same goes for locations like the lighthouse and the onsen area.

They’re obviously heavily stylised rather than being one-to-one recreations, but I try to capture something about how they felt to me. Mount Omuro, for example, felt enormous and really striking when I visited, so I wanted it to have that same presence on the map.

There are places where I’ve deliberately broken the real geography because the game needs to come first. Some locations have been moved so that the map is easier to navigate or so that important areas aren’t clustered too closely together.

So I think of it more as a condensed, stylised interpretation of Izu than a recreation of it. Hopefully someone familiar with the region can recognise the inspiration while it still functions as its own game world.

The Sushi Truck Is the Main Event

The story in Sushi On Wheels gives the player a reason to keep building the business, but Neil didn’t want it getting in the way of the management gameplay.

The grandmother’s dream is there to give the player’s work some meaning, while the actual day-to-day gameplay remains focused on running the truck.

The management side is definitely the core of the game, and I didn’t want the story to constantly interrupt that.

Your grandmother’s dream is really the motivation that gives the whole game a purpose. You’re taking over this truck, building the business and ultimately trying to earn enough to open a restaurant in her name.

From there, the story is mostly expressed through the people you meet and the relationships you build while you’re working towards that goal.

I wanted the emotional side of the game to give meaning to the management rather than compete with it. You’re still spending most of your time making sushi, improving the truck and running the business, but there’s a personal reason behind why you’re doing all of it.

The truck itself is also more than something to drive around in. Upgrades directly affect how the business operates, while cosmetic changes can also have a small effect on customers.

I wanted almost everything you do to the truck to feed back into actually running the business.

The functional upgrades directly improve how efficiently you can work. You can prepare sushi faster, store more ingredients, cook rice more efficiently and get through your queue of customers more quickly. That means serving more people and ultimately earning more money.

Even the cosmetic side has a small gameplay role. The truck has a kind of attractiveness or beauty value, so creating a nicer-looking truck can make customers more interested in stopping to eat there.

I like the idea that by the end of the game, you can look at your truck and not only see that it looks completely different from when you started, but also feel how much more capable the business has become.

Solo Development Means Doing a Bit of Everything

Neil’s background in art and technical art gave him a good starting point for many parts of development. 3D art, animation, optimisation and Unreal were areas he already knew well.

Other parts of making a full game were a different story.

I had a reasonable idea of how many different disciplines were involved in making a game, but I definitely underestimated how much work some of them would be.

UI and UX were probably the biggest surprise. I honestly anticipated it would be the most difficult for me to adapt to, and it still surprised me. Almost every system eventually needs some kind of interface, menu, feedback or explanation for the player, and getting that to feel intuitive is much harder than simply making it functional.

Systems programming also became much more involved than I expected. You can design something that seems perfectly logical on paper, build it, and then discover through actual play that the assumptions behind it were completely wrong.

That process of implementing something, testing it, finding the edge cases and then rebuilding parts of it has taken up a much bigger part of development than I initially imagined.

His previous work in studios still proved useful, especially when it came to the technical side of the project. UI and UX, however, became a much bigger learning experience.

My art and technical art background has probably been the biggest advantage.

Things like 3D art, animation, optimisation and working inside Unreal were areas where I already had a strong idea of the pipelines I wanted to use and what was technically realistic. That meant I could move through those parts of development much more confidently.

UI and UX have probably been the biggest learning curve. I had done some of it before, but never at the scale where I was responsible for every menu and every interaction in an entire game.

I’ve rebuilt a lot of UI because I’ll finish something and then realise I hadn’t considered how another system would need to interact with it. It’s one of those areas where the more I work on it, the more I realise there is still to learn.

Some Ideas Just Have to Wait

Being a solo developer also means knowing when an idea is too expensive to make. Neil has plenty of ideas for things that could have been added to Sushi On Wheels, but every one of them has to be weighed against the rest of the project.

Absolutely. Coming up with ideas is the easy part.

If I wasn’t a solo dev, the game would probably have more locations, more narrative content, more small minigames and a lot more bespoke animation and little character moments.

Animation in particular is something I really enjoy, but when you’re working alone you constantly have to decide whether spending a day making one charming animation is more important than fixing a system that the entire game depends on.

I sometimes joke that I use the art and animation work as a reward for myself after finishing the less glamorous technical jobs.

There are plenty of ideas I’ve had to put aside, but I don’t necessarily see them as wasted. Some might eventually make their way into this game, and others might become ideas for completely different projects.

That is also why Neil’s advice for other solo developers starts with making the project smaller than the idea in your head.

I’d say make something much smaller than the game that’s currently in your head.

Come up with a small project, and then seriously consider cutting that idea in half again. Finish it, learn from it and make another one.

Sushi On Wheels might be my first proper commercial game of this scale, but it’s definitely not the first game I’ve tried to make. I’ve made a huge number of prototypes and smaller projects, and when I’ve abandoned projects in the past, it has usually been because the scope became too large.

I’d also say you should make something that you genuinely find interesting, because you’re going to be looking at it for a very long time. Ideally, even on the days when you’re completely tired of working on it, there should still be something about the idea that makes you think, “Yeah, but this is cool.”

The Prototype Wasn’t the Problem

There is one part of development Neil wishes he had handled differently. Once the prototype proved that the basic idea worked, he moved into production too quickly.

The biggest mistake I made on Sushi On Wheels was probably moving too quickly from prototype into production.

Once I had a prototype and realised the core idea was fun, I got excited and immediately started building all of the different features I had imagined. What I should have done was stop, take the prototype apart and spend some time building a really solid underlying framework for the full game.

Instead, I eventually had to go back and strengthen that foundation while trying not to break everything I’d already built on top of it.

So I’d tell other solo developers that once you’ve proven the idea works, resist the urge to immediately pile features onto it. Spend some time on the boring architecture first. It’s much less exciting in the moment, but you’ll be very grateful for it later.

That lesson fits pretty well with the rest of Neil’s experience making Sushi On Wheels. The game may be about running a sushi truck around Izu, but building it has involved a lot of decisions about what one person can realistically take on, where reality needs to bend for gameplay, and which ideas need to be left for another day.

For now, the truck is still heading towards that restaurant, with Sushi On Wheels planned for release on November 9, 2026.