Unity workflow: expectations vs. reality

By this point I’ve gone through tutorials for both Unity and 2D Toolkit, and I’m really pleased about my decisions to use both. Unity is a solid engine and editor, and the fact that it can output to so many platforms with minimal hassle is really impressive. And 2D Toolkit is a fantastic extension — it essentially lets me forget about the fact that Unity is a 3D platform, which for this project is a big help.

But, working in Unity is a lot different than what I’m used to. Sure, it lets me use C#, which I already know. But I’m used to something like…

void main()
{
    while(quit==false)
    {
        Update();
        WaitForVBlank();
        Draw();
    }
}

…and within that I would build a state machine and start making the game. Using that method, game logic is pretty straightforward (at least as much as a given game design will allow), but asset- and display-related issues (loading, drawing, animating, cameras, etc.) require a decent amount of work.

But Unity is not like that. I knew Unity was somewhat different than what I was used to — I had seen editor screenshots and skimmed a video or two — but honestly, I thought it was more or less the above but with something like 3D Studio Max built in for doing level layouts. Though my expectation of the scene editor was pretty close to reality, I was wrong about the coding aspect. There is no main(), at least not one that you have direct access to.

In short, to contrast the above, with Unity the asset- and display-related issues are essentially free — you don’t worry about loading things via function calls, just make sure they’ve been dragged into the appropriate scene and they’ll display. Same for audio: if a button needs to play a sound effect upon tap, drag the sound file onto that button — no loading required. Now, you’ll still need to write code, but not in the way I was used to. I don’t control the main loop. Instead, I write code files (“scripts”) that I attach to objects in a scene, and each object’s script is run each frame. It works, and honestly I believe this set up will end up being very efficient, but for now it feels very foreign.

I’ve resigned myself to the fact that — particularly because this is a new paradigm for me — I’m going to be doing a lot of things the “wrong” way on my initial implementation of Project Smart Birds. But in order to finish the project relatively quickly, I must. It will pain me somewhat, but I must! After the game is complete and I have learned enough to realize that I made some boneheaded implementation design decisions, I can go back through and fix things as warranted.