Bringing things to life: Making SokoFarm

With all projects, there’s a point where things go from being a code-base to a game you can play. It’s normally quite early in the project and it’s when you start to see what you’ve got, if things work the way you thought they might, is it good; is it even fun? With Sokofarm, this happened unsurprisingly when we began putting the logic into the game objects. This process kicked off with getting the player moving about, for obvious reasons the game is grid locked, game objects move from grid point to grid point, to stop the game feeling rigid this had to be done seamlessly so as to hide the grid snap from the player as much as possible. That was mostly achieved by allowing the player to change direction while close to a grid point rather than waiting for the player object to actually reach that position. Blending between directions of travel also complimented this and smoothed the movement out making the games controls feel fluid and responsive in the process.

As we were making a Sokoban, the next thing to be worked up was for those Chonky Chickens in need of a push to get the code to receive that push. While not really that complex, interactions between objects is usually where a healthy supply of bugs can originate, and to no one’s surprise, pushing the birds around initially produced some amusing effects such as the birds bouncing around like beach balls, being stuck on the player object, or, shooting off into the air like a rocket as soon as they were touched – after a small amount of head scratching however, the birds were rolling around and behaving as expected, we had something that was starting to feel like a game.

In order to take something that was starting to feel like a game to something that was actually a game, the ruleset logic had to be coded. This also meant that the games start and finish sequences and associated interfaces were required, again something that really added to the feel of things. Like many games, the logic that runs the ruleset works in a fashion that would outwardly appear back to front, but kept complexity away from the birds, the nests listened for a bird being placed into it, rather than the birds listening for the nests. Doing things in this fashion avoided a rich source of bugs with the birds missing nests, or the game thinking birds were nested when they weren’t due to internal state issues within the birds, having made Sokoban before, it’s one of the little things you know to do differently next time. Once that was working, it was a simple matter to get the game-state object asking if there were any empty nests to check for a puzzle being completed.

To give the game a little more depth, we also included a move count for the players’ actions, and a move limit for each puzzle meaning that the player can actually fail a puzzle by using too many moves. A move would turn out to be defined by the player either turning, stopping or hitting a barrier, sounds obvious but we did try a couple of different ideas for this, but this approach turned out to be the easiest to quickly explain to a player and as such, the most practical. Failing a puzzle presented the player with an unhappy version of the success sun, while these were still at that point placeholder graphics, it worked really well and balanced things out nicely. We now had a playable game!