Search Unity

2 smaller scripts vs one large script

Discussion in 'General Discussion' started by SamohtVII, Jun 20, 2019.

  1. SamohtVII

    SamohtVII

    Joined:
    Jun 30, 2014
    Posts:
    180
    Will I see a performance improvement if I split my large script into 2 smaller scripts? Logically it makes sense to based on functionality but that's not really the question.
    Does having 2 half sized scripts improve performance over one larger script? And then what about 3 or 4, when does it end?

    Thanks,
     
  2. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,817
    You won't really see any performance change at all, unless both scripts are monobehaviours, in which case you will see a performance decrease. That said, the decrease is so small that you effectively need thousands of them to notice it have any meaningful effect.
     
    dogzerx2, Joe-Censored and Ryiah like this.
  3. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    6,253
    The different in performance between 1 and 2 Monobehaviour scripts is negligible.
     
    Ryiah likes this.
  4. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,052
    Performance is not the problem. Organization and modularization are the two main ones. Generally you ought to keep your class files as concise and modular as possible. My current project has 15 class files, I began writing last thursday. Each file is from 50 lines (minimum) to 160 or 200 lines in length.

    Modules make things cohesive and can be loosely coupled (good things).

    I've been there before, having a file with 300 or 700 lines of code. The problem you run into with a big file is it gets really difficult to manage both conceptually and organizationally.
     
    SunnySunshine likes this.
  5. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,289
    That is a great question. I'd actually like to see a technical answer on this: Something like ".0000001 ms extra time for two scripts vs. one script" or something like that. I don't know if anyone has ever tested it. Would be very interesting.

    I think for 99.9% of people, it won't technically matter. The main thing that matters is if you can keep your code organized and working. Personally I have a few large scripts in all of my games, something like 1000 to 2500 lines of code in some of them. Which professionally probably isn't good at all......but if you can comment your code well and keep things really organized, you can use gigantic scripts if you want.
     
    Ony likes this.
  6. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,052
    Something tells me you're writing *ahem* crummy code. If you need to comment things... I don't think you're naming things legibly nor "properly", a term I use tentatively because properly is a subjective topic BUT the objective of it to produce clean and readable code that doesn't necessitate commenting.
     
  7. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,364
    Many scripts don't really matter in terms of performance. Is just for human readability and convenience. Compiler will assemble them anyway, in appropriate way, for CPU/GPU to function.

    Is easy to organize. But there were programming environments, where separate files weren't an options.

    Modern script editors have capabilities, to collapse and quick jump to relevant scopes, within same file.


    Also, comments exist for a reason. They can convey messages, where name of variable, method or otherwise is not enough.

    Brief commenting what if, or for loop will be doing can be useful as well. Commenting at beginning, what script may be doing, can be informative too. But is harder to maintain, when scripts evolves. Also can comments can nicely divide script into sections.

    For example having multiple methods in one script. Like math. And commenting off vectors, trigonometry etc.

    Coming back next year to scrip, can be very time consuming, when there are 0 comments. Regardless of methods, fields etc., naming.
     
    Velo222 likes this.
  8. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,817
    ...My dude, you've got scripts the size of some of my entire smaller projects. That's not... great.
     
    xVergilx, Meltdown, Ryiah and 2 others like this.
  9. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,289
    If it works, it works. Of course it's great to keep scripts modular, I do that as well. But sometimes a "module" gets large, especially if it's a large or complex game. I don't have other people working on that particular project, so as long as I can understand it every time I go back to it, and it functions correctly, that's all that matters to me lol.
     
    frosted likes this.
  10. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,817
    This is a terrible attitude to take because monolithic scripts like this make debugging and refactoring a major nightmare. Even my large, complex special rendering systems don't get to that size.
     
    xVergilx and Ryiah like this.
  11. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,289
    Well, I'll take your advice into consideration. But it works, so I don't know what to say. I've been able to debug it just fine. And as for refactoring, I just havn't had to refactor that much, and it hasn't raised any issues. I know, it's bad form, so I get what you're saying. But to me, the end goal is that it works right?
     
  12. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,551
    I actually think there are very much times and places for large functions - that is a function that clocks in at like 500+ lines. It really depends though, and most of the time when people do stuff like that they're making a mess.

    Some of the code that I found easiest to work with given high complexity was a 700 line function I wrote to handle camera logic. I revised it and added features, etc, and found it quite easy to deal with. Much easier than if I had split it up.

    Again though, I wouldn't recommend this kind of thing in general - but there is a time and a place.
     
    Velo222 likes this.
  13. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,817
    "Works" does not automatically translate to "works well." Pulling out works, but you should probably just wrap it up instead.
     
  14. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,289
    Well, you're right. I'm not going to argue with that. :D
     
  15. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,096
    Optimisation Guide In Unity https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity.html

    Step 1. Profile...
     
    RecursiveFrog and Ryiah like this.
  16. Ony

    Ony

    Joined:
    Apr 26, 2009
    Posts:
    1,831
    I like big scripts and I can not lie.

    Some of my functions (methods, whatever, like I care) are freaking huge. Some of my scripts are wickedly long. Come at me bro.
     
  17. kburkhart84

    kburkhart84

    Joined:
    Apr 28, 2012
    Posts:
    732
    I've always seen that a class(like OOP style class, Monobehaviours are a bit different) should do one thing, and one thing only. That paradigm means that most if not all of our classes are too big, though I'm not convinced this "rule" is that big a deal. The point stands though, that we should try to keep things organized, etc... It can often make sense to split a script/class into separate parts, especially if either of those parts could be reused elsewhere. For example, if a player ship and an enemy ship have the same movement patterns/controls, but one is player controlled and the other AI controlled, I would put the movement in one class, and then have separate classes which then access that class, meaning you don't have duplicate code anywhere.

    Another thing to consider...besides the abovementioned point that you need to PROFILE before optimizing(pre-optimization is evil, etc... etc...). If you are using Unity, you are already technically taking a performance hit. This applies to any generic engine(UE4, Gamemaker, anything). This doesn't mean that the performance isn't good enough, as when used correctly the performance is almost always good enough. I'd say splitting scripts up where it makes sense is the same way. So you might lose a percentage of a millisecond here and there....totally worth keeping the sanity with organization of the project.
     
    Socrates likes this.
  18. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,454
    I like to budget some time refactoring any time a class gets too long. Several smaller classes will usually be far easier to maintain than one giant class.

    Similarly, I always try to keep every function small enough to fit onscreen without scrolling. It is harder to debug functions when you have to scroll to see it all.

    In addition to scrolling, large function tend be too long to name effectively. If you have a really long function that needs comments just to make sense, then you should break it down into several smaller well named functions with narrow scope. A bunch of small, well named functions can replace the need for most comments.
     
    TenKHoursDev likes this.
  19. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,454
    As for purely performance considerations, there is significant overhead to having many thousands of objects with Update functions on all of the scripts on those objects. However, having three or four classes instead of one will not affect performance in a meaningful way when dealing with a low number of objects.

    Side note:
    Having 10,000 extra Update functions in a scene will affect performance by a measurable amount. If you need to have 10,000 objects moving around in your scene, use ECS instead of instantiating 10,000 objects with scripts attached to each one.
     
    RecursiveFrog and Velo222 like this.
  20. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    7,819
    Indeed. And often sometimes, in a team, one person will make choices that are non-obvious because they support a larger architecture or some longer term plan. Our lead often puts these in if something seems weird, he will comment that it is works into a bigger piece.

    Although it is sort of weird, our team is fully distributed so our comments often work like a context-based chat system. I'll go in to wire something or build out vfx or whatever and find implementation notes specifically for me (and I do the same). Oddly we have found this works really well. Several of us are in different time-zones, so we pass work back and forth. For example, If our game play engineer needs to tell me something super specific about a new feature and the way he implemented it, he'll leave me messages in code, and I may ask questions or reply to him, in the code. If he were to slack or email or trello it to me, I may or may not see or remember it when I work on that part. In the code, it is right there in front of me, exactly when I need it.
     
    EQLucky, IcyPeak_S, Ony and 3 others like this.
  21. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,454

    Comments definitely have a place in coding. Anytime I do something weird, I will add comments to explain it. That is a great use case for comments.

    Sometimes comments get used for the wrong reasons, though. For example, some coders will choose to create a single massive function with a bunch of comments spread throughout that function to explain what each of the many subsections of that function do. That is a bad use case for comments, since the comments are trying to make up for the coder choosing to put too many things into a single function.
     
    Velo222 likes this.
  22. SamohtVII

    SamohtVII

    Joined:
    Jun 30, 2014
    Posts:
    180
    Ok it seems the general consensus is it doesn't matter (in terms of speed), but I just want to specify a bit more, I have a car changing script like scroll through cars in a garage and a paint the car a color set of functions. If I where to split those up I have to get the car again and call functions between the 2 scripts. I feel gameobject lookup is something to not go crazy with (like find with tag or whatever it is). Am I still being too cautious and should split them up?
     
  23. kdgalla

    kdgalla

    Joined:
    Mar 15, 2013
    Posts:
    1,533
    why would you need that at all? You can set a reference from one component to another in the editor, or a component to GameObject too (They just need to be in the same scene), so you don't actually need to "find" anything at run-time if you have performance concerns about that.
     
  24. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,096
    I would say yes then later on if you want the players to be able to change the colour of their car in another area of the game or want to change the colour of a car within the game you can without writing a new function.

    Often you will need manager scripts that hold the collection of cars it sounds like your car changing script should be or work for one of these scripts in which case it will be passed or know the cars reference.

    You might need to make a car script that works as a Utility script that holds the references to all the things within the car that can change then your car changing and painting scripts will just work through the car script and only need a reference to the car.

    Hint: if your using lots of Find<Component/GameObject/Tag> code you need a helper script that will store references all of the bits of a car that can be changed.

    By breaking apart the separate aspects of what you are doing you can simplify and streamline the process, in programming you know you have a good design when it feels like the code in the system is working with you to solve the problem.

    PS for best advice you should post your code, and always profile your code it's the only way you will find out what really needs to be optimised.
     
    RecursiveFrog likes this.
  25. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,052
    Silly question: DoEs CoDe ImPaCt PeRfOrMaNcE?? ?:p
     
  26. SunnySunshine

    SunnySunshine

    Joined:
    May 18, 2009
    Posts:
    669
    This, so much.

    I think the bigger question here is "How do I keep things modularized"? And for that, I think DRY is a very powerful technique, since it essentially forces you to modularize your code as that is the only way to prevent repetition.

    A problem I've had lately is that even though I'm not violating DRY, some classes might still end up becoming really big. I.e. there are things that are not used anywhere else but in a certain class, but keeping it all in that same file makes it bigger than what's comfortable to work with. This can be a really tough problem, because it's not always obvious where or rather when a class is becoming too big. It sort of sneaks up on you.

    A rule I'm running with now is that any one thing, any one concept that could abstracted into its own class with its own variables and functions, should, even though it's only used by a single other class. That can be a bit counter intuitive, as you're essentially modularizing something that doesn't need to be, for the sole purpose of making the class smaller. It's also definitely possible to overdo this, to the point where it's actually becoming harder and more confusing to read the code. There's also the question if refactoring the code to be more beautiful is even necessary for the product to ship. This and more is something the TechLead touched on in this video which I can highly recommend:




    Another thing to keep in mind is that writing and organizing code in a beautiful way also makes you more replaceable. So if you wanna make sure you're essentially unfirable, you want to be able to write incomprehensible code that makes you look really smart but that's actually atrocious. This is something the TechLead spoke about in this video:



    :)
     
    Last edited: Jun 24, 2019
    Ony and Velo222 like this.
  27. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,454
    If you need to find anything, do it in the Awake or Start function and cache the result in a class level variable. Do not find the same thing over and over during the Update function.
     
    RecursiveFrog, Ryiah and Velo222 like this.
  28. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,052
    Am I the only one who uses inheritance/OOP/SOLID to architecthis code? I can't be, I'm not sure that's possible.

    Reason being is what follows:

    Your classes ought to inherit from more semantically abstract base class(es). I'm sure we've all heard of the animal kingdom tree:



    This a tired example but I'll explain...

    Your concrete classes are the leaves of the tree. Your essential base classes are everything in between (Chordata, and its descendants). You can generalize this idea of a tree diagram to any object type.

    In general I would suggest examining what the core class is, and descent to more specific examples from there...

    Doing so lets you do cool stuff like:


    Code (CSharp):
    1. int iValue = 5000;
    2.  
    3. double dDistance = iValue ;
    4.  
    5. public class Animal { [] };
    6.  
    7. public class Mammal : Animal { [] };
    8.  
    9. public class Cat : Mammal
    10. {
    11.     []
    12. }
    13.  
    14. Mammal mammal = new Cat();
    15. //Original code: https://en.wikibooks.org/wiki/C_Sharp_Programming/Casting
    Which is very useful because with this you don't need to create a ton of 1. ugly 2. repetitive, and 3. annoying statements to handle different class types.

    The general rule I think is if you use SOLID, DRY, and OOP principles you should be OK. Don't forget to test though, unit tests/integration tests makes for good robust code, I don't do this yet myself in this project but I've got try...catch, throw, and null ref checks, debug.asserts, and Mathf.Clamp() and Mathf.Abs() , all over the place so that I can find and fix any problems.

    It would be awful if your DoDamage() method had the wrong sign, instead increasing the opponents HP to infinity, or the projectile/hitscan got a null-reference on your target upon colliding.
     
  29. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    5,817
    Object oriented programming, especially for games, was a mistake.
     
  30. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,263
    The keyword is: composition over inheritance. If you really want to sink in OOP, do it on a more flat inheritance-way.
     
  31. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,052
    I think I'd heard of it but its not been part of my designs...

    Oh yea? Why's that?
     
  32. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,364
    I used that, when I was learning OOP. Then soon become nightmare, to expand upon.
    Later I kept it to very minimum number of inheritances, which was more manageable. Also more modular.
    Now I don't need that with DOTS.
    I suppose this is typical way of learning things, to find out whats works and whats not, for particular case.
     
    xVergilx and TenKHoursDev like this.
  33. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    14,372
    Inheritence is inflexible, and can lead to unnecessary code if you decide you need some of the functionality of a base class but not all of it which can itself lead to performance losses. Composition has performance penalties too but you can much more easily offset them by only bringing in the functionality you need.

    Furthermore composition means you can create new functionality at runtime (eg for a mod) whereas inheritence leaves you at the mercy of whatever pre-existing types have been created.

    Once upon a time I would have gone with inheritence, as I had never heard or thought of composition before Unity, but now I can't imagine using it beyond what is necessary to make the framework for it (MonoBehaviours inherit from Components, GameObjects inherit from Containers, etc).
     
    Last edited: Jun 24, 2019
  34. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    4,583
    Sorry to hear that, it's working out quite well for me :) though I tend to stay away from inheritance unless the relationship is rock solid.
     
    Antypodish likes this.
  35. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,016
    I think the issue is definitely more about (overuse of) Inheritance than Object Orientedness itself. After all, composition is just another way to describe objects.
     
    Billy4184 likes this.
  36. Kevathiel

    Kevathiel

    Joined:
    May 10, 2015
    Posts:
    5
    People who complain about OOP, because composition is better than inheritance are silly, because Composition over inheritance IS an OOP principle, even mentioned in the Gang of four books, literally in the first chapter..

    “Favor object composition over class inheritance.”
     
    RecursiveFrog likes this.
  37. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    725
    To be clear, you wrote "books", plural, but there's only 1 book: Design Patterns: Principles of Reusable Object Oriented Software. Its from a paper with 4 authors, which is pretty standard - not gang-like at all.

    You're talking about page 19 (plus bottom of page 18 and top of page 20). If you read it, it describes something similar to how Unity works. To get a graphical GUI element, you don't have Image inherit from gameObject. Instead, make it an optional component. But, as the book describes, Unity uses inheritance to make the components - rawImage and Image inherit from MaskableGraphic, all types of Colliders inherit from Collider, and so on. That page is saying that of course we all know inheritance is great, but not for every single thing.

    That wiki page - the big bar at the top says it's bad, and it's not kidding. If you click the Talk tab you can see they didn't think very hard - some guys just wrote some stuff and can't explain why.
     
  38. Kevathiel

    Kevathiel

    Joined:
    May 10, 2015
    Posts:
    5
    Yeah, books was a typo. But... you realize that they are called the "Gang of Four", right? It's not something I made up..
    It's THE book when it comes to OOP.

    I don't know what you are one with your Unity example.. No should be dealing in absolutes. It's stupid to fully avoid inheritance, just as it is to use it all the time.. So nothing wrong with that. My point is that the issue of OOP is not the inheritance stuff, because even the foundation of OOP(the go-to lecture) favors composition.

    With the key part being:

    "Nevertheless, our experience is that designers overuse inheritance as a reuse technique, and designs are often made more reusable (and simpler) by depending more on object composition. You'll see object composition applied again and again in the design patterns." (GOF95)
     
    TenKHoursDev likes this.
  39. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,263
    You should realize that no one here was complaining about OOP because of inheritance as opposed to composition. Mostly despite of the composition. OOP is still a bad choice to make a game, however if it has to be OOP, it has to be on the basic principles of composition.
     
  40. CityGen3D

    CityGen3D

    Joined:
    Nov 23, 2012
    Posts:
    186
    If your script does two things then it should be two scripts.
    The Single Responsibility Principle is worth adhering to as best as you can because it massively helps code maintainability.
    It also helps to keep your public interface separate to your private implementations.

    Because of this, writing code in this way will often be more performant because it forces you to encapsulate data properly.

    If you ever find yourself copy and pasting from one function to another (we’ve all done it!), then there’s a clue there.

    Every programmer is guilty from time to time but as long as you understand why it’s important then it helps you not to ignore that little voice in your head telling you to split your code up better!
     
  41. Kevathiel

    Kevathiel

    Joined:
    May 10, 2015
    Posts:
    5

    Read the thread again..

    TenKHoursDev said he was using OOP.
    Murgilod followed with "Object oriented programming, especially for games, was a mistake."
    TenKHoursDev asked "Oh yea? Why's that?"
    Ryiah answered with the whole reply based on "Inheritence is inflexible, and can lead to unnecessary code.."
    Antypodish said OOP was manageable when he minimized inheritance

    Angrypenguin said" I think the issue is definitely more about (overuse of) Inheritance than Object Orientedness itself."

    Did I miss anything? So how is it NOT about inheritance?
    I mean you people could also just stop making empty claims like that and actually provide arguments.

    OOP is bad, but why? Aside from the inheritance argument there was nothing.
     
    Billy4184 and angrypenguin like this.
  42. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    725
    If anyone is interested, try the Search "OOP overused". Mine even had a StackOverflow question about what "Favor Composition Over Inheritance" really means. You'll also see lots of people talking about how OOP programs spray out interfaces and mediators and message-passing classes ... to do the simplest things. You may not agree with it, but you'll know what the internet thinks OOP means.
     
  43. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,016
    Indeed, this is what I was trying to point out. People say it's OO that's bad, but the causes for this seem to stem largely from the impacts of poorly used inheritance. To my mind the real underlying problem there isn't that inheritance is "bad", but that it's the wrong tool for the job.

    The other reason I see people complain about OO in game dev circles (though it hasn't been mentioned here) is the impact it can have on performance. It can definitely have a very real impact in certain cases. Again, though, I feel it's more an issue of the wrong tool for the job, as opposed to the tool being "bad".

    I think that with ECS Unity itself is now a decent example of how to split the two. Use standard OO / components for the stuff where it makes life easier without impacting performance. Use data-oriented stuff where it will have an impact on performance. Same deal with any other tool at our disposal - figure out where it's strong and where it's weak, and use it accordingly.
     
  44. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,016
    To answer the OP's question... my projects are typically made up of lots of generally tiny scripts.

    However, it's worth noting that most of the scripts are dormant most of the time. I use events to "wake" scripts up when they need to do something, and they turn themselves back off when they're done.
     
  45. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,551


    Why OOP is bad.
     
  46. Kevathiel

    Kevathiel

    Joined:
    May 10, 2015
    Posts:
    5
    So he lists a lot of examples of bad OOP code and his solution (at the end of the video) are to write pure, long and nested functions. He is also heavily biased because he doesn't talk about the actual advantages of OOP nor the disadvantages of his solution. Yeah.. totally objective.

    Anyway, it also seems that the whole hate on OOP in this thread is pointless and people would just let others use what they are more comfortable with.. Just like the Celeste devs were happy with their 5400 loc Player.cs..
     
  47. docsavage

    docsavage

    Joined:
    Jun 20, 2014
    Posts:
    995
    In spite of making my first game and it working I still consider myself a beginner programmer. I learned on the job. I don't doubt the code could be better laid out/structured but it works and only I'm going to see it (in theory). If anyone cracks it and manages to figure out the inbuilt obfuscation, i.e beginner code, then they are doing well :)

    Badly written code is badly written code whether on 1x10000 lines or 100x100 lines scripts. Well written code is just that. By the end of the games development I decided that a Keep It Simple principle is best whatever method you settle for.

    Just a thought.

    Here's a vid explaining with some good humor the same thing but much better explained by one of my favorite youtubers

     
    Last edited: Jun 26, 2019
  48. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    4,583
    Ok so what useful conclusions did you draw from that video?

    The problem with attempting to do away with OOP is a very simple one: to do it, you have to treat every object as a group (i.e. its data structure) rather than individually. The moment you want to identify and single out a particular object (e.g. the enemy boss for some special action) all your perfect abstraction takes a dive out the window (unless you consider a special data structure for a singular object to be not actually an object reference).

    Game programming is not a science, it's an art. All the time you have to stick your hand in somewhere and grab an object to do some special behavior just because for some reason it happens to make the game more cool. Just look at a Call of Duty game, every level is a succession of hundreds of carefully crafted individual events and behaviors that sweep the player along in a feeling of non-stop pressure and action. No level of perfect abstraction can achieve this.

    I think of functional programming a bit like the idea of procedural generation. It's an attempt to abstract something in a way that reduces the individual identity of things in your game, but you just end up with abstractions that are around about the size, shape and smell of whatever object you should have been dealing with to begin with.

    Games are about experiences that people can understand, not computers. That means that they are about objects and things. And lack of individual identity is the enemy of art - art is not about the 99 things that did X, but rather the 1 thing that did Y.

    I have not found a better way to program games than to use objects and OOP.
     
    RecursiveFrog likes this.
  49. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    725
    Is this a philosophy, or did it just work out that way?

    I've found that I just can't remember the names of lots of small scripts, plus they clutter up the editor tabs. I used to have lots of files with utility functions, but combined them into one. It's easier to use #region's and scroll through that one file than to bring up each one. Sure, it wastes the space on the functions I don't need, but only a few K. I was trying to remember what I used to do -- I had paper printouts of everything. In that case it was easier to have them in separate files.

    I often need tiny "data" scripts, for example AnimalDataScript would have enum AnimalType and int index (I keep the real data in a List in the controlling script). I'd check that when I collide with it. But instead of that, I switched to a single GenericDataScript, with val0 through val3, num, index, and other common names. The controlling script has dedicated functions like getAnimalType(genericDataScript g) doing the translation.

    If sounds more confusing, but if genericDataScript is on something named cow1 on layer animal, it's fine. Plus, without, I'd have dozens of the things.

    If the cows need to be smarter, I've found it easier to make a few big combined "do stuff to me" scripts, instead of lots of small ones. So my cows also have useless functions to change their non-existent text (on both sides, even!), text color, and to hide their borders (they don't have borders). It's just easier to remember the standard names, and only have to have that single script in the editor tab for animals, signposts, and so on. Theory says it should be several small scripts, using only the ones I need for each object. But finding the right one for each call is too much of a pain. Plus you always want something like setColor(textColor, bodyColor) which would involve two areas.
     
  50. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,263
    This is a false argument. The content and the way you work on it are different matter by all means.

    That's okay, personal taste is personal taste. No problem with that.