for (var go : GameObject in FindObjectsOfType(GameObject))
	{
	// do whatever you need to do here.
	}

   This seems pretty strightforward, but I guess I never thought to look for a type of "gameobject." Anyway, I thought I'd share.

PH S CT X: The Invisible FPS

It's based around the following tweet:

Would love to make a corridor shooter but where all walls are invisible. Constantly worrying if that enemy has open space to aim at you.

I think I spent about 14 hours on it. Bill Kiley wrote the music and graciously gave it to the game.  Enjoy!

First off, I invite everyone who is interested to browse images and suggest your own images at: 

http://reddit.com/r/visualinspiration

I intend this to be a great place for designers and programmers to share their favorite images and to be inspired. 

I also wanted to share more infomation about the images I showed in the presentation: 

Soviet monument

The sovient monument I showed is part of a series of monunements, a ton of which can be found here. 

Street art

The colorful mural was from Matt W Moore, and you can find the piece I showed here. Check out an image search for even more great pieces from him. 

Giant marionettes

The giant marionettes are from the Royal De Luxe theatre company, and there is a ton of great images and also video.  

Gas mask armageddon preparedness society

I can't find the source for this image, but I've hosted it here. 

Futuristic boxed apartments

The building is called Habitat 67 from the  Expo 67 World's Fair in Montreal. 

Recursion comic

The recursive comic is called Freaking Vortex and comes from the Perry Bible Fellowship. 

I think the big one is to save a scene (and reload it) during playback. It's clear the editor has this power in some fashion already, and it would be hugely useful for many types of games. 

But I know that's no small task. So, besides that, there's a ton that Unity could include, like: 

More data types for PlayerPrefs. The abllity to save arrays, for example. See EasySave on the asset store for a good third party solution for this.

Unique GameObject IDs that are static. When you save data associated with an object, you need to uniquely identify the object. GetInstanceID is a unique id for each object, but they can change every time you load the scene. I came up with a simple hack for powerups, but there should be a better way, especially since Unity's own way of saving data (PlayerPrefs) requires unique keys. 

An automated way to load and save a script's current properities. Right now, you need to write your own saver and loader for every single variable in your script. Add a variable? Add some code to saver. And don't forget your loader.  This is error-prone, and this should be automated. It's clear that the property editor has automated access to all the script's variables, so why not give us a way to bundle it up and save it and load it? It wouldn't have to work for everything (I understand the problems with saving transforms and whatnot) but just letting us save all integers, floats, and strings would save a ton. 

And if not that, at least give us a way to walk through them ourselves so we could roll our own autmated saver that doesn't require me hand-adding variables to save every time I change my script. There would still be the need for special-casing things, but this would be a great head start.

Summary

I know there's no way for Untiy Technologies to make the perfect SaveMyGame() feature that would work for every game out there, but really Unity needs more than what it has at the moment. It's almost non-existant.  In other game development environments, I'd have the tools to say "these variables are going to be saved." and then that's the end of it. 

Currently, for any game this isn't dead simple, SaveGame is one of the first things I need to think about -- and think hard about -- before I do any fundimental development.  And that's typically not what Unity's about. Unity is about focusing on your game, and not your engine. 

At the time I had no clue that My Little Pony had had a resurgence. Here are the results. 

Here it is in pastebin. 

.
 
@MenuItem ("Maquette/Batch Rename")
static function BatchRename() 
	{ // Renames all selected items in the Hierarchy to the first item selected, with numbers.
	var iname : String;
	ispacer = "0"; 
    icount = 0; 
	iname = Selection.activeGameObject.name;   // The item in the inspector
	
	istuff = Selection.gameObjects.length;  // if I wanted this to support renaming of > 99 objects correctly, I'd use this. 
	
	for (igo in Selection.gameObjects)
		{
		icount ++; 
		if (icount > 9) ispacer = ""; 
		igo.name =iname + "-" + ispacer + icount; 
		}
	}

How I imagine it is you can place objects into the crafting table, and depending on your ingenuity stat, you may see some spots around the item you place light up slightly. Rolling over these lit up spots, you may see items in your inventory highlighted.  This is giving you hints of how new crafting recipes can be discovered. This is an in-game approximation for having your character have insight into how things are built and how they can be put together.

The idea is that with low ingenuity, the highlights don't appear for some recipes, and when they highlight objects, they highlight "fuzzy" -- meaning it may highlight false positives in your inventory, or not highlight others. As your ingenuity increases, these fuzzy recipes get more defined, and new highlights start to appear for new recipes.  Each recipe has it's own skill level, so easy and basic things appear first, with more complex recipes appearing with higher ingenuity. Not all recipes would appear this way -- some could only be learned via wall carvings or parchments, etc. 

Ingeunuty, or perhaps another stat like "skill", may keep you from successfully building complex items (keeping people from looking up the reciipe online and buliding things their character couldn't have otherwise known about)

Ideally I'd like this inventory item to be a prefab that I can drop in the world. That's all well and good, but my issue comes up when the player picks it up. 

When it's in the player's inventory, there's no object in the world anymore, its just stored in an array for inventory objects.  Of course, if the player drops it, it will again be in the world. 

This *feels* like it will use two different kinds of objects, a GO with a mesh (etc) and a non-mesh object (not sure what that's called?) when it's in your inventory. BUT I DONT LIKE THIS ROUTE. It doesn't feel right to me.  Id prefer it to be one thing, although, if I can't have it that way, I understand. 

Any suggestions on how to handle this?

This is a free association sketch I did while brainstorming on Maquette. Note the simplified dome in the middle of the image.

I do a lot of free association drawing. it's just like free association writing, except for I'm drawing. But quite often I have no idea what I'm about to draw when I start. This is one of those cases. It's not about the quality of the sketch, or even the content. It's more about what my brain thinks of while I'm drawing it.