iGIPF — An iOS Game in 2 Weeks

Alexey Grunichev —
Apr 18, 2012

Day 2. Initial architecture.

Today there won’t be any jokes because the serious development process has started. Let’s begin on a positive note: we still have some development time left and our time milestone hasn’t passed yet. While being serious, we should look at what our current decisions are:
We will use Cocos2d as the graphical engine. The minimum target iOS version will be 4.2 or 5.0 (there are some good reasons). This decision has been made after analysis of iOS statistics for August 2011.

Initial architecture thoughts:

Model: Low Level

We thought that when it comes to AI and processing tons of data, any overhead would be multiplied by a large factor (maybe several thousand fold). As a result, we decided to write the low-level (everything that is connected with data representation and the board state) in pure C.

The two base classes are:

BoardInfo – This contains data that does not change during the whole game: board parameters: width/height, field structure, etc.

BoardState – This contains data that changes during the game: current set of pieces on board, number of pieces in reserve for both players, etc.

Our AI thoughts are based on evaluation of a large quantity of board states (for example, if we use Alpha-Beta pruning), so we absolutely need to use simple ‘memcpy’ to copy them and the fastest operations to operate with them. That’s why the data organization above and pure C were chosen.

Model: High Level

Here comes Objective-C and high-level wrappers of the two classes discussed above. AI uses low-level model only to make decisions about what is the “best move.” In all other cases, high level model objects are used (even to make the move, which was just evaluated using low-level structures only).

HexBoardGame – This class contains inner variables of type BoardInfo that do not change during the game. It also contains an inner variable of type BoardState, which is changed every turn, as well as initialization functions. Everything that is needed to create a game skeleton from board parameters (BoardInfo) and changing board states (BoardState) is also included in this class.

GipfBoardGame – This contains the specific implementation of HexBoardGame for iGipf rules. It expands HexBoardGame with such things as moves with pieces shifting (see the rules), row removal (see the rules), etc.

Controller – Structural diagram for the controller. We think everything is clear.

Views – Diagram for the views. Everything is even clearer. CCScene – is a class from Cocos2d.

Conclusion:

Enough for today. These drafts helped us to understand what we are going to implement and how to start the basic coding routine. The next interesting step will be AI experiments for which we need a proof-of-concept; but we’ll talk about that in the next part.