How much should scripts be broken up?

Agreed.

 

I was definitely not looking for a specific answer, but the combination of everyone's replies gave me a better idea. I don't believe this debate is silly at all, it is an important skill in any code to know how to organize it into logical divisions and how much it should be organized - which is the whole point of this topic. Being an industry standard isn't really as important for the new people who are going to read this - the real thing that matters should be how much should it actually be broken up depending on the situation.

The whole reason I made this was because I saw a lot of tutorials breaking things up unnecessarily - and not in a very organized fashion or with a lot of logic, but rather randomly - but I understand their intent and now I can better organize my own code.

 

An excellent reference on this very topic is the book Head First Object Oriented Analysis and Design, which explores in great detail how an application should be organized, and why. Also I like the style of the Head First series. And I've been teaching programming for over 10 years now, so I've seen a lot of texts on the subject.

 

Be careful. You can miss out on a lot of the benefits of OOP with this thought pattern. Container for code sounds a lot like the old procedural programming days. There are even perfectly valid extention methods that include code not even part of the class.

It's often better to to think as classes as things, or objects in your programme. They have some publicly available data, in the form of properties. They do some stuff, in the form of public methods. Everything else inside a class is magic. We don't care about it, unless we are working on that class, in which case we care intimately about it.

You should be able to hold the entire content of a class inside your head at one time. If I'm working on my player movement class I should be able to hold every piece of how the player moves in my head. Doing otherwise is a recipie for bugs.

Trying to hold the code for the camera follow in my head while I'm working on the player movement is difficult. Trying to hold a 2500 line script in my head is a recipie for insanity.

Even on related things, like mesh generation and triangulation, it often makes send to split them into seperate classes. I can worry about the mesh, and the triangles happen by magic. Later the same thing happens when I actually code the triangulation class.

There is a lot to be said for using magic in coding.

 

I can't speak for Daemon, but I'm a professional software engineer with a degree and 15+ years of experience and have worked at quite a few large software corporations before deciding to take a go at being an indie, and modular architecture is indeed an industry standard. In fact, modularity and code re-use is more or less the entire reason that languages like C++ and all the later OOP languages were even invented. The whole point of a "function" is that it lets you have a chunk of code that you can call into from other places, so that you don't have to copy/paste it everywhere. Copy/pasting is almost always a terrible idea, especially if you're working with other developers, because if you really want to ensure it's the same code, then whenever one person finds a bug and fixes it somewhere or needs to change how it works somewhere, they have to go and search the entire code base for every place you might have copied and pasted it and change it in all of those places as well. Avoiding that is the whole reason functions were invented. Classes and inheritance were invented specifically to let developers think of sections of code as objects and have them re-use the parts they have in common with one another while keeping the code all in one place, rather than copy/pasted a hundred times. A class isn't just a "container for code"; a program is a container for code. A class is a concept that was created to allow reusable code to be organized in a modular hierarchy instead of spread all over the place.

 

It is good to write DRY code.

 

I just want to make clear to you _Daniel_... this isn't saying you're wrong to do what you do, just to explain what this practice entails.

You're not writing OOP.

Plain and simple.

A class is a lot more than "a container for code", it is a mechanism that facilitates design of a project overall, a class can have a large impact on your project and your code. It is part of your code.

If you just treat them as simple containers for code... you're just not writing OOP. And that's fine and dandy! But don't be surprised when people who do write OOP don't agree with your statement that "a class is merely a container, a holder for code."

 

I think the main reason those tutorials were terrible not because they had 10-12 scripts for one object but that each script had their own Update(), fixedUpdate(), OnGUI, etc. - I can't imagine this helps performance much when it is easier to create a 'manager' script that updates any component scripts with only one Update() per manager class. The tutorials were treating each component class as if it was its own GameObject that would never seemingly have interaction with other components. - While that might make it more reusable, it's got to be terrible for performance with that many Update/fixedUpdate scripts running

 

I think he was trying to put it in simple terms, not trying to say that it is only a container.

 

Noooo, from what _Daniel_ has said through out this entire project. They don't appear to follow most if any OOP standards really.

Like I said, that's fine, it's just not OOP.

 

From what I read he just has different opinion on how far OOP should go - how a module should be used, not that he's not using OOP at all. Encapsulation is still a container, even if it used for nothing beyond that it is still OOP.

 

yeah, and that opinion is to NOT use OOP.

You probably don't know what OOP entails... so, I'm here to tell you. Their opinion is NOT OOP.

That's fine... OOP is not the end all, be all, programming paradigm. There are several others, and they all accomplish quite a bit. You don't have to write OOP.

Which _Daniel_ is not. The only OOP they're writing is that which they're forced to by the .Net/Mono framework and Unity (that being inheriting from MonoBehaviour so that it can be used in the component design pattern). But they use it merely to hook into the application and otherwise write their code as much in a procedural paradigm as they can get away with.

 

This kind of goes exactly opposite to all your arguing that enormous thousand line mega-chunks of code are fine and that breaking things out is bad. Weren't you just arguing that it's better to copy/paste the same 3 or 4 lines of "health" code into both player and monster classes rather than breaking them out into a shared component?

 

Which leads to multiple small modular classes. Or some weird stuff where every time you are putting methods that are common in a single common mega class.

 

He prolly meant use the inheritance model to do so.

For the most part I use components and share them, though a lot of my components do inherit from some abstract class that contains common bits.

 

Sure, I agree with that. That's why I said it's something to learn after you've got lower-level stuff down. The thing is, just because someone might not be up to that yet is no reason to generalise it as "not relevant". It's perfectly ok for someone to write code without architecture if they haven't learned that yet, but they should still be aware of it as something to aim for. If they're not aiming for it they'll never get there, and they'll miss plenty of important lessons they could be learning purely because they weren't aware about what to pay attention for.

 

Not sure I do. Modular coding by adding three scripts is no more difficult then coding by adding one monolith. Sure expecting muli layered inheritance or interaction through interfaces is beyond a beginner. And forget IOC or dependency injection. But modularity is easy.

Even the most humble beginner can understand the idea of single responsibility, and use it to great effect, if they are told it's worth doing. Every beginner is capable of logic like the following:

"So I need to put everything related to shooting in my gun script, moving in my move script, and damage in my health script. Why? Because the veterans on the forums and the tutorials told me so. I'll figure the details out later after I stop getting all these null reference errors"

 

Oh man, the ad hominem attacks. First off, not says me, says just about any experienced programmer. It's not industry standard in programming just to be difficult, but because programmers that make us look like morons came up with this stuff. Second off, my experience with software engineering is that I got my first computer, an Apple IIc, at the age of twelve, the first floppy I put in was tutorials for BASIC, and I've been programming ever since. So just about 23 years of working with everything from BASIC to Forth to C, on everything from the Apple IIc, to Atari ST, to Commodore 128 (bit of a step back there, but a fun one), to the 286 and on. Y'know, a little.

What is your software engineering expertise?

You can absolutely tell beginners to write modular, flexible code. That is how they advance beyond being beginners to being fully fluent, object oriented programmers. If you teach beginners to write like it's procedural, they remain caught in the procedural paradigm, and (for example) think of classes as nothing more than "containers for code".

 

Good point.

 

Agreed there, too. There's more to design and architecture / making code modular than *just* splitting stuff up. Taken one learning step at a time it's pretty digestible, though, and splitting stuff up is an important step.

 

Sure, if you take the concept in isolation they might do that. The thing is, people ask or read about these things because they want to learn and improve, and I'd rather have faith in their ability to do that than tell them not to bother in case they have a few stumbles along the way. And, by the same token, they can also too much emphasis on this stuff being "not relevant", which will lead them into problems of its own. (And those problems, in my opinion, are likely to be somewhat worse.) Any tool needs to be used appropriately, and any tool used inappropriately can lead to issues.

If you're worried about people getting hung up over "how many scripts they have" as a result of considering how to break them up, why are you not also worried about them getting hung up over how many lines of code they have when taking your suggested approach where "the actual code" is the primary consideration?

If your answer is that it's about having the right code rather than having more code... the exact same thing applies to splitting stuff up. We're not talking about "how many scripts they have", we're talking about "having the right scripts", and there most certainly is a point where it's time to stop focusing on just "what the actual code is" and start thinking about just how they'd like things to go together at a higher level.

As a coder in a team I'd even go so far as to say that as long as everyone is competent "what the actual code is" is not "the important part". It's an important part, but if your team is good at "having the right scripts" then the details of the code inside the scripts becomes far less of a focus at the team level.

 

For the sake of discussion, why would you prefer inheritance over composition? I used to be an inheritance person myself back in my university days. My first large game project cured me of that - I do still use it, but only in very small hierarchies dealing with a single concept.

For this example, I personally wouldn't use inheritance to get Health as a concept into two different types of Character. The first issue that pops into mind is that Health as a concept is neither unique to nor uniform across Characters - things that aren't Characters can have Health, and it's pretty common for a Character to not have (or deliberately ignore) Health.

The second problem is that there's no clear hierarchy as soon as you chuck other concepts into the mix. For instance, Characters can probably move, and if we're going with inheritance then it makes sense that Character should probably also derive from Movable. So how do we resolve that? Does Health derive from Movable or does Movable derive from Health? Neither conceptually makes sense as the concepts are unrelated, and either approach ties one into the other. We could go for multiple inheritance, but there are very good reasons that C#, Java and other modern languages explicitly choose not to include that feature, and it's only a partial solution anyway.

 

I favour composition nominally. But it works best with a bit of inheritance in the mix as well. Going back to the health example, I'll often use a Health component, or a component that inherits from health, as part of the composition. This approach allows you to build various different types of health components that can be quite different, but all behave in a similar fashion.

You can also do the same thing with interfaces. But as yet Unity doesn't always play nicely with interfaces.

 

Just a few things to consider...

There is no single "correct" approach.
There is a constant tradeoff in designing for change or reuse as opposed to developing for efficiency and simplicity.

Every time you add another class, and every time you reuse it, you are increasing the complexity of the system. You have to manage the connection and dependency. If you change a class that is used by 10 other objects, then you have to make sure changes to the class work in those other 10 instances.

Change is inevitable - knowing what will change and planning for it comes with experience.

If the currently planned behavior is specific to the entity, then don't try to make it a loosely coupled reusable object. You will end up fighting yourself the whole way.

For example, just because the ogre has health and the player has health does not necessarily mean it makes sense for them to share a common health component.

The more generic something is, the easier it is to reuse it, and the more likely it is to be reused then the more it makes sense to split it into a separate component.

If the animation behavior is intertwined with health behavior, then separating them can lead to highly-coupled code. If code is highly-coupled it is less likely to be reused anyway.

Do not waste too much time over-engineering and planning for reuse.

And do not blindly follow the design mantra of the day. Make your own opinions by learning from experience.

The best software is the software you love to work on.

Discussions like this can be valuable - as long as they don't promote blind acceptance.

 

I wasn't aware shipped products dictated skil or knowledge. I would love to meet the end user that could be as critical of my own code as I am. But no, I've no "published" code. I also have no college diploma, for that matter, before you call that one into question.

The fact of the matter is: when I started, you had assembly and BASIC, and both were treated procedurally. I spent ages in the procedural mindset, and C was a mind blower for me. OOP was a completely different way to think. The power of OOP is flexibility and modularity, and you're arguing in favor of ignoring that power.

Argue away, my piece is said, but every professional piece of OOP code I've seen argues against lumping thousands of lines of code into a single class.

Only if you fail at teaching them a proper sense of when, why, and how to divide the pieces of their program. And if you teach them that less lines is better. Small files aren't the product of a conscious aim for small files, they're the result of coding for modularity and flexibility. Not to mention self commenting, easier to read, easier to manage, easier to debug, easier to reuse.

Other than that, I guess there's no real benefits.

 

I feel left out! No one has challenged my credentials.

I have a years worth of hobbyist programming in Unity. And a few month in high school and primary school dabbling with basic. As to 'shipped' products I have: A couple of VBA applications (or extentions) in excel and access, because work didn't want to pay any one to build them, and I wanted them. One game on Kongregate, two hundred plays and 22 cents of revenue. And YouTube tutorials with 7000+ views.

Not sure what it says about me that I've had far more success teaching Unity then making games. There was the old adage from the university days "Those who can, do..."

Feel free to return to the topic at hand.

 

I recommend the SOLID principles.

 

It's not this simple, BUT ...

From: http://unity3d.com/learn/tutorials/modules/intermediate/scripting/coding-practices

I was going to write few paragraphs detailing my philosophy but decided against it ...
This covers it :

from: http://blog.codinghorror.com/coding-for-violent-psychopaths/

 

That's putting it backwards. The point of splitting up code is to reduce and eliminate dependencies. For MonoBehaviours if you need dependency then you can make it self documenting and self correcting using [RequiresComponent]. Each component should have a narrow, well defined API, preferably implemented as an interface. This all has the effect of reducing dependencies.

Using a monolithic script will end up with far more dependencies in your code then writing smaller, modular scripts.

 

Yep. A class is naturally dependent on itself, so putting more stuff in less classes increases code dependency, even if the number of dependent classes is reduced. For instance, if you stick both movement and weapon handling in a Player class, then those bits of functionality are dependent on each other even though it's not a class dependency - wherever one goes the other must follow.

Splitting stuff up into multiple components doesn't suddenly make dependencies an issue, it just makes you aware of it, which is the first step in learning to better manage them.

 

And it gets worse. You start using variables and methods that relate to movement to control weapon handling. Then you decide to change how movement behaves by changing those members and suddenly you weapon handling is busted. Throw a dozen systems in one script and the problem continues to get worse.

 

Haha, I was giving readers the benefit of the doubt by assuming they're disciplined enough to not take shortcuts like that. (Or "optimize" like that in anything but the lowest level code, given the abundance of memory these days.)

 

Lots of good information in this thread.

 

Of course.

 

Usually it's good to split up big scripts into small ones.

 

It should be more of a design time tool than a code time tool. By which I mean, typically you would code to match a diagram, rather than draw a diagram to match your code.

 

I occisionally draw one. Most of the time my class structure is not complex enough to warrant one. I tend to let Unity's structure do most of the heavy lifting.

I do find them good for cementing difficult concepts or structures. But by the time I open the editor the code structure is pretty obvious.

 

Agreed

 

Their most important use to me is a decision making tool at the design stage - it helps a programmer or team to quickly plan out the structure of code, or evaluate a bunch of different proposed structures. It also helps communicate that structure across the team.

 

To begin with I haven't read all the entries in this post.

Tutorials
They often only have a single thing to teach you. It could be how to rotate a camera, moving an object, change the color etc. but they usually show it in a easy and understandable way, not how it most likely would be in the real world.

Breaking up the code
I can't say how things are done in Boo and UnityScript. However, the usual thing I do is creating a single class for a single purpose. The concept is easy to understand, the hard part about it is deciding how to break up a big singular purpose into smaller ones. Here is an example.

A compiler has only one purpose, to compile. You could have one class for the whole project, that would be fine for a small language like BrainFuck (it's basically implemented using a switch), but one class for a C# would make you throw your computer out of the window. In a C# compiler, just for statements you would probably have an abstract class called Statement and one for assignments, for loops, while loops, returns and so on.

I have few points with this. Your class should do one thing and do it good. However, even a single thing can become complex. When this happens, split your big method into smaller ones. When that simply won't do, collect the groups of methods that work together into their own class an reference it in the class the methods came from. There isn't a foolproof algorithm for doing this, it is one of those "it depends" things.

I hope this helps you. I would like to recommend looking into Martin Fowler, he writes a lot of cool stuff about OOP. Also look at the book called Dependency Injection in .NET by Mark Seemann.

 

I know what you guys mean when you say "one idea per class".

 

Obviously things vary depending on the game, and there are instances where breaking out a class is not a black and white decision. The rule I would use is 'Can you describe the task the class is in charge of a single simple (aka not compound, not using 'and' to break up predicates) sentence?

'Class A controls the player'

Far too abstract - what does it DO?

'Class A lets the player perform various actions and manages his health bar'

Getting there, but still a bit abstract. But we can start splitting at the 'and'!

'Class A controls how the player moves around and how he can shoot people'
Class B manages his health bar.

A bit more splitting....

Class A controls how the player move around
Class B manages his health bar.
Class C controls how the player can shoot people

Now yes, people could try to get more specific, such as 'Class B raises his health bar and lowers his health bar'. That's just a value differentiation, I wouldn't consider it separate tasks. But, Class A lets the player run and jump.... that might depend on how the connection of the two actions is related on whether or not the class should be split.

Finally, another rule I use is 'If I could give two different developers these tasks and expect them to complete it without communicating with one another, they most definitely belong in separate classes. That doesn't imply the reverse, that communication required means same class.

 

I can contribute nothing but feedback to those that have shared their ideas, concepts and beliefs. Thank you all for having a constructive discussion. It has been and continues to be an excellent read.

<chair begins rotating 180>
"fascinating"

 

Deciding when to split up classes is a judgement call, but one based on concrete principles. It's affected by a lot of things, but file size shouldn't really be one of them. Small(er) classes are the result of good coding principles, not the other way around, although good coding principles can lead to extra code too.

If you plan well, and know which design pattern you're implementing, you should have a decent idea of what classes you'll need, their relationships, and their intended functionality. Once you've taken into consideration the scope of your project, you should have a pretty good idea what classes you'll have, what their purpose is in the grand scheme of things, and roughly how big each one will be. For bigger projects, a flowchart can help you visualize each prospective class' relationship to the other classes, and their interaction.

 

I can definitely see the advantages you get from breaking code into classes with distinctly different functions, but I still have the same worries as @ezjm427 about the actual performance of gameobjects with many script components that have Update() functions.

Wouldn't you have higher framerates if you combined the Update() hook of all gameobject script components into a single class?

 

This thread was hilarious and entertaining. Thanks for bringing it up so I could read it. Understanding the benefits of the Single Responsibility Principle is an important step in a software developers career.

To answer your question: No. There is no real-world performance impact of several Update() calls on various components vs one Update() call on a monolith class. Perhaps, if you were able to combine several thousand method calls into a single (long) method call, you could shave a fraction of a fraction of a millisecond off your frame time, but that is not a real-world case since most monoliths will be split up in to a few dozen or so classes. There are likely far more bottlenecks in your application than the separation of Update methods.

 

ezjm and _Daniel_, you may want to take a look at Clean Code, a book written by Robert Martin (a.k.a. "Uncle Bob"). It discusses a regime for highly readable code, and I should stress that that is really a big deal... you spend most of your time reading code, not writing it, and there are certain practices that can make reading your own code (to understand how to go about making changes) easier.

So think about this in terms of "How can I write scripts to accomplish X," in which case you might think having a single script for each game object would work... but rather "How can I write scripts so that when I need to debug or make changes to my game, I can minimize the amount of time I spend trying to figure out what the hell my code is doing." And the bent toward smaller methods and smaller classes (and hence more scripts) is fundamental to that.

 

Quite the necro here Though, I do feel like you make a good point, and while I feel the book you present does give some context to the why's, the how's can be simply implemented by proper code analysis as it seems to be mostly about style, and style cop is really good (sometimes I feel like it's TOO good) at forcing a globally used style of programming.

 

In my experience (I have no professional experience in software dev, but I do have a lot of programming experience) if you're copy and pasting code verbatim and in large to different places then perhaps that code would be better encapsulated. If you can just do: Function(); every time you need that functionality then its always a better idea. When software is as complex as it is its always a good idea to keep individual parts of it separated and reusable.

Unless you're infallible you will eventually mess something up or forget to copy & paste the whole thing or just make sure things are done correctly.

Come to think of it; I have to wonder if my game's scripts are too big and complicated now. In fact I can think of one class which would benefit from more encapsulation and cohesion. Its 450 lines, I think. The main players script could be made more generic so that when I get to implementing AI I don't end up copy and pasting code between the main players and the AI script to create the same control interface.

FYI: cohesion is a concept involving the breaking up of code in to smaller bits and pieces. Its a judgement call kind of thing. If you break the code in to such small and pointless parts that you can't replace one or two of them with new code; you have a problem. There is the converse too (no cohesion).

 

You don't need to create a class for every function! Consider the single responsibility principle (SRP)