As an example: we could use alpha (transparency) to show cloud fraction (0 to 1 corresponding to clear to opaque), with color being temperature and size indicating wind speed.

Technical stuff: I used volumetric perlin noise and a procedural particle system simulation. The whole thing is around 20,000 particles, and takes around 3 ms a frame to render, so it theoretically renders at around 350 frames per second. It scales up pretty linearly, so the theoretical max would probably be on the order of 200,000 particles. That’s actually not that much – to show a single time step of our FIM model, at G5 resolution (60 km global resolution, the lowest resolution it can run), would require around 3.2 million particles.

Check out the video below for a quick demonstration.

UPDATE: Here’s a video of the same basic idea showing sample fish data as it would be captured by a ship with multibeam sonar. The boat model at the top is the underside of the Okeanos Explorer.

If you’re curious, the basic idea for this visualization came from a paper written about a decade ago, called 3D visualization for pelagic fisheries research and assessment. I wanted to take a crack at it with updated technology to show folks around NOAA (like the Marine Fisheries Service and Ocean Service). Even though oceans are very much 3 dimensional systems, so much of how we work with them is through 2D maps or cross sections.

Here’s a sample video from the course that I taught on game design in the fall of 2012.

This video is from fairly late in the semester, so it assumes that you know a little something about 3D meshes and what ‘procedural generation’ means with video game design: editing objects with code, at runtime, rather than by hand, beforehand. I have to caution that it’s fairly technical, but there’s some good eye candy (especially in the second half), and a lot of good information about how to create and edit meshes from scripts.

I hope that this helps you in your own game designs!

Vertex Color shader: http://wiki.unity3d.com/index.php/VertexColor

Calculating tangents automatically: http://answers.unity3d.com/questions/7789/calculating-tangents-vector4.html

The normals visualizer code is below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

using UnityEngine;
 
//Written by Julien Lynge at Fragile Earth Studios, 2012
public class ShowNormals : MonoBehaviour {
 
    void OnDrawGizmos()
    {
        Mesh mesh = gameObject.GetComponent().sharedMesh;
        Vector3[] normals = mesh.normals;
        Vector3[] verts = mesh.vertices;
        for (int i = 0; i < normals.Length; i++)
        {
            Vector3 normal = normals[i];
            Gizmos.color = new Color(0.5f + normal.x * 0.5f, 0.5f + normal.y * 0.5f, 0.5f + normal.z * 0.5f);
            Gizmos.DrawRay(transform.position + verts[i], normal * .3f);
        }
    }
}

That being said, in most cases you should be fine reproducing the exterior of a building in your game, provided that the building is visible from a public area, meaning you wouldn’t have to trespass to view the parts of the building that appear in your game. The relevant section of law you want to be aware of is this:

Copyright Code, Title 17, Circular 92, § 120 . Scope of exclusive rights in architectural works

(a) Pictorial Representations Permitted.—The copyright in an architectural work that has been constructed does not include the right to prevent the making, distributing, or public display of pictures, paintings, photographs, or other pictorial representations of the work, if the building in which the work is embodied is located in or ordinarily visible from a public place.

HOWEVER, there are a number of caveats that can limit your right to use likenesses of buildings. A couple of them are below, but there are potentially others based on where you are and what you want to reproduce.

You cannot use copyrighted artwork in your games (or anywhere else) without the written permission of the copyright holder. This includes artwork on or near buildings, for instance sculptures. Check out this article for more information.

Again, you have to have permission to use names, logos, slogans, and anything else that’s trademarked, copyrighted, or otherwise restricted. This is something to be careful with when using photographs as building textures or buying models from 3rd parties. Typically game creators get around this by creating their own brands, store chains, etc. that evoke real-world companies. Parody and satirical use of real-world names and trademarks may be protected in some cases, but just because something is parody doesn’t automatically mean you won’t get sued.

There are some special restrictions when it comes to federal buildings – here’s a brief outline of the law from the governments General Services Administraction:

Except where security regulations, rules, orders, or directives apply or a Federal court order or rule prohibits it, persons entering in or on Federal property may take photographs of -

(a) Space occupied by a tenant agency for non-commercial purposes only with the permission of the occupying agency concerned;

(b) Space occupied by a tenant agency for commercial purposes only with written permission of an authorized official of the occupying agency concerned; and

(c) Building entrances, lobbies, foyers, corridors, or auditoriums for news purposes.

All the exceptions may be a bit daunting, but it’s usually perfectly fine to use a public building or landmark in your game. Just be sure you understand the basics of copyright and fair use, and do a bit of research if you have any doubts.

Every year, we bring students in from nearby schools and give them a tour of the work we’re doing at NOAA. The kids have a good time, and we try to stuff them full of environmental science and wonder about the world around them.

This year, the group I work for (the Technology Outreach Branch, or TOB) did two stops along the tour:

All in all, a good time was had, and we got a lot of good questions from the youngsters. Definitely looking forward to doing it again next year!

(Image credits: Will Von Dauster – http://vondauster.com/Grade8/index_2.html)

This is most likely just the first of many posts I’ll write on the MDA, or Mechanics-Dynamics-Aesthetics, framework.

MDA isn’t a method or set of rules for designing games. It’s a way of breaking down game design into discrete parts, and looking at how those parts interact. The end goal is to help developers go from mechanics (how the game works) all the way to aesthetics (how the player experiences the game). By doing so, developers can focus on creating a game that is engaging for the player on multiple emotional levels.

The original paper exploring MDA was put together by Robin Hunicke, Marc LeBlanc, and Robert Zubek; today, ideas from MDA are widely discussed in the gaming industry.

MDA can be broken down as follows:

• Mechanics are the formal rules of the game. The agents, objects, elements and their relationships in the game. They define the game as a rule-based system, specifying what there is, how everything behaves, and how the player can interact with the gameworld.
• Dynamics are the emergent behavior that arises from gameplay, when the Mechanics are put into use.
• Aesthetics are the emotional response from the players to the gameplay.

Take Monopoly, for example. The mechanics are the relationship between the board, the pieces, and the rules. Everything you need to play, and the rules specifying how you play. The dynamics are the processes and behaviors that arise when you actually play the game. During the beginning of the game, everybody starts equal, but sooner or later one player will get richer than the rest, and sooner or later the other players are driven into poverty and will lose the game. The aesthetics are the feeling of tension and joy in the beginning, the gradual loss of interest for the losing players and the joy of winning for the winner.
You can analyze the mechanics by looking at or reading about the game. You can feel the aesthetics when playing the game. And you can discover the dynamics when playing and analyzing how gameplay evolves over various play sessions.

A lot can be said about each of these three aspects, so let’s take a look at each in a little more detail. The Penny-Arcade website Extra Credits has a decent treatment of MDA, so I’ve linked to a couple videos there. To get you as many different viewpoints and ideas as possible, I’ve also included some excerpts from articles and books.

Mechanics are the rules of the game, and are what the game designer has the most control over, and interacts with most often. However, they are furthest away from the end user experience – the end user interacts with the game on an aesthetic level. So,

from the designer’s’ perspective, the mechanics give rise to dynamic system behavior, which in turn leads to particular aesthetic experiences. From the player’s’ perspective, aesthetics set the tone, which is born out in observable dynamics and eventually, operable mechanics.

Mechanics by their nature cause certain dynamics, which in turn affect the user experience. For instance,

In a First-Person Shooter video game, a common theme is for players to have “spawn points” – dedicated places on the map where they re-appear after getting killed. Spawn points are a mechanic. This leads to the dynamic where a player may sit next to a spawn point and immediately kill anyone as soon as they respawn. And lastly, the aesthetics would likely be frustration at the prospect of coming back into play only to be killed again immediately.

So what can you do with mechanics to make a great game? Extra Credits has something to say about it:

Video: Mechanics as Metaphor

Link to Loneliness: http://www.necessarygames.com/my-games/loneliness/flash

From an interview with Marc LeBlanc at Gamasutra

What about the D in MDA — dynamics? “[It's] the behavior of the game as a system — what happens when you play? How can we predict what happens when you play and how can we explain what happened when you played? Game dynamics is about predicting and explaining.”
He gave as an example a feedback system, such as a thermostat that turns on a heater or cooler based on room temperature. “A lot of racing games have a system [like this], like a speed boost for the guy who’s losing.” He added, “The player is part of the system too, so some of our understanding of game dynamics has to be an understanding of human dynamics.”
Understanding Mechanics
LeBlanc said, “There’s a vast library of game mechanics that get used and re-used over again. Shooters have the same kinds of vocabulary elements — spawn points, hit points, ammunition, and the rocket launcher at this point is a common mechanical meme — it has a low fire rate, a big blast rate, and fires slow and straight. They all have that now.”
Moving on from that example to the macro-scale of game design mechanics, “Not only are these the vocabulary the designer is using to build the game, it’s also the vocabulary he is using to communicate with the player. If you were making a golf game and you put a sand trap, people would know what it means. But if you put a big pile of sand in the middle, not in a hole, it would be confusing to a golfer.”
Mechanics vs. Dynamics
“There’s a gray area between the notions of mechanics and dynamics. Mechanics concerns with the direct consequences of the rules, whereas dynamics concerns itself with the emergent consequences of the rules.” To illustrate this contrast, LeBlanc offered this simple example: “In baseball, you have to run the bases counterclockwise. In hockey there’s no rule that says you have to skate backwards, but if you’re playing defense, it’s a good idea… it’s an emergent behavior that arises from the rules of hockey. Dynamics emerge from mechanics.”

In summation, according to LeBlanc, MDA is “what we know about these things and how they interact.”

And and exerpt from the book Brave NUI World:

When users engage a game [...], their actions vis-à-vis the game [...] constitute dynamics. For example, when players play chess, the movement of the pieces constitutes dynamics. While the mechanics of chess are fixed, the dynamics vary within a range. Players can make only “legal” moves. Conditions of victory are pre-set. However, the players’ behavior is not completely determined. Players bring their own knowledge and individual motives to the game. Each particular game has a broader context, for example, it could take place in a park. These characteristics make each chess game unique and interesting. The social context also plays a role. The game may be between old friends, in which case the interaction between the players could be more important than who wins. Alternatively, the game could be in a tournament in which winning is key. In other words, dynamics are predictable (you must play by the rules) but never fully determined. Every chess game is unique, but all follow the same rules. Thus, chess fulflls the criteria for a good game: simple to learn but hard to fully master.

The original MDA paper does a pretty good job hashing out game aesthetics, and the 8 or 9 experiences they conclude players are looking for when they play a game. These are (paraphrased somewhat):

• Sensation – Playing for the sensations of the game – the visual, audio, or tactile experience.
• Fantasy – Game as make-believe
• Narrative – Game as drama
• Challenge – Game as obstacle course
• Fellowship – Game as social framework
• Competition – Bringing us together by dividing us against each other
• Discovery – Game as uncharted territory
• Expression – Game as self-discovery
• Surrender – Game as pastime; a way of letting go or relieving boredom

So let’s take a look at how we can use aesthetics to define game genres in a way that might make more sense, and hopefully think about designing games in a different way.

Video: Aesthetics of Play

As we wrap up, I’ll throw one more fun video from Extra Credits your way. This video reminds us that how we perceive and experience a game (aesthetics) really isn’t at all connected with its graphical fidelity.

Video: Graphics vs. Aesthetics

If you’d like to explore more of MDA, you can find videos, slide decks, and more at Marc LeBlanc’s website: http://www.8kindsoffun.com/

The video below explains the major changes in the editor between Unity 3 and Unity 4.

More specifically, it goes over changes between Unity 3.5 (the latest version when Unity 4 was released) and Unity 4.0. It doesn’t include an introduction to Mecanim. That’s a large enough topic that it needs its own video (or videos), and when I post that I’ll add a link here.

Unity 4 also includes an upgrade called Property Drawers. These are a way to make working with scripts in the inspector a lot more powerful, and you may start seeing these in projects in the Asset Store or want to add them to your own scripts. To familiarize yourself with property drawers, check out this post:

A script, with and without property drawers

http://blogs.unity3d.com/2012/09/07/property-drawers-in-unity-4/

As I posted previously, this semester I’m teaching a new course in video game design and production at the University of Colorado. We have a great group of students, and they’ve just finished putting together their first game, of two that they’ll make in the course.

These games were developed by students of CSCI 4830-008, working in teams of two. This is the first of two games they’ll be making this semester in the Unity game engine. They were asked to create a 3-5 minute adventure / scavenger hunt game, where the player has to explore and track down various objectives to win.

The games explore many different genres, including:

• Horror
• Survival
• Infiltration

Crashed on a planet with no oxygen and a leaking suit, you must collect spare parts and tanks of oxygen as you work to repair your ship.

Avoid detection from cameras, beams, and patrolling robots as you attempt to infiltrate Evil, Inc.’s automated facility.
Ken

Try to escape with your life after a plague erupts on your ship in this sci-fi horror game.

Enter the house of a rich celebrity and make off with as much loot and incriminating info as you can, dodging security systems along the way.

Alone in the wilderness after a plane crash, you spot smoke from a cabin in the distance. Collect food and supplies, cross fallen logs and waterfalls, and try to reach the cabin before nightfall and freezing temperatures.

Stranded on a hostile planet, you have only your robot and a limited amount of fuel remaining to collect spare parts and escape the planet.

After your daughter is kidnapped, you’re forced to turn against your government and steal a top secret research project that could be devastating in the wrong hands.

This last week Julien was kind enough to allow me to teach a class in his new Introduction to Video Game Design at the University of Colorado. I covered using World Machine to generate realistic terrains for the Unity environment. I’ve shared the lecture slides and example file in an effort to beautify our virtual worlds.

If you would like to try it out for yourself, grab the free version of World Machine (non-commercial use only) and feel free to try out my World Machine Sample Terrain. I’m not sure if Julien plans on releasing his Unity terrain script, but in the meantime I highly recommend Tom’s Terrain Tools available through the Unity asset store for $25.

You can check out the course outline here.

Version 1 of this shader was created using the Strumpy Shader Editor. The original tutorial for creating the earth (minus night lights and night-side coloring) can be found here. The shader was then modified for nighttime lights and coloring.

This shader was created for the TerraViz project and may be considered open source with attribution.

Day and night lighting.

The night side of the earth is ever-so-slightly desaturated (greyed-out) and tinted blue. Both of these effects are very subtle, so feel free to play with these numbers. The corresponding lines are:

c.g -= .01 * s.Alpha; //lower green by .01 on the dark side - desaturate
c.r -= .03 * s.Alpha; //lower red by .03 on the dark side - desaturate
c.b = saturate(c.b + s.Alpha * .02); //raise blue by .02; saturate() clamps the value between 0 and 1

Night lights.

Lights appear on the dark side and fade in during ‘dusk’. The code that sets this is

half invdiff = 1 - saturate(16 * diff); //change the '16' to adjust how far dusk should extend)

Lights are tinted slightly yellow. The two lines below apply the rgb of the lights to the world:

c.rg += min(s.Custom, s.Alpha);
c.b += 0.75 * min(s.Custom, s.Alpha);

If you want the lights to be white, just get rid of the ‘c.b’ line and make the other line ‘c.rgb’. If you want them bright yellow, get rid of the ‘c.b’ line with no change to the other line.

Bump map

Supports a bump map for mountains and other features. The bump is taken into account with night lights (e.g. cities that are behind mountains ‘turn on’ earlier than those atop mountains – each changes when it becomes ‘dark.’

Atmospheric shading

A slight light scattering due to the atmosphere is created at the edges of the planet. The color and intensity can be set from the inspector.

If you’re looking for Earth textures to use with this shader, we used Blue Marble (from NASA) as the Earth texture. You can find black & white topo images (which you can import to Unity as bump maps) and nighttime lights many places; here‘s an example.

You can also download an asset bundle with the shader and sample textures here.

Shader "TerraViz/Earth-NightLights"
    {
 
      //Earth Shader created by Julien Lynge @ Fragile Earth Studios
      //Upgrade of a shader originally put together in Strumpy Shader Editor by Clamps
      //Feel free to use and share this shader, but please include this attribution
 
      Properties 
      {
    _MainTex("_MainTex", 2D) = "black" {}
    _Normals("_Normals", 2D) = "black" {}
    _Lights("_Lights", 2D) = "black" {}
    _LightScale("_LightScale", Float) = 1
    _AtmosNear("_AtmosNear", Color) = (0.1686275,0.7372549,1,1)
    _AtmosFar("_AtmosFar", Color) = (0.4557808,0.5187039,0.9850746,1)
    _AtmosFalloff("_AtmosFalloff", Float) = 3
 
      }
 
      SubShader 
      {
        Tags
        {
    "Queue"="Geometry"
    "IgnoreProjector"="False"
    "RenderType"="Opaque"
 
        }
 
    Cull Back
    ZWrite On
    ZTest LEqual
    ColorMask RGBA
    Fog{
    }
 
        CGPROGRAM
    #pragma surface surf BlinnPhongEditor
    #pragma target 2.0
 
    sampler2D _MainTex;
    sampler2D _Normals;
    sampler2D _Lights;
    float _LightScale;
    float4 _AtmosNear;
    float4 _AtmosFar;
    float _AtmosFalloff;
 
          struct EditorSurfaceOutput {
            half3 Albedo;
            half3 Normal;
            half3 Emission;
            half3 Gloss;
            half Specular;
            half Alpha;
            half4 Custom;
          };
 
          inline half4 LightingBlinnPhongEditor_PrePass (EditorSurfaceOutput s, half4 light)
          {
    half3 spec = light.a * s.Gloss;
    half4 c;
    c.rgb = (s.Albedo * light.rgb + light.rgb * spec);
    c.g -= .01 * s.Alpha;
    c.r -= .03 * s.Alpha;
    c.rg += min(s.Custom, s.Alpha);
    c.b += 0.75 * min(s.Custom, s.Alpha);
    c.b = saturate(c.b + s.Alpha * .02);
    c.a = 1.0;
    return c;
 
          }
 
          inline half4 LightingBlinnPhongEditor (EditorSurfaceOutput s, half3 lightDir, half3 viewDir, half atten)
          {
            half3 h = normalize (lightDir + viewDir);
 
            half diff = max (0, dot ( lightDir, s.Normal ));
 
            float nh = max (0, dot (s.Normal, h));
            float spec = pow (nh, s.Specular*128.0);
 
            half4 res;
            res.rgb = _LightColor0.rgb * diff;
            res.w = spec * Luminance (_LightColor0.rgb);
            res *= atten * 2.0;
 
        //s.Alpha is now 1 where the earth is dark.  The value of night lights has been saved to Alpha
        half invdiff = 1 - saturate(16 * diff);
        s.Alpha = invdiff;
 
            return LightingBlinnPhongEditor_PrePass( s, res );
          }
 
          struct Input {
            float3 viewDir;
    float2 uv_MainTex;
    float2 uv_Normals;
    float2 uv_Lights;
 
          };
 
          void surf (Input IN, inout EditorSurfaceOutput o) {
            o.Gloss = 0.0;
            o.Specular = 0.0;
            o.Custom = 0.0;
            o.Alpha = 1.0;
 
        float4 Fresnel0_1_NoInput = float4(0,0,1,1);
        float4 Fresnel0=(1.0 - dot( normalize( float4( IN.viewDir.x, IN.viewDir.y,IN.viewDir.z,1.0 ).xyz), normalize( Fresnel0_1_NoInput.xyz ) )).xxxx;
        float4 Pow0=pow(Fresnel0,_AtmosFalloff.xxxx);
        float4 Saturate0=saturate(Pow0);
        float4 Lerp0=lerp(_AtmosNear,_AtmosFar,Saturate0);
        float4 Multiply1=Lerp0 * Saturate0;
        float4 Sampled2D2=tex2D(_MainTex,IN.uv_MainTex.xy);
        float4 Add0=Multiply1 + Sampled2D2;
        float4 Sampled2D0=tex2D(_Normals,IN.uv_Normals.xy);
        float4 UnpackNormal0=float4(UnpackNormal(Sampled2D0).xyz, 1.0);
 
        o.Albedo = Add0;
        o.Normal = UnpackNormal0;
        //o.Emission = Multiply0;
            o.Emission = 0.0;
 
            //float4 Multiply0=Sampled2D1 * _LightScale.xxxx;
        o.Custom = tex2D(_Lights,IN.uv_Lights.xy).r * _LightScale;
 
            o.Normal = normalize(o.Normal);
          }
        ENDCG
      }
      Fallback "Diffuse"
    }

Night coloring

The clouds on the night side of the earth are ever-so-slightly desaturated (greyed-out) and tinted blue. This effect is very subtle, so feel free to play with the numbers. The corresponding lines are:

void nightcolor (Input IN, SurfaceOutput o, inout fixed4 color)
{
	color.r = saturate(o.Albedo.r - (o.Albedo.r - color.r) * 1.1);
	color.g = saturate(o.Albedo.g - (o.Albedo.g - color.g) * 1.05);
	//color.rgb = saturate(o.Albedo - (o.Albedo - color.rgb) * 1.1);
}

The nightcolor function is a final color application that lowers the red and green color by an amount relative to how much shadow has been applied (by a factor of around 10% and 5% respectively). If you wish to darken the clouds uniformly, remove lines 3 & 4 and uncomment line 5.

Global clouds can be a bit tricky to find. There are a few websites out there with greyscale clouds (try this site). Under the Unity texture import settings, select ‘Generate alpha from greyscale.’ to give these greyscale images transparency. Alternatively, you can use the images as a mask in programs like Photoshop or GIMP on a white image to create a semitransparent cloud image.

You can also download an asset bundle with the shaders and textures here.

Shader "TerraViz/Clouds" {
Properties {
	_MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
}
 
SubShader {
	Tags {"Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent"}
	LOD 200
	Offset -1, -2
 
CGPROGRAM
#pragma surface surf Lambert finalcolor:nightcolor alpha
 
sampler2D _MainTex;
 
struct Input {
	float2 uv_MainTex;
};
 
void surf (Input IN, inout SurfaceOutput o) {
	fixed4 c = tex2D(_MainTex, IN.uv_MainTex);
	o.Albedo = c.rgb;
	o.Alpha = c.a;
}
 
void nightcolor (Input IN, SurfaceOutput o, inout fixed4 color)
{
	color.r = saturate(o.Albedo.r - (o.Albedo.r - color.r) * 1.1);
	color.g = saturate(o.Albedo.g - (o.Albedo.g - color.g) * 1.05);
	//color.rgb = saturate(o.Albedo - (o.Albedo - color.rgb) * 1.1);
}
 
ENDCG
}
 
Fallback "Transparent/VertexLit"
}