Announcement

Collapse
No announcement yet.

I want Feedback from Epic about Mono for Unreal Engine

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

    #16
    Xamarin's C# integration is promising and follows a technically well thought-out design, however this is a fairly complicated topic.

    The challenge with this and other programming language integrations into Unreal Engine 4 is that, unless they were to be genuinely and thoroughly adopted by Epic, they would not quite be first-class citizens in the way that C++ and Blueprints are. Specifically, we put substantial work into documentation, samples, pre-release testing, compatibility, porting, and support on C++ and Blueprints that we can't feasibly replicate for a third-party plug-in. For example, unless the documentation on UE4 programming were updated to include side-by-side examples of C++ and C#, the programming experience with C# in UE4 could feel disjointed, and this downside may outweigh the upside of one's familiarity with C# and its easier header-free programming model.

    Programming language integrations are very different in nature than middleware integrations such as SpeedTree and Substance in this regard. Though the later are feature-rich, they are fairly self-contained in their interactions with UE4. A programming language integration can interact with just about any part of the engine and therefore has unlimited scope.

    For these reasons, we updated the UE4 EULA to require redistributed programming language integrations to be free and open source, so that if one gained a critical mass in popularity, Epic could adopt it and ensure its future viability in the areas described above. I'm hopeful Xamarin's C# integration goes this route in transitioning from closed beta to full release but I can't speak for them.

    There is another key point to consider: C# in UE4 more closely resembles C++ in UE4 than it resembles C# in Unity. Unity users coming from a background working with the componentized C# behavior model with Unity's MonoBehaviour framework will find that UE4 doesn't follow that model and therefore the emergence of UE4 C# support isn't quite the hoped-for panacea.

    Finally, when an engine is written in C++ and gameplay is scripted in another language, the interoperability barrier between languages eventually grows overwhelming. This is why we ultimately abandoned the UE1-3 era's UnrealScript language and moved to a pure C++ programming model. This gives UE4 the ironic property of making it harder to learn the engine and start writing a game, yet ultimately easier to grow, finish, and ship.

    Therefore, my recommendation for developers who want to use UE4 but prefer C# over C++ is to bite the bullet and give C++ a thorough chance. All of us at Epic clearly see the many ways that programming in C# is more enjoyable than C++, from header-free source code to generics to rediced boilerplate code. However, C++ is a language that scales upward without limit, and the experience of whole-program debugging (engine and game together) is incredibly illuminating, as are the power and visibility that come from having the full C++ source and ability to call into any part of it.

    Comment


      #17
      Hi,

      Thanks for the clarification Tim.

      For these reasons, we updated the UE4 EULA to require redistributed programming language integrations to be free and open source,
      Which kind of halted my endeavors to make UE4 compatible with the Embacadero RAD studio so I could enhance the engine as a Delphi programmer, so my 15+ years of coding expierience wouldnt be down the drain...(RAD Studio allows cross coding).
      Side question to that: Would it be Ok to use the Rad Studio C++ Builder together with UE4? (I really really dont like Visual Studio...)

      Im thinking however to make a little framework for custom dlls. If they use the FreePascal compiler (which can also compile ObjectPascal code), that would be ok since its free, right?

      Cheers,
      Klaus

      Comment


        #18
        Thanks Tim, for that clarification.

        Few comments though...

        Originally posted by Tim Sweeney View Post
        Finally, when an engine is written in C++ and gameplay is scripted in another language, the interoperability barrier between languages eventually grows overwhelming. This is why we ultimately abandoned the UE1-3 era's UnrealScript language and moved to a pure C++ programming model. This gives UE4 the ironic property of making it harder to learn the engine and start writing a game, yet ultimately easier to grow, finish, and ship.
        What about Blueprints ? You are not very constant in you argumentation since one can develop its own game-play via another programming paradigm than C++...

        Originally posted by Tim Sweeney View Post
        Specifically, we put substantial work into documentation, samples, pre-release testing, compatibility, porting, and support on C++ and Blueprints that we can't feasibly replicate for a third-party plug-in. For example, unless the documentation on UE4 programming were updated to include side-by-side examples of C++ and C#, the programming experience with C# in UE4 could feel disjointed, and this downside may outweigh the upside of one's familiarity with C# and its easier header-free programming model.
        I shall also remind that all "Mono for Unreal" does is exposing to a C# environment the blueprint-exposed functions that are already defined in the C++ environment, and therefore maintaining the C# API would rather be trivial.

        tl;dr -> Blueprints-exposed code in the C++ will automatically be made available in C# via the tool.

        Originally posted by Tim Sweeney View Post
        The challenge with this and other programming language integrations into Unreal Engine 4 is that, unless they were to be genuinely and thoroughly adopted by Epic, they would not quite be first-class citizens in the way that C++ and Blueprints are.
        Do you think that if Mono was completely open-source and free to use for any body then Epic would have done it's move towards Xamarin ?
        Last edited by matmuze; 12-18-2014, 08:23 AM.

        Comment


          #19
          Originally posted by matmuze View Post
          tl;dr -> Blueprints-exposed code in the C++ will automatically be made available in C# via the tool.
          We actually love scripting languages, and we want developers to be able to use the right tool for the job. We designed the scripting layer in Unreal Engine to be totally extensible through a pluggable API that uses the same surface area as our own Blueprint language. So you guys are free to use whichever language you want or create your own!

          As Tim said, we do require that language extensions to the engine to be totally free and open source. We believe this is in best interest of the Unreal Engine community. Just as an example, if a huge number of developers suddenly adopted using Google's GoLang for their projects, we would want to be able to make Go a built-in feature and support it at the same quality level as Blueprints (sample games, documentation, templates, video tutorials) and ensure developers could release projects on all platforms without restriction.

          We're really still focused on making the C++ experience awesome for developers. We have dozens of improvements coming, including faster compile times, fast code outdatedness checking, simplified Unreal Object syntax, and better API documentation. Of course many of these improvements will benefit scripting languages as well, and with every release we expose more engine features to scripting APIs.


          Originally posted by matmuze View Post
          Do you think that if Mono was completely open-source and free to use for any body then Epic would have done it's move towards Xamarin ?
          We do certainly keep an eye on .NET and other languages. We talk to Microsoft frequently and we're pleased they're opening up the core .NET code. For the foreseeable future we have our hands full with improvements to Blueprints and C++. We have a great trajectory with these languages and some extremely cool ideas yet to implement that we're very excited about.

          Please keep the feedback coming, we are always listening and trying to do the right thing for the engine and developers.


          --Mike

          Comment


            #20
            I think you need to use Mono http://mono-ue.github.io/ and give it a chance if that's what you want. put your efforts there or are they not answering your concerns like UE has?

            Epic has kept this Feedback Forum open and even though I don't agree with what you suggest (at this time), I agree that you should be able to voice your opinion, as should they be able to voice theirs. And they are a lot nicer than I would be.
            (maybe one day I'll look back at C# & even Mono but not today because I've seen what they both can do)

            Whether I agree with Epic, whether I like what they are doing all the time, whether I'm able to make something out of Unreal Engine or not, whether I stay or go, I still believe in Epic & Unreal Engine and what they are trying to do here. They listen and try to go forward with the community & their users in mind. And I will always uphold their right to do so, because it's something I believe in, as do many if not all of this community.

            If it seems I took offense, maybe I did, and I'll take this moment to apologize for it if I offended you or anyone. But it's because they do answer these concerns when they can or when they have an answer that is correct for the situation or the timing is right. This you should respect, as I suggested above you should take the time, if you can, to join the Twitch streams, voice your concerns etc. and there is also an Off-Topic forum thread that I'm sure you can continue your topic with. (if you can't make the Twitch you can ask the question in the Twitch Announcement topic)(look for someone that has something to do with your topic in the stream is best though)(never hurts to ask)

            So again, if I offended anyone in any way, my apologies. And Epic/UE4 you make me proud to be a part of this community! I still don't want C# tho', not today anyway!

            Comment


              #21
              Originally posted by ayretek View Post
              I think you need to use Mono http://mono-ue.github.io/ and give it a chance if that's what you want. put your efforts there or are they not answering your concerns like UE has?
              I've tried Mono for Unreal already, but the tool is simply not mature enough yet because they lack the man-power to develop it, therefore I think it is up to Epic to take responsibility because the potential is simply enormous, for both Epic and Xamarin -- just think one minute how popular it would be if every Unity user suddenly started to use Unreal Engine instead.

              Epic wants to allow level-designer and artists to script the game play via Blueprint, and that is the proof they want to open game development to a larger group of potential users, in that case it would also make sense to open it to lamba-developers, don't you think ?

              Originally posted by ayretek View Post
              So again, if I offended anyone in any way, my apologies. And Epic/UE4 you make me proud to be a part of this community! I still don't want C# tho', not today anyway!
              You don't want C#, fine, some people do not want Blueprints either and yet there no one is making a drama about it.
              Last edited by matmuze; 12-18-2014, 12:21 PM.

              Comment


                #22
                The C++ in Unreal is not C++, I mean it is, but it isn't. The layer of Unreal over the C++ makes it almost a different language entirely. Switching to C# isn't going to make programming easier on Unreal, because the 'Uneral Layer' will still be overtop the C#. If people want to spend their time making a wrapper, fine, but quit bothering Epic with these request. Their time is better spent doing QA on the features we need and have, rather than catering to a crowd who refuses to learn a industry standard language.

                Comment


                  #23
                  The C++ in Unreal is not C++, I mean it is, but it isn't. The layer of Unreal over the C++ makes it almost a different language entirely
                  And I wish there would be something like a primer or a fundamental documentation on UE4.
                  A little tour of the code that really starts with the most priimitive classes that are derived directly from native C++ classes.
                  Having a little tree that illustrated the class hierachy would be most helpfull

                  Comment


                    #24
                    Originally posted by The Britain View Post
                    The C++ in Unreal is not C++, I mean it is, but it isn't. The layer of Unreal over the C++ makes it almost a different language entirely. Switching to C# isn't going to make programming easier on Unreal, because the 'Uneral Layer' will still be overtop the C#. If people want to spend their time making a wrapper, fine, but quit bothering Epic with these request. Their time is better spent doing QA on the features we need and have, rather than catering to a crowd who refuses to learn a industry standard language.
                    The fact that C++ is a"industry standard language" and other languages are not is a very subjective remark, not every body would agree with that.

                    C++ in Unreal makes me think a bit about Qt, and I am glad to see that they made efforts to improve usability of C++ coding, however it would never reach the ease of use of C# and all the nice syntactic sugar, ever, there is not point arguing about that.
                    Last edited by matmuze; 12-19-2014, 05:52 AM.

                    Comment


                      #25
                      Thanks Mike I'm really pleased to hear from you guys, and to hear that you are also listening to want users want.

                      Here a few comments to what you said...

                      Originally posted by Mike Fricker View Post
                      We actually love scripting languages, and we want developers to be able to use the right tool for the job. We designed the scripting layer in Unreal Engine to be totally extensible through a pluggable API that uses the same surface area as our own Blueprint language. So you guys are free to use whichever language you want or create your own!
                      Fair enough to defend Epic's position by saying "if you want it just do it"...

                      However I find this argument a bit too easy IMHO, then why would Epic keep on implementing new features if users or 3rd party could develop it instead...

                      Open-sourcing is great but you guys should not rely on this too much for such important features and between you and me, we both know that if it's not officially supported by Epic, scripting solutions are quite unlikely to reach a very mature state, and users will never use it.

                      Originally posted by Mike Fricker View Post
                      As Tim said, we do require that language extensions to the engine to be totally free and open source. We believe this is in best interest of the Unreal Engine community. Just as an example, if a huge number of developers suddenly adopted using Google's GoLang for their projects, we would want to be able to make Go a built-in feature and support it at the same quality level as Blueprints (sample games, documentation, templates, video tutorials) and ensure developers could release projects on all platforms without restriction.
                      Well that's a step forward...I'm glad to hear that you are open to scripting in UE4. I agree that C# should not be prioritized over more wanted scripting languages.

                      What about creating a community-based poll in order to decide which language should be supported in the future ?
                      And the most favorite language would then get Epic's attention for a built-in support (A real one, not like the LUA plugin...).

                      Originally posted by Mike Fricker View Post
                      We do certainly keep an eye on .NET and other languages. We talk to Microsoft frequently and we're pleased they're opening up the core .NET code.
                      Well that's interesting news...tell us more


                      --Mike[/QUOTE]

                      Comment


                        #26
                        Originally posted by matmuze View Post
                        Thanks Tim, for that clarification.
                        What about Blueprints ? You are not very constant in you argumentation since one can develop its own game-play via another programming paradigm than C++...
                        I can answet that, qith question. Did you saw game made by Epic which is done fully in blueprint, except Tappy Chicken ?
                        While blueprints are awesome, nice, and it's best thing since sliced bread(no arguments!), I don't think most people even consider making serious game fully in them.

                        As an end point they are great (connect few nodes, like 4-6 and buf! you have new gameplay element, which just call to pre setup C++ interface) or as for prototyping, I can hardly imagine someone making fully big game with them.

                        Just because there is hammer around laying, doesn't mean you should use it to kill flies.

                        The same IMO is going for other non C++ languages. With even less benefits. Blueprints are fairly easy to understand by virtually anyone. While written languages, are not. For me it doesn't make any difference. But people who never wrote line of code, doesn't care if it C++, C#, Go, Visual Basic. It's the same arcane magic beyond understanding at first glance.



                        Aside from that. There is no real reason to implement anything else. Hardness of C++ (especially in wrapped version in UE4) is mainly based around prejudices, not any facts. Look, there are people around forums, who are artists, and yet know how to code in C++ .

                        However I find this argument a bit too easy IMHO, then why would Epic keep on implementing new features if users or 3rd party could develop it instead...
                        They add features, that most people want(and what they need). As you can easily judge, people around don't want scripting integration from Epic. More over most people seems to be clearly opposed to such thing.
                        Because it would take resources, which could be used to add new features, that are actually needed, or improving existing ones.
                        Last edited by iniside; 12-20-2014, 04:24 AM.
                        https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                        Comment


                          #27
                          C++ API in UE4 is great and I like it very much, but there are some features just impossible without some form of scripting on mobile platform, like hot-code-updating without going through AppStore. Nearly every online game in China is using this technique to facilitate super fast iteration (commonly 1 to several updates everyday, which is impossible with the slow review process of AppStore), so having this feature is crucial to be competitive on this market. For now the market is dominated by Unity, I'd be very happy to see UE4 to take over.

                          Blueprint is great in small scale scripting and prototyping, but I don't see the benefits in real production of complex games, the graphs in TappyChicken are way too CRAZY and FRIGHTENING for such a simple game!

                          Comment


                            #28
                            But people who never wrote line of code, doesn't care if it C++, C#, Go, Visual Basic. It's the same arcane magic beyond understanding at first glance.
                            Well, I have quite a background as a Delphi programmer and still C++ is somewhat "weird" to me.
                            Take for example the string handling. Im used to have a string as a basic data type. Now I started reading through the C++ primer, but still cant figure out how to concatenate strings mixed with integers (and storing it in a string variable. im not talking about cout << "text" << x << "more text"; here)...
                            So C++ is perhaps not the most intuitive language.
                            One reason why so many people like C# is the fact that it borrowed some nice stuff from Pascal, syntax-wise and also conceptionally.
                            Today I wouldnt use the original Turbo Pascal anymore either, but Object Pascal is equally strong as C++.
                            So introducing C# would offer a compromise between the two worlds.

                            C++ API in UE4 is great and I like it very much
                            Can you then recommend good reading material that explains the specific parts that Unreal introduces to C++?

                            Comment


                              #29
                              Originally posted by matmuze View Post
                              Come on guys, again, this is not the right thread for a debate C++ vs C#.
                              I disagree. You want them to spend time integrating C# which takes time away from relevant development, there would have to be a good reason why they should put their time into letting you use C# over C++. I don't think there's a good reason.

                              FYI in your original post you are already debating this.

                              Comment


                                #30
                                As a programmer you need to adapt and learning C++ in EU4 will benefit you in the end.

                                Comment

                                Working...
                                X