Shadow Gambit

Shadow Gambit: The Cursed Crew

Shadow Gambit: The Cursed Crew is the third game in the Stealth Strategy / RTT genre developed by Mimimi Games after the critically acclaimed Shadow Tactics: Blades of the Shogun and Desperados 3. It launched to overwhelmingly positive reviews on Steam and is also available on EGS, GOG, PS5, and Xbox Series.


My work on Shadow Gambit

I was part of the development team from the early stages of pre-alpha until release and held many responsibilities in the process. In general, my work centered on the following tasks:

  • Create and maintain a Global Progression & HUB system that allows designers to: build and iterate on the non-linear narrative structure of the game; generate dynamically loaded quests and additional content and allow for the revival of new Crewmates.
  • Rework the Camera infrastructure to allow for better and faster iteration cycles and iterate on different camera control modes in close collaboration with our Creative Director.
  • Improve the game’s performance by reducing CPU and GPU load to reach stable and satisfactory FPS on PS5, Xbox Series, and Steamdeck.
  • Work in close collaboration with Designers and Artists to create new gameplay systems or rework, refactor, and iterate on gameplay systems from previous games that required major changes.

For a more technical insight, I’m writing a few dev-centered posts on my work on Shadow Gambit:
links coming soon


Why Shadow Gambit: The Cursed Crew is a big deal for the genre

While it generally builds on top of the previous two titles, Shadow Gambit changes the formula by focusing on increasing the players’ freedom through some key new features:

  1. Multi-linear storytelling through the usage of a recurring HUB
  2. Crew and Spawn point selection for most missions
  3. Island-centric level design instead of traditional level-centric design

All of these elements combined drastically increase the replayability of the missions and result in what many praised to be “the best modern installation in this Genre”.

The release of the game also marks, in my opinion, the first real formula change of the commandos-like subgenre. Other games until now, including the previous Mimimi titles, kept the same overall structure and focused solely on improving/polishing the second-to-second gameplay. Contrarily Shadow Gambit is an attempt at real change to bring this niche genre into the modern world without sacrificing the genre’s identity.


For more on Shadow Gambit, check out the IGN review below or other reviews on opencritic.

All that Lies Below

All That Lies Below

All that lies below is a game about mining developed in Unity.

Specifically, it tries to play off the fantasy of being a gold digger at the beginning of the century. Of course, this means that the main activity is mining, but what else comes with this fantasy? Setting off searching for riches always meant sacrifice, it meant leaving something behind. We went for the most obvious trope: a family in need, because it is quick to understand and allows for great extrinsic motivation. The fantasy of being a gold digger seems about gold and fame, but in reality, the adventurous nature, the repetition and continuous failures and the responsibility and pressure to make something out of the situation, to not fail, are the stronger emotions. In these times of crisis and self-isolation, playing a man who has to keep moving forward, day after day, with minimal social contact and no guaranteed progress feels a lot closer that one might expect at first.

To gamify the fantasy and play of the setting we realized quicky that the urge to explore and the desire to find secrets underground would be a key factor in our experience.

These aspects ended up representing our initial core pillars:
· Mining
You are a miner and the challenges of the world are the challenges a miner face.
· Daily loop
You are a man with responsibilities, your family needs your help, and you need to keep going back in order to move forward.
· Sacrifice
The game is about making sacrifices. Initially the sacrifices where handled by a physical local: The Altar, which would reward you in exchange for game changing sacrifices. (like sacrificing your family or your happiness)

In the later stages sacrifice became more of a Motif:
Narratively you sacrificed being close to your family to be mining. You also sacrifice your precious time to keep exploring.

We soon realized that our attachment to sacrifices was caused by three important aspects:
The sacrifices where a way to talk about something more important: Everything has a cost.
How are you really paying in these hard times?
What is the real cost of the gold John finds?

The sacrifices also always included the other side of the coin:
The different types of rewards.

Is finding all the gold your family needs underground and becoming rich the reward you are seeking?
Is the greatest reward finishing the game or paying for your sons’ collage?
What about the mineshaft you have built? The consequence of your work in the pursuit of happiness, is that not the real reward the game gives you?

When playing the game myself, I quickly end up spending my resources for two things: A radio and a ball.
I’m not mining to find the gold, or to send money to my family. Of course, I feel the responsibility to do that, but primarily I am mining because I enjoy it. Because it is playful and calming.
That should, in many ways, reflect my stance towards game development and the end of the study. The bachelor thesis is the concluding act of our study. While developing the game we were not only faced with the challenge of finishing it, we were also faced with the challenge of accepting that the study is coming to an end and to understand what we want to do with it.
In the end Sacrifice made way for a new and more important pillar: that of exploration and discovery.

Who knows what lies at the end of the mine?
The idea that there might still be something, is often what makes you continue moving forward.
While the game was meant in no way as a metaphorical one, I have come to terms with the fact that our games end up saying more about ourselves than we expect.
For me the game is about responsibility, persistence and finding joy in the small things.
As of right now John cannot go back to his family, the only thing he can do is continue mining. The game also lacks a real ending.

Will he end up like the old miner in the cave?

Game Architecture

All that lies below was the third bigger platformer me and Lucas developed together following our internship at the HKW and Corona World.

This allowed us to save a lot of time understanding the developing pipeline and the work separation between us.

In the end the work separation boils down to a simple algorithm: Who feels like doing a task takes it.

This works well between us because we share different interests and both have a strong sense of completeness, meaning that uninteresting tasks were never left behind.

As we can both function as generalists, this meant that all development parts where somewhat covered and overlapping.

Because of Lucas artistic proficiency and my programmer knowledge the visuals we ended up naturally splitting these kinds of tasks. Lucas took care of the View of the game while i handled the Model.

For non-programmers it’s easy to forget the amount of time and energy that goes into making a game functional, stable and expandable, which are often the main factors in blocking a games growth and in lowering morale.

Here are some of the most important architectural decision.

Dependency Injection

I decided to switch to Zenject a few weeks into the development.

A main cause for bugs and slowed development is the presence of bad dependencies. Systems start relaying on other system become more and more intertwined and coupled over time. This is especially true for games with a lot of dynamics and a lot of small systems.

With the help of Dependency Injection all dependencies come in the same form: An Injected Object. With Zenject these are also always localized at the beginning of the file or in a so called “Installer”. This streamlined the development process of anything:

Create a new script, inject the necessary dependencies, implement the behavior.

If something needed to become a dependency on its own it always meant taking the intentional decision of adding it to an installer. This naturally forced the architecture to be vertical and to avoid circularities. It also meant that it was really difficult for Lucas to make an architectural mistake without knowing that it might happen, as dependencies can only be created very knowingly.

Clear Categorization of Classes

There are pretty much four types of classes in our project.

Data Objects, Handlers, Behaviors and UI scripts.

Data objects simply hold data. Things like player settings and Items attributes. That’s all they do and all they should do.

Handlers take care of abstract concepts. Often these are mapped to specific mechanics. There is a Progression Handler, a PlatformHandler, a Transition Effect Handler etc. Anything that is conceptually larger than a single thing gets its own handler. Handlers are also (nearly) the only thing that gets passed around as a dependency.

Behaviors are scripts that make a thing behave like that thing. For example, the Platform script makes the platform visually attach correctly and connects to the underlying map, but it’s the Platformhandler that takes care of connecting different Platforms together.

With every task the pipeline was simple:

Are all the abstract concepts in place?

Yes: Inject them with dependency injection and write a behavior

No: Write a handler for the abstract system, make it injectable and then write the behavior

Every bigger concept in the game probably has a Handler for it. (This connects back the Single responsibility discussion above)

Following S.O.L.I.D.

Over the last projects I’ve been working hard on understanding the SOLID principles. Specifically, it was important for me to understand how and when to use them in a small indie game development context. For our previous platformer: Corona World, I ended up trying too hard to stick to these principles.

I tried to program closer to what software-developers expert recommend for large software, which often does not work with games.

Here are my learnings from then, which I applied in this project.

S:

The single responsibility principle is everything. A game developer that doesn’t apply it constantly and think about it all the time will never be able to keep anything larger than a prototype under control. Most games are a large amalgam of smaller systems. The programmer needs to be able to think about the individual component in its small form, even more than software developers.

It’s all about understanding what the machine is doing and games are quickly to big to be understood in their completeness. If you have one object for one responsibility, a human can still make sense of it.

O:

The Open / Close principle should NOT be followed when the game is not fully defined (which, let’s be honest, we have learned is never the case.)

Designers NEED to have the space to change their mind. If a designer changes their mind it is often out of necessity. And we need to support this. Following the Open/Close principles encourages expansion and fights modifications. In the best of all worlds for games we would need an Open/Open principle, which is impossible.

Personally, I’ve come to adopt the following process when developing a new feature: Decide about the Open / Close principle by talking with the designer and understanding how sure they are about what I need to implement. If the designer is thinking (trying to understand and experience a design idea) than you should never build a closed system. If the designer is very sure and you know that probably there will be no going back on the idea, follow the Open Close principle as it results in cleaner and more sustainable architecture down the line.

L:

The Liskov substitution principle is in its pure form a necessity. The extended interpretation requires an excessive abstraction of ideas. This was one of the mistakes I made in Corona World and I ended up writing a huge number of interfaces which were only implemented by one class anyways.

My learning:

The Liskov substitution principle should be followed until the last days of production, where anything goes, but there is no need to excessively abstract concepts if you are in a small development group. (Overdoing even causes confusion. Do it only when necessary.)

I:

Interface segregation is really about team size and product size, if you are just a few programmers, who cares about the interfaces not being clearly separable.

As games are more complex than complicated, worst case scenario you have to refactor a few classes down the line.

D:

Dependency injection is the reason I can sleep well at night. Unity encourages terrible architectures. In Unity anything bigger that a prototype should use Dependency Injection if you want the program to still be stable a few months down the line. (I’ve been looking at a few Unity developing companies in Berlin recently and they all add “Knowledge of Dependency Injection frameworks” in their requirements, so I know they agree with me.)

Player State Machine

The Save and Load System

The saving and loading system plays a central role in our game.

This is because both the normal saving and loading as well as the saving and loading of sub-scenes run through the same system.

Every underground cave as well as the overworld are developed in custom levels, where they are specifically assembled.

At the beginning of the game these are all loaded into the playing scene.

Al the necessary handlers are also spawned in as well as the Player and Camera. Making the game playable. This assembled final scene relies on a few core ideas to work.

Initially we would spawn the extra scene using Unitys “Additive Scene Loading”. This quickly resulted in 10-15 seconds of waiting time, for a few scenes, which made the development very painful.

For that reason, I reworked the saving system to allow saving and loading custom scenes.

At the beginning of a new game all our custom scenes are Loaded into the game at a specific offset. When the game is then saved by the player, by going to bed, the final, assembled scene is saved in one combined object.

This allows us to have procedural and semi-random generation, while still saving the scene correctly.

Key feature of the save system is the ability to save the tile system submaps as well, and to “imprint” them onto the playing map.

When loading additively not only do the objects get spawned, map areas get carved onto the main map as well.

Because of this the Main “PlayScene” only contains a sporadic amount of GameObjects in Editor and we can both play, test and develop in this scene without getting merge conflicts or stepping over each other’s feet.

In Engine Scene Addition Preview

The Dialog System and Miro Parser

I was interested in adding some form of narrative from the beginning. The first altar drafts already included branching conversations and topical responses. The problem was always the development pipeline. Throughout the process I wrote different dialogs systems. Starting from the first one, where I wrote the dialogs in excel and connected them with IDs similar to what you would find in an old design document.

Due to its cumbersome nature we soon reworked to a static structure where you don’t converse with the dialog but directly can decide what to sacrifice for.

The idea to parse data from Miro was in my head from day 1. My problem was always that I feared the implementation would take too long a be really problematic.

As is often the case, this did not happen. I achieved a functional Miro exporting script very quickly thanks to the great Miro Developer API. From there it took a few steps to get it to work as a Dialog Tree developing tool.

The core idea is very simple: The best way to visualize branching dialogs are trees. These are extremely easy to build in Miro, with the help of arrows to connect different sections. All i needed to do is to convert the Miro widgets into an internal tree representation. This was, of course, not as simple as it sounds.

Here are the steps I take to convert the Miro boards into in game dialogs:

1. Export the Miro board as JSON. For that I run a simple script in my Chrome Brower

2. Load the JSON file in Unity. For this I created a small custom Editor, which simply uses the default Windows file selector to select and then read the File.

3. With the help of Unities JSON library I convert the Board to a Usable C# object. This already filters out a lot of unnecessary data, as I only parse the data I need, such as Type, Id and arrow connections

4. Because I always export the whole board, the first step after loading is to remove all the widgets I clearly will not need, such as Frames, Text, Images etc. until I am only left with Cards and arrows

5. Now I am only left with card trees and individual cards. So I first remove all cards that are not connected by arrows

6. As we also tend to build card trees for other purposes outside of Dialogs, I need to only keep the Trees that start in “Dialog” or in “Option”.

7. To do that I need to convert the Widget list (including both Cards and Arrows) into a Tree structure of cards, where the arrows are replaced by connections between the different card nodes

8. Now I am left with a list of nodes and the connection they have to other nodes. As well as a list of Root nodes. (Which I internally called a StringTreeCollection)

9. I serialize this collection and save it into a file. This can be understood as my intermediate format. This way on GIT only a tiny file gets pushed on every dialog update instead of me pushing the entire board every time. This is also the last step done when loading a new board version.

10. Upon game startup the previously saved file gets loaded again and the next translation step starts.

11. Because the content of every node has a very specific behavior based on the displayed text (“Trigger” needs to trigger an event, “SetVariable” needs to set a variable), i convert the StringTrees into Dialog trees by parsing the content text and converting it into a dedicated Object. So, a Node containing: “Trigger CamShake1” becomes an object of type DialogTriggerNote with a variable set to “CamShake1”.

12. I now have an unusable logical tree of nodes with different behaviors. This is very close to a Behavior tree system. The final step is to simply run one of the root dialog nodes through an object which can execute it correctly. This involves a lot of architectural steps, but it basically boils down to: When the current node needs to display text tell the visualization to display text and then switches to the next node and so on.

While these steps sound very complicated, it was actually a quite quick and painless process, that was stable after 1-2 days.

I wish I tried this out earlier instead of waiting until I had no other option. I tend to overestimate the complexity of certain systems, which is something I also did for the Kernel rework for the crumbling system.

Ingame Dialog

Letters and Love

I proposed the idea of exchanging letters with an external narrative figure very early into the prototyping. I was fascinated by the parallelism between modern Text messages and Tweets and

how a letter system would work in the game. The letters need to be short to be read (Around 100 words in the final version) and they usually get a response or follow-up in about 5-10 minutes. This allowed us to encourage the feeling of loneliness by using the thematically fitting concept of letters and still provide an experience that we can still identify with in the digital era.

We have all sent strong emotional short messages through WhatsApp or per message and know the feeling of waiting for a response. When Isabel sends you a letter, it’s the same experience as if you had just received a message, without the narrative setting being broken.

This postbox/letter system quickly expanded to other systems, like our shop.

We suddenly had this Postbox, which was our connection to the outside world.

Initially my plan was to write back and forward conversations between John and Isabel. Due to the explosive nature of this system and the fact that I was always busy taking care of the other priorities, we soon realized that writing these letters would have been a bit of a problem.

Cutting the system was not an option, as it really helped making the world believable and real and had grown into a central motivator for the player.

We thus decided to rework the system to reduce the number of letters needed and to find someone to write them for us.

Having someone write them for us ended up being a good decision. Rebecca’s (our writer) letters where to the point and better written then mine. Most importantly it allowed me to concentrate on other aspects of the game, while still maintaining a directing role in the overarching narrative, which was the aspect I really cared about. I loved the idea of conveying the problems of a distance relationship with these letters.

In my head this simple letter mechanic alone adds a completely new dimension of thoughts in the mind of the player.

Will i make it in time? How is my son doing? Will my wife leave me?

These are powerful questions, especially taking into consideration that none of these characters really exists.

Because letters arrive, in the mind of the player, an outside world gets created, even though our world only consists of a Hut and some underground structures.

Our development cycles always shifted the narrative aspects to last. Our first priority was to make the core game loop: Mine -> Discover -> Sleep fun and enjoyable. The bigger loops ended up having longer iteration cycles. This means that now, upon delivery, I am unsure how well the latest iteration of the letter system really works.

Because of the short development time and the fact that understanding how well the narrative works requires a lot of playtest, I think we took the right decision by prioritizing more central aspects.

Production-wise the fact that we had no time to iterate of the final state of the letters implies a very clear problem: We tried to do too much, with to little time.

Wanting to do too many things is a staple problem throughout this Project. As it is our final Project and we are finally capable to technically create what we design and desire, we really wanted to do everything in this game. (And I still plan to add Multiplayer as soon as I get a few days of break)

Is that production-wise a mistake?

Definitely.
But this is not a project where we need to make all the right choices, this is a project where we can have fun. Some of the most fun mechanics in the game: Like the Ball, Radio and Elevator came from one of us having fun, developing by intuition and by instinct.

                          

Ingame Letter View

Instrumental Convergence

At the beginning of the prototyping phase we intentionally decided to not design the games around our thesis topic. I had a few interesting ideas to apply the thesis of instrumental convergence in a very direct way, but they all required drastic limitations. Generally, using the theory in a production context, instead of a targeted game, more closely fits the ideas described in the thesis.

If you don’t know what I’m talking about, this section is refering to my Bachelor Thesis: Instrumental Convergence for Game Development, an analysis of the utility of the theory of Instrumental Convergence in games, which you can find here.

Concretely, we used the theory sporadically during the development.

The reasons behind that are a few:

· The theory itself, as a lens, is meant as a designer’s tool to be used when discussing motivation and predicting behavior. In most games, like this one, this will not be often the case.

· Because both Lucas and I spend most of our time developing, we spent a lot less time thinking about the game, than one would do in a traditional designer position. I probably spent around 60%+ of my time programming. With the rest of the time being split between, designing, planning and discussing.

· As it mainly is a theory of numbers, that works especially well with games targeted for large audiences, the game was also not a good fit.

Regardless, I was surprised by how often applying the theory in my thought process allowed me to understand certain situations better.

A good example of it being applied practically is in the discussion of the consequences of ingame-death.

Practically I have a few corrections to make to the thesis thanks to my experience with the project.

The basic drives play a minor role in the motivational aspects of a game. Leading factors like extrinsic motivations (quests, narrative goals, win conditions) combine with the basic drives and expectations to merge into a final amalgam of motivation. In the thesis i always observed them individually, while playtesting our game I often found that they had the greatest effect in combination with another motivation.

Here is a good example:

We had a few playtesters with a lot of experience in similar games like Minecraft and Terraria.

This was a huge problem! Because, even though the games have large mechanical similarities, they function in completely different ways. The punishment for death in normal Terraria is completely negligible. More importantly, the initial core loop of Terraria is all about going down as quickly as possible. These players entered our game adopting their basic drives from their experience playing terraria. They rushed downwards as quickly as possible and were completely punished by our death system. We don’t want our game to be rushed, as we thing that it is the most enjoyable when taken rather slowly. So we put in place multiple aspects to slow you down, our death being the main punisher. But these factors where put in place expecting the basic drives of a human: Terrified of death, cautious and careful. For these warped drives our design is terrible!

I discuss the topic of real-life drives being carried over into a game, but i never considered how effective this also was between similar games. A similar example happened with Minecraft. In Minecraft the creativity drive thrives, everything is so dynamically connected that finding creative solutions to problems is nearly always the right answer! The building mechanic is a big part of this.

That is not the case in our game, design wise our game definitely encourages the Efficiency drive over the Creativity drive. The game is very rational and is easily predictable, all factors that encourage the Efficiency drive. Minecraft players coming in with a boosted Creativity drive were quickly left disappointed. As we were not rewarding them for their creativity.

Did we fail to encourage the creativity drive or did we fail to communicated the core differences between our game and Minecraft?

Personally, I find these expectation-related morphed basic drives to be extremely fascinating.

But at the same it throws a bit shadow onto my theory. If the basic drives can be so easily morphed, that it requires a deep understanding of social expectations to predict them, how helpful are they really?

A second addition I would make to the thesis is on the chapter of Instrumental driven prioritization. In it I discuss how using this strategy is effectively the safest way to gamble a development decision. While I still consider that to be rationally sound, i have come to realize that it is not helpful.

My realization is the following:

If you find yourself gambling a decision in the development process something has gone very wrong. The events that lead to the situation should be analyzed and a decision should be drawn accordingly. So, you should never end up actually using the technique.

In my head, I compare my advice to the advice you get in case of a shark attack.

If you ever find yourself attacked by a Shark, your best bet is to hit it in the eyes. While that is probably true, a more helpful advice is to discuss how to NOT end up in a shark attack in the first place.

Instrumental driven prioritization is the same, while it might be and interesting technique, there is more useful advice around (see the entirety of Agile Processes), which should take priority over a last resort strategy. If you end up needing to take a development gamble, you have bigger problems than the decision itself.

Corona World

Corona World

The Bohemian Browser Ballet is a satirical program part of the German Funk network. They are mostly known for their comedic sketches that push the boundaries of satire, but also, to some, for their games.

In periods of high topical trends they like to hire indie game development studios to quickly develop a fitting satirical game. The goal is simple, develop a game in a very short amount of time, to use it as a new-media platform for satire. The results are often controversial, some people love them, some people get mad, but excitement is always in the air.

At the beginning of the COVID pandemic the Browser Ballet immediately realized the potential for gamification and started contacting it’s previous developers. Due to the short notice all affiliated companies where unavailable, so the Ballet started looking for a new player.

My team and I were recommended by our professor, who happened to be one of the developers on a previous game: Muslim Ban 2. Very happy with our performance at our previous gig he introduced us to the representatives and after expanding our team to match the requirements, we were in business.


We now had to develop a topical game, highly inspired by Super Mario World, in around 3 weeks, making sure to meet all of their requirements, which included multiple enemies, a boss battle and at least 5 minutes of gameplay. Additionally we had to make sure to implement a leaderboard and to properly package everything with Unity’s WebGL.

Our team had the following composition:

  • 1 Producer
  • 1 Programmer (Thats me!)
  • 1 Level Designer
  • 1 Designer
  • 2 Artists
  • A bucket of love for the craft and juvenile naivety

If there was a team composition that was fit for the task, this was definitely it, but we knew from the start that my time would be stretched quite thin and my responsibilities were high. After all I had to implement multiple enemies, implement a boss battle, setup a leaderboard system (inclusive server-side), allow for localization and iterate on a complex player controller all while ensuring the happiness and productivity of my designers. We also had no time to deal with development issues, thinks had to work quickly and they needed to continue working correctly indefinitely!

Fortunately, contrarily to most game development processes, this game had a very beneficial requirement: The games final structure was set in stone from day 1; The game would always be a Super Mario World like level based platformer with a boss battle at the end. This allowed me to execute the following strategy: Pre-design and implement the macro software architecture immediately, while the designers are still busy with figuring out the themes expectations.

In a normal development scenario this would be a very wasteful strategy as games tend to mutate largely in the early stages of development. But in our case it proved perfect. By properly following the SOLID principles and implementing a custom minimal dependency injection framework I was able to setup the entire architecture in the first 2 days.

Here is my Day 1 Architecture diagram:

Corona World Class Diagram

I am happy to report that this diagram only required minor modifications and allowed me to focus my attention at the remaining responsibilities. Most notably, I ended up having to spend countless hours fighting “hackers” (or rather abusers) who immediately after release realized the abysmal security measures (or lack thereof) that i had implemented.

Honesty, do I really have to use advanced encryption for high score submissions of a satirical minigame?!

In the end the development went quite well and the Browser Ballet was satisfied. The initial reaction where quite positive, some people even started speedrunning the game and submitting competitive scores. Over time though, with the continuation of the COVID crisis, the game’s videos became more of a platform for unsatisfied citizen to express their repressed frustration.

If you, like me, still feel like throwing disinfectant on people that don’t follow restriction regulations or simply want to smash COVID’s head, give the game a try. It can have a real cathartic effect.

https://www.playcoronaworld.com/

Spiel Das HKW!

Spiel Das HKW!

I had the opportunity to work on this project for the House of the World’s Cultures one of the most important cultural institutions in Berlin. They decided, as part of a internal exhibition to commemorate the 30 year anniversary of the institution, to make a game. This game had to gamify the internal workings of the organization and display quirks and features of the institution in a playful manner.

We developed the game in a group of four developers. As is the normally the case with small teams, we split most responsibilities equally, but I was mainly responsible for programming and rapid prototyping. Due to the highly mutating requirements from a client base that was not accustomed to playing games, we quickly realized that the best strategy was to produce numerous miniature prototypes, to reach as wide of an audience as possible. For the final exhibition we would then develop a more extensive game. We ended up developing 3 prototypes, a card game and an arcade machine as well as the final game.

Windwalker

Windwalker

Windwalker is an explorative gliding game I produced with a team of 7 members in the Unreal Engine.

The team roughly comprised of 3 Designers, 3 Artists and me acting as a producer and developer. Practically most responsibilities were handled in a more cross-department way, which meant that designers would implement & prototype their own designs and artists would directly influence level design and take care of tech art.

For me, this was the first experience as a producer with a team of this size. I was also one of the more experienced Unreal Engine user, which resulted in me being the engine guru from a technical standpoint. This project gave me a lot of insight into working with different personalities and taking care of unique project bound responsibilities. Specifically, in this case, a lot of energy went into planning a process which allowed the designers to stay productive without the presence of dedicated developers to cover their needs. The production board linked above is a great place to look up the challenges we had to face.
(Note that the board was meant for internal use only and expanded over the development in an emergent way, also containing meeting notes and similar active documentation notes which are unintelligible to an outside viewer)

In the later stages of development I also took responsibility for some technical tasks. Most notably iterating on the gliding mechanic, implementing the saving system and adding bird flocking simulation.

Dim

Dim: A Light in the Dark

Dim is an atmospheric puzzle game developed in Unity I worked on a few years back in a group of 5 people. In it I was the main developer as well as mechanic designer.

The main puzzle mechanic revolves around the player being able to collect and distribute energy “charges” which he can use to interact with the environment. Similar to a modern day battery, the player has the ability to charge and discharge specific energy containers. This triggers environmental effects (lights turning of, machines starting/stopping) as well as additional puzzle logic. A key example is that of elevators: based on the energy state of the attached container elevates to a different height. Additionally NPCs and other systems also interact with this quantized energy state system to allow for complex puzzles.

Technically the mechanic is implemented using an event system which allows concrete implementations to listen to state changes in associated containers and react accordingly. This allowed for the rapid development of additional layers while ensuring a continued correct behavior of the core system. Additionally, simple juice inducing effects were extremely straight forward to implement, allowing me to delegate this responsibility.

//Affect animations based on energy levels
public class AnimationMotor : BaseEnergyStorageListener
{
    ...
    public override void OnEnergyChange(int newEnergy)
    {
       bool active = newEnergy >= activationEnergy;
       animator.SetBool(IS_ACTIVE_ID, active);
    }
}

Mindbend Engine

Mindbend Engine

The Mindbend Engine is my first attempt at writing a custom rendering engine. Inspired by Marble Marcher and the articles by Inigo Quilez i decided to write a small game engine to push the limits of modern game development.

In essence, the Mindbend Engine is a rendering engine that uses SDFs (Signed Distance Fields) and Raymarching to visualize mathematically defined structures. The potential of the theory is mind-blowing. Shapes that are impossible or incomputable to draw with traditional triangle based engines become the norm. Additionally procedural effects and other recursive rendering have no added costs. This allows for amazing effects, like bending geometry over time (think of Inception), multiplying objects and boolean mesh operations.

If it is so great, then why aren’t people using this already?
A big part comes from the technical limitations. Similarly to ray tracing, ray marching requires very expensive per pixel computations. This highly limits the amount of objects allowed at one time and requires more high end hardware. None the less Nvidia and AMD have been working very hard towards improving support for these technologies in the latest years. In a few years, this technical limitations won’t be a problem anymore.

From a game development standpoint I believe that we haven’t seen many games using these technologies extensively because there simply aren’t the right tools around. My goal with Mindbend is to create an engine that allows designers to prototype objects at runtime, by writing SDFs and assigning dynamic parameters. Established concepts like meshes and traditional rigidbody physics algorithms fall apart, objects need to be defined in a purely algebraic form and physics needs to be approximated using point-based approximations. Once the appropriate tools are put in place to properly take care of these limitations, new games will be born that challenge our understand of reality.

This project is still in it’s early stages and is not more than a proof of concept. Currently I am working on creating a runtime interface to allow runtime definition of SDFs and consequently quick runtime Shader compilation.