Posts Tagged ‘vzero_omake’

Warning: Something eat you !!!

Posted by (twitter: @molecats)
Thursday, December 18th, 2014 12:27 pm


ENTRY | Postmortem | All Making-of Posts

Hi there! We continue our Visibility Zero making-of posts. Now we will talk about “Something” :)

We have a few environment enemy:

  • Hot Lava Spots
  • Deadly Pitfalls
  • Mysterious Creature Swarm

If talk about Lava Spots and Pitfalls it’s simple mechanics, sphere collider and below Y-cord Instant Death.

So we’ll talk about Mysterious Creature Swarm. In our game we wanted to add something mysterious to killing you, but it should not be instant death was, but rather slow.

And we came up with to use a system of particles Boids. You do not see it at first but if you walk they will eat like piranhas but slowly.




Boids Algorithm based on

flocking in nature


So each Creature is affected by 3 base forses:

  • cohesion
  • separation + collisionAvoidance
  • alignmentForce

But for our game we also add Powerful Force is Player, *** SPOLER *** so when player not near Green Stellar they attack him *** SPOLER ***.


1000 particles – boids

You can find in internet many cool examples how to create and use boids and draw in one Unity draw call, do many Meshes and update it.

This simple idea add awesome experience when people die trying escape from Something and fall into Pitfalls


Play and Rate

Visibility Zero Making-of Part 2: the Environment

Posted by (twitter: @molecats)
Wednesday, December 17th, 2014 4:18 am



ENTRY | Postmortem | All Making-of Posts

Hi there! We continue our Visibility Zero making-of posts. The 2nd one will be about environment assets.

As I’ve already said in the previous article, due to limitations of what is seen on the screen in various modes we had an opportunity to use very simple assets for the environment, still maintaining a nice visual presentation at the same time.

I will start from the list of common rules for the assets, which have helped us to quickly compose the environment almost without worrying about performance:

  1. Lowpoly speed modelling with almost automatic smoothing group assignment (by angle, with minor manual tweaks) to easily receive properly triangulated models for “papercraft” feel.noise
  2. Automatic unwrap, no texture baking, no texture painting.
  3. Simple noise with a very small tiling is used as a texture.
  4. Very simple materials & shaders (except the ones we use for “glowing” objects).
  5. No global lightning & shadows in the scene (we only use red point lights near “HOT” objects).
  6. We don’t really like Unity’s standard terrain (cause it’s not very flexible), but for this project it was just perfect: we haven’t used any textures at all because the player has almost no chance to see them.

As for example assets, I will start with our Planet Rover (just for looks on the frontpage, you know=)):

rover_make (more…)

Visibility Zero Making-of Part 1: the Device

Posted by (twitter: @molecats)
Tuesday, December 16th, 2014 6:44 am


ENTRY | Postmortem | All Making-of Posts

Hi! As promised in our postmortem, we will do several Visibility Zero making-of posts this week, starting with this one. You will find all the posts under the tag vzero_omake.

My name is Stas and I’m an artist / designer in our team. The first post is about the visual side, so I’m the one who will narrate.

As soon as we’ve decided to do the idea with “a screen device with various visibility modes toggle”, I’ve started a visual style research. “The Device” is the central & the most important part of the game. It is always before the player’s eyes. It is an UI and a gameplay mechanic at the same time. As the player doesn’t really see a gameworld without the Device and as there is serious limitations of what is seen on the screen in various modes, then we have an opportunity to simplify the scene assets. Thus we have more time to make the Device itself.


Visibility Zero Postmortem

Posted by (twitter: @molecats)
Friday, December 12th, 2014 2:26 pm


Visibility Zero Game Entry


In this Ludum dare we are two individuals staying on the edge of the crater (two different craters actually, on different planets)… ohh sorry let’s backtrack to Ludum Dare postmortem.

Yaroslav = code / design
Stas = art / design

Both are working on the main project : Molecats ( an indirect-control tile-twisting puzzled adventure …with traps!


Theme & Idea

We’ve spent 8 hours just to generate the final idea and for us that was the biggest challenge because we must create and finish game in so short time period.
In that 8 hours we’ve generated over a dozen ideas. Here is the list:

We didn’t like to approach the theme as a “technical limitation” as the main our goal was to reflect it through gameplay.  So, we’ve chosen an idea with a special screen device that helps to survive in very bad conditions.


What’s gone right:

  1. Actually finished build in 72h. It’s a helluva achievement for our team. Although we’ve done fast prototyping before, it was not even close to the finished product of this scale. For example, the result of our first try to jam – Mars Commando was much more simpler and it took a week after the initial 72h to make it work as a game. And then another 2 months to polish it.
  2. Nice visual presentation.
  3. Nailed the atmosphere and the feel of “blindness”, forced dependence of the screen device.
  4. Gameplay seems to be “a bit” slow and vague, but it turned out to be very close to what we really wanted.


What’s gone wrong:

  1. Unexpected & non-trivial theme for interpretation – took too long to brainstorm the idea on the 1st night = sleep time shifted, less actual working.
  2. We are usually very picky when it comes to visuals, so we’ve spent a little bit more time to figure out the artistic style than needed. At first, we wanted to make the screen device and character’s hands in 2d, like it was done in old FPS’s. But after a few tests we have dropped the idea, because it became clear that we didn’t have time to make it as good as we wanted. 3D lowpoly is usually easier for us to do, but we feel a bit disappointed that we had to drop the initial style.
  3. Standard Unity3D FPS controller is… just works. We haven’t even thought about expanding it or trying to find an alternative due time shortage, so we’ve faced some collision & control problems in the final build.
  4. Not much time left to do playtesting = level design could be better and a learning curve could be smoother.
  5. We have totally forgotten about time for music and sound fx – so we have had to do make/implement them literally in 30 mins before submission=).


What’s next?

We will make a few more detailed “making of” posts, so stay tuned! Thank you for playing and voting!





Play and Rate




[cache: storing page]