Now that we can move around the board, we should start adding the activities related to that journey. The first thing I want to include is the random encounter. This is where a player encounters a wild Pokemon, which can be potentially captured and used as an ally. In this first part, we will simply handle the systems necessary for spawning them and displaying a new screen when they appear.
Unofficial Pokemon Board Game – Board
It’s a little funny that we’ve come so far into a series on making a board game and still haven’t even looked at the game board. In this lesson we will fix that. In addition, we’ll make some pawns, and actually implement the ability to “roll” and move your pawn around the board on your turn.
Unofficial Pokemon Board Game – Transitions
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.
Accessibility For Blind Users
I have recently been tasked with the implementation of accessibility related to blindness on a few different iOS projects. There is a lot of documentation on this already, but finding it all in one place and getting a “quick” overview of the basic idea were a bit harder to find. Following are the notes I made for myself as well as some tips and gotchas that others might benefit from.
Unofficial Pokemon Board Game – Setup Screens
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.
Unofficial Pokemon Board Game – Data Models
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.
Unofficial Pokemon Board Game – Data Controller
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.
Unofficial Pokemon Board Game – Title Screen
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.
Unofficial Pokemon Board Game – Flow Control
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.
Unofficial Pokemon Board Game – ECS
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.