Project Netsuke by OutOfTheBit

How the Stork Vector Engine came to be

A world made of Polygons

Hi Everyone,
I’m excited to introduce you to our dev blog regarding our first indie game!
My name is Alessandro Motisi and I’m OutOfTheBit founder and main developer (you can also follow me on my personal blog).

This post is all about the process that led to the creation of the engine the game runs on.

Before even conceiving the game, I had this vision of a world made of primitive polygons, with no textures and no fancy 3D lighting.
I believe Eric Chahi had a similar vision in 1989 when he started working on

Unfortunately, his style hasn’t left a strong legacy as in the early 90s 3D graphics in games started being mainstream, so we went from pixels to 3D directly.
3D graphics in games can be nice. But there is something about it that makes everything fake and often takes magic away from the game.
Many games try to look photorealistic and sometimes they succeed, but most of the time they just look like bad copy of reality.
It’s a big deception for our brains, it looks real but it doesn’t behave as we expect.
A good use of 3D has been made in games such as Mario and Zelda, where things don’t try to look real.
3D is a big hack to me, we need textures, UV Mapping and much more because our computers cannot properly simulate reality (at the moment).
I am not implying that the current 3D technologies should never be used in games or other forms of art, infact I have enjoyed many 3D games and films in my life. It’s just that I didn’t want this fake realistic 3D style for our game.

I wanted to take “the world made of polygons” vision even further than Eric Chahi could in 1989.
How? By not using even a single bitmap image, texture or even gradient to draw the game world. And, thanks to the advances of the latest mobile devices, by using more polygons and much better screen resolutions.
Such constraints (no curves, textures, gradients and shape outlines) were going to pose a true challenge to the graphic designer.
It took more than a month to find the right designer for the job, but at the end I came across Arnaud, one of the most talented and creative persons I know.
Despite complaining about those limitations from time to time he is doing an amazing job with the game graphics!

There are advantages in having those constraints though:

The game will look different from anything that’s been made before;
The engine can run really well on the powerful but limited graphic cards of mobile devices.
To me, having smooth animations and scrolling is of outmost importance. At the moment the game runs at 60 frames per second on our target devices and this gives the feeling of a “window into a new world” that we want to convey.

Vector Editor - First Version

In July 2012 I started working on our first version of the Vector Editor.
The idea was to draw all the graphic for the game directly on the iPad, using it’s multitouch capabilities.

To me vector graphics has some purity, you can zoom in and out as much as you want and it’s always perfect, no need to worry about silly textures that are never pixel perfect. What you see it’s our magic vector world, flawless at any resolutions on any device, iPhone or iPad, retina or not (on retina devices the results are pretty amazing actually).

Drawing with vectors isn’t easy though, that’s why the tool is being built working closely with Arnaud, our graphic designer. It’s a back and forth between the two of us, between Art and Technology.

The first version of the editor allowed him to draw using multitouch, but the code was far too complex for what we had to do.

I am a perfectionist and I always try to simplify the code, to make it “pretty” (any true developer will understand this feeling).
This is risky as sometimes it can lead to writing the same functionality over and over in search of perfection.

Vector Editor - Second Version

The problem with version 1.0 was that I had abstracted lots of things: I started defining an abstract C++ class called Shape, then I added the Polygon class (subclass of Shape) and Rectangle and Triangle (subclasses of Polygon). In order to aggregate shapes I then added the ShapeGroup class (subclass of Shape). Things were working but I was at the start of the project and the class hierarchy was exploding!

I decided to simplify things so I removed all those classes and replaced them with one class, called VObject (as VectorObject). Objects of this class could draw polygons of any number of points and have subobjects. To create a rectangle I just had to call the method:

Code:

initWithRectangle(float x, float y, float width, float height)

No need for separate classes, just different methods of the same class.
In addition the fact that each object could have subobjects proved quite powerful and led to a huge simplification in the Vector Editor code.

At the end of July, before leaving for my summer holiday I left this version in the capable hands of Arnaud who, thanks to dropbox support, was able to draw, import and export a great collection of vector objects that will be hopefully used in the final game.
It was exciting! Every day, after having spent a good amount of time near the seaside and having eaten every possible good sicilian food, I would grab my iPad to check on his latest creations.

When I came back from holiday I was on fire. Completely recharged, I started writing the Level Editor and the Sprite Editor, which would complement the previous (Vector) Object Editor.

The creative flow was like this: Arnaud would draw the objects in the Object Editor, then export them into the Level Editor, where those objects could be used to assemble the levels, or edited to display animations.
The cool thing about this system is that you could push the play button in the level editor and play the game straightaway!

This system had its shortcomings though. In order to build the level I had created a new abstraction, called Sprite. A Sprite would contain a Vector Object and would be able to draw it using a given transformation matrix. So to position the Vector Object on a specific point with a given scale or rotation.

A level would be a collection of sprites, drawn in a specific order.
This abstraction worked initially but then it made really hard to edit things on the fly. We had to go back and forth between the editors and I had to duplicate lots of functionality in each editor.
Things such as move to foreground, background, erase and object selection where needed in each editor.
Furthermore, there was no easy way to export, import or reuse sprites.
Something smelled in the code.

I really didn’t want to rewrite the same code three times (one for the Object Editor, one for the Level Editor and one for the Sprite/Animation Editor). So I kept thinking about the problem.
It was an obsession, my brain couldn’t stop thinking about it.
I knew there was a better way to abstract this but I couldn’t quite see it.
At the end the idea struck me.

Third time lucky - The Stork Engine

Why did we need two different concepts, the Sprite and the VObject?
Why did we need three different editors?
What if we only had one editor, which could define a hierarchy of Vector Objects?
This would simplify the code immensely and would solve many problems at once!
I decided to rewrite everything from scratch, making good use of all the lessons learnt from the previous versions.

This was a major setback because we were hoping to ship something before Christmas.

The truth was that the Christmas deadline was too ambitious for the kind of game we are building (a real time strategy game, based on custom technologies). Plus the fact that we are independent means we can ship whenever we are happy with the game, not when we are forced to (of course the flipside of this is that we may never be 100% happy with it and we’ll never ship, we’ll make sure this doesn’t happen

).

The new engine would be really flexible and it would be possible to reuse it for many games.

Since in our game the World has been created by a Giant Stork, I decided to call the new engine Stork, the mother of all worlds.
I’ve worked on Stork for the whole month of October and now that it’s almost complete I am very pleased with it.
Stork can import anything that’s been drawn with the previous editor.

Now Arnaud can draw an object and then create several instances of it (therefore save precious memory). He can also create hierarchies of objects and make animations on the same editor.
When he is done, he can push a button and play the game from the editor and if he doesn’t like something he can go back and change it immediately.

I will post further information about how Stork works and how we use it to create the game in the following weeks. Please don’t forget to follow me and Arnaud on twitter too!