If UT were to add a new programming language what one would be best?

But those aren't used for general-puprose programming, right? The further you get into DSLs (like my business rules examples) the easier visual representation becomes, and I suppose Blueprint is an example of this, but saying "text != programming" is not generally all that valid.

My first full-time programming job ('86) was writing visual database tools that spit out code... here again, highly domain-specific.

 

This kind of comparison of visual vs code oriented development is like everything else. All depends on the context of the objective and requirements.

For programmers using C, C++, C# etc I think just straight forward manual programming in a text editor will always be far more efficient.

When you are used to programming by writing everything out using visual programming just feels like you are working with lead weights on your wrists. Slow. Tedious. And the feeling of being "boxed in".

With "normal" programming we can write code quickly to solve problems and have the creative freedom to choose one of many possible ways to implement something as well as greater potential for what can be done (meaning being able to do things the designer of the visual tool never considered).

On the other hand there are a lot of fields out there that do rely heavily on various VPL tools. Ladder Logic has been around for a long time. SQL DB visual design tools have been around a long time too.

In fact, there are VPL tools all over these days. Tools for making desktop apps, custom databases, building dynamic websites and of course creating games.

The only thing that confuses me about people wanting more VPL for game dev is this already exists. There are many great modern game dev tools out there that rely on VPL for game creation. Just need to stop looking at it from the "box" of Unity and take a look at what is out there.

 

Not trying to pick a fight over the details here, but letting a generator generate an sql database with frontend is not exactly rocket science.
Which is exactly where todays code generators excel. Creating stupid cookie cutter code for cookie cutter tasks that give the engineers that have to put up with it fits when they have to copy pasta the thing together.

Now, a) I would dare you to sit a person without ANY technical knowhow in front of that generator and ask him to generate the dabase and frontend (you most probably would get bogged down in explaining to him what a database and frontend is), b) I would dare you to come up with a more complex use case, and see if the code generator still spits out something that is of satisfying quality.

I would like to remind you of the horrors that were the HTML generators of old, Dreamweaver and the like. Guess they are still around, don't know if the code they spit out still sucks as much.
Sure, you could drag and drop your site together. And after some versions, the generated pages actually worked! And yeah, at least Dreamweaver was mighty good at handling the differences in javascript and html implementations between browsers... but damn was the generated code ugly and inefficient!

That probably didn't bother you when the tool did everything you wanted (like creating a simple static page)... as soon as you were trying to use the output as a starting point for a dynamic webpage written in PHP, Java or whatever other technology, you most probably would have been faster starting the HTML part from scratch. The only really useful part was the handling of different browsers in the javascript parts, because that was a BITCH to code by hand everytime.


Again, we are not talking about code generators for routine tasks. These work fine, even though the output is often of dubious quality. Though that often doesn't matter alright (most of the code written for business apps I have seen in my time I would classify as throwaway-code... and the rest is grossly over-engineered)...
What we are talking about is a system that allows a technically illiterate person to come up with new code to tackle not already solved problems. Because to be honest, these routine tasks are often already covered by existing code. Given that many "wheels" are already out there on the net, either for free or reasonably priced, I question why a person with obviously no knowledge of the subject matter should be empowered to invent one.

 

I had this same feeling before I gave Blueprints a serious look. Also, it was very hard to get over this (wrong) feeling that I was being "cheap" for not coding everything in C++.

Ultimately, I think they work better WITH C++ because C++ allows you to pick and choose what to expose to Blueprints which has a number of benefits. Blueprints also give you much quicker and easier-to-navigate access to "intellisense" type functionality.

1. Much cleaner Editor and Blueprints
2. Easy to refactor code out of your Blueprints and into a base class where needed.

While I think it's pretty clear that I am a bit biased towards UE4 over Unity in UT's current state, I must say that I will likely end up developing in Unity if I decide to work on this upcoming project since that is the engine that the team is more familiar with, and they are completely closed-minded when it comes to even DOWNLOADING AND TESTING FOR FREE Unreal Engine 4. I have never seen people so emotionally attached to a single engine as I have with Unity... where people literally pitch stripped down/void functionality and base-feature set as some sort of benefit of the engine...while also throwing around the "ITS FREE" nonsense...while then going on to say that everything that is missing from the engine is available on the "ASSET STORE" for purchase.

And there is a complete unwillingness to admit where Unity falls short. How can the engine improve when its user base cannot even admit there are problems.

 

Yeah, its not for general purpose stuff. Its very domain specific to the industry I'm in.

I'll agree with you there. Hand crafted programming is required for solving new problems.

But many problems have already been well and truly solved. And for those code generators work fine.

 

I would add that at that point, the question if a code generator is actually needed or good general purpose code already existing can fill the need is actually important.

Most of the time, "code generators" for such problems are basically just elaborate build scripts or configuration tools. I would shy away from calling such things code generators for many reasons, most important of those to circumvent those discussions BECAUSE many understand the word "code generator" as "a tool that lets average joe write any code". Which they clearly are not.


I guess we can then agree on that we need better access to solutions for already solved problems for the coding illiterate, be that already existing code, or more flexible solutions like buildscripts that build the final code according to specifications set by the user.
Giving the coding illiterate access to a tool that generates code for not already solved problems however might prove still too difficult, if not impossible to do, without those coding illiterates doing something against their "coding disability" (or better, generally developing a better understanding of the underlying technology, no matter if they learn a traditional language or not).
And if they do, the question arises if the already existing languages really cannot fill their needs.

 

It's just struck me the irony of debating if code generation is possible on the forums of a game engine. Game engines are perhaps the biggest code generation tools out there.

 

Are they? AFAIK they are basically just "build tools", in the sense that they take the input you made by laying out your scene in the editor, and assinging behaviour script to your objects, and compile that into a more performant format that can run fast on a given platform.

IDK if I would call that code generation. Its basically again building code from "configuration" for already solved problems.
Save your behaviour code, which might tackle new problems. But then again, this IS code that gets translated into some other format, so not exactly "code generation"


I guess we will spiral down into fighting over semantic details here, so I'll stop there

 

Isn't that the definition of a code generator?

Yup. This whole thread was doomed to go that way from the OP.

 

No?

Game engine usually is supposed to be a standalone program, that just gets different set of resources. Or they incorporate user code. I don't really remember any code-generating aspect in unity. UE4 has code generator similar to Qt Meta Object Compiler.

However, one could also argue that editor and engine are two different things (which is kinda/sorta reasonable), and in that case most of the engines would almost never generate code, while their resource editors and build tools sometimes do.

---------

Either way this is heading towards semantic argument full speed and I hate those.

"code" means "program code" and does not mean "machine code". "code generator" means a tool that produces output in high* level language (meaning C or above). This is a fairly uncommon behavior.Hence the game engine does not fit definition of "code generator", most of the time.

 

I almost fell into the semantics trap earlier. It seems we're talking about output, ultimately, so the divisions I'd draw are compiler, API, and finally code gen (probably visual in some way). Maybe add gian-reto-alig's "config/build" as the least like "real programming" of them all?

The use of the term "scripting" in Unity-land always kind of chafes me. I always thought, traditionally, scripts were interpreted, not compiled. Though I guess with all the JITs and IL and whatever else is out there, that was probably meaningless long before I ever installed Unity.

Meanwhile, speaking of scripting and getting back to languages, with Unity already committing to the use of Web Assembly internally for WebGL, once bytecode compilers and browser runtimes become widely available it seems likely that the mutant hack-job language we call Javascript is here to stay and will likely be highlighted as the low-bar starting point for non-programmers. After all, it kind of has that "easy" reputation today, I think (even though you can do complicated stuff with it, whether it's a good idea or not, and with all the bad decisions and horrible results that can bring).

I haven't ever used Unity with JS. It's currently some not-real-JS internally-built subset, as I understand it. Is that about right?

 

Fair enough.

Perhaps I'm just failing to see what one would use one of these code generators for. Or how it would look different from the current solutions we have for problem solving. Sure an access database, an excel spreadsheet or a Unity game might not be code. Neither are a dozen of the specific domain tools used by experts. However its worth remembering that code on its own is useless. Code isn't made just for the sake of having code. Code is made to solve problems.

Currently a computer can automatically put together prebuilt pieces to solve common problems. Much of what was called programming a couple of decades ago is now done automatically by the computer.

So what would we expect a code generator to do? Identify new problems on its own and structure the solutions? That's getting into general intelligence stuff. And it's something that many humans struggle to do.

 

Its basically C# that's been dressed up to look like JavaScript. It looks like JavaScript on the surface, but it doesn't really behave like JavaScript at all.

 

Ah, thanks. So much the better. Once compilers/runtimes are available, a Unity upgrade renames existing *.js files to *.ujs (for today's then-deprecated legacy UnityJS), deploys a webasm compiler, and viola, New Improved Beginner-Friendly Real Javascript Support can be advertised everywhere. They've clearly figured out the engine tie-ins already, it would probably be a nearly-free enhancement.

And we all gain whatever (probably limited) resources are currently devoted to making sure today's fake JS keeps working.

Seems more likely than getting support for either a custom language or some existing but new-to-Unity language.

 

Both of the alternative languages supported (officially and otherwise) are open source too.

https://github.com/bamboo/unityscript
https://github.com/bamboo/boo

 

Wait, you mean it is pure C#? I'd expect language binding to be partially on C++ side of the engine and well-hidden

 

It depends on what it is written for. Meta Object Compiler in Qt and unreal build tools generate hidden data structures and members that support named properties and stuff like that.

 

UnityScript is written in Boo. Boo is written in C#. I've only skimmed portions of the source but I'd be surprised if the language bindings weren't implemented at the CIL level. After all if I remember correctly there have been successful examples of people using alternative languages that were not shipping with Unity. It's just a very involved process.

Edit: Found the F# tutorial again. http://jacksondunstan.com/articles/3229

 

I will throw my vote in for C++. I already know how to use it. But really, I don't think one is needed.

 

C# is great and should stay. Take JavaScript away, add Visual Scripting for the Designers, and add C++ so we can get close to the metal if need be.

 

F# is your new God.

F# doesn't have The One Billion Dollar Mistake a.k.a. runtime null reference exceptions, either. I found handling states with F#, much better than in C#. F# is supported by the M$ Imperium.

This is what I wrote today on the FSharp Software Foundation #game_dev slack channel, regarding PlayMaker and NodeCanvas:

Of course there is one thing to keep in mind with F#. The whole reason why F# is much more powerful is because it's not Objected Oriented, but Functional. Programmers may have to learn more new things.

 

Moving from Scala to C#, just to develop games with Unity, I seem to miss the ability to mixin traits (interfaces) the most.

I know that there would be much technical difficulties and little demand for the language to expect it to happen. But personally, I really wish I could program in Scala when I'm developing with Unity, as it would make my API so much cleaner than it is now.

 

If you dont mind building your own assemblies, it is possible to use F# with unity and F# would be the closest thing the .NET world has to scala

 

Urg... I was so happy with my Rider IDE

 

Yeah, I already run into a problem. I'm just don't know what failed here. Is it Unity or CLR?

https://forum.unity3d.com/threads/f-values-get-stuck-and-require-editor-restart.464911/

 

Yes he really hates OOP.

I can only make strong cases for F#, though (for now). Yeah, F# does also support full OOP. But for those who don't know F#. OOP in F# normally only is for use with OO APIs/Frameworks/Engines.

 

I only watched a bit of that but agree on the writing generic code stuff. It is a burden. The way I see that stuff is it is fun to write like playing around with a toy building a little train set etc. But it just adds a burden in understanding the code later as well as for other people.

For all intent and purpose generic and abstract code and even inheritance are "dark magic" things. Increases the cost of maintenance by other people due to an increased complexity = more time required to understand how it works. Mainly because the idea behind it is often to hide how it actually works presenting the infamous black box. Fine some times. Terrible when you inherit the project for maintenance.

Especially the way so many people go so overboard with it breaking things out into seemingly as many separate files and components as they possibly can. And then generally not documenting any of it on top of it all.

 

I actually agree with Brian Will. It's just that he got from OOP is Bad to OOP is Garbage. If you mentioned C++ or Blueprints or visual scripting for game logic, I would tear you apart into individual atoms. But with OOP, I'm like "I agree". Time I looked up a psychologist. :/

 

I agree with him conceptually but not necessarily on needing a new language. People don't have to architect their programs the way they do. They do it primarily for two reasons: either they want to (they simply enjoy and even take pride in turning something simple & direct into something more abstract, generic and complex) OR they think they should be doing that to gain some benefit of doing so. Probably both cases ultimately come down to the second but I believe there are definitely people who love complexity and abstraction just for the sake of it in and of itself.

I think it is much like some people love trying to write a single line of cryptic code that does as much as it possibly can while simultaneously being very difficult to understand. It's kind of an ego boost "look at how clever I am" kind of thing where you'll have people proud of writing such things and others boasting "oh come on! it's easy to follow!" (even if they spent 3 days working on it themselves). lol

The biggest issue I see with such things is a person who loves complexity usually fails on the fundamentals. They may write fancy stuff, "beautiful" systems but they won't document any of it or very mimimally either due to not really understanding how it works or what exactly they are doing themselves or because that is too "easy" too boring.

To me great code and great design is such that you could take a beginner sit them down and they would be able to figure it out and pretty quickly depending on overall scope of course. That is the acid test of good code writing and architecture/design IMO and so I am much more impressed by simple high clarity code than cryptic/generic/abstracted/complex code.

 

I didn't watched the whole video, but I believe that he seems to have missed the whole point of OOP, and fell to one of the common misconceptions that supposes the smaller LOC or the simpler the structure a codebase has, the easier it becomes and more maintainable.

The whole point of OOP is to modelling a software in a way as closely as possible to the conceptual model we have in our mind of the world, so abstracting away the details in a hierarchical manner. In such a system, you don't really have to actually read the whole source codes to understand what a certain part of the code does.

If you see such a type signature like, "Button extends Component, Clickable, Themable" you can intuitively see that a Button is a type of Component that also reacts to mouse clicks, and can be decorated with a theme without even reading actual source files of any of the said super types.

Now, turn all those functionalities, like handling mouse events, applying themes, and etc to functions and put them all in the source file of the Button, like 'handleClick', 'applyTheme', and etc. (which, unfortunately, seems to be the way that monolithic MonoBehavior is designed in Unity, by the way.)

Does it make it any easier to understand? Some can argue that it does, since now we don't have to navigate the class hierarchy to follow the source code. But if you need to read the source code to understand and API which is designed following OOP principle, it's more likely that either the API is very badly designed, or you don't really understand the principle at all.

Maybe you can get away with just a handful of such random functions defined in a file. But what if the project becomes larger, and you have tens or even hundreds of them?

The biggest problem with this approach is that it mingles many different concerns in a single unit of source code, thus making it more difficult to understand and manage, despite it having a simpler hierarchical structure.

Increased number of classes, methods, or LOC doesn't necessarily makes a program more difficult to understand, but mingling concerns almost always does. So, even if you refuse to follow OOP, you will eventually have to find your own way of keeping things organized, like maybe defining relevant functions together, or even using common prefixes in their names, and etc. But now you are just doing basically the same thing as OOP does, namely enforcing some kind of a convention, or a method to organize the functionalities according to different concerns.

The problem is, while the convention and principles of OOP being almost universal so one can learn from reading online tutorials or reading books, you cannot say the same about your own 'local rules'. And with such languages like C# or Java, the core API itself is designed in OOP paradigm, thus it makes much more easier to understand and extend the functionalities if you own code follows the same principle as well.

Also, OOP can provide common methods of communication with 'design patterns'. If you don't understand what a 'Factory' is, for instance, you might think your if-else blocks are simpler and easier to understand. But it doesn't scale well with complexity of the project, and once you understand the concept of the Factory pattern, you will immediately understand intention of the author if you see such names like 'XXXFactory' in an API someone else wrote without even looking at the source code.

Of course, OOP is not a silver bullet in programming, and there can be many instances where you can write a good software without following its principles. However, there are very good reason why this paradigm has gained such support in the past few decades, and there are countless examples in which OOP contributed much to make a clean and manageable design.

The Functional Programming, however is a whole different problem than this naive 'simpler, the better' misconception of those who don't really understand benefits of OOP, as it has some real advantages over traditional OOP in certain type of situations.

However, I have a suspicion that it might be more of a valuable tool to solve certain types of problems, or to supplement traditional OOP paradigm, rather than be the 'silver bullet' which is supposed to cure every real and imaginary defects OOP has, as so many people seem to claim these days.

Maybe my view can change as I spend more time in FP in future. But for now, I'm quite happy with mixing OOP and FP as I see fit, as it's supported by some of the multi paradigm languages like Scala.

 

Capability to use C++17 similar to C# in Unity to avoid overhead of C#. I believe we can still use portable C++ libraries but I would like to use C++17 in a way similar to C# in Unity.

 

Actually, his point is that a lot of people using OOP have missed the point of OOP and are using it where they don't have to.

Which, in turn, is him missing the whole point that you use OOP all the time so when you really need to use OOP, you are thinking about your problem instead of how to use OOP because it is actually important now. You have thousands of hours of practice writing interfaces and establishing access levels, so you don't even need to think about it anymore.

The procedural approach doesn't scale. That's the problem. By electing the procedural approach, you don't just reduce the current size of the project, you also reduce the practical maximum size. And by spending all your time writing procedural instead of OO, you effectively reduce the practical maximum size of all projects you can ever do.

I could definitely keep extending my Frankensteinian creation of one core script for my game that just runs one massive Update call, but that would be wrong. It is already becoming hard to follow, and it's less than 5% complete. So I regard it as a proof of concept, and I turn to an empty project, and I start reimplementing with tiny little methods scattered through the object heirarchy.

This necessarily adds twenty and thirty lines to the project for every component I have to script, and there are going to be a couple hundred of those, so that's a couple thousand lines of "useless" code that I would not need if I just wrote a ten thousand line Update call.

But that code pays off when I get the bug report about a slider not working, and instead of trying to hunt down where in that Update call I deal with that slider, I just open the slider component and edit the script and hey presto all the code is right there. And that scales to thousands of components, not just hundreds. When you say "problem in this object," I just open that object, and the problem is there somewhere.

The real money quote: "I wanted to demonstrate how it would be better in a straight procedural style. Now, I'm not going to give a full account of how the emulator works, because honestly... the details... I'm sketchy on myself, because i don't understand the NES hardware."

Then how does he know the project is better?

 

What I find funny about that statement of his is that one of the advantages of object-oriented programming is that you don't need to understand how the object functions under the hood in order to use it. You just need to understand how to use the public variables, properties, and methods.

His attempt to discount it is itself an example of why it's useful.

 

One might even speculate that had the code not been object oriented, he would not have been able to rewrite it in the first place.

 

Quite possible though after reading a statement he made in one of his articles I'm starting to believe it's more that he never truly understood object-oriented programming. Whether that's because he was so set in his ways that he never truly embraced the concepts or he simply abandoned it before giving it a fair chance I don't know.

https://medium.com/@brianwill/object-oriented-programming-a-personal-disaster-1b044c2383ab

I remember my own early attempts to learn object-oriented programming were held back by my knowledge of procedural programming and that I didn't start feeling proficient with OOP until I started letting go of some of the design concepts that came with procedural. Unlearning previous coding habits is sometimes necessary to start learning new ones.

He has a tutorial website linked in his YouTube profile but the tutorials are simply all over the place and far too simplistic to be of any real benefit in my opinion. At best they might serve as a very rough introduction to the concepts they cover but that's it.

http://codeschool.org/

Briefly checking his personal website, his YouTube profile, and a couple of the sites he frequents turned up absolutely nothing about the guy. No mention of a resume. No mention of a professional profile on a website like Linkedin. Nothing.

 

And sometimes you don't appreciate the new ones until you revisit the old ones. I know I had a renewed respect for component-oriented development when I had to go write a bunch of COBOL around the Y2K period, which let me approach C# with an open mind and not "IT'S LIKE THE RETARDED OFFSPRING OF JAVA AND VISUAL BASIC"

 

Yes! A few months back I came up with the brilliant idea to revisit an old project of mine (my highschool text adventure engine) and attempt to rebuild it to the best of my ability with the exact same language (QuickBASIC).

I had a rough idea of how to approach the project but between the lack of a framework of common tools and a lack of certain language features (namely a reference/pointer equivalent) I quickly decided I couldn't bring myself to spend more than a day trying. Basic features would have easily taken many times the same amount of code compared to C#.

At this point in time I've basically written it off. Future recreations will be with modern conveniences.

 

The entire reason I picked up Unity early this year was when I realised that the first game I ever actually finished... was finished 25 years ago. So I thought "How would I do that if I did it today?" and that has been a fun and fascinating journey.

 

It could be he did understand it and just didn't agree with it. Perhaps not but it is possible. I once loved OOP and thought inheritance was cool as hell. Then I embraced composition and thought it was much better than inheritance because it is more flexible and programs don't become quite as bloated as they often do with inheritance.

Now I see it all basically the same. 6 one way half a dozen the other. I can have a little enemy object that encapsulates all of its states and all of its logic and manages itself or I can have a manager class (static or singleton) that manages an array or list of enemy objects that are basically just state containers and all of the logic is inside the manager class. Neither way is really better than the other.

It is kind of just what a person prefers and that can and often does change over time. Sometimes just because you want to do things differently simply for a change from doing things the same old way. One day I may well be embedding the logic inside objects again or maybe even using inheritance or whatever. But I don't view any given approach as inheritantly better than the others.

Mainly because I think the fundamentals are most important and they apply no matter which paradigm I am currently wrapped up in. Even straightforward procedural programming.

 

Quite possibly but between the videos and the articles it feels like he wants attention and isn't simply disagreeing. We have disagreements on these forums all the time and yet very few of them become anything more than simply that. YouTube is a perfect place to grab that attention too.

Just off the top of my head I can think of one situation where having the manager class performing the heavy lifting is a much better choice than the other. When you need a great number of objects on the screen acting somewhat independently of the others. Particle systems are a very common example but a real-time strategy game with large numbers of units is another.

 

C# should stay no matter what...
C++ will be good to add... and some visual scripting
that's it... (and maybe throw away javascript... but that depends on how many people are using it)

 

I wonder if programmers are addicted to complex syntax, as a way to justify what they do as it looks complex and unreadable?

So do you wonder why we need such powerful editors, compilers and debuggers to help us find the bugs in our code.

What if you could have a new language with parallelism build in that can be compiled to the CPU or GPU (shader/compute programming) and it had a simple clean syntax?

Would it undermine your programming genius as it does most of the complex stuff for you or enable and empower you to do more faster?

 

Check out this comparison of Swift and C# syntax notice the simplicity of Swift http://pietschsoft.com/post/2014/06...C-and-Apple-Swift-Programming-Language-Syntax

Code (CSharp):

1. // Iterate from 1 through 5
2. // C#
3. // using increment
4. for(var i = 1; i <= 5; i++) {
5.     // do something with i
6. }
7.  
8. // Swift
9. // using range
10. for i in 1...5 {
11.     // do something with i
12. }
13. // using increment
14. for var i = 0; i <= 5; ++i {
15.     // do something with i
16. }

You have to love the lack of brackets on if and for statements, and the 1..5 loop beautiful.

Code (CSharp):

1. // Function with Parameter and Return Value
2. // C#
3. string sayHello(string name) {
4.     // do something
5. }
6.  
7. // Swift
8. func sayHello(name: String) -> String {
9.     // do something
10. }

Then again Swift's function calls, and a colon to Type a variable Yuck!

 

I agree with you that there's no 'correct answer' in a matter of choosing a development paradigm or design, so in many cases it falls back to each developer's personal preferences.

However, I suppose we cannot ignore importance of searching for the best practices, and establishing what could be the sound principles in writing softwares in a way that improves productivity and managablity.

For instance, even though it's up to individual developers discretion to determine variable names, that doesn't mean you can name them whatever you like, like 'a1, a2, a3, ... a99999' or 'paul, jane, kate, chloe, ...' and etc.

So, what could be such best practices or good design principles are always open for a debate, but I suppose one better come up with some persuasive arguments, if he wants to criticize such a widely accepted principle like OOP.

And if all he can say against OOP is it makes you write more number of functions/methods, and if what he suggests as a remedy is simply returning to the pre-OOP way of doing things, I can't say I'm convinced of his arguments.

 

When writing OO code. Ask yourself how many questions you have to consider when implementing. Like, should I use: struct, or enum, or class? Field or property? Inheritance or interface? Private, public, or protected? Sealed or abstract? Virtual override?

Geez... and really, what for?

In F#. Well, this list may be incomplete since I'm a noob with F#.

Should I use: Union or record? Refactor that one mutable, to immutable, because I hate mutables? Into which module? *anything else?*

The F# compiler was written in F#. And it ought to be complex?! So, F# can take on complexity without the downsides.

When you are data oriented, then the data itself already tells you what you can do and what not, and what it does, or is, in the first place. This was one of the arguments of Brain Will. And I think he is right.

I know. I saw the date before I posted. But, I decide that you may want to jump off a bridge. I can also push.

 

Also, F# Unions are a very good examples for that. The very reason why they can do state machines better than C#, is because they enforce the state structure just by their own definition. You can assign a type for a Union case if you need. Enums are loose stupid labels only. They are dependent on how the switch-case handles all. They don't tell much by themselves. And with OO state machines. You need generics and inits, and more freaking classes.

Yeah, with F# I could ditched the need for a FSM in editor. Like PlayMaker or NodeCanvas. All because how the data is talking to me.

I don't see how all that OOP jazz, does really structure so much better. For what it's worth. F# is multi-paradigm. So, F# does have full support for OOP programming. If you really need it, you can use it. Or just ditch it.

 

Um... the answer to each and every one of those questions is dictated by the nature of your project.

If you aren't sure how to answer them, you don't understand what you're doing.

 

I agree completely! These are the things that do matter and are most important. That's what I was referring to by the fundamentals. Naming is a perfect example. Consistency is another. Favoring smaller blocks of code over larger. Having the purpose of those blocks be to handle only one thing or a tiny number of very similar or associated things. Etc. The fundamentals can be applied regardless of using procedural programming or OOP, inheritance or composition heavy architectures.

 

Well not really but it is a perfect example of why I generally prefer the manager approach for games. Still this is a matter of preference. Each thing we do... each different approach... has pros and cons... good and bad... and those are what make it all a matter of preference.

One person will favor "real objects" wanting them to manage themselves above all else. Another person will favor raw performance over all else. And so many other pros and cons about each thing.