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.
Since this is a game for private and educational purposes only, I didn’t mind using copyrighted materials to play with. In this lesson I will show you where I found all of the assets used to create the game. It might be easiest to follow along with the same assets, although it isn’t required and you are free to use whatever you want.
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!