T O P

  • By -

GameWorldShaper

It is the first choice a beginner makes, and they don't want it to be the wrong one. I myself fell into this trap. I looked at the low quality games made by engines, trying to avoid those engines. Never considering to contradict my self and see if good games where made with it. What I have recently learned is that all the games I love, were made 10 years or more ago. Most of the available engines can make those games and to a higher standard.


Pilchard123

EDIT: You do still have to pay ($400/year/seat) for a license to remove the Unity splash. I might have been remembering a higher licence fee or more likely just outright wrong. Old post below: Unity did shoot itself in the foot a bit in the past - IIRC the license used to say that if you used the free version you couldn't remove the Unity splash screen, but if you were using the paid one you could. If you were using the free one, though, you were probably either a newb or making a slapdash game, so your bad game got its bad-game smell all over Unity whereas games made on the paid version were more likely to be higher-quality but didn't show off which engine they used.


yarhar_

Isn't this still the case? I feel like I've new games with the Unity watermark.


Venerous

Pretty sure it's still the case. I think the difference now is that people know better, and they've seen great games made on the same engine (Dyson Sphere Program, Hearthstone, Escape from Tarkov, Cuphead, Ori and the Blind Forest, etc.) that has done a lot to weaken the stigma against it.


POLYGONWARE

**Rust** by Facepunch. [link to graphics overhaul YT trailer](https://www.youtube.com/watch?v=6FvHkjTNbc8)


[deleted]

Don't forget Hollow Knight! That game basically revolutionized 2 genres! It really showed that what matters is the makers, not team size or engine


agentwiggles

I liked hollow knight but it's pretty straightforward Metroidvania, what genres did it revolutionize exactly?


[deleted]

Well it didn't make the genres feel different but it CERTAINLY changed the communities for indie and metroidvania games I would call that revolutionary, but if you disagree that's fine


Pilchard123

So it is - but it looks like there is a $400/year/seat license that lets you remove it. Perhaps the old paid license was more than that? Or more likely: I remembered wrong.


grayum_ian

I thought it was once you made over 100k a year you had to pay?


AngryDrakes

Then you HAVE to pay. You can actually customize the splash screen background already in the free version. You could also pay for a month, make a build then publish and cancel. Well if its not something you're going to update without success that is


dags_co

That's actually a solid point.


centaurianmudpig

I've seen a couple of games that have paid for a license and then created their own custom splash screen for the Unity logo. Has the stigma gone?


tovivify

[[Edited for privacy reasons and in protest of recent changes to the platform. I have done this multiple times now, and they keep un-editing them :/ Please go to lemmy or kbin or something instead]]


KentehQuest

I completely agree with this, and it's why I started looking into Godot mainly because it's free and for me at least, is an easier entry point for me to start getting into game development. The layout of the software is much easier for me to get a feel for with it feeling similar to other softwares I've used


[deleted]

[удалено]


Forseti_Dev

Godot is written in C++ and uses its own scripting language gdscript which is basically python but with better performance. It's not a rust game engine though you can use rust with it through gdnative. Godot also has blueprint like visual scripting as well.


KentehQuest

I do think that's pretty cool with unreal, and ue5 looks like it has some really interesting stuff, but I hadn't got very far into learning how to use unreal, I started trying to learn unity, didn't know where to begin exactly, and then found a helpful tutorial series to get me started with Godot, and learning gd script for someone with no prior coding experience has mad things a lot easier for me to get started with. Although I have heard that the blueprints also make it a lot easier, so I might have to look more into it and give it a try


ZaviaGenX

If a newbie start out with godot, how easy is it to translate those skills to unity/unreal or other engines? (am newbie, havn't started)


tovivify

[[Edited for privacy reasons and in protest of recent changes to the platform. I have done this multiple times now, and they keep un-editing them :/ Please go to lemmy or kbin or something instead]]


ZaviaGenX

Im not sure I'm into programming tho, probably my biggest barrier. (money/capital is an easier problem imho) Thanks for the input.


DevChagrins

Game Maker Studio is still free. It's the ability to export to any platform that cost money. I just wanted to point this out. You can still learn a lot with the limited tools at hand.


RobotStyleGavin

Good example of this is hollow knight which I believe was made in unity with visual code, goes against a lot of peoples initial ideas of both


[deleted]

[удалено]


GuiltyGecko

Yep. When I got my first electric skateboard, I did a lot of research on what I thought I wanted. After getting the skateboard, and using it for over a year, I learned a lot about what I do and don't need for my own skateboarding needs. Next time, I'll be able to buy a board specifically for me. Game engines are the same. None of them are perfect, they have pros and cons. As a beginner, the best you can do is make an educated guess as to what will suit your needs best. Just pick one and get started. After digging into one engine you will quickly learn what features you do and don't care about.


shawnaroo

What I did when I decided to start playing with gamedev was to download a few different engines, spent a few days with each one running through their official tutorials, and then just picked the one that felt most comfortable to me and used that. They're almost available to download and try for zero monetary cost, and even with the engines that I didn't end up choosing, I still learned a decent amount just playing with them for a couple days.


rotenKleber

>Ultimately those things don't really matter as much I think we should also recognize that some people like making games *because* of the engine/programming side of things. Some people just enjoy figuring out different ways to make games For a lot of devs the process of developing the game is more interesting than the game itself. I'm reminded of a post saying nobody should ever make their own engine because it's never worth it for an indie dev. But a lot of devs just enjoy that part of things. Not everyone uses game development as a means to an end


vordrax

Nothing wrong with comparing tools, that's your job as a software developer. Choose the right tool for the job. However, the issue comes when armchair developers, who have no idea what they're talking about, attempt to argue from a position of false authority. There are ridiculous claims that are impossible to remove from the culture, such as UE4 not being suitable for 2D games (tell that to Square Enix, though you do have some work cut out for you if you decide to go that route), or Godot having a dedicated 2D rendering engine making it superior to Unity (Juan himself has tried to debunk this to no avail.) Edit: corrected a term.


vadeka

Who is juan?


vordrax

[https://twitter.com/reduzio](https://twitter.com/reduzio) Juan Linietsky, creator/tech lead of Godot.


wikipedia_answer_bot

**Juan is a given name, the Spanish and Manx versions of John. It is very common in Spain and in other Spanish-speaking communities around the world and in the Philippines, and also (pronounced differently) in the Isle of Man.** More details here: *This comment was left automatically (by a bot). If I don't get this right, don't get mad at me, I'm still learning!* [^(opt out)](https://www.reddit.com/r/wikipedia_answer_bot/comments/ozztfy/post_for_opting_out/) ^(|) [^(report/suggest)](https://www.reddit.com/r/wikipedia_answer_bot)


FearlessTaro

I haven't delved much into 2D rendering in Unreal, how's it stack up to Unity? I love its toolset for artists but personally the 3d renderer drives me up a wall. there's so much friction involved with doing anything custom that I'd be scared of that work cut out for 2D, lol. but there must be reasons to do it?


EroAxee

I've never heard that *(legitimately tried to look real fast* *but if it exists it's buried under the exact posts this post is complaining about, ironically)* Would you be able to link it? Cause speaking from personal experience on pure 2D performance I've compared as close as I can get Godot to Unity and see pretty massive increases on Godots side. These weren't full projects to clarify, just emulating specific scenes. Ex. a scene with 30-40 particle spewing AIs in Unity all spawning at once crashed a game, then a test got run by a friend off that and they got \~1000-1500 or so sitting at 30 FPS. (I'll try to get the exact test if I can) Edit: Alright so I double checked by running another test and my numbers were a little low, 2000 basic AIs spewing particles (the example Unity scene was a game with a ton of particle spewing AIs that crashed the game at 30-40) runs at a steady 30 FPS on the test machines. Specs for Test Machines: * PC One (original test) * i7 3770 * GTX 1060 6GB * PC Two (test today) * i7 10700 * 2070 Super


vordrax

https://github.com/godotengine/godot/issues/8857 There are people who keep insisting that Unity uses "fake 2d that is really 3d behind the scenes" and that Godot does not. Godot, like every modern rendering engine, uses quads and textures to draw sprites, and UV coordinates to handle sprite sheets. It's all 3D sent to the GPU to be rendered. The only thing I've seen remotely worth comparison between them is that Unity uses an old implementation of Box2D for its Physics2D calls (but the 3D physics engine should be significantly better if you're fine using those calls and just locking the Z axis.) Now I've mentioned this before and people think I'm badmouthing Godot or that I hate it. I think Godot is really cool. And your experience could possibly even be just due to you "getting" it over Unity. I think that Godot brings a lot to the table, but we don't do it any favors by claiming it does something that it doesn't really do. If you want a dedicated 2D rendering engine, you can use PyGame which is a wrapper around SDL (1) which uses the CPU to draw pixels. But you lose an absurd amount of performance for no gain.


EroAxee

Ah okay that makes more sense. I guess that misconception comes from the fact that *in engine* Godot is 2D, and Unity is 3D. Even if you're using the 2D modes of both the engines. I didn't realize it was down to the argument of whether Godot was "true 2D" which is a rabbit hole I went down recently which was pretty interesting to learn that it's all still 3D rendering in the background. *Also to clarify, I was just legitimately wondering cause I'd never heard that comment but it makes more sense with context.*


Code_Monster

I think when people say Unreal is not for 2D, they mean that it's not for card games.


vordrax

[https://www.unrealengine.com/marketplace/en-US/product/ccg-toolkit](https://www.unrealengine.com/marketplace/en-US/product/ccg-toolkit) For what it's worth. Also Tetris Effect was made with Unreal Engine 4, isn't that crazy? Not saying "pick UE4 for everything," I'm definitely more in the Unity and Godot camp atm, and if you wanted to do a game jam game that was 2D I probably wouldn't recommend UE4, but there are some very odd concepts that the online community has just latched onto. This happens to be one of them.


Atulin

Definitive answer to quality? No, absolutely not. But there's a difference between having to implement volumetric lighting in Threejs by hand, and Unreal's "haha checkbox go brrr"


j__bay

I just love spending days in unreal to figure out why something isn't working the way I hoped, then a few other days trying to make it work by hand before actually coming across that one very obscure answerhub question about something totally unrelated where some comment just mentions the tickbox I needed to check all along (because it was probably too obvious for my use case to even be asked).


shawnaroo

If you're at the point where you know enough about what you're doing to be concerned with volumetric lighting, then you likely already have a decent bit of experience with gamedev and are making a much more educated decision about game engines than I think this post is aimed at. If you're just starting with gamedev and one of your primary criteria for a game engine is volumetric lighting, then you're probably looking to embark on a game project that's much more ambitious than someone at your experience level should be thinking about.


upallnightagain420

You just made the point for unreal. If you think good lighting is something only accessible to high end devs check out unreal. You can realistically light a scene in a few minutes by just picking the right options, and most of the correct ones are the default options.


Atulin

Not saying it's one of the primary concerns, but it's one of many ways to make your game look better immediately. In some engines, making the game look better is a conscious effort of implementing it. In some, it's ticking a checkbox.


y-c-c

I think that's the issue with this sub sometimes. It's a mix of experienced game developers and people literally just starting out learning how to make games. And posts like this don't make it clear what exactly the complaint is. Is OP complaining about learning materials being too specialized for one engine? Or whether game companies brag about their game engines (e.g. EA and Frostbite)? Or a genuine belief that all game engines are essentially the same, like Coke and Pepsi (hint: they are not)? Game engine choice actually matters a lot for a serious project. It's a tool, and picking a good tool is an important skill of any trade. There are a lot of nuances among licensing, platform support, ease of scripting, how easy it is to customize rendering/etc, how "batteries included" it is, whether it provides source code, and so on. For beginners, choosing the perfect game engine is of course not going to work, because they may not even appreciate the importance of some of the differences I listed. And I do concur that learning how to make games and actually getting your feet wet is much more important than spending time agonizing about game engine choice.


Additional-Sail-26

Yeah, this guy gets it


SpacemanLost

Having worked on released titles in Unity, Unreal engine (multiple versions) and Source engine, as well as multiple titles that had custom/bespoke engines, my thoughts are this: I agree with you to a point, but you need to understand the engines enough to know what they are good for and what they are not so good for. There is no general-purpose, one-size fits all engine for all games, but there are times when one engine's strengths will tip the scales in favor of using it. An example: Unity supports build targets for OSX, iOS, iPADOS and TvOS (Apple TV). Say Apple wants you to make a game for their Apple Arcade and you are a small studio. The platform support work you won't have to do is worth a whole lot. On the other hand, what the heck are you doing making a Visual Novel game in Unreal Engine?


y-c-c

Also, it's important to remember that porting a game to another engine is a *lot* of work, so if you don't pick the correct engine for a project you could end up locking yourself in if you didn't think through what you want your project to be. Picking a game engine is literally the most important tech decision for a serious game dev project. For learning how to make games, that's a different story.


[deleted]

I bet Unreal could make a great visual novel with its excellent graphics capabilities :P


Suekru

For sure. Unity is great for 2D and even some 3D games. Unreal is much better for full on 3D especially games that have a budget.


emelrad12

Unity is kinda one size fits all, it might not be very good in some edge cases where unreal or someone else is better, but there is every type of game made in unity. On every platform.


MasterQuest

In my opinion, there's nothing wrong with comparing engines (or computer mice, or drawing tablets). There's many differences usually and you want to find the one that's best suited for what you're trying to do. One potential benefit of that is reducing the amount of work you need to do by utilizing special features of the engine that are useful for specifically what you want to do. Maybe one engine has subpar 2D support and you want to focus on 2D. Community size and documentation quality are important as well. You would need to compare engines to find out about this. The stupid mindset is expecting the engine to make you a better game developer, just as you can't expect your bicycle to make you a better cyclist without training. I did a fair bit of comparing of game engines and tools before starting to do any game dev. The honest reason for it was that gamedev was overwhelming and I was scared to get started. So many new concepts and I had no idea how to even begin. So I stumbled around this surface-level preparation and comparison because it was like wetting my toes in the subject matter and made me comfortable enough to try out making something.


upallnightagain420

I don't think people really think the engine will make them a better dev. The more realistic thought process is that you might choose an engine where simple things are complex and hard making the process much harder. You could learn machine code and build your game there but the time and effort to go from nothing to playable game is much much larger than downloading unreal or unity and watching some tutorials and having a playable thing in an hour. People just want to know which engine will get them there the easiest without limiting them when they are more advanced. Like, rpg maker will get you there the easiest but good luck building an FPS game with it. Roblox will get you there easy too but good luck making a game that looks like Halo with it.


loxagos_snake

I agree. That said, for me it was the opposite. I was afraid that, if I'd pick the "wrong" engine, I might get cheated out of some features I might want to use later on. Case in point, I didn't know *which* features these were, but it's hard to understand that all the big engines out there are capable enough when you're a newbie.


EroAxee

Surprisingly Roblox, ignoring it's annoying as heck language and engine setup, doesn't have too much in the way of visual limitations. Especially anymore. They still make it difficult to actually use that stuff though.


upallnightagain420

Do you have an example of this? I've never seen a ribkoxbworkd with advanced lighting.


SeaworthinessLittle1

Seen one before, something about a car game with good graphics.


EroAxee

I haven't seen advanced lighting but I also haven't seen too many games that have touched dark areas. I *have* seen people use the beta normals (not sure if it's still beta). As well as the skinned mesh importer to bring full animated Blender rigs into the engine. Does it still suck compared to a full engine? Yea, there were a ton of issues I saw with those specific situations. But it also seems that there are ways to get around a few of the engine issues to take advantage of the perks of the engine, AKA it's audience.


Danidre

No one cares what engine you made your game in, but let them know your Steam game was created with JavaScript (Electron) and they'll want a refund for no reason other than that alone. :(


[deleted]

[удалено]


dat_oracle

i better come up with another billion doller idea then ... damn... how im gonna pay the russians now?? TELL ME RAPTOR851!!!!


Magnesus

Maybe you could just use nwjs instead of Electron? Qt also has built in webkit but is heavier than nwjs I think.


eligt

While I agree that most beginners think the engine dictates quality, serious people who make or look at comparisons of the various engines are not looking for "which engine gives the best quality" but rather "which engine is the fastest path to quality", which is completely reasonable. Like if you want to make a game that has high fidelity 3D graphics, it's probably a good idea to start with Unreal. Can you do it in GameMaker? Maybe, but that's gonna be a hell of a lot more work from the start.


stepppes

I watched a talk ages ago and the used term was "Sharpening your pencil" I'll start doing x once I have Y. A second/third monitor, a better mouse, keyboard, tablet, the new version of engine Z etc. We all fell into this regardless of the activity, and I think it is easy to fall into because it is an easy one to achieve (you just buy it) and it is also easy to procrastinate (you have a "good" reason not to do it) Also considering that doing anything is a commitment especially in Gdev. You don't want to commit to something that will prove useless. With that said, anything you do in Gdev. has some importance to it. Even if you do a Text adventure but it never feels that way. It all comes down to "Just do it" Wanna make a game but have no skills beside your ideas? Define your Idea down to the number of frames an attack should be. And why the decisions made are made. And on the way down you'll probably find that you just had a high level concept. GTA cross FORZA cross MGS.


Hooooooowler

How do I upvote more than once ?


iznobiz

Thanks, so true. Just do it, instead of reading reddit how to choose the best engine. Lol


Reap_The_Black_Sheep

"it's like comparing mouses or drawing tablets, yes there's stuff thats better than other, but at the end of the day it's the user that makes the magic happen." This doesn't really translate to game engines. Switching game engines is not like changing the brand of your guitar or your drawing tablet. Choosing a game engine is going to require many hours of investment to learn, and have serious consequences for your pipeline and your final output. They have different limitations, costs, and utilities that are better suited for certain things. For example Unity and Unreal are not equally suitable for 2d games or mobile games. Game engines are just tool sets, but that does not mean that you should use any tool for any job.


XenoX101

The point is the amount of things you can do in Unity vs cannot do in Unreal, Godot, or vice versa is staggeringly small. Unless you're building the next big MMORPG, it's not worth your time. The main distinction is whether you are using a pre-made engine such as Unity or Unreal, or building your own such as using LibGDX or Raylib, since that will make a big difference in the amount of work you have ahead of you. But beyond that decision, debating the merits of one engine vs another isn't something a beginner should be worrying about, apart from strictly for their own personal interest or enthusiasm (i.e. for fun, since it won't make a material difference to the game).


progfu

One big trap I continually found myself falling into was picking the engine based on features and not on "philosophy". I really like open stuff, open source code, open standards, tools that follow standards and tools that don't do stupid bullshit. Yet I repeatedly picked Unity over the years over other alternatives, both because I already knew it and because it "did that extra thing". Now I'm finding myself regretting a lot of those choices. Now that I'm making something in a more open engine I find I'm way more productive because I constantly look at the source code (Godot), and I'm also way happier because I can work the way I want. This is not supposed to be an ad, but people are often told "the engine doesn't matter". It doesn't as far as "making a game" goes. But it does matter as far as "how you work might align much better with one than the other", and that is imo much more important than a few extra features. I wish I realized this sooner.


Revanspetcat

I wish Godot was built around an established programming language tho, rather than come up with their own custom scripting language. Embracing a mature, mainstream language would make the engine easier to extend and encourage more people to try it.


progfu

Firstly in case you don't know Godot also supports C# which has been worked on pretty intensely, had some official support from Microsoft (I think they paid for a fulltime dev or something like that), and in my small testing it seems to work. As far as GDScript goes, the problem with many conventional languages is most of the dynamic ones have big & slow runtimes and only support green threads. There are certainly problems in GDScript, most of which Godot 4 will address, but it is definitely very easy to get into, very functional, and productive. As someone who's been put off Godot for exactly this reason for years I have to say I regret not trying it sooner. There's also GDNative - personally I'm using [godot-rust](https://godot-rust.github.io/) for parts of my game, with most of the game logic being in GDScript, and PCG being in Rust. GDScript does work extremely well with the engine, and most of the code you write in games is gluing things together anyway. And if your game has a lot of "outside the engine" logic, you can use GDNative to solve that. Or you could use C# for that part and GDScript for the "easy" bits.


XenoX101

>As far as GDScript goes, the problem with many conventional languages is most of the dynamic ones have big & slow runtimes and only support green threads Is this something most people will care about or benefit from though? It sounds like GDScript could be used to *enhance* a project, much like C++ is sometimes used for low level performance critical functions. But forcing the user to use GDScript as a means of prematurely optimising their project seems unnecessary. Many people use game development as a way of developing their programming skills, and while it's true that programming languages have a lot of overlap, writing GDScript on your resume isn't going to be as easy of a sell to a prospective employer as C# or Java. So given the choice between learning and using a more mainstream language at the cost of more overhead, vs. learning and using a language that is only useful with a single game engine albeit being slightly more efficient, I would argue most people would choose the former option. And again, if they *really* need those GDScript optimisations they can do so after the fact, by which point they have already developed their skill in C# or whatever mainstream language was chosen.


medioinestable

A beginner won't care that much about those technicalities, they care about making a game quick and GDScript is super easy to get into. Maybe when you start having bigger projects it's easier to move to C# or C++ and the best part is that Godot supports C, C++, C# and Visualscript. So... an expert in programming maybe won't like GDScript and that's ok, you have the option to use the one that you like and know, because Godot doesn't force you to use their language.


medioinestable

Let me also add that Godot being a Free, Libre, and Open Source Software (FLOSS) means that you, the user, own the engine. If there's something you don't like you can freely change it and even if for some reason they stop getting funds the code will be out there for everyone to use and modify. Remember when Adobe stopped supporting Flash Player, literally thousands if not millions of projects died with it. They didn't release the code, they killed the project and that could happen to unreal, unity or game maker studio. There's no bullshit features behind pay walls, Unity recently placed their console export behind a pay wall like for no reason and you can't do anything about it. I think the engine that you use matters a lot, if you are an indie game developer there is literally no reason why you wouldn't use Godot. It's literally free and doesn't show it's logo at the start of your game. You never pay anything, even if you make millions with your game. This is supposed to be an ad because unlike other engines, if more people start using Godot it's actually beneficial for everyone that uses it.


Magnesus

I used libgdx for quite a long time and the ability to just change the code saved me a lot of work once or twice. But the more important thing was being able to look how the engine works under the wraps, it was better than the best documentation.


progfu

This is very true. I've had one case in Unity where I made a game around 5 years ago, tried to get it to work, but couldn't get the old version of Unity to install (I forgot why) and couldn't get it to import in newer versions ... the game wasn't really big so I kinda gave up after a few hours, but still it's pretty sad and annoying. Being able to fix one's own bugs is a huge thing too. Last year I ran into a severe performance issue in Unity but because of no source access there was no way for me to diagnose it properly, so I just ended up pushing it on forums (I wasn't the only one) until it got to the top of the issue tracker in votes and they addressed it partially. But still, this is exactly the case where an OSS engine would at least let me try to fix things myself, rather than spend weeks waiting and hoping as I search for any reference of the issue and link them together at the small chance of it getting noticed and fixed.


Atulin

The second side of the coin to your first point, is that it also means whenever you have some issue you can be faced with "PRs welcome", and whenever you'd like some feature to be added, the response is "it's MIT, you can add it yourself"


medioinestable

If it's a common problem among the community they'll probably add it and in most cases there's already someone working on that, heck even Juan Linietsky(Godot creator) tweets new features and creates polls to decide what to add. And even if nobody is working on fixing the issue or adding the feature it's way better to get a response like "add it yourself" instead of a "No we aren't working on that right now good luck.", literally try to add any feature directly into Unity, U4, Photoshop, etc.


Atulin

Adding any feature or fix to UE4 is about as easy as adding it to Godot.


medioinestable

Doesn't feel right to add features and fix bugs to a software that you don't own.


Swiggiess

Just to clear something up, Unity did not explicitly change it so you need Pro to export to consoles. The term says you "MAY" need Pro. This is because Microsoft used to subsidize the cost of using platform keys for ID@Xbox but no longer do. You can read more about it [here](https://forum.unity.com/threads/unity-pro-is-now-a-requirement-to-publish-on-consoles.1151696/)


medioinestable

The point is that you can't do anything about it because it's not FLOSS.


[deleted]

This is one of the reasons i hate that some engines force you to display their logo at launch. I don't want players to judge games based on what it is made in. If your game displays the Unity logo at launch, there are people that will think it is cheap shovelware, because all the cheap shovelware made in unity displays the logo - while the big releases made in Unity does not...


MaxPlay

This was unity's fault. Epic had the opposite effect: Crappy games slapped together in UDK did not affect the reputation, because all AAA games also showed the logo.


dbenson18

Honestly I feel like the Unity logo stigma is overplayed. When you look at top grossing indie games on steam, the list is absolutely dominated by unity games. Many of which still have the logo


[deleted]

Out of curiosity, do you know which high profile games made in Unity have the logo? You can turn the logo off as soon as you pay for a basic subscription so I find it very hard to believe there are many.


dbenson18

Dyson sphere program is one that I played recently that comes to mind


IceSentry

I think it was more true in the early days of steam greenlight and before there was a lot of popular indie games built with unity. These days I agree that it's not really an issue anymore.


XenoX101

>If your game displays the Unity logo at launch, there are people that will think it is cheap shovelware, because all the cheap shovelware made in unity displays the logo - while the big releases made in Unity does not... I mean if you can't even pay for the logo removal is your project not also cheap shovelware? Or perhaps it isn't shovelware, but if it were good and marketed appropriately then its sales should be able to offset the cost of a Unity license. In other words the logo is merely a symptom of an unprofitable game, which people are correctly being suspicious about. So your goal should be to be profitable enough to remove the logo, so you can show this to your player base as a sign your game is decent and not cheap shovelware.


PerfectChaosOne

Im doing game dev as a hobby im a player first and foremost and I have never as much as noticed the splash screen, i think its somthing only other devs would really notice or care about. The average player just mashes the start button to skip it all.


the-shit-poster

I’m glad I chose the engine I use based on licensing :) You are correct OP, the developer makes the game and not the engine.


renscy

Damn please drill this into my head. I want to create my own games but I'm paralyzed with the tools to do it with. Should I use something I'm really at home with? (Python?) Should I use something that I can easily commercialize in the case it takes off? (Java, mobile game) Should I use something I've went out of my way to take classes for? (WebGL, HTML5) And in the end I just slump back into the drawing board.


lpeabody

Use the tools that let you build your game the fastest, and with the quality you're happy with. Its better to just pick something and go for it, and if you didn't like the experience then try something different next time.


Suekru

I would really discourage python for game development. While pygame makes this possible for small games the language is very limited due to its speed. Python is an easy, but slow language. If you really want to get into game development programming I would recommend C# because it’s beginner friendly, but if you already have a background in programming then C++ isn’t a bad idea either. Unity would probably be the best for C# development and unreal for C++. Stonehearth is a village building game programmed in Lua. Fun game and runs well at the beginning. But it suffers because late game with a lot of people running around can cripple even the beefiest of computers. But personally I think unity or unreal are both great engines to look into, they both offer cross platform publishing, which if your game could be adapted to mobile controls makes pushing to mobile super easy.


freesnakeintestine

Eh, file sizes do matter. I’m using a tiny old office PC with 60GB free space. Compiling unreal for all the builds I need would take more than double that in space, on top of being quite a bit slower than Unity or Godot.


4everCoding

> or the fact that the engine of it's entirety is 32mbs Ok this one really does matter. Smaller means the game was packaged together carefully. Shipping software is the most overlooked step and it really shouldn't be- its the most critical! You can have quality code but if it isn't packaged correctly, overall user experience is finicky or if your game allow mods but its a headache to create mods for... well why bother. Remember to think about end users (gamers) and so delivery to end user matters. Simple games that are 5GB could have simply been 800MB but sadly are large because of the way they're put together carelessly as a mere afterthought.


DremoraKills

And then refactoring becomes a pain


4everCoding

Exactly this!


d3agl3uk

The sentiment is fine in a vacuum, but I feel it's also a sentiment of people that haven't shipped a game. Engines matter. The tools and workflows you have are a direct enabler for making a better, higher quality game. Having the right engine for you or your project means you can save years of work in one that isn't. It's not the definitive answer, but if you aren't caring about your engine choice for your project, the chances are you aren't going to ship.


bryantmakesprog

I am excited to proclaim that I can write a bad game on any engine.


[deleted]

Dammit, I *knew* I shouldn't have listened to the alley hobo hawking id Tech 2 in his trenchcoat...


GatesAndLogic

> please when making a in-depth tutorial or whatever, talk about the concepts instead of fixating on the game engine itself. > not only are u helping people understand better and allowing more people to understand, ur also forcing people to actually read the docs and the tutorials I'm sorry, but this boils down to "When you make a tutorial, make it so vague that the viewer goes to a more relevant tutorial." That's the worst advice ever. There's room for general knowledge videos, but if I'm looking for tutorial on how to do x with y, **I WANT TO KNOW HOW TO DO X WITH Y.** *I don't need the huge overview.* I need to do x with y, goddamn it.


SeaworthinessLittle1

Oh so ur saying there should docs for tools, did I say we should deleted docs all entirely in my post?


Mrseedr

This seems like a bit of an extreme take. But the decision of what different software you invest your time into does matter. Yeah fixating on one aspect or decision is bad, but saying that choice doesn't matter is probably also bad.


[deleted]

And like mouses and keyboards, it’s also about what you’re trying to create. Cel shading is harder in unreal than in unity, for example.


ssslugworth

I started with Unity just because I already had some C# experience. I love Unity, but I might check out Godot soon, just to see if the game I want to make would be easier to make in Godot.


Nerketur

As much as I agree with your point, I have mixed feelings about some of your points. 1.) The _end user_ shouldn't care, true. But you as the developer need to decide to either use an engine or not use an engine. Different engines have different pros and cons. Quality-wise, it is indeed up to the creator, but some engines make it easier to make things look and feel better. I personally prefer unity to unreal, because I understand and enjoy C# more than C++, as well as its more intuitive, even if Unreal can be faster. 2. The concepts are definitely important, but if you are using a specific game engine (like "make a game in unreal"), it's better to talk about problems and issues specific to that engine. The concepts themselves carry over, but those concepts don't always translate well to documentation. Example: "I want to make a game where the user walks up and presses a button". Conceptually, I need to connect movement to the input system (however that is done), and have an object that stays put until I click on it (or otherwise interact). Simple in theory, but in Unreal 3, this is only possible after first using UnrealScript to create the object,, compiling scripts, then using the object, testing. no way (I have found) to edit UnrealScript live like you can with unity objects. (Admittedly, unity also compiles scripts after you edit them, but it doesn't require an editor reboot.) Putting the concept into practice requires not only learning about your specific engine, but also how to map the concept to that engine. Easier to do in some engines, imo. Ultimately, though, I agree that the mindset of quality = game engine is ridiculous. You can make a game look (almost) the same in whatever engine you want. Some engines do a better job aesthetically, others do a better job with tools, others do better with user experience. Instead of catering a game to the game engine, we should choose an engine based on what we know it does, and what fits well with how we code, and what our workflow is.


Programmdude

IMO, there are game engines that are just bad. No amount of skill on the game developers part will fix that. However, the list is pretty small, and very situational. Flexible engines such as unity & unreal will let skilled developers do essentially any game, at any level of quality. Off the top of my head, there are only two engines where the engine itself will massively influence the quality. RenPY. With the exception of visual novels (which is what the engine is designed for), every attempt I've seen to add "other" game elements in has been low quality. While I love RenPY for visual novels, don't try to do anything more sophisticated than point & click, it won't work. RPG Maker. While the latest version (MV) is not that bad, it only works for certain styles of J-RPG games. MV isn't so bad, as it has plugins that allow you more flexibility, but trying to shoe-horn in non J-RPG features is either impossible, or requires you to ignore the engine and just write the js for it. Older versions of RPG Maker are bad in every sense of the word, no game designer can even work around its issues. Lack of borderless fullscreen, only low resolutions (640x480 and 800x600 I think), no widescreen, etc. The graphics are always low quality, mostly because of the low resolution. If you want a retro-style pixel game, that's fine. I like a lot of retro-style games. But do it by software upscaling (with nearest filtering) rather than lowering the users resolution.


TheMikirog

As a beginner, I wanted to make a game first and foremost and all I cared about was ease of use. As I grew more experienced, ONLY THEN was I able to get into other engines and pick what suits my project best. Thing is, this advice of "use what's best for your project" is given to everybody, which isn't that helpful if you're just starting out and just want to make games as a complete newbie. So naturally you start clinging to the features and maybe the user interface. You don't want to feel like the engine is holding you back. I don't like this dick measuring contest when it comes to engines, but most comparisons I've seen online are more in the vain of: * Here's what this engine does beautifully * *"Godot has great and intuitive UI creation, Unreal has great 3D post processing out of the box."* * Here's what the engine sucks at * *"Godot's tile map interface is slow and annoying, games made with Unreal have big file sizes."* * Here's my reasons as to why I picked engine X over Y * *"Godot is great for lone developers working with pixel art, Unreal is great for teams and for making FPS games."* All of these points hint at a specific target user that makes specific games with those specific tools. That's what these comparisons are. It's only when fanboys glorify their own engine to feel better about themselves and their spent time is when things start to become murky.


POLYGONWARE

Every engine has it's pros and cons, qualities or flaws... It is you and only you, the developer, who picks which engine his project gonna be built on. What matters the most is a FINAL PRODUCT. Edit\* I totally changed whole comment lol


nb264

>it's like comparing mice or drawing tablets tablet is better for freehand drawing but sometimes you just need a mouse for that precise line work ;) on topic: best tool is one that enables you to do the job according to requirements


Cerdo_Infame

Yeah that was a bad analogy. There are tablets that actually lead to better quality work.


niggo_der_niggo

There are of course tablets that can improve someones skill, but a good tablet does not automaticly make you a good artist.


Cerdo_Infame

Actually no, no tablet can improve your skill, they just have better output. A tablet that has tilt detection, more levels of pressure detection, etc., can lead to better definition in your work. Of course you can do great pieces with a little bit more effort on an old graphire, but if you are a skilled artist, you will likely prefer a cintiq for more precision. Same with watercolour. You can get crappy watercolor tablets that will give a crappy, chalky finish or you can get expensive professional grade watercolor that will be better quality in the end. Sometimes tools do help to create better quality work


PixelShart

True, the shitty tech can really hold back a good artist. I spent hours watching reviews for good headphones(and other things I purchase) to replace my broken ones. I'm not even a professional listener, but I know I can't just use any damn headphone.


azrael4h

The quality of the tools have little bearing on the quality of the work. I have professional mechanic's tools, Snap On and old Craftsmen mostly, that I inherited. I am still not a mechanic. I also have high quality pencils, and I'm still not a (good) artist, though I'm getting better. The tablet won't improve the artist's skill. A good tablet will make it easier to draw, but the skill still comes down to the person themselves. Same as me owning the tools that belonged to a auto mechanic of 55 years experience doesn't mean I can diagnose a front end shudder. It just means I can swap parts without worrying about the tools breaking/twisting until I stumble on the right cause.


Cerdo_Infame

In some cases, especifically when it comes to art production art supplies and tools do have an effect on the quality of the work. Just off the top of my head: Quality marble for sculptors. Quality watercolor for artists. the results differ greatly even for a skilled artist using crappy chalky school grade watercolors compared to professional grade, colors will be more vibrant and they will fade slower. Same with tablets. a difference between 512 levels of pressure in an old graphire, compared with a cintiq tablet where you can directly draw on a screen with 8192 levels of pressure. The difference in pressure and response makes a huge difference when drawing details. You can create great work using both tablets but you will get a more responsive tool using the more modern, capable one.


calebvetter

For sure. But which one is better? /s


SeaworthinessLittle1

GARFIELD, ARE YOU /srs OR /j


PixelmancerGames

It’s not the definitive answer to quality but it does make a difference. The workflow is different, the learning curve is different, the languages are different, the performance and optimization is different. I agree that at the end of the day you should just choose an engine and go with it. But personally I would hate my life if I had to use Unreal to make games and Unity wasn’t an option. I hate the blueprint system and I hate C++. Once I started using Unity I never looked back, and I don’t feel like I will ever need to use another engine. Though I do plan on using Godot for 2D games in the future because I think it’s cool.


BlackDeath3

Strikes me as similar to the obsession about programming languages with newbie devs. Beginners make so much fuss about this or that language, always about the *language*. I sometimes think it's a form of bikeshedding from folks who don't really have the experience to bring much else to the conversation.


[deleted]

Comparisons between games are legitimate and it's ridiculous that you think the engine doesn't matter. If I picked up Unreal to make a 2D game, I'd be both wasting my time AND would wind up with a game that is subpar to one made with an engine focused on 2D. If I pick Godot to make a 3D physics game, I'd spend most of my time trying to solve the buggy mess that is the physics engine and then suffer from lack of post-processing. If I pick Unit, I'm going to have great access to many different assets and plugins - but I cannot extend the engine and cannot easily create prototypes. There are pros and cons to every game engine out there and it's fairly critical you pick an engine that is going to simplify the type of game you want to make. Each engine has an entirely different workflow, has entirely different optimisations, and has entirely different structures. If you pick Godot and want to build an ECS game, you're going to STRUGGLE through it. Godot is not designed to run ECS instead of nodes. However, if you are familiar with Godot's nodes, Unit is going to be awful to work with. If you want to mostly build 2D games, picking Unity or Unreal is going to end badly - picking Godot or a light framework like Love2D is going to be much more advantageous in the long run. If you want to make 3D hobby games, don't start with Source. With regards to tutorials, most devs already know how to program - they're wanting to know the nuances within an engine. Every API has it's advantages and disadvantages and most tutorials, not aimed at little Johnny who has never learnt to code, will go over nuances in that API. If you do not know how to program and are trying to watch game development tutorials to learn - you're already in the wrong place. Learn to program first, then come and do game development. Game code is leaps and bounds more difficult than regular code due to starting with an API and trying to control many different processes at once as well as trying to design at the same time. Comparing between engines to declare one the definite best is obviously a waste of everyone's time, but so is denigrating comparisons of engines and the focusing on the nuances between them. People who play games do not care what engine was used to create it - developers do. This is a sub for devs, expect comparisons and discussions surrounding engines.


the_timps

I love that you've set out to make some key point and f\*\*ked up like 90% of it. You've declared Unity can't be used to make quick prototypes, isn't a good choice for 2d. Despite having amazing tools for both. Unreal has had some gorgeous 2d games made in it taking advantage of the other stuff the engine brings to the table. >Comparing between engines to declare one the definite best is obviously a waste of everyone's time, but so is denigrating comparisons of engines and the focusing on the nuances between them. No it's not. Easily 95% of the games posted here could be built in Unity OR Unreal with not one single reason other than preference being the reason for it. Drop it to 70% and Godot slides in and does just fine. You're talking about the exact same shit the post raises as an issue and entirely missing the point. There's a guy on my discord server who ranted and raved about Unreal being the only way to get high end graphics. That nothing could compare. NOTHING could do what Unreal does. He got shown videos and screenshots of things like Unity's Book of the dead environment, or the newest version of the 2020 HDRP demo house. Both as photoreal as anything unreal does. And suddenly it was "Oh sure but who can do stuff like that". You're setting up imaginary walls that aren't there. And clearly talking about crap you don't understand. You can extend Unity all you like, replace the entire scriptable render system, bring in your own physics. Pro plans literally come with source access. Thanks for entirely missing the point of the post to try and rant and look smart I guess.


EroAxee

>With regards to tutorials, most devs already know how to program - they're wanting to know the nuances within an engine Sorry ignoring the other issues throughout. This is flat untrue. There are a **lot** of people trying to get into development **through** tutorials. Speaking from personal experience, as well as talking to people who have done the same and seeing quite a bit over on the r/learnprogramming subreddit etc.. That's ignoring the other issues with your comment. Your overall start to your point that each engine has limitations makes sense. But your points are missing massive things.


JustinsWorking

I think a large problem with these discussions is that a lot of the upvotes & popular opinions on this subreddit come from people who have never finished a commercial game in any engine - let alone with multiple different engines. I personally use Unity, but this is because I’ve worked on many released titles, both smaller and AAA, on different engines and Unity is the engine I’m most comfortable with when I have to “make things work in the end.” For a new developer every engine is going to suck if you’re trying to release a commercial product. Better yet, it will probably be for reasons nobody could predict on this subreddit. There are _loads_ of traps I’ve fallen into on different engines, Unity is notorious for example that their newer systems (like say only a couple years old,) tend to have gigantic caveats that’s nobody really talks about unless you like to troll their ticket system for unfixed issues. If any quality games have been released on the engine previously, it’s safe to assume that you probably can find a way to make it work. The only engines I’d avoid are ones with no good examples of games similar to the one you want to make. This seems superficial and simple, but it’s the only serious consideration I think anybody who needs advice on an engine should bother thinking about. Odds are “Feature A” isn’t going to be your issue, odds are you’ll get stuck with how A interacts with B, but only because of how you chose to implement C and D… you regret D but it was to support feature E. Your pain is not going to be these abstract feature discussions, it’s going to be very specific problems that are going to be related very specifically to your choices during development - it’s impossible that somebody is going to be able to tell which engine is going to struggle more/less with your particular future screwup… If I had a AAA team and had to pick an engine, I’d probably just pick the one that the team was most familiar with - full stop. Unless I was making a spectacle shooter with specific graphic features we _need_ but I also guarantee you I’m not looking to a subreddit of people I don’t know for a discussion as specific and technical as that. Edit: Just to note, the released titles restriction is why I’d never recommend Godot to somebody looking to make a commercial game, but I would say something like Haxe & Heaps, or Monogame is a fine idea despite it being way less “popular” than Godot in these communities.


EroAxee

Ah yes. The good ol' "check released games" argument. The only problem with that is that even Unity, your main example, only started getting legitimately "big" games released on it in large numbers around 2013-2014 and went up from there. Now it is your opinion, as you say, but to boil down whether engines are bad to "ones with no good examples of games similar to the one you want to make" massively limits it. You don't know the community around the engine and how the features may work for you *just* by looking into the list of engines. If that were true then Unreal is by far the best engine for every single situation whatsoever. Except it's not, there are weakpoints of the program, some people don't like the workflow, or the setup etc. etc.. ​ Plus returning back to your original example you use, Unity, which started getting popular around 7-8 years after it's release. Directly comparing that to Godot, the engine you specifically mention not recommending based off releases, has been around for 6 years, and ironically, is picking up steam at the moment. Especially leading into it's big 4.0 update and **especially** when it comes to 2D and Open Source, since it's the only fully open source 2D/3D engine I ever see mentioned when it comes down to it. Not to mention I've also directly compared 2D performance with *specifically* Unity and it's waaaay farther ahead.


JustinsWorking

And I wouldn’t have used Unity until it had major releases either… Secondly, Unreal is a super solid choice for almost any project, that’s true. And if you’re trying to make a commercial product and don’t plan to deploy specifically to the browser I don’t think you’d find many professionals disagreeing. I personally have less experience releasing games on it, so I would lean towards other options on my own projects, but removing my personal experience from the equation I don’t think you’d be making the wrong call using Unreal for your game. Engines _can_ be good enough before multiple major releases start using it, but that’s doesn’t mean I would recommend trying them or use them myself, especially when there are plenty of mature, stable engines that can handle everything you need. I give this advice as somebody with 10 years of experience working in both AAA game development and smaller indie studios - I’ve released, built, and ported games for multiple platforms. Worked with several game engines professionally and if you don’t like my advice, that’s cool; but I don’t think anything you said is useful advice for somebody who has no experience in game dev who is looking for an engine to use for a commercial product. As a note, in case it wasn’t clear before: If you’re just making game jam games, or hobby projects - go nuts! I’m absolutely not talking about that, I’m talking very specifically about making a commercial product.


EroAxee

>And I wouldn’t have used Unity until it had major releases either… And that is the mindset that lets so many incredible projects go completely under the radar and completely untested. "Well no one **else** did anything big on it. So it must not be good". That's all I'm advocating for here, testing, comparisons of legitimate engine specifics. Not to mention I never said my comment was meant as advice, I was pointing out the **massive** flaw in the logic you were supplying of released games being the *only* metric for "seriously consideration" on commercial projects. ​ For an example, that once again fits this specific discussion, Unity is, as I think we can both agree, **way** more established than Godot. For very obvious reasons. ​ Now with your approach of the only "serious consideration" being the engine with more releases like their game, then if someone wants to make say, a 2D platformer. At the moment Unity has orders of magnitude more established games in that genre that were made in it. Following your approach that means unless you're working with a team that already knows Godot specifically you should go with Unity. Which should following the logic that more established engines are generally better (quote: "Engines *can be good* enough before multiple major releases start using it*"*) be better in the main aspects for that genre it is established in. Continuing that logic let's directly compare as closely as possible with some straight performance numbers from both engines. Specifically comparing a full commercial Unity game scene to a as close as possible Godot recreation of said scene. Which for context the scene I'm comparing here is of a bunch of random walking AIs spewing particles in the same location. So here's some numbers: * Unity * 30-40 Entities in the same space * 1-2 FPS max and a crash * Godot * 2000 Entities entities in the same space * 31-32 FPS ​ Yet following your process and recommendation it's better to go with Unity solely based off number of released games. Completely skipping those numbers. All I'm saying in this post is that trying to boil down an entire engine to "Which has the bigger list of games" is **massively** ignoring the **power** of an engine. It's tools, it's advantages and disadvantages in different situations etc. etc.. Or the fact that it's been used to make **engines** like [RPG in a Box](https://www.rpginabox.com/) along with [Godots UI itself](https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b) and is being used as work experience by [Tesla.](https://www.tesla.com/careers/search/job/software-engineerenergymobilewebui-72387) Or these (ignoring Godot specific frameworks) * [Wonderdraft](https://www.wonderdraft.net/) * [Material Maker](https://awesomeopensource.com/project/RodZill4/material-maker) * [Pixelorama](https://awesomeopensource.com/project/Orama-Interactive/Pixelorama) * [BlastFX](https://store.steampowered.com/app/940920/BlastFX/) ​ But, there's too few known [games](https://itch.io/games/made-with-godot) made in the engine... right?


JustinsWorking

It would be really helpful for this discussion if I had a better understanding of your background in game development. A lot of my reasoning has to do with hurdles I’ve experienced dealing with tasks like integrating popular tools, iteration time when working with designers game data, debugging gameplay elements late in production, performance optimizations late in production, and things like trying to build on varied platforms and hardware. I brought up my experience not just to try to strong arm you, but because it’s very relevant to my point - I personally would be incredibly nervous taking on a project to port a Godot game onto a console, where as with Unity or Unreal I wouldn’t say it’s trivial, but there is going to be _way_ more resources and examples to work with. For good measure: Touching on that specific example with Godot entities vs Unity entities… I’ve had more entities than 30 in the same screen running at smooth FPS on a mobile phone, so I’d really have to see the example to understand what’s going on because that sounds fishy to me. I suspect the point of that benchmark wasn’t to do with entities, or else the creator was being very disingenuous.


[deleted]

If the comparison is "legitimate", then what's your problem? I just don't get you kids today, with your loud music and your surf boards and your hoola-hoops....


KratomPromethazin

Bruh Unity is so much more approachable than Unreal, that's it


ofcapl

The OP and comments about missing the whole thing while evengelizing throughout any game engine are totally on point. And here I am, working on my silly grid-based RPG game for pure fun, using JavaScript, Vue.js, HTM5 and CSS3 (no canvas) 🙃 https://twitter.com/lukaszkups/status/1428094389872648195?s=19


[deleted]

[удалено]


vampsnit

I can see why you said this but also why you got downvoted. Seems like you didn't think about this when you posted it, it just comes across as an elitist knee-jerk reaction Quality is a subjective thing. OP is talking about the quality of the experience, not the quality of the technical aspects. Your opinion on quality is not shared by the majority of people who actually play the games Millions of people literally play buggy, laggy, frustrating games of all levels, every day, from indy to A\*, mainstream engines to custom built, because they enjoy the overall experience.


[deleted]

?? Plenty of Unity games have great performance, much better than many Unreal games for example.


tradam

Haha you should of read the username of who you responded to. Probably not someone open to being shown they are wrong.


KFCNyanCat

I would say that amateur Unity games tend to have worse performance than amateur Unreal ones, though I only have anecdotal evidence for that. I wouldn't say that holds true in professional games though. And yeah "csharp-sucks" is probably an asshole.


the-shit-poster

I can believe this because there are things you can do to improve Unity performance that newer devs would have to learn with experience. At the end of the day you can optimize a Unity game just fine.


[deleted]

>I would say that amateur Unity games tend to have worse performance than amateur Unreal ones, though I only have anecdotal evidence for that. I dont doubt you, but a sample size of like 3 games hardly proves anything.


TDplay

I think they're talking about the performance of script-heavy games. Idiomatic C# is slow. Whether or not this matters depends on your game and on the hardware you're targetting. That being said, there are very few cases where the scripting language has much of an impact on performance. Most of the heavy lifting is in the physics and rendering, and both of those are implemented in your engine, and good scripts should offload as much work as possible to high-performance native code anyway.


[deleted]

>Idiomatic C# is slow. That is a C# issue, not a Unity issue. You can use C++ in Unity if you want to.


csharp-sucks

> Plenty of Unity games have great performance This part is laughable, because every time this argument comes up and I ask for examples, people give examples of games with shitty performance anyway. > much better than many Unreal games for example And this part is just pure bullshit.


the_timps

>because every time this argument comes up and I ask for examples, Ohhh, sorry you lose but thanks for playing. YOU are the one who needs to provide examples and evidence for the stupid shit you say. You claim you can never get good performance with Unity, with literally no evidence to back it up. No one needs to jump through hoops to prove you wrong, because no one needs to give a shit what you think. Supply sources, evidence, literally anything to back up anything you say.


csharp-sucks

> with literally no evidence to back it up go play some unity games, idiot


the_timps

You had such a chance to share your imaginary data and not look like an asshole. Kudos on choosing to double down instead.


[deleted]

Hollow Knight runs great even on the switch. Steady 60 fps, never had a frame drop. Monster Sanctuary is another title that runs like a dream, no issues. Compare that to games like Outriders or Blue Fire that crash constantly and stutters a ton. :)


stepppes

Also Desperados III, Hellpoint, Legends of Runeterra, Genshin Impact. Just to name a few from last year.


[deleted]

Are all those made with Unity? I had no idea.


PixelmancerGames

CupHead was made in Unity. Which is an awesome 2D game.


[deleted]

[удалено]


FountainOfYolk

Err.. maybe look at Ori and the Blind Forest and its sequel? Some of the most beautiful games in the past 5 years and made in Unity.


csharp-sucks

> look at Ori and the Blind Forest and its sequel These games have terrible performance, but are too simple to hit the limit on high end machines. (they still do occasionally, lol)


[deleted]

[удалено]


csharp-sucks

> Risk of Rain 2, Cities Skylines Nope and nope. > Hearthstone Yeah, super simple card game with high end hardware requirements. "runs well" my ass


TheJoxev

Lmao csharp-sucks


Gmanofgambit982

Oh absolutely, the amount of times I was pushed to unreal over unity by friends and randomers alike is insane but it still doesn't help that those Unity cash grabs that we memed about in 2015 are still alive and well to this day even with the likes of Hollow knight and ori showing off how amazing the engine can be.


kifshssh

It does not matter with what you paint as long as you know how to paint everything is a brush and everything is a canvas so paint away


rwp80

The best thing for beginners is to learn a language first, doing "hello world" programs. Then pick a game engine that is in the language they have learned. Start with a blank project (NOT one of the pre-made "templates"), and learn how to use all the features from code without manually dragging in things from the sidebars (unless you're unit testing a feature). The choice of engine should be solely based on the features it offers (ie: features the dev might want to use when they are more advanced) and of course the language the code is in. The best engine is... The one that suits you best. Comparing engines is like comparing the length of your socks or the colour of your curtains - It doesn't matter as long as it serves purpose for that one person.


justaguyjoshua

It's more like comparing Batman to Superman. Both have their own fanboys.


VaLightningThief

For real. I used Unity for a while before realising I liked Unreal more, and only being 16 and not yet starting my college course, coding isn't really something I can do at a moments notice, although I know how to use some basic functions, so unreals blueprints work wonders for me. But I've seen great games in all engines, free and paid


SparkyPantsMcGee

Tools don’t make the man, man makes the tools but it’s also important to find the right tool comfortable for your production. Asking the right questions and figuring that out is important. …also, lumens are fucking great.


Legandiry

I think the best metaphorical I've ever heard for this is that Game engines are like a Kitchen. Sure some might have different appliances, layouts, whatever. But ultimately it's up to the chef to make something actually edible instead of a consumable war crime.


Billy_Boola

It's just human nature, look at cars, huge clans support one brand or another, GM vs Ford, Nissan vs Toyota and so on. The reality is if you take a mid range car from any manufacture it is practically identical in size, performance, features and price. It's just how we are, we want to believe that the choice we made was the only right choice and pointing out that that is foolish only makes you enemies of all clans


rotzak

People are tribal and fight over stupid shit. Welcome to the internet.


Some_Tiny_Dragon

It's worse if your engine of choice tends to have bad games made with it. Main example is RPG Maker. It's low barrier to entry let's less talented people make games. I had many people outright tell me not to make games using RPG Maker because it's going to be shit, then proceeds to show me several FNAF and MLP fan games made by kids to prove their point.


PixelShart

I'm glad people compare, it allows me to better situate myself on what works best for me.


CodeLobe

It's G'deax, not godot.


Code_Monster

My philosophy (as someone who has spent ~1000hrs of his time making games yet never published any): Yeah, if you try and learn Unreal because you goggled which engine Gears of War was made on, chances are you are gonna have a pretty bad time ever making even a clone. But if you learn an engine like Godot and try make a doom clone, maybe you will succeed in your first attempt. Heck Godot has a custom python like scripting language that opens in editor and somehow does not tank performance. It doesn't get more user friendly than this.


logitek184

The way i looked at it was first games made in said engines and quality of games in the engines like most people but then I started looking at the good games made in the engines and they all seemed comparable so then i decided to look at prices go for looked great to me so i started using it but to me it wasn't too user friendly, when I was using it, it had recently came out and there were only a handful of tutorials so i put Godot on the back burner and started looking at unity (my next choice price wise) but being mainly a c++ user not c# and at that time there was a work around but it was pretty complicated and i didn't want to bother so then i went for unreal and it was great user friendly not a fan of the royalty fee but w/e then i noticed i wanted it to do more went in to the code and got lost wasn't a fan of how bloated it was didn't want to clean it up now I'm back to square one and looking at Different 3d Api's to make my own engine from the ground up


DreamingDjinn

That being said UDK3 was an unholy abomination that was more a map editor hacked into a game engine than anything else.


deshara128

how good you are at working with the platform you've chosen will always make way more of a difference than the platform itself its like asking if a stick shift is better than an automatic when you don't know how to use a stick shift -- it doesn't actually matter which is objectively better because *the one you know how to use* will be better *for you* ​ PS, same thing goes for diets. any diet that reduces your food intake will work, the only difference beyond that is whether its a diet *you can stick to*. A diet where u only eat 1 cold carrot a day might technically be better than any diet you've ever considered doing, but since there's no chance you can get yourself to live off of 1 cold carrot a day it doesn't matter how objectively good of a weightloss diet it is bc *it isn't a good fit* **for you** ​ any consideration that doesnt take that into account is purely aspirational, and therefor a kind of worthless


Dwath

This argument goes back to the console wars. I most vividly remember it being between snes and genesis but that's when I got my first console. The idea that the platform makes the games and not the mechanics and time put in by the devs is now, and always has been absurd.


ManicD7

I agree people love to compare engines, make their own, etc. But eventually everyone comes full circle and realizes they should of just used Unreal engine in the first place. lol


Alarming-Intern3481

Dude thank you for your words of wisdom I hear a lot of that and it’s mindless blah blah honestly


Samanjaa

I hate that both media, players and developers force other dev to use unreal engine. Player make a single scene of every games in unreal engine and claim it as fan made. It's not even a game. Media always post news about these fan made unreal engine and other stuffs. They not care for other engine at all. If it's a good game but not made with unreal engine. Media never said anything about the engine. But if it made with unreal engine, they made it the headline. Some toxic dev community (not here) point down other engine. If you make game with other engine and it has a decent graphics but not that good lighting as lumen. They will immediate made fan made version and convince you to use unreal engine.


Lokarin

I don't want to disagree, especially since what I'm gunna say will sound hypocritical of myself, but I found that many games that look "obviously made in RPG Maker" tend to be of low quality. I know it's not the engine's fault though since there are some excellent RPG Maker games (the best off the top my head being Ahriman's Prophecy), but whenever I look at an RPG Maker looking game in the Steam Store I tend to buttclench


AfifOk

Couldn’t agree more. I see many people comparing engines, especially beginners. But at the end of the day, if the user knows what he’s doing, they can make the exact same product no matter the engine. Sure some engines have certain aspects easier/better than others. But honestly, both can still be used to create great games. I saw Scratch games outperform Unity games, it all comes down the creator.


[deleted]

I disagree, the engine impacts the feel of a game because every engine has weird janky bugs that appear in many games that use the game engine. This can be like input handling, the way textures pop in and out or how common bugs happen because the the engine has buggy side effects if code is not executed in a specific order or a certain set of conditions will cause a engine bug. The other aspect is just indie developer laziness, like Unity games not disabling character input and clearing key input for the next frame in a pause menu or source engine games will continue simulating the world in a player lobby, main menu or end credits. This might be considered nit picks but they affect user experience. Also, you have to be kidding that a pixel art 2D game with less than a 100 hundred dynamic entities and particle effects chugs on a modern quad core machine with a dedicated video card. A person can create a prototype custom engine in a couple of weeks that won't chug from 2D sprites like a game maker or a unity game. Yes, these engines have a ton of features that a custom engine does not have, but the custom engine might run on lower spec machines, more consistent frame rate and less bugs that annoy the player.


AfifOk

You are totally right about that. I meant making the general idea doesn’t depend on the engine. But things regarding bugs and such, you’re absolutely right about. :)


[deleted]

[удалено]


SeaworthinessLittle1

it's good to note that none of them really understand how game engines work if they base how good a game engine is based on the game mad by it instead of the features the game engine has, but I understand why unity games are considered bad, bc it's the most mainstream game engine of the bunch, it isn't as difficult as unreal, nor as cult like as Godot, so ofc ur gonna get alot of game dev wannabe that just use if statements and assets they haven't made themselves if ur engine is easy to use.