Ibrahim Abdo on Moving from Art Direction to Solo Game Development

A conversation about building an RPG alone after 20 years in art, animation, 3D environments, and game production.

Ibrahim Abdo is the Creative Director at Stranded Cat, where he is developing an original RPG in Unreal Engine 5.

His background covers more than 20 years across 2D animation, 3D props, environment art, art direction, technical art, teaching, and game development. He has worked on projects and with teams connected to Playrix, Obsidian Entertainment, Riot Games, and other studios.

What makes this interview interesting is the shift from professional art production into solo game development. Ibrahim is not only making art for games, but building his own game world, managing scope, learning technical systems, and turning years of visual experience into an original IP.

The conversation is aimed at indie developers, artists, founders, and small teams who want to understand how game art direction shapes visual identity, production decisions, and the transition from creating art to building a complete game.

Q: You have a long background in art, animation, 3D environments, and game production. What pushed you toward building your own RPG?

A: I have always been drawn to experimentation. New technologies, new ways of making things. That curiosity is what pushed me from 2D animation into art direction and eventually 3D environments.

Growing up playing Blizzard games like World of Warcraft left a lasting impression on me. Those worlds felt alive in a way that stuck with me. At some point I just wanted to try building something like that myself, my own world, my own systems.

There was also something personal in it. Back in the early 2000s I used to make Flash games, and I had this feeling of making something complete on your own. That feeling faded as I moved into professional production, and I wanted to find it again.

The timing helped too. Game engines have come a long way, things that used to require a full team are now reachable for one person. That made it feel like a reasonable thing to try, not just a far-off idea.

Q: Your devlog has a very honest title: “No Clue How to Code! My Dream Game.” What was the hardest part of moving from visual production into actual game development?

A: Honestly, the hardest part has nothing to do with code. It is the mental shift between being an artist and being a developer.

When you are building a system, you need placeholder elements just to test if the logic works. But as an artist, I kept falling into the same trap – I could not bring myself to drop in something rough. I would end up building the item properly, giving it real art and detail, and then scrapping most of it after testing.

That cycle taught me prototyping in a real way. Now I try to be deliberate about which mode I am in, because the two mindsets do not mix well.

Q: How did your art direction background help you as a solo developer?

A: Coming from an art background gave me a strong advantage in shaping the visual identity of my game, especially when it comes to creating high-quality stylized environment art, which is something I’ve done professionally for years. So instead of relying only on pre-made asset packs and trying to combine unrelated assets together, I can build a world that feels coherent, readable, and visually consistent.

For me, that’s very important because gameplay is not the only thing that attracts players. The clarity of the world, the mood, the visual language, and how well all the elements fit together can make a huge difference. As a solo developer, my art direction experience helps me avoid the common problem where indie games feel like a mix of disconnected assets, and instead helps me create something with a stronger identity and a more polished presentation.

Q: What parts of solo game development surprised you the most?

A: What surprised me the most was how time-consuming solo game development really is. I expected it to be difficult, but I didn’t fully realize how much time every small system, asset, decision, and technical problem can take when you are doing most of it yourself.

In my case, it was even more challenging because I made a conscious decision not to rely too heavily on ready-made systems, presets, or tools from the Fab marketplace. I wanted to use the project as an opportunity to properly learn and master Unreal Engine Blueprints and understand how the systems work, instead of just plugging in solutions made by someone else. That helped me grow a lot, but it also made the process much slower.

The biggest surprise was probably how important planning and time management become. As a solo developer, you are not only the artist or designer – you also become the programmer, producer, tester, and problem solver. So even if you have the skills to create something, you constantly have to manage scope and decide what is worth building now, what can wait, and what might be too expensive in terms of time. 

So the main surprise was not only the technical challenge, but how much discipline and production thinking solo development requires.

Q: When you are building an RPG alone, how do you decide what to keep, simplify, or cut?

A: For me, the most important word is prototyping. That becomes even more important when you are building an RPG alone, because RPGs usually involve many connected systems – combat, farming, inventory, NPC interaction, quests, progression, and so on. In my case, the game has several of these systems working together, so I need to constantly test ideas before fully committing to them.

I’ll admit that I still sometimes fall into the trap of wanting to build too much, but the more I work on the project, the clearer it becomes which systems are essential and which ones can be simplified or removed. Sometimes a feature sounds great on paper, but once you prototype it, you realize it doesn’t add enough value compared to the amount of time it takes to build.

That’s why having a clear Game Design Document is very important. It helps define the core experience of the game and makes the features easier to judge. When the main vision is written down, it becomes easier to ask: does this feature support the core gameplay, or is it just extra complexity?

So my approach is to prototype first, keep the systems that strengthen the main experience, simplify anything that is too expensive for its value, and cut features that would risk turning the game into a 20-year project.

Q: Your work includes stylized environments, props, animation, and 3D production. How do you keep the visual style consistent when you are responsible for so many different things?

A: Keeping the visual style consistent is one of the biggest challenges in solo development, especially when you are responsible for environments, props, animation, and 3D production at the same time. A common issue I notice in many solo or indie games is that the visuals can feel disconnected, because the developer uses many different asset packs that were not designed to work together. Even if the gameplay is interesting, the game can lose its identity if the art direction is not coherent.

I think this often happens because many developers come from a programming background, so the visual side can become secondary. On the other hand, artists who make games can sometimes focus too much on the visuals and not enough on gameplay. For me, the goal is to find the balance between both: a game that plays well, but also has a clear and recognizable visual identity.

That is one of the reasons I decided to create most of the assets myself. It allows me to control the shape language, colors, materials, proportions, and overall mood of the world, instead of mixing assets that may not belong together.

I also try to approach it in a professional way, the same as I would in an art direction role. I use mood boards and references to define the direction early. In my case, I organize references in Trello, including environment images, videos, gameplay examples, materials, and lighting references. That helps me stay focused and avoid drifting into different styles.

Another important thing for me was to create a final-looking visual setup early in development. Even if the game is still in progress, having a clear target for lighting, color, materials, silhouettes, and post-processing gives me a strong visual foundation. After that, every new prop, environment, or animation can be judged against that direction, which helps keep the whole game consistent.

Q: You have worked as a 2D animator, technical artist, 3D environment/prop artist, and creative director. Which part of that background became the most useful for your own game?

A: I think the most useful part is not only one specific role, but the combination of all of them. My background has been a gradual evolution through different areas of game development. I started in the early 2000s making Flash games, where I was mainly a 2D animator, but I also learned how to write simple scripts in ActionScript 2. That gave me an early understanding of how art and interactivity connect.

From there, I moved more into illustration, 2D art, and eventually 3D environment and prop art. Later, because I had experience in animation, 2D, 3D, and a bit of scripting, it naturally pushed me toward technical art as well. So I became more of a generalist over time, not by planning it from the beginning, but because each step added another layer to my skill set.

Now, as a solo developer, I see making my own game as the next natural evolution of that journey. Every part of my background helps me in some way: animation helps with movement and timing, environment art helps with world-building, technical art helps with problem-solving, and creative direction helps me keep the whole project focused.

So I would say the most useful thing is being a generalist with an art direction mindset. It allows me to move between different parts of production and understand how they all support the same game vision.

Q: You worked on projects like Pentiment and game animation projects before building your own IP. Did working on other games change how you think about your own production?

A: Yes, definitely. I was very privileged to work with extremely talented individuals on different projects. Every team I worked with added something to the way I think about game development, whether it was about production, communication, visual direction, animation, or how to solve problems creatively.

One thing I learned is that every project has its own rhythm and its own way of working, and being exposed to different pipelines helped me understand production more realistically. It made me more aware of how important planning, consistency, and decision-making are, especially when you are building your own IP and you don’t have a large team supporting every department.

From my experience, some of the most fun and creative projects were the ones made with smaller teams. In smaller teams, the exchange of experience happens more naturally. You are closer to the decisions, closer to the problems, and you can learn directly from people around you. That had a big impact on me.

So when I started working on my own game, I didn’t think only as an artist anymore. I started thinking more like a producer and a developer too: how to keep the scope realistic, how to make creative decisions that serve the game, and how to build a project that can actually be finished.

Q: What do artists often underestimate when they start making their own game?

A: I think artists often underestimate three main things when they start making their own game.

The first is the danger of creating final art too early. As artists, we naturally want to make things look beautiful and polished, but if the gameplay or level design has not been tested yet, a lot of that work can end up being changed or even completely scrapped. I learned that it is better to prototype first, test things inside the game, and only then spend serious time on final assets.

The second thing is gameplay. Artists can sometimes focus so much on the visual side that they underestimate how important the gameplay experience is. A game needs to be enjoyable to play, not only nice to look at. The player needs a reason to keep going, and that comes from a strong gameplay loop.

The third thing is optimization. It is very easy to build beautiful environments that look good in screenshots but don’t run well in real time. So I think it is important to keep the frame rate visible while testing, optimize assets as you go, use lighting properly, and always check that the game runs smoothly.

I personally fell into all of these traps during the development process, so I learned that making a game as an artist requires a shift in mindset. You still care about beauty and style, but you also have to think about gameplay, performance, and whether the work actually serves the final experience.

Q: What advice would you give to artists who dream about making their own game, but feel blocked by code, scope, or fear of starting?

A: My advice would be to start small. You don’t need to begin with a huge 3D RPG or an MMO. Taking your first steps in solo game dev can be overwhelming, and a lot of artists block themselves because they imagine the final dream game immediately, and that can feel impossible. But the better approach is to start with a small prototype, one mechanic, or one simple scene, and build confidence from there.

Today, we also have much more accessible tools than before. Unreal, Unity, and Godot all make it easier for visual people to enter game development. In my case, Unreal Blueprints helped a lot because it feels more designer- and artist-friendly than traditional coding. It allows you to understand logic visually and gradually learn how systems are built.

Also, with the current AI tools, artists have even more support than before. You can use AI to help explain code, generate small examples, or guide you through technical problems. Of course, relying on it too much can create debugging nightmares later, so you still need to understand what you are building. But as a learning assistant, it can be very helpful.

So I would tell artists: don’t wait until you feel fully ready. Start with something small, learn one system at a time, and accept that the first version will not be perfect. The most important step is to begin, because once you start building, the fear becomes much smaller.