At the end of August, I usually take two weeks to drive down to Austria to visit my grandparents, who live in a small village near Graz. This is pretty much the only time of the year when I step away from computers, game development, and everything else for a longer stretch. Instead, I spend my days taking long walks and bike rides through the nearby forests and mountains while enjoying time with my grandparents.

This also means the blog will be on pause for the next two weeks. I'll pick it back up once I return. I think it's important to step away from everything once in a while, reset, and come back refreshed.

I hope you're also making the most of the warm weather while it lasts. Cheers!

I just got back from Gamescom and had an absolute blast this week. I managed to get a trade visitor ticket and arrived on Tuesday afternoon, where I already got to try out some games at the Devcom Expo. A few of them I had already played at GG Bavaria earlier this year, while others were completely new to me.

The next day, Gamescom officially kicked off, and all trade visitors, exhibitors, and press were able to try the latest games on display. I played a lot of the new AAA and AA titles, and my favorites were Reanimal, Borderlands 4, RE9, Lego Batman, Silent Hill f, Pragmata, and Cronos. I wanted to give Silksong a try too, but the queue was so long that it just wasn't worth it.

On the second day, I also checked out the indie area, where I played plenty of games like Fractured Blooms, Adaptory, Greta Sees Ghosts, Altered Alma, and Death by Scrolling. I even got to chat with some of the developers, which was really fun.

I spent Thursday and Friday mostly exploring the rest of the convention, meeting up with people I know, and getting to know new people from around the world. This was actually my first-ever Gamescom, and I'll definitely be going again next year, though I might focus more on networking than playing, since gameplay usually shows up online not long after Gamescom anyway.

If you want to catch me at the convention next year, feel free to message me, and we can grab a drink together. :)

Since my last projects were either direct PvP or PvE, I wanted to try something we don't see often in Fortnite: an RTS! The concept is similar to Clash Royale, where you choose your units and deploy them in the arena to destroy the enemy's objectives. The twist is that you, as the player, can actively defend your objectives instead of relying on turrets or towers. You'll need to balance when to defend yourself and when to deploy units, all while keeping track of what the enemy is doing.

Most of the core mechanics are already implemented, and I'm currently working on the art. I'll document the project in detail in my portfolio once it's finished, since there were some interesting technical constraints that led to tough design decisions. I probably won't have it ready before Gamescom, but I'll let you know when it's done. You can already play and test it by joining my Playtest group here!

Verse being part of UE6 was already announced back in October of last year, which is part of the reason I wrote my bachelor's thesis on UEFN and UE5. I use both of these tools to create my games, and I personally believe that UE6 will be a huge milestone in game development, so I'm doing everything I can to prepare for it. It's still quite a while away, but that gives me the time I need to really dig into everything required to work with it.

C++ and Verse are the two programming languages I use most, and I'm constantly working to improve my skills in them. I'm also starting to explore concepts like Scene Graph and other new features to deepen my understanding of the engine and the development process.

There's so much to discover and learn that most of my time is split between development and studying. I'm even considering adding another semester to my master's program to get more time to work through everything I want before trying to enter the industry.

Disclaimer: The sounds I used for this are not my own. I found them on the internet and I don't know who the original creators are. If you are the creator and you want me to remove the sounds, please let me know.

I'm a huge fan of giant, over-the-top weapons in games, and I wanted to implement something like a killstreak from Call of Duty within Fortnite. It should be callable and wreak havoc wherever it hits. So I thought an orbital laser would be the perfect fit, and you can see the result of my implementation above.

It's activated using a remote, and the laser strikes wherever the player was looking when it was called. You can combine this with a damage volume that activates on impact to deal massive AOE damage, or even do other fun things like terrain manipulation.

This took about half a day to implement, and I might use it when I create a multiplayer shooter or something similar.

This year I took part in AUXJAM 2025, a game jam organized by my university. The theme was "Kreislauf", which can be translated into English in different ways depending on the context, but it basically means something like cycle, loop, or circulation. That made it a pretty broad theme since almost all games have some kind of game loop. So, I got together with a couple of friends and we created a fun dating sim called Tower of Rizz (yes), where the player goes on three dates to test their "rizz". If they do well enough, they're crowned the Rizz-Lord. If not, they're kicked out of the tower and have to start over.

You can find our itch.io page here (it's in German, as is the game).

We had 48 hours to complete the game and actually managed to finish what we set out to do, even if we had to make a few compromises. The only thing we didn't quite get to was the final cutscene at the end. If you pass all the tests, you're supposed to be crowned the Rizz-Lord, and then the game ends. Unfortunately, that crowning cutscene didn't make it in, so the game just closes when you win.

We made the game in UE5.6, and my role was programming and “gluing” everything together. I handled the logic for the mini-game where you eat a fly to choose your answer, and I was also in charge of the overall game flow. I worked alongside another programmer who took care of the dialogue system. The artists on our team provided the assets, and I implemented everything in-game.

Looking back, I'm really proud of what we achieved in such a short time. We made everything ourselves, from the art and music to the code and writing. It was a very fun jam, and I encourage you to check out the other submissions too. A lot of teams made some really cool games. I'll definitely take part again when the next jam rolls around.

I built a small mechanic in Verse that lets players swap between two different locations in real time. The inspiration came from Five Nights at Freddy's: Security Breach. In that game, when the player puts on the Vanny Mask, they're transported into an augmented version of reality. This works by teleporting the player to a different level that is layered on top of the base level.
I first saw this here.

I wanted to try implementing this in UEFN. Since UEFN offers teleporters, I created a custom device that uses a teleporter placed above or below the player, allowing them to swap positions at any point in the game. All the player needs is a remote or some form of input to switch between the two levels. You can simply stack the levels, adjust the teleporter distance, and recreate an effect similar to what you see in Security Breach.

What makes this exciting to me is the potential for storytelling and gameplay. Imagine using this in a puzzle or mystery game. Players could shift between realities to gather clues, solve problems, or piece together parts of a larger narrative. One world could give context to the other, and players could use that layered knowledge to progress.

I've also shared an updated version that works in multiplayer on my GitHub, in case you want to use or build on it.

Lately, I've been thinking about how much depth there really is to game design. We usually talk about mechanics, systems, feedback loops, etc.. And sure, those are all important. But I'm starting to realize there's another layer, one that's just as essential but often flies under the radar.

It's the human side of design. Understanding how people think, what drives them, what holds their attention, what pushes them to act. I'm talking about things like player psychology, motivation theory, behavioral economics, even a bit of neuroscience. These aren't always part of the traditional design toolkit, but they shape the player experience in ways that systems alone can't. For me, this realization has been a bit of a turning point. The more I learn about how players respond on a deeper level, the more intentional I can be with my design choices. I'm not just building a game mechanic anymore. I'm shaping how someone might feel, where they'll lean in, when they'll surprise themselves.

I noticed the senior designers I worked with seem to carry this knowledge almost intuitively. They've built up a sense for it over years of watching people play, seeing what lands and what doesn't. But for those of us still building that experience, digging into the theory is one way to speed up the process. It gives you a lens to interpret what players are doing and why.

Right now, I'm reading Thinking, Fast and Slow by Daniel Kahneman and Influence by Robert Cialdini. Both are helping me connect the dots between human behavior and game design. And honestly, there's a whole stack of books I've been meaning to get through, so I'm hoping to make some real progress now that summer break's here.

If anything interesting jumps out at me along the way, I'll share it here.

I wrote a post on this blog recently about how picking up different skills can help you express your ideas more fully, and today I want to dig into how to actually learn those skills in a way that's efficient, sustainable, and meaningful. This is something I've had to figure out through a lot of trial and error. I'm still constantly learning how to learn, but maybe some of these insights can help you out.

When it comes to learning, the biggest thing I've realized is that balance matters. You need both input and output, learning new concepts, then applying them. If you take in too much theory at once, it starts to blur together. Your brain gets overloaded, and what you thought you'd remember just slips away. But if all you ever do is practice what you already know, you get stuck. You might feel productive, but you're not actually growing.

So now, whenever I'm trying to learn something new, whether it's animation, level design, or even just a new piece of software, I try to keep this rhythm: learn a little, practice a little, then pause and reflect. I ask myself: What went well? What didn't? Why? What's the next step?

It sounds simple, but it's surprisingly effective, at least for me. It helps me see where I'm improving and where I still need work. And it saves me from falling into that trap of just grinding without direction.

The truth is, learning isn't just about putting in the hours. It's about how you use those hours. You don't get better by repeating something endlessly. You improve by targeting what you're struggling with and figuring out how it actually works. That's why I think the 10,000-hour rule is not only false, but can actually mislead people.

So if you're trying to grow your skill set, whether for game design or anything else, start with a clear goal, stay intentional, and don't forget to step back now and then to see the bigger picture. That's where real progress happens.

It's crazy to think that the first semester of my master's is already coming to a close. To me, it feels like it just started yesterday. We've made really good progress over the past few months and laid the foundation for our game. We're now also completely done with the concept of what we want to build, and we'll continue with more detailed planning over the holidays so we can hit the ground running next semester, when we have to finish and submit the game.

After that, in the third semester, I'll either take a break to do some research or start working on my master's thesis. I'm not quite sure yet. I have a few ideas for what I might want to write about, but I also feel like I need more time to explore some of the tech I want to use before diving into it.

Anyway, I'll post more updates about the master's once the new semester kicks off.

At the end of every semester I usually have to give quite a few presentations about the projects I worked on during the semester. Some are in front of classmates, some in front of professors, and occasionally, a few are part of a bigger event where we meet with people from other universities. Over time, I've realized that the way I present can change how people understand and remember my work. But figuring out how to do it well didn't happen all at once.

In the beginning, I focused too much on trying to sound impressive. I'd cram slides with technical details, use complicated phrases, and try to cover everything I'd done. It never felt quite right. I could tell people were tuning out halfway through, and honestly, I didn't blame them. It wasn't until I started thinking more about the experience of the people listening that things started to shift. What helped most was learning to tell a story. Not in the sense of making things up, but in connecting the dots in a way that made sense to someone who hadn't been inside my head for the past few months. Every project has a journey: what problem I started with, what didn't work, how I overcame the challenges, and what I ended up discovering. Framing my presentations around that kind of narrative made them feel a lot more alive and engaging.

I also started paying attention to how much information was enough. When you're deep in a topic, everything feels important. But in a presentation, more isn't always better. I've learned to pick a few key ideas I really want people to walk away with. That means cutting a lot, which can be hard, but it brings clarity. I remind myself that people can always follow up later or check the documentation if they want more detail. Of course, what you always have to keep in mind is the goal of your presentation. A pitch, for example, is structured very differently from a semester project presentation. If you can figure out what your presentation is meant to achieve and what the people attending expect, you can shape it to actually meet that need.

Finally, I've learned not to underestimate the value of presence. Making eye contact, pausing to let things sink in, and being okay with silence is not about being charismatic or flashy. It's about being present. When I show up as someone who believes in what I'm saying, even if I'm a little nervous, people tend to respond.

I still get a bit nervous before some presentations. That hasn't gone away. But I've also started to enjoy them. They've become an opportunity to share what I've learned, reflect on the process, and connect with others who might see things differently. That, to me, is the real purpose of a presentation. Not just to inform, but to engage.

We held a mini game jam over the course of 5 hours to create a fun little VR game we called Crazy Bowling. I worked with two of my friends to make this game, where you experiment with different bowling balls to find wacky combinations and try to knock down all the pins in one go. We used Unity because it has an easy-to-use XR toolkit, which allowed us to build the game quickly and export it as a .apk for the Meta Quest headset.

I was responsible for most of the coding and for setting up the game world and prefabs, like the bowling balls, pins, and any scripts related to them. I also created 3D meshes for the backdrop, like the houses and spaceships you see in the game. I even had some time to play around with a synthesizer to give the game a bit of a dystopian alien apocalypse vibe, which was the theme we went with.

Making this was a lot of fun, and I always enjoy doing little game jams like this. There's another one coming up at the end of July, and I'll be taking part in that too. I'll share the results once it's done.

A fellow student asked me recently why I spread myself across so many different skills. They had noticed I spend time practicing 2D art, 3D art, programming, and even building with Lego, instead of focusing on one medium and aiming to master it.

It's a fair question, and I think in the games industry it comes up a lot. Some people choose to specialize in one role within a large team. Others become generalists, able to take on many parts of a project, often working in small teams or even alone.

For me, it comes down to the kind of work I love most. I really enjoy prototyping, and prototyping often demands a little bit of everything. One day it might be sketching an environment, the next it might be writing dialogue or composing a bit of music. Then I might spend the rest of the week programming systems to make it all come alive. If I only knew how to do one of those things, I would have to stop and wait for someone else before I could test my ideas. That would slow me down and, more importantly, create distance between the idea in my head and the version I can put in someone's hands.

Every skill I learn removes another barrier between vision and reality. That freedom is what I value most. It is not that I avoid mastery. I am deeply focused on mastering game design itself. The difference is that I see a wide range of creative skills as part of that mastery.

Games are a blend of many art forms. Understanding how each part contributes to the whole makes me a better designer. Building a broad skill set has taught me how to bring an idea to life without losing its shape along the way. For me, being a generalist is not a compromise. It is the most direct way to create the work I want to see in the world.

I picked up Scott Robertson's How to Draw book, and even though I've only been using it for a couple of days, I've already gotten so much value from it. I think the book does a great job of guiding you through the fundamentals, which are the most important part of drawing in my eyes. I really like the approach the author takes to drawing, though I can understand it's not for everyone. I'll keep using it and see where things are a couple of months from now. :)

I know it's been a while since I posted one of my Lego MOCs, but to be honest, it's hard to work on any during the semester since all my Lego is in Munich. But I finally got the chance to spend some time there and put together this Lego Star Wars-inspired MOC, using some repurposed gunship parts and pieces from my collection. I spent about an hour or two on it.

I really think having something where you can express yourself creatively away from the computer screen is refreshing. You can actually feel every brick in your hands, and when the finished model is sitting in front of you or on a shelf, it feels like you've accomplished something, even if it wasn't super ambitious.

By the way, if you're into Lego Star Wars MOCs, I highly recommend the YouTube channel 2bricks:

https://www.youtube.com/@2bricks

He creates absolutely stunning MOCs, and I find myself watching almost all of his videos. He goes into detail about how he designed his builds, how he solved challenges, and more. I wish I had more time to dedicate to building MOCs, but making games is even more fun, so I'm not complaining.

I took part in a 2-day workshop at my university led by Jonas Wurm, a concept designer at Aesir Interactive. You can check out his work here:

jonas-wurm.artstation.com

He showed us a great method for creating concept art using both 3D and 2D tools. Everyone in the workshop was given the assignment to come up with a vehicle concept and then create it, ideally using the techniques he demonstrated. Above, you can see my work in progress. There's still over a month left until the assignment is due, but I'm not someone who likes to procrastinate.

As you can probably tell, my concept is a combine harvester repurposed as a zombie-killing machine for a video game. The setting is the USA in the 1990s. The image is a direct render from Blender, and I will now start painting over it in Krita, adding details like wear and tear, blood, bolts, and more. I'm really happy with it so far and I'll post an update with a full description of the features and the reasons behind them when it's done. If you happen to see this before July 18, 2025, feel free to email me any feedback you might have :)

I just finished reading The Beginning of Infinity by David Deutsch. I'm someone who's very interested in how the world works, especially the vast, mysterious universe beyond our everyday lives. Because of that (and because physics was my favorite subject in school), I read a lot of science books.

You might be wondering what any of this has to do with game design. But if you think about it, making games is a lot like creating your own mini-universes. We invent the rules, build systems, and then watch as entirely new kinds of gameplay unfold.

While scientists strive to make sense of the given, we designers must construct systems whose internal logic will make sense of all that can arise within them, letting the players take the role of the scientist. Any successful game design, whether minimalist, experimental, or narrative-driven, involves designers making choices about why certain elements are included and how they will interact with players to create a desired experience. These choices, implicitly or explicitly, are the "explanations" of the design. If the design works well, the underlying explanations are "good". If it fails, they are "not good enough".

What Makes a "Good Explanation"?

According to Deutsch, a good explanation is both hard to vary and has reach.

Hard to vary means that every part of the explanation is essential. Change one detail, and the whole thing falls apart. In games, an example might be: "Emotional investment in a game's story depends on consistent character motivations, meaningful consequences, and real moral dilemmas." If you remove any one of those elements, the explanation no longer holds. That's far more useful than something vague like "players enjoy compelling stories," which can be arbitrarily tweaked without leading to deeper understanding. This doesn't mean that our designs can't be modular and should collapse with the slightest change, it's about the reasoning behind the design choices.

Reach refers to how broadly an explanation can be applied. A good explanation doesn't just describe one situation, it generalizes. It predicts, it scales, it adapts. This makes it especially powerful when we apply these explanations across multiple games or experiences.

How To Create Good Explanations

Modern game development leans heavily on data and AI to predict what players will do. But as Deutsch points out, predictions without explanations are often parochial when it comes to advancing true understanding. While data and advanced AI can certainly offer powerful predictive capabilities (even from "black box" models), they primarily tell us what is happening or what will happen. They may not always reveal the underlying why.

Data can tell us what players are doing. Explanation tells us why. That's where the real leverage is for human understanding and design improvement. Yet designers often settle for vague or superficial reasoning. They might say, "players quit because they're bored", when a stronger explanation could be, "players disengage when the challenge-to-skill ratio drops outside their optimal flow state". This explanation is hard to vary because it connects key elements like challenge, skill, and agency. It gives us a clearer picture of what's actually going wrong. And it has reach, as it can be applied to multiple games and situations.
Technology can help uncover these patterns, but only if we use it to pursue real understanding. We need to dig deep, drawing on every possible source of information to form an explanation that is both hard to vary and has reach. If it fulfills these criteria, you're likely onto a good explanation.

The Beginning of Infinity

When creating good explanations, we can think of game development as a cycle of knowledge creation. Every design decision is a hypothesis. Every A/B test, playtest, or market result is a potential refutation. When something doesn't work, a feature falls flat, a tutorial fails to teach, it's not a failure. It's a refutation. And that's valuable. It tells us the explanation we were working from wasn't good enough. So we revise, test again, and improve. This isn't guesswork. It's the scientific method, applied to design.

Embracing good explanations transforms game design from a reactive, trial-and-error process into a proactive, knowledge-driven craft. It allows us to build systems with greater depth, flexibility, and longevity and enables us to grow as a community. It helps us understand our players, not just how they behave, but why they behave that way. Of course, the practicalities of game development (tight deadlines, commercial pressures, and the sheer complexity of player psychology) can make consistently digging for perfect explanations challenging. Yet, striving for this deeper understanding, even in the face of these constraints, through post-mortems or dedicated research time, is what makes us grow.

Viewed this way, game development becomes an "infinite game." There's no final form, no ultimate patch, no perfect balance. There's only progress. A continuous loop of conjecture and correction, problem and solution, mistake and insight. To support this, studios need a "culture of criticism": one that rewards debate, encourages testable ideas, and discards easy-to-vary assumptions. It's a mindset of optimism, the belief that with better explanations, we can always improve.

The opening showcase for Unreal Fest 2025 just wrapped, and UE5.6 looks to be all about optimization, which really shines in what they've done with The Witcher 4. That game looks absolutely insane! I've never seen a game with such high visual fidelity. The demo was apparently running on a base PS5, which is incredibly impressive. I can only imagine how high-end PCs will turn this game into an experience where you'll just want to stop at every corner and soak in the environment. Since it was a tech demo, not much gameplay was shown, which is what interests me most, but that will come soon enough.

Next, they showcased a bunch of games using UE5 to power their creative vision, with Expedition 33 being the standout. I think this game is a huge indicator of where our industry is headed. I personally believe that AAA experiences won't just be delivered by large studios anymore, but by smaller teams as well. With the advancements in AI and the tools Epic is providing developers (like MetaHuman), a lot more work can be done by fewer people. So, I expect to see more small studios forming and our industry diversifying exponentially in the coming years.

Then came the UEFN showcase. As a Fortnite Creator, the new features coming to UEFN are particularly interesting to me, especially things like the Persona NPCs. These NPCs use LLMs to react to what the player is saying or doing, creating a unique experience with every playthrough. While it was a bit goofy in the showcase, we have to remember that this is just the beginning. AI today is the "worst" it will ever be.
But I also think generating dialogue is the least interesting part of AI in video games. There are so many possibilities for how you can use it as a dungeon master, worldbuilder, and much more, which is something I'm actively exploring in my master's degree.

Another interesting, though predictable, feature was the AI Verse code assistant. Until now, no AI was able to generate Verse code because the language was too niche and inaccessible for LLMs to pick it up. That's why my portfolio projects still feature code snippets, as this is code I've written to showcase my understanding and application of the language. I think being experienced in Verse will still be useful, but with the AI Verse code assistant, I'll be able to create more, faster.

I've been working on a new game called Formulate (formerly "Equation Ascent"), a strategic math-building roguelike where you construct mathematical expressions to achieve target scores. It's been a great way to put into practice what I wrote about in my previous article on using AI for game development prototyping.

Core Concept:
In Formulate, you build mathematical expressions by combining numbers and operators from your hand. The goal is to reach target scores that increase with each level, but there's a twist - longer expressions and strategic use of operators can significantly boost your score. The game features a unique scoring system: (Result + 2×Length) × Upgrades, which encourages creative expression building rather than just finding the highest possible result.

Development Process:
Following the process I outlined in my AI prototyping article, I started by clearly defining what I wanted to achieve. I knew I wanted to create a game that made math engaging and strategic, rather than just educational and I wanted to use the Balatro framework as I think it fits this game well. Using AI, I was able to quickly prototype the core gameplay loop using Pygame. The AI helped me implement features like the expression validation and scoring logic, which would have taken much longer to code manually. What you see in the video above took about 2 hours of implementation and iteration. It is still very basic, but it's enough to test my ideas.

I'm still working on polishing the game and adding more features, but I'm excited about how it's shaping up. It's a great example of how AI can help bring complex game mechanics to life while maintaining the creative vision and design decisions that make a game unique.

AI is rapidly changing game development, and I'm always looking for ways it can help designers like me get ideas working faster. I've personally used AI to make prototypes in a fraction of the time, like my Phaser-based Beatwitch game, which went from idea to playable in just hours. You can find it further down in my blog. This way of working is super helpful for quickly testing game mechanics and ideas.

But there are some really important things to keep in mind. This article will show you how I use AI for prototyping, give you essential tips, and explain how to get the most out of it.

My AI Prototyping Process

1. Know Exactly What You Want
Before you start with the implementation, you need to know exactly what you're trying to do. Let's say you're building a double jump in UE5. First, write down everything you want it to do. This might sound obvious, but being specific here is key. The more detailed your prompt, the better the AI's result will be. For more complex tasks, like making a procedural planet, do your research first to get rid of any false assumptions and to get a better understanding of the task yourself. Gemini's Deep Research is a great tool for this.

2. Let AI Help You Plan
Once you have a clear goal, let the AI help you figure out how to get there.

• Understand the Scope: Ask the AI for a basic overview of what your goal needs and any limits or pitfalls you might encounter.
• Get Recommendations: Have the AI suggest the best ways to build it. This lets you choose the best approach for your project.
• Make a Detailed Plan: Ask for a step-by-step plan to reach your goal. You can basically have the AI create a plan for another AI to implement it. This gives you a good prompt out of the box.
• Check the Plan: Before you proceed, carefully read over the AI's plan to make sure it matches what you want.

3. Build with AI (and Understand the Code)
After you have a solid plan, have the AI execute on it. Even though AI can code for you, it's really important that you understand how it works and the overall structure. The cool thing is, you can use AI to explain code and concepts to you in a way that fits your experience level. You can also ask it for specifics it should focus on. It's usually a good idea to focus on why it's doing something and how it's doing it, not just what the code is doing. This helps you learn and makes you better at directing future projects.

4. Improve and Refine
With the current models, the first code the AI writes, no matter how good your prompt was, will probably have bugs or act in ways you didn't expect. This is where you keep making it better.

• Test Thoroughly
• Write Down What Needs Fixing: As you test, make a specific list of things you want to improve, fix, or change.
• Ask for Changes Smartly: Current AI models work best with two or three changes per prompt. If you give them a list of ten, they'll likely miss things.
• Let AI Suggest Solutions: If you're not sure how to fix a problem, ask the AI to suggest a solution. This can even be done for design decisions.
• Start New Chats for Big Features: For more complicated things, it's a good idea to start a new chat now and then. This stops the AI from getting confused or making up things because it loses track of the conversation.

Let's use this process for our double jump in UE5 that I mentioned earlier:

1. List Requirements: Write down exactly how the double jump should work: what buttons to press, what constraints it has, what parameters should be exposed, and so on.
2. Set Up: Make a new C++ class in UE5 and open it with your favorite AI-powered code editor (I like Cursor).
3. Ask for a Plan: Tell the AI your requirements and goals, and ask for a plan to build it. (For something simple like this, you probably don't need to ask extra questions or do more research.)
4. Review the Plan: Carefully check the AI's plan to make sure it's good and will do what you want.
5. Get the Code: Tell the AI to write the code into your C++ class. It usually explains how it works afterward, but if not, ask it to. At this point, understanding the code is super important, so you know how to use it and can check it for bloat or overengineering which can harm your game and make the code harder to understand for other people.
6. Test and Tweak: Compile the code and test the double jump in UE5. If it works, great! If not, or if you want to change things you can't tweak directly, make a list of changes and ask the AI to improve the code. Keep doing this until you're happy.
7. Finish Up: For more complex features, this is when you'd clean up the code, write documentation, and so on.

It's pretty interesting how AI + C++ has mostly taken the place of Blueprints in my quick prototyping, even though Blueprints are supposed to be for designers to build things fast. I find that AI + C++ is not just quicker, but it also gives me a lot more freedom in what I want to do and actually makes my game run better. It's a win-win.

One important thing: If you're mixing C++ and Blueprints, decide early on what goes where. If you don't make this clear, the AI will put everything in C++, and it can be a real headache to untangle things you wanted in Blueprints later.

I'm still actively learning C++ using learncpp.com, which I've found incredibly helpful and would recommend to you too. Like I said, understanding the code and knowing the language you're writing in is essential for really getting good at prototyping with AI.

My process will definitely change as AI tech gets better and I learn more about game development. But I think this approach is a solid starting point for anyone who wants to be more effective and get more prototypes done.

I really enjoy physical games like sliding puzzles, but I wanted to create something that could bring multiple players together around this classic mechanic. That's how Slide & Solve was born. It's a competitive sliding puzzle game where players race to recreate patterns as quickly as possible.

The Core Design Challenge:
Traditional sliding puzzles are solitary experiences that can feel boring rather than fun. My goal was to transform this into something social and exciting. The key was shifting the focus from solving a complex image to quickly matching simple, colorful patterns. This made the game accessible to players of all ages while maintaining the satisfying puzzle-solving experience.

Game Components and Mechanics:
Each player gets a 3x3 sliding puzzle with 8 colored tiles. The magic happens with the pattern cards, a deck featuring various arrangements that players must recreate. I designed two types of cards: white template cards for standard play, and black event cards that introduce unique twists like "Mirror Mode" or "One Hand Only."
The core loop is simple: draw a card, everyone starts at the same time, and race to match the pattern. The first player to finish places their puzzle in the center of the table. If it's correct, they earn a point. You need three points to win the game. But if you place an incorrect solution, you lose a life. Lose all three lives and you're eliminated.

Event Cards - Adding Variety:
The event cards were necessary for keeping the game fresh. Each one changes the rules in a meaningful way, from physical constraints like using only one hand, to perceptual challenges like matching a mirrored pattern or only matching a certain color. These cards prevent the game from becoming a pure speed contest and give different types of players moments to shine.

Player Feedback and Iteration:
I've only tested this game with my family so far, but it was a lot of fun. It turned out to be surprisingly tense during the rounds, with everyone sneaking glances at each other's puzzles to see who was ahead or how someone was solving a particular template. I also realized that sliding puzzles can be pretty challenging, especially for kids, but I noticed everyone getting better as the game went on. It's definitely something you improve at with practice. I'll need to test it with more people to see how well it holds up.

Slide & Solve was a fun little challenge. Taking a familiar concept and finding new ways to make it social, fun, and endlessly replayable is something I really enjoy. Having a 3D-printer allows for some quick experiments like this, and I'll definitely be using it more in the future.

I just wanted to share a quick update on our Master's project at the university. Our artists are hard at work creating concept art and developing the game's art style. While I can't show anything just yet, the project will eventually have its own section under the University Project tab, where you'll be able to take a detailed look once everything is finished.

The game also has a name now: They Sent Us Both. Here's a quick recap of the logline: They Sent Us Both is a 2-player co-op game where you travel to a distant planet to save its inhabitants from extinction while building up and managing a small, evolving settlement that depends on your collaboration, strategy, and empathy to survive.

Right now, I'm working on setting up the inhabitants. I'm still figuring out the code architecture, since this is my first time handling such a large-scale project. I'm focused on keeping the codebase maintainable and well organized. I'm also thinking a lot about how to connect various features and how to give our designers the tools they need to tweak and balance the game effectively.

It's been really interesting not working as a game designer for once, but instead being on the other side of things as a programmer. Not only is programming in C++ a lot of fun, but it has also given me new insights into the relationship between designers and programmers. There are many things that seemed simple to me as a designer, but I now realize how time-consuming and complex they can be to implement. This experience is helping me better understand the technical impact of design decisions, and I think these are lessons I'll carry with me in my future work as a game designer.

My previous post on this blog got me pondering more about how to study games effectively. I was especially thinking about live-service games, when I remembered a quote from Richard Carrillo's book, The Role Of A Great Game Designer (2021): "For game designers, spending one hundred plus hours on the same game should not be seen as a badge of honor; instead, it represents missed opportunities." (P. 187). This means that Carrillo suggests you should play a bunch of different games to broaden your horizons instead of spending a lot of time on one game. But that immediately makes me wonder: how do we then understand live-service systems, where the whole point is for gameplay to be exciting for hundreds, or even thousands, of hours?

If you read my last post, you'll remember I suggested that playing isn't the only way to study games. You can also watch playthroughs, reviews, and livestreams. And while this works for many aspects of games, I realized that something that's very hard to understand by watching or reading is long-term engagement. What actually compels players to spend hundreds of hours on a single game? Especially now, when live-service games are among the most successful titles out there, I think it's crucial to deeply understand what truly drives and motivates players to commit their time to one game.

Now, Carrillo's point about playing lots of different games is certainly valid. I agree that you should broaden your horizon. However, if you want to design for live-service (which, again, lots of games these days are), then, in my opinion, you should have experienced what makes the live-service loop tick. You need to understand what motivates you to keep coming back, to develop a deep understanding of the retention systems, and to really grasp what truly matters to players over the long haul.

To illustrate this point, let's look at my own experience. As I really enjoy shooters, my most played live-service game is Destiny 2. While I haven't played it in over a year, I've sunk many hours into it during the pandemic and I honestly believe I could have read a dozen books on the subject and not gained the same wholistic view and depth of knowledge on what makes a live-service game work. I got to see not only what motivated me, but also what motivated my friends, their perspectives on why they kept coming back, and what made Destiny 2 stand out to us as our preferred live-service shooter.

I'm definitely not saying you need to invest thousands of hours in a single game to learn this. Instead, I'm suggesting you should commit yourself to a game for an extended period to truly understand what motivates you and what keeps you returning. This commitment looks different for everyone: some prefer MMORPGs like World of Warcraft, others gacha games like Genshin Impact, and some looter shooters like Destiny 2 or MOBAs like League of Legends. I genuinely believe that having played at least one of these games with the intent to study its long-term retention will significantly improve your understanding of live-service design and help you refine your own systems. The key is to approach these games with the intent to study them and to know when you've gained the insights you need so you can move on. That's very important to keep in mind. Don't just mindlessly play. Take notes and learn from other people's work. In the case of live-service design, I found this to be the most effective way to improve.

I want to take a bit of time to talk about watching vs playing games as a way to study them. Many game designers will tell you that you have to play a lot of games to become a proficient designer. While I agree with the idea behind this, that you need to experience a wide range of games to understand what works and what doesn't, I don't think it's always feasible, especially for someone like me.
As a student, my budget is very limited, and spending 60-70€ on a game every other week just isn't realistic. Game Pass mitigates this issue a bit but there are still a lot of games that are not on it. Another issue is that games are made up of many different systems and elements. While it's important to see how these systems interact, it's often more effective to focus on one specific thing you want to learn or analyze, rather than trying to absorb everything at once. For example, if you're playing God of War and you're interested in boss design, you'll need to get through hours of unrelated content before reaching those fights.

My solution is to watch games being played. I don't hear many people recommending this. It's usually "you have to play it yourself." But I don't entirely agree. In many cases, watching someone else play can be more effective for studying a game.
First, it solves the two problems I mentioned earlier. It costs nothing to go on YouTube or Twitch and watch a playthrough, and you can easily skip to the sections that interest you.

But the benefits don't stop there. Watching others play allows you to compare your opinions with those of other players. It's easy to dismiss a design as unsuited just because you think it doesn't fit, only to find that many others really enjoy it. Seeing reactions from Let's Players, Twitch chat, YouTube comments, or reviews helps you put your opinion into perspective.
Another benefit is seeing how different people engage with the same content. This goes beyond just checking opinions. It lets you observe how players handle tutorials, which parts they spend the most time on, where they get frustrated or excited. It allows you to study not only the game itself, but also the emotional responses it generates and how effectively it communicates its experience with different players.

Now, I'm not saying you shouldn't play games yourself. You absolutely should. There are certain aspects of game design, like controls and game feel, that you can only truly understand by playing. Feeling how a game responds, where it flows well or where it frustrates, is something watching alone can't fully replicate.
That said, you don't have to play every game that interests you. We have the internet at our fingertips, and I believe we should use the tools it offers to broaden our perspective and adapt to our individual situations. Watching others play can often be just as valuable, especially when you're looking to focus on specific mechanics, observe player reactions, or compare different playstyles. It's not about replacing firsthand experience entirely, but about studying smarter with the resources available to you.

PS: The reviews on this blog are called reviews, not studies, for a reason. When I review a game, I've played it and I'm giving my personal opinion. When I study a game, or a specific part of one, I often turn to online playthroughs, other people's reviews, articles, and more. I find this approach more effective for learning than playing the game myself, where I might get too immersed in the experience to analyze it objectively or don't have the time to play through it.

As part of my master's project, a game where you manage a small population on a planet, I've been looking at how other games handle similar setups. I was especially curious about what makes interactions with NPCs and groups of NPCs feel meaningful. Cult of the Lamb seemed like a perfect case study, so I spent some time digging into it.

What Stood Out:
One of the first things I noticed, and something I also mentioned in my LET IT DIE impressions, is how there's always something to do. Whether you're managing your cult, decorating your base, playing Knucklebones, or heading out to fight a boss, everything is connected. The systems all feed into each other in a way that feels purposeful. Nothing feels like filler.

I also really liked how the game lets you decide your own pace. If you want to focus on combat, you can. If you'd rather manage your cult or just relax and decorate, the game supports that too. That level of flexibility makes the experience feel tailored to the player, which is part of what gives it so much broad appeal.

What Didn't Quite Work:
There isn't much I'd point to as a major issue, but the roguelite aspect of the game felt underdeveloped. The four regions you explore may look different on the surface, but they start to feel pretty similar after a while. I understand that when a game spreads its attention across so many systems, not every part can go super deep. Still, I think the combat side could have used more variety. If it meant pulling back a bit on the base decoration content, which at times felt almost excessive, I think it would have been a worthwhile trade.

Since combat is something you spend a lot of time doing, it stands out more when it starts to feel repetitive.

A Few Standout Moments:
Most of my favorite moments came from the cult members. There was always something happening: quirky quests, spontaneous events, unexpected drama. Some of the interactions were genuinely funny, and they helped make the cult feel alive.

The final boss fight also stood out. After getting used to a fairly predictable combat rhythm, it felt fresh and more dynamic. It was a strong ending that gave the whole journey a satisfying payoff.

What I Learned:
This game is a great example of how to keep players engaged across different playstyles. It blends a lot of mechanics in a way that feels seamless. But what I focused on most were the cult interactions. Watching how the game made me care about NPCs, how it used procedural elements and layered mechanics to deepen those relationships was really valuable. It showed me what it takes to make player-NPC dynamics feel personal, which is something I plan to apply directly to the Master's project.

Final Thoughts:
Overall, Cult of the Lamb is a smart, flexible game with a lot of charm. Whether you're into management sims, action games, or something in between, there's probably something here for you. Definitely worth checking out.

This game was inspired by an episode of the Think Like a Game Designer podcast featuring Reiner Knizia. Before this interview, I had never heard of so-called "auction games", and I was immediately intrigued. It sparked my creativity, and I sat down to brainstorm what my version of an auction game could look like.

The Blind Auction is an auction-style game where three players bid on concealed objects of varying values over 10 rounds. The player with the most wealth at the end of the game wins.

Game Components:
Every player starts with 21 bills of different values that add up to a total of 6,800. The funds of each player are visible to everyone. There are 10 objects that players can bid on: 3 high-value objects worth 1,000 each (yellow), 3 medium-value objects worth 500 each (purple), and 4 low-value objects worth 250 each (blue). The game also includes extra 200-value bills that players receive each round starting from round 2.

How It Works:
Each round, one player selects a face-down object to auction. Bidding proceeds clockwise, with players either placing a bid or passing. The auction ends when all but one player have passed. The highest bidder wins the object, surrenders their bid to the void, and the object's value is revealed and added to their wealth.

The core tension comes from risk assessment - do you bid high on an object that might be worthless, or do you let it go and potentially miss out on a valuable prize? Players must balance aggressive bidding with resource management across all 10 rounds.

I created this prototype using parts from an old Monopoly game and some custom 3D-printed pieces. When I playtested it with friends and family, some fascinating dynamics emerged. Players naturally gravitated toward different strategies: some played it safe, bidding low at the start and saving for the later rounds, while others took big risks, spending heavily in the first round. What's interesting is that both styles can work, depending on a mix of luck and how well players plan and read each other. As the rounds progress, the tension builds. Not just from the stakes themselves, but from watching those strategies unfold and collide.

This little design exercise taught me a lot about creating meaningful choices with limited information, and how uncertainty can drive player engagement. While I don't have immediate plans to publish this, it was a valuable exploration of auction mechanics and player psychology.

This week marks my final week as a Game Designer at Edurino as I've made the decision to shift my focus fully back to my studies. While I've absolutely loved my time there and would have ideally juggled both, it's become clear that I need to dedicate my full energy to finishing my degree right now.

Working at Edurino, and creating games that genuinely have a positive impact on our next generation, has been incredibly rewarding. I've had a fantastic time working alongside such a talented and supportive team, and I've learned an immense amount from them and my Design Lead. I've also made some truly great friends there that I'll definitely keep in touch with.

I'll miss the team and the unique atmosphere at Edurino, but I'm also really looking forward to the road ahead.

We have, for the most part, decided together what kind of game we want to make. To sum it up, we want to make a game where two players with asymmetrical roles arrive at a distant planet to help the inhabitants survive a major catastrophe which is endangering their lives. We have outlined the rough core pillars that are important to us and on which the rest of the design will depend:

2-Player Co-op Dynamic:
Both players have different roles but are dependent on each other to manage resources, progress, and win. Selfish playstyles lead to consequences.

Democracy System:
The planet's inhabitants should play a central role. Players have an effect on the inhabitants, and the inhabitants have an effect on the players.

Accessible for Casual Co-op Gamers of All Ages:
The game should be accessible to everyone interested in video games and should match the average gamer in terms of both difficulty and hardware requirements.

Learning Effect:
The central game systems, such as democracy and resource management, should show players what an ideal interaction with a planet's population can look like and what consequences negligence or selfishness entail.

In preparation for this, I have set up a couple of C++ classes that will allow us to create procedurally generated planets and place buildings on a grid on that planet. This took me like 5 days to get up and running, but I learned a lot about Goldberg polyhedral and basic procedural generation.

Marathon has been teased and rumored about for a while now, but today we finally got official gameplay trailers and hands-on impressions. Right off the bat, I have to say that I'm very excited for this game. I think the visual style and gunplay are exactly what I like, and the PvPvE aspect looks promising. I must admit, I've never played an extraction shooter, since to me they look like games you have to invest a ton of time into to get even remotely good, but I'm more than willing to give this one a try. From what I've seen, Marathon is trying to make the extraction shooter genre more approachable and add the Bungie DNA into the mix. So, as a former D2 veteran, I would consider myself the prime target audience for this game.

But of course, it's not all sunshine and roses. I've heard some of the bounties can get pretty boring and repetitive, and that encounters with other players are a bit too rare. But most importantly, players report that the game is just not that engaging. It's missing that tight and fun core loop which is at the heart of every good game. I guess we'll have to see how the Alpha goes.

Like I said, I'm really excited for this and definitely willing to give it a shot, even if it's a premium game. That said, I can only really share an opinion once I've actually played it, so I'll post my thoughts after the game launches and I've had some time with it.

With the Lies of P: Overture DLC just around the corner, I finally sat down to play the base game and see what it had to offer. I wrapped up my playthrough in about 25 hours, and overall, I came away with a really positive impression.

What Stood Out:
The combat is solid and surprisingly approachable, even for players without much experience in Souls-like games. The difficulty feels fair, and I really appreciated the addition of the Specter system. It's a smart way to offer a bit of help without compromising the challenge.

The prosthetic arm was another standout. It gave me the edge I needed during some of the tougher boss fights like the Walker of Illusions and the Nameless Puppet. But where the game truly shines is in its storytelling. Lies of P manages to tell a compelling, layered story without being cryptic or overly vague. Unlike many Souls-style games, I never felt like I needed to watch a 30-minute lore breakdown just to understand what was going on. The narrative stayed clear, engaging, and emotionally grounded throughout.

What Didn't Quite Work:
Even though the difficulty felt fair overall, it's possible to become a bit overpowered early on. That made many of the early and mid-game bosses feel underwhelming. The balance tips back in the game's favor later on, but by then, a different issue shows up: regular enemies in the final areas become so tanky that fighting them starts to feel more like a chore than a challenge. I often found myself running past them just to get to the next boss, which is where the game really comes back to life.

Some of this seems tied to how the scaling was handled. Compared to something like Dark Souls, where the power curve and enemy design feel tightly tuned, Lies of P doesn't quite hit that same level of polish in the second half.

The weapon crafting system was another area that didn't quite land for me. It works fine, but it didn't feel especially meaningful. I ended up sticking with basic upgrades rather than experimenting, and the build variety felt more limited than I was hoping for.

And one last thing: when I repeatedly refused to let Alidoro come to the hotel, only for him to show up there anyway, it broke some of the trust I had in the game's choices. If my decision doesn't actually matter, it probably shouldn't be presented as a meaningful choice at all.

A Few Standout Moments:
Both the Walker of Illusions and the Nameless Puppet were excellent boss fights. They pushed me to really understand the mechanics and felt like proper skill checks. I also really enjoyed how the story unfolded. There were some genuinely surprising and emotional moments, especially toward the end, that stuck with me after I finished.

What I Learned:
This game taught me a lot about designing difficulty that's accessible without being watered down. The Specter system is a great example of this, offering optional help without removing the sense of accomplishment. It also showed me that clear storytelling doesn't have to come at the expense of mystery. Lies of P finds a good balance between guiding the player and letting them discover things for themselves. That's something I'd love to apply to my own designs.

Final Thoughts:
Despite a few missteps, I thoroughly enjoyed Lies of P. It's one of the more welcoming entries in the Souls-like genre, and I'd happily recommend it to anyone curious about trying these kinds of games. Whether you're new to the genre or already a fan, there's a lot here to appreciate. I'm definitely looking forward to what the Overture DLC brings.

Today, I finally caught up on all the episodes of the podcast "Think Like a Game Designer" by Justin Gary. I ended up taking over 100 pages of notes from interviews with amazing designers like Richard Garfield, Eric Lang, Ben Brode, Alex Seropian, and many others. They offered invaluable advice and insights for anyone looking to get into game design or the games industry. I learned so much from every episode and can highly recommend it to any game designer or creative. I'm really thankful to Justin Gary for conducting these interviews and hosting the podcast for free, which is incredibly generous and means a lot to the community.

Last semester I finished my Bachelor's degree in Interactive Media at the University of Applied Sciences Augsburg and this semester I'm continuing my specialization in game development with the Master's program Interactive Media Systems, which is a direct follow-up on my Bachelor's program. The core of this is a two-semester Master's Project where we will develop a game in a team of 9 people, with each team member choosing their specialization. In my case, this is game design and programming. I'm not seeking to primarily be a programmer, but I think it's a really good opportunity for me to hone my skills in programming in UE5 and getting to grips with C++. I think this is important for creating prototypes and having a deeper understanding of what's going on under the hood. I will be looking into things like optimization, maintainability, code structure, and much more. I will share some progress and highlights over the coming year.

Here are 60 seconds of gameplay from the prototype I showed in a previous post. As you can see, it's Five Nights at Freddy's meets On Observation Duty. The game is all about paying close attention to your surroundings while managing your blink and flashlight resources.

From the start, the player's vision becomes blurry over 15 seconds. If the player does not blink within that time, they die. This means blinking is essential for survival, but each blink gives the puppets around the room a chance to move closer. If they get too close, the player dies. However, the player has a flashlight to defend themselves. With every blink, the player has three uses of the flashlight before it runs out and is recharged with the next blink. Flashing an enemy sets that enemy back to its original position. The puppets can approach from many different angles and many puppets can be active at once, so keeping them in check is crucial.

I'm continuing to work on this game and here are a few features I still want to add:

1. A second enemy type called the Stalker, which will come through the vents at the back of the room.
2. The option to pan the camera left and right to increase the angles from which the puppets can come.
3. Different poses depending on where a puppet currently is (for example, clinging to a table leg, standing, or crawling).

I also shared this with some fellow students at the university, and one of them expressed interest in creating art for the game. I'll need to finish the implementation and test it several times before accepting that offer, though. But if it works out, we can probably put the game on itch.io for everyone to play.

I just finished another book on game design, or more specifically, on what goes into being a great game designer. It was considerably shorter and less in-depth than Tynan Sylvester's Designing Games, yet it still provided incredibly valuable insights. I have applied the idea of inspiring the team rather than simply explaining the design to my work as a working student in game design at Edurino, and it has made a big difference. When the team is inspired, great ideas and the will to put them into action come from every team member. Particularly in the art department, the artists I work with often have fantastic suggestions for the visuals of each mini-game. By allowing them to take ownership while still ensuring their ideas fit the overall goal we set, they create something amazing every time.

Another important takeaway is the question "What problem are you trying to solve?" This helped me a lot when random feature requests came in or when I caught myself adding something to a game just because I thought it might be fun. It is one of the most important questions to ask yourself when examining a new idea, even if it may not always make sense during the brainstorming phase for a new experience.

Overall, a great book. I am currently reading Justin Gary's Think Like a Game Designer and will share some of the insights that stood out to me once I finish that as well.

I'm currently working on a game called "Blink". At its core, it's a horror-survival experience but with a twist that plays directly on something we all do without thinking: blinking.

In the game, blinking is your main resource. You have to manage it like you would health or stamina in other games. The idea is simple, but it creates an unsettling tension. Every time you blink, there's a risk. Enemies move, the environment might shift, and you're briefly blind. But if you try to keep your eyes open for too long, hallucinations creep in. Your vision distorts. And if you push it too far, it can kill you.

So you're constantly walking a line: blink too often and you speed up the danger. Blink too little and your mind turns against you. The challenge is in learning to observe, read the environment, and time your reactions under pressure. You're also armed with a flashlight which you'll use to hold enemies at bay or to check vents and corners for signs of movement.

It's still early in development, but I'm excited about where it's headed. Once the enemy AI is fully implemented, I'll be sharing another update. For now, I just wanted to give a glimpse into what I've been building.

Over the past week, I gave myself a little challenge: build three different LEGO car MOCs, on three separate days, each in under an hour. No limits on what parts I could use from my collection, but once the clock hit 60 minutes, I had to stop. No tweaking, no finishing touches.

This wasn't my first time setting up a build like this. A while back, I did something similar with a mini LEGO Tumbler, where the challenge was all about using parts deliberately. But this time, the focus was different. Instead of slowing down and being deliberate, I wanted to push myself to work fast, make decisions on the fly, and see what would happen when I didn't have time to overthink everything.

Turns out, I still managed to overthink everything.

One thing that became very clear, especially under time pressure, is that my approach to the base structure of a car is kind of a mess. I use way more pieces than I need, and I often jump into adding details before the foundation is even solid. For example, with the orange car, I look at it now and honestly have no idea what I was going for with the back tire covers. They don't look functional or intentional. Then there's the black car on the top. That one's basically a solid brick. Most of the inside is just filled in for no good reason, which made shaping the outside a real pain and wasted a lot of time on unnecessary blocks.

What I've learned is that I need to start each build by quickly sketching out the shape in my head, or maybe even with just a few core pieces, before diving into the details. Without a clear plan, it's way too easy to box yourself into a bad structure that's hard to fix later, especially when you're racing the clock.

Even though I'm not totally happy with how any of the cars turned out, I still consider this a win. I had fun, I learned a lot, and I caught myself in the act of doing things I didn't realize were holding me back. Challenges like this, where you're working under constraints and reflecting on the process, always seem to push you further than just casually building whatever comes to mind. And for me, that's where the real growth happens.

Since I was just writing about drawing practice in my previous post, I want to share two more tips. I'm not a pro artist or anything, but these helped me improve more quickly. The first is tracing basic shapes like squares, circles, and triangles to get a feel for how to draw them, especially circles. You can use the circle tool in Krita to place perfect circles on the screen, then trace over them and try to stay as close to the original as possible. After that, try drawing some without tracing.

The next tip is a bit more personal. Since I have a 3D printer, I printed a few "Dummy 13" figures, which you can pose however you like. This helped me with gesture drawing and improving my flow when drawing humans or human-like creatures like robots. If you don't have a 3D printer, you can just buy one of those drawing mannequins and it will work just fine. But with Dummy 13, you can print your own accessories and customize it however you want.

For me, the best way to improve my fundamentals in drawing, like line and shape practice, is through graffiti. I study alphabets and pieces from famous artists, trying to learn from each one by incorporating certain elements into my own work. Graffiti is great for practicing clean lines of different lengths and really tests your understanding of shapes. I used to do graffiti on actual walls, but since a can of spray paint now costs around 6-7€, and you go through them pretty quickly, it has become too expensive for me. Still, I enjoy doing digital graffiti or just grabbing a marker and sketching in my sketchbook.

I recently finished reading Designing Games by Tynan Sylvester, and I found it to be an excellent resource for anyone interested in game design. The book offers a wealth of valuable insights into the collaborative process of creating games, as well as a deep dive into the elements that contribute to a great design. Additionally, it provides clear definitions of many key terms, helping me better put abstract concepts into words. I wholeheartedly recommend it to anyone looking to break into the field of game design or to elevate their existing skills to the next level.

Ah yes, another month, another evolution in the world of AI. I've been experimenting with Claude 3.7 since it was released, and I have to say, I'm genuinely impressed. I was expecting improvements over earlier models like DeepSeek R1 and OpenAI o1, but Claude 3.7 really brings us closer than ever to having a coding assistant that's actually useful.

It handles a wide range of problems I throw at it with ease and is especially good at tackling smaller tasks, like writing specific functions exactly how I want them. It can even generate fully functional programs and apps, often in just one try, though that's less reliable than when it sticks to smaller tasks.

If you're looking for an AI coding assistant, you should definitely give Claude 3.7 a try.

I'm continually working on improving both my concept art and pixel art skills. Lately, I've been creating character 360-degree spritesheets to get a better feel for proportions and perspective. I'm also storing these assets, as they might come in handy for future game prototypes.

I played Steins;Gate over the course of this week. I don't usually play visual novels, but I wanted to revisit this franchise since I watched the anime almost ten years ago. I didn't remember much going in, partly because of how much time has passed, but also because I was probably too young back then to fully grasp what Steins;Gate was doing. Recently, a fellow university student made a visual novel for their bachelor's project, and that pulled me back into the genre. I'm really glad it did.

What Stood Out:
This game absolutely deserves its reputation. The storytelling is some of the best I've come across. It's carefully layered, emotionally complex, and genuinely immersive. I felt like I was living Okarin's life and sharing in the Future Gadget Lab's discoveries. The characters are deeply written, and the time travel mechanics are handled with a kind of intelligence that makes the story feel strangely believable, even as things spiral into chaos.

What Didn't Quite Work:
The pacing, especially early on, was a bit of a struggle. Other visual novels like Doki Doki Literature Club manage the early slow burn more smoothly in my opinion.

I also found the email and D-Mail mechanics pretty unclear. The game doesn't make it obvious that your replies actually affect the story's outcome. I assumed they were just flavor text, not meaningful choices. Because of that, I ended up with Suzuha's ending first without realizing I had the ability to steer the narrative. From what I've seen, this is a common point of confusion. In a shorter game, this wouldn't have bothered me much. But with a runtime around 25 hours, replaying everything just to reach another ending felt like a big ask.

A Few Standout Moments:
There are points in Steins;Gate where the weight of time travel really hits. Okarin's breakdown during his time loop in Suzuha's path, for example. I also watched the true ending after my playthrough, and it's excellent. It ties everything back together, makes sense, and provides a satisfying and emotional resolution to a story built around suffering and sacrifice.

What I Learned:
Steins;Gate reminded me how powerful slow-burn storytelling can be. Even with the pacing issues, it's the characters that really carry the experience, even more than the plot. They're what keep you emotionally grounded through all the twists and time loops. It also made me think more critically about how important it is for games to clearly communicate their mechanics. When players don't understand the weight of their choices, it weakens the impact of a branching narrative. That's especially true for a long-form story like this one. If it were five hours long, replaying for a better outcome would feel exciting. But at 25 hours, it becomes a commitment.

Final Thoughts:
I love this game despite its flaws, and I'd recommend it to anyone who values great storytelling. Even if visual novels aren't typically your thing, this one is worth the time. The emotional payoff and narrative depth are something special.
El Psy Congroo.

This was a fun little code experiment. I downloaded a program called LM Studio, which lets you download and run different LLMs locally and host a local server that can be accessed via API. I used it to create my own Visual Studio Code extension as a challenge since I always wanted to know what goes into making an extension like that.

I'm currently using a 14B distilled version of Deepseek R1 since my hardware doesn't support higher-quality versions. The extension is still in its infancy, but I want to experiment and see what I can do with it. I'll probably continue development whenever I have time to work on it.

There's a project called Ludus AI that aims to help developers create content in Unreal Engine 5. I downloaded the plugin and experimented a bit, but I couldn't get it to work. It seemed like the servers were down at the time or there were some issues with the API. If you want to see what it can do, I found a video on it that you can watch above. I highly recommend checking out the video since it's not just about Ludus AI but also explores what a game entirely made by AI looks like. Really interesting. I'll be keeping my eye on this plugin and try it out again another time.

I picked up my first 3D printer from Bambu Lab a while ago and have mostly been printing practical things like boxes, clips, and stands. But recently, I got a lot more interested in printing miniatures and figurines. I subscribed to a group of artists on Patreon called Bulkamancer and printed one of their many awesome figurines.

After tweaking the settings, printing, and assembling all the parts, I painted the figurine with simple acrylic paints and quickly realized I have a loooong way to go when it comes to painting miniatures. Still, it's a really fun hobby, and I plan on printing and painting a lot more to decorate my otherwise pretty barren room.

I picked up Mortal Kombat 11 recently and ended up playing through the entire campaign in one sitting. The only other game in the series I had played was Mortal Kombat X, and even then, it was just casual matches with friends. I never touched the story mode, so I went into MK11 knowing almost nothing about the lore. Even so, I found myself fully hooked.

What Stood Out:
The campaign felt like stepping into an interactive action movie, in the best way. Cutscenes and fights flowed into each other with surprising rhythm, keeping the pacing tight for most of the experience. The characters and dialogue had that classic action-movie energy. Quite over-the-top but completely aware of what they are, and it just worked.

Combat feels incredible. Every hit has weight, and the animations are as brutal as you'd expect. But what really impressed me was the sound design. The audio team deserves serious credit for making each punch, kick, and slam feel physical.

What Didn't Quite Land:
I'm not a fighting game expert, so I won't pretend to analyze the competitive aspect of the game. But as someone who plays these games from time to time, there wasn't much I didn't enjoy. The only real downside was that a few cutscenes ran longer than they needed to. There were moments where I caught myself thinking, "Let me play already." But overall, the balance between watching and playing was solid.

A Few Standout Moments:
The opening cinematic grabbed me right away with its production quality. It felt like a clear signal that this game was going all-in on spectacle. Some of the fatalities were genuinely impressive, not just in their shock value but in how creatively they were executed. And the final boss fight delivered exactly what I hoped for. It felt like a proper, earned climax.

What I learned:
MK11 showed me how powerful it is when a game fully embraces what it is. It doesn't try to tone itself down or appeal to everyone. Instead, it commits to being a loud, stylish, violent spectacle, and that confidence makes it work. It also reminded me just how important sound is to the feel of combat. It's not just visuals that sell a punch, good audio can make a hit feel real.

Final Thoughts:
All in all, Mortal Kombat 11 is a great example of a game that knows exactly what it wants to be and delivers on that vision. Whether you're deep into the franchise or coming in fresh like I did, there's a lot here to enjoy.

Since what I discovered in my last post left me with a lot of questions about how something like Google Genie 2 actually works, I wanted to dig deeper into how generative AI does what it does. In the process, I came across a website called paperswithcode.com. It features a lot of recent research and scientific papers on machine learning, AI, and related topics. I browsed through some of them, and there's some really fascinating stuff in there. If you're into the latest developments in AI and machine learning, it's definitely worth checking out.

While doing some more research on how AI can be used to create games, I came across a video demonstrating how Google Genie 2 can generate interactive experiences on the fly. Since interactive media is my field of study, I was genuinely blown away by what I saw. I honestly can't even begin to wrap my head around how something like this is possible. I have a few personal theories about how it works, but still, I've never seen anything quite like it.

Of course, it's still a bit weird and rough around the edges, and there are definitely limitations. But the fact that this level of dynamic generation is already achievable is pretty mind-blowing. Considering the leap from Genie 1 to Genie 2 happened in about a year, I'm really curious to see how far it'll go in the next year.

DeepSeek just dropped their new R1 model with API access, and that means it now works with the Cline extension for VSCode. If you've been keeping an eye on coding assistants, this is a pretty big deal. It opens the door to using R1 as a powerful dev tool without paying $200 a month for OpenAI's o1. I'm still testing it out and refining how it fits into my workflow, but so far, it definitely feels like a real step up from ChatGPT.

Lately, it seems like every month brings some kind of leap forward in AI. It's exciting, but also a bit surreal. You start to wonder where the ceiling is, or if there even is one. What's really struck me, though, is how these tools are changing what individuals can do on their own. Things that used to require a team of specialists are now within reach for solo devs or small teams.

But with that power comes some questions we each have to wrestle with. What parts of your work do you want to hand over to AI? What parts do you want to hold onto? For example, if you're a 3D artist, having a fast, affordable tool that can handle your game's logic sounds great on paper. And in the near future, that might be totally viable. But there's a tradeoff. If you don't understand the code, you're putting a lot of trust in something you don't have full control over. When something breaks and the AI fails to fix it or do what you want, you're essentially stuck and forced to reach out to someone eventually.

That's why I keep coming back to the idea of AI as a tool, not a replacement. A tool is only as good as the person using it. If you have some coding knowledge, or you're collaborating with someone who does, then you can catch mistakes, adjust things, and make smarter use of what the AI gives you. That kind of partnership is where I think AI really shines.

So yeah, I'm going to keep watching this space and using AI where it makes sense for me. I don't see the point in being all-in or all-out. These tools are here, and they're not going anywhere. The real question is how we choose to use them and whether we do so with proper intention.

Here's another custom LEGO car I built. As you might have noticed by now, I'm really into LEGO cars. I own a few Speed Champions sets, and they've definitely inspired me to start designing my own models. This time, I went for a cyberpunk-style vehicle with a black and red color scheme. It's a hybrid air/ground craft with extendable wings that double as laser cannon mounts. It also seats one minifigure in the "cockpit" area.

When it comes to reference, I usually just search around on Google for cool photos or renders that match the vibe I'm going for. I gather everything in PureRef and keep that board open while I build. Just like with drawing, having solid reference material on hand really helps when you're building MOCs. It makes a noticeable difference, and I always end up learning something new about design or form along the way.

This particular MOC took me about one evening to put together. If you're into LEGO Star Wars, maybe you can guess which set the windscreen came from. ;)

I wanted to explore a game engine called Phaser to see if it's something I'd use for some of my projects. So, I decided to make a small rhythm game called Witch's Groove, where you pop bubbles in sync with the song. Took about two days to make, including the music, sprites, code and level maps. It was interesting learning how to handle input delays and use .json files as level maps, but while Phaser is definitely a great framework for getting these sort of games up and running quickly, I still prefer Godot for creating my web games because you're not just looking at code all the time.

I created a Lua script for Aseprite that lets you preview an animation from a spritesheet. Simply select all the sprites you want to include and run the script. It opens a new file where you can play and adjust the animation without having to stack a lot of frames in your main file. You can download it below!

I started playing LET IT DIE today, and five hours disappeared before I even noticed. That kind of time slip always tells me something's worth paying attention to, so I figured I'd share a few thoughts.

What Stood Out:
Right away, the game-within-a-game setup pulled me in. There's this layered world where you're not just playing the game, you're playing a game within the game. It creates this clever narrative tension between the "real" world in the arcade and what's happening in the tower itself. That dual perspective adds depth without feeling forced. It's a smart design choice that makes everything feel more alive and immediately gets the player asking questions.

Gameplay-wise, it hits a nice rhythm. There's real challenge here, but not in a punishing way. You can return to your safe room often and restock before heading back out. Progression feels meaningful, and from what I've seen so far, there's a huge amount of content to chew through, even if you never spend any money.

What Didn't Quite Click:
That said, starting out can be a bit rough. There are a lot of overlapping systems, and the game isn't always great at easing you into them. It throws a lot at you, and more than once I found myself slogging through long text blocks just to grasp the basics. I don't mind text in a tutorial, but sometimes it felt like I was flipping through a manual half the time instead of just playing.

A Few Standout Moments:
Taking down the first major boss and finally making it to the surface felt huge. It was one of those moments where I actually sat back and smiled. There's also this unmistakable Japanese charm running through the whole game. I can't quite define it, but it's something about the style, the unpredictability, the energy that makes the game feel fresh, even when the mechanics aren't entirely new. I'd love to dig into what exactly gives a lot of these Japanese games that feeling.

What I learned:
I'm starting to see how powerful meta-narrative can be when it's used thoughtfully. Breaking the fourth wall isn't just a gimmick here, it actually pulls you deeper into the experience. And from a design perspective, I'm realizing how layered progression systems can keep players engaged in a way that feels both intentional and earned. When every step forward unlocks something new, it gives you a real sense of momentum. I also spent some time thinking about how I'd redesign the tutorials, because honestly, you tend to learn more from games when things go wrong than when everything runs smoothly.

Final Thoughts:
I'm still early on, but there's a lot here. Maybe too much, honestly. It's a bit overwhelming, but in that "I could lose myself in this" kind of way. If you're looking for a game that's strange, bold, and packed with personality, this one's worth trying. Just be ready to take your time with it. Like I said at the start, five hours flew by like nothing, and that's usually a good sign.

Here's a Mini-Tumbler MOC I put together using some spare parts left over from another build. It took me about two hours to complete. This version of the Batmobile is definitely my favorite, so I tried to stay as close to the original design as possible.

I really enjoy miniature builds like this because they push you to get creative. With limited space and fewer parts, every piece has to be used deliberately. You can't just rely on volume or size to solve problems.

Larger builds, on the other hand, often span multiple days and require a lot more planning. They're satisfying in a different way, since you have more freedom to experiment and solve design challenges by throwing more pieces at the problem. But there's something uniquely rewarding about working within tight limitations and still ending up with something that looks and feels right.

Happy New Year!!! As part of my 2024 reflection, I realized how nice it would be to have my own blog. I've been working on plenty of projects that don't make it onto the front pages of my portfolio, but I still want to share them. I used to rely on platforms like X for this sort of thing, but the character limit is frustrating, and without being verified, it feels like no one sees your posts anyway. So, I wanted to create a space where I can write as much as I want, adjust posts to my needs, and share everything with you, including non-game-related stuff. My goal is to post updates every 5-7 days. Hope you enjoy!