Early last year Microsoft sent an email to registered developers letting them know that XBox Live Indie Games (XBLIG) was going to be shutting down. That meant that anyone who had purchased the XBox 360 version, would no longer be able to play the game they purchased. At that time I decided to change the Android version to being completely free with no advertisements. That was kind of my way of giving the game back to the people who had purchased the game on the XBox 360.
Later this year, the XBLIG will be permanently shut down, and all access to the game will cease. In light of this, I have decided to release all the source code to both the XBox 360 version, and the Android version to the public. You can find the source code on GitHub using the following two links:
Today I want to talk about Truth, View, Input (TVI), a coding concept designed specifically for video game development. I first heard about this concept from Michael C. Neel (www.vinull.com) during his 2016 lecture at the Knoxville CodeStock convention. Since then I have thought over the concepts and attempted to put them into practice in my own games. Today, I want to explain what TVI is, how it can be used, and most importantly, why it should be used.
Truth, View, Input (TVI) is a programming concept designed specifically for game development, much the same as Model, View, Controller (MVC) was a coding concept designed for web development. In truth, MVC and TVI are very similar, however, there are some marked differences between them. I'll leave comparing the two up to you, but let's first make sure you understand what TVI is.
The first concept to discuss is the Truth. We're not talking about truth and lies here, it is not that kind of truth. Essentially the Truth part of TVI is the data portion of your game. It is the player's coordinate, the position and health of all the enemies, the list of items being carried by the player. In practice, the truth should be the entirety of the game, minus all graphical outputs or player inputs. In short, the Truth is a data representation of the games current state, and contains all the code necessary for running the game.
The second concept to discuss is the View. When you play a video game, the graphics you see are part of the view. When you open a menu, the graphical representation of that menu is part of the view. Quite literally, the view is how the player sees the game.
The last concept to discuss is the Input. As the name suggests, this handles all the player's input. For multiplayer games, this may also handle all inputs from remote systems. When you see a button on the screen, the visual display of that button is in the View, but when you click on that button, the Input handles that click.
Bringing it Together
The struggle here is separating the three concerns and having them work together as though they were all built as a single unit. The key to doing this is how the Truth is designed and implemented. The code in the Truth should never interact directly with any IO. It should provide methods and events that allow the other two pieces of TVI to interact with it.
Let's think about Tic-Tac-Toe for example. The Truth layer keeps track of the 3x3 grid and what moves have occurred, it also handles checking for win and loss conditions. When a player selects a square to place their mark, it is the Input layer that handles that interaction. So let's say that player 1 places his X in the center square. The Input layer receives the input from the player and calls a method in the Truth Layer telling it to put player 1's X in the center square. The Truth layer notifies the View layer that the X has been placed, then checks to see if that move creates a win or a loss condition. If the move does create a win condition, then the Truth layer fires off an event that declares player 1 the winner. The View layer sees that event being fired and updates the screen to show a victory screen for player 1 and a loss screen for player 2.
Why Use It?
The Truth, View, Input concept separates the game logic from the output and inputs of the game. The main reason that you'd want to do this, is to make it easier to port the game to other platforms. TVI also makes it easier to reskin a game completely.
Let's say you were building a clone of the original Zelda game. In keeping with the style of the original game, you started building the entire game using 2D sprites, so the entire game was 2D. Then you get a DMCA notice from Nintendo saying that what you are building was too similar to their game. After a brief talk with your legal team, you've determined that you could change the game to being a 3D, top-down game and that would keep you legally safe. Without using TVI, you now have to go through all your code updating all the graphical code, but since it's so integrated with your game logic, things break. By using TVI, you don't have to touch the Truth or Input layer, you just update the View layer, and you're back in business.
Now the game looks completely different from the original, and you release it and its a hit. It sells really well for PC, but gamer's demand that you release it on XBox One and Android. With TVI, you just have to change the Input layer and you're ready for XBox. As for Android, you determine that on-screen controls would be best, so you update both the Input and the View layers.
The basic idea is, that by just swapping out the View and Input layers, your game should be able to be released on virtually any system. It's entirely possible to build an RPG game that runs in a dos window using ASCII character for its graphics, then easily convert that same game to using 2D or 3D tiles by merely swapping out the View and Input layers.
For an example of how TVI can be used within Unity3D, check our our publicly released project, BrickLayer on GitHub: