Scripting Workflow: Amassing scripts vs namespaces and static libraries

Hi All,

So recently i've taken my enjoyment for creating games as a hobby, to wanting myself to approach it in a more professional manner. I have recently (yesterday), made the switch from MonoDevelop to VisualStudio.

I knew i wanted to create a collection of code so that I didn't have to recreate the wheel every script. Things like vector maths, physics functions, and graphical changes. This got me into looking at things like Snippets. Being a self taught programmer it took me a while to learn that snippets were mainly for small code insertions and not for full classes. I started looking into creating namespaces, and static class libraries. This seems to be more what I am after.

Having learned the concepts of maintaining functions like this, I am a bit lost how I should tackle the grand scheme of long term "Unity Game Development". All I know is that I want to increase my workflow productivity without having a million scripts to work from.

Say I want a collection of movement scripts for the way objects interact. Maybe a Jetpack controller, a bouncy trampoline or ball, a collision breakable object. Is it best to just amass folders of different C# scripts for different situations and then manually drag them into your project? Surely there is a more organized approach to this that would allow me to look up things I have created in the past either in Unity or VS.

And if I were to have a collection of scripts that all accessed my pre-created static class libraries, what would happen if I ever needed to make a change to something, would it break everything across all games? So I would need to insure that the math functions were spot on.

TLDR: Want to work smarter (less code), in order to work faster.

 

I don't know why you don't have any responses because this seems like a fair question.

You are on the right track in thinking about namespaces and libraries. You can create a library as a separate visual studio project (and have it compile it to a dll if you like) and then include that in your other projects. You can actually create multiple libraries if you like. Try to keep them nice and contained - e.g. a library to collect all your data structures, or a library for all your vector math.

Moving code from a project into a library also tends to get you to think about it in a different way, e.g. How can I make this generic and usable for multiple projects? If you can't answer that question leave it in your project for now.

Yes. But only if you 'upgrade' the other projects to use the new version of the library (so they can keep using the old version of the dll if you like, but then you have multiple versions to keep track of). Visual Studio does gives you tools to help make refactoring code easier, and there are third party tools to help also. But the best approach is to keep as much of your classes/methods private as possible. You can always promote their visibility later (e.g. private -> protected -> public), but taking it away is not so easy. The interface of your library is essentially a contract. Changing the interface is like breaking the contract, so slow down and only move code into your library when you know you've thought about it. Usually after you've needed to use it a few times you have a good idea of how it should look. And don't worry, this process is kinda messy for everyone.

 

Awesome, cheers for the info.

I would like to have a collection of scripts I have made in the past accessible from Visual Studio. Much like the solution explorer, but navigable outside of the project. Something where I can set a folder and have it up on my UI at all times. Do you know of anything like this for VS?

 

I have an idea that might be of interest. I use SVN on all my projects. In SVN you can create a thing called "Externals". Essentially what it does is that it creates a reference to another repository's contents, so that when you pull the global "Update Repo" then the externals are gonna be refreshed too. I've never done this myself for Unity, but for other vs projects i have and it works pretty well. You will need to create a separate repository for your library functions.