7 ms·
It's interesting that this phenomenon is much more prevalent in game development, as opposed to (for example) web development: some people build their own web d
by Townley 5y ago
It's interesting that this phenomenon is much more prevalent in game development, as opposed to (for example) web development: some people build their own web development frameworks, but it seems like every game dev tries to make an engine at some point.
My theory why: good web frameworks consider developer experience to be of paramount importance, and invest heavily into examples, documentation, and API improvements. Unreal and Unity by comparison are unpleasant to work in. The UI is clunky, the examples cap out after a certain point of complexity, and community input is almost nothing when compared to the Django, Express, Rails, or language-specific ecosystems.
Anyway, I can't say I've ever made it far enough down the rabbit hole to want to make my own language... but I know for me, the desire to make my own engine* has punctuated every attempt over the years to get better at both Unity and Unreal
*Acknowledgment that I might be partially disproving my own point, as I've tried to build both my own web framework, AND my own game engine... but I spent a lot more time on the game engine (https://github.com/RobertTownley/gamehook https://github.com/RobertTownley/gamehook)
- coptun 5y agoTake a look at Godot. At least then it will be "our own game engine" rather than "my own game engine".
- BeefySwain 5y agoSpeaking of making a language for an engine for a game...
- sli 5y agoThere's the Mono version that supports C#, which is also faster than GDScript already, if it's at all a (real) sticking point. And you can use C/C++ or Rust if you really want.
- Agentlien 5y agoI've worked with a lot of game engines, and indeed made my own engines and editors. My reason for making my own was partly that it felt like less work to write what I needed than to learn the intricacies of an existing engine. Also, back then the big engines didn't have as generous licenses as now. As for Unity and Unreal: I found them both very easy to get into and get productive with.
- Razengan 5y agoBecause making websites isn’t near as fun as making games.
- csande17 5y agoFor 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 agoThat 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 agoThat 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 agoYou 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 agoYeah, 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.
- vvanders 5y agoI would hazard that game engines are an order of magnitude more complex than web frameworks. A better analogy may be game engine vs db engine or web framework+runtime(ex: Erlang/Elixir+Phoenix). If you have performance issues with a web framework you can scale it horizontally to a degree(depending on downstream dependencies like your DB). Games are built to run against resource constrained hardware and so they optimize for specific usage patterns. There's also the issue that most engines are built to be good at a specific game type and may make trade-offs in terms of how assets are managed and scene complexity. An open-world has much more different requirements than an on-rails shooter. For instance I had to do some pretty heavy retrofitting of one of those engines to handle LoD/geometry streaming and a bunch of other optimizations to make them work well with a large sight-distance game.
- pjmlp 5y agoDepends on the game engine, most 2D ones are quite comparable.
- Kuinox 5y agoNo no, browser contain components similar to a game engine, browser are way more complex, and frustrating, because you do not control the specs.
- pjmlp 5y agoDepends on what the game engine X and Web Framework Y are trying to achieve.
- Kuinox 5y agoThat's true, but you can see new open source engines rising becoming a serious choice to make games. Not so much for web browsers.
- pjmlp 5y agoDepends on the motivation and how much of ChromeOS one wants to implement. https://twitter.com/awesomekling/status/1508953394836353024 https://twitter.com/awesomekling/status/1508953394836353024
- jfoutz 5y agoI think part of it might be learning how to ask good questions. I wrote a terrible terrible C compiler for a class. But I learned so much about the choices between doing things the slow but probably correct way, vs the cool but hard way, or even the jaunt into esoteric decisions. This more than anything else in my career taught me how to evaluate random software. As a professional, or even serious hobbyist, I think it's a good idea to dive deep, build one yourself. Really get a feel for the tradeoffs and hassles of different choices. Even if nothing goes anywhere, it'll improve your craft.
- russellendicott 5y agoThis comment speaks to me. I hate modern web development but I always want to build user interfaces so one day, I thought to myself "Why don't I start from scratch and make my own protocol and write a browser but only for the terminal?" So that's what I've been doing and it's been a lot of fun. A lot of the time I'm pulling concepts from HTTP but what's great is that I can be very picky. Maybe I'll end up just rewriting HTTP but at least I'll understand deeply why all of those decisions were made.
- prewett 5y agoIf you want to build user interfaces, I'd recommend learning Cocoa or Qt, which are both well-designed UI libraries. (Java/Swing is okay, but Win32 has a limiting design, and MFC is crap. Was pretty unimpressed with Android's UI, but haven't really used it enough to have a quality opinion.) HTML was designed for documents and its model is unsuited for UI. If you're going to learn for research first, then in my opinion you'd be better off learning how to do it right, and then if you still want to use the DOM, you'll have a better idea on what would be an effective framework to make/use.
- russellendicott 5y agoPart of the reason I chose the terminal because it's basically the same on all platforms.
- resonious 5y agoWhen I was a kid, I had this messed up idea in my head that if I used a game engine then the resulting game wouldn't be one that "I built". It's like I built this "Unity game" rather than I built this game. I don't really buy into that mindset anymore nowadays, but I guess there's something to be said about how the tools we use influence the products we produce.
- boredtofears 5y agoMaking a game is at least an order of magnitude harder than making a website. Web apps are constrained by the protocols upon which their built (mostly the lifecycle of HTTP requests). Games are gigantic state machines that also require complicated rendering cycles. Unity and godot et el ARE good developer experiences in that they remove much of the complicated stuff even if the abstractions they use require them to be a bit clunky.
- Aeolun 5y agoThis is only true if you talk about the average website, and the average game. Because there is a lot of wordpress spam. I can practically guarantee that any given AAA game is less complicated than the horrible morass of complicated system requirements a multinational company can invent for their internal systems. Mostly because it’s designed to approximate reality, which is complex.
- dagw 5y agoMaking a game is at least an order of magnitude harder than making a website. Ridiculous statement. Making a polished AAA game is orders of magnitudes harder than making a React ToDo Clone. Making a Tetris or Snake clone is orders of magnitude easier than making Gmail. With engines like Unity you go from never having written a game to a shitty 3D fps game in a weekend.
- blt 5y agoI pondered this for a while, still not sure why. It could be the connection to the physical world. There is something satisfying about working with geometry and differential equations. The realtime constraints force you to care about performance, which many people find a fun challenge. Your output is the frame buffer instead of the DOM. It's more of a blank canvas. Most web development is utilitarian, whereas games are more artistic. I am not sure, but I would love to be a game engine developer in another life. I have zero interest in web framework development.
- pizza234 5y agoProbably, many programmers played videogames when they were little, so there's always an underlying dream of creating one. I dabbled in games development, but I've met the same problem; videogames development is actually much more than programming (the engine), and the creative part, which is the primary one, may not appeal people who are technically-minded. This phenomenon is very visible in Rust; there are several game engines, but very few production quality games. The most famous game engine, Bevy, is very popular, but after approximately two years of development is still an alpha (and a very changing one); contrast this with Fyrox, which is much more stable, but is considerably less popular (essentially, unused).
- selfmodruntime 5y agoBoth industry leaders and indie programmers have used Unity and Unreal to make finished games. Large studios may opt to create their own engines at one point or another, but even with all their resources, these custom engines don't always work out. An example of this would be the frostbite engine, of which multiple devs at EA reported that it was an absolute nightmare to work with. Turns out, if you need developers to work on the engine at the same time the game is developed, you just lose manpower to actually engineer your game. [1] [1]: https://www.usgamer.net/articles/ea-frostbite-engine-history-bioware-ea-sports https://www.usgamer.net/articles/ea-frostbite-engine-history...
- Agentlien 5y agoI worked with Frostbite for five years. The engine is very capable. It's also developed in a vacuum with very little exposure to actual game development. It's used to create fancy new features and show them off in tiny toy projects. Then it's handed off to developers to make actual games and the issues begin. The biggest issue with Frostbite was always that its developers treated it like an ever revolving set of cool new projects. There was always some fancy new system meant to replace the old one in just a few years and never any fixes for the shipped and still broken systems.
- qw 5y agoWeb developers may not create their own frameworks as much as game developers, but many spend a lot of time switching frameworks, libraries or simply just rewriting existing applications. I see this tendency at work, where the relatively simple React app has been rewritten 4 times in a couple of years. The recent hires would rather rewrite it from scratch than to refactor / improve the existing one. Apparently, the 5th rewrite will solve all problems with the first 4...
- scotty79 5y ago> [...] prevalent in game development, as opposed to (for example) web development [...] Everybody made their own framework before some of those became popular. And people are constantly producing new frameworks. Because it always will be more entertaining and meaningful for someone to build a framework/engine that feels good than yet another app/game. Not to mention many compiled to js languages made by and for webdevelopers.