With our battle setup complete, now it is time to implement it with various states and display it on various screens. In this lesson we will finish implementing the first type of battle that our game will support – the capture battle. If you are successful, then you will be able to capture the wild Pokemon you encounter and add it to your team.
If you’ve been playing the game much since the previous lesson, you may have encountered a few Pokemon that you really wanted to capture. In this game, I decided to make capturing a Pokemon harder than simply throwing a Pokeball at it. You actually have to fight with the wild Pokemon to weaken it before you can capture it. Implementing combat completely is pretty involved, so in this lesson we will just do some setup work by creating a few models, factories and systems we will want to use to complete a capture battle.
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.
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.
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.
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.
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.