On the Farm: Making SokoFarm

Since we now had a fully working framework, it was time to start paying attention to the game itself. Before we could realistically get objects in and moving about, or to even start to think about actual game-play logic; we needed to create an environment for all of these things to exist in. Like many games of this nature, SokoFarm is effectively tile based, unlike the mock-ups everything is constructed with 3D meshes not 2D sprites making what is usually a simple task into something slightly more complex. The 3D assets would require buffering, positioning, rotating, scaling and welding so that the composite mesh could be converted into the appropriate material and instance lists required for rendering.

Another little quirk of the environment builder involved the actual level designs themselves, rather than having to define each tile index for the fences/walls in the level tile-map, the design only held references for what was ground, barriers and dynamic objects – this would be a much faster and more flexible way of working allowing for the designs to be skinned in whatever appearance we wanted, something that would be needed as the game had graphical seasons, the downside naturally was that functionality had to be coded to auto-generate the correct tile indexes for each tile in the map. Not a complex task, but often a fiddly and laborious one as the game would need many tiles to create interesting layouts convincingly.

After some work to improve stability and performance, the basic environment creation was there and robust, the games levels would still need layers of decoration applied, but that would come later, for now, the paths, barriers and surrounding grass were all in place and not looking too bad for a first pass all things considered. The next step would be the dynamic objects, a reasonably easy matter as everything needed to define and spawn such things had already been done to create the maps, and all that was needed was to add the concept of such things to the map parser.

The player, nest and birds objects all went in very smoothly without any real issues and were on-screen quickly, abet without any actual logic in them, there were at this point purely static game objects. They also didn’t quite look as they do in the finished game, the player was a box, the birds a sphere and the nests were closer in appearance to squashed doughnuts than anything else. Odd looking, but this is how most games start as the code often leads the art at this stage, it’s not pretty, but it does allow for the games functionality to be created and worked up.

Now that we had an environment being built from proper map designs and the ability to create all of the game objects the design called for and positioned correctly, the code-base was starting to resemble an actual game. The next steps would involve adding the logic for the objects and rulesets to turn everything into something that could be played, won or lost.