One thing you'll pick up if you stick to game development is that although we have certain coding patterns, the problem is that code is so flexible.

As an analogy imagine you were in charge of inventing the first railroad(both the rails and train) to transport things across country. Maybe someone told you how a railroad generally works, but all the details are really up to you. The gauge of the rails, what they're made of, how far apart they are, what the engine is made out of, how big it is, what kind of propulsion it uses. If you think about it there are a million little variations that would still end up with you having "a thing that travels along rails that transports people or goods over distance" same issue with coding.

That also makes it hard to understand other people's code many times because the essence of what their algorithms are doing can be hard to distill down just by looking at it, you have to work with it a bit to understand the idea behind it.

In addition coding really has two differing facets to it: efficiency and ease of use.

-Efficiency is really how fast or with how little memory some code can complete. Now arguably you don't want to worry about this all the time because that leads to micro optimization, spending all your time trying to make something run faster that arguably doesn't affect the gameplay experience that much. An example is saving. Saving happens infrequently by nature, if the game takes 5 seconds to save all your data and you spend many hours redoing the code to make it save in 3 seconds, did you really help that much? Percent wise you increased it by quite a lot but do you think people will care that much if the game takes 3 seconds to save vs 5? They probably won't unless saves happen constantly.

-Ease of use is something people push here a lot. It is designing your code so that it is easy to work with and expand, so that it isn't coupled tightly to other code and thus can be swapped out easily. We stare at code all day so making it easy to understand and easy to expand is nice, but the important thing to realize is that it being easier to read doesn't help the performance at all(generally.) Main advantage to this is that as a codebase gets larger you run into the issue of scale. Adding new features can take exponentially more time and changing existing things is slow too because you have to basically redo a lot of the wiring in your house.

Just to tune in on the whole Unity vs. Unreal thing.

If you don't intend to compete in the highest of ends, don't worry too much about the power of Unity. It can do pretty much everything Unreal can, given you have the expertise or the money to upgrade some of the stock systems.

As an example, the stock terrain engine in Unity is seriously dated. You still can create a goodlooking game with it with a capable artist, but you will certainly hit certain ceilings without modifications... BUT: there are already a ton of VERY capable third party assets in the store to upgrade the Terrain System. Using a thirdparty terrain shader (for example RTP), and a thirdparty grass and tree system (for example Infinigrass), you get already a terrain system that you would have to struggle quite a bit with the Unreal Material node system to get a comparable result.

Now, This will cost you some 100$'s of dollars for all the improved systems you need, and you probably loose some % of performance because these systems are not built into the engine core, whereas the Unreal stock systems are (but of course messing around with the Unreal Terrain shaders leaves room to mess up performance again). You COULD develop your own systems in Unity just fine given time and skill, but I guess this is not what you want to waste your time on. The Performance thingy is really up to question... will it affect your game? Do you REALLY plan to push the hardware with your game? Should it be the next Witcher? I doubt it. Even if you ramp up your team, can you realistically expect to hire the 20+ team members needed even for small scale AAA effort? Or will your rather just hire a single artist, and maybe a programmer, and have to make do with much simpler graphics which will not push the engine just as hard?

Don't get me wrong, Unreal 4 is a really fine engine, just as is Unity since they bounced back from their rough start in the Unity 5 release cycle. If you make the switch, and get along with the "Unreal way of doing things" (which is very Blueprint centric, and C++ centric at all unless you happen to have a lot of Unreal C++ expierience already), you will be just as happy using Unreal as you most probably are using Unity.

Just don't make the switch expecting Unreal to be the magical silver bullet that does everything for you, and more. Its not. You get better stock systems, and POTENTIALLY more power at the highest of ends when pushing the limits on graphics and stuff like terrain streaming. You pay for it with a very strict way of doing things, having to rely on Blueprint a lot, having a less intuitive and more cluttered editor than in Unity. And having less options in many areas (they didn't have a forward renderer option when I last checked, though epic was working on it). And if developing for mobiles or some of the more exotic platforms, Unity usually has you covered with build targets, and usually is more often used on these platforms than Unreal.

So really, you will most probably not gain MUCH, unless you are currently developing on a shoestring budget and are not ready to pay for assets in the Unity asset store that could upgrade some of the more dated aspects of Unity, AND are really hitting the ceiling of what the Unity stock systems can do. The Unreal stock systems will usually let you do way more, for free.

Another thing to keep in Mind, IF you would switch mostly for futureproofing, is the pricing models. Unitys is basically a fixed cost as soon as you hit a certain income threshold with your game, per seat (sadly now you have to pay a sub, but Unity still gives you the option to end the sub and keep the license after a certain sum has been paid). Unreals on the other hand is a 5% royality you pay after you hit a certain income threshold. You can get around this AFAIK by buying a commercial license at some point, though how expensive these are nowadays IDK. Most probably still targeted more towards big AAA studios, thus 100k$+.

But really, just download Unreal 4 and give it a test run. Its free! It only costs you some time to get into it, but IMO that is time well invested... for one you will learn more about how engines work in general, and you will now make a better decision on which engine to use for which project, and why.

I did it, and came back to Unity after 6 months. Unreal 4 just isn't for me. I can get the same Power from Unity with the help of some upgraded systems from the asset store, and I am positive that I can work around some of the performance lost because of the engine or the less integrated systems with some optimization at the end. I work way faster with Unitys way of doing things whereas in Unreal everything felt like a struggle to me.

Never underestimate the ergonomical aspect of different engine editors. If you can work much faster in the editor of an engine, that can outweight an engines lack in power in many cases. Especially when you know you will have no use for that additional power for your project.

In the end I came back to Unity with a new appreciation for the Engine, which I still think has many weaknesses. But it has its strengths where it matters for me, and I think I work faster in it than in any other engine. And this is what matters most to me, not some theoretical future proofing that might never be necessary.

Might be the total opposite for you. Maybe Unreal Engine 4 just clicks for you, and you find out you work faster in it than Unity. In this case, you will be happy you have made the switch now, and not waited for another 6 months.

But maybe you also find Unreal to be not to your taste. In which case the theoretical upgrade in power and stock system quality might not matter anymore, and you will come back to Unity with a renewed sense that this is the right engine for you.

In either case, investing some months into learning Unreal will be a very good investement of time, even if your game makes no progress during this time, and you have to learn many things from scatch again for Unreal. Your knowledge will grow anyway.

Kylotan

Yeah, it is surely a challenging subject to self-teach, but I must to what I must to accomplish my goals. Maybe ink and paper books are what I need. The tutorials are helpful, but so far I can't help but think "I don't think I would have done it that way."

I'm going to read through Game Programming Patterns, this looks to be a fantastic resource. Thank you so much for posting that.

Knowing the terms "persistence," "serialization," and "game states" are all very helpful. It's hard to know what to Google when you're starting fully from scratch, so these terms even so common to you are like a rosetta stone for me.


Satharis

Your railroad analogy is perfect. It's like how different drummers play different things to the same bass line.

Yeah I get that, everyone has such a different way to accomplish even simple things like character movement and loading menus. I've been doing different tutorials so I can learn a variety of ways to think, and figuring out how all the scripts talk to each other has been the most helpful part for me so far.

I'm not so worried about minute efficiency. The game I am making is not likely to be heavy on the system, it's mostly going to be dialogue and character interaction, with random and triggered battles being the most intense thing the game does.

Ease of use is important to me as I intend to take on crew when the project is ready to demo. I've noticed what you mentioned about scale already in tutorials. I decided to add a new stat to character sheets and I had to edit my leveling scripts, my saving scripts, my base item properties scripts, etc. It was more work than I expected but I think once all the nuts and bolts are working on character movement, leveling and items, I can focus on triggering dialogue and story events without having to revisit that stuff much. Here's hoping.

Gian-Reto

I am of the mind to always be ready to compete in the highest of ends. I believe Unity is adequate, but if my game is well-received I don't want to regret having made unnecessary compromises to get done just a little more quickly. Third-party assets appear to be a great option, and I have no issue paying for them, they're just a little expensive to purchase without trying before my game is even functional, considering I may switch platforms.

Since my game is mostly character interaction in real-life environments like inside of buildings and out in the woods, I worry about the realism. Most of what I am doing right now is just scripting characters and working on their interaction. I think the actual character scripting, dialogue, game events, etc. are going to be largely similar on either engine, but I think the user experience for Unreal will be better as far as realism. The distribution for Unity is the only thing I know it does better.

What does terrain streaming mean?

I'm happy to hear that you can get good realism from Unity. I have been working in unity so far, and I like it, but I haven't been able to make any of the test environments stand up to other games. I'm sure it's largely due to my skill level, but I worry that I might wind up with less realistic gameplay on Unity.

Your final point was exactly the thought I needed to consider. If I learn both I will know better which I prefer. Thank you for your advice.