• Advertisement
Sign in to follow this  

Unity Commercial vs. "Other" Engine Productivity for a Single Developer

This topic is 456 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is kind of yet another "which engine" post (so recommendations welcome), but not quite.  

I'm particularly interested in hearing what people have to say about productivity of modern commercial engines (ex. Unreal 4) vs that of popular open source engines for a single developer. That alone may be enough to rule out most or all commercial stuff, but maybe I'm wrong!  

 

I've always assumed that a commercial engine would require a ton of "bootstrapping", have a huge learning curve, would assume your requirements are all AAA (thus making my more trivial requirements actually harder, vs a simpler engine designed for the little guys), and that it'd be completely infeasible for a single dev to ever use.  But I've decided to re-visit that assumption.  

 

A few constraints to be aware of: 
-Not particularly interested in toolset-oriented engines (ex. Unity?)

-C++ should be a first class citizen - I don't want to spend my time learning tools, I'd rather spend my time learning a well documented, high quality API where I can stay in code world as much as possible.  

-"Tools" like static scene or level builders are okay I guess, but probably not very helpful since I'm interested in space-sim type projects centered around travel, "building" your own scenes/bases, and some procedural content.  
-Linux support (at least as a runtime platform)

 

Edit: 

I should probably state that by "commercial" I mean proprietary, AAA capable, corporate backed, and so on.  I guess that commercial/noncomm line is starting to blur a bit lately...

Edited by Tebriel

Share this post


Link to post
Share on other sites
Advertisement

I  say go with the requirements .. if you need AAA game use AAA engine .You are not going to make it better then the comercial engine simply because they have larger user base and are already tested.If not just pick a engine with features that you need , a decent resource and memory management or do it by yourself.Generally if you are not making FPS a simple pipeline with just texturing , basic shading and skeletal animation will do the work.

Share this post


Link to post
Share on other sites

The fact is, UE4 does have C++ as a first-class citizen but it is also heavily toolset-oriented. I would say that in my experience all major engines are toolset oriented these days. Programmer time is expensive so a lot of effort has been invested into the tools so that implementing features and integrating assets can be done with minimal or even zero coder intervention; that's what makes these engines worth the money.

 

Your productivity with such an engine is very context-dependent. Many tasks become easier - once you know how the system requires you to do it. Investing an evening to read the docs, watch some tutorials, and take notes will pay for itself within the first week.

 

Right now I wouldn't touch any of the basic open-source frameworks or engines unless it was mandatory. There are several interesting alternatives to Unity coming along, like the Godot engine and Polycode, but there you're talking about small communities and relatively untested code.

Share this post


Link to post
Share on other sites

commercial engines (ex. Unreal 4) vs that of popular open source engines for a single developer.

I find that with the open source engines it's easy to do basic things, when you start getting deeper into development and the closer you get to releasing the game the harder it gets to do things.

These smaller open source engines have a much lower learning curve in the beginning than a commercial engine however as you near the end of development the learning curve gets much worst than a commercial engine.

 

Unity I find suffers from a similar problem, although not as bad as a open source engine, once you load a 3D mesh into Unity the material is a fast setup but when you want to adjust a value that needs adjusting only once in a while- like Fresnel- you have to rewrite the shader. Unreal has you loading in a mesh then using the material editor to assign color and textures, however adjusting a value like Fresnel is the same as adjusting color.

 

The commercial engines have a much higher entry level, with a more constant learning curve. Also when you learn something new you get good feedback from the engine making you feel like you are progressing.

 

If you only plan on making simple puzzle games or games of low complexity a open source engine is a good choice. Unity is a good lightweight engine for most types of games, however making large games with it or just good looking games is much harder.

If you plan on making large or beautiful games then I will recommend Unreal, it can just do so much more, faster when you know how to use it. Lumberyard is also a option however it's still got a lot of work left before I will start recommending it.

Share this post


Link to post
Share on other sites

If I did try a commercial engine, UE4 is the one I'm probably most interested in.  I am concerned that it might be too constraining to always have to do it the "engine's way", as I tend to be interested in building stuff which doesn't usually fit into the typical cookie cutter pattern, but that issue seems to crop up even with smaller engines.  Only way to know is to try it out, I guess.  

 

I find that with the open source engines it's easy to do basic things, when you start getting deeper into development and the closer you get to releasing the game the harder it gets to do things.
 

I'd say I've noticed the same.  

Does anyone know how UE4 is with on the fly mesh generation and low level tasks like this?  Ex. manually filling vertex buffers, texture coords, and so on.  (Not for everything, just for say, terrain.)  Or is that kind of thing way too low level for an engine like this?  

Share this post


Link to post
Share on other sites

 I am concerned that it might be too constraining to always have to do it the "engine's way", as I tend to be interested in building stuff which doesn't usually fit into the typical cookie cutter pattern

No engine is perfect for this reason almost all of them allow you to extend or modify the core engine with extensions or plugins. All the engine is a bunch of really good pre-made tools there is no reason you cant do things your own way.

Engines are made in a way that you can get the most out of doing the least, with some research you will quickly learn that most of "engines way" is often the faster and most yielding workflow.

 

Does anyone know how UE4 is with on the fly mesh generation and low level tasks like this?  Ex. manually filling vertex buffers, texture coords, and so on.  (Not for everything, just for say, terrain.)  Or is that kind of thing way too low level for an engine like this?  

Unreal can and has it's own terrain tools that are easy to use, it also has a lot of pre-made tools for mesh generation.

Share this post


Link to post
Share on other sites

I find that with the open source engines it's easy to do basic things, when you start getting deeper into development and the closer you get to releasing the game the harder it gets to do things.

I would say my experience is similar.

With UE4 I have found that the massive community surrounding the engine helps to find solutions to problems of every size quickly, and in the rare cases (which I have had) that there isn't already a solution posted the developers scan the forums and make posts themselves. This fact is boosted by an actual company looking to make money from the product and can only do so if you make money, provides a great system of aid.

 

Hope this helps.

Share this post


Link to post
Share on other sites

Honestly, I can't claim that I've used a variety of engines, especially when you get in-depth enough to know how well they work out for a full and complete project.  But that being said, I've pretty much only worked solo, so I can make some comments about that.

Using UE4 is, I think, completely viable for a one-man operation.  First off, you don't *have* pursue a AAA visual design.  As a solo developer myself, I have to honestly look at what I can produce by myself.  What kind of code can I write?  What kind of of art can I produce?  Levels, sound, and so on down the line.
And while I don't have the art skill to make something that looks photo-realistic, I can still create something that looks stylized to a uniform direction.  And while I can't make extensive ground-breaking changes in my code, I can follow examples and make relatively simple games.
And you know what?  I can do both of those with UE4.  Their material system makes it MUCH easier to build something to a cartoony style or a painted style or etc, as opposed to having to actually write shaders myself.  And their blueprints system makes it easier to create basic programming changes; I can do a lot without having to actually compile code.  And beyond that, I have a large community that I can turn to when I get stuck and get help on their forums.
Epic does these showcases every so often, and they include a number of projects that don't look like some AAA team of 30-40 people, but just talented hobbyists doing stuff at home.  They don't get as much attention, but they are still there.

But I'm a bit confused as to why you would reject Unity for being a "toolset orientated engine" but not Unreal for the same reason.  Perhaps I'm just not sure as to what you mean with that term, but they both come with their own interface and their own set of tools that you have to use to produce anything.  And honestly, I'm not sure why you would want to avoid that.  All development requires tools.  All games are going to require you to use a variety of tools to create the game.  And personally I would much rather be using Unity to get a significant starting point in what I'm doing plus have my code easy to write and implement.  Being able to tweak variables in the game and instantly see the changed result without spending hours recompiling is a godsend.

Share this post


Link to post
Share on other sites

Since the main purpose here was to determine if using something the size of UE4 was feasible for a one person team, and nobody has claimed otherwise here, I think I have my answer. Thanks 

But I'm a bit confused as to why you would reject Unity for being a "toolset orientated engine" but not Unreal for the same reason.

 

Possibly just ignorance of these large engines (that's why I'm asking), but I was under the impression that Unity was more toolset oriented relatively.  The real issue for me with Unity is that I'd rather work in C++.  

Being able to tweak variables in the game and instantly see the changed result without spending hours recompiling is a godsend.


I wonder if this is this a big issue with UE4?  I know how valuable that is, since I'm used to it. 

Share this post


Link to post
Share on other sites

Possibly just ignorance of these large engines (that's why I'm asking), but I was under the impression that Unity was more toolset oriented relatively.  The real issue for me with Unity is that I'd rather work in C++.

Oh. Well in that case, yeah, Unity doesn't give you access to the source code.
You get to write scripts in C#, but you don't have full source control.
That being said, I never felt like I needed full source control; I have no need to re-write how the engine handles libraries or rendering control. I had to learn a few Unity-specific functions that I call within my scripts, but I never felt like there was anything I wanted to do that I couldn't in Unity. Except for creating custom shaders, which I could have but I would have had to learn a whole new language for that.
Oh yeah, and I believe you can write new dll's for the engine to use, I started to look into that while back but didn't get very far.

With that in mind, Unity and Unreal really give you the same experience. It's just that Unreal gives you an option for more control if you need it.
When describing the differences between Unity and Unreal to a layman, I said that if you are create a small and simple game, like most mobile games these days, it is easier in Unity, but you want something with a lot of content, it is easier in Unreal.


I wonder if this is this a big issue with UE4?  I know how valuable that is, since I'm used to it.


Unreal 4 give you two significant options for adjusting your code. One, if you have only made simple changes (like no new variables I think) you can actually recompile the code while the game runs, and it will begin executing the new code as soon as it finishes. The game never drops or stops, it just recompiles in the background.
The other option they give you is to be able to adjust variables via console commands; you have make some functions be able to be called via console commands so you can easily set up your code to have certain functions run different versions or tweak variables on the fly. (Actually I have personally never used this in UE4 yet, but I assume it is still there.)

By contrast, in Unity any public variable in your script can have its value changed within the editor while the game is running (or before the game runs.)

Share this post


Link to post
Share on other sites
Unity was more toolset oriented relatively

Both are tool-set oriented with Unreal having more tools than Unity has; does that mean Unreal is more tool-set oriented?

 

 

 

I wonder if this is this a big issue with UE4?  I know how valuable that is, since I'm used to it. 

No it isn't, what he meant (I think) is that a code based engine VS a tool-set engine. With a tool-set engine you load things in and they work, with a code engine you have to write the code and compile before it works.

 

With Unreal if you use C++ you create a small code and you only have to compile the new code -Unless you mod the source code- so it only takes a small amount of time to compile. The downside is that all C++ code is called using Unreal's blueprints, meaning you can make a game using only blueprints or by using both C++ and blueprint.

 

Once you understand how blueprint works, it quickly becomes apparent how useful such a system is. With the Blueprints you only need to program a thing like a door opening once and then you can just copy, paste and modify it as you want.

 

 

Changes in the Blueprint compiles as fast as the blueprint saves, you won't notice it's so quick variable changes will be made here instead of visual studio that takes longer to compile.

 

Since the main purpose here was to determine if using something the size of UE4 was feasible for a one person team, and nobody has claimed otherwise here, I think I have my answer. Thanks 

It is feasible, although many people will advice Unity over Unreal for a one man team. Unreal is a bit slower to start, making it hard on a single developer but once it's running it gathers momentum allowing you to make larger games in shorter time than other engines. 

 

Unity is much smaller than Unreal to download, it would be best if you tested both. Personally I feel Unreal is much better than Unity, but it's subjective.

Edited by Scouting Ninja

Share this post


Link to post
Share on other sites

Both are tool-set oriented with Unreal having more tools than Unity has

Unreal has eclipsed Unity in its tool-set by having most of the engine available without writing a single line of code. 

t is feasible, although many people will advice Unity over Unreal for a one man team. Unreal is a bit slower to start, making it hard on a single developer but once it's running it gathers momentum allowing you to make larger games in shorter time than other engines.    Unity is much smaller than Unreal to download, it would be best if you tested both. Personally I feel Unreal is much better than Unity, but it's subjective.
 

Agree with this 100%!

I started with Unity in the early 3.0 days and now find that UE4 has so much more raw and refined power.

There are some limitation to UE4 that I think Unity doesn't have like UE4 must be build on the platform they will run on. So if you want a Mac or iOS build you will need to have a Mac. Unity gets around this issue, I think by being more api call/script focused.

Share this post


Link to post
Share on other sites

There are some limitation to UE4 that I think Unity doesn't have like UE4 must be build on the platform they will run on.

 

Good to know, I'm usually working on Linux (which UE seems to support now), although I don't see why I couldn't toss stuff onto a Win machine if I ever want to distribute something.   

Share this post


Link to post
Share on other sites

Big engine - "You are not a big enough customer to get support about the missing documentation."

Free engine - "Don't bitch if it's free!"

Write your own - "What was it that I was supposed to do now that the engine is done?"

 

Pick your poison. :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
    • By Estra
      Memory Trees is a PC game and Life+Farming simulation game. Harvest Moon and Rune Factory , the game will be quite big. I believe that this will take a long time to finish
      Looking for
      Programmer
      1 experience using Unity/C++
      2 have a portfolio of Programmer
      3 like RPG game ( Rune rune factory / zelda series / FF series )
      4 Have responsibility + Time Management
      and friendly easy working with others Programmer willing to use Skype for communication with team please E-mail me if you're interested
      Split %: Revenue share. We can discuss. Fully Funded servers and contents
      and friendly easy working with others willing to use Skype for communication with team please E-mail me if you're interested
      we can talk more detail in Estherfanworld@gmail.com Don't comment here
      Thank you so much for reading
      More about our game
      Memory Trees : forget me not

      Thank you so much for reading
      Ps.Please make sure that you have unity skill and Have responsibility + Time Management,
      because If not it will waste time not one but both of us
       

  • Advertisement