How to react to people "hating" on the Unity engine, who are ignorant?

The techempower benchmarks (https://www.techempower.com/benchmarks/), there are different ones. E.g. just responding to clients as fast as possible. Some with DB access. Everyone can send solutions for their favorite framework, so some use full .NET stacks and others use minimal stacks or other frameworks.

Here round 8, the last one that (still) includes Windows. This is json task, just respond with json to a client request:
https://www.techempower.com/benchmarks/#section=data-r8&hw=ph&test=json

Here with a real server instead of a consumer machine:
https://www.techempower.com/benchmarks/#section=data-r9&hw=ph&test=json
They removed the Windows results, I have a copy of that pages that still includes them. I have some kind of idea why Windows was removed (it did not scale, meaning more CPUs and 10GbE Lan did not help to make Windows solutions faster beyond a certain point)...

[Hint: they now have a business relation with MS, also read round 13 commentary (how .NET now is 859 times faster than before and how they congratulate MS (but in a single test only (the stupid one, just send fixed answer)), how they call it "now a top performer" even it is over a million req/s behind Java in this most stupid test, also .NET has 1272 errors while the real top performers have 0). MS now invests resources and money to not look bad in this benchmark, because it looked so bad. Note that in any of the more realistic benchmarks, .NET even loses vs Python, and Python does not have real multi-threading, only a single thread can be active at once, lol.
And earlier runs on AWS showed that they got better Hardware when running Windows, so be careful with trusting cloud benchmarks, especially now that MS provides the cloud.

E.g. read this "marketing", they are in direct contact with MS now (and then compare to the actual results):
"There is room to improve[...] Microsoft is taking on those challenges and will continue to improve the performance of its platform."

And this:
"It’s like an F1 car that anyone can drive. We should all be so lucky."

I would bet the commentary for round 13 is from a MS PR guy... Read it, it is funny (and sad).

This was such a good benchmark, and now MS ruined it with their money. Very sad. And I knew this would happen, even wrote here a year ago that MS will do that. I knew so I backed up the data of earlier rounds, and see there, the Windows results for real servers vanished.]

 

I actually find that I've been most productive, most efficient, and have made the most progress getting my game done in the least amount of time when I decided to program it entirely from scratch (without any libraries or engines beyond C/C++ runtime libraries and OS libraries). So I don't always buy into the Unity/productivity thing and the idea that you have to be an AAA studio to work at any level below Unity.

I don't attack Unity, though. I think it can be a great choice depending on your game design requirements. If Unity does everything you need it to do, if the performance you can achieve with it meets your needs and doesn't upset any of your game's players, if you're productive in it, and you don't care about or already have learned how things work at a lower level, then that's fantastic. Use it.

I agree that there are a lot of people who are very ignorant and who will associate a bad game made in Unity with Unity itself, rather than with the developer. They don't understand the process very well. And I'd have to agree with the advice to ignore those people, because what are you going to do? That's how people are. Maybe they just need to see some of the many great games that have been made with Unity already and create new associations, if they can get past the natural confirmation bias.

 

Exactly.
But let's be honest, that happens everywhere.

Very known example: for almost everyone, MS Paint is just a pile of ... And it's just a hell of effort to get something simply done.
But still, take a talented and passionate artist and he/she will blew your mind with impressive art that is usually rather associated with Photoshop, Gimp, LightRoom etc.

Games take this to a completely different level. It's not that Unity cannot be used to achieve impressive content, it's just that the ones working with it either cannot spend the time and money (which is unfortunate and a real pity - there are lots of professional teams out there!), lack the motivation and passion to get the best out of it or simply give it no real chance at all.
And the ones who can spend the money and the time usually take something that they've been using for a long time, simply because the knowledge, trust and reputation is already there.

It's (unfortunately) often just the final product which makes people measure the potential of the actual tools that have been used. That's how consumers often forge their opinions.

 

To be fair this is not really about .net - this is about IIS. Those are all IIS benchmarks, and don't necessarily have much to do with .net itself. IIS has always been a bit of a dog.

Just something worth noting, you're clearly way more passionate on the subject than I am.

 

There were solutions without IIS that were equally bad. E.g. pure .NET HTTP Listener. It did just not scale, you could add an extra CPU and gain nothing. Maybe a problem with the Windows TCP/IP stack?
Also the current benchmarks are Linux only. (I assume until MS can fix Windows to not look orders of magnitude worse). So no IIS involved, but here .NET seems to scale at least.

 

I would argue that those who have the time and money simply don't advertise that they are using Unity. Its pretty much only low funded, non professional games that show the splash screen.

There are plenty of decent games built in Unity.

 

Well put it this way. All those gamers trying to talk smart about "what game engine is better" or "Engine X sucks more than Engine Y" are pretty much nobody (when it comes to developing) and don't know jack$h!t. They have absolutely no concept of how graphics work in a game engine, or even what developing in a game engine is like. Now if they'd look at the Adam demo, they'd see that Unity is capable of producing graphics that are as good or better than Unreal's. It's all up to the developer and hardware available. If you're targeting 90% of Android devices, sorry, the games are going to look bad compared to someone targeting only iOS devices. Same with console - to - PC comparisons that so many "gaming" YouTube channels do.

So in your subject line, how should you react? Ignore them. Just understand they are people who have no idea on what they are talking about, yet want to sound smart for the sake of internet points.

 

I was rather referring to the very big titles and the corresponding companies who have been in the business for decades.

 

Unity is very easy to develop with, and is free to use for the vast majority of projects using it. It also works out of the box with Blender, and there's a vibrant community of people using it and sharing information. There's also the asset store so you can get assets for your project quickly for a relatively low cost if you lack the ability or time to create it yourself.

This is the "great democratization of game design" of a low barrier of entry. However low barriers also invariably brings an increase in lower quality games made by inexperienced (and occasionally disreputable) people. This is fine though, we want this as it means people who couldn't have made a game before now can, and so it also means an increase in new good and genuinely great games.

This is also happening at the same time as the Steam store has been opening up making more of these games easier to distribute and more easily available rather than just being sold on someone's website, or possibly only if you actually know the person making it. This increases the exposure of those games and the engines they use.

Ultimately game engines don't make bad games, but they also don't make good games either, they're just a tool. Tools are only as good as the person who wields it.

 

I am calling you out on this. If you are well versed in both Unity\C# and C++ then Unity will always win in productivity. In the time it would take you to code a correct GL context and window with a triangle rendering in modern GL in C++\Win32\Xlib you could have created a game prototype in Unity and possibly a vertical slice.

To back this up, look at HandMadeHero. He is obviously a great developer BUT he has ~367 videos of ~1-2 hours each and barely has a game. In 9 weeks of a normal work week I can create and polish a small game in Unity.

The only exception might be a pure console\terminal based game, but even then I would at least include rlutil.h for better terminal control and input.

I am looking forward to be proven wrong though.

 

I don't have much to add other than this great quote by Bjarne Stroustrup on programming languages, except that I feel it applies to game engines and frameworks in general as well:

http://www.stroustrup.com/bs_faq.html#really-say-that

 

Seems to me there are just two very different types of people. Some really connect with the modern game engines and for them it really does seem like these engines make game dev faster.

On the other side there are people who find it to be faster to just do it all in a more straightforward code-oriented manner.

I can definitely relate to @JasonBricco in that I find it is much faster to develop games in a code-oriented manner. Of course, I make use of things such as map editors, world builders, etc but as far as handling collisions, physics and so forth I find nothing beats straightforward programming.

BUT... I think a lot of it just depends on the person. Imagine someone is making Pac-Man in Unity... there are many ways to do it and I saw a video or maybe it was an article where a person literally assembled the playfield inside the Unity Editor. They added colliders to all of the walls, colliders on the prefabs for the pellets and colliders on the prefabs for the power pills. Then added all of that to the level inside the Unity Editor. It was so tedious I was thinking why would you possibly do it that way?!

For Pac-Man I'd use tiles and a map editor.

Right tool for the job and so forth.

I do differ from @JasonBricco in that I prefer using a programming language and a game-oriented API. But the main benefit I find over this approach compared to Unity (and other modern game engines) is I am starting with more of a clean slate. And because there is simply less going on in the background, less architecture in general and so forth it actually makes it faster to develop.

I think definitely the kind of games being made and their requirements can make a difference but generally speaking I do much better with less than I do with more. Meaning I find a cleaner, more simplistic (perhaps limited) api to be easier and faster to work with. The main thing is I don't run into the major time waster of fighting against the engine.

The more complex a system is the more pieces it requires to be set up to work with it and the more concerns there are to keep in mind as far as getting everything to work together. The ultimate example of that is probably when dealing with several different script assets from the store. On the other hand when you are working with just very tiny building blocks you have a tremendous amount of freedom to combine those in a number of different ways and you do not have concerns over connectivity and so forth. It could be this is what @JasonBricco finds so helpful in developing from scratch.

That being said Unity is a great game engine. Definitely.

 

Well, a few things.

Casey's videos consist of typically 1 hour of actual programming and a half hour of Q&A. There were a few exceptional days. If we assume 1 hour each, then that would be 367 hours. Let's say 400 to compensate for some extra time past the hour boundary (such as when he did a marathon stream). That comes out to 10 weeks of work in a job setting. That's only a few months to create almost a full game engine.

You're right, he barely has a game. But what he has will allow him to do things with his game you couldn't hope to do in Unity without paying an intolerable performance penalty. And what he has is something that is now entirely free from bugs he can't fix from Unity, and free from any limitations Unity may impose that requires spending extra time to work around those limitations. And what he has utilizes his preferred way of working, the way he's most productive using.

Which brings me to my next point, and why I said that I am more productive doing it the way Casey does it.

I make games that don't really fit the Unity way of doing things. I like to do a lot of procedural generation. I like to do a lot of custom drawing with code. I don't like to have a GameObject for every entity in my game because of the memory and CPU overhead. I like to make worlds that can be as large in size as the player might want them to be.

So I'm spending time hacking a way to allow extremely large worlds. I'm finding ways to avoid using GameObjects to avoid their overhead. I'm hacking in ways to get around threading limitations because Unity doesn't let you touch its API with background threads. I'm spending tons of time optimizing things in crazy, messy ways that would be much simpler to optimize if I had the control a language such as C++ gives.

And that's not including the situations where I almost can't even find a way to work around a limitation and have to accept limitations as a result.

When I can just program the way I want to program without all the working around limitations, I'm a lot more efficient.

Now, I do use Unity when my project is well suited to it - in that case, I don't run into nearly as many troubling limitations. And from that perspective, Unity is a fantastic engine that I highly recommend!

 

Weird. I've had tens of thousands of downloads for my apps and games and most of them have the Unity splash screen and I don't think anyone's ever mentioned it.

They're made with Unity 4 and below so its got the nice "made with Unity" splash screen.

Edit: I probably missed the point in what you were saying.

 

I think it is that working with a game engine is faster.

I would prefer to write my own stuff, use C++ for game engine programming, and tinker with all the awesome systems in a game engine, which fall into "amazing problem"(tm?) category. Meaning you can waste a lot of time on this time feeling good about it, while in reality there will be no useful work done.

First time I managed to made a basic 3d game prototype with a combat without even trying too hard, from scratch in a freaking 15 hours, it was a hard slap in the face indicating that it is the time to rethink my approach.

Traditional approach with the speed of unity - it is not happening. Not possible. Anyone who claim productivity, need to be called out on it, and they need to demonstrate it. It is possible to work "on your own" and feel really good about it, but that's not productivity - something that can be done in unity in hours will take months. Working on it will feel great though. But it won't be "productive".

---

A good test for productivity is Ludum Dare compo - with 2 day deadline to finish a project. Number of non-engine entries was incredibly low. I recall seeing one of them and it was 2d.

 

I think this is part of the issue with this discussion. Sure, I'll be more productive in Unity if I want to make a flappy bird clone that I can make in a day. I mean, the sorts of things I would make for Ludum Dare aren't very representative of the real things I actually wish to make.

And when things get more complex, then how productive an engine is depends on how suited the engine is to what you're making. To say, definitively, that an engine is more productive is very shallow because you do not know the types of games people want to make.

 

If you are trying to literally do everything yourself in C++ maybe using OpenGL then yes I think the first game or two will of course be much slower to develop. But the idea is (for me anyway) to build up your own patterns and library that supports rapid development. So on the first game there will be a lot of boiler plate code to write. Ideally that will be a one time thing. And then you just keep expanding on that base. Of course, I haven't done anything in a couple of weeks or more now. But that was always my plan.

I was coming from the angle of using a game oriented api, an existing library and there are a lot of them out there. I don't want to get into all of the other libraries though because I know the mods hate that kind of thing here. Just saying there are options allowing you to build your games with C++ with a simpler api and an overall simpler architecture. Perhaps not even a true game engine just some higher level support than provided by something like OpenGL. So you give up some features. But if you don't need them anyway then you are not actually giving up anything.

 

This is reasonable in theory, but the issue is this stuff can easily take a decade (due to infinite number of distracting "amazing problems"(tm?) ), unless you have a very precisely very narrowly defined project. Engines are general-purpose, and you'll want your "library" to be general-purpose as well. However writing flexible general purpose solutions is the hardest thing to do.

And that api/library is a Game Engine.
Unity, Unreal, etc.
At least that's the way I see it.

------

Basically... in my experience, trying to write your own stuff and going low level is a good way to ensure that your project will never be finished. If the goal is to "have fun programming", sure. If the goal is to "finish the game".... definitely a horrible idea.

 

Different things for different people.

Unity does make 3D game dev much faster than something like Direct3D for sure. I prefer something kind of halfway between OpenGL/DirectX and Unity/Unreal/Other massive engine.

I'm not saying Unity is bad. Just that in my case anyway I don't need all of this stuff and don't want to be bothered with it. At same time I can't be too hard on it because I did spend a good amount of time learning to strip it out and develop in my own way in Unity in 2D and 3D games. Although I only worked on 2 games in 3D it was enough to be able to test out ideas and see that my 2D Unity dev style mapped fine to 3D Unity games.

 

In response to @GarBenjamin.

I would like to preface this with I am not averse to writing your own things for fun or using C++ because you want to etc. But stating it's more efficient \ productive to (When developing a game) write an engine\start from scratch is just blatantly false ESPECIALLY when you don't even make use of SDL, SFML, Ogre3D, GLFW or similar. I have some knowledge in this area so you know I am not just being difficult on purpose:

http://nhold.github.io/toasty.html

First of all, I was responding specifically to the statement I quoted from @JasonBricco where he states he is more productive and efficient when writing a game from "scratch". I equate productive when developing a game with working on and getting the game done, not the underlying windowing, rendering and entity systems which you could most likely work on for years on them alone.

Your ideas boil down to basically a code-oriented workflow, which is fine but then you imply that Unity isn't usable like that which is false. You can use Unity like a basic game library.

Maybe I'll make a blog post about this but you could make a vim user feel at home using Unity API to build a game:

• Have a bat\bash script that calls a known editor build script from a unity installation and project dir for building.
• That editor build script will ensure an entry point scene and entry point MonoBehaviour exist and is in the build.
• Use your favourite text editor \ file explorer to build the game.
  • If you use Visual Studio \ Mono Develop you will probably have to call the internal class SyncVS.SyncAndOpenSolution(), you could do this in another editor script that a bat\bash script calls so you could generate from command line or open the editor once to generate it.

I am not sure what you mean by blank slate or more happening in the background. You are free to ignore anything in the Unity API you don't like and roll your own if you are so inclined.

Recently on a project I was lucky enough to work with the ex-lead engine developer at Half-brick, he created his own terrain system (Additive modifiers only, brilliant!) and node-based road generation system for our project in Unity. This is something you would have to do if you were writing your own engine but without all the time sink of literally everything else.

In response to @JasonBricco

Casey himself would likely admit it's less productive to do what he is doing instead of using game library and\or engine. That's why he specifically says that he is doing it to create a high-quality lesson for programmers and not because it's the most productive method to create a video game.

Your assertion that he can do things I can't in Unity is completely false. I can write C\C++ libraries to get more performance for my game and hook it into Unity, I get the best of both worlds. I have done this before with a proof of concept multi-threaded octree based voxel planet handler:



But I didn't start building a house to replace a tap in my already existing house.

If your optimisations or feature additions makes things crazy or messy, it's you who is doing something wrong. Now I am not saying Unity is amazing, I am aware of and in most cases replaced or fixed it's issues and missing features, but it's usually better than starting from GL\C++ which I have done numerous times.

We should probably stop de-railing and start a different topic or move to a different forum of discussion though.

Again, I love working in C++ and Unity. However in almost all cases it's more productive (I.e getting the game done) to use Unity. I still want to know what your use case is @JasonBricco as large, even 'infinite' worlds have been done in Unity before without having to re-write an engine.

 

@NathanHold I did not realize that. How do I completely avoid working in the Editor and use only the API and how do I completely eliminate GameObjects? Just two examples. If this can actually be done the next time I work on a game I may very well give Unity another try.

 

Unity provides low level native plugin interface. It is very bare bones, thoguh, but you can interact directly with rendering api.

You can also ping-pong data between C# and C++ code by using native plugins. C# allows one to send arrays into C++ code without actually copying the data, meaning you are pretty much feeding internal array pointer to the C++ side. Now, there's still a matter of writing C# bindings for C++ dlls, but you are free to discard any side of API and move all the work into your own code.

Not much point in doing that, though, because you'll be losing benefits unity provides.

Still, if you want to fill a texture using data generated in a native code, this is fairly trivial.

 

Unfortunately, you'll need to have at least one scene and one game object (Similar to how Zenject works). I call those entry-point objects when working like that. But you can automate that in your build script so you don't have to worry about it. I know some teams who write their own ECS in Unity in this manner, although personally I am fine with the Unity ECS.

I posted a basic how to here:

 

Ha ha. I think you obviously take this much more seriously than I do.

It's cool that you have it all working the way you like though! I spent a good amount of time when I got into Unity working to streamline everything and ended up with an approach that worked for me. But it still wasn't quite what I was looking for.

I don't want to get into this overhead type of stuff. That kind of thing is another example of what I like to avoid. I'd say the odds are if you saw what I ended up with you may go into shock. lol Originally, I started using everything I know and used in my career. Building complex systems, I took full advantage of my own interfaces for communication as well as creating a Message system, the component-based design for the tiny scripts and so forth.

I then went on a mission to throw out as much of this stuff as I could and simplify. Ended up with basically using just procedural programming with objects serving only as containers. No prefabs, no Animator, basically I used Unity to play audio and draw graphics. The first couple of projects used colliders and the API to detect collisions. The last one I replaced that as well with my own collision system. And that all worked beautifully. I achieved a very high speed development environment.

But... I feel the need to say again I am not saying Unity is bad. Heck I will probably use it again at some point. I haven't done any game dev in 2 to 3 weeks now and am loving it. But I think I will get back to it at some point. Maybe 6 months down the road. Maybe a year or two.

Anyway, thanks for sharing your thoughts.

 

You too.

There is a reason I am developing my own game API\Engine and Editor built on top. It's just not that productive when developing a game!

 

I want to make something clear here. I programmed in Unity for several years and I programmed in C++ for several years. I told you which method I am more productive using. It happens to be the 'from scratch' method. That method is more compatible with how I think and the workflow is better suited to my preferences.

I don't know how you get by thinking you're in a position to tell me what makes me more productive when I'm the one who tried both and saw for myself which one makes me more productive. Maybe YOU'RE more productive in Unity. That doesn't mean I am.

I already gave you my reasons for saying so.

I understand that (almost) every problem can be solved using Unity in some way. What I said is that I don't like to have to waste time trying to work around engine limitations. I like to directly program what I want to do. Spending time learning the engine and figuring out workarounds is time I can spend making my own. And when my own is made, I don't have to make it again. It's done. And I can build from it, reuse it for future games, etc.

And I'm so much more powerful, and my game performs orders of magnitude better than what I can do in Unity.

Yes, you can make 'infinite' worlds in Unity. At what cost? It's virtually free at the low level.
Yes, you can use C++ code with Unity. I don't like to pay the thunking costs especially with the performance requirements I have. I work on the level of having potentially millions of entities within the player's view range that have to be processed. Yes, there are ways you can get millions of entities performing in Unity (even if they all are individual entities with unique qualities). But C++ gives me much more power to optimize it in ways that are more straightforward and easy for me to understand.

It's what I like. It's where I'm most productive. I don't think you should be trying to argue with me about that. You don't even know the kinds of games I want to make.

And in fact I am using Unity right now for a project, because I think Unity is well suited to this project. But even when it's well suited to the project, I find myself wasting a lot of time trying to figure out why its lighting isn't working as I'd expect, for example. And who knows, I didn't program it. I could spend months messing around with the lighting to try to get it to work how I'd like it, or I could just go program it myself and know exactly how it's working, and make it work how I want it to.

It gets a little annoying when people come and preach to others about how they should be using so and so tool to do their development and that they shouldn't "reinvent the wheel". You know what, let people program how they wish to program and you program how you wish to program. There is no such thing as the 'wheel' right now. If we actually had a wheel, then that advice would be sound. What we have is a vey clunky, inefficient, and poorly designed wheel. And there's a lot of room to improve that wheel.

 

Most of what you say is not relevant to me, I don't care about re-inventing the wheel. I don't care about how you like to code. I don't care if you use Unity\Unreal\C++\Python\JavaScript etc. I care about this statement you made:

I want to see you prove that. I ask you to prove it because I want to learn what you are doing \ how you are doing it. Why do you stop at the C++ run time libraries\OS libraries to be more productive, instead of say creating your own optimised compiler and language or using x86/x64 assembly? Why don't you use SDL at least for windowing, what makes that aspect more productive? What about rendering? How is it more productive to ignore say BGFX or Ogre3D which have had thousands of man hours put into them? Or Bullet\Havok\PhysX? Have you written your own build system or using cmake\makefiles\premake? Are you specifying your own file formats, or using others? Have you considered using assimp, where is the productivity gain in not using it?

If you want to bring some numbers out I have been developing in C++ for 12 years and C# \ Unity for 5. Yes I have more experience with C++ than C# or Unity. I have nothing but interest for your statement, let me learn from you.

 

Whoaaaaa now guys - haha. I don't want to see this thread degrade into personal attacks or anything like that, so lets keep the peace ya'll

Firstly, you guys both do some (awesome looking/sounding) wild stuff in unity and outside of it ( @NathanHold and @JasonBricco ). You both probably are trying to do way more complicated stuff than I typically take on (although my project pixel destruction has turned into quite the complex thing) and you obviously both are not ignorant about what it takes to make a game, and what it takes to do it with unity or otherwise... So for the two of you to argue (have a heated discussion? ) about the drawbacks and issues with this stuff - totally makes sense to me, and yes you both make valid points!

But.... remember, the point of this thread is to discuss people who DO NOT UNDERSTAND AND COMPREHEND what game development is like - ignorant people for lack of a better way to describe it - who go and create these hateful to engine X or Y posts online somewhere, when they simply have no idea what it really takes to make something out of nothing, whether it be in some engine or a frigging raw old school assembly crap, and harp on how thing Z would be done so much better if engine/framework/language was not the one it is...

I see very comprehensive and detailed explanations sometimes about people having issues with unity to do something complex that pushes the engine too far - and that happens, I get that - but I sure hate to see it when someone with no background in this stuff is dogging on an engine or whatever, and spreading misinformation with no research, no evidence, basically just hate mongering for one reason or another, from the perspective of a gamer, who thinks they know what they are talking about, but actually has no idea... and often it seems they just have formed a bias instead, and forever assumed an engine is inferior for one reason or another, without real proof or examples of alternatives....

So in conclusion - yes, there are always going to be things engine X or Y won't do as good as the other, but remember that I mean specifically "ignorant" (does less informed sound more polite? haha) people who make these kinds of claims with no evidence or research.

 

-Why don't I create my own optimized compiler? Because I don't need to.
-Why don't I use assembly? I do, when I absolutely require the performance. I wouldn't write the whole application in it because I would not be more productive doing so.
-Why don't I use SDL for windowing? Because it's dead simple to handle windowing without it. Why would I want the complexity of the library added to my project for something simple like that?
-Why don't I use libraries for rendering? See Casey's (Handmade Hero) simulation regions he adds early in development for an example.
-Why don't I care about how many hours were put into Ogre3D? Because those hours weren't spent designing something for my game. They were spent designing something that is general purpose, and not always compatible with my game.
-Why do I ignore Ogre3D? Same reason as for 2D.
-Why do I ignore full physics engines such as PhysX? Because they offer way more than I actually need, are often fairly glitchy, worse performing (given I often don't need the complexity), and don't give me enough fine tuning control to get the feel I want.
-Which build systems do I use? I don't use build systems, I use batch files/shell scripts and re-compile all the code each time.
-Do I specify my own file formats? Yes.
-Have I considered assimp? I have not considered using assimp. Perhaps using some libraries would offer small productivity benefits, but I often don't like the complexity of a library being added to my project unless I'm really going to gain serious time from it without sacrificing much.

-It is extremely amazing that you have been programming for C++ for 12 years and Unity for 5 years. I'm not playing a numbers game. I made the comment I made to state that I reached the conclusion about how I'm most productive based on x number of years of using both. The numbers don't actually matter because the conclusion was only relevant to my personal preference anyway.

-Have I programmed for as long as you have? No. Does it change anything I'm saying? No.

I will apologize for contributing to de-railing this topic. It is, indeed, about those who are ignorant about the process and aren't making justifiable claims. And that's a whole different matter.

 

Unless your game is extremely small, I don't see you being more productive following your reasoning here. Do you have a place where you blog\stream so I can see your productivity first hand?

EDIT: This is my last post in this thread so we don't get it locked. PM me if you are interested in chatting more.

 

No, I don't. And you may not see me being more productive, but that's your issue. I'm stating that I am more productive following that reasoning. And I'm also stating that Unity is a great engine, and not telling anyone to make games from scratch. Just saying my preference. If you disagree, then that's fine. You do it how you are happy doing it.

 

I think that efficient approaches are more important/interesting than "people who do not understand" but get angry at game engines, and I honestly don't see much point in discussing those people for a whole week.

So, if someone knows a better approach, they should tell others their secrets.

However, the most likely scenario is that people mistake "comfort" for "productivity".
"I work this way, because I'm more comfortable working this way" is a valid argument, but that does not mean productivity. Feeling comfortable and convincing yourself that you're more productive does not mean that you're actually more productive. There's "getting things done" and then there's "feeling good while thinking you're getting things done".

Anyway, not much point in discussing this further.

 

Well, yeah... your right, I don't intend to keep the conversation going haha... I just kind of wanted to get a perspective of how other unity users felt about these types of situations really (and whether it "grinds everybody elses gears" too), and didn't expect such a big response on this thread! So I guess this thread has outlived its usefulness

Thanks guys for all the input!

 

For some reason, some people believe that comfort isn't important for productivity. It's so strange. Seems like a pretty fundamental thing for productivity. I have found myself to be most productive when I am most comfortable. I guess some people shouldn't be speaking for others. Some of us are capable of measuring whether we are getting things done or not, by the way.

I'll have to agree with neginfinity, though. No point in discussing this further.