Unity scripting workflow and app layout

Mar-20-09, 2:35 pm by Hanford
File under: game design, Unity, tech

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 because 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.

One Comment | Retweet this

Feedback - One response

Displayed newest to oldest. Leave a comment.

Emil Johansen aka AngryAnt wrote: Mar-23-09, 3:55 am

In 2.5 I tear off the console window tab and place it in the same area as my text editor (on *my* second monitor :P ) that way, when I save from the text editor and unity automatically recompiles without needing focus, the console updates with errors and warnings in the same focus area.

You mention unity needing focus to recompile? Are you on windows? On OS X I don't need to focus unity to get it to compile in new changes.

Alternatively, you could hit save and then focus unity or even just the console window since its right there next to your text editor.

Comments are displayed on posts and visible to all site visitors.