Your workflow?

For my latest game I’m going to do things differently.

Normally I have an idea, work on some art assets, start making the game in Unity, add more assets, make more game, add more features, make more assets for the new features… etc etc.

This time I’m thinking of making the entire game with squares and such until it’s all done then work on making it look nice.

Just wondering what other people do?

Yup, prototype first with boxes and primitives - prove what you want to do is fun and actually achievable first, rather than spend time on making loads of art assets for stuff that you’ll only later find out won’t work.

That makes a lot of sense. :slight_smile:

You are prototyping, prototyping, prototyping, and then some day you realize that you are not in the right mood for any serious work and want to take a break and have fun. You decide why not to change the terrain’s checker texture, that you were using from the very beginning, to something visually more appropriate for terrains. You change the texture. Then you change it again because you have found a better one. And then again. Then you realize that the texture looks bad at the slopes, you think maybe you should use tri-planar texturing. Then you think, you have a wonderful terrain, but it really lacks some grass. You start looking for a proper grass texture, try some of them, then realize that it would be even better if there were two types of grass, or three, and flowers too…

At some point later you realize that the development is far from its finish, it just has started, and you are not even sure about the gameplay, but you already have to deal with all those textures, shaders, models, lighting etc.

I’ve started using a prototyping setup similar to what’s mentioned above; I only create things like trees/textures/etc. on an as-needed basis. Most of the animated bits are simulated using either a cube or a generic blank model with no animation done.

GUI is something I’ve had an easy time with; I wrote a series of serializable C# classes that provide the mechanisms to control and tween various Unity GUI controls; I merely pixel up the interface and write a minimum of code to implement.

Sometimes, doing it that way reveals things that just won’t work. I’ve rewritten a number of ‘main menu’ interactions from what is shown on my dev blog, because I took the time to prototype. I also realize my current system is imperfect in and of itself; it dosen’t lend itself to reactive displaying, which is bad should I want to take this to a mobile platform (which I do). Again, another benefit of taking the time to build the technological framework first.

An old engineering maxim: get it working, then get it right!