Snowify

Snowify

SNOWIFY is a tool I created early 2013 that allows the user to generate thick packs of snow on any prop.
For when a simple snow shader isn’t enough.

It started of as a hobby project; I had just had to make a snow level for work (more precisely, a snowed version of an existing level), for which I had created a couple of simple snow shaders (using the angle of the surface normal to determine snowiness).
But when making that level, I found that in some cases it would have looked better if the snow had a volume, rather than being flat.
So afterwards I came up with an idea to create snow meshes based on the mesh of the object it was resting on, and started working on a tool to do that in my spare time.

Since I nowadays work primarily in the Unity3D engine, I made this tool for use in Unity.

houses with snow

The tool allows for complete control over the snow’s thickness, angle, direction, material, smoothness, and various other settings.
The snow meshes are also automatically unwrapped and textured.

jeep with snow

It’s available on the Unity Asset Store.

RocksARocksA2
RocksBRocksB2
RocksCRocksC2

Edit:

Snowify was used by Hinterland Studios for the creation of their game “The Long Dark”:
http://unity3d.com/showcase/case-stories/the-long-dark
(it’s being listed as one of their favorite packages from the Unity Asset Store)
Darkplace

Advertisements

Projection Correction

Some time ago I had to take a bunch of screenshots of the TTS VR for advertising purposes.
They needed a lot of screenshot for various formats (web banners, magazines, …),
so they tend to recrop the screenshots I send them a lot, depending on the need and space,
because of that I have to add some extra space outside of the actual screenshots, which I simply do by increasing the fov of the camera I render the screenshots with.

The thing is though, that the higher the fov, the more perspective distortion you get away from the center.
(a logical result for a projection of a 3d space onto flat plane)
This isn’t essentially a bad thing though, it’s actually correct, if the image is viewed from straight in front of the center, and at the right distance, so it’s looked at with the same angular size as the image was made (the fov).

The problem, is that these screenshots sometimes get cropped in extreme ways, by which I mean, far to one side, moving focus away from the center.
This causes the image to look strange, as the content is skewed and stretched.

So I decided to make something to counter that.

I figured that if the 2d space that was projected on was a spherical shell instead of a flat plane, there would be no distortion.
A spherical shell however can not be mapped to a flat plane without distortion (obviously, just look at maps of the earth),
but, a cylindrical shell totally can.

So, using math and logic (whoo) I created a post effect that manipulates the image as if it was projected on a cylinder (with either a horizontal or a vertical axis), and then unfolded.

This way it can make sure there is no distortion either horizontally, or vertically, depending on whether the image is in landscape or portrait.
Because of this, you can move focus in this direction (horizontal or vertical), without it looking off.
A side effect of this is that you can easily stitch together screenshots made by rotating around the cylinder-axis.

rendered with projection correctionAn extreme example, the horizontal fov is more than 200 degrees, this isn’t even possible with normal rendering (only <180 degrees).

FullCorrection

There are a few setbacks however,
firstly, unlike normally (projecting on a flat plane), not all straight lines (in 3D) are straight in the image, some are curved,
secondly, a lot of space is wasted in the image (the black parts), because of the extra cylinder-mapping, which means you have to render at a higher resolution for the same detail.
and lastly (and definately least), there is no filtering done in the cylinder-mapping, so the result can be a bit jaggy (and moreso the bigger the fov is).

I also made a second mode, which is a bit simpler and less extreme,
as it only streches 1 of the axes, just so proportions look correcter. This one is actually more difficult to explain, just look at the pictures.

SimpleCorrection

I’ve made this post effect available for free on the Unity Asset Store:

https://www.assetstore.unity3d.com/#/content/9882

It requires a Unity Pro license in order to work though.

Tacx Trainer Software Virtual Reality

I’ve worked for a little over 3 years now on the Virtual Reality part of the Tacx Trainer Software.

The Tacx Trainer Software (TTS) is software for riding training sessions on a Tacx bicycle trainer, for amateur and professional cyclists.
The Virtual Reality (VR) lets you ride in virtual worlds; terrain, slope and wind info is send to the bicycle trainer, for a realistic riding experience.

For the most part I was the only artist. So I pretty much made every level on my own from scratch.
(That includes the level design, placement, lighting, particle systems, …, and creating almost all off the props)

Initially we started development using GameBryo, but halfway through production, we switched over to Unity3D.

Here are some screenshots from various levels:



Downhill Valley, the first level made in Unity. Most of the vegetation was painted on the terrain, rather than placed individually (unlike the Mediteranian level)
.



Valeggio, half of the Mediteranian/Italy level, the first level I made. Originally made in GameBryo’s Lightspeed.



Metropolitan, Originally started with a (very basic) 3th party city-pack, but only a part of the street layout and basic buildings remain, as most of the textures and UV’s are completely replaced or redone. The smaller props, like the traffic lights, and the entire park were made by me. (Allthough the park also contains a couple of standard Unity3D trees).

While the orginal male and female cyclist models aren’t made by me, I did make almost all the cyclist outfits (shirts+pants, not the glasses, helmets and shoes), and redid the UV-layout to better fit these dozens of outfits, and created the necessary maps for changing the skin and hair color (and for some outfits, the outfit colors).

 

I also made all the bikes (currently 3 types), which also have customisable colors.

MTB Track Race MTBb Trackb Raceb

More screenshots can be found on Flickr.

Edit:
For more info on a more recent level (summer 2014), check here.
Golden Circle Level

The power of blend maps (or whatever they’re called)

First off, I don’t actually know whether it’s called a blendmap, that’s just what I call it,
what I mean is a grayscale texture that is used to dynamically blend 2 images.

in it’s simplest form, a single numerical value defines the clipping value; for each pixel of the blendmap, if the luminosity is higher than the clipping value image1 is used, otherwise it’s image2.
Most often though, I don’t want a hard cut like that, so instead I use 1 value that roughly determines how much of image1 to use (_BlendAmount), and 1 value that defines the sharpness of the transition (_EdgeSharpness).
Which looks something like this:

float blend = blendColor + (_BlendAmount * 2 – 1);
blend = saturate(blend * _EdgeSharpness – (_EdgeSharpness – 1) * 0.5f);
result = lerp(color1, color2, blend);

Now this might not seem like much, in fact it’s pretty much just an alphamap.
But it’s strenght comes from the fact that it’s great for dynamic transitions from one image to another, in time and/or space, and that’s usefull for a lot of things.
And it’s quite simple and cheap, which is also a good thing.

For example, I used this to make a snow material, that would blend in snow with the diffuse texture, based on the surface normal, using the blendmap in the snow’s alpha channel.
And for fading HUD overlays (like the Frost Effect, and blood splatter when taking damage).

Usage in games

The first time I came into contact with this technique, was when I saw the snow in Uncharted 2 (on the internet, I never actually played the game).
They seem to be using blendmaps for the transition between snow and ground/rocks. (which gave me the idea to make a snow material)

And I believe a lot of games also use blendmaps in general for transition between terrain textures, which looks a lot better than the default fading.
(Which should actually be a little more complex, as it’s not just blending 2 textures, but any number)

But the weird thing is that I can’t seem to find anything about it, I mean, actual documentation (or just even how it’s called),
but maybe that’s just cause I’m terrible at finding things on the internet.

Shoot ‘Em Up! (experimental flash game)

gameIcon

I never play much casual or web based games,
but I do visit Kongregate every so often (though it has been a while),
because they tend to have more original games than the average flash games site.
(or atleast they used to)

I also made some small games available there, mostly fairly rough, not-quite-finished games, like Warmada for example.
But an other one is Shoot ‘Em Up, which this post is obviously about.

One thing I liked about making games for use on Kongregate, are the APIs.
(To be honest though, I’ve never uploaded my games anywhere else, so I don’t know what it’s like on other sites)

One of the APIs is the “Shared Content API”, which allowed users to save content they made in a game, and let others load it.
Mostly used for sharing save games and creating custom levels.

But I started thinking of ways to use the API for more direct gameplay mechanics, for creating a more cooperative gaming experience.

The Concept

I got the idea to make a 2 player co-op game, where instead of 2 players playing simultaniously, only 1 player playes at a time, and the other is a recorded run of someone else.
And after finishing a level, the player could then save his run, and share it with others so they could then play co-op with it.

The idea was to see if this concept could allow for a new interesting experience, given the advantages and disadvantages that come with it.
The main advantages beeing that it allowed players to play together without having to play at the same time, and that any single run could be used for any number of different players, both friends and strangers.
(and smaller advantages beeing the impossibility of there beeing server or connection problems)

ShootEmpUp_small

Since it was gonna be an experiment, I decided it should be a fairly simple game, not too big and easily accessible.
A 2D Shoot-em-up with pixel graphics seemed to be a good chose, as that’s one of the more easy games to make (seeing as how Warmada was made quite fast).

Well that turned out quite differently.

seu2 seu3 seu4 seu14

The Development

I liked making different ennemies, bosses and weapons too much, so it caused me to make the game at lot bigger and complexer than originally planned.
The graphics style was indeed fairly easy to make, but that only caused me to make more and more content.
Other than that, it also proved very difficult to explain the game mechanics in simple and clear ways to the player.

I wanted to emphasise the co-op element of the game, so I tried to make it really about cooperation.
I didn’t want it to be just 2 players shooting trough enemy waves, ignoring each other, I wanted them to help each other and work together.
Now how do you do that when 1 of them is a predetermined recorded run?

Well the biggest ellement I added for that purpose was the gates and gate switches;
some levels where devided in 2 parts, 1 for each player, with gates blocking their paths and gate switches that opened the gate when shot, but the key beeing that the switches for Player1’s gates where in Player2’s part and vica versa.

Gates Gates2

And another was a weapon, the helix cannon.
It shoots a beam of red and blue particles, that can move through walls, in a sin-like wave.
But when both players had this weapon equipped, their beams would be drawn towards and spiral around each other. Beacuse of this the players really had to keep track of each other and act in accordance.

helix1 helix2 helix3 helix6 helix7

The Problems

Having one player beeing completely predetermined causes some issues ofcourse, I anticipated this, but the gravity of it was still much bigger than expected.

Simply put, everything that makes a playthrough different from the playthrough of the recorded run, can cause the recorded player to behave illogically.

For one, this means nothing should happen, even partially, at random. Everything must happen exactly the same each time (except for the active player), otherwise the recorded run would make no sense.
And all the enemies that target a player, always have to target either player1 or player2, they can’t change this based on whoever is closest, cause this would further differentiate it from the recorded run, this unfortunately limits the enemy behaviour.
An issue that can’t be helped, is that when the active player kills an enemy (that wasn’t killed in the recorded version), the recorded player might still try to shoot it down,
and worse, when the active player fails to kill en enemy fast enough (that was killed in the recorded version), the recorded player might fly into it (causing massive damage to the player).

The designs of the levels, and the gates and gate switches, had to be severly simplified,
because originally there where gate switches that both closed gates and opened others, but the problem with this was that it could cause the recorded player to fly straight into a gate, killing him instantly.
And the gate HAS to kill him instantly, as it is a recorded run, and so the only alternative would be making him fly through the gate.

The Result

All in all, I like how the game ended up, though I do not consider it a succes.
The concept has it’s plus sides, but IMO they don’t really outweight the downsides.

The problem basically comes down this:
It’s supposed to be a cooperative game, and that really requires interaction between the 2 players,
but there can’t be interaction when one is prerecorded, there can only be reaction.

It was an experiment, and although it wasn’t a great succes, an experiment is only a failure when you fail to learn from it.

seu5 seu7 seu15 seu23 seu20 seu21 seu22 seu16

You can play the game here:

http://www.kongregate.com/games/Stef1987/shoot-em-up

But make sure to read the instructions before you start.

You can only save your run and share it when you have a Kongregate account (don’t worry, it’s free)