An Unreal Decision

Disclaimer: I work for Unity. -As for 64 bit support, the biggest problem for that with Unity is all the dependencies to third party technologies we integrate. We've managed to get all those resolved for the Runtime part (Mac/Windows/Linux standalone players) a while ago (we've been adding 64 bit versions of those during the 3.x and 4.x release cycles), which meant getting Mono, PhysX, FMOD, Substance, etc all working on 64 bit. For the editor, however, there are a lot more third party libraries involved (such as a web browser engine for the asset store), not all of which had 64 bit versions to start with. So there were a lot of dependencies to resolve, which is why this took time. Good news is, we have all this working in 5.0, which will be out later this year.

-For the new GUI, we are not going to fix this only in Unity 5, but already in Unity 4.6, which should be out really soon.

-About the "JavaScript" misnomer, I agree that that was a bad decision in retrospect, though it is not trivial to change at this point.

These are my gripes with Unity, in question format :) Would love to hear from anyone that has concrete answers for these:

- How does UDK build apps for iOS natively on Windows without requiring a Mac? Are they doing some kind of insider thing that Unity can't replicate?

- I see Unity as massively extensible and that's one thing I like about it. Comparisons are often made between vanilla Unity and UDK; what about Unity + PlayMaker + UFrame + Level Builder, etc. I don't see this ease of editor extensibility with UE4 (I'm sure it's there; but the Unity Asset Store just lets me cherry-pick one, click buy and then just have it to use immediately after download - I like that).

- My biggest gripe with the editor is the font size. Will the new UI that's coming in 4.6 and/or 5.0 allow me to increase the font size used by the Unity editor to actually make it comfortably usable rather than fatiguing?

FWIW I've preordered Unity 5 and I use UE4 at the moment as well. Nothing big completed in either engine (just some side work here and there) but no fanboy-ism for any particular one (though a bit of a fondness for Unity as I encountered it back in the old Mac days when Unity were called Over The Edge Entertainment; GooBall was pretty cool by the way).

Ok, my apologies. I genuinely thought you were trying to make some kind of point. Haskell has a REPL, Scala has a REPL, OCaml has a REPL, F# has a REPL; it's not at all unusual for a statically typed language to have a REPL.

(If I had to guess why Java doesn't have one I'd assume its emphasis on OO and everything-is-a-class; expressions in a REPL are almost inherently not contained in a class. For C/C++ I'd guess the emphasis on manual memory management and programmer-visible memory layout don't play nicely with a REPL. And for go I'd guess because it doesn't like including features that weren't in Algol '58. I don't think that's the real reason, but I am literally incapable of understanding what people like about go. Those are just guesses though)

> It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? You can invent the future today. There's no reason to put up with the current limitations.

To me the browser just seems like an extra layer of junk, particularly when you're talking about things like WebGL where the API talks more-or-less directly to the graphics card. So I certainly hope the future looks more like steam - a library interface where I can run any program I want, automatically updated, with my saved data automatically kept in sync. Once you have a system that looks like that, what's the advantage of the browser? Put another way, if we're writing a game runtime, why would we include a document layout engine, an extremely complex styling system, and all the other stuff a browser comes with? I certainly hope the future looks more like Steam than like the browser.

I agree that developers shouldn't have to worry about cross-platform. I think it's a damning indictment of our industry that the best way to get a cross-platform runtime environment for your program is to bodge it into a scripting language that was written in three days to bolt on to a remote document viewer. I'm hoping that things like MonoTouch mean we're getting closer to a cross-platform runtime that provides a better platform for general-purpose applications and games.

"Boring" is what platforms should be; stable, reliable, almost invisible unless you're looking at them. I agree that there are better things than C++, and I do what I can to contribute to them. But I really hope the browser isn't the best we can do.

> This just seems like a button toggle problem

Sometimes it is, sometimes it isn't. The problem is knowing when it is or isn't. That needs building with all warnings enabled and vetting through them manually, a run with a static analysis tool searching for possible 64 bit bugs, or at worst, running extensive test suites to try to detect errors at runtime.

Some (older) software might also have some internal structures that are designed on the assumption that pointer size equals 32 bits.

This issue is made worse by the loose conventions in implicit integer type casts in C and C++. Warnings do help here, but there's going to be a huge amount of spurious warnings too.

So, at best, all you need to do is change compiler flags. At worst, you'll need a lot of manual labor in making sure that your applications build cleanly for 64 bit machines.

I don't know how UDK does iOS but I'd like to mention that was also a big draw to adobe air for me - you can develop/compile/deploy to ios from windows (don't know how it does it either but apparently it's possible).