What guidelines do you apply for your team project?

Unity Engine
1

I have noticed in the past few team projects I’ve been involved in that there has been some confusion and misunderstanding about how Unity “should be used”. To be honest, I still don’t know for sure myself. I read a question in unity answers a while ago that addressed one issue, and it was about how you’d manage prefabs and graphics content updates. I guess it sparked to my mind the idea that I still don’t know what the heck I’m doing. I guess this mainly stems from the fact I mainly ever do coding so I don’t know in detail how assets are handled by Unity, from the “team pipeline” point of view. So then I guess there must also be other gotchas with team project planning and execution, and I’d like to get your favorite opinions about what you think improves a project.

I’m thinking about things like (but not limited to):

  • Do you apply guidelines for artists to follow a strict naming convention?
  • Do you apply guidelines for handling prefabs so assets are easily updated?
  • Do you apply guidelines for file structure?
  • Do you apply guidelines for material use?
  • Do you apply guidelines in general to your project?
  • Do you… (anything else related)?

I also have one immediate question related to all this. Since I’m on yet another project and I know that artists will author levels in their favorite 3d editor, how can we ensure that we can keep level-specific triggers etc without losing the clarity and easiness that unity offers with components? We also must allow content to change without breaking existing functionality. Would you name objects in a certain manner (to apply scripts during load) or would you just make prefabs and build the level in Unity with all those prefabs? Or are there other approaches?

Note - this is for a team project. Not a solo project. So naturally we are most interested about team guidelines. However if you feel you have a general guideline that should work regardless if it’s a team or solo project then feel free to post.

Thanks for taking your time to read this.

2

Bump.

3

I have only been working with Unity for 6 months now, but before that I spend a couple of years working with Unreal.

For the project I am running now, Unity is used. And the way the team organizes the assets is remarkably close to how Unreal handles its packages actually. Now this is something that was to be expected, seeing the experience the people have with the Unreal engine and the way assets are saved and organized.

I personally think however that the way Unreal did it, is really nice! And it works really well for us right now in the Unity engine.

Assets are placed under their type first. Example : Mesh/texture/shader/particle/prefab/music/soundfx etc…
All assets clearly named of course, so a simply search should provide the right type of asset the user is looking for.

The way we organize the entire mesh folder for example, is purely by giving the objects clear names and putting them in logical folders. If for example level 1 is good, and level 2 is evil and both levels contain a plant.
Than most likely the mesh/foliage folder will contain : Plant1_lev1 or perhaps a Goodpland1, or for its evil counter part: Plant1_lev2 or Evilplant1.

It may be really obvious and simple, but that is the reason it works so well for us I guess :slight_smile:

As for the prefabs… That is just something that will remain tricky. Since a prefab can contain anything, the only thing you can do with them as far as I found out, is just to keep an eye out where the are placed. And what would happen to all those locations if the prefab is changed. its the up and down side of using prefabs I guess.

As for the level design… I don’t know how big your levels are, but making prefabs and combining them to a functioning level is a good way to go in any situation I guess. You can easily spot what is wrong, or if something is refusing a other part to preform normally. And you can put down entire prefabs as a single tasks for people to complete, which is a lot easier to plan and delegate than assigning the lose parts that make up that single prefab to a lot of people.

And if you are worry’d that 3d artist will break your game… Than It would not be a bad idea to put someone in the middle, like a level designer or game designer… Give it a fancy title. Someone that clearly understands the functional needs, but also sees the way the artist see the game. And that person should be responsible for a smooth build. Kinda like a translator between the graphical people, and the code people… may sound stupid, but in my experience the really talk two different languages sometimes :stuck_out_tongue:

I hope my experiences can help you out in anyway.

I would also like to say that I really like this topic, I am really interested to see how other people work with Unity.

4

I definitely agree that there can be improvements made in the artist-programmer interaction area :slight_smile: Not stupid at all, in all of my projects I have been part of I have seen this distinct contrasting way of how artists and programmers work. I find artists are chaotic and creative and programmers ordered and systematic, with a rare few exceptions.

I dont worry so much that artists break game, but I worry more that I find no solution that is maintainable from both the artists and programmers perspective. Unity is all about simplicity but I have a hard time dealing with the contrasting reality. I end up having to write code “the old fashioned” way because I can’t add components to models for example, where I wanted them to be from the first place. :slight_smile:

Clear naming is good. I prefer to avoid abbreviations unless it is some very common one. I want to keep it as plain text as I possibly can so people know what things are without having to consult the authors.

I found a solution for our level problems. We have artists making the entire level in max and some objects need colliders but not all of them, so I wrote a script that iterate through the objects during awake and compare names. Not really the most elegant way of doing this but it’s about as good as I can get it myself. Do you have other tips on how we can automate this kind of behavior? I’d really want all this to exist during design time but prior experiences put me off putting components on 3d-content.

5

Hmm, automating colliders is something I have no experience with to be honest. All projects I worked on required the level designer to make a clean collider for the map, or objects. This whas done because the levels where quite large, and the default colliders generated by the game engine (Unreal back than) are not really easy to render. So entire collision meshes where modeld over the level, and all collision from the objects where removed. So the player actualy collided with a huge mesh constructed from a single plane, and than extruded over the objects in the game.Wraped almost perfectly over all objects, the result… A fully covering verry cheap to render collision hull.

The problem with doing everything automaticly is that everything follows strict lines and can not bend the rules just a little bit in some area’s. When it comes down to level design, and creating smooth gameplay this could (fully depending on the type of game ofcourse!) make things worse.

If you are trying to make a perfect workflow in games, where all pieces of gameplay/mechanic work the first time and never need to change again, and turn out to be succesfull than please tell me how you did it :stuck_out_tongue:

My experience is that gamedesign is a huge amount of playtesting, especialy on the bigger games where certain gameplay mechanics are used troughout multiple levels. That is really something you want to have functional, and locked the moment you start using it. Changing that at around 70% of the development is a true nightmare!

And tweaking the final things to preform as the should is most of the work. Best way to go, in my opion is to make sure that people understand what part of the game the are working on, and who els is also working on it. Because this way the are less likely to get in the way of eachother. This is what creates 90% of all the problems.

I gues you should just give it all a go, do things the way you want to see them work. And if that works, you got your self a workflow you can continue using on that team.