next »

[cmspice]

After using to write several large ish scale programs, I've been thinking of writing a short ( < 50 pages) guide on writing complex games/programs in Unity. This guide assume readers are comfortable with C# and the basic concepts of Unity.

outline:
-Intro nonsense
   -who is this for
   -the prototype approach
   -the scalable approach
-scripting
   -good and bad usage of mono behavior
   -taking control of the game loop
   -using libraries, and creating your own libraries
   -accessing resources in code
      -managing input
      -managing sound
      -managing materials, textures and shaders
-prefabs
   -bad usage
   -good usage
   -managing object scale
-scenes   
   -as level editor
   -"parsing" a scene for game specific content
   -memory limitations and how to get around them
-project management
   -file organization
   -asset management
      -when and when not to to use external resources and how
   -editor scripts and constructing your own pipeline
      -when and how
-specifics
   -unity for 2d
   -unity for phyiscs games
   -screen effects

This is sort of a "what is A right way to use Unity when trying to make larger programs" or possibly "how NOT to use unity when writing large programs". It attempts to offer alternatives to many of the implied best practices which really are not conducive to writing large programs in Unity. If I could summarize this book in one line it would be "don't use unityscript" and possibly "if your scene hierarchy has more than one essential thing in it, you're doing it wrong"

I wouldn't mind a collaborator or an editor or just someone to stupidity check some of my theories if anyone is interested.

Most importantly though, I'm probing for interest. I feel that this might be a silly thing to write because by the time you reach the point where you might want a guide like this, you would most likely already have some theories on how to go about writing a scalable program in unity, which may or may not be any better or worse than my ideas.  Also, I literally have not read a single Unity book or guide since I started using Unity. I have glanced at indexes, and all the books I've seen just do a chapter by chapter usage guide of all the Unity features. But perhaps there is something similar/better than what I want to do here.

[Sergi]

Do it! I use mainly Unity, and coming from C++, it feels weird sometimes because I don't know if I'm doing something really stupid or inefficient, etc., since I don't know what goes on behind the scenes. Over time you learn a bit of best practices, but it would be nice to have it all more or less in one place.

You have a lot of experience with Unity, I assume?

[cmspice]

I've been at it since velociraptor safari days. I sometimes really do hate every time I start a project in Unity because I feel I'm locking myself more and more into their system, but really it's just so efficient both to make and release projects in Unity that I'd be stupid not to be using it.

Unity implies a certain usage that is very very good for prototyping but makes for code that is too tightly interlinked with the scene. I use to follow this approach and even finished a few projects but always ran into some sort of coding/refractoring hell trying to keep track of my scene dependencies, script execution order, and game logic flow in general. Every project I start now usually only has a single item in the scene hierarchy with any sort of script attached. The editor is used only for positioning objects if needed. I use a script to sweep the scene and pick objects to attach monobehaviours (for things like catching collision callbacks) if needed. I'm sure many will disagree, but this is my Unity philosophy that I definitely think is the best way to go about making projects with any sort of complexity.

The popular Unity approach (attaching monobehavirous, using the editor to create references, etc) has severe limitations in scalability but that doesn't mean Unity itself has these limitations. I think many users run into these limitations but don't know what the right way to work around them is. I guess this guide is designed for those people.

[Sergi]

I've lately been working on my own set of scripts to build a kind of "framework" or "engine" on top of Unity (just my bunch of common code between projects to speed things up). Basically for 2D stuff. When I started I tried to create custom editor scripts and all of that, and wasted a lot of time. Now I scrapped that and just do everything by code.

My scene (before starting the game) consists of just one GameObject. This one creates everything needed when running the game. Now everything's in code, and I feel like I can control more. I still don't know whether that makes sense, though, but I'm trying it out.

It seems weird because you feel the pressure to do most stuff in editor, and minimal stuff by scripting, so it seems like I'm fighting against the waves. But I see it like this: I'm making games by code, using Unity as an engine that would let me export to a bunch of platforms, and on top of that, it's a godsend for debugging (pausing the game and inspecting everything, drawing stuff for debug, manipulating the scene on runtime...). I can also use the editor for placing things or tweaking parameters on runtime, and then saving them to code.

So I think it's more or less the middle ground between both ends (pure editor based Unity, and DIY C++ code). I'm still not sure if I'm doing the right thing, though. We'll see.

I'm interested in what you can say about this kind of way of using Unity.

[cmspice]

I think bypassing Unity's preferred mechanisms is never a bad idea since you can always fall back when needed. It is in general a safer choice. I do find myself often rewriting a lot of Unity's high level features simply because I  don't like them when they are often times perfectly sufficient for what one needs to do. For example, I tend set up my own callback mechanisms but Unity's "SendMessage" functionality is actually not a bad choice especially for single shot events.

[Pishtaco]

I would be very interested in something like this. I'm currently working on something in unity that is meant to become large, and I'm already getting slowdowns that I don't understand.

However 50 pages sounds like a lot of work. Shorter articles would be very useful too.

[forwardresent]

Slowdown in Unity is such a pain.

As a C# Unity student making awful little prototypes, I'd love to read anything really about C# and Unity.

[Valerien]

This would probably be interesting for a fair part of the unity community, as optimization or usage of specific components can be an issue even in small projects.
Now, we've been working on unity with a programmer since not so much and there are already many many learning resources on the web. You may have an easier time compiling data on a blog or so rather than writing a guide from scratch.

[Reyold]

Yes, PLEASE do this. I'm planning on using Unity, and I need all the help I can get. And I'm sure I'm not the only one.

[EdgeOfProphecy]

This would make a good read, and I'm sure there are lots of people who'd be interested in it.  I'd certainly be interested in it.

[jonbro]

yes, I would also like to read this book. I am just switching over to unity now for things outside of jams, and it would be great to have some direction about how to do things properly.

[megameta]

Please, please do this. There are far too few tutorials for advanced scripting topics in unity.

[Saishy]

Hi,

I'm also developing scalable games in Unity and would like to give you a hand on your project,
contact me if interested! (pm or other contacts at my website in my signature)

Cheers.