[Mono-ue] A call to establish a C# / Mono development and build environment for the plugin

Fri Mar 20 01:37:33 UTC 2015

Thanks Robert - much appreciated.  We're aware of the C# limitations (eg
pausing during GC as a simple example).  Many of these have been addressed
by updates in .NET.  -  eg
https://msdn.microsoft.com/library/ee787088(v=vs.110).aspx#background_server_garbage_collection

It's a form of game, but not in 3D at the moment.  We have an urgent need
to test out some concepts in a 3D engine, and Unreal was our preferred
choice.

While at some point we can re-commit to Unreal and what appears to be
between 1-2 weeks of toolchain development, and thence to maintain it
ourselves, the reality is that Unity and Unreal are similar engines
feature-wise, though Unreal appears to focus more on high-quality 3D games,
whereas Unity is a mix of 2D (ish) and 3D mobile games.   In other words:
the engines are similar, though one has a larger asset library and solid C#
support.

FWIW - our developer on this indicated that it was probably no more than a
day or two away from a finalised build, however we're hoping for a "zero
time" install of Unity + C#.  For us, at this stage - that's very
compelling.

Much appreciated for the build details btw.  We'll store these for when we
get back to Unreal.

Many thanks for your help - we do appreciate it!

Cheers - David

On 20 March 2015 at 11:52, Robert Potter <robertbrucepotter at gmail.com>
wrote:

> Disclaimer: I speak for neither Epic nor Xamarin, but the info here is all
> readily available if you look.
>
> Epic is not really involved in this. This is a Xamarin operation and an
> as-yet exploratory one. If your production needs hinge on there being C#
> support, I think you will need to look elsewhere for the time being.
>
> That said, there are a few things you might consider:
> 1) Your desire for binary releases for every is understandable, but for
> larger teams/organizations it is immensely helpful to have the tools build
> as just part of your normal process. Especially when it comes time to prep
> to go live, you want the ability to lock down a version but still take bug
> fixes from downstream (not to mention any changes you may want to make to
> better support your usage). If building the tools and distributing them to
> your team (via source control like Perforce or a local CDN... don't use
> DVCS like git or hg for large binary content) is just part of your normal
> process, then it won't be a potentially crippling distraction in the
> critical time of your project.
> 2) There are things C# does not do well, especially in realtime
> applications (though I don't think you've specified, this doesn't sound
> like a "game" project, but this still applies in general for RTA). C/C++ is
> difficult to avoid at a certain level, since some of the hoops you have to
> go through to get the same behavior in C# (say, fixed structured arrays);
> not to mention, the runtime optimizers are still less than ideal
> (especially the Mono-Unity version. Holy hell, it's terrible). It's hard to
> say whether it would come to that since I don't really know your project,
> but I quite often find a moment where I really want to be explicit about
> what the computer should do and C# is not the language for that (arguably,
> neither is C++).
> I still like C#, and I am watching this project closely, but I don't think
> you are going to get what you want here.
>
> -Robert
>
> PS: not sure what build issues you are having, but I found the process
> pretty straight forward if you follow the directions. A few things though:
> 1) Make sure you have all of the prereqs (don't skip things like the DX
> Runtime version it specfies... it can give you seemingly unrelated build
> errors) installed and ready.
> 2) Build the vanilla version of UE4 first just to ensure that is correct.
> It's a mostly turn key process, so other than build time (do it in the
> background), it's not much of a hassle.
> 3) Start with 4.4, since that's the version that it is targeting while the
> plugin stabilizes. You can get it working with the later versions, but I
> would hold off on that until you get it working with 4.4 (easier to get
> support).
>
>
> On Thu, Mar 19, 2015 at 4:48 PM, David Ford <davidfordaus at gmail.com>
> wrote:
>
>> As mentioned - we have tens of thousands of lines of C#, and a small
>> number of lines in JavaScript.  In short:
>>
>>
>>    - We have developers that need to know one language - C#
>>    - The rest of our product is in a single language
>>    - C++ itself is notoriously painful (though I know it reasonably well
>>    myself - I find it far easier to code in C# with Linq, reflection,
>>    automatic GC, etc etc)
>>
>> In short: rather than either re-skill a developer to C++, or fragment the
>> team, or outsource the work, or any one of a myriad issues surrounding
>> supporting C++ - we're using C# unless a compelling case can be made to
>> support multiple languages.  As it is we're using C# with a number of
>> additional frameworks (eg Postsharp, etc) - so it's a non-trivial C#
>> environment in any case.
>>
>> This should be just a plugin - built by Xamarin or Unreal / Epic.  This
>> would install in seconds. Ryan Burnham's comment seems to indicate the
>> issues he's found using the existing practice of "compile your own".
>>
>> In addition to the rebuild problem - the statements around the fact that
>> the plugin isn't "production ready" after many months of apparently zero
>> development does not fill me with any sense that it's a viable option
>> long-term, and could be killed at any point.
>>
>> Epic / Unreal - if you're listening : I will be blogging about our
>> experiences with the C# environment.   My most honest and best advice is
>> this:
>>
>>
>>    - Finish it - not all features need to be supported, but core ones do
>>    need to be
>>    - Include C# / Mono as part of your software build process - which
>>    will make it part of your normal dev cycle, and will disappear as a problem
>>    - Distribute it with the product out of the box
>>    - Trumpet it across the C# development threads
>>
>> Right now it's a failed feature launch.  It indicates that it's easy to
>> use - but the reality is far from this, and is largely full of frustration.
>>
>>
>>
>>
>> On 20 March 2015 at 10:23, Eugene Tchoukhrov <ujen at vicogamestudio.com>
>> wrote:
>>
>>> Hi David,
>>>
>>>
>>>
>>> I’m not with Xamarin nor Epic.
>>>
>>>
>>>
>>> Just for my curiosity, what are the reasons you and your team are tied
>>> to C#? I moved our team over to UE4 and C++ a couple years ago and we have
>>> not looked back. It has been a great experience working with C++ and UE4.
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Eugene
>>>
>>>
>>>
>>> PS, you don’t have to respond, but I’m simply curious.
>>>
>>>
>>>
>>> *From:* mono-ue-bounces at lists.ximian.com [mailto:
>>> mono-ue-bounces at lists.ximian.com] *On Behalf Of *David Ford
>>> *Sent:* Thursday, March 19, 2015 2:58 PM
>>> *To:* Ali Scissons
>>> *Cc:* mono-ue at lists.ximian.com
>>> *Subject:* Re: [Mono-ue] A call to establish a C# / Mono development
>>> and build environment for the plugin
>>>
>>>
>>>
>>> I think my request still stands.  There is very little (if any) benefit
>>> to having each individual developer compiling on their own.  Few (if any)
>>> Unreal downloadable examples appear to use 4.4.
>>>
>>>
>>>
>>> I am re-tasking our developers to Unity as of this morning, and halting
>>> Unreal development entirely.   We may return to Unreal at some point, but
>>> will review the decision to support two engines in detail before committing
>>> to that effort.
>>>
>>>
>>>
>>> If there are someone within Xamarin / Unreal that this email can be
>>> forwarded to - I'd appreciate it.  We're expending effort developing
>>> products, not wasting time recompiling (with compilation errors, as it
>>> turns out) non-production grade toolchains.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> On 20 March 2015 at 03:24, Ali Scissons <ali.scissons at gmail.com> wrote:
>>>
>>> The plugin isn't complete and not ready for production use, not to
>>> mention the plugin requires changes with UE4 itself (thus the patches).
>>> However, not everyone is required to build UE4/plugin from scratch. Once it
>>> is built, you should be able to redistribute it to your other developers
>>> and only have them setup with C# related tools like Xamarin Studio and it's
>>> plugin.
>>>
>>>
>>> Ali Scissons
>>>
>>>
>>>
>>> On Thu, Mar 19, 2015 at 7:34 AM, David Ford <davidfordaus at gmail.com>
>>> wrote:
>>>
>>> I'm somewhat confused as to why each developer wishing to use C# "must"
>>> recompile from source.  As far as I can see there's nothing compelling
>>> within the Mono code that requires that each developer should rebuild for
>>> their own specific machine or environment.
>>>
>>>
>>>
>>> Can I suggest that the better (best) approach be that a virtualised
>>> build environment be established within Xamarin or Unreal / Epic, and that
>>> a single developer be tasked with updating the Mono plugin on each release
>>> of the game engine (presumably the API's don't change between patches to
>>> point releases - eg 4.7 + patch will be compatible with the plugin if 4.7
>>> raw is compatible.  This developer wouldn't be full time, but may perhaps
>>> spend a day each month (or less, assuming straightforward compatibility
>>> between releases).
>>>
>>>
>>>
>>> At this stage there is potentially a vast amount of wasted effort having
>>> every C# developer establishing a full Mono build environment and toolchain
>>> for C#, when in fact most developers (including myself) simply want to
>>> download the Mono plugin and add it to the UDK, then add our own C#
>>> assemblies.
>>>
>>>
>>>
>>> We currently have one developer spending several days simply getting a
>>> Mono C# plugin environment to run, when in reality a pre-built Mono plugin
>>> would have removed all of that needless effort, and reduced the time to
>>> hours at most.
>>>
>>>
>>>
>>> We would prefer to use Unreal rather than Unity, however at this stage I
>>> may pull our Unreal development completely and switch our (early phase)
>>> project to the Unity platform based solely on the lack of a simplified
>>> development toolchain with C# / Mono.
>>>
>>>
>>>
>>> Note that all the other code for our project (20 + C## projects, tens of
>>> thousands of lines of code) are C#, and I see no reason to add a small
>>> amount of C++ purely to support Unreal, and based solely on the fact that
>>> recompiling the Mono C# plugin for each UDK release is non-core effort.
>>>
>>>
>>>
>>> Best regards
>>>
>>> David Ford
>>> 0421 659 552
>>>
>>>
>>>
>>> _______________________________________________
>>> Mono-ue mailing list
>>> Mono-ue at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-ue
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best regards
>>>
>>> David Ford
>>> 0421 659 552
>>>
>>
>>
>>
>> --
>> Best regards
>>
>> David Ford
>> 0421 659 552
>>
>>
>> _______________________________________________
>> Mono-ue mailing list
>> Mono-ue at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-ue
>>
>>
>

-- 
Best regards

David Ford
0421 659 552
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-ue/attachments/20150320/536e2fe1/attachment-0001.html>