Thursday, December 19, 2013

Review: PlayMaker and nGUI, two tools that should always be used together!

Today, I review the Unity4 tools Playmaker and nGUI.  I purchased both tools for a project I was working on, and have had no real contact with the companies making them.

I will not be covering the feature set of each tool, since this is published on their websites.  I will instead be talking about the reasons I feel these tools are useful to a consultant/designer like myself, and why you should get both for your own toolbox.

Playmaker ( is a tool allowing you to visually design logic for use in your games.

nGUI ( allows you to visually build menus and work with menu based visual effects.

PlayMaker NGUI Scripts ( is a bridge program allowing you to use Playmaker and nGUI together.  NOTE:  While this software was not totally up-to-date when I started using it to bridge the above two tools, it has since been updated by the creator.  This by itself should be a selling point, since many stop supporting their tools in unity soon after making them.  Kudos to merlin981 (

These three tools allow me to not only make my menus visually, but then to connect them to programming logic without ever having to ever write a line of code.  While I am an advanced C# programmer, I can say from experience that being able to flowchart your menus and gamestate logic is a good thing, and well worth the $200 I spent on these tools.

And before you programmers out there tune out this review, it should be noted that PlayMaker can tie into your own code with little effort.  Playmaker, at the very least, can send SendMessage signals to any script you like.  Truth is it can do a LOT more than that, but you can look up PlayMaker and read that elsewhere.

None of these tools are effortless to use.  They take a willingness to learn how they work, just as Unity does.  In exchange, they offer you a better (not necessarily quicker) way to design your project and menus.  One that allows you solid a design and debugging process that can be modded much easier than traditional coding alone.

Combine that with PlayMaker's efficiency and nGUI single drawcall for rendering, along with the fact they are fully compatible with both android and iOS, and you have a solid winner.

I've been building a toolbox for Unity for a while now, and I have to say that I can't really see myself regretting these purchases any time soon.

Tuesday, November 5, 2013

Kodos Can't Fly

Book Cover
Someone asked me for proof I can do book layout and have a sense of humor.


How about this?  Kodos Can't Fly: A World of Warcraft children's book.

This book was created as a lark while my wife and I played World of Warcraft.  While we have not played in a while, we still feel that making this was one of our favorite memories.

Good times, good times...

Wednesday, October 23, 2013

Unity and GUI scaling, the easy way...

Today's update is about GUI design in unity, and some ideas on how to make it a bit less annoying to use.

Anyone using the GUI system knows that it can be tough to make it work with multiple resolutions and aspect ratios.  In fact, this issues is the lead one clients come to me about when working with the GUI system.  Well, after "What do you mean Unity does not have a built in GUI editor?"...

Well, there is an easy method to deal with that.  Using the GUI.matrix variable.

The idea is to set a variable with the default width and height of the screen in pixels you want to design for, in this case, 1920x1080.  Once you know that, you build your interface based on the idea that EVERYONE will use that resolution.

Then at the beginning of every OnGUI() call, you just set the GUI.matrix and it will do all the hard scaling changes for you.

Example below:

Saturday, October 19, 2013

Sounds Foolish, or Foolish Sounds

One of my many hobbies is writing songs (or parodies, actually) about things that interest/annoy/amuse me.  Needless to say, that leads to a lot of songs.

Some of the songs are not listed here due to them being so horrible that I'd like them to fade away and die.  (yes, worse than these.  Think about it.)

I at no time wrote the actual music for these, just lyrics.  The vocals are mine, though.

First, the Second Life songs:
Avatar (Parody of Rockstar by Nickleback) was the first parody I ever published, based on most people's expectation of SecondLife.  It's also possibly one of the best known songs about Second life ever made.
Prim in my Hand(parody of stone in my hand by Everlast) is a song about Primitives, the building blocks of Second Life.
Sweet home on the mainland (Parody of Sweet home Alabama) talks about how hard it can be to find a place in Second Life, even your own home.
Lindens Lamnent (Parody of Piano Man) was written especially for a concert I hosted in Second Life.  It's a bit tongue-in-cheek, but overall is about how people seem to always push SL further than the game engine can function well.

And then the songs about how far Second Life has fallen due to Linden Lab mismanagement:
Lost Life (Parody of Mad World) came out at the point that I generally got tired of trying to make SL work, even though Linden Lab seemed to want to find ways to break it and chase off their client base.
You're Virtual (Parody of You're Beautiful) was written based on an archtype of player everyone in SL knows about.  Bet you do too.

And songs from other games:
World Of Warcraft: The Hunter (The Gambler Parody) This was done in a couple of days as a lark when they changed the hunter class for the umpteenth time.
StarCraft: Living in the Zerg Hive (Strawberry Wine) Zerg Rush!
StarCraft: Battle of new Gettysburg (Battle of new Orleans) Ever wondered how it went down at New Gettysburg when the Zerg and Protoss jumped the Terrans and whacked the whole planet?  Well, now you do!
Eve Online: Clone in the Lowsec (Down in the Boondocks) Eve has an interesting backstory about using clones for immortality... and euthanizing the original...

And songs made for RPG games I ran, in this case PathFinder:
We be Goblins  Is a song I took from Pathfinder's first RPG module.
Whisper in the Attic  Ditto.

Finally, my life in a song:
(I wish I Worked) Nine to Five (I'm Alive) is a song after trying to keep a series of servers up with a second-rate server company that liked to not only break things, but to tell us "no, everything looks fine from here!' Of course they do.  The server is OFF.  You can't get errors when they don't have power...

Sunday, September 29, 2013

L.E.O. Defense: A game in 6 hours

LEO Defense

As an example of designing a game in a single day, I've built LEO Defense.

Currently, it has no real effects or models, just using primitive shapes to define the game objects. Green is for aliens, Red and yellow for attacks, and boxes for cities on the planet.

Another day would allow for some basic models, special effects, and polish to the gameplay, but I wanted to show a six hour day of gamebuilding, from concept to playable demo.

Controls are easy:  Leftclick to shoot a bullet, Rightclick to fire a bomb.

There are limits to the number of bombs you can fire, based on how many cities you have.

See if you can figure it out. Link to the game: LEO Defense Webplayer

Saturday, September 28, 2013

Easy Rigging of Models with Blender and Mixamo: A Quick Walkthough

Many have asked me how to setup a quick pipeline from blender to Unity for rigging and animation.  Let me give one of the fastest setups I know of currently.

To use this method, you have the following limits and needs:

The steps are simple:

  • Install the most recent version of blender.
  • Unzip the 2.49 version of blender into a place you can run it from.  
  • Copy and blender_collada.pyd files from the collada importer zip file into the /.blender/scripts folder in your 2.49b version of blender's directory (possibly \blender-2.49b-windows\.blender\scripts\).
  • Take your finished model (it should also be uv-mapped to a texture, as you would do with any game model), and export it as an OBJ file.
  • Go to Http:// and chose the Auto-Rigger.  Upload the model.
  • Follow the directions for autorigging the model, and download the file as a collada 2.49 DAE file.
  • Run the older 2.49 version of blender, and chose FILE -> IMPORT -> Miximo Collada 1.4.1 import.
  • Use the menu to import the collada file you just downloaded from Mixamo.
  • Save the imported model and skeleton as a blend file using FILE -> SAVEAS.
  • Close the 1.49 version of blender and load the most recent version of the Blender software.
  • Hit SHIFT-F1 to load the new blend file you just saved.  it will open it and let you pick the part of it you want to load.  Chose the item called "scene", and then the file called "Scene" that was inside it.  Click the button in the upper-right called "Link/Append from library"
  • Look for the entrybox with the word "Scene" at the top of the Bender window, and click on the darker area with an icon of three shapes to its left with the updown arrows.  Choose "Scene.001" from the dropdown menu.
  • You should now see your model in blender, already rigged from mixamo.  From here you can export it as an FBX fo use in unity, or add a few more bones, such as bones for the eyes and jaw.  
This process can take hours of rigging time, and reduce it to just a few minutes.  If you need help with this process, I'm always available for consultation.

Friday, September 27, 2013


MetaMorph is a Unity3d and Blender3d toolkit that allows mesh animation in Unity games using Blender shapekeys.  It includes an export script for Blender that converts shapekeys into Diff maps and saves the animation data as text files.  The MetaMorph script for Unity can read the Diffmaps and animation data in order to play back the morph animations in real time.

Demo is here: MetaMorph Demo

You can get the files here:  Google Drive link

As of now, the most recent version is for Blender 2.58.

This thread at the Unity forums has more information:

I'll be trying to update this as I get personal time, but wanted it all in the same place for now.

Wednesday, September 25, 2013

Portfolio updated with video from several projects...

I updated youtube with video showing quite a few old projects.  Will be adding more as I can process them into video, images, and Unity players.

Portfolio Update

Wednesday, September 18, 2013

Mecanim and Unity Pro: How to match events to actions cleanly.

Today, I'll be discussing a method I'm experimenting with in Unity Pro, but I'll also talk about how to use a similar feature in basic Unity as well.

As you know, there is not event system built into mecanim currently, and the workaround is to use Curves to make variable spikes that you can check on to see what float value they have.

For example:  You have an animation of a man firing a gun.  You want to have the attack even happen during the actual firing moment of the animation, or about 0.13 seconds in.  You could make a coroutine to wait that long, but what happens if the animation is interrupted by the character's death?  Then you would have to put in even more options to check for such other events.

In the case of Curves, you can add a floating point curve named "FIRING" to the animation of the gun firing, and have it jump to 1.0 when it reaches the moment the gun actually fires.  Next you add a FIRING variable to the Mecanim Animator system you're using for the character. Then you have your code check each frame, and if the curve get's above 0.9, then run the damage code to attack the target.

This works fine, but it has a small flaw:  If you get a low framerate, you can actually miss the firing frame that gets the FIRING variable above 0.9.  It could jump from 0.8, miss several frames, and then run 0.7 as it leaves the spike you made.

So, how to fix that?  Simple.  Use an upward curve that ends in a sudden falloff at the moment that the attack should happen.

You then have your code check to see if the current FIRING value is less than the last frame's FIRING value.  If so, then trigger damage.  This will work even when many frames are being skipped, and prevents odd glitches.

But what if I can't use curves?

Well, this method depends on you actually making the animations, so if you're getting animations from someone and cannot edit them, it won't work.  If you do make your own animations, then do this:

Attach some additional bones to your character, and name them after the event they will represent.  Then treat them like curves and have them move (or rotate) based on the event you want to represent.  I used to use a bone that moved from near the feet to up near the head to show something happening, such as being a trigger for a particle effect.  All you will need to do is watch that bone on your code to change in order to use it as a trigger.

Friday, September 13, 2013

Choosing your tools: Blender 3D

All right, before we get started, I want to make something perfectly clear:  Blender is not the best tool for working in 3D.  It's hard to learn, has a clunky interface, and generally takes an extended time learning how to use it properly.

And so does every other 3D development tool out there, including Lightwave, Maya, 3dMax, 3dCoat, and Zbrush.  If I didn't mention a tool, then assume it's hard to use too.

Generally, the thing to keep in mind is to choose a 3d platform and stick with it.  While the cost of the software is a factor, there is a second cost that people always miss:  The personal cost in time and effort to learn their chosen software.  Software does not run itself.  You will have to learn how to use it, and that takes months, if not years, or practice.  If you spend a month trying to learn Maya, and then switch to 3dMax because you think it's "better" in some way, then you are going to lose a lot of the useful experience you gained in Maya and have to start over in a lot of your training.

So pick a tool and stick with it.

Myself?  I use Blender 3D.  Here are my list of reasons:

  • Personal Investment:  I started with blender in the late 1990s, and have been using it for over a decade now.  Switching to another platform would slow down my productivity to a crawl as i relearned how to do even the most basic task.
  • Evolving toolset:  Blender is opensource and evolving.  Every few months, I get a new tool to add to my library built into an interface I am already familiar with.
  • Swiss Army Knife:  One of the things that make blender so hard to use for newcomers is due to how many features it has.  It not only deals with 3D modeling, but a huge number of other tools.  It can even be used as an advanced video editor, and even allows camera tracking (tracking a film camera's position in 3d space) for visual effects.
  • Works with Unity3/4:  If nothing else, the FBX exports from blender work in Unity with minimal Pipeline tweaking and effort.
As you can see, my reasons for using blender probably not the reasons you would use it.  Most people would mention it being free, for example.  Well, as we know, nothing is free.  While Blender may not cost you money directly, it and other 3d software will cost you a huge investment in time to learn them.

So, this article is about blender.  If you do chose to start learning it, I advise the following:
That will get you started.  Next, many will ask how to use Blender 3d for game development.  Learn the needs of game modeling.  It is TOTALLY different from artistic modeling.  Polycount and design methods don't matter nearly as much when you are rendering a charater inside blender, as opposed to when you are building a model to be displayed in real time inside of Unity3d.
  • While you can build the source model as high resolution as you like, be prepared to have to build a new model for the game based on your highres model.  The normal way to do this is retopology.  This is the art of making a new, simpler mesh that generally matches the form of the highres mesh.  All the detail is then rendered into textures.
  • Get used to working with UV maps. Learn how to use them well.  Knowing how to use UV maps to texture a model is absolutely vital to game model design.
  • Normal and specular maps.  Learn em.  Game engines tend to use the holy trinity of Diffuse (color), Specular (shine), and Normal (surface angle, NOT BUMP) maps.  Don't just use them blind: Learn how they work.
  • Learn how to optimize the mesh by hand.  Where you may need to add extra faces or edgeloops (look it up), and why.  Game models can be rendered utterly useless by bad topology.  This is one of my main issues with 3dMax:  Artists getting used to using the automatic stack tools that make modeling easy, but don't even know how to clean up a mangled section of mesh that has a hundred triangles the size of a pinhole that messes up the model in unity.
Again, one thing to remember about 3d development tools:  Use what you want, and stick to it.  Switching tools won't help you to learn faster.

Saturday, September 7, 2013

Portfolio and Services Offered Up

I have started publishing information on previous projects and current services offered in the menu above.  Additionally, added a contact page for clients.  Still have around ten years of things to publish, though.  This may take a while to get finished.

Ah well.  Everyone needs a hobby.

Friday, September 6, 2013

RayFrakked (or how I built a game in a single month)

A playable demo fully realized. 

I've just re-released the demo of RayFrakked, a single player, 3d, social, puzzle game.

You will need to register, but you can always put in a fake email address, it's not used, since I don't have a password reset system installed yet.  Just leave the default key when you are registering as well.  Keys are currently turned off.

When you get into the game, you can either play one of the tutorial levels, or try using the editor.  The editor allows you to not only manipulate rods embedded in the walls (extend, retract, rotate), but to also place attachments onto panels on the rods.  These attachments are generally sensors (like buttons) and effects (like lasers).

In addition, you can lock rods in place, and turn of the refraction panels in each rod.  Normally, when the rods have lit panels, you can shine lasers into them and they will reflect back out another panel elsewhere on the rod (possible even a panel still not extended from the wall, so keep that in mind).  A laser can reflect through as many rods as it hits, so a single laser might pass though the entire map several times.

All attachments you can add to the rods can either hear or transmit on a channel.  Channels range from 000-999, and include some with special abilities:

  • 001-009: These channels are regularly triggered every 1-9 seconds in play mode.
  • 900-998: These channels only trigger once, unless reset by calling the relative channel on 800-898.
  • 899 resets all the 900 level channels.
  • 999: This channel tell the game the player won.  Try to put a trigger with this someplace hard to reach, but not impossible.

The player start position will be the same as your own position when you saved.

Yeah, looks complex, don't it?

This game, while not finished, is definitely in the late beta stage.  It includes the following features:

  • First person camera action, based on movement and jumping less than shooting.
  • An environment that changes to present puzzles based on room configuration.
  • A full level editor, including the ability to test your created maps and publish them for others to try their luck against.
  • Full sound effects.
  • Start Menu to allow feature navigation.
  • A key registration system that ties a single product key to a username/email/password.  This system is similar to what steam uses for it's product registration.  The key system is currently disabled, allowing anyone to register.
  • Web based server for registration, sharing levels, and leaderboard scoring (this section still needs work, but is mostly ready for use).
  • It has reflecting lasers!  And crushing walls!  And changing environments!
This game was conceived, designed, and built in a single month.  The only parts that I used from the outside were a texture pack I purchased, and some of the sound files.  Everything else was created myself in that time.

Made with Unity!  RayFrakked 

Game Design Specs.

  • Concept took about 3 days to begin with, and expanded from there as the game was designed. 
  • The game itself was created in Unity3, using UnityScript as the coding base. 
  • Models for the game were created in 2 days (including rejected model attempts).
  • The FPS is a default Unity design, with modifications.
  • Sounds were downloaded from, and processed using Audacity and Sony Sound Forge.
  • Start menu uses the default GUI system of Unity, as does the HUD for editing maps.  This was Not fun, but it was educational.  At this point, there is not much I can't do with the GUI system.
  • The key registration system used a random key generator software for windows that I can't for the life of me remember. (this was over a year ago).  It was able to generate a text file of thousands of non-repeating keys I was than able to upload into a sql database.  Those keys are then in one of three states:  Stored (you can't register them), Ready (they can be registered), or Used (someone registered the key).  This allowed me to make sure every player always have a unique key.  This took about 4 days to setup.

So, how did I build a 3D game with all these feature in a month?  

By knowing how to design the game from concept up with reduced production needs in mind.
  • The game has no characters that are seen, so has no need of organic modeling, animation, or character AI development.
  • The game actually only has around three main models.  The walls, the pillars, and the spacers between the pillars. Talk about limiting asset needs...
  • The pillars all use the same code, and are generated when the game starts.  This means most of the game logic was built when one pillar was created and designed, and changes to the code/model of one pillar changed them all.
  • The game is single player, with only web calls to transfer data to and from a php base server.  This means no needing to deal with realtime servers, networking code, and debugging.
  • The game is made to allow the player base to develop puzzles.  I'm just creating the tools.  While I obviously will need to create tutorial levels and some starting puzzles, the players will actually be playing against each other and trying each others maps more often than not.  Since the game does not allow an unbeatable level to be created (since the player making it has to be able to beat it to publish it), this means that all maps are "possible" to win against.  (Yes, I know they could make maps that are nothing buy trial and error, but that's what ratings are for).

What kinds of problems did I run into?

  • The main issue was with rendering 9x9x6 pillars (that's 486, for you non-math types), that move.  Check out most games you play, they do NOT have that many moving parts.  Combine the increased render passes with physics needs, and the game design initially slowed to a crawl.  It took nearly a week of remodeling the pillars, testing rendering modes, and a host of other research to get the game to where it is now.  In addition, Unity 4 sped things up considerable in terms of framerate.
  • The Unity model imports from blender using FBX were kinda sketchy back then.  Much easier now, though.
  • Sounds.  Not making them, but playing them.  With around five hundred pillars, all potentially moving at the same time, each making it's trademarked grinding noise...  The sound system broke.  I was forced to make a system to que and limit sounds that could play at one time.  Otherwise, it sounded like a trainwreck.  A lot of trainwrecks.

What would I like to improve and change?

  • Well, I'd like to remove channels and add some kind of visual connection between attachments.  Not sure how I would do that without making it an even MORE complex mess to figure out visually.
  • Finish adding the voiceovers for failure, clues, and humor.  Those were fun to make, and yes, they ARE my voice.
  • Cleanup of a lot of kludge code.  Heck, would love to upgrade it all to C# as well.  Just to keep up with my current coding preferences.  
  • Get the level selection system finished, polished, and linked to the websystems fully.
Overall, it was a fun project that proved that it was possible to build a full 3d game in just days.  It just takes limiting your designs to allow for your skills and available resources.

Wednesday, September 4, 2013

Welcome to the new Foolish Designs website!

Under Construction
Please excuse the lack of content as of the moment, as I am moving my old website over to Blogger in order to better tie my ability to show off my game design portfolio, publish a development blog for projects I'm working on, and generally centralize my web presence.

Since starting my game development consultancy work, I have seen several things asked on a regular basis.  I hope to publish on many of those topics here, hopefully helping those that come here to avoid many of the same mistakes that have been made before.  If even a few people walk away with something helpful, I'll consider it a success.

As I get time, I'll be discussing issues that come up on projects I'm currently working on (If allowed by those I'm working with, I often sign NDAs), and commenting on how i was able to correct or avoid the issue.  Hopefully this will also be useful to those that visit.  I also want to discuss more technical aspects of game development, such as using features of the Unity3/4 engine, asset management, and even team coordination using such things as Skype and Google+.