I get pretty dismissive when I hear someone is designing a custom engine for their game. It often seems like they’re stalling for one reason or another, or have something to prove. Mother 4 is a good example.
I read tomorrow and tomorrow and tomorrow w my girlfriend. She didn’t understand why building an engine is such a bad idea (for a modern pc game). I compared it to a hobbyist car designer starting to design a car by formulating his own rubber for the tires, and building the engine and transmission and wiring from scratch.
I think it's wrong to be dismissive. Or rather, it seems to be the product of an efficiency mindset.
If your goal is to release as fast as possible or create as many games (for some definition of game) in your lifetime, then I guess there's a case against building your own engine or - as I would call it - using libraries.
But big engines definitely have distinct "feels" and can't quite hit certain gamefeels.
There's also the long view: What if I spend 5 years making an engine, learning gamedev and computer graphics, and come out highly expert with an engine built to my tastes? At that 5 year mark, suddenly my engine is better for me than the generic ones.
You may say - there's no guarantee! True. But what if I know I'm technically excellent and that I'd be wasted that advantage of mine by _not_ going that route?
What if I really only want to make a handful of games in my lifetime. Maybe I'll release smaller ones along the way as learning exercises, but I'm fine with spending 5-20 years in the dirt growing and come out the other side with something truly special?
Tools affect your art. Especially programming & gamedev which is so psychic. I may not want my mind tainted by engines with product-mindset values I don't agree with.
Eh, of you spend five years not telling stories, you will be woefully out of practice as a writer, with an underdeveloped craft. You are how you spend your time - spending five years on an engine means that there are a lot of things that you're not.
There's a list are great reasons to make a new engine, but making a great game is not on it.
You can do other things concurrently, you know. I find it not hard to both draw and write and make music along with the programming. Most knowledge and skills development in those areas happens subconsciously in my experience.
Viewing things like this as zero sum is a bad mindset imo and not one I want affecting my art.
It kinda sounds like martyrdom, or a monk or philosopher, pursuing enlightenment or, in this case, knowledge and expertise.
But like with any software development, technological self-gratification doesn't make a product. Every programmer loves writing code, but you need to be aware whether you're writing code for writing's sake or if it has an objective.
If you want to develop games, develop games; focus on results first, only when you've proven to yourself that it's games you want to develop instead of the technology behind them can you start to think about what the existing engines are lacking that your custom engine would do better.
It has the same energy as PHP developers from a decade ago that for some reason all insisted on writing their own frameworks, CMSes, etc.
You make your own tech in part because current tech doesn't satisfy your needs. One huge weakness of the popular 3rd party engines is iteration times. The author alluded to such. When you get to a point where a few lines of code takes 5 minutes to compile so you can test a small tweak, you quickly lose your motivation.
So I get it. These engines are made to help medium-large scale studios create high profile games, collaborated on by dozens, hundreds over a few years. An single dev doesn't need all that tech but it's tech that bloats down their iteration cycles. Especially if your goals are a small 2D game.
Thank you. For me, I like making engines. It’s my time off, I can do what I want. I know someone else will make something leagues better with premade engines. But it’s not a race. And I make many of my own art assets too. They’re terrible. I make these things for myself and to share with a few people dear to me. Maybe they makes me no more grown up than a kid hoping their drawing gets on the family fridge, but I want to create these things, not just produce.
If you're an indie dev working during your free time, then trying to produce a game with tools you don't find interesting will just result in you making a bad game, or never finishing it.
You'll learn a lot from writing things from scratch, and likely come out of that a much better programmer. This experience can lead you to making a more interesting game.
The difficulty of writing a custom engine is also overblown, you don't need to (or should) implement a general purpose engine. Just implement exactly what you need for your game.
Anyways there are plenty of recent examples of very successful indie games using custom engines, often from a single dev or small team. Sure you may be able to get your game finished faster with Unity, but there are thousands of garbage Unity games on Steam, you can always add one more to the pile.
There are two types of game developers: those who spend their time making tools to make games and those who spend their time making games. So really there is only one type of game developer.
Really depends on what you call those devs who makes a living off of asset store tools. It seems a but gatekeep-y to just call them "software developers".
Seems more comparable to using a framework like Rails or rolling your own. Both can be valid decisions from a business perspective, depends on the situation, what you're trying to build and what kind of team you have.
As a guy who started 14 games (most with a custom engine, some not) and released none of them, I think both approaches can keep you from shipping in their own unique ways if you're not focused enough on _what_ you're building :)
I disagree. in some ways it's inefficient, but there's a homogenization of game engines (UE) which makes a lot of AAA look the same with similar performance issues like shader compilation
That's a false narrative, game engines don't create games that look the same. Actually one of the funny propositions (not serious) that a fellow game developer had on social media was to instead replace the default game engine logo with a custom one, just to avoid this narrative that gets repeated. Outside of asset flips, most people can't tell which engines create which games without that giant logo alerting them. Then it creates this bias of "oh yep that's a unity game!"
Shader compilation has more to do with dx12 than it does game engines. Game engines try to encourage developers to handle this appropriately, but there is no one button automatic handling yet. You would also run into this issue in your custom game engine unless you avoid vulkan/dx12 entirely.
I have no scientific basis for disagreeing, but from my own experience, I can definitely tell with >50% accuracy whether a game was build with Unreal or Unity, especially for indie games. For Unity it's something about the materials and lighting that seems to give it away, for Unreal stuff like over the top focus effects and such.
Technically, from what little I know about these I don't see why you couldn't make a game look exactly the same in both. But I guess what's easy to do and what the respective community commonly does have a notable impact? Or maybe people self select for one or the other based on what games that align with their sense of aesthetics use one or the other?
One of the great things about both Unity and Unreal is that both engines let you get a basic project up and running quickly. Throw in a cube, give it controls and movement, and build a little level, and things basically work. The game engines have handled physics, lighting, shaders, camera, etc without you needing to touch them.
The tipoffs you are detecting are those game engine default settings. One distinction between them is that Unreal has motion blur, camera aperture effects, and some fancy lighting configured by default. Unity is more "basic" by default. For small projects, a dev is focusing on other things rather than pouring a lot of energy into how light reflects off surfaces or whatever. Each engine is capable of really unique looks, but they also look pretty good even if a dev doesn't touch it.
Yeah most of it stems from the asset marketplace. If you look at Unreal's marketplace or Unity's asset store and sort by top seller (and especially the free categories), you'll probably find exactly the things that you're talking about. From particles to sounds. Great resource, but a lot of developers don't really customize them much and they tend to be the things people are noticing per engine.
You are on the money regarding self-selection as well. A small team is probably going to pick Unity due to all the preconceived notions, and alongside this will probably create similar looking visuals to other Unity games due to a reliance on the asset store if their team isn't heavy on visuals. It might seem like I'm focusing too much on the asset store, but it goes for custom assets too where even if you're working smartly, you have to blend those premade assets with custom ones. If you're on a large team working on an Unreal game, it's probably going to be realistic looking for example so you're limited based on what lighting makes the skin look good, what particles make sense in a grounded world, and so on.
It's technically possible, you're only going to run into problems when you then try sharing assets from different stores (audio and textures excluded), where you now have to recreate it from the ground up to match in that other engine. So you're also right about that aspect!
As real examples of the flexibility of modern game engines, Octopath Traveller Yoshi's World, and Arkham Knight were made on UE4. For Unity; Cuphead and Escape from Tarkov.
As a player, Unity games seem to have some issues with stuttering especially on resource load (e.g. first time a new enemy type appears). It happens to a degree that is surprisingly bad, given the relatively low fidelity of a lot of titles compared to games of that past that ran better on worse hardware.
I recall Ori and the Will of the Wisps being particularly bad for this. It was unplayable when it was installed on a HDD, and when I moved it to SSD it still had major stutters during racing segments where the goal is to traverse the map quickly (and presumably, load a lot of assets on the way).
>game engines don't create games that look the same
sure they do. Like anything else in software, what defaults you set will drive the course for a lot of user behavior. You make a downvote button and users will start to use it to say "I disagree" or "I don't like this comment", even if you remind them everytime that the downvote button is not a disagree button.
Of course you can dig deep and change every default, but few studios in the grand scheme of things will bother if the default is good enough.
This is especially so with 3D games. 2D games has less of this problem, as you tend to rely more on the assets for art direction than fancy lighting or in-engine geometry creation and the default lightings for 2D stuff is simply your basic shaders with sprite textures.
I agree with you in spirit, but reality tends to show otherwise.
> I get pretty dismissive when I hear someone is designing a custom engine for their game.
Teardown [1] was developed by one guy, custom engine, and sold over a million copies. The technology is so unique that it wouldn't be possible to implement in an existing engine, at least not without significant rewrites.
I read tomorrow and tomorrow and tomorrow w my girlfriend. She didn’t understand why building an engine is such a bad idea (for a modern pc game). I compared it to a hobbyist car designer starting to design a car by formulating his own rubber for the tires, and building the engine and transmission and wiring from scratch.