The screens we have implemented so far appear and disappear immediately. That looks fine for some screens, but chances are good you will eventually want to add a bit more polish. In this lesson we will implement a couple more screens that animate onto and off of the screen. We will use a couple of different animations, and see how to continue in our flow after the animations complete.
Thanks to all the work we did creating our data models in the last lesson, we now have enough that we can continue on with the game flow into the setup screens. In this lesson we will implement two new screens. The first screen will determine the number of players, and the next screen is for configuring each player with a name and starter Pokemon.
There are several more models we will need to create before we can start even a basic game. Pokemon, Players, and the Game model itself are all a required part of the setup flow. Technically other data models will need to be created during setup as well, but at a minimum to get the game up and running we will need these three. In addition, each of these models will be provided with a factory class to help create and configure them.
I’d like to continue moving straight through the flow to the setup screen, but there are several pre-requisites we will need to address first. Among them is the creation of a database connection that can be easily consumed by all of our systems. After connecting to the database, there are a few things we can do to make fetching and working with its data a little easier. These will be implemented as extension methods.
Now it’s time to provide a concrete example of our flow in motion. We will handle the first couple of states, the “Intro” and “Setup – Menu” state. We will show how to display one screen after another, both based on an app event (launch) and based on user input. The Flow Controller handles both cases like a champ.
The application flow determines what happens and when it happens. In nearly all of my previous projects, the flow sort of just emerged as user interactions and app reactions were tied together. However, you may find value in taking the time to create flow charts. Almost like an artist would create some thumbnails before painting, flow charts can provide you a way to quickly rough out the logic you’ll need to implement. If you can make it clear now, it should be clear later too. In addition to being a good diagram to follow during development, a good flow chart can also serve as an excellet piece of documentation for later – one which probably far surpasses the value of code comments.
There is one last “resource” we need to gather – the data for our database. I saved this for its own step, because I wanted to take a bit more time to explain the “how” and “why” of the layout of the data. It has a certain pattern to it which is based off of something called an “Entity Component System” architecture.
If you’ve followed along with me in the past, you have probably seen me use project assets such as prefabs or scriptable objects as a sort of database. While this approach has certain conveniences such as the ability to make edits in the inspector and connect references with other project assets, it has the downside of being a little fragile. In this project I decided to use SQLite as my vessel for storing Pokemon data. While it can only store basic data types, SQLite still has plenty of other strengths to offer.
I’ve completed another prototype. This is actually a game designed by my oldest son (9 years old) that he created on paper, and I decided to flesh it out for him. The game is a local multi-player game where each player is a Pokemon trainer. As you travel around the board you can have random encounters with wild-pokemon, catch and train them, and eventually test out your skills against a gym. The first player to earn four gym badges wins!