I’ve switched gears as I set a simple goal for 2023: ship a single game… the hardest way possible. Look at me, I’m being an adult with goals and strategy (it may be a bad strategy, but it’s mine)! I’ll have more details on the game in 2023 as it becomes playable, but I’m building a new runtime for games. I want to explain the reason for the emphasis of runtime over engine, and then I want to make the case for such an investment.
Most games are typically bad investments due to the high failure rate and exceptional costs. Despite the failure rate, many people will try to make a game which is why the game engine market is a multibillion dollar industry. The promise of a game engine is to derisk and accelerate time to market which lowers many expensive technical costs. This works out well because most games feel like content.
Games as content is the right mindset, and the key question is how to dramatically lower costs.
In entertainment mediums, a spectrum emerges of content from reading a book, watching a movie, playing a video game, towards a completely immersive VR experience. As the production cost (and perceived quality) goes up, the need for imagination goes down. Board games sit just above reading a book as they require using your imagination with just enough visual clues to unify the experience among players.
Belief #1: Modern game engines are for AAA games, yet modern AAA games are exceptionally expensive for an increasingly inferior medium.
At this point, I probably sound like an old man yelling at the damn kids to just read a book. This is probably a fair point, but the important aspect of a game isn’t the graphics, animations, nor audio but the socialization. There is a deeper reason for playing games, and the task at hand is how to lower the engineering costs. This belief manifests is focusing away from all the possibilities of every possible experience, and instead focus on a rich library of well crafted composable experiences.
The runtime is a set of composable components which operates against a streaming medium (i.e. Adama). The runtime is significantly leaner than a game engine as it is a thin client where Adama does all the heavy lifting of coordinating game play. The goal of the runtime is to create a reasonable and accessible user experience (UX).
This runtime should mirror how the browser turns HTML into a document. However, instead of text, tables, and buttons; we have decks, tokens, and other things found within most board games.
We start with a deck of cards precisely because the first game I want to make is a trick taking card game. With just a deck of cards and a variety of ways of using cards, a number of games unlock alone. The beauty of this approach is that as more components are added, more games become possible.
For example, having the concept of a token and token mat then enable more games to unlock, and there are many components that will compose in a variety of ways.
Understanding the design space can be accomplished in two ways. First, the components available from The Game Crafter are a reasonable target set of things to work towards. Second, the book Building Blocks of Tabletop Game Design, an Encyclopedia of Mechanisms provides a comprehensive study of the vast variety of games. From a tactical perspective, the possible components to build is finite and just needs ordering in terms of execution.
This is philosophy I’m bringing towards roslin which is the bespoke runtime I’m building.
The question then is whether or not this investment achieves the mission of dramatically lowering the engineering cost of bringing a board game online.
Belief #2: Data binding is exceptionally powerful when leveraged at design time
The working picture of this system looks something like this:
The game state comes from Adama (1), and this state is everything the player can see. Roslin has three jobs: turn the JSON into a picture, (3.a) manipulate local view state, and (2) generate explicit JSON messages to represent player decisions. The view state is gossipped to Adama (3.b) such that Adama can yield view-specific game state. This picture illustrates the technical flow of the runtime, but it may be more interesting to explore the production workflow.
Here, there are two core roles in making an online board game. The “board game logic developer” primarily works to transcribe the game’s rules to Adama (1), and this is an engineering role. The “board game graphic designer” has the role of using the design tool to interact with the game logic (2) and then design the game’s UX (3). The logic can then be connected to the UX via data binding (4). These two roles are highly collaborative yet disjoint. The ideal developer tools are such that a game can be played at a low level without any UX. The spirit of the design tools is to allow introspection of what data is available to leverage in a design, and then transform the data into a good looking picture. The key ask for the traditional graphic designer is to learn how to data bind, and the tooling should make this as easy as using fake data.
The key element is that the engineering cost is exceptionally minimal as Adama is beyond powerful. Working with Adama has the same cognitive complexity as working with Excel which has a long history of transforming computing. It should be clear that this has exceptionally lower cost when compared to either web development or game development as there are no front-end engineers nor game developers, and the spirit is that a single person can build an online board game: the board game designer.
This low cost also comes from the fact that the components are provided for almost all board games, and the composition is a well thought system which further reduces the need for the board game publisher to invest in software testing (play testing is still important).
The cost is so low that I believe that pursuing this path unlocks an open platform for anyone to build an online board game.
Belief #3: Board games are only the beginning…
Please sign up and stay tuned for more details.