next »

[Pineapple]

Now you see, _MadK? This is how you argue a case. This is the proper way to defend/support a particular position. Nice, well-structured reasons that are clear and make sense.

Do you see the k capitalized in the name? No? Good. Because your mom doesn't make sense either.

[CowBoyDan]

If only panda3d has an editor like Unity3d *sigh*

Have you looked at JMonkeyEngine 3?

[ஒழுக்கின்மை (Paul Eres)]

Unity is the strongest engine I've seen for some time, flexible, well documented etc, but here are still some reasons for writing your own, as several people seem genuinely convinced it is never a good idea.

i don't think anyone in this thread said it's never a good idea -- like i said i think it's a good idea when an engine can't do something you want to do

i don't think the 'feel' thing is all that common to people who aren't game developers though. since i'm so familiar with gm and other engines i can usually spot a game made in those engines, but the vast majority of players aren't able to do that

i'm not sure about the 'polishing of individual features' part of what you said though. wouldn't that just be a subcategory of limitations? since you want a feature that an engine gives you, but you want it to be slightly different/better than that engine's feature. which counts as a limitation of that engine

so i'm not sure there's any reason not to use engines besides the limitations issue. the feel issue and so on aren't that understandable to me

[Matthew]

Unity and "rolling your own" aren't mutually exclusive.  There are big projects that use Unity but completely ignore the editor environment and its component-based architecture.  The new version of Universe Sandbox was shown at Unite last week, and it's literally just a single scene with a single GameObject running a bootstrap script.  Everything else lives in code.

Futile is another example of ignoring the editor and doing your own thing: http://struct.ca/futile/

Personally, I think there are very few use cases that justify airlocking the benefits of the editor.  Universe Sandbox is a really good example, because the scale of their simulation just wouldn't work with Unity's own scene graph.  Most games can just customize the editor to meet the unique needs of their workflow.

But to answer the original question, Unity is so popular because:

- Iteration is super fast with the editor (pause, inspect stuff, make changes, continue)

- Unified editor means artists/programmers/designers share skills and workflow

- Robust multiplatform that actually saves more time than it wastes

- Burgeoning ecosystem--Unity's popularity means it's easy to find skilled collaborators for projects

[Full disclosure and all that:  I actually do some work for Unity on their Unite conference]

[ஒழுக்கின்மை (Paul Eres)]

that's a good point -- even in game maker you can code "engines" within it. for instance i didn't like the gm room editor so i coded my own level editor / level save format in GM and use that instead. i also didn't like the gm collision, gravity, and friction features so i coded my own collision system and gravity and friction features. engines are usually flexible enough that if you don't like one of their features you can code your own alternative

[CowBoyDan]

My ludum dare entry was in unity.  I used the editor to create mockups to see how things would look, then i created prefabs from them.  The actual game scene is blank except for a flat panel (should have made a terrain or something to look prettier).  In the game itself though everything is instantiated in code (my game is kinda weird and different, doesn't use physics at all either).

A lot of people say they don't like unity's physics, well you are free to write your own if you really want.  Most of the time however the issues can be resolved by adjusting the global physics settings.  Unity uses PhysX.  Somehow I suspect that most people on this forum (or any forum where poeple complain about unity physics) aren't going to write a better general purpose physics engine than PhysX, if you really think you can, you should call NVIDIA and get a job.  That of course not to say that if you are trying to do some unusual physics interaction that is unique to your game that your own code might not be better suited to the task.

[motorherp]

Unity and "rolling your own" aren't mutually exclusive.  There are big projects that use Unity but completely ignore the editor environment and its component-based architecture.  The new version of Universe Sandbox was shown at Unite last week, and it's literally just a single scene with a single GameObject running a bootstrap script.  Everything else lives in code.

Futile is another example of ignoring the editor and doing your own thing: http://struct.ca/futile/

I posted in the other 'futile' thread about this but didn't get any feedback.  I'm scratching my head a bit about what the point of writing an engine within an engine is?  If you plan to not make use of all the main features of an editor based engine like Unity then I gotta wonder why you would use Unity in the first place.  Surely this is a case of another engine being more suitable to the task at hand rather than writing your own engine within another engine?

A lot of people say they don't like unity's physics, well you are free to write your own if you really want.  Most of the time however the issues can be resolved by adjusting the global physics settings.  Unity uses PhysX.  Somehow I suspect that most people on this forum (or any forum where poeple complain about unity physics) aren't going to write a better general purpose physics engine than PhysX, if you really think you can, you should call NVIDIA and get a job.  That of course not to say that if you are trying to do some unusual physics interaction that is unique to your game that your own code might not be better suited to the task.

From my experience the problem people have with Unity physics, myself included, isn't PhysX itself (although the lack of determinism really sucks) but rather how Unity wraps PhysX which really gimps the physics capabilities.  Unity doesn't give you any direct access to PhysX itself but instead only provides physics through a very limited wrapper interface around PhysX which really limits what you can do with it.

[BorisTheBrave]

i don't think the 'feel' thing is all that common to people who aren't game developers though. since i'm so familiar with gm and other engines i can usually spot a game made in those engines, but the vast majority of players aren't able to do that

Perhaps they cannot, but the effect of it is still felt - less innovation, more railroading. The end consumer cannot tell how difficult to make a product is, either, does that mean we should disregard game creation difficulty when picking an engine?

i'm not sure about the 'polishing of individual features' part of what you said though. wouldn't that just be a subcategory of limitations? since you want a feature that an engine gives you, but you want it to be slightly different/better than that engine's feature. which counts as a limitation of that engine

Yeah, it is pretty similar. But not necessarily the same. The sort of thing I was thinking off was, say, implementing tile maps in Unity. It has no support for them (I presume), but I wouldn't call it a limitation, because it is out of scope for the Unity engine. Implementing them inside of unity wouldn't be too bad, but they might not be quite as nice as they would in a home rolled engine, and possibly more work, too.

Unity uses PhysX.

PhysX is a huge library. I gather many of the complains of Unity's physics are because it doesn't give you full access to the physics library to tweak things as you see fit.

[ஒழுக்கின்மை (Paul Eres)]

saying that all games in an engine have a similar feel and saying that games in engines are less likely to be innovative are completely different things. you can't really "package deal" those two concepts, one does not imply the other. in my experience it's the opposite: because game are quicker to make in engines, they tend to be more experimental/innovative. it's not a coincidence that the most experimental / innovative games tend to be made in engines (e.g. increpare, tale of tales, cactus, christine love, and other people known for making innovative/experimental games tend to use engines)

[BorisTheBrave]

Perhaps I was identifying two different issues. My point was that it was a concern, that some choose to avoid. I'm not pretending that engines are a constant source of evil.

it's not a coincidence that the most experimental / innovative games tend to be made in engines

That is a bold assertion. Anyone else care to corroborate?

[Richard Kain]

That is a bold assertion. Anyone else care to corroborate?

I think he might actually have a point there. A lot of the indie games that I actually see get finished are made in existing engines. It's just easier and faster to make forward progress and maintain enthusiasm when working from an existing foundation.

It also narrows the gap between working on the back end and front-end. In the Unity project I'm working on now, I am regularly switching from working on graphical assets to code. In some of the custom engine projects I've worked on, I would do nothing but code for weeks on end.

There is still plenty of innovation and experimentation to be had in coding engine mechanics. A fine example would be the recent success of Minecraft. The draw of that game was NOT in the graphics, but in the back-end structure. But most generalized game engines don't prevent that sort of experimentation.

[Graham-]

As a general note, there is a skill to working with someone else's code and abstracting out well enough so that you can get what you want out of it. I see lots of cases, engine or otherwise, where programmers let existing code "define" how they write their own. Then they back themselves into a corner, blame the structure of the existing code, even though the issue was probably avoidable if they labored more in their abstraction.

There's a cost to using an engine by learning how to use it. If you feel confidence in doing this, then by all means. But some people hate that stuff, for whatever reason, and use their own. Most of the time the idea of "flexibility" comes down to where your skill set lies. Unity has some restrictions. Something like UDK for example has far fewer. Most of the time you can get what you want.

[InfiniteStateMachine]

Unity and "rolling your own" aren't mutually exclusive.  There are big projects that use Unity but completely ignore the editor environment and its component-based architecture.  The new version of Universe Sandbox was shown at Unite last week, and it's literally just a single scene with a single GameObject running a bootstrap script.  Everything else lives in code.

Futile is another example of ignoring the editor and doing your own thing: http://struct.ca/futile/

I posted in the other 'futile' thread about this but didn't get any feedback.  I'm scratching my head a bit about what the point of writing an engine within an engine is?  If you plan to not make use of all the main features of an editor based engine like Unity then I gotta wonder why you would use Unity in the first place.  Surely this is a case of another engine being more suitable to the task at hand rather than writing your own engine within another engine?

I have to agree with this statement. If Universe Sandbox wasn't a good fit for Unity I can't really see the logic in doing a code-first engine within unity. Another engine or from scratch seems like a much more sane approach to me.

[InfiniteStateMachine]

Unity is the strongest engine I've seen for some time, flexible, well documented etc, but here are still some reasons for writing your own, as several people seem genuinely convinced it is never a good idea.

i don't think the 'feel' thing is all that common to people who aren't game developers though. since i'm so familiar with gm and other engines i can usually spot a game made in those engines, but the vast majority of players aren't able to do that

I think what ends up happening is non-developers end up not liking the game but can't pinpoint the exact reason. My main case in point would be the input and networking systems in the bigname FPS engines (Source, Crytek, UDK).

[ham and brie]

I posted in the other 'futile' thread about this but didn't get any feedback.  I'm scratching my head a bit about what the point of writing an engine within an engine is?  If you plan to not make use of all the main features of an editor based engine like Unity then I gotta wonder why you would use Unity in the first place.  Surely this is a case of another engine being more suitable to the task at hand rather than writing your own engine within another engine?

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

[motorherp]

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

[st33d]

it's not a coincidence that the most experimental / innovative games tend to be made in engines

Yes and no. I've been making these icon-games recently, all the code is mine.

However, they all use a platformer engine I built from the ground up for an unreleased game.

Using an engine does allow you to hack together experimental ideas quickly, but the engine doesn't necessarily have to be someone else's code.

[Matthew]

Cross-platform support is one of them, but you still get the programmable asset import pipeline.  In Universe Sandbox's case, they're still using the art pipeline, shader pipeline, and even doing things like bringing in Asset Store packages for various effects.  It's just that their simulation lives in code, and then they position Unity objects to visually represent everything (they mentioned in their Unite talk that the Unity camera doesn't even actually move).

And as someone already mentioned in this thread, you also get whatever else comes down the pipe from dozens of super-duper-smart engineers.

I don't think it makes sense to use an engine-in-an-engine if you're doing a lot of your own low-level rendering.  But Unity still makes a lot of sense if you're mapping some other coordinate system/simulation/whatever into standard "render thisee-here 3D object" output.

There are some 2D games that build up a lot of their own animation tech, which straddles the line somewhere between rolling their own and off-the-shelf Unity.  The Mike Mobile guys do this really well (Zombieville):

[EdgeOfProphecy]

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

Also on the note of "Make a game in engine X and it feels like an X game."  That is simply not true.

Didja know that Dark souls and Flower were built in the same engine?  Can't think of many games that are further apart than those two, but they were.

It's more accurate to say that engines are highly tempting rather than limiting.  They offer a big ol' toolbox of nifty things that you can plug into a game.  Want smoke?  There's a particle for that right in Unity.  You don't even have to configure anything if you don't want to, just drop in an emitter and bam!  Smoke.

The asset store for Unity makes it very easy to acquire tools that others have written, prepackaged solutions for a problem.  This means it is very tempting at times to use these solutions, in their basic form, to achieve a certain goal in development.

These are tools that are publicly accessible to multiple people, and it's very possible for multiple developers to use these tools in a very off-the-shelf manner, which can result in similarities between titles.  It's not the fault of the engine, however, but moreso the developers themselves.

A game that feels like a "Unity game" doesn't do so because the engine is so incredibly crippled and limited that it can only produce that sort of game, but rather because it offers a lot of readily accessible tools to make that sort of game.  If you don't care to modify things, or don't have the technical skill to, then yeah you'll end up with a samey feeling game, but not at the fault of the engine.

(An engine can be a terrible, limiting pile of crap but I do not believe Unity to be such an engine)

[motorherp]

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

People are, you really think Unity is the only engine people use? 

Besides anyway, my point isn't that other engines are better than Unity, I use Unity plenty enough myself and really enjoy it, just check out my blog, so dont take offense.  What I'm getting at is that different engines are more suited to different workflows and different tasks.  Why go to all the effort of writing your own engine within Unity just to circumnavigate most of Unity's main features and try to force it to fit your workflow when all of its design works against it.  Alternatively there's likely another engine or framework out there that you could use out of the box that is much more suited to your desired workflow and still has the features you wanted from Unity such as cross-compatibility etc.