Welcome, Guest. Please login or register.

Login with username, password and session length

Advanced search

1411455 Posts in 69368 Topics- by 58422 Members - Latest Member: daffodil_dev

April 21, 2024, 10:46:58 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsProject Netsuke by OutOfTheBit
Pages: [1]
Author Topic: Project Netsuke by OutOfTheBit  (Read 4222 times)
Level 0

View Profile WWW
« on: November 05, 2012, 01:05:13 PM »

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! Smiley
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:

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 Smiley ).

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!
Level 10

View Profile WWW
« Reply #1 on: November 05, 2012, 01:17:54 PM »

Looks amazing! Kiss

Thank you for posting this and for going into so much detail, always interesting for us programmers. Smiley
Level 5


View Profile WWW
« Reply #2 on: November 05, 2012, 01:21:09 PM »

Wow, I love the minimalistic style!
If you add a subtle paper texture as an overlay you can get a really nice effect, like papercraft Smiley

Level 10


View Profile WWW
« Reply #3 on: November 05, 2012, 01:30:34 PM »

is this going to be released to the public (the tools)?
is this restricted to isometric rendering?
is it restricted to ipad?

subsystems   subsystems   subsystems
Level 0

View Profile
« Reply #4 on: November 05, 2012, 02:17:03 PM »

Very interesting read. The art style is amazing!
Level 5

View Profile
« Reply #5 on: November 06, 2012, 02:39:58 AM »

This looks very interesting. I'll be sure to keep an eye on this.

Also, I believe I have seen Arnaud's work somewhere before. Maybe at Deviantart? Dribble? Both?
Level 0

View Profile WWW
« Reply #6 on: November 06, 2012, 06:03:31 AM »

Thanks green, Drevlin, Seiseki and happymonster. It means a lot to us since we are spending months on this!

We've thought about paper texture as well and tried it as an overlay but didn't work very well with moving objects, we might give it another try using a different technique for the next game though.

@moi (great questions!)
We would love to release the tools to the public but it's too early for that as all our resources are targeted to completing our first game.
The tool itself it's not restricted to isometric drawing and can handle any 2d polygon drawing (we will post some video about this in a future post).
The game will be iOS only initially but we plan on supporting other platform in the future.
Harry Harrison
Level 0


View Profile WWW
« Reply #7 on: November 10, 2012, 12:48:15 AM »


Level 1

View Profile WWW
« Reply #8 on: November 10, 2012, 01:03:31 AM »

 Kiss WooooooooooooooooooooooooooooooooooooooooooooW Smiley that's look super amazing can't wait to see the game in action Smiley

Level 3

Eat this!

View Profile WWW
« Reply #9 on: November 10, 2012, 05:41:01 PM »

As I said before, vector art style is my favourite so I can't be more excited about this!
I hope you find the time to release a version of the vector editor for the iPad. Would be awesome to try!

Level 0

View Profile WWW
« Reply #10 on: December 04, 2012, 07:25:43 AM »

Stork - Isometric Obstacles

Now that we can draw, import and export vector sprites with Stork we have finally started focusing on the game!
One of the first problems we faced was handling collisions between players and foreground objects.

about how we use Stork to create isometric obstacles. The video is made of 3 steps:

Step 1 - Draw the obstacle

I draw a cube in front of the player and make it a new sprite.

Step 2 - Draw the Collision Mask

I make use of the sprite hierarchy to draw the Collision Mask within the obstacle.
This is needed as we want the player to stop only if the base of the cube is hit, not the top.

Step 3 - Draw the Transparency Mask

When the player is behind the obstacle the game engine should draw the player and then the collision object (in order). Since for our gameplay we do not want players to get lost behind objects, we’ve decided to show both the player and the collision object with 50% of transparency when a player is behind an obstacle.

I draw the Transparency Mask to let the game engine know when a player should be displayed behind an object (i.e. both objects will be drawn with 50% transparency for this game).


Any isometric world rendered with a 2D engine will pose problems on how to handle obstacles and collisions properly. So far, we’ve managed to solve those problems by using a Collision Mask and a Transparency Mask associated with any obstacle.

If you are facing those problems for the first time, this post might give you some idea. If you have already solved those using different techniques, I would love to hear them!

I plan to add further posts as development progresses, please follow me on twitter (@alimotisi) if you are interested.
Pages: [1]
Jump to:  

Theme orange-lt created by panic