Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity Future in X years? (School Project)

Discussion in 'General Discussion' started by tobiasmeier204, Dec 8, 2020.

  1. tobiasmeier204

    tobiasmeier204

    Joined:
    Dec 8, 2020
    Posts:
    1
    So basically my name's Tobias and im working on a Documentation + Presentation about Unity.

    And i thought it would be interesting to hear as many thoughts as possible from ppl which are actually working with Unity etc. so here's the Question! :)

    • What do you think / guess how Unity will look like in 10 Years?
    I'll appriciate every answer, u can answer with anything like (Community, influence, International Impact etc.)

    Thanks in advance everyone <3
     
  2. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,956
    Sadly, I believe it will likely not have progressed that much further than it already has. Unity has simply stagnated too much. Official documentation is very hit or miss and hasn't had significant improvement for most of my time with it, and the official tutorials are almost always in a broken state outside of one specific release.
     
  3. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    That said, I hope Unity spends this time stabilizing what they have, fixing bugs, and making things really solid. With all the new DOTS tech, there's a large hill to climb for it to become adopted as a standard among Unity users. The networking/multiplayer solution is still floundering, even though there are okay third-party alternatives.

    What I want is for Unity to have its technological identity established in 5-10 years. But what will probably happen is more technologies thrown in to "stay competitive" for their marketing folk, especially with shareholders and all.

    I'm still giving it to Unity for their efforts in adapting. They really jumped onto competing with Unreal, and there are small details that I appreciate in the direction that they're taking. For example, it used to be a pain to not have versioned Assets from the Asset store, and now the Package Manager helps alleviate this issue. Another example is AssetBundles. They're a pain to deal with, but more in line with how professional practices handle the asset pipeline as far as large productions go. These are just small examples that I notice and I'm sure there are plenty more. Like, how have nested prefabs been handled? I mean, people have been bitching for years, and now it's here. And same with dark mode. Also part of what I'm noticing is that JR was the CEO of EA when I was there, and he actually was pretty instrumental in adapting EA into the digital age. I'm seeing similar large sweeping motions to get Unity to adapt and stay competitive.

    So far, I have no major complaints. I'm still waiting for those ridiculous shareholder decisions, but otherwise, if Unity "stays the same", I'll be happy.
     
    tobiasmeier204 likes this.
  4. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Purely my own speculation....

    Unity will continue to increase in modularity, with more and more core functionality moved to essentially plugins. Currently this is done via the Package Manager, but I wouldn't be surprised if in the next decade the Package Manager system was itself replaced. I'm expecting Unity to end up largely as a framework which handles running through frames, calling the various special timing related methods, which other plugins hook into for whatever functionality you want.

    Unity will focus more and more on multi-core efficiency, with functionality from Unity utilizing it better. The DOTS/ECS project will become mainstream and fully supported, with larger desktop/console projects utilizing it, but the main thread focused MonoBehaviour system will still dominate smaller projects and remain more popular on the whole.

    I know you asked primarily about documentation, but the above is still very important on the topic. This is because documentation will continue to degrade and fragment, as the primary documentation repository gets less and less relevant as more functionality moves out of the core engine into plugins/packages - each with its own separately maintained documentation of varying quality. With two competing systems for writing your scripts (DOTS/ECS and MonoBehaviour), code samples and tutorials will also fragment along those lines.

    We had a brief period in the 2017/2018 release years where virtually everyone was on C# using MonoBehaviours with the vast majority of documentation in one location. Basically the entire community was for a short time on the same page. That's coming to an end.
     
    Last edited: Dec 8, 2020
  5. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Dont hold your breath on the multi core part, gfx jobs are still a broken mess and Vulkan support is also pretty much broken.
     
  6. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    10 years from now it might be gone or lose relevance.

    Does anyone remember Torque? Torque right now is what Unity might become in 10 years.
     
    Last edited: Dec 8, 2020
  7. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    The question is about the state a decade from now. A $700 basic low end laptop will probably have 32+ cores, so all but simple games will have to adapt to that reality, and I'm sure Unity will as well.
     
    tobiasmeier204 and Antypodish like this.
  8. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Yeah, but unity is unity :) we have been rambling about this for years now. I have checked our steam hardware survey and its well over a year since 8 core surpassed 4 core so it's time unity get on the train.
     
    Last edited: Dec 9, 2020
    Joe-Censored likes this.
  9. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    It really could go anywhere, they probably will continue to acquire and try to sell services as they try to work out how to turn a profit, and continue to tack on extra paid things that should have been core engine features and would be competition killers, such as unity MARS etc in a move to try and find some other form of profit that can prop up the engine. That might in the end prove successful, or it might end up being a bad move.

    Thing is, until they work out how to make the usage of the core engine itself feel worth the money to users, whilst still competetive to competition, whilst still profitable for them in some way, its not an easy thing to speculate on as its hard to see what their actual final direction will be when this all gets worked out in the coming few years.

    I just overall dont think the licensing structure for unity, works best for unity longterm vs the licensing structure for unreal when looking at profits for company vs value for users.
     
    Last edited: Dec 9, 2020
    Deleted User and SunnySunshine like this.
  10. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    400
    Bloating, abandoning core community, truing to sell engine to off-game usage(automotive, movies, ect), dying. Rising of a new, simple, friendly and easy to use engine(???godot???). It's a standard lifepath of any software. Perfect example is jira vs trello.
     
    tobiasmeier204 likes this.
  11. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    Both Unity and Unreal are moving toward becoming general-use 3D tools. Unreal is dominating rendering and animation while Unity is dominating simulation and machine learning. Tbh I expect that in 10 years one of them will pull far ahead in terms of being the 'go-to 3D tool' and the other will either fizzle out or just go back to specializing in a small niche.

    Who will win? I don't know. Unity are starting from better roots, but are extremely slow to develop compared to Unreal. They are acting like a company in its twilight years when the game has only just begun. Meanwhile Unreal are cranking out features and breaking china everywhere trying to grow faster.
     
  12. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Proof?

    I mean, there may be some proof of concept projects, but that doesn't seem to be what the engine is being used in the real world right now.
     
  13. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    No proof, just based on what I have observed:
    - Hiring the machine learning whiz from Uber
    - Machine learning agents
    - DOTS/ECS, Havok etc
    - Artomatix
    - https://unity.com/products/unity-simulation

    I really can't see this being aimed at just making better strategy games.
     
  14. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Trello is not a replacement of Jira. Jira is enterprise scale which Trello is not. Jira vs Azure devops is a better comparison
     
    Deleted User and tobiasmeier204 like this.
  15. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    You can use machine learnign for a lot of stuff. For example in VR it can be use for pose prediction to substitute additional trackers.
     
    tobiasmeier204 likes this.
  16. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    Sure, it has a few very good uses for games, but not many. I don't think that's what Unity are aiming at. Same for ECS and DOTS. 99% of games don't want/need it. But for engineering visualization/simulation it's very useful.
     
    Deleted User likes this.
  17. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    I agree on the machine learning, but not on ECS/DOTS. ECS as a concept has been around for a while not just in unity but in the games industry, and there are not "types" of games that are better suited to it, just its a different way of thinking entirely. You can certainly make any game using DOTS and ECS.

    For example overwatch uses ECS (non-unity, they have propietary engine).
     
    tobiasmeier204 likes this.
  18. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    For what exactly? 99% of games are bottlenecked by graphics, rendering, physics etc. ECS is cool and useful for some things but not very many, and it severely impacts workflow. I tend to agree with Tim Sweeney's perspective:
    "ECS is fast, but is primarily suited for particle-system-like constructs rather than ordinary gameplay code, in which updates an entity can freely read and write anything in the scene in an atomic, isolated, consistent, and durable way."

    Overwatch is the first I've ever heard of it being used in a game. And massive AAA games are being shipped in Unreal all the time without it, without performance issues. I don't see how it makes up for its complexity.
     
  19. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    ECS can be used for alot of complex systems when and if it becomes mature.

    Edit: complex as in alot of data
     
    aer0ace and MadeFromPolygons like this.
  20. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    I think you are confusing ECS and DOD in general with Unitys specific implementation. They are not one and the same. Just because unitys current WIP implementation is awfully complicated, does not mean the industry standard ones are. It also doesnt mean unitys will remain this way forever too!

    ECS != complexity.
    DOD != complexity.

    The point is making the system usable, an AAA like overwatch will have done so and now reap the benefits when it comes to performance etc. It does not seem to have impacted their ability to operate as normal. Just as unity are doing, they build things into the engine to make the process of building games using ECS and DOD Practises faster (think visual tooling etc)

    EDIT: including a link to one of the overwatch talks where they talk about architecture etc, at no point do they ever talk about "but we had to then balance the complexity it brought" or anything remotely in that vein:

     
    NotaNaN and tobiasmeier204 like this.
  21. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    Parallel data.

    As soon as you want one thing to not be like the others (i.e. the player, or a boss) you run into trouble. That's what the quote above pointed out. Attaching 'if' statements to parallel code is just not pretty.

    Games are usually not like simulations. As a game designer you want to be able to pick out a specific thing at a specific time and make it do a specific action, because that's just what looks good. It's hard to do when you're supposed to treat everything the same like they are a bunch of particles.

    What do you mean by complexity when you say ECS != complexity? When I say it's complex, I mean that it forces you to design with the additional burden of thinking about how everything will be affected at once. In OOP if I want an object to do something specific, I write a script and slap it on and ignore everything else. With ECS, everything I do basically has a global scope.

    It seems to me that ECS is the equivalent of writing a singleton 'manager' component with all the code and querying it for what to do next. Not exactly the easiest system to design in a complex game.

    I'll take a look at the video, but can you sum up the benefits for me?
     
    Deleted User and tobiasmeier204 like this.
  22. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Actually you can run ECS single threaded and you will gain performance from that too because nicely packed structs are fast to access for the CPU. But yeah, its also easy to multithread. Well, depends on the problem.
     
  23. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    Okay I see where you are coming from.

    So think of it this way, before you learned OOP (and its difficult for most programmers, myself included, to think in that way as OOP is usually learned alongside your first few languages) it would have been just as hard to think about how everything connects, how to access the specific thing you are wanting to access at a certain point in the program, etc.

    You eventually learned how to think and now its second nature, and so you can design much bigger and complex things than at the start.

    Its totally the same with ECS and DOD. It feels crazy difficult and strange and obscure because its an entirely new way of thinking about and using code, its not a new language (syntax and features), its not a new tool (new workflow) its a new way of thinking - just as OOP was at one time to everyone at the start.

    So yes if you are currently trying to think about designing the same scale game you can now with OOP, in ECS, it will be maddeningly difficult and feel hard to see through the fog.

    But if you learn ECS treating it properly as you did OOP in the beginning, as a newbie and setting low small projects at first until you get the grips, very quickly this too becomes second nature and you end up just as fast. So its not more complex to design with and use, its more complex to design for an OOP minded developer/designer - and that I do agree with entirely.

    If you are interested in learning ECS at some point, dont try making entire games. Work backwards and take an existing OOP game and start converting bits to ECS and that will make you see through that fog way quicker.

    FYI even with everything I said above, I dont think unity ECS is all that great right now or worth learning, mostly because on top of the normal problems we discussed above in that you have to learn a very new and different way of thinking, it also adds lots of extra complexity on top because unitys ECS and DOTs system is insanely convoluted and complicated - in its current early access form.


    Onto the benefits; I dont think I can sum up as best as the video, but if you get around to watching it (its a really interesting watch!) they explain benefits not only to performance but to gameplay too hence why it was not just used for networking and particles and common use cases.
     
    NotaNaN and Ryiah like this.
  24. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    I envy these simple desktop games. Everything is so much more complex in VR, more so with MP :p
     
  25. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    Thats true, but there are still lots of great use cases in a VR MP game for DOD practises. It sounds like you are using a lot of them as you have talked in this thread about benefits of packing of structs etc so I am assuming you must have already converted some of the good candidates over?
     
  26. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Ah yeah, thats not what I ment, just watching the video. its so much simpler with their limited movable parts and what they need to sync etc.

    edit: no, we are not using ECS yet. We looked at it for our ballistics but wasnt mature. Btu we will will probably migrate to it
     
    MadeFromPolygons likes this.
  27. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    Oh right, yes ofcourse, a VR MP game is probably the pinacle of difficult in that regards!
     
    MDADigital likes this.
  28. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    It's not just another way of thinking. It's not just a new syntax, it's an architecture with specific strengths and weaknesses.

    As I've said in other threads, OOP is by far the most logical and intuitive way of thinking about physical reality, which is usually what a game is depicting in some way. An object is the fundamental atom of physical reality. If we see a dog walking down the street, before we think 'what is its manager singleton thinking' we think 'what is the dog thinking'. The dog (to put it crudely!) is an object, and within it we find its intentions and the source of its actions. A different dog may have a completely different set of intentions.

    We want to make a car move? We add an engine to the car. We don't add an engine to divinity and then use it to drive the axles of all cars.

    With that intuitiveness, OOP comes with some performance cost. But I would argue that it's almost never enough to warrant looking at something in a fundamentally restricted and cumbersome way. Programming forces you to take difficult paths sometimes if there's no other means, but there's no reason to take them otherwise.
     
  29. kdgalla

    kdgalla

    Joined:
    Mar 15, 2013
    Posts:
    4,615
    ten years from now, no one will be interested in game engines anymore. Those few humans that manage to survive by escaping into underground tunnels will be too busy scavenging for the last remaining food and forging a new civilization on the ashes of the old.
     
    Kiwasi likes this.
  30. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,956
    Having spent many years with Unity I have come to the conclusion that OOP is not the most logical and intuitive way of modeling physical reality. Component-based programming is much more sensible as very little in the real world is as simple a single object.

    A dog, for example, isn't just a single self-contained object. It's a collection of components all working together. You have legs (movement component), eyes (sight component), ears (hearing component), etc.

    Since it seems you have a good grasp on the idea of an object having components it shouldn't be at all difficult for you to pick up on the idea of a system.

    While it may have additional syntax you have to deal with the reality is it's not that different from the current way you implement systems except instead of having the systems directly tied to the components these systems are separate and must provide information on the components they work with.

    Boilerplate is the major disadvantage to this but the major advantage is that a single system is no longer tied to a specific object but can be used to implement the functionality of many objects in your project.

    Speaking of boilerplate, the last time I checked a few months back it was being rapidly reduced and it was nowhere near the complexity of when it was initially introduced. Within a year or two I expect it to be much more friendly for non-programmers. If you're struggling now just check back every few months.
     
    Last edited: Dec 9, 2020
  31. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Those are largely proof of concept experiments that are not adopted anywhere and speculation (hiring machine learning whiz does not mean you're dominating the field). So it is not "dominating" those fields. To dominate those areas it has to be widely adopted there.

    Honestly, at this point I do not believe Unity is dominating anything. Maybe it is still superior in number of supported platforms, but the way I see it there isn't a field it EXCELS at at the moment, and it is going in some strange direction.
     
    Deleted User and tobiasmeier204 like this.
  32. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    Actually I am mixing the ideas of OOP and components, but I think it's fair because the critical question is not whether the functions and data are on the same component but whether they are on the same object.

    To be clear, I think component-based programming does fit into the paradigm of the most intuitive and simple way of doing things. Different components on one object are a great way to segment functionality, and in my example (of engines and axles) one easily might think of the axle as a component and the engine as an entity (although an engine operates on an axle only for a specific purpose. It has it's own data, and is operated on by other 'entities' in the car. So trying to fully separate entities and components I think does deviate from intuitiveness).

    In fact, having 'entities' and 'components' on the same object is perfectly intuitive - in fact, this is the foundation of the architecture of my space kit, where the concept of a vehicle is made up of 'module managers' and 'modules', the latter of which are basically passive, like components.

    The problematic part comes when you start adding vital components for an object outside of the object itself, and using them (obviously) to drive many objects at once. Because then the question is how do you differentiate objects and treat them individually? You might say you don't need to, but I'm sure the majority of level designers would beg to differ.

    As a programmer yourself, I'm sure you understand the need to manage scope when writing code, and avoid creating unnecessary dependencies. The idea of writing lots of 'manager' components and singletons is typically seen as a negative for this reason, because you end up invisibly coupling a lot of objects together. That's fine for particle systems but I would argue that most 'objects that do things' in games typically require a lot more independence and flexibility, especially in terms of giving a designer the most capability to craft the player experience.
     
    tobiasmeier204 likes this.
  33. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    That may be, I haven't paid too close attention to what has actually transpired from all of it. It's more about where I expect Unity to be in ten years, and the current vector of where they are heading.
     
    Jingle-Fett and tobiasmeier204 like this.
  34. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Composition over inheritance IS OOP.
     
  35. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Commonly mentioned principles of OOP are:

    "Encapsulation, Data Abstraction, Polymorphism and Inheritance."

    Composition very frequently isn't even mentioned as part of it.
     
    Kiwasi, aer0ace and tobiasmeier204 like this.
  36. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Composition is one of the tools your use everyday in any OOP domain. Take the strategy pattern for example it's composition
     
    tobiasmeier204 likes this.
  37. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
  38. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    That doesn't matter. You use functions every day in OOP programs, but that does not make OOP euquivalent to a functional language.

    And no, you do not use composition every day in OOP. The most commonly used OOP tool is inheritance.
    Part of the reason for that is that composition works best with a language that has a concept of message passing, and such concept is not exactly popular. And without it, coupling multiple classes through composition requires jumping through multile hoops or a lot of forwarding.
     
    aer0ace and NotaNaN like this.
  39. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    No, actually senior devs minimize inheritance and rely on composition . Thats what the term composition over inheritance comes from. That is also why DI is so popular we inject our dependencies (our components).

    Here is the definition from wikipedia
    Even contains the OOP term several times ;)
     
    Deleted User likes this.
  40. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Honestly this depends on your level of zoom.

    Zoom in closer to the dog and you tend to find that all of its atoms behave in identical ways based on a few sets of rules, which are easy to externalise and process. Zoom out and you'll find that planet earth moves around the sun in a predictable manner that's identical to every other planet, moon, and star in the universe. Its only on the personal human level that we see the universe behaving as a bunch of unique objects.

    As such the appropriate system to use depends on your specific game type. Plenty of games (but not all) work on ends of the scale where it makes sense to use a generic data driven approach rather than a specific object oriented one.
     
  41. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,956
    Last edited: Dec 11, 2020
  42. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    We're talking about the most intuitive way of conceptualizing something. Knowing that atoms behave in generally the same way doesn't help you create an interesting dog, nor does knowing about the extent of the universe. To begin with, the dog doesn't know either of those things.

    Obviously, if you are making a game about atoms or grains of stardust in the universe, I'm sure ECS would be of some assistance. Because the entire point of it is that it's useful for making it efficient to process large numbers of the same thing, like bits of debris in a particle system. But most games don't take that level of scale into account or care about it.

    Unless you want to figure out the systemic rules that turn a clump of restless atoms into a dog that's looking for something interesting to do, I'd stick to the level of self-contained objects with components on them that interact with each other (unless you're looking to create a pack of 10,000 dogs doing exactly the same thing).
     
    Deleted User likes this.
  43. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Being deceptively intuitive is not a good thing.

    The most common issue with OOP is overuse of inheritance and object hierarchies, and, for example, if we take your atom anology, trying to implement atom as a class with 50 virtual methods.

    Inheritance also has its problems, because people take example of Deriving Circle and Rectangle from Shape, and then try to derive Car from Engine.

    Someone also said that the worst flaw of OOP is bundling methods with data they're supposed to manipulate. And that is probably true. As it leads with fun situations like trying to decide whether drive() is a method that should be part of the Car or its Driver.

    I do think that as a whole OOP might not be the greatest idea, and that it also most likely greatly contributed to modern software bloat. And one issue here is that people may often try to conceptualize object itself, instead of building model of data necessary for the program.
     
    NotaNaN and MadeFromPolygons like this.
  44. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,631
    Hopefully in 10 years it will look like nothing because I will have fulfilled my dream of making enough money to make a hostile takeover of Unity, purge their source code and then shut down the company.

    But in case I fail, I expect it will be exactly the same as today only a bit more buggy.
     
  45. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    I completely agree about inheritance, I typically avoid it if at all possible. Composition is far better. And to be clear, as Ryiah pointed out, I'm not using the precise definition of OOP. Instead I'm arguing that the idea of independent objects with components attached to them is intuitive, as opposed to passive components all over the scene driven by 'managers' that live somewhere in the ether.

    For your example of where the method Drive() should go, typically in a game world (as opposed to software in general) this isn't so much of an issue. The most important thing is to conceptualize a 'reality' for the game even if it's not the same as the one we live in.

    For example, in my space kit I use Game Agents as the player/AI, which contain scripts for input. A Vehicle, on the other hand, is passive. You can send control values to a vehicle (from -1 to 1 typically) but how that is implemented on the vehicle is built into the vehicle's own components. So in a sense it emulates reality, in that you can conceptualize -1 to 1 as the physical limits of a physical control which does something internal to the vehicle.

    This makes the vehicle an independent object, and the interface that the player has to control it has a clear scope.

    I could just as well have added Fly() directly to the ship, but that would not only have been less intuitive but interfered with other aspects of intuitive reality, such as getting in and out of the ship and transferring control to some other entity.

    So in the end, I modeled everything on a (simplified) model of reality, in a way that I believe people understand intuitively without having to look at things in terms of memory management. If I had to go with ECS I think it would be far more difficult to design.

    Anyway, I don't want to completely derail the thread, but I wanted to clear up that OOP in its precise definition is not exactly what I'm saying is intuitive, but rather gameobjects with their data and methods attached, and a limited-scope interface for interacting with other things. And this is relevant to games, not necessarily software in general.
     
  46. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    I don't think you would really have an issue, providing you grasp the principles of it.
    Here we are dealing with components in the end.


    You want have an engine component, then having system, which provides power, when engine is running.

    Then you have vehicles, like car, bike, boat, or plane. Each tagged as well with relevant components. Attach engine component to them, and you will receive power.You may decide also have battery component, which provides alternative power.
    Car and bike may have wheels propulsion, boat and airplane propellers. Give them power, and they will put your vehicle in a corresponding motion.

    You want some weapons mechanics, attach component with gun to a vehicle. Separate system will deal with gun behaviour.

    Now you can derive many types of vehicles, based on a car component. I.e.small and big cars. You can mark them with relevant components like taxi, bus, truck, private car etc. etc.


    So again, I don't think you will have an issue designing using ECS.
     
    NotaNaN and MadeFromPolygons like this.
  47. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    It is not intuitive, though.

    It takes quite a bit of time to adjust to component based way of thinking when switching to unity, before the whole thing "clicks". It is easy to forget about this phase later, but unity's approach is definitely not the default way of doing things. yes, it can be quite elegant/clever/etc when you GOT it, but that's definitely not the first approach plenty of people are going to try.

    The intuitive idea that most programmers will try to implement - is passive components all over the scene driven by the managers.
     
    Ryiah likes this.
  48. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    There are alot of principals in OOP that existed before OOP, composition is one of them. Monobehaviors are components on a gameobject. Are you saying that is not OOP?

    edit: your own article links to my composition over inheritance.
     
  49. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,956
    While some programmers may have decided to categorize it as a core principal of object oriented programming at the end of the day the categorizations of different principles is just their opinion.
     
    Last edited: Dec 11, 2020
  50. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    JavaScript does not have inheritance (in the normal sense) are you staying its not a OO language?