Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Antidamage View Post
    You even have a plugin in your sig. :P

    Can't compile a blueprint to a plugin as far as I'm aware. We need to add a side case where we understand that plugins are like packaged engine customizations. I certainly can't talk to DLLs using blueprints. All the stuff Rama does works way better as C++ modules.
    Code required to convert any BP project to a "C++" project and be eligible for compiling plugins:

    Code:
    // MyGame.h
    #pragma once
    
    #include "Engine.h"
    
    // MyGame.cpp
    #include "MyGame.h"
    
    IMPLEMENT_PRIMARY_GAME_MODULE(FDefaultGameModuleImpl, MyGame, "MyGame");
    
    // MyGame.Build.cs
    using UnrealBuildTool;
    
    public class MyGame : ModuleRules
    {
        public MyGame(TargetInfo Target)
        {
        }
    }
    If that much code is your excuse for not using BP...sigh

    Comment


      Originally posted by Szabo View Post
      Thanks guys.

      My problem with BP is not the performance (although I have plenty of prototypes on hold because of performance issues, and BP isn't exactly performant), but the problem is, I think writing code is a really nice way to program. I don't like visual programming at all. I can't even stand the material nodes in most 3D packages and surely don't want something similar to create logic.
      I always wonder how people with absolutely no affinity for visual stuff can even end up developing games. What I understand even less though, with your programming background you should be absolutely ecstatic you can use something as expressive as C++ and have access to the engine code. Even if you don't understand a thing (hell I don't understand 99% of it either, but I sure find it exciting). Anyway, you seem to have made up your mind that blueprints are too visual and C++ is too codey or something, so have you checked out the following intermediary solutions?

      http://skookumscript.com
      https://mono-ue.github.io

      Granted, the Mono effort seems to have stopped, but Skookum looks great for someone like you. It's been in development for a long time though, and they've gone rather quiet, but a release can't be far away now. Maybe you can get on the beta. Just be aware that by avoiding blueprints completely you'll be missing out big time. They are just too integral to ignore. Even if you went with C++ you very much want to use blueprints in tandem. Both are meant to work together.

      Comment


        Originally posted by Gigantoad View Post
        Even if you don't understand a thing (hell I don't understand 99% of it either, but I sure find it exciting).
        If only everyone had that attitude!
        Marketplace Assets

        Advanced Mobile Input: Marketplace Page | Support Thread ――― Easy Input Remapping: Marketplace Page | Support Thread
        Multiplayer Blueprint Chat System: Marketplace Page | Support Thread ――― Closing Credits System: Marketplace Page | Support Thread
        Minesweeper Template: Marketplace Page | Support Thread ――― Maze Creator: Marketplace Page | Support Thread

        Comment


          Unreal4 C++ is like C++ on training wheels, don't be afraid of it, get a good book, look at the unreal template's codem, figure it out, if you already know C# then it will just be annoying but not hard to master.

          This is been said before, the choice of C++ is because is the game industry standard, if you wanna become someone in this industry you have to learn C++, i wouldn't even consider using Unreal if it wasn't for it, as it would be a big waste of time, hence the reason i do most stuff in C++ including game jams.

          Comment


            Originally posted by Szabo View Post
            I hear people saying that all the time, but so far I didn't actually find anything (guide/tutorial or docs) that doesn't make me feel I'm going backwards in terms of technology.
            Not sure what you mean there.

            The idea is that you should use technology you're the most comfortable/productive with, not the "newest/shiniest/most popular" one.

            After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
            • because it is garbage collected, you can't actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
            • However, unity does not garbage collect scene objects.
            • But because it is technically garbage collected you can't apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
            • No multiple inheritance.
            • No protected inheritance. Interfaces are public inheritance.
            • No const parameters in functions. No const references.
            • No const functions. I wanna ensure that this function can't change my class instance, dammit.
            • Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if you're not using it.
            • I believe there's trouble if you'll try to pass out parameter to another function with "out" parameter. You'll need to create temporary.
            • Type deduction for generics is inferior.
            • No type aliases or typedefs. Having to type "TMap<String, TList<MyStructureStorageType>>" every time is great.
            • "var" does not work in class declaration. "TMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();"! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
            • No macros means you can't collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
            • You'll have to use Unity serializer, but it does not support generic types. At all. You'll need to inherit class from generic type container, then mark it as [System.Serializable].
            • Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its *.h/*.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
            • Defining object equivalence by implementing Equals() is "FUN". There's no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.


            That's just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the json serializer out of the box (you'll need to download unmainatained third party script or buy it for $20 from asset store).

            The ONLY good feature C# has is reflection (You'll hear "don't use reflection, it is slow!" all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And that's it. Those two advantages are outweighted by huge number of issues.

            So, I'd rather not see Epic team waste their time impelmenting C# binding. You're free to implement them yourself, just keep in mind that according to EULA you'll have to release those language bindings for free.

            As it was mentioned, epic team put some effort into making your life easier by implementing some helper facilities. So you shouldn't have much trouble if you already have experience with C#.

            Originally posted by Antidamage View Post
            If you're comfortable limiting yourself to last-gen stuff then Unity is fine for your needs.
            Err, no. Unity has number of superior technologies, except that many of them are buggy.
            C# is not one of those better technologies.
            For example, realtime precomputed global illumination is still experimental in unreal 4, but it is implemented in unity. You bake scene in specfic way and you'll be able to change light color/intensity on runtime, and changes will propagate across scene, with light bounces. However, on highly modular setup every object might receive random tint (it is significantly worse than lightmass seams) and those realtime baked lights won't be casting any dynamic shadows.
            Also, mecanim can retarget root motion properly, which is not the case with Persona animation retargeting at the moment.
            Last edited by NegInfinity; 10-28-2015, 02:02 AM.

            Comment


              Originally posted by bleeds187 View Post
              C++ is not like C#, especially with the UE4 macros, conventions and added complexity; its not for the feint of heart (not saying you are, but until you do a big project with UE4 C++ you should want to do nothing more than a Hello World and work up the chain).
              Yeah, perhaps I'm skipping the 'Hello World' part. .
              Originally posted by Gigantoad View Post
              I always wonder how people with absolutely no affinity for visual stuff can even end up developing games. What I understand even less though, with your programming background you should be absolutely ecstatic you can use something as expressive as C++ and have access to the engine code. Even if you don't understand a thing (hell I don't understand 99% of it either, but I sure find it exciting). Anyway, you seem to have made up your mind that blueprints are too visual and C++ is too codey or something, so have you checked out the following intermediary solutions?

              http://skookumscript.com
              https://mono-ue.github.io

              Granted, the Mono effort seems to have stopped, but Skookum looks great for someone like you. It's been in development for a long time though, and they've gone rather quiet, but a release can't be far away now. Maybe you can get on the beta. Just be aware that by avoiding blueprints completely you'll be missing out big time. They are just too integral to ignore. Even if you went with C++ you very much want to use blueprints in tandem. Both are meant to work together.
              Visuals are too much overrated imho. I don't know why everything has to be "visual" nowadays.
              Also, I don't think most former C++ developers who went C# want to go back to C++, so I don't understand why you're surprised at all.
              BTW, Skookum seems good enough. Thanks for the recommendation. There are things to consider though, specially because I've learned my personal quota of 'obscure stuff that serves nothing nowadays', I'm not saying that Skookum is going to fail or something, but I surely have to think twice before investing time learning something that so far doesn't seem very widely adopted, I mean, is that knowledge valuable if I end up not using it at all?
              Originally posted by KukoBar View Post
              Unreal4 C++ is like C++ on training wheels, don't be afraid of it, get a good book, look at the unreal template's codem, figure it out, if you already know C# then it will just be annoying but not hard to master.

              This is been said before, the choice of C++ is because is the game industry standard, if you wanna become someone in this industry you have to learn C++, i wouldn't even consider using Unreal if it wasn't for it, as it would be a big waste of time, hence the reason i do most stuff in C++ including game jams.
              Not everyone in the game industry knows C++, that's for sure. Perhaps most programmers in AAA industry, but surely not everyone. I don't want to be a 'programmer', so, being able to read and understand C++ properly is more than enough for me imho.


              Originally posted by NegInfinity View Post
              Not sure what you mean there.

              The idea is that you should use technology you're the most comfortable/productive with, not the "newest/shiniest/most popular" one.

              After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
              • because it is garbage collected, you can't actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
              • However, unity does not garbage collect scene objects.
              • But because it is technically garbage collected you can't apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
              • No multiple inheritance.
              • No protected inheritance. Interfaces are public inheritance.
              • No const parameters in functions. No const references.
              • No const functions. I wanna ensure that this function can't change my class instance, dammit.
              • Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if you're not using it.
              • I believe there's trouble if you'll try to pass out parameter to another function with "out" parameter. You'll need to create temporary.
              • Type deduction for generics is inferior.
              • No type aliases or typedefs. Having to type "TMap<String, TList<MyStructureStorageType>>" every time is great.
              • "var" does not work in class declaration. "TMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();"! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
              • No macros means you can't collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
              • You'll have to use Unity serializer, but it does not support generic types. At all. You'll need to inherit class from generic type container, then mark it as [System.Serializable].
              • Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its *.h/*.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
              • Defining object equivalence by implementing Equals() is "FUN". There's no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.


              That's just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the json serializer out of the box (you'll need to download unmainatained third party script or buy it for $20 from asset store).

              The ONLY good feature C# has is reflection (You'll hear "don't use reflection, it is slow!" all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And that's it. Those two advantages are outweighted by huge number of issues.

              So, I'd rather not see Epic team waste their time impelmenting C# binding. You're free to implement them yourself, just keep in mind that according to EULA you'll have to release those language bindings for free.

              As it was mentioned, epic team put some effort into making your life easier by implementing some helper facilities. So you shouldn't have much trouble if you already have experience with C#.


              Err, no. Unity has number of superior technologies, except that many of them are buggy.
              C# is not one of those better technologies.
              For example, realtime precomputed global illumination is still experimental in unreal 4, but it is implemented in unity. You bake scene in specfic way and you'll be able to change light color/intensity on runtime, and changes will propagate across scene, with light bounces. However, on highly modular setup every object might receive random tint (it is significantly worse than lightmass seams) and those realtime baked lights won't be casting any dynamic shadows.
              Also, mecanim can retarget root motion properly, which is not the case with Persona animation retargeting at the moment.
              I agree with much of what you said. However I'm pretty sure that 'list' will end up way bigger in the opposite situation :P. Here are some points:
              [*]GC - yeah, sucks terribly, I agree, but it's still much better than not having it imho.[*]Lack of multiple inheritance really sucks. Workarounds are cheap and crappy.[*]ref is certain trouble. Sure.[*]Equals() is sure nonsensical... I'm not sure if there's no standard though.

              I've either never experienced/needed the other stuff, or they work great for me, for example /out/ always was great, and lack of type aliases/typedefs i never really needed but i see how they could be useful... autocompletion helps immensely here though, but I agree that it could get too verbose.

              Something important you mentioned is the asset store. Everything nowadays ends up in the asset store. It's the solution to all your problems, there's no problem in that per se, except when most of these solutions clearly should be built-in.

              I'm not a fan of reflection. Sendmessage for example, which is widely used, I find that extremely ugly, or passing a string in GetComponent, it feels to me like bad code that will break soon :P. Most people seems to be OK with that though.
              Last edited by Szabo; 10-28-2015, 10:13 AM.

              Comment


                Originally posted by Szabo View Post
                I agree with much of what you said. However I'm pretty sure that 'list' will end up way bigger in the opposite situation :P.
                Don't think so. I've spent plenty of time with C#/Unity.

                Originally posted by Szabo View Post
                Something important you mentioned is the asset store. Everything nowadays ends up in the asset store. It's the solution to all your problems,
                Err, no. Definitely, no. Usually, every asset you find in asset store has some hidden fun problem you won't ever discover until you actually buy it.

                Buying anything coding-related is definitely not recommended. There's maybe 3 good assets total. The rest is people trying to rip you off.

                Asset store is decent (not good, just decent) when you need art assets. Models, or textures. Even in this case, It is highly possible that after forking out $50 you'll discover that the dude who made your pack didn't know how to make proper normals (so every box-shaped object is smooth-shaded, so you'll have to fix them manually), or created ao/normal maps by running diffuse texture (which was taken straight from cgtextures.com) through filter (which will result in a big mess), or that animation pack is pretty much useless because everything is stiff despite allegedly being mocap.

                ----

                You may want to cut the chase and tell what's your point is. If you like unity workflow and C#, unity is still available, last time I checked.

                Comment


                  Originally posted by Szabo View Post
                  Yeah, perhaps I'm skipping the 'Hello World' part. .

                  Visuals are too much overrated imho. I don't know why everything has to be "visual" nowadays.
                  Also, I don't think most former C++ developers who went C# want to go back to C++, so I don't understand why you're surprised at all.
                  BTW, Skookum seems good enough. Thanks for the recommendation. There are things to consider though, specially because I've learned my personal quota of 'obscure stuff that serves nothing nowadays', I'm not saying that Skookum is going to fail or something, but I surely have to think twice before investing time learning something that so far doesn't seem very widely adopted, I mean, is that knowledge valuable if I end up not using it at all?
                  I wasn't talking about high end visuals. Even the most ugly programmer art is visual in nature. Games are a visual medium. Even if you made a game for blind people you'd have to think visually, just that you'd use sound and dialog instead of graphics to paint images in the mind of a blind person.

                  Skookum is a very specialized game scripting language. The chances of you ever using it outside of UE4 are slim to none. But it has very easy syntax and nothing you learn is ever useless. It's also meant to work with both blueprints and C++, not as a replacement though. So there's that again.

                  If you're thinking about the value of learning a language it sounds to me like you do want to be a programmer, which you refuted a few lines down. So, what exactly do you wanna do in games? There's not a whole lot of room in between visuals and programming really, if you want to do neither. The fields in between are usually hybrids of both sides, like technical artists.

                  You can plead and hope for C# in UE4 all day long but it's a waste of time. The chances of an officially endorsed by Epic C# are practically none existent. Too much work for very little benefit. Too narrow a space to cover in between the very scripty blueprints and the very powerful C++. And what's so incredibly visual about blueprints anyway? Surely as a programmer you've made some class or flow diagrams before. Do you consider that too visual as well? Blueprints are essentially just diagrams, what could possibly be so unmanageable about that.

                  Comment


                    Originally posted by NegInfinity View Post
                    Usually, every asset you find in asset store has some hidden fun problem you won't ever discover until you actually buy it.
                    Exact. When you Google how to do something, a lot of the times you end up in the Unity answers and most answers are about buying stuff on the asset store, what's a subpar solution for most cases, and specially when the problem you're having should be provided natively by Unity.
                    Originally posted by Gigantoad View Post
                    I wasn't talking about high end visuals. Even the most ugly programmer art is visual in nature. Games are a visual medium. Even if you made a game for blind people you'd have to think visually, just that you'd use sound and dialog instead of graphics to paint images in the mind of a blind person.

                    Skookum is a very specialized game scripting language. The chances of you ever using it outside of UE4 are slim to none. But it has very easy syntax and nothing you learn is ever useless. It's also meant to work with both blueprints and C++, not as a replacement though. So there's that again.

                    If you're thinking about the value of learning a language it sounds to me like you do want to be a programmer, which you refuted a few lines down. So, what exactly do you wanna do in games? There's not a whole lot of room in between visuals and programming really, if you want to do neither. The fields in between are usually hybrids of both sides, like technical artists.

                    You can plead and hope for C# in UE4 all day long but it's a waste of time. The chances of an officially endorsed by Epic C# are practically none existent. Too much work for very little benefit. Too narrow a space to cover in between the very scripty blueprints and the very powerful C++. And what's so incredibly visual about blueprints anyway? Surely as a programmer you've made some class or flow diagrams before. Do you consider that too visual as well? Blueprints are essentially just diagrams, what could possibly be so unmanageable about that.
                    Afaik, 'visual' has nothing to do with 'structure', but it's about using your eyes to figure stuff, for example, when you're coding, a function call is an 'imaginary link' (sorry the terrible term), when using BP, there's no such a thing, the 'link' is a visible line on screen.

                    Also, that statement "nothing you learn is ever useless", unless you're talking about the little bit of experience you can use on other stuff, is very flawed. I'm the living proof. I know a truckload of things I've never used in practice and surely will never use. It was a huge waste of time learning them.

                    I don't agree there's nothing else in game development than graphics artists and programmers too.

                    The blueprint 'programs' I've seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.

                    Comment


                      Originally posted by Szabo View Post
                      Exact. When you Google how to do something, a lot of the times you end up in the Unity answers and most answers are about buying stuff on the asset store, what's a subpar solution for most cases, and specially when the problem you're having should be provided natively by Unity.

                      Afaik, 'visual' has nothing to do with 'structure', but it's about using your eyes to figure stuff, for example, when you're coding, a function call is an 'imaginary link' (sorry the terrible term), when using BP, there's no such a thing, the 'link' is a visible line on screen.

                      Also, that statement "nothing you learn is ever useless", unless you're talking about the little bit of experience you can use on other stuff, is very flawed. I'm the living proof. I know a truckload of things I've never used in practice and surely will never use. It was a huge waste of time learning them.

                      I don't agree there's nothing else in game development than graphics artists and programmers too.

                      The blueprint 'programs' I've seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.
                      in Unreal4 you have the best of the best, Blueprints as an awesome replacement for scripting that doesn't require a learning curve, it's just intiutive (can't said that about LUA or other crappy scripting language) and then you have C++ which unless you try it in depth you'll love as a programmer, it's not like people is forced to use it, a lot of developer use it because it's great, and the fact that 99% of game engines are programmed in C++ proves that. Also if you notice there's lots and lots of Unity freelancers, why? because the ones who knows C++ are working on AAA games

                      Also i doubt anyone who has done some serious C++ and switched to C# for some reason (by job requirements most likely) don't want to go back to it, it seems to me that this is a "the right tool for the right job". Said that C++ is the right tool for game dev

                      If you can't appreciate Unreal 4 that way, then is not for you.

                      Comment


                        Originally posted by Szabo View Post
                        Also, that statement "nothing you learn is ever useless", unless you're talking about the little bit of experience you can use on other stuff, is very flawed. I'm the living proof. I know a truckload of things I've never used in practice and surely will never use. It was a huge waste of time learning them.
                        My point about learning was that it is knowledge and that never hurts. You can read in many programming books that you should learn several languages. Some go as far and say learn a new one every year. While I certainly wouldn't want to do that, they sure have a point that each language will add a little more know-how. Skookum is the only language actually completely made for game scripting. If you look here

                        http://skookumscript.com/about/look/

                        you'll see what makes it special.

                        Originally posted by Szabo View Post
                        I don't agree there's nothing else in game development than graphics artists and programmers too.
                        Uh, well what else is there? Music, sound effects, marketing, business stuff of course... from what you wrote so far about wanting C# it doesn't seem like you're interested in those either.

                        Originally posted by Szabo View Post
                        The blueprint 'programs' I've seen so far are hardly encouraging. They are a mess of wires, nodes and components, surely they have nothing to do with complementary diagrams used for programming, which are generally very elegant and clean.
                        Blueprints can get messy, no doubt about it. Because of their visual nature they tend to promote bad code habits in general. But with a little care you can keep them fairly clean. You can combine nodes in functions and macros, you have both global (per BP) variables and local ones in functions. You have classes, inheritance, interfaces. Components aren't much different than prefabs in Unity. It's just a bunch of stuff that belongs together. There are even blueprint components. Say you want to make a piece of code that makes an actor move up down a bit, like a floating animation of sorts. Make that as a separate component and now you can add it to any actor you want with a few clicks and they will float.

                        Comment


                          Originally posted by Gigantoad View Post
                          My point about learning was that it is knowledge and that never hurts. You can read in many programming books that you should learn several languages. Some go as far and say learn a new one every year. While I certainly wouldn't want to do that, they sure have a point that each language will add a little more know-how. Skookum is the only language actually completely made for game scripting. If you look here

                          http://skookumscript.com/about/look/

                          you'll see what makes it special.



                          Uh, well what else is there? Music, sound effects, marketing, business stuff of course... from what you wrote so far about wanting C# it doesn't seem like you're interested in those either.



                          Blueprints can get messy, no doubt about it. Because of their visual nature they tend to promote bad code habits in general. But with a little care you can keep them fairly clean. You can combine nodes in functions and macros, you have both global (per BP) variables and local ones in functions. You have classes, inheritance, interfaces. Components aren't much different than prefabs in Unity. It's just a bunch of stuff that belongs together. There are even blueprint components. Say you want to make a piece of code that makes an actor move up down a bit, like a floating animation of sorts. Make that as a separate component and now you can add it to any actor you want with a few clicks and they will float.
                          To tell the truth, I've checked Skookum back when I played Sleeping Dogs :P. I always check those techs in games splash/credits. It seems good indeed. The problem is comparing it to C++, I think I'd rather get some C++ experience than learn Skookum, not that it's bad or something, it's just a matter of where I'm gonna place my bets.

                          I was thinking game design :P.

                          I totally didn't understand that part about Unity prefabs.

                          Comment


                            A language is just the interface to express your logic, if you can express what you need to in Blueprints, then more power to anyone who can. C++ is a bit lower level than C#, and with the UE framework, a lot of the guess work is already removed. As for people going to and from C++/C#, it depends on what your doing, you use the language that makes the most sense for the job, going "back" to C++ from C# is no different than going from "Python" to "PHP", one job required one thing, a different one required another one. Depending upon how adventurous you are, finding something that would bind your c# library to a c++ library is something you may want to look for.

                            Comment


                              Originally posted by Alezrik View Post
                              A language is just the interface to express your logic, if you can express what you need to in Blueprints, then more power to anyone who can. C++ is a bit lower level than C#, and with the UE framework, a lot of the guess work is already removed. As for people going to and from C++/C#, it depends on what your doing, you use the language that makes the most sense for the job, going "back" to C++ from C# is no different than going from "Python" to "PHP", one job required one thing, a different one required another one. Depending upon how adventurous you are, finding something that would bind your c# library to a c++ library is something you may want to look for.
                              I agree!

                              That example is a little bit excessive though, I'm sure that going from C# to C++ isn't as bad as going from Python to PHP. The latter case is much more traumatic and nonsensical, unless of course you need to use PHP systems, otherwise I see absolutely no reason not to use Python, unless you want to get bald. You're comparing the best and worst languages I've ever used.

                              Also, I sure agree that there may be reasons to use C++ over C#, no doubt in that, however, I don't see why one wouldn't consider C# completely usable for game development, it's not like it's not the right tool for the job, of course there are some 'cons', but it's totally suitable imho.

                              That's not being adventurous, that's being sadistic and suicidal .

                              I found some good unofficial tutorials, I'm gonna give C++ a 89102th try. Another thing to consider is the better 'obfuscation' of your IP, on C# you basically ship your source (open any compiled project with ilspy and you'll get pretty much the exact source), C++ is much better, although of course not perfect, it's surely not worthy to "decompile" a C++ game, it's much easier to re-code everything, while Unity stuff you can pretty much copypasta code from ilspy and with minor modifications you can use it.

                              Talking about IP, does BP have some kinda obfuscation?
                              Last edited by Szabo; 10-29-2015, 11:00 AM.

                              Comment


                                I have been lurking in this thread for a very long time..it's about time i posted

                                Originally posted by NegInfinity View Post
                                The idea is that you should use technology you're the most comfortable/productive with, not the "newest/shiniest/most popular" one.
                                I agree with this.

                                However this

                                Originally posted by NegInfinity View Post
                                After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
                                • because it is garbage collected, you can't actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
                                • However, unity does not garbage collect scene objects.
                                • But because it is technically garbage collected you can't apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
                                • No multiple inheritance.
                                • No protected inheritance. Interfaces are public inheritance.
                                • No const parameters in functions. No const references.
                                • No const functions. I wanna ensure that this function can't change my class instance, dammit.
                                • Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if you're not using it.
                                • I believe there's trouble if you'll try to pass out parameter to another function with "out" parameter. You'll need to create temporary.
                                • Type deduction for generics is inferior.
                                • No type aliases or typedefs. Having to type "TMap<String, TList<MyStructureStorageType>>" every time is great.
                                • "var" does not work in class declaration. "TMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();"! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
                                • No macros means you can't collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
                                • You'll have to use Unity serializer, but it does not support generic types. At all. You'll need to inherit class from generic type container, then mark it as [System.Serializable].
                                • Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its *.h/*.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
                                • Defining object equivalence by implementing Equals() is "FUN". There's no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.
                                I completely disagree, C# and C++ are two different beasts. How can C# be so unpleasant to work with after using C++ ? Why ? because of what you posted ? Well i could make a fairly good argument to use C# and not C++, because of those reasons, it would take awhile and im at work so I'm not going to waste my time, but just because those things seem limiting, in actuality they aren't as limiting as you think. I use both in my day job, and both have their place, C++ isn't inherently better than C#, and neither is C# inherently better than C++. It's a completely different beast is all. Most of your complaints are things that the creators literally choose by design. You can't complain about the design of a language just because it doesn't make sense for you. C# wasn't even really meant for public consumption it was made specifically to be economical towards memory and processing power for a specific company, and was never meant to even directly or indirectly compete with C. I mean the creator of C# himself said that the CLR was driven by the flaws of major languages like C++, java, smalltalk. Which in turn drove the design of C# itself.

                                If you were to base a comparison of C# and C++ purely on modern features. C# wins.

                                I don't hear you complaining about C++'s archaic compilation model, all the inherited legacy C garbage, classes vs structs, new keyword, exceptions or the ghastly multiple inheritance implementation, complexity added when operator overloading, template syntax, complicated atomics, c++ never protecting you from yourself...I mean there are allot of problems which make C++ problematic.

                                Originally posted by NegInfinity View Post
                                That's just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the json serializer out of the box (you'll need to download unmainatained third party script or buy it for $20 from asset store).
                                A JSON Serializer isn't necessary for game dev, you have to realize what you're using, a game engine. There are going to be allot of things you don't have. That's why things like an asset store exist. Also, on the same note, in response to you saying you can never really know if a product from the asset store has a bug, well that's the same for any program, is it not ? I mean UE4 has bugs. Your games, my games have bugs. yes all software has bugs. you paid for the assets in its current state, you did not pay for something claiming to be 100% bug free.

                                Originally posted by NegInfinity View Post
                                The ONLY good feature C# has is reflection (You'll hear "don't use reflection, it is slow!" all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And that's it. Those two advantages are outweighted by huge number of issues.
                                ??? To say the only good feature that C# has is reflection is a bold statement to say. Many many people will disagree with that.
                                Last edited by SaxonRah; 10-29-2015, 12:30 PM.
                                Youtube
                                Machine Learning C++ Plugin
                                Lindenmayer System C++ Plugin

                                Comment

                                Working...
                                X