If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
One take away I got from this video is that organising your project is similar to scoping variables in scripts. You only want to share them as much as you need to. Oversharing is bad. Does that sound about right?
I came across this web page of tips from Glen Stevens some time ago and found some of the advice handy. Some of it’s over my head at this stage in development but I go back and read it from time to time to see if it makes any more sense. You may not agree with all of it, so as usual with advice, your mileage may vary!
I look forward to seeing how you suggest we organise this project, I’m a bit of a efficiency nazi so I’m open to better ways to keep things tidy and fast.
1 Like
Resolving my challenge: Sharing my thoughts on organization, including talking about what has and hasn’t worked for me in the past – -
As a solo developer, I’ve been trying to develop the “combat moment” on my own. Except it’s not really on my own, since I’m also following this course – which is kind of like collaboration – and so it’s been an odd process. Every so often I decide to go off on my own or resume the course and sometimes I just need to backup and begin a new approach without depending on preexisting scripts/assets. The result of this has been several Havenwood project directories.
Havenwood v3 is my master RPG right now. But I’m about to start a new project called Havenwood Fights, where I approach combat from an entirely different angle in which my character is in an empty room and enemies spawn at the door and approach me to fight. The purpose of this scene is to work on my combat maneuvers, animations, move rates, distances, weapon types, etc.
I want to get a real feel for what combat looks and feels like, especially from the view of what kind of input controls I want to ask the player to use. Instead of focussing on level design or enemy stats and such, I just want to focus on attacks. This is because my action RPG emphasizes action a little more than Diablo and similiar games, and so I’m picturing having a “block” or “dodge” button and stringing some animations into combination attacks.
The one thing that does not change among these project files is the design documentation. Havenwood v1, v2, v3, and Fights have all shared the same overall design schematic, art direction, general concepts, etc., as explored through the RPG course.
If Fights doesn’t work out, I’ll resume the course with v3. Otherwise, I may use Fights as the basis for beginning a v4. I am really not liking how the NavMeshes is working for me in v3, and I may abandon point-to-click altogether depending on how things work out in Fights.
As far as individual project organization goes… yeah, I’m still in the habit of labelling folders as Scripts, Textures, Scenes, etc. The only difference is I put an _underscore if its a folder I made, as opposed to one that came with an asset.
I have made exceptions in the form of a Player, Enemies, and Environment folder but even then I think I prefer if these subfolders of Materials, Prefabs, etc.
Since I’ve kept my combat moment so simple (no where near as large as Rick’s right now), the organization really doesn’t matter and so currently is a mix between the two styles in that I keep going between the two alternatives. I am much more comfortable with this older, “less efficient” style of putting things by type into their respective folders, but I also understand how grouping things by concept can be beneficial when collaborating.
The Best Practices document Ben shared with us in Complete Unity Developer recommends grouping things by scene location when possible, and I suspect this is how the World Objects folder will be organized eventually.
1 Like
You need to be careful about merge conflicts for monolithic files like graphics, 3d models or video if you are working in a team using Git (or other distributed source control systems). Centralized SCSs usually have a ‘check-out’ feature that prevents other contributors from making changes to a file until the active developer checks the file back in; you know someone else is active on a file before you start to work on it. Git gives everyone their own copy and detects conflicts on check-in.
Git is great for code, with good support for line by line merging of changes to the same file by multiple dev’s, but not for non-text formats, only one person’s update can be accepted.
It is another reason why setting Unity’s asset serialization to use text can be useful. It is usually possible for a knowledgeable person to merge configuration changes in YAML or other text formats, but not to binary files.
I just posted this question for a slightly earlier lecture - it’s very relevant here:
I’m really wanting to organise my assets and file structure, but am a bit unsure on this particular aspect.
I was taught the classical way of organizing by file type — a prefabs folder, a scripts folder, and so forth. My only concern with the method of organizing described in this video is what the code hierarchy will look and feel like in the code editor, but I have yet to try it this way.
I tend to be a stickler for organization, so my project remains pretty clean. However I did learn that some assets you bring in are required to stay at the top level, mostly things that add features(water,terrain editors,etc). I had to get used to that aspect. I am a solo developer so I don’t have to worry about things getting changed, but I have worked with others and it can be a pain if your not on the same page.
This is something that comes with experience. The important thing is to be consistent and know how to evolve as the pain points get identified.
Examples:
- Being able to export and reuse assets can be a real life saver as your projects start to add up.
- Start my folder names with “!” to force the sort to the top.
- Try to keep a minimum version of 3rd party assets in their original folders, with the least amount of modification so they can be updated in the future.