next »

[starsrift]

I've been more tempted to switch to Unity, lately. Mostly because that way I don't have to worry about so many compatibility and tech issues. I was wondering if some people who have released games on both could share some experiences about using unity compared to their own engine and how performing tech support was. Easier? (I'd assume) Harder? About the same? Advantages, disadvantages?

[SirJson]

The thing is if you code your own engine you have full control over the source and can often fix most of the tech related bugs right away. When using Unity you can only hope that you can find a workaround or that the bug is fixed in the next few patches.

[Netsu]

The thing is if you code your own engine you have full control over the source and can often fix most of the tech related bugs right away. When using Unity you can only hope that you can find a workaround or that the bug is fixed in the next few patches.

Not my experience at all. When the engine is mine then it's up to me to find a fix to every single little thing that breakes the game on a myriad different platforms and hardwares.

I spent a year writing my engine, then another year writing a game on it and only ever managed to make it run flawlessly on a few select systems. There were strange graphics card bugs that I was never able to solve, a lot of compatibility issues with all the different libraries I used etc.

With Unity I just click build and it builds, no cross-compiling pains to cover all the systems, no days spent searching for the right build of a library that will work with my compiler and target system. Granted, my problems might have stemmed from the fact that I used C++/OpenGL/OpenAL instead of some integrated environment, but still, this is my experience.

Still glad I made my own engine, but I will never try that again.

[motorherp]

Some quick thoughts based on my experience of things you should consider before committing to using Unity over your own engine:



Unity doesn't mix all that well with large dev teams due to issues with source control and asset/scene management.  If you have a dev team larger than a handful of people this is something you should investigate further.

If your project will require any special or out of the ordinary tech you should definitely prototype those systems first.  Given that Unity is a black-box which expects a certain work-flow there are some things that will require a much larger amount of effort to do than you might anticipate or that you just simply aren't going to be able to do at all.  Make sure your project wont run into a dead-end before you invest too much into it.  (NB: physics gets a special mention here since the Unity wrapper around PhysX is very limited and inflexible)

Be prepared for a very hard time getting help/support for anything but the most simple of issues through the free channels.  Unfortunately the forums and answers hub are massively overrun with beginners and hobbyists who aren't able to help with advanced issues and who's relentless onslaught of basic issues will quickly bury your threads.  It used to be the case that premium support was very cost ineffective for small teams / indies but it looks like Unity now offers a smaller scale premium support package although I don't know what the price is like or how good it is.

Once you've got your head around how Unity works it'll be a huge huge boost to productivity in the early stages of development compared to writing your own engine.  As development progresses productivity will start to drop a bit since it becomes more effort to maintain all the relationships and dependencies between the code and editor where as bespoke engines tend to improve productivity further into development since they are streamlined for the job at hand.  For anything but really the largest or most specialised projects however you're very unlikely to beat Unity in terms of development speed and ease by writing your own engine.

If you use Unity you will also benefit from the ongoing development and support for the engine which brings it up to date with modern techniques and hardware.  Having to continue to update and support your own engine is an ongoing job which for a small teams can be a serious time sink which detracts from the development of actual games.




TLDR version:

If you're a small dev team working on a reasonably sized project you absolutely cant beat Unity for speed and ease of development compared to writing your own engine.  If you're a larger dev team, or your game is very large or has specialist tech requirements then you should test the waters first before taking the plunge.

[oahda]

If you're in it for the money and want to get a game out as soon as possible, or just want to focus on the game alone anyway, probably Unity.

If it's more of a hobby project with no rush, then perhaps make your own engine if you enjoy that.

That's what I'm doing (while also making another game in Unity, so that I learn/develop both and can borrow concepts from either experience into the other — also considering learning Haxe for the next Ludum Dare). At some point I can probably focus more or less entirely on just game content and it might be time to make it a bit more serious and perhaps even try to fund it, but for now I'm just enjoying my hobby while working other decent jobs.

I don't want to rush my games anyway (but I'm still forcing myself to do boring stuff sometimes just to get necessary work done, and try not to implement new stuff in the engine until the game needs it, which is a good way of working — codeveloping game and engine to see what the needs really are rather than making the engine first with guesswork as to what will really be needed).

[J-Snake]

I spent a year writing my engine, then another year writing a game on it and only ever managed to make it run flawlessly on a few select systems. There were strange graphics card bugs that I was never able to solve, a lot of compatibility issues with all the different libraries I used etc.

I don't quite understand. If you are using opengl properly then the only cause for gfx bugs are buggy drivers. How would Unity magically change that? I assume it is using opengl etc. under the hood aswell. I can imagine that some driver implementations tolerate some wrong use of opengl while others don't.

[Netsu]

I don't quite understand. If you are using opengl properly then the only cause for gfx bugs are buggy drivers. How would Unity magically change that? I assume it is using opengl etc. under the hood aswell. I can imagine that some driver implementations tolerate some wrong use of opengl while others don't.

You assume that I write bugless code

[J-Snake]

Aha, you faulty human

[Sik]

I don't quite understand. If you are using opengl properly then the only cause for gfx bugs are buggy drivers. How would Unity magically change that? I assume it is using opengl etc. under the hood aswell. I can imagine that some driver implementations tolerate some wrong use of opengl while others don't.

What makes you think that Unity's programmers aren't spending lots of time looking for workarounds for buggy drivers so they can sneak in more features even if at the cost of ugly code internally? Especially for annoying bugs that only happen under very specific circumstances.

[jgrams]

What makes you think that Unity's programmers aren't spending lots of time looking for workarounds for buggy drivers so they can sneak in more features even if at the cost of ugly code internally? Especially for annoying bugs that only happen under very specific circumstances.

^ This. Absolutely this. I was sort of around on the outskirts of the Factor language while it was growing, and I remember Slava having to spend ridiculous amounts of time finding workarounds for all the different buggy drivers to get it to the point where you expect it to render reliably on an arbitrary machine.

Of course, that was 2005 or so; things are probably better now, but I wouldn't bet on them being *that* much better. The Unity team probably spends a fair amount of time on things like that.

I know the Blender team has given up on it: their standard response is "It's not our problem: complain to your graphics card manufacturer." And it seems to still be a surprisingly common complaint that people have about Blender.

[J-Snake]

What makes you think that Unity's programmers aren't spending lots of time looking for workarounds for buggy drivers so they can sneak in more features even if at the cost of ugly code internally? Especially for annoying bugs that only happen under very specific circumstances.

It is just absurd and will cause even more problems over time. Why should it make sense to do that if they still cannot write flawless code; Unity still has its own engine bugs. The same probably goes for Blender. Driver implementations can change from update to update, it certainly is the responsibility of the driver creator to do his part right.

[Layl]

It is just absurd and will cause even more problems over time. Why should it make sense to do that if they still cannot write flawless code; Unity still has its own engine bugs. The same probably goes for Blender. Driver implementations can change from update to update, it certainly is the responsibility of the driver creator to do his part right.

It's easy for unity's devs to say "it's the driver's fault, we can't implement cascading lightmaps until they fix it". However, that won't stop people from jumping ship to UE4 if it does support them at the cost of a single file of worse code.

[J-Snake]

Except that it is more likely Unity's fault than the drivers fault.

Drivers will get updated quickly when major complaints arise.

[starsrift]

Thanks a lot for the responses, especially Netsu and Motorherp.
I have my engine made, but I'm really dreading running into some obscure graphics or video card issues and trying to support them. And yeah, exactly like Netsu's, it's C++/OpenGL/OpenAL... 

Ah well, time to learn Unity, I s'pose. Buddy of mine from university said it's super easy, that I should be able to pick it up in a day...

[Netsu]

Ah well, time to learn Unity, I s'pose. Buddy of mine from university said it's super easy, that I should be able to pick it up in a day...

It's so easy I felt like I was cheating for the first month. Instead of making a game the game was making itself
But after a while I got used to the idea that my goal is to make a game, not to write code.

[Dacke]

There's plenty of middle ground between locking yourself into a proprietary system that may screw you over in the future and writing your own engine from scratch.

[oahda]

No matter what I think it's always good to look into new, popular technologies.

That's why I finally slipped out of my C++ monogamy some bare two years ago or so to start exploring Unity, and why I now have my sights set on Haxe. Still making my one game in C++ because that's how I started it. Another in Unity, like I said. I have no plans for Haxe besides perhaps, again, doing the next LD with it. Perhaps I will look at Unreal at some point.

And I did indeed get into Unity rather quickly, but at least for me personally I don't think it's about Unity in particular, but just learning any new programming environment as a seasoned programmer; it tends to be reasonably easy.

I vote for as much knowledge of as much as possible, no matter whether it comes to programming, human languages or something else. c; Everything ties together and makes you more proficient on the whole. Even if you end up going back to your engine, experience with Unity will surely have taught you a lot and given you new ways to think about software development, and going into Unity now your previous C++ and engine experience will allow you to do so with an insight many others would lack coming into Unity. Or, you could keep doing both and benefit from either experience simultaneously.

[J-Snake]

I have my engine made, but I'm really dreading running into some obscure graphics or video card issues and trying to support them.

Can you elaborate on what those issues are, what you are trying to do, and what gpus you have tested it on?

[Schrompf]

I made my own engine, mainly because I'm used to do it and I'm backed by a huge framework. I need more work at the beginning of development, but get new stuff done more quickly at the later stages of development. One additional downside I'd like to add to motorherp's post is that my artist kept complaining about the workflow details in our editor. Providing artists with a workflow they're used to gains some productivity, too.

Now that my game is released for Win/Mac/Linux, I'm fighting a dozen of dreadful details that you'll never have with Unity. Ok, supporting multiple mice and keyboards is something you'll not get with Unity at all, but still it's a source of issues I didn't expect. Like a keyboard registering itsself as Mice (yes, plural) on Linux XInput2. I also got some startup issues that some MacOSX users reported, a problem Unity definitely solved for you. My use of C++11 also caused the game to require at least OSX 10.7 because I had to link with -stdlib=libc++

Rendering, on the other side, was surprisingly not an issue at all. Windows builtin Intel OpenGL drivers crashed in glDrawElements(). Windows Intel OpenGL drivers complaining about deprecated shader code which fails the shader compilation when omitted. The normal OpenGL madness, you'd say. I really look forward to Vulkan, and I'm grateful that I took the time to wrap all those 3D APIs into a set of classes so that I can still use DirectX on Windows.

[InfiniteStateMachine]

I made my own engine, mainly because I'm used to do it and I'm backed by a huge framework. I need more work at the beginning of development, but get new stuff done more quickly at the later stages of development. One additional downside I'd like to add to motorherp's post is that my artist kept complaining about the workflow details in our editor. Providing artists with a workflow they're used to gains some productivity, too.
 

This would be the biggest reason I would use something like unity.