Separating View from Model

Very early on it was decided to separate the user interface and the logic/data of the game to enable fast simulation in perhaps level generation. So the architectural pattern known as Model View Controller (MVC) was adopted. The idea is that there is a once way dependency between the controller and model and model and view. The whole point of which is to keep things simple as the model and controller didn’t need to know anything about the view. Of course in our case, without a view simulation can be done fast.

Simple Enough

This sounds simple enough, however, just doing this would lead to horrible player experiences. If the view was updated each time the model was, the player would see each movement between adjacent square as discrete events, and each turn would seem to take forever. If the view was only updated at the resolution of each turn, it would be confusing in the case of a match that led to other matches domino-style.

It would be a problem in the reverse was as well where the player would like to see a single model update as a series of view changes. Take for example when an arrow flies across the screen, they would like to see a token only been triggered as the arrow passes through it. However, from a model update, all would disappear together.

The solution was to have two models, a true and view model. They of course would be in sync at the end of each turn. In the case of simulation, the view model would simply not be created. In the case of a token dropping down several squares, the true model would be updated for each adjacent square while in the view model, it would be conflated to one single move. The view model contains a list of discrete operations that have one or more dependencies. So for example on operation might be to create a token (like an arrow) and another step might be to move it (due to gravity) and of course, there is an obvious dependency there.

We have no idea how other coders approach this issue, there is probably no standard way. 

We had an issue when early testing the teleport mechanic, we found in some cases tokens endlessly going around and around, so we created a rule, a token can only go through each teleport once per turn.

The ability to simulate proved quite useful in early tutorial levels. It means that we could no suggest an advance piece get created when it had not been introduced yet.

Simulation

Being able to simulate each level gave us an idea of how hard each level is going to be. Particularly if it was impossible or simply too easy. It is not feasible to test each permutation obviously, so we just do a random walk that reward turns that lead to desired matches or the creation of special tokens with more walks in that direction. It is no uncommon to test over a million games to get an idea of how it might play out.

If you go this far, please feel free to download my game. Happy trails :)