Live data from Hacker News

Create your own Game Engine but don't use it

zeroequalsfalse.press

1–10 of 113 posts

Re: Create your own Game Engine but don't use it

#2
I think a lot can be said for someone trying to go their way, and learning the value of a prebuilt solution. A lot of people would stubbornly keep trying to build their own "because they could build better" rather than focusing on the end outcome of a playable product.

Re: Create your own Game Engine but don't use it

#3
On the other hand, I find my game engines, particularly (unfortunately) open source ones, are in a terrible state.

They often try to support many platforms, then it turns out they usually support one platform well, and the others are various degrees of broken. Then, when you want to get your game working on Android, the engine is too massive and complex for me to have any chance of figuring out how to fix it.

Re: Create your own Game Engine but don't use it

#5
I've worked with Unity from the beginning of my career as a developer. (Used to be a game designer and producer before that). I haven't quite understood what's so special about it before I tried other solutions, including open-source (Cocos) and in-house ones; turns out, a LOT of things that Unity devs take for granted (like asset pipeline and management) are lacking elsewhere.

Sure, a senior developer should be able to write his own game engine from the lowest level - but he almost never should actually do it on a real project.

Re: Create your own Game Engine but don't use it

#6
I think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling.

The reason the average quality is so low with Unity titles is because of just how easy the technical aspect of making a video game has become with modern engines. The barrier to entry for creating a game with AAA graphics is now a $20 shader pack and the ability to hack together some C# scripts.

Re: Create your own Game Engine but don't use it

#7
A year is nothing in the grand scheme of things. If you can't invest a year into building tools that could be your foundation for the next 3 decades, then what you are building is just a quick-rich scheme that doesn't matter. Use whatever you want because it doesn't matter...and your game probably isn't going to sell anyway. Those are the odds.

But as they've pointed out, you kind of need to know that stuff anyway, so it's time well spent.

I don't have a ton of gamedev experience, but at least graphically that game isn't doing anything you can't do in a few hundred lines of C++. Maybe that's part of their problem. Why use Java if you want to make a mobile game and it isn't well supported on one of your primary platforms? That sounds like a bad fit.

Unity and Unreal are super cool but they are also bloated with features that you don't need and lacking in others you do. For the longest Unity required you to use 3rd party modules for a camera. A camera....something that takes a few lines of code for a basic implementation. Why didn't that come standard?

If you really want to hurry to market yet another game by all means use one of the existing engines. It might even work really well. But if you want to do anything interesting, you're gonna be doing custom stuff anyway.

Re: Create your own Game Engine but don't use it

#8

A year is nothing in the grand scheme of things. If you can't invest a year into building tools that could be your foundation for the next 3 decades, then what you are building is just a quick-rich scheme that doesn't matter. Use whatever you want because it doesn't matter...and your game probably isn't going to sell anyway. Those are the odds. But as they've pointed out, you kind of need to know that stuff anyway, s…

>For the longest Unity required you to use 3rd party modules for a camera.

What do you mean? How can there not be cameras? How then can you view a scene without that 3rd party module?

Re: Create your own Game Engine but don't use it

#9
This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked.

The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be lacking compared to one developed by a team solely focused on making the best widget they can. I could write an HTTP server or a threadpool or a database connection layer if I really wanted to, but thousands of talented people have invested millions of hours in those tasks already, and I'm not likely to do better than them on my own.

Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. In my day job, I'm working on a (relatively) trivial problem that's never been done before, because there are about ten people in the world that need it. As a hobby I work on a text editor that is completely customized to my personal workflow, and which will probably never be used by anyone else.

Re: Create your own Game Engine but don't use it

#10
post #4

Interesting contrast to the Carmack school of thought: _do_ build your own game engine and don't even reuse anything you made before, because you'll know better this time.

Most of us aren't John Carmack, though. When you're the guy that basically invented the genre of code you're talking about, there's a very good chance that your next project will advance the state of the art. When you're basically a hobby coder looking to get an game in the app store, it's a slightly different story.
Post reply on HN