Worn Edges

Worn Edges

WORN EDGES is a tool I created in 2013 that allows the user to generate a worn look (amongst other things) for their props. It is written as a Unity3D editor extension (as such it only works within unity).
I wrote a small post on it when it was early in development, you can see it here.

Tori, before and after using the WORN EDGES tool

It works by generating a lot of different maps, which get combined into a single “combined map”, which details the level of wornness for each pixel of the texture. This combined map is in turn used to alter the original, clean, texture.

a simple example of the principle
a simple example of the principle

The tool can create a lot of different maps:

  • 3d, 2d and 1d noise map
  • sharpness map
  • ambient occlusion map
  • directional occlusion map
  • angle falloff map
  • distance map
  • wood map
  • mask map

How these maps are created and combined is fully customizable, to create the effect the user desires.
As such, it can create more than just a worn edges look (see screenshot below).
tikis with different maps

In general, for just a worn edges look, only the 3d noise, ambient occlusion and sharpness maps are used. The other maps are generally for more specific effects (see screenshot above).

The models this tool is used on should have a clean UV layout, without overlapping triangles (although symmetrical or otherwise identical geometry can often share uv-space without a problem). But it can also bake everything to a 2nd set of UVs, for example the auto-generated lightmap UVs (that is often used in Unity3D). As such you can actually also use this to bake multiple textures with overlapping UVs into a single texture that uses these 2nd UVs.

wooden - worn edges
ball_variations 2_ballDevelopment
worn (edges) (worn) edges

It’s available on the Unity Asset Store.

Here’s a relatively recent (at the time of writing) demonstration movie:

and here’s an older demonstration (a bit outdated, but still relevant):
(Unfortunately though, it is kind of slow)

Golden Circle Level

The GoldenCircle Level is the newest for the Tacx Trainer Software Virtual Reality (see my previous post on this software here). It’s the biggest yet, containing more than 40 km of road, in a region of 4 x 4 km.

The level has an oriental theme, and consists of extremely varied Chinese and Japanese scenery.

I created the full Golden Circle Level, the bulk of the work was done in Spring and Summer of 2014.

GoldenCircle
GoldenCircle
GoldenCircle
GoldenCircle GoldenCircle
GoldenCircle
GoldenCircle GoldenCircle
GoldenCircle GoldenCircle GoldenCircle
GoldenCircle GoldenCircle GoldenCircle
GoldenCircle

More screenshots can be found on Flickr.

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

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)