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

Show HN: Crown – A flexible game engine written from scratch in C++

github.com

Post reply on HN
Print view View original

131–140 of 179 posts

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#131

Post by JabavuAdams »

thehardsphere wrote: post #66
JabavuAdams wrote: post #24

Great learning project, but for production just use Unity unless you absolutely, positively (triple-check) cannot. You will be massively more productive.

Umm, no. Unity has lots of problems that make it not ideal for games that have fast action or are developed by a larger team. Like, the fact that it uses an old version of Mono on not-Windows, which uses a mark and sweep garbage collector. You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. I've al…

There's a lot of FUD surrounding Unity, although I cannot comment on PS4, specifically, as I have not shipped for that platform.

On mobile, and/or desktop there are very few empirical reasons not to use Unity. If you have the skills to develop your own engine and tools, then you certainly have the skills to work around Unity or garbage-collection issues.

When I'm hiring a game developer and they'd rather work on engine or tools than making games, this is a red flag. I've seen projects waste person-decades of development effort all because one or two senior devs wanted to do roll their own thing instead of using Unity.

The engine and toolchain that is always has flaws that the utopian engine and toolchain that could be don't have (yet).

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#132

Post by gpderetta »

imron wrote: post #126
gpderetta wrote: post #107

Earlier quoted context omitted.

It is very different from having a static method returning an optional, which guarantees that you can access the optional (with at least an assert in debug mode) only if the object is actually successfully constructed. Using a separate initialize member function means that you may have objects in a zombie state laying around after a failed construction which lead to all kind of initialization order issues (you might…

> It forces heap allocation though, which is bad. It does, and it can be, but in situations where it matters, the static create function typically returns a value from a preallocated pool of memory, so objects are all contiguous and cache friendly.

Even when using a pool allocator, you still have unnecessary indirections which is expensive. One of the benefits of C++ is the ability of being able to allocate subobjects inline with the containing object or array. By forcing indirection, allocating subobjects requires navigating a potentially deeply nested tree.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#133

Post by goldfire »

lazyjones wrote: post #46

While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp. The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C…

There was an attempt at a somewhat standardized C++ subset called Embedded C++. Even within embedded circles I don't think it ever got much traction, presumably because it was _too_ limited.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#134

Post by aphextron »

thehardsphere wrote: post #66
JabavuAdams wrote: post #24

Great learning project, but for production just use Unity unless you absolutely, positively (triple-check) cannot. You will be massively more productive.

Umm, no. Unity has lots of problems that make it not ideal for games that have fast action or are developed by a larger team. Like, the fact that it uses an old version of Mono on not-Windows, which uses a mark and sweep garbage collector. You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. I've al…

> You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently.

This is a coding problem, not an engine problem. A game should have almost no dynamic resource allocation.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#135

Post by [deleted] »

thehardsphere wrote: post #66
JabavuAdams wrote: post #24

Great learning project, but for production just use Unity unless you absolutely, positively (triple-check) cannot. You will be massively more productive.

Umm, no. Unity has lots of problems that make it not ideal for games that have fast action or are developed by a larger team. Like, the fact that it uses an old version of Mono on not-Windows, which uses a mark and sweep garbage collector. You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. I've al…

[deleted]

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#136

Post by thehardsphere »

JabavuAdams wrote: post #131
thehardsphere wrote: post #66

Earlier quoted context omitted.

Umm, no. Unity has lots of problems that make it not ideal for games that have fast action or are developed by a larger team. Like, the fact that it uses an old version of Mono on not-Windows, which uses a mark and sweep garbage collector. You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. I've al…

There's a lot of FUD surrounding Unity, although I cannot comment on PS4, specifically, as I have not shipped for that platform. On mobile, and/or desktop there are very few empirical reasons not to use Unity. If you have the skills to develop your own engine and tools, then you certainly have the skills to work around Unity or garbage-collection issues. When I'm hiring a game developer and they'd rather work on engi…

>On mobile, and/or desktop there are very few empirical reasons not to use Unity. If you have the skills to develop your own engine and tools, then you certainly have the skills to work around Unity or garbage-collection issues.

I guess. The question is why should I have to work around Unity?

I mean, everything is a trade-off. I understand that for many teams and games, the hassles of Unity are worth the benefits. But that is not every game and every team.

>The engine and toolchain that is always has flaws that the utopian engine and toolchain that could be don't have (yet).

We don't have to compare Unity to utopian engines and tool chains when we can compare it to its competitors like Unreal.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#137

Post by JabavuAdams »

thehardsphere wrote: post #136
JabavuAdams wrote: post #131

Earlier quoted context omitted.

There's a lot of FUD surrounding Unity, although I cannot comment on PS4, specifically, as I have not shipped for that platform. On mobile, and/or desktop there are very few empirical reasons not to use Unity. If you have the skills to develop your own engine and tools, then you certainly have the skills to work around Unity or garbage-collection issues. When I'm hiring a game developer and they'd rather work on engi…

>On mobile, and/or desktop there are very few empirical reasons not to use Unity. If you have the skills to develop your own engine and tools, then you certainly have the skills to work around Unity or garbage-collection issues. I guess. The question is why should I have to work around Unity? I mean, everything is a trade-off. I understand that for many teams and games, the hassles of Unity are worth the benefits. Bu…

> I guess. The question is why should I have to work around Unity?

When shipping a production-quality game there's almost always going to be something you have to customize or work-around with any engine. What often happens with home-grown engines is that the cost of tools friction or engine implementation is not properly accounted for, because it's kind of fun although it's unproductive.

> But that is not every game and every team.

Agree, but I'm fed up with the amount of FUD around Unity. I've watched teams burn money rather than putting up with some annoyances. I'm an older dev (40+), so I've seen many iterations of devs refusing to use existing tool X in favour of supposedly more convenient but less battle-tested tool Y. This is in game development, and software development, more generally.

There are also holistic benefits to Unity, like 1-2 second recompiles. This is a game-changer in terms of debugging and allowing you to try more iterations of things.

> We don't have to compare Unity to utopian engines and tool chains when we can compare it to its competitors like Unreal.

I think Unreal is a great engine, and I'm admittedly less familiar and therefore productive with it than with Unity.

That said, I would say that for mobile or small-footprint games Unity still has an edge. This is based on the experiences of several studios / devs that I've talked to. They make great headway with Unreal, but then the project bogs down when it's time to actually ship. That said, this could be Unreal FUD from developers who are new to that engine.

To get the benefits of Blueprints in Unity, just buy PlayMaker. It's $65 dollars a seat, and you'll never write another Finite State Machine.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#138

Post by makapuf »

jcranberry wrote: post #63
zakirenish wrote: post #55

If you come to finance, most of the developers love premature templatization, it makes them feel like they know something. Not sure it that can be attributed to their insecurity about C++ coding skills, but it gets really ridiculous at times.

I have a friend who runs a hedge fund, not really insecure at all but uses templates vigorously. More stuff in compile time rather than runtime. In critical sections inheritance can be prohibitively expensive because of the use of lookup tables.

if you're using templates for compile time computations it's maybe time for c++14 or even c++17 simpler constexpr functions (if possible and available, and if allowed to, ofc.)

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#139

Post by thehardsphere »

aphextron wrote: post #134
thehardsphere wrote: post #66

Earlier quoted context omitted.

Umm, no. Unity has lots of problems that make it not ideal for games that have fast action or are developed by a larger team. Like, the fact that it uses an old version of Mono on not-Windows, which uses a mark and sweep garbage collector. You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. I've al…

> You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. This is a coding problem, not an engine problem. A game should have almost no dynamic resource allocation.

Then what about Unity leads everyone who uses it to allocate dynamically, somehow, on every platform but Windows?

If everybody makes the same coding problem, and the common denominator is one of their dependencies, it makes you wonder what's wrong with the dependency.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#140

Post by mhh__ »

monocasa wrote: post #128
jcranberry wrote: post #63

Earlier quoted context omitted.

I have a friend who runs a hedge fund, not really insecure at all but uses templates vigorously. More stuff in compile time rather than runtime. In critical sections inheritance can be prohibitively expensive because of the use of lookup tables.

Thrashing your I$ because you have too many template instantiations can be prohibitively expensive too, it's just harder to metric.

Just how many nested templates are we talking about here? You can have that problem (obviously) with or without templates. Most sane template designs don't exist when the program is actually run (Debugging them when they don't work is another matter)
Post reply on HN