Sokoban Garden: Android game created with Blender, Inkscape, GIMP
A new indie gamedev company Kivano Software released Sokoban Garden — a game created with just free software, such as Blender, Inkscape, GIMP, FontForge, Audacity and others.
Kivano Software is Jakub Grzesik and Izabela Latak, the programmer and the graphic designer respectively. They are young, ambitious and they seem to have a soft spot for free software. Looks like it works: the game already got Silver Medal from Playandroid.com magazine.
Work on the game started in May. It’s difficult to say exactly how much time the team spent on its development, because Jakub was also writing his master thesis, and Izabela was finishing her accounting course that she took specifically to be able to handle financial work in their future indie game dev company.
The making of Sokoban Garden is very well documented in the following video.
Let's sum it up. Blender is used for all the models, exported to OBJ for further use.
Inkscape is used for all UV textures:
As well as for all sprites:
While GIMP is used for prost-processing the sprites:
Izabela chose Inkscape and SVG for source file format for a very simple reason:
When we published our previous game (JellyBalls+), we did a lot of graphics purely in GIMP. Soon it turned out that standard phone screen resolution was rising very rapidly, and we had only our low-resolution graphics. So at some point people started to feel that our game had poor graphics.
As a matter of fact, Inkscape was also used for the game design package and tweaking letter shapes in the game's typeface which was then generated with FontForge.
As you can see from the video, the game was notably prototyped with physical models first. Izabela explains:
When I worked on a new game, I like to create small paper prototype. This is helping me to feel and understand desired atmosphere for the game. It helps me to find proper style for the game.
Finally, they also used YASC — an open source implementation of the Sokoban game for Windows. But in a quite different way:
YASC was used only as a tool. It’s very nice for creating and testing sokoban levels. Initially we were trying to design our levels on the paper. But then it became obvious, that this is very tough task (we can’t test these levels easily, sometimes we were not even sure if certain puzzles were solvable or not).
YASC is great “command center” for every experienced Sokoban fan. Thanks to this program, you can play Sokoban, design your own levels, modify them of the fly, try to make them harder, and finally you can check if your levels are solvable.
But what about producing the games? What game engine did they use? None, as it turns out.
No game engine? Really?
Another notable thing is that the team deliberately decided against using a game engine. Jakub has a point:
We wanted to develop this game entirely on a Linux machine. That is the reason why we don’t even look at professional engines like Unity, or ShiVa 3D (a ShiVa 3D port for Linux is a work in progress though).
When it comes to Blender engine, it’s not designed for mobile games (I’m not sure if there is awork in progress on that right now). I think I should also mention JMonkey engine here (if someone is trying to make their own decision).
In the end, we wanted to be sure that it will be relatively easy to publish our game for other platforms in the future. We would love to make an Ubuntu port some day.
“This libgdx library was quite easy to use,” — says Jakub — “it doesn’t impose anything, so you are not forced to do things in “one proper way”, you can experiment as much as you like and however you like”.
Did it work well enough?
Even with low-poly object the game looks and feels quite fun.
Jakub and Izabela had a lot of troubles with project management in the beginning and even tried to use Basecamp. That didn't work well. “I wanted to make some indie games” — says Izabela — “not learn how to perform good project management!”
So they tried to simplify it all and went for services like Dropbox and Google Docs. Izabela explains:
In Dropbox we create folder structure for things that are “waiting for deploy” and it’s equivalent for already realised things.
We also use Google Docs a lot. We especially like drawing functionality. Thanks to drawings and instant synchronisation we are able to discuss quickly new ideas. When it comes to code management, we are using Mercurial because of its simplicity.
As you read this, Kivano Software is working on their next game due to be released in two months. It's going to be a variation of “4 in line” with a twist, and the team is using the very same toolchain.