Do you create a 'Game' script with everything in?

Normally, when making simple small games I create a 'Game' script that handles everything.

On my larger projects, I tend to create a lot of small scripts, but lately I've been thinking I should add them all to 1 'Game' script as I'm now starting to struggle to find where things are in my scripts.

So I'm just wondering what you guys do?

 

Big manager scripts are a no go for me.

I find Unity works best when structured as a 'robot swarm'. Lots of little scripts that work together for a big effect.

Managers just tend to add unneeded overhead.

 

Unity is component based, throwing everything into 1 script will definitely work against you in the long run. For example I had a script for a tool that was 2500 lines long. Sure I just had one script, but this is a real pain when extending the script. It's better to split your script into separate functions and let them all work together. The art is in deciding how you split up these functions. You don't want to create a script for every single function. For example in my tool I often need to export stuff, so I have one script called 'exporting' that has 3 functions, one for exporting to prefabs, one for assets and one for fbx.

 

You mean a grand total of 1 script for everything in the game? Or a game script that handles all globally game related things, such as level loading, enemy spawning, saving game state, gui, whatevs?

Either way, you'd still want to split into reasonable categories. But hey, whatever works for you. I've heard some oldschool people will grab Unity and script 5 games into one, using 1 script. But maybe it's just a myth.

If you have way too many scripts, you MAY have a problems related with execution order.

You can control execution order in Unity, but you can only establish order per script. But you have no say about which object's script runs first, if it's the same script.

Also, I would like a better way to find where's the script int he execution order. I had like 200+ scripts in my game, and at some point when I wanted to edit execution orders, it was always kind of a pain to find it.

 

@dogzerx2 the execution order should be less of a problem if you properly use your Awake and Start messages

 

I think my execution order problems would go away if I was a good coder.

 

Rule of thumb, use Awake to initialize your component, and setup all of its references and do anything that does not involve accessing data and methods on other components. Use Start to do anything needed on other components.

 

I have practically everything in one big script in my current game. In other games I have had lots of small scripts scattered around many GameObjects. Each has suited me for the particular projects.

 

I meant a script that handles all the game kinda things.

 

You should do it the way that works best for you meaning the way that is most comfortable and creates the smallest number of issues.

How you actually implement it is entirely up to you. If it works it works. Doesn't matter if you have one class or 100. Use OOP or don't.

 

Ultimately I will do it the way that works best but it's nice to find out if anything is considered the normal way of doing things.

 

Well it depends if your working with programmers or not. But i usually have a bunch of managaer scripts that sit on the same gameObject but arent the script.

 

No. Never. "God classes" are an anti-pattern that is best avoided.

 

I tried, once. Ultimately, with how Unity works, it was more of a pain to get the script itself to a manageable state that it was to just use a bunch of components.

 

My current project is barely over 5k lines big, but it already contains 150+ .cs files. Probably, it's a bit extreme to split everything into such tiny pieces, but from my experience it's much better than to have a few unstructured, gigantic classes which can be justly called an 'anti-pattern'.

 

That does seem kind of extreme averaging 33 lines per file. Seems like you are creating a new class for each new method you write.

Not that I'm knocking it. A person needs to do what they enjoy doing. That's the conclusion I came too. Years ago I thought oop was the best thing of all and anything else was not "real" programming at least not professional. Then interfaces over inheritance. Then DI. And so forth. And finally now I have come full circle and highly favoring purely procedural straightforward architecture at this point. Next year maybe oop again. lol

There are pros and cons to everything.

Lol it's funny in my current project I am taking the exact opposite approach to yours. Normally I break the program down into a number of files. At the start of this project I thought... you know this is just a matter of perspective... a logical separation and I remember long ago achieving the same thing in a single file. So I made the decision to use a single file for this game. I do organize the code into sections in that file as well as by naming conventions and in this way I find it as simple and even a bit faster to work with than if it was scattered around in many different files.

Granted the entire program is less than 1,300 lines at this point and I expect when done it shouldn't hit even 4k.

 

Probably it's because I have a lot of interfaces with only a few methods in, and I have a habit of over engineer everything so that might have been a factor too

And I definitely agree with you that it's more a matter of personal preferences. I'd advise a beginner in an OOP language to avoid using a 'god class' because it's a practice that is commonly regarded as an anti-pattern. But once you understand why some approaches are generally considered a best practice, and why others are the opposite, I believe it's up to individual developers to try to make their own way that works best for them, which doesn't necessarily be a traditional OOP.

Probably, it might be a bit of a problem when working with other developers, because it's easier just to tell them to follow such a convention since it's a best practice than to explain some in-house rules that are peculiar to the project.

But it's my understanding that the traditional OOP is not that popular even among experienced game developers anyway, and there seem to be quite diverse approaches, some of which are Unity specific.

As such, I just concluded that the internal consistency might be more important than conforming to some existing best practices, so I wouldn't be surprised that you have found your ideal approach using the way you described in your post.

 

I think if you're working on your own or in a VERY small team, then you should do whatever works for you or feels comfortable. Don't worry about design patterns, or best practices, etc. The end result should be to create a game, not to create textbook elegant code.

On all my projects I use a combination of (a) 1 class that's global to the game, (b) a handful of classes global per scene, (c) traditional object-instanced classes. Works for me.

 

1 class for an entire game is far too much for me to tell you to do "what works for you". Even worse if you start thinking about doing for large project! For me it's a big "NO NO"

There is general best practices for good reasons, having a 1000+ line file usually means you are doing to much in it. A class should ideally have a very specific purpose, this is easier to manage and debug, not only right now but in 6 or more month if you go back to your project or have to share it with someone.

If you have a desire to get any better at coding i would suggest you try a more organized way and follow best practices. It's a waste of time to do things the wrong way, you will keep doing it and not learn much, you will hit issues when stuff start to be more complex and everything breaks.

You don't have to do everything perfectly but at least try to make components works by themself and then put them together on some gameobjects.

There is some learning to do but ultimately you will save a lot of time by structuring your projects.

If you really can't find out how to organize yourself you can try to force yourself by using something like Entitas (can be kind of hard if you have not much coding experience).

Now if you are an artist and plan to replace stuff with the help of another programmer and this is just for you to pitch it to them or something and you don't care much about bugs and have no desire to be any better at coding then obviously you do as you want, developer art are a thing (we all know how that look) and there is "artist" scripts.

 

Some of the reasons include

• To fix issues created by using other best practices
  
• To keep the industry always active... always one more certification / training to sell
• To write an article or book and share a developer's opinions or worse a white paper to share a non real world ideal to strive for... and unfortunately this becomes accepted as "a thing"
• To facilitate development of very large and complex software the person has no need to be building to begin with

There is good in the best practices for sure and it is also important to look at the full picture.

@mysticfall I think hit it on the head the main thing is strive for consistency. I would add "and simplicity". A lot of the cost in software projects is directly connected to developers love to over complicate everything just because it is fun and satisfying to them.

If a person strives for consistency & simplicity I think most of the other problems won't show up or if they do will be very manageable.

It's when a person sets out to build a hangman game and their mind immediately goes to how can they build ultimate dictionary system... one that is auto-updating and then they think they want to provide tips for the player and also offer a competitive mode against the computer. So they decide they will also build an advanced learning machine AI system for those things.

Point being the bulk of software problems begin before a person writes a line of code or even thinks about how to structure their program.

 

This kind of thing also really depends on the scope of the project and code base itself.

I think one problem with going super extreme at like 33 lines per file is just running out of good names. You just run out of good nouns to describe similar ideas at some point and you end up just cramming words together into 50 character compound monstrosities like AbstractInterruptibleBatchPreparedStatementSetter.

To some extent, if you just pay attention to how you name stuff, it can really tell you if what you're doing makes sense or not.

If the scope is small enough that at 33 lines per file, you still have good, clear, descriptive names then you're probably in good shape. If the scope grows and suddenly your average class name is 35+ characters then something went wrong.

 

It really is up to your preference, and what you find the easiest to understand and maintain.

Personally, I prefer a mix of "classic" and "Unity component swarm" methodologies, with managers tying things together.

I typically have something called an AppManager that handles administrative tasks: saving/loading, logins as needed, handling preferences, etc. I'm also refining my UIManager for handling switching between menu panels and such, though I should point out that each individual panel gets its own MonoBehavior script that handles tasks specific to that screen.

Other managers that make sense (for me, at least): MusicManager, CharacterManager, WorldManager, GameTimeManager. But that's all depending on your own needs, and these may not apply to you.

The component swarm is fine and all, but I just like to be able to organize things and know how to access them quickly and efficiently. Oh, and I also started using @LightStriker's great (and free!) Universe plugin for handling my managers, and highly recommend it if you want to use singletons.

 

I can't agree, i have been in the situation of @derkoi . Long ago when i started dev i was writing thousands of lines in singles files and then i learned OOP (that was more than 10 years ago) and many more things along the way. Nowdays i can code stuff faster and it feels easier, the code i write today is not necessarily more complicate than what i was doing before if you take it line by line, but i can write more powerful system than before with actually less efforts.

Not only that, there is a lot of redundant boring part when you code (game or other app). When you start writing clean and manageable code you will be able to reduce those annoying things a lot and focus on the "fun" stuff instead, it makes a coder a lot more efficient if he likes what he is working on


I can't tell someone, that obviously is doing it wrong (no offense), to keep going and tell him it's up to his preference and it's all the same and fine, because it's just not. If he want to be a decent coder some days it's just bad advice and he should try to understand why there is better ways. It's for his own good IMO. Now if that's not his goal then yeah whatever he wants i guess.

I'm not saying to go crazy on patterns and such, but there is a lot of possible improvements from "doing it all in 1 big file", just try different methods to learn and get better with each project and then you can start to make some choices and have "preferences"

It's like cooking and just putting all the ingredient in a pan and call it a day... Once you know how to cook each ingredients the right way you definitely end up with a better dish.

 

I really like cooking analogies for code.

 

There's a very influential, and inspiring classic called "How to Write Unmaintainable Code", which I think every programmer should read.

It suggests a very creative solution to the problem here, which practice I sometimes feel tempted to follow when I'm out of a good name for my shiny new class

On a serious note though, I think I've just gotten used to the practice of splitting functionalities to such an extreme level. It's especially practical with a language which supports composition of interfaces because it's very easy to create a larger whole using such tiny components. (I'm not sure how the hell C# doesn't have such a feature already when even Java does. If you are interested, you can read about it and vote up the issue here.)

By the way, I got curious so I checked the stats of my other project which contains 1,800 source files and it says each file has about 88 lines on average. Considering it's a Scala project in which a single file tends to have multiple types, I guess it should be close to 30 lines per type which seems to be my personal comfort zone, and it's more or less a maintainable practice for larger projects also.

 

This is an enormous blunder and should never be done. God-classes are a significant scale and maintenance risk. I've personally had to fix projects that do this (offshore outsourcing) and it was the absolute worst experience to work with, eventually leading to scrapping everything they had and doing a full rewrite with proper architecture.

The concept of Manager classes is good, as long as you use them correctly. For instance NetworkConnectionManager, or PlayerManager, etc.

 

I think 88 lines on average is closer to reasonable. To put this in perspective, if you maintained 30 lines per file the other project would have nearly 5,500 files.

Generally I think there's kind of a sweet spot at around 125-150 lines average (in c# - it will vary from language to language), although it definitely changes depending on a billion other factors.

 

This is true. In general there really is a comfort zone and while I am sure it varies wildly from person to person basically it all comes down to scope in the end I think. I guess my view on it is I'm not seeing any more value from having 100 files with 100 lines of code in each than having 1 file with 10,000 lines in it IF the code in the single file is all organized.

Having a hundred or more files to dig through can create complexity where there was none. Granted any relatively modern code editor has some nice features to help us jump directly to the code for a specific method no matter which file it is in. But I see it like the same is true if the code is all contained in a single file. So it becomes a matter of where exactly is this bit of code at? In the same file or in one of many other files.

Actually thinking about it more... I believe the reason I made the choice to put everything into 1 file and only 1 file for my current project is simply because it is something different. Sometimes it is refreshing to just do things in a different way. I've not run into any problems yet with this approach but again I haven't quite hit 1,300 lines yet. I just don't think it will be a big deal though.

I mean at one time long ago most code was along these lines and these days the code editors are much improved. As long as I can easily find the given section of code I want to review or update... well I don't need any more than that. I'm not focusing on making systems just for the sake of it... only focused on the game itself.

I also feel that by programming this way (i.e. single file and not using oop) it actually greatly reduces the tendency to over-engineer things. It's interesting.

 

While I am all for doing what works for you, there are some concepts that are important and which will save you a lot of hassle when it comes to bugs.

For example, encapsulation--limiting data and behavior to the object to which it pertains. The problem with the "one script for everything" is that all of your game objects will have access to all data and behavior, even when it does not and should not pertain to them.

So now when you have a bug, the list of places to track down the error is literally everywhere. Yes, you could argue that if you are working by yourself, then only you can create such errors. But that argument presupposes that we don't make mistakes as programmers. Encapsulated data and behavior prevent us from making those mistakes.

I would also argue that proper use of inheritance and composition are important since this helps you eliminate redundant code and reuse logic at a higher rate. This means three things: First, you will write less code. Second, because you are writing less code, you will create fewer bugs. And, three, when you do have a bug, you only have to fix it in one place.

Lastly, while you may be working alone now, that might not be the case in the future. If you throw common/best practice out the window and then need to collaborate with someone down the road, you are going to have problems. No one is going to want to wade through you 50K line script to figure out how it works.

 

I think programming like most other areas has rules.
You start out not really knowing the rules but you try to learn them and follow them.
There are different parts of the rules or strategies that you learn.
Then after enough time of playing by the rules you learn when to break the rules.
And mix them up.

To follow a single pattern in an application or design is not a good thing.
You should pick the best pattern for the current feature or task.
If you don't know what that is then research and try one. Better try a new one you haven't used before.

In most of my projects I have a bit of everything.
My editor scripts and tools tend to be much larger.
Then my manager classes, which I try to spread the work around if possible into smaller parts or classes.
Then for common repetitive things or common logic those tend to be smaller and more object oriented.
Other times they are very component based with events and references tying them together.

I will agree there are probably not too many perfect ways to do things. But there are a lot of better ways to do things.

 

this kind of thing (lines per file) really does come down to a lot of personal preference. honestly I don't think it really matters nearly as much as some people tend to think.

It will also vary dramatically depending on how heavily something is commented, how much error handling there needs to be, and even stuff like formatting (linebreaks on braces) etc.

If you want to do high polish commenting for example, its not uncommon for about 25% of the file to be comments and white space. Error handling can also be much more code than your basic functionality, so if you have robust error handling and logging, this can also be a ton of the code.

The main advantage to dividing up files is creating new tabs automatically in your ide and being able to use shortcuts like ctr+tab to switch between files quickly.

I have a number of larger classes that are divided into multiple files, and a number of smaller classes that are all dumped in the same file.

It's just about finding a happy balance where I can find what I'm looking for with minimum hassle.

 

I believe the crucial difference between the two approaches is that one makes it easier to utilize polymorphism while the other hinders it.

Granted, OOP is not a silver bullet so you don't really have to follow it if you happened to have a better approach that suites your personal needs. But it's still one of the most widely understood principle, and also a very powerful tool to construct a complex piece of software with.

Theoretically, one can devise a working principle to organize a very complex program into a single file, and maybe invent something to replace polymorphism with.

But I guess there needs to be a good reason to go down that route, since if the project involves more than a single developer, it'll inevitably introduce some overhead to reach a consensus with other members of the project, as such an in-house rule is not something readily understood or accepted among average developers.

 

This is also a big deal. A ton depends on the other members of a team.

For example, even though I have a completely opposite set of preferences from @mysticfall - if we were working on a team together, the best approach would probably be a set of design compromises where both of us could still be as productive as possible. Generally this comes down to a set of conventions established in your working domain or in the company culture.

If you're working solo, then you need not make any such compromise, and so 33 lines per file or 1 giant file, doesn't matter, just make it work for you and adjust when needed.

 

Oh yeah I'm not bashing oop saying it is useless. For me it is more that I've done so much work using oop and all of this other stuff that has been tacked on over the years I am finding it very refreshing to just throw it all out.

Basically I am taking a very QBASIC / simple C programming approach to my projects now. Except I have also thrown out the concept of multiple code files. lol But that is only for this current project. I just like to test things and see which way is the most productive for me personally.

There is value in OOP and I also think there is much more danger in it too. I've seen so many projects where people started out to make a game or a utility or whatever and the went down the rabbit hole of architecture and engineering "clever" systems and ended up with nothing.

I mean sure they had a lot of fun creating the little system and there is beauty in such things from a technical perspective but it also shows how often it just serves as a distraction from the real goal. The goal is not to create elegant systems or complex "things" the goal is to complete a game or a utility or whatever.

Sure if a person just wants to spend their time creating those things for the fun and satisfaction of doing so that is cool. But I think generally what happens is these people started out with the idea of completing an application of one kind or another and just got lost along the way.

It's the programmer equivalent of starting out to make a game and spending years doing nothing but creating graphics / scenes but being no further along after years then they were at the first month.

And I am not immune to this either. It happens. We're humans and it is fun to play around and create just for the heck of it.

Even in my current tiny game project I wasted at least 2 to 3 dev sessions doing little more than tweaking colors and other aspects of the visuals. A couple of times I have thought about refactoring the code into more of a system. These I see as temptations that we should resist unless they are needed. But again... human.

I just think some approaches are more vulnerable to these kind of distractions taking over.

 

Too much time spent discussing something this simple.

One class for everything is bad for pretty much anything. Even while writing a snake clone, having only one class for the whole game will be quite problematic (because even in snake you'll need 2 or 3 additional datatypes). Unless the program is literal "Hello World", then this is not a case of "whatever you're comfortable with", but an example of God class antipattern.

Someone mentioned 30..50 lines per file, this is too low. 30..50 lines per method/function makes more sense, but even in this case it is should not be a strictly enforced limit. 30..50 lines per file implies that there are too many classes being introduced and they're not grouped by functionality, meaning that finding where the classes are is going to be more problematic. In case of large number of abstract classes it may be a good idea to group them in namespaces by intendend purposes and functionality, and non-abstract small classes are more likely to be "one-time classes", meaning they frequently don't deserve their own file (and can be either enclosed in another class, or made non-public, depending on the language).

Now, I DO occasionally have small files (I think the lowest I had was 5 lines of code per file), abstract bases etc, but I'm not seeing any complicated work happening in a class with this kind of restriction in pklace.

Also, I frequently end up with singleton classes (ObjectPool, I'm looking at you), and some kind of "GameManager" classes that orchestrate what's happening in the scene, and the latest addition was GameState kind of class that controls persistent data and persists through scene load. Having those is reasonable, but the mechanics and things game does must be normally split into multiple different datatypes.

 

I don't take 30-50 lines per file as some sort of a positive restriction myself. It's rather something that I usually find out after I try to write a code in a manner that I feel the most comfortable with.

I'll definitely respect your opinion if you say that you think 30-50 lines per file is too low, but I'd object if you'd rather insist it as an established fact, since my own experience with programming tells me differently.

(By the way, it's on average that I have 30-50 lines per file, not that every files are so short. I have many interfaces in my project, which should have contributed to that statistics.)

And as you said, using namespaces helps a lot to deal with large number of types, so I don't think having a few thousands of them would be too much of a problem, provided they are well organized into separate namespaces and follow a sane naming convention.

 

A few thousand files... I'm curious what are you building? I get that a lot of these files are just interface declarations but still even thousands of interfaces makes me think this much be for a game of a huge scope.

Is it WOW?

 

Ah, I didn't mean my current game project has a few thousands of files It's only a 3 month old project (linked in my signature) which is still in a prototyping stage.

I just assumed it would be more or less similar to my other projects at work when it's finished, which actually contain 2-5k types. They are all much boring stuffs, like some business intelligence or infographics platform, which is actually the reason why I'm so desperately hoping to do game development as a full time job

 

By the way, I got curious so I measured the same statistics over the source tree of Spring Framework, which I regard to be a very well designed framework.

It reported 154 lines per file on average (1 mil.+ lines of code over 6k+ files), which still looks to be within at a lower range, especially when considering general verboseness of Java language.

 

Ha ha. I got ya. Yeah I understand. I enjoy the work I do for my job for the most part. It's a bit varied with desktop application software development with SQL Server on the backend and TCP/IP on the one hand and many interfaces to 3rd party products on the other. Still it is different compared to game dev but I try to keep it fun.

Probably another reason I like doing game dev in a different way. At work yeah it's dozens to hundreds of forms and hundreds to thousands of stored procedures and classes depending on the project. Events, exception managers and so forth. Basically the whole layer upon layer of modern "goodness".

Even for work the more time passes the more I view it as simpler is better.

Ha ha! It's funny I have seen the term anti patterns thrown around on these forums at least a couple of times now. I have that book here on my shelf along with Code Complete, Fowler's book on refactoring and many more from back when I was more of a purist on this stuff.

I think basically the older I get the more I tend to think all I know is we really don't know. We (people... developers) in general don't really know absolutely what is best. We just try our best to spot the problems and create solutions. But since we are not perfect generally our solutions aren't either. And at this point we have come so far away from how development was done decades ago I feel we have layered on so much stuff we have created more complexity and risks than what we first set out to solve. lol

Just my view on it. So I am currently at the point of seeing it all as the anti-pattern.

 

Over the last decade or so I've also gotten way more lax.

In general I think a lot of these discussions should include a lot more "[x] worked for me in [y] circumstances" and a lot less "everything should be [x]".

Almost every programmer I know has a problem with being overly certain of the 'one true path'. It's just a side effect of too much time in too many foxholes and i think programmers as a group have a real problem with addiction to 'best practices' and dogma that borders on blind fanaticism.

 

you have asked a nice question! I think there is no standard answer! if you create a 'Game' script that handles everything is really useful ,so do it; if you find the 'Game' script exist Malpractice, continue to find best solution;

 

why are people talking about lines per file, use as many lines as are needed to get the behavior you want. Some things you want to accomplish are just inherently more or less complex, what you should be thinking about how your data flows from object to object and how readable that is.

 

I usually have a "Manager" script that keeps references to other scripts. That's about the extent of it.

 

I did.

Now I use a Playmaker FSM.