The importance of making games during a game engine's development | Hacker News Reader

The importance of making games during a game engine's development

team-nutshell.dev

75 pointsraytopia59 comments

I like how the Blender Foundation creates Blender Open Movies with the intention to improve Blender by using it in a production environment.

https://studio.blender.org/films/

Not just game engines but pretty much everything else. Rust got good first-hand experiences with Servo in its early days. A lot of Blender features were developed in conjunction with its Open Movies.

Regular SaaS products also tend to suck hard due to the creators not actually using the product themselves.

This is especially true for programming languages. Which is why it drives me nuts when people complain at programming language developers when they dare use that language to develop other software.

> people complain at programming language developers when they dare use that language to develop other software

Interesting. That sounds very weird. Do you have any example you could point at?

Self-hosted languages are said to be prone to overfit because that self-hosted implementation tends to be the only large application written in that language, so they converge into a similar set of features (in particular functional ones). Not necessarily bad by its own, as many features in modern languages do come from FP, but that convergence is frequently independent from the originally stated goal and ultimately lowers a probability of success.

This. I firmly believe if you are making a platform or saas product for devs you need to be building an application that uses it first or in parralel even though building the platform sounds more important and higher impacting and everyone loves to sell shovels. It’s the only way to prove your platform is high value and to work out the real value. In days like today where there are a lot of folks selling shovels, I trust the platforms that use them as well far more then yet another platform with customer logos.

Very true! When I learned PHP back in the 2000s I had a few failed attempts because I had no project. Then I wanted to make a browsergame (like galaxywars) and I have learned so much during that project.

Having a goal makes learning so much easier

Not so much a goal, I think OP's meaning is more along these lines:

https://en.wikipedia.org/wiki/Eating_your_own_dog_food

Yes but it's having a goal that makes you metaphorically hungry in this analogy, otherwise we wouldn't be eating dogfood.

In a world of moderately prudent people the encouragement of ensuring a product is fulfilling its purpuse to the necessary extent should be unnecessary. Those making things but not trying it for the purpose should not make products for others. I feel a bit silly commenting such evidency, almost like if I was promoting the benefits of water for a fish.

Unity is a prime example of getting it wrong, as they aren't making their own games with their engine. When you go beyond small experiments with it, you realize that many undercooked, janky, abandoned features were driven by business needs, not developer needs. If there is only one reason why unity was never as good as Unreal for "serious" game development - it's this.

Unity actually started doing this while I was working there[0], and then eventually axed it[1] as part of a broader shift towards low quality high revenue mobile development (acquiring ironSource, for example). This shift was highly demoralising for the entire organisation, as it included laying off huge swathes of creative staff from Gigaya development (and other teams) and hiring in areas of monetisation (read: advertising and tracking).

Unity is no longer a games engine company, it is an ad company. It is taking surprisingly long for people to see it this way.

It was really sad to me, because (possibly naively) I saw joining Unity as a potential opportunity to pivot more closely to game engine programming (from web), but that was an uphill battle given that the resource allocation was massively in the opposite direction.

0: https://blog.unity.com/games/introducing-unitys-latest-sampl...

1: https://80.lv/articles/unity-stopped-the-production-of-its-s...

Yup, real shame. There were also a number of teams working on internal projects specifically for dogfood-ing as well. To my knowledge those teams all dissolved as well (but that was nearly 2 years ago now, maybe things changed for the better).

>Unity is no longer a games engine company, it is an ad company. It is taking surprisingly long for people to see it this way.

to be honest, I wasn't aware half of unity's revenues were ads until I worked there. Online gaming discourse has such tunnel vision for AAA console games that it is very easy to miss how over half of gaming revenue is mobile, which is where Unity rules in terms of market share.

thanks for sharing this, I guess Gigaya was announced and axed in such a short timeframe, that I've completely missed it

Couldn't agree more on the business vs actually making a game needs, the amount of half-baked stuff in Unity is shocking. Our docs are littered with pointers to forum threads explaining why some workaround has to be done because yet another known for years problem is still unsolved

Its kind of funny trying to figure out how something - and actually what - could be done with it together with scores of clueless - and many times unpatiently frustrated - community participants. I feel like the Unity developers find it funny to watch too, otherwise they would not redo half baked essential 'solution' (inaccurate choice of word here) units into a different but a little bit more complicated half baked solution without proper explanations, so using Google in lack of real help would shuffle clueless chatter of the poor bastards ironically titled 'users' and 'community' ('support group' would be more proper) about multitude of versions together. Nice game of puzzle trying to figure out what the heck is this about on the end. If you are there just for fun.

Plenty of "serious" games are made in the engine -- Genshin Impact, Hearthstone, Marvel Snap, Among Us, Pokemon GO, Beat Saber... is there a reason those games are worse than something made internally?

Yes, the point is that having an internally developed game would mean that when issues and inconveniences are identified, they force valuable improvements/fixes to the engine (which benefit the product and others) instead of workarounds by the external game developer in their particular game.

it's possible to make good and big games in Unity, but you can't rely on many Unity features in that case. Like, I'm sure there is barely any "Unity" in Genshin Impact, I bet they replaced most of the engine with custom tooling.

It's been a while, but I worked on some Unity stuff in the past (I had a decade of C# experience back in 2013), and this is what I saw for a lot of mid-size-to-large games (but nothing AAA, and definitely nothing compared to Genshin Impact!).

On a lot of those, the engine is more of a bare-bones renderer: only one Scene is really used, all entity instantiation and level loading is done by a user-land script. Some physics/collision was very custom too. Editors were also almost always custom, on larger games you write custom tooling, mid-sized ones preferred packages from the asset store.

Perhaps things are different now. Character movement was 100% offloaded to packages, but now there are more capable systems (I haven't kept up). But I still see a lot of chatter about how to do this kind of thing in forums, etc. Anyway, that's what I remember seeing, so: IME and YMMV, of course.

> Perhaps things are different now.

hehe, no. Things are pretty much the same. Source: I'm working with Unity daily.

All those don't use in house tooling for lots of stuff. This is a situation similar to android were some libraries from Google are useless basic implementations. Pointing out that android is widespread does not invalidate the point.

Talented developers will overcome the 1000 papercuts and build something worth playing. That doesn't mean it's the best solution.

Also pouring enough time and money and resources in product will solve issues eventually. But does not mean things could not have been better or cheaper.

Unity did start making their own demos, but it seemed more to catch-up with Unreal Engine which did it since the start (eg. Unreal games where the name comes from).

Feels like they had a grand idea but got tired pretty soon after starting to realize. Now it is just fiddled around like with any Microsoft products.

There are far more games that were made with Unity, not Unreal, I would even say an order of magnitude more. So I don't really get your point? Unity is vastly easier to jump on, so a lot more people actually make games and test things (not knowing the quirks of the engine inside out, like a game engine developer would).

> There are far more games that were made with Unity, not Unreal, I would even say an order of magnitude more.

that's correct. As the saying goes, it's easier to start making a game in Unity, but it's easier to finish it in Unreal. Most games in Unity are pretty small, or unfinished.

> Most games in Unity are pretty small, or unfinished.

By that reasoning, aren't these games the majority of the market and therefore the engine is a good fit for it - starting and working on arguably smaller indie projects and such, as opposed to some hypothetical huge game, of which there are decidedly few? I think that's why Godot is also a pretty good engine, even aside from it being open source, even if the features aren't all that mature - it's easy to iterate in it, even faster than in Unity.

I found some stats: https://steamdb.info/tech/

  Unity has 42160 games.
  Unreal has 11701 games.
  GameMaker has 4498 games.
  RPGMaker has 2939 games.
  PyGame has 2273 games.
  RenPy has 2213 games.
  Godot has 1170 games.
  
  All the other engines together have around 6000 games.

Steam used to be notorious for hosting a massive amount of shovelware and asset swap (I think they tightened it up a bit?), so I don't think these stats are as significant as you imply.

Ohh right, then we might need more data about the ratings and/or profits of each game, to properly figure out the relative... utility of those engines, in making profitable and well received games?

>aren't these games the majority of the market and therefore the engine is a good fit for it

it's the Pareto principle, I suppose. There are tons, tons, tons more small games than large ones, but the large ones take the lion's share of the revenue. So it depends on how you approach games.

The point is that the engine developers don't get a reality check that a particular feature is janky and needs a change, since noone in their organization has ever actually used that feature, and the external developers who could identify that need have no ability to change it.

JavaScript is the most popular programming language on GitHub.

It doesn't mean it's a good example of how to design a programming language.

Something Godot got right. Its original authors were involved in a couple of games (not only with Godot), for example:

https://www.mobygames.com/person/96245/juan-linietsky/credit...

https://www.mobygames.com/person/96244/ariel-manzur/

There was also Dog Mendoça in the early days:

https://godotengine.org/article/support-us-kickstarter/

IIRC the Godot IDE is also made using Godot.

that is arguably not a plus. Game engines usually have very different needs then editing tools. a simple example is maybe the ability to undo. Good tools are designed around editing whereas game engines are designed around performance. The two are often in conflict. It's quite often that tools based around an engine are inflexable and engines based around tools are slow.

Effectively they should argusblybe built separately with the tool designed to make editing easy and flexible and extensible and then have it generate/bake optimal data for the performabt but l ss flexible engine

A concrete example might be the difference between Photoshop and textures in a game. go watch almost any texture artist and they'll have 89 layers in Photoshop but it will all get baked down into just An rgba texture. Photoshop needs to support those layers, layer masks, compositing modes, blend options. The game just needs in rgba8unorm texture.

note:I shouldn't have to say this but because some pedantic person will take issue with this example. I get it's an imperfect example. The point is tools and game engines have different needs. The point is not the specific examole of layers. Another example might be that Photoshop virtualizes storage since it was designed to edit gigiabyte images on machines with 4-8 meg of ram. Game engines, even if a few can stream large images, they are generally not dessigned to edit them

> The point is tools and game engines have different needs.

Game engines need to offer sometimes quite complex graphical user interfaces too. Think of menu, windowing systems, dialog boxes and a compositor style approach to drawing them. If you're going that far you might as well build your editor in it.

Once upon a time, yes. I wonder how much the popularization of "minimalism" came from design trends, how much from the lack of time to refine UI for games, and how much due to the lack of tooling in modern engines to easily translate complex designs mocks into the game?

Right, imagine a company where the team decides to use Macromedia Flash for game UI only because they need to deliver something working on the next sprint. And then everyone gets stuck with that decision for more than a decade.

Might not end up too badly... Reminds me of certain "poor" "indie" company with some rather profitable products... But that might be despite that choice.

I get that tools and game engines have different needs, however, arguably the benefits of better testing/dogfooding the practical usability of multiple parts of your engine are simply more important than whatever cost/time/effort savings you'd get on that editor app by picking some more suitable external tool.

Say, you use the same foundation for both the game and tool. Nothing prevents you from building features on top that are optimized either for a tool or for a game! Plus you dogfood the system all the time.

That's not my experience. It's about momentum. They are vastly different things with vastly different needs. A game needs data in an optimal form, a tool needs data in a flexible form. Those 2 things are in conflict. So game tools based on engines usually suck because they are designed inside the engine's data structures, which don't match the needs of the tools. Yes, in some imaginary ideal world it would work but it never does in actuality.

Or to generalise: 'Eat your own dogfood'

Scientific version with nuance of why it might be a bad practice in cases: https://www.computer.org/csdl/magazine/so/2006/03/s3005/13rR...

TL/DR: dogfooding is good, but you should still keep an eye on what your competitors might be doing better than your product, and be wary of NIH syndrome.

That's the path I took with Polygonjs ( https://polygonjs.com ), and a game I've just released ( https://polyreplay.com/minesweepertwist ), with more coming shortly.

But it didn't start like that. It only started as a tool I could use to deliver client projects, as I was trying to become a freelance for interactive 3D scenes for the web.

Project after project ( some examples here: https://polygon-lab.com/ ), I could improve Polygonjs. Then I found clients who would be interested enough to buy licenses, and would give valuable feedback which would help the project grow even more.

And a few clients asking for not just interactive sites, but also games. This pushed Polygonjs further, and after several games released, it definitely qualifies as a game engine.

So this is generally an advice I give to people who want to become freelancers. Build a tool that solves a problem in your space, as this gives you an edge, and you'll also get the chance to confront that tool to reality, which will help it - and you - grow. This becomes a virtuous circle very quickly.

I recently joined a local game jam with the intent of showing off my 2D engine. Halfway through, I realized I didn't have a way to properly destroy game objects. I realized it after messing up my cooldown timer and accidentally spawning a few thousand projectiles. It's something I knew I had to do that but I kept pushing it back to work on more interesting (but less critical) stuff. Now I am building a very simple hack-and-slash game and adding engine features as needed. Documenting the process here[1] for anyone interested.

[1] https://nik-os.com/agl/17_collisions.html

It is more expensive to keep a game engine kind of generic while developping a game. Usually the game engine will end-up being taylored for a specific type of game. Namely, diverting for that type of game won't feel right or even will work badly. It may explained why games based on the same engines feel all the same (just a skin swap, zero flavor): game devs don't want to divert from what the "usual" and optimized usages of a game engine, because they don't want to have to deal with engine internals (or they cannot due to closed source) for the very good reason which is: most of the time those engines are insanely complex and massive (and that includes their SDK too).

All that to said, there is no magic bullet. Maybe some functional and completely siloed modules may give more flexibility to game devs, but they will work out the glue.

Not every game based on the same engines all feel the same - compare Left 4 Dead, Half-Life and Titanfall 1&2. All built in Source, all feel like different games. TF especially.

This is not what I said, I said roughly, namely as a general trend, not an absolute truth.

An absolute truth, for instance, is c++ and similar being toxic for humanity because of their syntax complexity.

Upvoted because it's really easy to get lost when developing a game & engine.

I am trying this approach right now with the functional clojure 2d engine 'gdl'https://github.com/damn/gdl , which just 'organically' evolved out of developing https://github.com/damn/Cyber-Dungeon-Quest , an action RPG.

Which means that all features have been created by an actual need.

I don't work in games, but it seems like making a game engine is incredibly complicated, and has some unbounded requirements. In many ways, it seems harder than making a working browser.

Depends on what you mean by working. If you mean able to render a standard HTML5 page with a little bit of CSS and no javascript, a game engine would probably be more complicated. But to create a browser that implements most/all of the features a modern browser offers, without becoming bloated, I think that would be far more harder than any game engine we have right now.

As a game programmer, I have to agree. Game engines exist. Non-bloated browsers do not. Simple as that.

It all comes down to the ability to manage scope. You can take a lot of shortcuts and still come up with a cool, unique game engine. Browser development, on the other hand, has been hijacked by Google. Even if you hire 50 people, all you can do is fork Chromium and add some bells and whistles.

As a result, making a game engine is both simpler and much more creatively rewarding. Of course, if you're having too much fun, you can always kill both of these advantages and try to develop a UE5-killer. But that's on you.

To my admittedly jaded eyes, any game engine that doesn't make asset management a primary goal has already lost.

Far too many open source game engines don't seem to realize this.

It is similar in idea that you have two implementations as RFC protocol proposal. Game engine has to be used. It is better used from day one

I thought game engine development is making a game

Reply on news.ycombinator.com