6 ms·

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

75 points by raytopia 3y ago

weinzierl 3y ago
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/credits/ https://www.mobygames.com/person/96245/juan-linietsky/credit... https://www.mobygames.com/person/96244/ariel-manzur/ 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/ https://godotengine.org/article/support-us-kickstarter/
- n_plus_1_acc 3y ago
  IIRC the Godot IDE is also made using Godot.
  - nox101 3y ago
    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
    - bzzzt 3y ago
      > 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.
      - johnnyanmac 3y ago
        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?
      - nercury 3y ago
        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.
        Ekaros 3y ago
        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.
    - nercury 3y ago
      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.
      - nox101 3y ago
        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.
lifthrasiir 3y ago
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.
- geek_at 3y ago
  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
  - harry8 3y ago
    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 https://en.wikipedia.org/wiki/Eating_your_own_dog_food
    - fragmede 3y ago
      Yes but it's having a goal that makes you metaphorically hungry in this analogy, otherwise we wouldn't be eating dogfood.
- resonious 3y ago
  Regular SaaS products also tend to suck hard due to the creators not actually using the product themselves.
- dbish 3y ago
  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.
synctext 3y ago
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/13rRUygBwg0 https://www.computer.org/csdl/magazine/so/2006/03/s3005/13rR...
- rob74 3y ago
  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.
saint_angels 3y ago
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.
- speps 3y ago
  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).
  - deleted 3y ago
    [deleted]
- Dzugaru 3y ago
  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).
  - saint_angels 3y ago
    > 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.
    - KronisLV 3y ago
      > 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/ 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.
frading 3y ago
That's the path I took with Polygonjs ( https://polygonjs.com https://polygonjs.com ), and a game I've just released ( https://polyreplay.com/minesweepertwist 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/ 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.
brylie 3y ago
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/ https://studio.blender.org/films/
yellow_lead 3y ago
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.
- subtra3t 3y ago
  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.
  - stodor89 3y ago
    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.
resatori 3y ago
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 https://github.com/damn/gdl , which just 'organically' evolved out of developing https://github.com/damn/Cyber-Dungeon-Quest https://github.com/damn/Cyber-Dungeon-Quest , an action RPG. Which means that all features have been created by an actual need.
ngcc_hk 3y ago
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
sylware 3y ago
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.
- pests 3y ago
  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.
  - sylware 3y ago
    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.
bsder 3y ago
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.
mediumsmart 3y ago
I thought game engine development is making a game
onikolas7 3y ago
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 https://nik-os.com/agl/17_collisions.html

75 points by raytopia 3y ago

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/credits/ https://www.mobygames.com/person/96245/juan-linietsky/credit... https://www.mobygames.com/person/96244/ariel-manzur/ 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/ https://godotengine.org/article/support-us-kickstarter/

n_plus_1_acc 3y ago
IIRC the Godot IDE is also made using Godot.
- nox101 3y ago
  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
  - bzzzt 3y ago
    > 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.
    - johnnyanmac 3y ago
      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?
    - nercury 3y ago
      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.
      - Ekaros 3y ago
        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.
  - nercury 3y ago
    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.
    - nox101 3y ago
      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.

lifthrasiir 3y ago

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.

geek_at 3y ago
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
- harry8 3y ago
  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 https://en.wikipedia.org/wiki/Eating_your_own_dog_food
  - fragmede 3y ago
    Yes but it's having a goal that makes you metaphorically hungry in this analogy, otherwise we wouldn't be eating dogfood.
resonious 3y ago
Regular SaaS products also tend to suck hard due to the creators not actually using the product themselves.
dbish 3y ago
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.

synctext 3y ago

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/13rRUygBwg0 https://www.computer.org/csdl/magazine/so/2006/03/s3005/13rR...

rob74 3y ago
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.

saint_angels 3y ago

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.

speps 3y ago
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).
- deleted 3y ago
  [deleted]
Dzugaru 3y ago
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).
- saint_angels 3y ago
  > 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.
  - KronisLV 3y ago
    > 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/ 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.

frading 3y ago

That's the path I took with Polygonjs ( https://polygonjs.com https://polygonjs.com ), and a game I've just released ( https://polyreplay.com/minesweepertwist 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/ 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.

brylie 3y ago

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/ https://studio.blender.org/films/

yellow_lead 3y ago

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.

subtra3t 3y ago
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.
- stodor89 3y ago
  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.

resatori 3y ago

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 https://github.com/damn/gdl , which just 'organically' evolved out of developing https://github.com/damn/Cyber-Dungeon-Quest https://github.com/damn/Cyber-Dungeon-Quest , an action RPG. Which means that all features have been created by an actual need.

ngcc_hk 3y ago

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

sylware 3y ago

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.

pests 3y ago
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.
- sylware 3y ago
  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.

bsder 3y ago

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.

mediumsmart 3y ago

I thought game engine development is making a game

onikolas7 3y ago

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 https://nik-os.com/agl/17_collisions.html