Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Create your own Game Engine but don't use it

zeroequalsfalse.press

Post reply on HN
Print view View original

61–70 of 113 posts

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

#61

Post by thehardsphere »

steeleduncan wrote: post #14

This blogpost gives the other point of view: http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f... Essentially that the engine you use can constrain what you create, so write your own.

I've considered a stack like that myself for less exotic looking games. It's nice to know someone who actually has gotten farther than I have is making similar choices and that those choices are working for them.

I think the choice boils down to project scope and the relative size and skill of the team. If a game of your scope is already well served by an existing engine, it makes sense to use it. If you have a large team with a particular skill set, it makes sense to cater to their skill set by picking the engine they know. For any other case, rolling your own makes sense, provided you know what the scope of the project is in advance.

The common mistake (that maybe the guys in the parent article also made) is that they assume "game engine" is some necessary prerequisite to making games, so they spend time working on all of these technical problems that are not actually their game they want to make.

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

#62

Post by emodendroket »

Koshkin wrote: post #47
emodendroket wrote: post #13

Earlier quoted context omitted.

Beyond that, it's not the 90s anymore; what novel feature are you going to implement that is going to wow anyone in the way that Carmack's engines did?

> what novel feature Ask that in 10 years; I believe there is always progress to be made.

Yes, there is always progress to be made, but the thing is that it gets more incremental every time. I don't think we're likely to see games that look as starkly different as Virtua Fighter 1 and 2 did anymore. By contrast, Tekken 6 and 7 are separated by ten years and don't look anywhere near as different as those two games, released one year apart, did.

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

#63

Post by fermuch »

aphextron wrote: post #45
thomascgalvin wrote: post #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 l…

>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line o…

I've got that same feeling when I started using zapier. The amount of tasks you can automate without modifying nor writing any code is incredible. Since last year, I added webhooks to every action in every system I make, and then I use both zapier and huginn to send analytics, add users to mail groups, notify me when something goes wrong, and even make systems that write everything to Google sheets.

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

#64

Post by corysama »

aphextron wrote: post #16
emodendroket wrote: post #15

Earlier quoted context omitted.

I have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?

Most big studios are still on UE as a matter of momentum and the aforementioned biases. Unity really only became viable in the past 3 years, which is shorter than the average AAA game development cycle. Also certain games such as FPS are still better off with UE, as that's what it was designed for.

You are selling UE short in a whole lot of ways. Anywhere Unity's performance is higher it's because the feature set is less advanced. It's a matter of two different approaches.

Unity started out targeting low-end PC, then got into mobile a long time ago when mobile was very weak. So, naturally it used very basic techniques that are crappy but fast. Over time, Unity has been adding more and more advanced tech.

UE is the opposite story. It started out targeting consoles and high-end PC. It started targeting mobile when mobile was already pretty capable. At first, the tech it used was not feasible on mobile. But, over time the perf improvements of UE and mobile hardware have been converging.

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

#65

Post by Kenji »

steeleduncan wrote: post #14

This blogpost gives the other point of view: http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f... Essentially that the engine you use can constrain what you create, so write your own.

Thank you for presenting an encouraging counterpoint. I think own game engines can work, but you'll probably have to stick to 2D or 2.5D because 3D introduces such great amounts of additional complexity - and even though 3D is not extremely hard, it's a huge time sink.

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

#66

Post by thehardsphere »

advice_giver wrote: post #54

This blog post and the comments here are amazing. In no other software field but indie game dev does spending a year trying to build your own toolset instead of $ACTUAL_PRODUCT_THAT_MAKES_MONEY draw praise.

It's cargo-cult word-thinking. "Game engine" is associated with "game" because of the success of id Software, Epic Games, Valve, CryTek, et al. So people who don't think the way programmers do, have the impression that a game engine is a required step in the software development process to have a successful game.

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

#67

Post by pdpi »

tomku wrote: post #26
avaer wrote: 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.

It's worth pointing out that without id's engine licensing business that depended on other companies NOT following the Carmack school of thought, it would've been harder to justify writing a new engine for every game.

I'd argue it's probably better to think of most of the later games as elaborate tech demos for the engine business

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

#68

Post by emsy »

davexunit wrote: post #53
karmadog wrote: post #30

There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…

>what technology you choose depends on what you value

No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use.

In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment.

>It doesn't make programs better

Yes it does. With a GC you lose control over runtime, which is crucial to the performance.

I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.

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

#69

Post by juliangoldsmith »

musha68k wrote: post #49
juliangoldsmith wrote: post #35

Earlier quoted context omitted.

Game mechanics were a lot of what always set id apart from everyone else. You could always count on them for smooth, fast-paced action, without much in the way of frills. While their new games are still quite good, they seem to have begun to slip a bit after Carmack's departure.

Huge Carmack fan here but I feel the need to defend the latest hi-octane Doom incarnation from 2016 - IMHO great controls, fast old-school gameplay, superbe graphics.

I'd agree. The single-player for the new Doom was excellent, but not groundbreaking.

The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.

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

#70

Post by davexunit »

emsy wrote: post #68
davexunit wrote: post #53

Earlier quoted context omitted.

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…

>what technology you choose depends on what you value No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use. In contrast, you can write web applications in almost any language with little technical differences. That's the point where…

>No, what technology you choose depends first and foremost on what you want to achieve.

Maybe for you. But not for me. I find the rest of your post to be very mean spirited.

I don't work in the games industry because those constraints sound miserable.

Post reply on HN