I came across a blog post from Spiderweb founder/developer Jeff Vogel, who dishes out some thought-provoking iPhone development advice. Here’s some snippets:

There’s a lesson for young developers. Make sure your game fits the way people will want to play it. PC Games = Longer sessions. iPhone Games = Ping. Zap! Done.

I feel this sums up most of the reasons why I am not developing iPhone games. I don’t want to make games that would play well and/or sell well on the iPhone. I don’t want to take an idea I have and say “okay, now how do I make it work on the iPhone?”

But my favorite line he bangs out is this:

When someone can make a ton of money on an app that makes your iPhone fart, that should be your first warning of unsustainable sales.

This is the final strike on the proverbial nail in the coffin for me. Because of the games I want to make don’t fit the iPhone, I’d be hopping onto that platform and making a game simply for the hope of “hitting it big”, and I just don’t want to take the hobby that I love and channel the wrong kind of energy into it like that.

Please read his full blog post. It’s quite interesting.

This post it going to describe how I’ve transitioned from scripting in Director to Unity. Unity and Director have very different scripting workflows, so I thought this would be a good topic to cover for new users.

Application layout

I use a two monitor setup. I have resisted dual monitors for years becuase they divide my attention, but monitors are so cheap now (I had a small one just laying around) it was an easy to hook one up and use it. Let’s call the primary monitor monitor 1, and the secondary monitor 2. You can probably duplciate this setup with only one monitor by dividing your monitor in half for most of this.

On monitor 1 I set up Unity with all the viewports: Hierarchy, Project, Inspector, Game and Scene. The only Unity panel I put on monitor 2 is the Console, and I make it really wide (we’ll find out why later).

I also set up my external script editor on Monitor 1, and a web browser window on Monitor 2. I have bookmarked the local Unity scripting Help page (with search) on my Firefox window, in the toolbar, so I don’t have to go to the bookmarks drop down for it.

Scripting workflow

With this monitor/application setup, I have the following workflow:

Test

Testing the game is done in monitor 1, with the console expanded in monitor 2 so I can see print() (AKA Debug.Log()) statements and other errors, without them getting chopped off. I use a lot of print() statements for debugging.

Debugging/scripting

When I find an error in the game, I can edit the script by double clicking it in unity (you can quite often double click the error message in the Console to open the script in question).

This brings my script editor to front on monitor 1, but leaves the console completely visible in monitor 2. This is key. It’s key becuase you can clearly see line numbers for the errors, and you can see the exact complaint Unity had while editing your script. Director, on the other hand, takes you directly to the line itself (yay!) , but the error message is only displayed in the modal dialog (boo!).

Scripting help

At this point, if I need clarification of something, I can pop open my browser window in monitor 2 and use the bookmark to go directly to the search feature. Again, becuase it’s on monitor 2, I can go back to script editing in monitor 1 while still having the documentation visible.

Script compiling

You have to save your script and switch to Unity in order to get it to compile. This part is less than optimal, I wish the unity editor had a button or single key command that did that, but in reality it means ctrl-S Alt-tab (tab, tab, tab sometimes). Simply keep your eyes focused on the console and in a few seconds you’ll know if you fixed the errors. If you did, the error messages will disappear. If they stay there, you didn’t fix the errors.

This can be confusing for the new user, because when I first started Unity, I thought error messages appeared in the Console like print statements, as if I could scroll backwards in the console and see old error messages that I have since fixed. This is not the way it works.

Error messages in the console are persistent and will disappear when you fix them. If you see an error, attempt to fix it, and come back to Unity and the original error is still there, it means you didn’t fix it. If you fixed the original error but created a new one, when you switch back to unity the old error will be replaced with the new one.

Scripting gotchas

This is a confusing one: quite often the last good compiled version of a script will still be in memory if you test your game. This means if you introduce a bug in your code, then switch to Unity and hit Play without noticing errors in the Console, you’ll get the behavior of the last good compiled version of that script in the Game (becuase the current script never fully compiled due to the bug).

This can feel uneasy -- I’m left looking for gameplay based on the code changes I made but not seeing them. Clearly the script is functioning, why is it not behaving like I expected? If you’re not used to looking to the Console for errors, this can catch you. I still make this mistake from time to time.

Also, errors quite often halt the compile process, meaning other script changes that have not been compiled yet won’t be active either.

Feedback

If you test this method out, I’d love to hear how it works for you, or any modifications you might make to the setup for your own use.

Unity for Windows is now live. It’s fantastic; I hope to post more about it here soon.

UV modeling tip: fuck it and use atlas projection.

I’ve been creating all my object texture sheets at 1024 by 1024 and using Unity’s Max Texture Size setting to reduce them in the game based on quality and memory. I think this is a great technique because it allows you to make quality and memory decisions interactively throughout the development of your project. It’s a lot easier to find the smallest texture size that still looks good directly inside of Unity rather than having to bounce between shrinking-and-saving in Photoshop and checking it out in Unity. Beyond that, you can keep them all at 1024 by 1024 during development, then change settings based on your target download footprint for beta.

But yesterday I noticed something with a text graphic (warning! programmer art). Here’s the original on the model at 1024 by 1024:

Now here it is with with the Max Texture Size set to 256:

This looks to me to fall below my smallest-size-while-still-looking good test, and normally what I’d do is kick it back up to 512. But the text itself looks pretty gnarly here, and it got me wondering: why is it really that bad? Is it the nature of 3d textures? is 256 by 256 really that nasty?

I took the original 1024 image, resized it in Photoshop down to 256, saved it, and applied it to the model:

Not only is the Photoshop-scaled version significantly cleaner than the Unity-scaled one, it actually appears to be a higher-resolution. The Unity version does a better job at preserving the text’s original color and brightness, and I think it may be doing this by applying a sharpen filter to it, but if that’s the case, Unity’s filter is too heavy and is unnecessarily pixelating the text. I can apply a sharpen filter in Photoshop with a bit more percision to help fix color brightness issues.

I decided to see what Photoshop could do at the 128 by 128 level, to compare it to Unity’s 256 by 256. Here’s what Photoshop did:

To me this version is too low res to ship, but I’d take it over Unity’s 256 by 256 scale. It’s clearly at a lower resolution but it’s not as jarring to the eye; it’s still not as pixelated.

Conclusion

I will still be using Unity’s Max Texture Size setting to adjust textures during pre-beta development as it’s just too damn handy to do in-engine, but I’m going to be taking a closer look at their quality, and I plan on using Photoshop during an optimization round towards the end of beta cycles. I think it’s fair to say that Photoshop scaling can get you smaller, better looking textures than Unity alone.

(Note: I’m a new user to Unity, and I don’t know if I’m using the Max Texture Size setting correctly, but regardless it would be ideal to be able to use it this way)

I’ve been on Twitter for a while now, and if you can’t get enough Hanford Lemoore action from this blog, check me out on Twitter.

Working on some textures for a game, and it accidentally came out like this. Not the way it’s going to be when it’s done, but I thought I’d post it because I it looks neat.

Randomly found this 80s Congo Bongo commerical featuring a Henny Youngman soundalike(?) telling non-jokes about the game to canned laughter. I totally remember this from back in the day, when isometric graphics mesmerized me. What mesmerizes me now is how anyone, even back in the 80s, could think that Henny Youngman would be a great way to sell video games.

Why I’m not developing iPhone games:

4. The iPhone’s controls are not suitable for the types of games i want to make. Tilt control simply doesn’t cut it for me. point-and-click is good but not when using a finger instead of a mouse. And the games I’ve played that use multi-touch have really been sucky.

3. Apple has the right to refuse my game. This creeps me out. I don’t want to do a lot of development work, just to find out Apple it’s going to deny me. You can’t run a business on a risk like that.

2. The iPhone store is currently being flooded. Both with quality stuff, but also a lot of crap stuff. Reminds me of the Atari 2600 debacle. I think this current flood is disproportionate to the iPhone’s market, meaning it is probably harder to have a hit game on the iPhone than it is on a PC casual game portal. The reason for this is that it’s being heralded as a developer’s gold mine, so it’s attracting a lot of get-rich-quick apps (remember how hot Facebook apps were for a while? What happened there?)

1. It is unclear how to market and promote iPhone apps. Anyone who has been in the indie game biz for a while knows that marketing a game is, in general, a lot harder for an indie developer to do than actually developing the game. While there’s tons of info online about how to market PC and Mac games, there’s very little about how to do it for the iPhone. The current strategy seems to be “somehow get it on the top games list” which really isn’t a strategy at all.

Now that I’m working with Unity full-time, I’m having a lot of fun learning the system, and it’s pros and cons. I’m still unsure of the best strategy to do big save-games, but I’m not too worried about that for my first game. But I want to make save/load data easy to use when building levels.

Unity’s PlayerPrefs allows you to save and load data using name/value pairs. It’s pretty general and reminds me of Director’s SetPrefs (Did Tom help them design this feature? ). One thing I have not been able to figure out though, is how to get a unique ID for a gameObject that I can turn into a name for PlayerPrefs. Let me walk you through an example:

You have a health pickup prefab, and it’s name is “HealthPrefab”. These prefabs are scattered throughout the level. When you pick them up, you want them to stay picked up, even if you leave the level and come back. This can be done with playerPrefs, but because you have multiple instances of the health prefab in the level, you need a unique name for each one.

This could be done by assigning a name to every instance of the prefab using the inspector, but this is time-consuming for the designer, and error-prone.

It can’t be done with GetInstanceID because while this number is unique per object, it changes every time you load the level.

The best solution I have come up with so far is to generate a unique name based on the position of the object in the scene. Here’s how I do it:

Object name + Scene name + Transform x + y + z

With this code, you can add prefabs to your level at your leisure without having to name them uniquely, and they’ll just work.

I actually use integers of X Y and Z to make the name shorter, and this just means you have to make sure your pickups are at least 1 unit away from each other. For most games this should not be a problem, but if it is, just modify the name-generator to use higher-res values. In my game, the name-generator is a static function that every object calls, but in my script here I stuck it in the same script. I’d love to know what people think of this, and if anyone knows of a better way to do this, let me know!

// Simple Pickup code -- .js -- for Unity

private var savename  = "";

function Start ()
{
savename = savename(this.gameObject, "pickup");  // Generate a Unique Savename.
if (PlayerPrefs.GetInt(savename,1) == 0 )
{Destroy(this.gameObject); }
}


function OnTriggerEnter (hitby : Collider)
{

{// Put some code here to check to see if the item that triggered you can pick you up

PlayerPrefs.SetInt(savename, 0);
Destroy(this.gameObject);
// do some "you picked me up!" sound effects, etc
        }

static function savename (object : GameObject, ilabel : String)
{ // Call this to get your unique save name!
// this builds a unique savename by stringing together the object's level name, X, Y, and Z locs (interegers of), and a prefix that is defined
// by the object itself. The idea is that this is a uniqueish enough key for saving the status of an in-game object.
// Ideally this function is a master function somewhere, rather than in every type of pick-up script you have.

return ilabel + "." + Application.loadedLevelName + "." + parseInt(object.transform.position.x) + "." + parseInt(object.transform.position.y) + "." + parseInt(object.transform.position.z); // this makes a unique name for this object. Kinda.
}