6 ms·

For me, at least, I like to write my own engines to get the end-user experience I want. Every game engine comes with a million little decisions about how games

For me, at least, I like to write my own engines to get the end-user experience I want. Every game engine comes with a million little decisions about how games should work by default, and writing my own engine lets me make those decisions for myself. In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback.

mrcartmeneses 5y ago
That might be because there is a lot more creative freedom in game development because playing a game is essentially an exercise in coming to an understanding of the underlying dynamic. And a game is played for fun. Conversely users of a web app generally don’t want to invest any time in understanding its underlying dynamic and instead want something that works in a familiar way. So we optimise for that.
quickthrower2 5y ago
That many react apps look like that is not a react thing but a design thing. You can make a react app that looks like HN. Or like a game!
- onion2k 5y ago
  You can make a React app that's wildly different to all the others, but if you follow "best practises", and you learned from the same tutorials, and you're using the same component libraries as other React devs your app will probably drift towards looking and working like other React apps unless you make a conscious choice to stop that happening.
  - csande17 5y ago
    Yeah, one difference between React and, say, Unreal Engine is that Unreal Engine is the brand for the whole package while React is the brand for one of the core components. ("I'd just like to interject for a moment. What you're referring to as React is, in fact, React/Redux/Tailwind...") Once you've bought into the whole ecosystem, you get an "engine" that wants your app to look and work a certain way just like how Unreal wants your game to look and work a certain way. You can customize it however you want, but every decision you don't make is made for you by the engine. And even when you are making the decisions, the engine is always there, nudging you in a certain direction by making some things easier than others.
  - selfmodruntime 5y ago
    That is just not true, no matter how hard you try to make it seem that way.
  - quickthrower2 5y ago
    There is some truth.m to that. Tutorials need to decide where to focus on React but want to make you feel like you are building something cool so they will bring in style frameworks to assist so you can focus on the react. I assume this is also true for jquery/angular/vue and other library tutorials. Maybe just for fun they should use alternative frameworks! Then on the job, well unless you are a designery company it will be devs who do design and will happily delegate that thinking to a framework. Again not a react thing but a general dev thing. I have seen this too in desktop apps of 90s. Just use MFC or some popular toolkit.
iamsaitam 5y ago
"In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback." - Erm, nope. You might be talking about people relying on UI component libraries, which has nothing to do with React.
- neoberg 5y ago
  I've been using React full time almost since its first release and I somewhat agree with the previous comment. While the choice of framework usually doesn't really restrict what can be done; it's often easier/harder to do specific things with a given framework. For example; animations responding to user interactions are easier to do in frameworks with an OOP approach. It is generally more "different" in a declarative way. So most React apps simply don't have those. There are lots of small things like this that over time make React apps feel Reacty.
maccard 5y ago
> every React app eventually starts to look and act like the Reddit redesign, Not every unreal engine game starts to look and behave like gears of war. If you drop a bunch of asset packs from the store it's going to look like every other asset flip out there, but so will your game engine if you use the same assets. > , I like to write my own engines to get the end-user experience I want. My day job is working in unreal engine, and in the last 7 years of using it I can only think of one scenario where the engine was the limiting factor in the user experience I wanted, and not something I could easily work around. If you think you're going to be limited in your end user experience in unity or unreal you probably need to reconsider how much you know about those engines.
- Agentlien 5y ago
  In essence I agree that the big engines very seldom get in the way and should be good enough for almost any project. However, I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features. To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) and found myself having to implement some things I just couldn't understand were missing. For instance, URP supports a depth prepass for opaque objects but still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass. Just binding the already generated one instead allows you to get a lot of free depth culling and in my mind is one of the main reason to use a depth pass. But in URP it was apparently used exclusively to feed depth information to shaders.
  - maccard 5y ago
    > I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features. Agreed wholeheartedly, and this is part of game development. Sometimes that comes in the shape of adding features that are straight up unfinished, other times it comes in bugfixes/workarounds. I hope my original message didn't come across as "there is no work involved in using a preexisting engine!" > To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) <...> still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass. Presumably implementing that was _far_ less work than writing a URP yourself, and that's before you take into account the benefit of the art/design pipelines being able to use the render pipeline for the X months it would take you to write one yourself. That example doesn't effect the "user experience" of the game either (which is what the GP comment claimed they wrote their own engines for), but that's not to say it's not worth doing!

mrcartmeneses 5y ago

That might be because there is a lot more creative freedom in game development because playing a game is essentially an exercise in coming to an understanding of the underlying dynamic. And a game is played for fun. Conversely users of a web app generally don’t want to invest any time in understanding its underlying dynamic and instead want something that works in a familiar way. So we optimise for that.

quickthrower2 5y ago

That many react apps look like that is not a react thing but a design thing. You can make a react app that looks like HN. Or like a game!

onion2k 5y ago
You can make a React app that's wildly different to all the others, but if you follow "best practises", and you learned from the same tutorials, and you're using the same component libraries as other React devs your app will probably drift towards looking and working like other React apps unless you make a conscious choice to stop that happening.
- csande17 5y ago
  Yeah, one difference between React and, say, Unreal Engine is that Unreal Engine is the brand for the whole package while React is the brand for one of the core components. ("I'd just like to interject for a moment. What you're referring to as React is, in fact, React/Redux/Tailwind...") Once you've bought into the whole ecosystem, you get an "engine" that wants your app to look and work a certain way just like how Unreal wants your game to look and work a certain way. You can customize it however you want, but every decision you don't make is made for you by the engine. And even when you are making the decisions, the engine is always there, nudging you in a certain direction by making some things easier than others.
- selfmodruntime 5y ago
  That is just not true, no matter how hard you try to make it seem that way.
- quickthrower2 5y ago
  There is some truth.m to that. Tutorials need to decide where to focus on React but want to make you feel like you are building something cool so they will bring in style frameworks to assist so you can focus on the react. I assume this is also true for jquery/angular/vue and other library tutorials. Maybe just for fun they should use alternative frameworks! Then on the job, well unless you are a designery company it will be devs who do design and will happily delegate that thinking to a framework. Again not a react thing but a general dev thing. I have seen this too in desktop apps of 90s. Just use MFC or some popular toolkit.

iamsaitam 5y ago

"In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback." - Erm, nope. You might be talking about people relying on UI component libraries, which has nothing to do with React.

neoberg 5y ago
I've been using React full time almost since its first release and I somewhat agree with the previous comment. While the choice of framework usually doesn't really restrict what can be done; it's often easier/harder to do specific things with a given framework. For example; animations responding to user interactions are easier to do in frameworks with an OOP approach. It is generally more "different" in a declarative way. So most React apps simply don't have those. There are lots of small things like this that over time make React apps feel Reacty.

maccard 5y ago

> every React app eventually starts to look and act like the Reddit redesign, Not every unreal engine game starts to look and behave like gears of war. If you drop a bunch of asset packs from the store it's going to look like every other asset flip out there, but so will your game engine if you use the same assets. > , I like to write my own engines to get the end-user experience I want. My day job is working in unreal engine, and in the last 7 years of using it I can only think of one scenario where the engine was the limiting factor in the user experience I wanted, and not something I could easily work around. If you think you're going to be limited in your end user experience in unity or unreal you probably need to reconsider how much you know about those engines.

Agentlien 5y ago
In essence I agree that the big engines very seldom get in the way and should be good enough for almost any project. However, I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features. To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) and found myself having to implement some things I just couldn't understand were missing. For instance, URP supports a depth prepass for opaque objects but still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass. Just binding the already generated one instead allows you to get a lot of free depth culling and in my mind is one of the main reason to use a depth pass. But in URP it was apparently used exclusively to feed depth information to shaders.
- maccard 5y ago
  > I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features. Agreed wholeheartedly, and this is part of game development. Sometimes that comes in the shape of adding features that are straight up unfinished, other times it comes in bugfixes/workarounds. I hope my original message didn't come across as "there is no work involved in using a preexisting engine!" > To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) <...> still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass. Presumably implementing that was _far_ less work than writing a URP yourself, and that's before you take into account the benefit of the art/design pipelines being able to use the render pipeline for the X months it would take you to write one yourself. That example doesn't effect the "user experience" of the game either (which is what the GP comment claimed they wrote their own engines for), but that's not to say it's not worth doing!