I had another great experience at Global Game Jam Vancouver.

This time I jammed with 6 other CAPCOM employees and my friend, Michael Lee (www.soundcloud.com/pixelee), an amazing artist who provided us with exhilarating music and SFX.

The theme, "ritual," inspired us to create a twin-stick shooter where an ibex uses magical powers to protect itself from villagers trying to ritually sacrifice him. Made with Unreal using 3D models from Maya.

See the full credits below and check out the game page at www.globalgamejam.com/node/30800

My role was 3D modeling & UVs with additional responsibilities including scoping and guiding our project schedule, mentoring UE4 visual scripting, and imparting (surprisingly little) design wisdom. I photoshopped the credits and game over screens too.

While working on a board game in my free time, I ran into a complex problem that is simplified here for discussion. I am designing a systems based game with three paths to victory, all of which should give a roughly equal chance of winning. The paths use different mechanics to increase the player's odds of winning as the game progresses. Setting up my game in Machinations provided fast automated testing, which I used to balance the three paths to solve the ceiling problem: to make sure a player is equally likely to win whichever path they choose. Only playtesting revealed the fatal flaw in this system. 

There exists a low point in the current prototype that is so hard to climb out of that the afflicted player will take more than the length of an average game to return to a normal state. This typically drags other players down too, until everyone must pass on all the opportunities and gameplay made available to them. Since most of the win conditions are based on chance, players are put in a situation where they are hoping that someone else gets lucky and wins. In other words, an abysmal failure at systems design; no matter how many good playtests it had.

Winning is not the most important part of a game. Why did I treat the systems design process as if this were the case? It was an honest mistake, trying to leverage the tools that I had.

I could also try to take a data-focused approach and continue to leverage these tools by finding what conditions caused my floor problem: when a player can no longer take actions that lead them towards victory. This approach suffers from tunnel-vision and probably would obscure some other problems that must be solved with the current design. Other designers recommended comeback systems to solve the floor problem as used in many highly-rated games, like Lords of Waterdeep and Agricola. My definition for comeback system is one where the player(s) who are not the current visible favourites to win can gain large amounts of points at the end of the game and win if the other players do not account for them. However, I lean towards a guideline I was given by another designer which warns that comeback systems only do a good job at concealing the true game state from the player. I do not want to conceal more from the players or myself in the solution to my problem. 

No, the solution must be a holistic one because the problem is with the perspective I took when designing the systems. Good multiplayer systems have a safety net that prevents death spirals, or positive feedback on successive failures. Great multiplayer systems are designed to leverage their mechanics so they do not need any safety nets. These edge cases often require inelegant solutions, and may require a new one for each new edge case discovered. I will end this wall of text with a moral: