Milestones are clearly defined deliverables or outcomes as part of a project. A “project” can be anything - for example, a custom AI system, a gameplay feature, or a technical tool. This “project” will then be split into multiple milestones, each representing a concrete step toward completion.

I take full responsibility for each milestone’s implementation, including planning, coding, and testing, so you don’t need to provide technical direction – the work is fully handled on my end.

Each milestone has a fixed scope and a fixed price. While a milestone is typically equivalent to roughly one focused development day (8 hours), it is not billed as a daily rate and not tied to a calendar schedule. This is backed by a formal work contract (Werkvertrag), so the price is tied to the deliverable, not the hours worked. Milestones are scheduled flexibly based on scope, availability, and project needs. Workshops operate the same way, with the schedule being flexible and not tied to consecutive days.

Once a milestone is agreed upon, the price stays the same – even if it ends up taking more time or effort than expected on my end.

For more information, see the Terms & Conditions for full contractual details.

It’s important to come prepared – but don’t worry, you don’t need a finished design document or a polished project plan. At minimum, it helps if you have a rough outline or notes about what you want to achieve. Think of it like homework: a starting point for our discussion.

Bring energy and an open mind, because I’m going to ask a lot of questions – and I mean a lot, down to the tiniest details. This ensures we’re on the same page and we know exactly what we want to create. The more prepared you are, the smoother the workshop will go and the more accurate the resulting project plan and pricing will be.

The workshop happens in writing, so every discussion and thought is documented. This ensures nothing is forgotten, provides a clear record for both of us, and makes it easier for me to review our conversation and plan the project accurately.

Remember: everything we discuss in the workshop directly impacts how I execute your project and how much it will cost. Taking a bit of time beforehand to think things through will save us both time and make the final outcome much stronger.

The license lets you use the work exclusively for one specific game project. That means only you get this license, no one else will be granted the same rights, and it covers the main game plus any DLCs, expansions, or updates tied to it. You’re free to modify and monetize the work within that project.

The license is perpetual (it doesn’t expire) and royalty-free, there are no renewals or ongoing payments required.

If you want to use the work in other projects, like sequels, ports, remasters, or new games, you’ll need to get a separate license and pay a reuse fee. This fee is 10% of the total you originally paid for the licensed work, reflecting that the new project will generate revenue and build upon the original work.

If you do want full rights to the work, that is also possible. In that case, the price would be 3× the base rate per milestone. For example, a single milestone would cost €1,770 instead of €590. If you start with a restricted license, you can upgrade later by paying only the difference between the restricted and full rights price.

This higher price reflects that transferring full rights removes my claim to any future revenue from the project, allowing you to freely monetize or extend it as you wish. It also prevents me from reusing general tools or solutions developed during the project, which are part of my business model and will impact efficiency and may impact revenue, since each project is complex and unique.

A restricted license is usually all you need because it’s exclusive to you and your project and only limited in scope. It’s also the more affordable option if your budget is tight. A full rights transfer would only be necessary, e.g., if you want to sell the work as an asset, sublicense it, or claim full ownership and use it however you like. If you don’t care about owning it outright, a restricted license is all you need.

Think of it a bit like leasing a car. You get to use it for your own trips (your project), and you can even use it to make money (commercial use). The only thing you can’t do is rent it out to others or sell it on to a dealership (that would be sublicensing or redistribution).

Full ownership, on the other hand, should be seen as an investment, not a necessity. Start with a restricted license to test and validate the work in your project. If it proves successful to the point where you can see the value of full ownership, upgrading to full rights allows you to invest in ownership with confidence only when it is truly worth it.

Beyond the voluntary warranty period I offer on top of the statutory 2-year warranty, I’ll be available at no extra charge for any questions or clarifications you have. I’m here to ensure everything works smoothly and that you feel confident using what I delivered. Support does not end when the project ends, and your project’s success matters to me.

The main reason is long-term reliability and support. I don’t own or control third-party tools, so I can’t guarantee they’ll stay compatible or supported throughout your project – especially by the time you launch your game. By minimizing their use, I help reduce technical debt, which is the potential future cost and extra work caused by choosing a quick, easy, or less robust solution now instead of a better, more sustainable approach, and avoid future headaches. It also means I can fully stand behind everything I build.

Another important factor is that most third-party tools and assets are designed for general use, not for the specific needs of your project. To support many different scenarios, they often include a large number of features you may never need. Those unused features still add complexity and can become a maintenance burden over time.

Engine updates and deprecated features can further complicate things. If a third-party tool relies on functionality that changes or is removed, you may be forced to update or replace it. Removing such tools is rarely trivial and can lead to cascading issues across your codebase. Even updating them can reintroduce features or behaviors you previously had to work around or remove.

By building focused, project-specific solutions, I keep systems lean, predictable, and easier to maintain over the long term.

For more detailed information on liability and third-party dependencies, you can review my Terms & Conditions.

Not by default. I avoid using experimental or beta features unless you specifically agree to it. Just like with third-party tools and dependencies, these features aren’t guaranteed to be stable, supported long-term, or even available in future engine versions.

If your project really needs something that’s experimental, I’ll discuss the risks with you first so you can make an informed decision. As always with such potentially risky elements, I elaborate further on this in my Terms & Conditions.

I process payments securely through Stripe and currently support:

• Credit & debit cards

• PayPal (EEA countries only)

• Digital wallets (Apple Pay, Google Pay, MobilePay)

• Klarna (available in most EEA countries)

• Alipay

• Link

• iDEAL

• Bancontact

• EPS

• TWINT

• Billie

• Bank transfer

Payments are generally always made upfront. In cases where budget or cash flow is limited, it is possible to split a milestone into two installments. A one-time 3% fee, based on that milestone’s total price, is added to the first installment for each milestone that is split.

I also accept PayPal, Klarna, and Billie, which allow you to pay in installments or defer payment.

There is no single “best” game engine. Each engine has its own strengths and trade-offs, so the right choice depends on what you want to build, your technical requirements, and your long-term goals.

For example, Unreal Engine is a strong choice for FPS or open world games because many complex systems are already built in. You don’t have to develop everything from scratch. Features like character and vehicle movement, physics, destruction, and multiplayer support are integrated.

Another benefit is that these systems are maintained by Epic itself, so you don’t have to rely on third-party solutions for core functionality. Epic also provides high-quality free resources, including example projects and assets, and their ongoing work on Fortnite helps drive continuous improvement of the engine.

Ultimately, the best engine depends on the specific needs of the project rather than a universal ranking.

Knowing only the buttons and quirks of a specific engine isn’t very useful on its own. A game engine is just a tool – like a hammer and nails, or like driving a car: even if you’ve never driven a sports car, your knowledge of driving still applies.

Many companies use proprietary engines – Source itself is Valve’s proprietary engine – so it’s common to work with engines you haven’t used before. At the end of the day, I am doing the same thing I do in Source with another engine: developing game mechanics and systems. I still do programming, I still do problem solving.

What truly matters is the ability to solve a problem regardless of the technology being used. That’s what separates a true professional from someone less experienced.

The main reason this matters is performance. Scripting languages usually come with a performance trade-off because they are designed to make development easier and more flexible. One example is Lua. It allows you to develop without worrying about the stricter rules and complexities of a language like C++. In Lua, errors are usually always handled gracefully – your code might fail to execute a function, but it usually won’t crash the game. Lua is also good for modding because it has a gentler learning curve.

C++, on the other hand, is popular because it’s fast and efficient, but mistakes can have serious consequences, like crashes. Scripting languages like Lua act as a bridge: they give flexibility and ease of use at the cost of some performance because they run on a virtual machine, which introduces delays compared to native C++ execution.

Another limitation of scripting languages is that you can only access functions that are exposed by the engine in C++, which is not always the case. For example, in Unreal Engine, Blueprints is a scripting language; the difference being that you script visually by connecting nodes. You can do a lot within it, but certain functionality must be exposed from C++ to Blueprints, and the way that’s done has to be efficient.

Imagine hiring a developer or a team of developers, and the existing code is a mess. Only one person understands it, and now they’re gone – or worse, they’re difficult to work with and deliberately withhold knowledge that would allow others to understand and maintain the code.

Suddenly, no one else can maintain or expand the project, and fixing the mess becomes very expensive and time-consuming; a stressful and unpredictable situation (for everyone involved) – because you end up paying again to fix something that was supposed to be done properly in the first place. In the worst-case scenario, you might even have to pause or cancel your project.

Messy or poorly structured code makes it difficult to predict how changes will affect the rest of the project. Adding new features or fixing bugs becomes risky because hidden dependencies and unexpected side effects can appear at any time. It quickly turns into a maze of the unknown.

This is why I focus on well-structured systems, clear documentation, and best practices from the start. Doing so saves time, reduces risk, and ensures your project can grow reliably over time, and saves money too. I’d like to compare it with building a house: if the foundation is bad, you might have to tear it down because you can’t patch it all.

Yes. This is something I’m happy to offer if you’re an indie developer looking for guidance, technical direction, or expert advice for you or your team.

The process is similar to a workshop. The only difference being that consultation is a service contract, since the focus is on guidance, planning, and expertise rather than development. However, I may also provide code examples as part of the consultation to help illustrate concepts or approaches. Any code examples or materials I provide as part of the consultation can be freely used in your project.

Consultation pricing:

• Single 1-Hour Session – €390

• Single 8-Hour Day – €690

• 40-Hour Week (5-Day Intensive) – €3,290

Consultation can be a more cost-effective solution if you want to implement the work yourself and are on a tight budget.

I primarily specialize in gameplay programming, which includes designing and implementing game mechanics and gameplay systems.

I only offer services in areas where I’m confident I can deliver high-quality results. For example, I typically do not work on engine programming for custom engines, graphics programming, or level design. The exception would be level work directly related to gameplay scripting, such as scripting systems or behaviours (for example, VScript in Team Fortress 2).

By focusing on what I do best, I’m able to provide reliable, high-quality work and ensure strong results for every project.