Unity3D/2D

General Discussions
#21

“Unity” the engine is excellent and does so many things out-of-the-box there is very little else to compete with it. What it doesn’t do out-of-the box there’s quite often an addon available for it in the infamous Asset Store. It has an incredibly vibrant community of modders and addon producers and asset crafters which put almost any other community around game development to shame.

It targets more platforms than pretty much any other integrated tool. As for phones as a platform… the big names are generally covered and fine. Incompatibility problems are largely down to the phones themselves just being a bit shit and you have the same problem in any other environment. Broadly speaking Unity has had more testing than any other environment out there - you simply won’t get better. Patches and fixes are frequent.

The “asset pipeline” is excellent. Chaz can diddle around in Max making 3D animations and see it running in Unity on-screen in-game a matter of minutes. I don’t know how well the 2D stuff - especially the GUI stuff - stacks up since 5.x as we’re still on 4.6. I imagine it might be on a par with my own GUI stuff, but that’s really very nifty so probably not 8)

Java would have been in this position if, years ago as we’d tried repeatedly to make happen, Sun had made a few decisions to allow it, but they didn’t. So it’s all on top of Mono now, in C#, and that’s a little sad in some ways. There’s still reasonable scope for someone to compete with Unity using a Java-based platform - and it would actually have a reasonable chance of success as the Java platform is a whole lot faster than the Mono platform which enables a whole superset of games and technology that require that kind of performance (and of course not to mention the huge variety of libraries available for Java gives it a great kickstart). Something based on Eclipse would be massively useful: 90% of the problems with Unity are down to the crappy bugridden IDEs (both Unity development environment, and the shockingly primitive MonoDevelop). libgdx and RoboVM are interesting places to look at to solve the cross-platform stuff, though really the elephant in the room is XBone/PS4. No Java on those two, so … no go.

Seriously… anything would be better than the Unity/MonoDevelop unholy combo. Visual Studio is barely better than MonoDevelop for Unity work, too, before anyone pipes up.

Cas :slight_smile:

#22

My opinion:

Unity is VERY great if you want to actually make and finish the game in reasonable amount of time - it have all kinds of features you need to achieve this goal and - even if something is missing - you can easily grab that from asset store or make on your own. Probably the biggest problem for lots of people is that you must stick to Unity API if you actually want to have something done, and that it makes writing clean code really hard (forget about good scope control unless you want to use some dirty tricks, stuff like MVC and many other useful patterns - while possible - are mostly impractical here). It also lacks good IDE, MonoDevelop or Visual Studio are not even close to NetBeans or Eclipse and tend to be much slower. Also, are you Linux user? Well… Then available toolset is even smaller - while Unity itself works on Linux natively, forget about Visual Studio.

On the other hand, Java is excellent if you want to have code-heavy stuff finished in reasonable amount of time, so - while writing game in it will in most cases take much more time than in Unity - it is very good for writing tools, especially GUI-heavy tools. Unity don’t have good out of box GUI support with advanced components, while Java have two very good GUI libraries with lots of available free libraries for them: Swing and JavaFX. Like I mentioned in Unity section, Java IDE’s tend to be better than their C# equivalents, you are not limited with pretty strict Unity pipeline as well.

#23

Layers of Fear is also Unity. Good game but runs dog slow, 15 fps on my machine :<

#24

Yeeeah, I can see that.

Thats surprising actually, good to know.

If I could use Eclipse with Unity I would give it a chance.
But then again if someone asks me, you gotta learn a new engine Unity or Unreal Engine, which is also free, which one do you choose? I don’t really see any point of choosing Unity.

#25

I tried using Eclipse with Unity and it was then that I discovered that Eclipse, staggeringly, has no support for C# at all. There’s an ancient half-assed syntax colourer for the editor for C# code, and that’s it. Which is just bloody ridiculous. I expect it’s just snobby them-and-us mentality between C# and Java camps that has prevented any serious effort getting C# working under Eclipse.

Cas :slight_smile:

#26

We use SharpDevelop at work to support our C# clients… don’t know if it works with Unity…

#27

The object pooling in unity gives me cancer :x

#28

Why is this a thread? The topic is toxic bullshit and you should be ashamed Hydroque.

#29

If its not java, someone else has to write the thing that does all the highlighting and stuff. The Eclipse team itself doesn’t do it. Since C# has good tools outside eclipse i suspect nobody has bothered.

The Scala one is fairly decent. C++ one i used a while back was also good. Hell even the latex one is good. But none of these are done by the Eclipse team.

#30

It is good, but only when you are not participating in it

#31

Firewatch is made with Unity, PC version gets 82% on Metacritic.
Developer was “working with Unity” to improve performance on PS4 and has released a patch which does that.

#32

I’m in a love/hate relationship at the moment with C#

I’ve started to get used to the get; set; operators and use it more frequently in my code style.
I also love how you can overload the [] and other operators.

But honestly… that’s about it.

In all my years of programming, I’ve come to witness some the worst written code in C#. Thankfully all of it is from outside our company so its often a one-time affair. Still gives me nightmares.
Despite being in C# land for the past few years, I still find myself doing rapid prototyping/projects in Java.

#33

Has anyone tried Project Rider? It’s basically ReSharper in IntelliJ, I don’t know how anything else could compete with that.

#34

You and one other person are the only toxic people here. Good bye.

What is it?

#35

No squabbling please! Despite trollbait there’s value to be juiced from this thread.

Project Rider looks very interesting, mostly because IntelliJ is so good.

Cas :slight_smile:

#36

I don’t think Unity is for beginners and only for people who are very good at modeling and texturing (or rich…).

Reasons

  • Asset Store
  • Models cost money
  • Textures cost money
  • Modeling and Texturing is art

I wonder how texturing and modeling go hand and hand if you have a Java Engine versus their engine, meaning the time it takes to organize and tackle these projects. While you control model loading and texturing dynamically in Java Engines, Unity is very deterministic in what you use and how you can use them - for that all around support. But that is weighing portability versus extendability which is one of those no answer arguments of which is better.

If you integerated Unity with Blender then GG.

#37

Unity was developed to target all audiences – yes, that includes complete novices as well. Unity is for 3D development, but it is often used for 2D development as well.

Another thing I want to mention is that (I think NegativeZero mentioned this earlier) engines, libraries, APIs and even programming languages…they’re supposed to be treated as tools. Unity isn’t shit, Unity simply doesn’t suit your needs and isn’t the right tool for you. Game engines are also designed for different types of games. Creating an extremely simple 2D game in Unreal Engine would be like trying to cut bread with an electric power saw – it works, but it makes no sense. Simultaneously, trying to create GTA V in JavaFX’s 3D API would be like using a scalpel to try and cut down a tree. It makes no sense either. You seem to be under the delusion that certain programming languages are better than others, or that certain engines are better than others. This isn’t true – it is simply that every programming language is a tool suited for different tasks, and every API is also a tool suited for different purposes. It is a programmer’s fatal flaw to think that one tool is better than the other. They’re suited for different needs, so it’s not about which is better; instead, it’s about which is appropriate.

#38

OpenGL development does not at all involve communicating “directly” with the graphics card. It is a low-level graphics library, but however low-level it is, it is completely different from communicating with the graphics card directly. You can go for an even more low-level API like Vulkan, or if you fancy Windows, you could make do with DX12. Or if you feel like making AMD a little happier, you could go for Mantle development (Vulkan is largely based on Mantle, so you might as well learn Vulkan).

Still, I respect the fact that you’re trying to find out more about what’s happening behind the scenes in commercial game engines. But there’s a lot more than meets the eye, even when you’re working with OpenGL. Continue trying to find out more, there’s nothing wrong with that :stuck_out_tongue:

#39

I never said it did. Anyways, my point still stands that I like working close with things.

Here is my outlook on Java:
Thousands of libraries strung together by user’s thousands of libraries which functions get isolated into smaller and smaller calls to functions until you come to the main which executes this monstrosity.
It’s why I rather code lower ._. I trust OpenGL, as it’s only extended to the point of being usable and with the latest schemes.

#40

[quote]Thousands of libraries strung together by user’s thousands of libraries which functions get isolated into smaller and smaller calls to functions until you come to the main which executes this monstrosity.
[/quote]
You just perfectly outlined the best strategy to implement abstraction in an application, and that sentence could just as well have come from a text book on software design. :), though probably phrased a bit differently.
This is exactly the only way to structure a complex application and implement said application in a finite amount of time.
There is always a single highest-level main(), which always delegates to high-level functions, which then delegate to low-level functions (with arbitrary middle-level abstraction layers in between). This is the typical call tree found in EVERY software system, no matter what paradigm or language is being used. And those functions are typically packaged into libraries to ease deployment.
And it is a good thing, because otherwise you would not live long enough to finish any useful application.