ojjer

https://dl.dropboxusercontent.com/u/117768698/pokemon/pokemon.html

Using a pretty simple script, we can get Unity3D to respond to the default microphone on a PC and interpret its signal. After attaching that script to a GameObject, referencing MicrophoneInput.spectrum will give an array of floats representing the intensity of frequencies in the sound.

From there, the sky is the frickin limit. Any scene can now respond to the microphone. Properties like scale or rotation can be controlled by the bass line. Use the relative volume to control the speed of an animation and palette-swap on big hits and you get something like this.
skeleton555

https://dl.dropboxusercontent.com/u/117768698/squash/squash%20-%20Copy.html

or whatever!

here’s some more things I done did with it

bahabah
https://dl.dropboxusercontent.com/u/117768698/bahbah/bahbah.html

https://dl.dropboxusercontent.com/u/117768698/OHMYGODOHMYGODOHMYGOD/OHMYGODOHMYGODOHMYGOD.html

doomigif

https://dl.dropboxusercontent.com/u/117768698/doomslider/doomslider.html

Advertisements

magenta skeleton FX

soundtrack to this post:

4OpzySS

That rain particle system eventually found its way into magenta skeleton :^)
The stellar dude didn’t :(

I wanted to make a game with glorious rain that soaked a city and flowed off awnings. Finding out Unity3D particle systems could collide and bounce was the First Step in a Series of Some Steps that would Step Towards/Through Magenta Skeleton.

Behind the scenes (in the Unity3D scene editor), the rain in Magenta Skeleton acts like one of those cartoon rainclouds that follows a sulking earthling around. It is a big particle system that is just way up above the players head.

rainbehind

Make sure the particles Simulate In World Space rather than Local Space or you get Weird Effects (maybe you want those weird Fx tho, experiment (assuming you want to even make rain maybe you’re just reading this for the simple pleasure of parsing text + viewing gifs (good on you either way)));


The main Rain ParticleSystem is that outlined box. This is the rain u probably think of when you think “Magenta Skeleton had rain”.
It emits a LOT of particles that are rendered as Stretched Billboards based on Their Speed. They use a simple gradient in their material to make the bottom of the drop White and the top Fade Out. They fall really fast (gravity) so you get LONG STREAKS of WONDERFUL RAIN.

These raindrops collide with objects tagged “Water”. “Water” was a default unity3d tag and I didn’t change it. Objects Tagged Water collide with Rain and KILL THE RAIN. The highway that passes over the island is tagged Water and so any rain that collides with it is killed off, leaving a sweet little dry zone below.

The terrain was tagged Water, but when rain collides with things tagged Water the rain dies IMMEDIATELY and doesn’t really appear to ‘fall into’ the object but rather just DISAPPEAR. Looking out along a flat plain, the rain disappears a few feet above the surface of the ground and only sometimes tentatively prods at the earth below. So I tagged the terrain as “Ground”. This Main Rain doesn’t collide with Ground, so it just drops right through and looks really nice. The rain just gets absorbed into the earth.

watercolls

In this gif i have the rain collide with the ground and then not collide with the ground. you notice more water “passing into the ground” during the “not collide with the ground” part.

There is a second particlesystem, it is like the Main Rain except it emits in a much greater area around the player and emits Much Less Rain and These Raindrops Emit a Cloud of Mist whenever they Die. This second rain collides with Ground and Water tags. The Main Purpose of this rain is to coat the world in that wonderful mist. In Unity3D you can have a particlesystem emit a secondary particle when it dies. So this rain emits a CLOUD  (cloud is just a textured cube).

clouuds
this gif goes
no rain
Main Rain
Clouds Rain

the CLOUD is actually just a particlesystem whose renderer is set to render MESH->BASIC UNITY CUBE with a pretty bleh cloudtexture on it. The clouds fade in and out over their lifetime and rotate a bit. It makes me smile when i think of how stupid the cubes look  in the editor vs how nice they look in game.

cloudimage

The Buildings!

Before I knew how COSTLY thousands of particle collisions could be I wanted each raindrop from the sky to dramatically bounce and tumble and roll off every dang building. That can’t happen on my lappy, so I had to FAKE IT.

The places where rain seems to FLOW off a structure are actually just their own particle system.

buildingrain
I just set up the emitter to emit along the edge and send that rain arcing down. It doesn’t collide with anything and seems to be pretty cheap. The entire length of the overpass has this type of rain cascading off of it.

THE SKY!!!!

skycomp
For most of development the sky was that boring dark grey/green color. The ground looked awesome with mist, but the sky looked like so empty! Where did the rain fall from?

I added ANOTHER PARTICLE SYSTEM to the game. This time I used a giant half-sphere emitter. The sky is actually GIANT NOISE-TEXTURED CUBES THAT FALL GENTLY.

It is huge and fills the sky with wonderful noise that seems to flow down (looking like lots and lots and lots of distant rain)
raindome

In game if you look up at the sky you can see some cubes in the mess of noise. I think it looks pretty cool.

I think that mostly covers the rain effects.

The MAGENTA.

The neon signs in this game are giant fullbright cubes.

I have two cameras. One camera renders Most Of the Terrain and the skycubes-noise-rain. the other camera renders The Rain and The ?N?eon Signs. The final game composites these two cameras to create What You See.

The camera that renders the terrain is drawn first (it has a lower Depth setting on its Camera Component).

The camera that renders the neon is drawn second.
attached to the neon camera is a script with

void OnPreCull() {

RenderSettings.fogDensity = 0.0064f;
}
void OnPostRender() {
RenderSettings.fogDensity = 0.01f;
}

So just before the neon is rendered (OnPreCull), the fog is made much less dense. This makes the neon appear mega bright, even at a distance, even when the surrounding area (terrain, rendered earlier) is fogged out. After the camera renders (OnPostRender) the fog is reset to the default for the scene, so next frame the terrain is foggy.
lightfog

i toggle that script in this gif

Leaf through the Messages in this Script Reference http://docs.unity3d.com/ScriptReference/MonoBehaviour.html to see all kinds of things unity has functions for. Sometimes finding cool functions sparks an idea for me.
I added the rain/rainclouds to the neon camera because otherwise the neon signs would draw overtop of the rain even if the rain was in front of it and that looked silly and plus the rain looking bright looks better imo.

Every sign that flickers has a FlickerScript on it. Its a mess.

Essentially:

The script chooses a new random color for the sign and then waits about 1/10th of a second.
Every 1 in 15 times that the script chooses a new color it pauses this new color selection for 5-25 seconds.
The result is that a sign holds a color for a bit, and then flashes a few random colors, and then holds another color, and so on.

the script adds a giant point light to the sign object.

the point light matches the color of the sign.

Every frame the point light is positioned somewhere between the sign model and the player (it looks like it casts it onto the surrounding area and looks kinda neat and moves a little as the player moves. Its “wrong” but “seems interesting” (make things following that precept).

The script also generates a soundwave (a sin wave) that is based on the signs current color values (RGB numbers) (i just played with multiplying / dividing the sin waves’ amplitude and period by the RGB nmbers until it seemed ok). The signs hum and worble in interesting ways. When they flicker through colors they bleep and blorp because of wave math or something.

The SCREEN EFFECTS

I linked the basic script earlier. Essentially, each camera’s pixelRect is scaled down by “The Size I want My Pixels”. So I want big fat pixels, I divide the pixelRect by four. Now the cameras are only rendering to a tiny corner in the bottom left of my unity window. Now I use a function by the name of ReadPixels to snatch the camera render and put it into a Texture. This is typically a SLOW operation because it is sending information from the Graphics Card to the CPU, but because the camera pixelRect is only a quarter of the original size, its Not That Bad. In fact, making the pixelRect smaller is saving me more time than I’m losing to ReadPixels because of all of the transparent pixels I would be overdrawing with all of these insane overlapping particleSystems.

So I grab the scaled down camera pixels.
Then in the OnGUI function I just draw that ReadPixels texture as a GUI element stretched over the screen. Glorious chunky pixels.

That’s not all though. I also frankensteined a few shader effects into the mix.
The GUI function that draws my texture accepts a material as an argument. A material has a shader :=0

I took a Dithering Shader I found on the unity communify wiki, and a ‘blur shader’ i found somewhere. I wanted it to appear like “light bloom” so I made the shader only render the pixels if they were above a certain brightness. bright areas (the mist, the neon, the rain) get rendered as a dithered and blurred image rather than just normally. Everything else doesn’t get rendered.

Everything else should get rendered though. So I render two gui images. once as the dithered, blurred, only bright things. and then i just paste the unshadered, low res, screen image underneath. The shadered version acts like a highlight.

is that… it?

Weird magenta skeleton fact: there’s an unused intro scene. Check it out here: https://dl.dropboxusercontent.com/u/117768698/magbts/magbts.html

Particles

I am finishing up a particle editor for the videogame.

Here is a video of it.

 

 

It uses curves to determine the properties of the particles throughout their lives. It is basically a less exciting version of the particle system from Brutal Legend that we were shown in class.

I should finish it up before long.

I like to move it… move it

A hex grid is great. A hex grid that a nude hermit can teleport around on is even better.
I ended up changing things around a bit since last time.  Pointing to elements of a vector was turning out to be a gigantic hassle, so I gave the character a two dimensional integer that represents its location on the game board instead.

This grid:

This diagram I mocked up was a big help when coding the movement. The biggest hurdle was that movement in directions 0,1,3, and 4 have to act differently if the X value is odd or even. For example, moving along edge 3 from an even numbered X column goes up one X and down one Y but from an even numbered X it only has to go up one X and keep the Y value the same. Modulo operators are very helpful.


Look at him go…

And now for something completely different:

As a break from the monotony of Visual Studio 2008, I thought I would work on mocking up an interesting setting for the game. The vast darkness of an empty openGL window stirs up fear of the unknown and man’s struggle with the infinite. That is no place for someone’s mental state to be in when they want to play a videogame.

The entire game should reinforce the idea that the player is playing a magical medieval board game. “If not in an empty void, where else could a magical medieval board game take place?” I asked myself. “On a table!” I am genius!

Some cursory Googles lead me to a really great blog maintained by a skilled woodworker. The tables are gorgeous.

I want to smell them and touch them and spill drinks all over them. I want Tarotory veterans to resent their mass-produced plastic-and-particleboard Ikea™ table every time they boot the game up. They will load the game on their iPad (I can dream), place the iPad on their current table, and set their dinner plate on top of it all so that they might get some hint of how great it would be to eat off a table like that.  But even though the tables look medieval they do not look magical.

Deeper Googles bring me to burl furniture. This is more like it. This is the sort of table upon which a magician might leave his latest issue of O Magazine.

So I started to get some of that put together. Ideally, the menus and introductions will all take place at a table like this. The game might open to a table with menu options strewn about it. Starting a game could start a sequence where some wizard magic arranges the pieces across the table as the game transitions to the play state. You get the idea.

It is a start...

Well it is late. I’ll get more of this done tomorrow and hope to have something impressive for the milestone in GDW.

Game Progress

I made a hexagonal grid, I did!


That is a screenshot of a 100×100 grid of hexagons.

The hex system is handled as a 2D vector of Hexagon objects in a Board class that keeps track of them all. Each hexagon has its own location that gets calculated based on its index in the 2D vector (thanks to some math from this smart dude). Each hexagon also has an array of 6 pointers that point to whichever hexagon is adjacent to each of its 6 edges. Border edges are represented by NULL, and more code will be needed to keep our (eventual) characters from falling off the edges of the world. The framework is there though!

The Board has a node in the scene graph and each hexagon has a node that is a child of the Board node.

Here is screenshot of my beautiful hexagon placeholder.

Hexagon Pun

Where I Spend Too Much Time Playing the First Level of Shinobi


I’ve been musing over how great the first level of Shinobi is ever since I first picked the game up a few weeks back. Inspired threefold by a classmate’s tweet, a great blog post about the design of Mario World 1-1 on auntie pixelante, and my own blog’s stagnation I decided to write about the design of that first level of Shinobi I so adore.

Level 1

The Assassination of KEN OH

Like Mario 1-1, Shinobi opens with the player standing on the left side of the screen,  urging the player to move right and find… What ho? A Foe! Lurking in stage right are two of the world’s worst villains. The sight of a ninja so excites the gun-wielding thug on the roof that he immediately fires his only bullet way off into god-knows-where. He freezes up and starts imagining how pissed off Ken Oh is going to be (very). The thug who would have had a clear shot has no pistol. He walks forward and gives the player plenty of time to mash all 2 of the buttons (bufons) on their controller until they find the attack command. The player could safely proceed now, but they are way too excited by that weird monkey-kid-thing sitting in front of the terrified thug.
This is where my first playthrough hit a bump. You can’t jump up there using the basic jump. It is just too dang high! Believe me, I tried for at least 5 minutes. I eventually found out that there exists a “Super Jump” that I could perform by holding Up when I jumped. Someone should have read the manual.

 

Moving rapidly forward, our hero gets shot at some more (does that first guy even count?) by a thug standing behind a crate. “Take cover!” shouts the player’s monkey brain. The crate looks like a promising spot to take cover.  So the player takes it and crouches. The bullets fly safely overhead. “I can just duck underneath bullets!” the player concludes. No explanatory text necessary- just a crate and the danger of being shot. The designers appear to trust the player’s intuition.

Damn! We’re in a tight spot.

 There is another weird monkey kid sitting here. If the player still hasn’t learned how to Super Jump (and thus has not collected any monkey kids) this thing should make them want to learn how. Running into the kid plays a jingle and gives the player 1000 Points. “Boy howdee is it rewarding to collect these monkey kids!” is what every single player will think when they do this. They might even backtrack to get the first one they missed. Who wouldn’t!? The first kid doesn’t give 1000 Points, however. He “Up”s the player’s “Power” instead. “Rad!”


Continuing right, the player gets introduced to another exciting character. Shield-boomerang-ponytail is standing on the rooftop. He, like the first pistol-haver, freaks out as soon as he sees the player and throws his boomerang at nothing in particular. The player gets to watch from the safety of the streets as the boomerang flies over a stack of bricks (“Hey I could duck under that!”) and then turns around and flies back to Shield-boomerang-ponytail. He stands around like an idiot after that. The player could spend a while meditating on this but there is another thug strutting towards him that demands immediate attention. “This crate will protect me!” the player thinks. The illusion of security (and, likely, the player’s entire world-view)  is shattered when the thug jumps onto the god damned crate and continues his awful strutting. Thugs can climb over stuff. They are also allergic to shurikens thrown at their face, which is really too bad because that is how Shinobi says “hello”. The player now wants to get those monkey kids on the roof and they are willing to risk an encounter with Shield-boomerang-ponytail to get them. Unlike the first enemy, Shield-boomerang-ponytail still has ammunition (that would be the “boomerang” part) so the player has to use everything they learned about crouching and shuriken-greetings to deal with him. Introducing enemies by having them display their abilities in harmless ways is a good way to get the player accustomed to fighting them without frustrating them.

The rest of the level mixes and matches these elements to the delight of the player. Crates behind crates. Crates on top of crates. Monkey-kids on top of crates. Thugs firing pistols on top of crates. Thugs shooting from behind other thugs.

Shinobi Level 1

Its ... beautiful (CLICK FOR HUGE)

 The level ends with a power up that completely restores the player’s health. Any damage sustained while “learning the ropes” is forgiven. Thanks, monkey-kid!