I don't know what it is about game development that really brings out the yak shaving in people.
One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
>I don't know what it is about game development that really brings out the yak shaving in people.
People get into game development because they want to have fun programming. Getting projects done involves a lot of things that are not fun, so it usually goes nowhere because the incentives are misaligned.
I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tools/jigs/sleds than actually building some projects, hobby guitar players spending more time on gear than playing, etc. and I'm 100% guilty of it as well.
Sometimes all you have to do is shave the yak and give the wool away, and a nice yak-wool coat will come back to you. :)
Which is to say: sometimes, if you build a low-level library/infrastructure service and release it, someone else will take advantage of it to write the high-level thing you were originally aiming to create.
I'm speaking from experience — my company's DBaaS is built on the premise of just building a really good database domain-model to hold a certain type of large, public-available datasets, for efficient, flexible querying of them; loading those datasets into it; and then giving people access to it (through SQL or various use-case-shaped APIs.) It's a really thorough yak-shave of the DB+ETL layer of what was originally planned to be a higher-level B2C product.
But it turns out I have a pretty unique view of what should be considered "fun", because my yak-shave was everyone else's schlep. Everyone turned out to be dying to get their hands on this thing, because they wanted to spend all their time on a product, rather than getting good data to feed their product. Once we realized that, we stopped trying to build a B2C product at all, and just started selling the yak wool directly.
I never thought about the implication that shaving a yak is the most fun thing you want to do all day. It's so great you would rather shun all your other responsibilities to shave some yaks. I guess I'd better try it.
I really depends on the species of yak. Shave your matted, smelly yak? No thank you! But my silky black yak, absolutely!
I guess the trick is to fall in love with a species of yak that everyone else needs but wants to avoid, so they'll pay you to shave your favorite yaks.
> People get into game development because they want to have fun programming
Totally agree. I think the only real issue here is expectations. If the project mentioned was crowdfunded specifically and only with the goal to deliver a game, then I think people would be right to be a little bit irked that the developer is instead tinkering with their own programming language rather than the game, after eight full years. However if the project was funded with the understanding that the developer was just going to explore and share the process of game development and everyone is on board with them going off-piste to develop something interesting, then I guess that's fine.
That said, the amount of money in question is $67k spread over 1660 backers (~$40 each) so it's not like this person has grifted millions then done a rug-pull :)
I don't know about other backers, but I'm happy with how this has turned out myself. I think backing anything comes with a level of risk, and the fact that they're working on something publicly, eight years later, is more than a lot of campaigns manage.
Thank you. It's not a grift (or is that what a grifter would say - oh god I hope it isn't). I didn't want us to overpromise and become the next No Man's Sky (which has by now fully redeemed itself) so I never spent much time on advertising and trailers. As a result, we didn't get much money. People were skeptical from the beginning, which was expected. What we got in support largely came from a handful of friends who wanted to see it done, and most of their names are going to end up in the credit roll. 99% of our present funding comes out of our own pockets and from Sylvia's illustration business.
> I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tools/jigs/sleds than actually building some projects
As a hobby woodworker, I was saved from this by circumstances: I couldn't build a workbench in the old shed, I couldn't build a new shed at the time, but I needed a new nighstand ASAP because my son needed a larger bed, so I had to make it on an old kitchen table in the old shed.
That is absolutely fine, and you can learn a lot with that sort of approach. It really depends on your objective.
The only thing to keep in mind is that writing software for business (e.g. SaaS) requires the exact opposite approach. You go lean, write what other people want, and go for an MVP first.
In my first year of 3D printing, I printed mostly parts about upgrading and modding my 3D printer.
But the good thing is it also made me get used to the whole process of refining a 3D print and after a year I barely started to print functional&useful things.
So yeah, I don't see a problem with this approach :)
I'm somewhat guilty of this when working on a desktop app. I made a state management library, though I realized I cannot possibly finish it in full so I spent only 100h on it to get it minimally working. I don't consider it a waste though. The waste was trying to come up with some kind of strict error handling ala Rust in TypeScript, I went far with this and got an idea to do it with minimal development, thankfully I pulled the plug on this after a month and went back to work.
As a solo bootstrapper founder it's really hard to do development and business / marketing in the early stages. Focusing purely on development is preferable when time limited, however, I think it's sometimes helpful to stop development and take a break to spend on business / marketing - i.e. some education, or preparing marketing content for the future. This tends to put in perspective how much time sometimes is wasted on meaningless things and gives clarity on what is really important - shipping a quality product.
This is a lot like what a YouTuber by the name of Randy has been doing: he decided to create his own game engine instead of using something like Godot/Unity/Unreal and it's been quite the adventure.
Of course, he still has nothing close to an actual game and the progress he's made in a year is visually similar to what i threw together in a month in Unity for a freelance client once. Though admittedly, he's probably learnt a bit more about how game engines work by creating his own and it's been quite the educational experience, as well as something that actually has gained him a nice following of people who support him towards more videos.
But that's still not very conductive to shipping finished games. It's very much the same as people whose games tend to balloon in scope, another thing that's as damaging to finishing a product in a reasonable amount of time as writing your own engine is.
I do suspect that not everyone has the utilitarian approach to game development that i or other people like me have: who just pick Godot/Unity/Unreal for every single project of theirs without ever caring much about the inner workings of everything. Then again, i'm the kind of person for whom, for example, adding graphical effects to their game consists of utilizing pre-made shaders instead of learning to use the shader language properly and all that.
Not that there's anything wrong with that, but those are wildly different mindsets.
In case you missed it, some further context, his website now reads:
I’ve decided to shelve Arcane (a video game I’ve been “working on” for 7 years) so I can practice shipping smaller games first
I’ve been sending out a personal changelog every Sunday
I’ve started using Unity so I can hone my design & prototyping abilities
I scrapped my old custom website with this WordPress one
I’ve transitioned to having writing (this site) be my main communication medium since I’m not the biggest fan of chasing the YouTube algorithm
Yep, that is actually the eventual outcome for many of these grandiose projects.
Nonetheless, i hope that his further pursuits are more successful or at least fulfilling for himself!
Who knows, maybe he'll be able to create interesting content about Unity some time in the future, like Sebastian Lague and others make: https://www.youtube.com/c/SebastianLague/videos (if he ever feels like doing more YouTube content)
> as well as something that actually has gained him a nice following of people who support him towards more videos.
A following which has recently turned against him after they funded 6k a month on his patreon, and he flatout told them that he would stop communicating, doing YouTube videos and he would also stop working on the game they were giving funding for.
If he was making that much money for a while, lives somewhere affordable, and saved a lot of that, he’s got a decent runway to start making money by actually making games instead of getting lost in his own engine.
I did the same thing 10 years ago. I probably spent about 9 months full time building a game on a custom OpenGL engine, but at that point I realized how many systems I was still missing (for example animation, more advanced effects and shaders, etc).
But as of recently I'm now doing game development again, but this time using Unity. I've learned that game development is really hard, geometrically more so than a random business application or tool, and you have to use all/any tools that are available to you.
Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch.
I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the operating system provides (too low level), and what a DBMS provides (too high level). So I'm having to build all these weird bespoke disk-based data structures myself. It's clear these things can be done and there is a lot to gain from doing it, but the language support for non-trivial disk based data structures is a bigger pain in the ass than sitting on a burning cactus covered in tabasco sauce.
> Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game.
The vast majority of games don't need to be low level for performance. Practically nobody outside of massive AAA studios is writing architecture specific assembly for modern PCs or consoles (and even in those studios, there are very few people doing so). The majority of gameplay programmers are writing bog standard C++ that would be just as performant in C#, or in many cases a lot of the logic is written in a higher level scripting language that is orders of magnitude slower than the native C++, or even just writing all of the game code in something like C#.
> Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch.
Oh for sure, and there often are better ways to solve these problems. In my experience, one of the most common reasons for not doing things better is because the codebase is based on an engine from 20+ years ago when they _did_ have to avoid interfaces and virtual function calls for game performance, and you have "modern" systems that are built on top of those abstractions (in the same way that lots of modern networking libraries still leak details about concerns from the 80s/90s)
Depends entirely on what you want to do. Use a bog standard engine, and you get Satisfactory. If you build your own, you can have Factorio. The former will never reach the sort of simulation complexity the latter can even on modest hardware.
> The former will never reach the sort of simulation complexity the latter can even on modest hardware.
You're comparing games rather than engines here. There is no reason at all that you can't write your simulation logic in vanilla bare bones C++ as factorio has done, and still get the benefit of using an existing engine. You get all the neat (and hard) things like serialisation, multiplatform support, networking, asset management, patching, and a bunch of other things. Sure, factorio may not need a 3d renderer, but it definitely needs and uses the rest of what I listed above.
But you'll always be fighting the engine, because these kinds of "one size fits all" engines are complex enough to be essentially another operating system above the one you'd otherwise be dealing with. As long as your desires are well aligned with the abstractions it presents it will probably save you time, but the more you drift from that the less time it will save you and eventually there's a point where dealing with it costs more time than it saves.
For the level of performance the Factorio devs want it makes sense they'd opt for maximum control over everything rather than fighting someone else's implementations.
The problem is you can't deal with the number of entities factorio regularly does on a stock engine. They just aren't made to deal with hundreds of millions of stateful and non-trivially interacting entities. That's not what game engines are built optimized for.
I think you're underestimating what can be done with the industry standard engines. From a rendering perspective modern game engines can handle so much stuff that it will fill your screen entirely. Just look at UE5's Nanite which supports ridiculously massive scenes and splits the frame into roughly pixel-sized triangles to render at interactive frame rates.
If you do end up in a situations where you have more objects than is suitable for even these systems to simulate you don't need to throw the baby out with the bath water. Create your own managers running whatever simulation you wish without tying the units directly to the most obvious game engine entities, with whatever scheduling you need to make the updates work with the compute budget you have. Use the engine entities to represent whatever higher level object makes the code manageable and easy to work with.
Then you can surely leverage the game engine for input handling, rendering, and a lot of your logic, just writing your own code for whatever challenges are unique to your game and where the standard approach for that engine is unsuitable.
Just because you're using unreal doesn't mean you need to have one actor per entity (for example). Using [0] as an example, there's no reason you can't implement a cache optimized simulation algorithm in C++ and pass the results out to UE4 instead of whatever layer factorio is using.
To be fair, factorio is a pretty good example of when the existing options offer limited value (lock step networking, _very_ simplistic rendering, very little in the vein of "gameplay" features), but it's one of very very few. For every factorio, there's 100 2d side scrollin platforms that are written in a custom C++ engine rather than using unity.
Reimplementing all of the features that unity provides for you is time spent on "just" adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations, when you could have been building a game. I can spend a month building a bare bones C++ engine that gives me all of the above and start into my game, or I can download unity, start with all of those features and spend a month working on my game.
Sure, and then deal with leaky abstractions and fighting the engine wherever its abstractions don't give you what you want.
> adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations
None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be. And there's value in having complete control over your product and understanding how every part of it works. You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
I'm not saying it's the wrong choice to use a bespoke engine, indeed many games that are made with bespoke engines would not have been made otherwise and I'm grateful that such things exist and enable those games to be made, I'm just saying it's not necessarily a bad idea to make your own engine. Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
> None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be.
I never said they were _hard_, but they take time. Time that can be spent on your game.
> You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
Every system has bugs. You're always going to have to make tradeoffs when building projects, and building an entire framework from scratch to avoid those bugs is throwing the baby out with the bathwater. You're trading the possibility of at some point in the future being blocked from developing a very specific part of your game for the guarantee of spending time up front yak shaving.
> Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
Blow has shipped two games in 20 years, and one of those (braid) predates _any_ of the existing engines being free and easily accessible. Another of the "build it from the ground up" camp is Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game. The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
You say that like it is a bad thing. By (nearly) all accounts Braid and The Witness are lovingly and expertly crafted, unconventional, and brilliant games. He's not making the annual Madden or Call of Battlefield here.
> Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game
Be fair to Casey, Handmade Hero is primarily an educational project and he only devotes a few hours to it each week. Though admittedly he has allowed the scope to creep quite a bit from the original goals.
> The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
My point is more that I'm kind of sick of people being so down on the concept of building your own engine even for relatively simple 2D games. Yes, I agree that it takes time, but so does learning the ins and outs of an existing engine and the time you invest in the latter nets you less generalizable skills than the former and leaves you with less control over the end product. It is a tradeoff, and like all tradeoffs there are good reasons to go one way or another.
Is that really true though? Aside from graphics and physics, which seems to be highly reusable, where's the performance critical stuff? Lots of engines seem to be mostly using scripting languages for everything a game developer needs to do.
I wonder if there's a DBMS out there somewhere that already does what you need? Seems like by the time you got to a scale where you would need custom stuff, you'd have money to redo it(Unless it's a foss thing meant to be big but not commercial, or to run on a server you're paying for yourself)
I work specifically with video game performance, mainly as a graphics programmer, and often focusing on getting things to work well across multiple platforms. In my experience the performance issues are almost always a combination of how much is being simulated and rendered, how it's being rendered, and how much stuff is kept in memory at any given time.
If you can improve culling before rendering and physics, minimize the surroundings streamed in to your immediate vicinity, and optimize some of the heaviest materials and post effects, that goes a really long way.
Of course, there's an endless list of caveats depending on what your game specifically is, but even in an open world game where things happen off screen the above applies. You just have very simply LODs/imposters for faraway visuals and simplified logic running at lower frame rate for characters in other parts of the world.
Sure. What about simulation? Like I mentioned Factorio in your neighboring comment. It does things with a custom engine that you simply can't do using "highly reusable" systems.
Existing engines are great as long as you want your game to look and behave like every other game written in the same engine. It's gotten to a point where a careful observer can tell which engine a game is written in just by looking at it and feeling how much input lag and framerate variance it has.
I think a lot of people get into game development to go back in time to their early experiences of computing. Before all the enterprise projects, before all the tools and frameworks, before all the tiring interactions with people and teams and managers and customers. Just an empty BASIC prompt, just a blank C file. It’s a search for a blank slate, open to infinite creative possibilities, before the world put everything in boxes within boxes within boxes and drained much of the joy from these magical machines. Finishing a game is coming back up for air, who’d want that?
Game development methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading platforms).
With trading platforms, they last for years, decades maybe. They're created with some ideas around how to manage performance and to support evolving requirements. Developers know this thing is going to be around for a long time, so its treated as such. Years down the line, you start creating a new platform and look to do a long migration to keep clients happy because you can't just turn off their favourite functionality.
Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Dump the old game as the new one is released. Much seems to be from scratch. The BF2042 scoreboard issue seems like it should be almost off the shelf. There also seems to be this big shift towards short release cycles which pushes even more churn and reinventing the wheel. Look and feel must be updated to keep things "fresh". Although most of the popular games on Steam[1] are older games that have been around for years.
So many places to shave a yak, I'm surprised games get shipped at all.
Of course take all of this comment as an outsider who just yearns for the old days of cool mods and custom servers.
The days where AAA games dumped the engine between releases are long gone (like Playstation 1 long gone).
For franchise games there will be incremental improvements to engine systems; some to support new gameplay features, some to help with development tooling/pain-points, and some to improve visual fidelity. The trick is choosing the correct number of upgrades/refactors that fit the release schedule while remaining relevant and not dooming your next franchise release with insurmountable feature debt.
In my experience the biggest engine changes come with new hardware platform support, typically a console generation jump. More power requires a toolchain that can handle more complex assets (and more of them), new graphical features and expectations, different optimizations, new API, different storage types or capabilities etc. Bigger franchises may use a new console generation as an opportunity to gut an existing engine and rework to the strengths of the new hardware generation (and remove the support for older hardware, such as removing 32bit pointer support, DirectX9, Windows7 etc).
Historically where game engines get in trouble is when a codebase is written to one franchise and then forced on to a team making a fundamentally different game with fundamentally different requirements (open world vs compact maps, physics heavy vs platformer, single player vs MMO). At the executive level it makes total sense, they spent x million$ on a game engine and are told by everyone how great an investment it was... why not spin up a new game using that amazing (and paid for) technology?
The flip-side has also sunk numerous game engine efforts, which are often buried without ever becoming public. Doing everything all at once is impossible, you can either do many things generically but with restricted performance and capabilities. Or you can do 'everything' required by a specific game and slowly introduce features that support other games and make things more generic.
> Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Much seems to be from scratch.
I think this should be qualified. The audience and creative workers demand new assets for new titles, but gameplay concepts and codebase seem to move at a slower pace, though live services seem to be distinct systems and not expected to live long, of course.
On one extreme, you have EA's sports titles, where new releases have just incremental updates.
If you don’t mind a digression for someone who needs help…
What is the architecture pattern of a trading platform?
I am looking to build a system that is able to:
- receive 1000s incoming streams of data
- save the data
- make data available to live subscribers
The closest analogous system I can think of is bond/stock/commodity/etc price subscriptions for traders.
I feel like this many in - many out data stream architecture should be solved by now and I rather not start from scratch in architecture and technology choices.
I can’t find the right phrase to even google to get started.
I assume your live subscribers are external people over the internet?
The trading platforms I've worked on tend to order things into a single stream that you can act upon. This helps with testing, race conditions, auditability. You will want to be able to replay an exact series of events to recreate conditions.
LMAX Disruptor[1] and Aeron[2] are two open source examples of something widely used, either using the libraries themselves or as concepts.
Some things that trading systems (generally?) need which you may not, which might simplify your architecture:
- Every message must be delivered and in order. UDP is usually used over TCP, as the platform will likely want more control over handling missed messages.
- It will be common to have read/write applications that need to add a message as a response. Writing is difficult as you need to be quick, otherwise a subsequent message from another application might invalidate your message.
Do subscribers need older data? How do dropped packets impact the system? Can they just be forgotten? What latency requirements do you have? Do subscribers also write to the same stream?
I think sometimes the followers find out that being engaged in the process of creating something brings more value than the game they're waiting for anyway.
I have been in a couple of communities involved with developers as they built games and it was almost disappointing when the game was released because the 'journey' was finished and so time to disband.
It can certainly be a curse though if the developer isn't or stops enjoying it.
Wait, that's the game by Leonard Ritter, aka paniq!
I loved his (demoscene) demo Masagin[1] way back when, and have the SVGs of the geometric shapes somewhere, with a vague idea of bleaching them onto t-shirts (speaking of old projects that never come to fruition...)
Frankly, I can't say I'm surprised that's where he's at with Nowhere. Well, I'm glad he's having fun.
Truth is developing the engines is a lot more fun than developing finished products. Game engines are like virtual machines purpose built for interactive audiovisual program execution. The games themselves aren't that interesting. Operating systems are fun, the applications running on them are boring. Browsers are fun, the web sites are boring.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
Haha, sorry but was that intentionally snarky or just happened to be?
Implementing and refining game tech is not easy, but it's fun, is mostly a science, and gives you rewarding feelings regularly. Game design/production is a mystical dark art (or at least can feel like one) that can be incredibly discouraging, so people avoid it, and avoid the point at which the end is in sight and the game will be judged as a game, by gamers. Modern games leave such a potent impression on our psyche that trying to design one of your own without excessive imitation or feelings of inferiority asks a lot of us. There's also the phenomenon of "devlogs," whose quantity is proportional to development time, and which are useful to show backers that you're making progress (in good faith or otherwise.) And in many cases, somehow they are always long enough to maximize ad placement!!
Hi, this is the yak shaving developer in question speaking. I was worried we'd get grilled hard over our slow progress, but I'm relieved to read that most of you understand how perilous and long-winded gamedev can be. Our backers are also very patient with us, and I don't want to destroy this relationship, but keep being as open and forthright as I can with our progress.
I don't mind the jokes (after all, yes, the whole undertaking is a bit ridiculous), but just want to make sure the facts are understood as they really are:
* Yes, the premise of Nowhere continues to be that it's an alien life simulator (as in: simulating the everyday life of an alien).
* The game is being developed by not just one, but two people: My wife Sylvia Ritter[1] is responsible for the concept art that drives the procedural design (she has given me a lot of work), and I am responsible for programming and direction. We both have a hand in the game design.
* Yes, development is still going strong, and will continue to do so, until the game is done or I keel over, whichever comes first ;-)
* Yes, I am absolutely yak shaving, and there's definitely some sunken cost thing going on here, but there is still no project I'd rather work on than this one. When we launched the crowdfunding, I had a hunch that this would end up taking us 10 years. Now we are on the far side of it and I had to start cutting features and workflow improvement ideas in order to have a chance at making it in time.
* Yes, I developed a programming language for the game, because the art is procedurally driven, and that requires both fast turnaround in prototyping (close to Scheme or Python) while providing C level performance at the same time. There simply was at the time that I started, and still is, no adequate solution available. Originally, I didn't want to do it, but we rationalized that innovation of technique requires innovation of tooling, and hence worth the effort, provided we'd open source everything we made in pursuit of our goal.
* No, Scopes' string implementation is complete for several years already, the recent commits are all touch-ups, augmentations and small fixes for the userbase that has grown around the language, which were quick to do and cost me no significant time. We have in fact other, much larger, support problems that I can not adequately cover because the game is main priority, and the language exists to service the game.
* Yes, I developed a pure functional reactive language on top of Scopes for our game engine that I wrote a few examples with, in the intent of finally merging the CPU and GPU models so we save 90% of pointless and repetitive boilerplate code for CPU/GPU resource management. It's a fantastic idea that is going to go places, but after realizing how much more I'd have to write to get it all the way to its final, visual programming oriented form, I aborted the prototype and focused back on the game.
* What else have I spent my time on? I spent most of those years writing a bunch of prototype shadertoys to explore possible technology used for the game and also teach mathematical concepts to other developers, and they're all released here[2]
* What's going on right now? After streamlining package management[3] for both Scopes and Nowhere, I am presently working on our sculptable terrain engine. There is a by now somewhat outdated video demo[4] of one of its earliest incarnations. The LOD stitching has been fixed, and we have occlusion culling now, but I still have to rewrite parts of it to get a rock solid sub 10ms per frame performance. It would have been more fun to do all that with FRP instead, but tooling is never quite where you want it.
Since I've crossed over from game dev to doing illustration myself, I've realized something about how one ends up in this place, because I've been there. Not as deeply or for as long, but I've seen it and still get tempted by it. It's not actually unique to game dev - it applies to any creative work(e.g. the 30-year novel) - but games demand a higher degree of engagement with their technology than static works, and that creates the ground conditions for scope to explode far more frequently.
What actually happens when scope explodes is that a coherent view of the project has been lost. This is not problematic in a creative sense, just in a "finished product" sense: every time you introduce a contradiction into the work you have to either eliminate it(which creates a negative attachment response, and therefore really requires project managers to step in and cut off some heads) or you work very hard to create some kind of technical rationale, e.g. "we'll do both ideas, so now we have a new type of asset and the entire game must be populated with it and the features will be a little more complicated by it". Which you can proceed to start doing without difficulty, and only feel the downside of later.
Game devs are particularly susceptible to this because games sit in an intersection of dynamic/synthetic/interactive that allows infinite numbers of assets and features to be added, but at a gradually increasing cost, even if you drop fidelity(see every roguelike that has been in development for more than a few years.) And it lets the dev sit in a space of perpetual escape from coherence, because "it'll be great as soon as I add this next thing - after all, nobody has ever done this before". It's a little hype cycle that can be reinflated over and over.
But if you paint a picture, it's one-and-done: there's only so much room on the canvas, so you have to deal with your folly immediately to finish. You can, of course, go the route of burning it and starting over, making the same mistake repeatedly, but this provides much less of an illusion of progress than hitting the compile button on your ever-growing codebase. And you can do a lot of preparatory studies and meander without committing to the image you're making, but the act of doing the studies still propels you into a space where you can hurry up and finish whenever you want.
So the usual advice given to game devs to manage scope is to introduce a technical restriction that "limits the canvas," but if you're technically inclined I think the proper advice would actually be to limit dynamism and make more static works with simple design scope so that more of your technology can be one-off, and not required to be integrated into the large, fully-automated framing of a game engine. E.g. a magnificent rendering system that creates static images for a visual novel. "Simulator" type projects are mostly eliminated by this except where they can take a direct reference, like a vehicle sim. All of my least coherent designs started embracing the simulation concept - and doing that was itself a way of getting away from a clear statement of belief within the game, of trying to accommodate multiple sets of beliefs without directly engaging them.
Not that anyone is going to listen, of course. Sometimes one has to lose a few years of living to this stuff ;)
It's not game development that brings out the yak shaving, it's programming language development. Game development is just a gateway drug because it provides so many opportunities for good abstractions to make things easier. The mistake everyone makes is thinking that they can create a programming language while also doing X, where X is whatever they had doing when they got the itch to do a PL. Really, if you want to do a PL right, you have to do it full time.
Actually I'm not sure it's really a mistake, it's just that doing PL development is so much fun that there's no reason to go back to the original project, if original the impetus for it was to have fun.
Yeah. After wasting two years working on a programming language I realized nobody was ever going to use, I made an oath to just stick to hacking on top of language that already exist
Honestly, my problem is: I don't want to write low-level code, I want a game engine where I can focus the majority of my time on implementing the actual game mechanics. I don't want to have to deal with manually redrawing the screen every time, I want a sprite graph.
I also don't want to have to use slow and clunky UIs like Unity, I just want to spend the majority of my time writing code in text files, and making assets in other tools like Tiled or photoshop or whatever.
It really surprises me how few engines there are in that category. Only ones I've found were: PhaserJS and HaxeFlixel, and unfortunately no 3D ones.
Thank you for backing his work, his posts and twitter feed are a gold mine for some pretty unique ideas in signed distance field and other rendering research.
I read an amazing quote online about any satelite company trying to create their own custom rocket to launch its satellite instead of using existing infrastructure.
The day they decide to get into that is the day they stop being a satelite company and become a rocket company instead. The person put in much more eloquent words so wish i could find that comment but its sounds similar to that.
Wow these are just excellent and even though it says spacecraft design most of them ring just as true for software design.. or maybe just true in general!
This one really made me laugh :D
> At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
What an excellent link, thanks for sharing. Definitely bookmarking this.
Working on languages and runtimes is just fun on its own. It ends up pulling in many facets of CS: graphs, perf, grammars, automata, resource allocation, etc.
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)
I 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.
I’d go an order of complexity above again. The real comparison is to the browser, particularly for general purpose engines like Unreal and Unity. I’d hazard most game engine teams are bigger than most browser teams.
I disagree. Modern web browsers are the most complicated pieces of technology we have today. The amount of work that goes into sandboxing and security alone probably eclipses the complexity of game engines.
That seems very optimistic when compared to some of the bigger engineering projects we have going as humanity. Aircraft carriers and nuclear submarines as a whole system (including the multiple computer networks and their software) are much more complex than browsers, to say nothing of one-offs like the ISS (lots of cutting edge hardware but also full of software) and the systems controlling modern factories. Browsers don't even come close.
I think it's kind of hard to quantify complexity in a way that compares nicely across domains. For example, a lot of the complexity in a browser comes from needing to service ~billions of users across thousands of devices using loosely implemented standards. This is quite a different problem to building an aircraft carrier, where you're going to run in to hard engineering and physics problems but you only have to target ~10k well trained users.
Not when you start. While UE5 is no doubt orders of magnitude more complex than any web framework, no one sets out to write UE5. In fact most people start writing their own game engine because they want something a lot less complex and more tailored than what is available.
If you have the right background knocking out a very simple game engine isn't hard. Many people do it as part of a university course. The problem is that your 'simple' game engine ends up being not that simple very quickly once you start adding features.
Yea, my point was related to why people so often write their own game engine (and so rarely write their own browser). Writing your own game engine for your own game looks fun and easy from the outset. And in fact, depending on your game, writing a game engine that lets you ship that one game doesn't even have to be complex.
Right but there are smaller scale browser-like things as well which have a more vibrant DIY scene like Gopher, Gemini and so on. We shouldn't take a narrow view on what a browser is if we're not going to do that for a game engine.
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.
> 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.
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.
> 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!
It was absolutely a tiny amount of effort in comparison to developing your own fully featured render pipeline. As is anything I've had to do. That is, after all, the point of using a commercial engine. It does the heavy lifting, I just need to tweak it.
> I hope my original message didn't come across as "there is no work involved in using a preexisting engine!"
Absolutely not. I've come across the argument about making a game for the end user experience before and it always strikes me as a case of not understanding the capabilities of your tools. I just wished, more for others who come across this than people with our experience, to add that some modification of the tools is to be expected.
> That example doesn't effect the "user experience" of the game either
Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;)
> Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;)
While this is true, it's also not a "given" from a custom engine and needs to be planned for. It's a big ask for a team to reimplement their renderer as a forward renderer, but it's a checkbox in UE4 (plus reimplementing all the materials etc).
I certainly agree. I'm really not arguing for writing your own engine as anything other than an excellent learning exercise. I've written my own engines and renderers (both forward and deferred) and I'm more than happy to rely on whatever engine we happen to be using at work to solve most hairy issues for me.
I don't think anything is impossible in big commercial engines. I mean, IIRC Unreal Engine gives you a Visual Studio project containing all of the engine's C++ code, so theoretically if you use Unreal your game could be any legal C++ program.
But as a practical matter, using Unreal turns every decision you make from "what behavior do I want" into "what behavior do I want and is it worth fighting Unreal on this", so Unreal games are a lot more Unreal-y than they otherwise would be. (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users.)
Particularly on the 2D hobbyist stuff that I do, writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.
> But as a practical matter, using Unreal turns every decision you make from "what behavior do I want" into "what behavior do I want and is it worth fighting Unreal on this",
I don't agree with this at all - Unreal gives you defaults that can be easily replaced. The decision is "do I use what unreal gives me or do I write my own" for most systems, compared to "do I write my own or do without" if you're starting from scratch.
> so theoretically if you use Unreal your game could be any legal C++ program.
That's a bit reductionist, and not really fair. All of the "behavioural" parts of the engine are exposed in very customisable ways. As an example if you're not happy with the collision detection behaviour/triggers, they are designed to be modified and changed around. If you're not happy with character movement, you provide your own character movement definitions.
> (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users
If your definition of end user experience of a game is file layout on disk, then so be it. Knowing that something is made with unreal engine doesn't immediately turn it into another copycat unreal engine project. Besides looking at the disk layout, you could also just see the splash screen that you're legally required to use when licensing the engine. Also, you have source code to the engine, to the automation process, and the pak tools. If you want a different layout on disk, go ahead and change it.
> Particularly on the 2D hobbyist stuff that I do
If you want to do hobbyist engine development work, _that's_ a great reason to write game engines. Not "liking" an engine and wanting things done differently isn't the same as wanting something that's incompatible with a game engine's design and architecture. If you want a lock step multiplayer game with rollback then sure, you're probably not going to find it. But if you want "less floaty" character physics, or a different camera perspective, a different startup flow/implemention, you can _definitely make that within the bounds of Unity and Unreal
> writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.
You definitely don't _need_ to be an expert in an engine to use it, any more than you need to be an expert in python to start writing some scripts. Also, how can you know how much of the engine you need to throw out before you actually know how to use it?
Many Unreal games released around the time of the original GoW did look very similar though. I think it was the lighting. Two examples: Bioshock and Batman Arkham Asylum.
"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.
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.
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.
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.
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.
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.
I 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.
This 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.
If 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.
I'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.
Probably, 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).
Both 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]
I 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.
Making 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.
This 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.
Making 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.
There'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.
Web 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...
When 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.
> [...] 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.
Always a pleasant surprise to be scrolling through HN and seeing one of my articles on the front page!
For anyone interested in how that code would get zero memory safety overhead without the classic borrow checker, a big part of it is because of the "region borrow checker" [0]. There are some other factors (iso regions, hybrid-generational-memory, etc.) but region borrow checking is the big one.
To someone else's point the article says it was not implemented yet at the time. Assuming it is I'd love to see a follow up after you built what you discuss in this post.
I've writing a Rust based canvas engine, with content via my own IDE, the runtime is fed data via WebSocket using my own API protocol, web proxy routing through a streaming and distributed load balancer using a new protocol, landing on my back-end platform running my own language, writing deltas to my own data store. https://www.adama-platform.com/
It's not quite yak shaving, but it certainly is... something:
> I mean, we are running Access in Wine in X11 on Linux in an isolated
user account on our server slice that revision controls your Access
database in git, and we're displaying it using VNC in your web browser
in flash. People can't possibly want that. But they need it.
That’s the total opposite of yak shaving, but in the most hilarious way. Layers upon layers of systems and protocols to maintain legacy systems… lazily use a bunch of glue and duck tape to build the whole thing… and it miraculously works!
I always wonder why the Access database isn't moved then from JET to some database server, even MSSQL (Postgres would also work), and then you can continue Access but without needing to snapshot it in weird and possibly broken ways?
For any comparison to C# (it being slower or having GC pauses), it probably doesn't take into account the latest advances (.NET 6). That's understandable given there isn't really incentive to gain a mastery in every language during a comparison.
With regards to C#/.NET 6, it is now easy to:
- Have zero-allocation code through the whole stack, making garbage collection zero/near-zero.
[Span<T>, Memory<T>]
- Distribute platform specific all-in-one binaries with no unbundling/uncompression or need to install any runtime.
[dotnet publish -r win-x64 -c Release -p:PublishSingleFile=true -p:PublishTrimmed=true]
- For hot-path optimisation (many available profiling tools), dive into new high-performance APIs such as CPU vector intrinsics, or native memory allocation (aligned or unaligned).
[System.Runtime.Intrinsics.X86, System.Runtime.InteropServices.NativeMemory]
- For faster startup times: AOT compilation.
(Not necessarily faster at runtime in general; JIT has advantages there with being able to detect hot paths)
These are just the features I've used, there are doubtless many more. In the future .NET 7, it will be possible to disable runtime marshalling so interop calls to C DLLs have no overhead (along with a compile-time analyzer to throw errors if the types you're using are not compatible, aka 'blittable').
Credit to Vale - it appears to be addressing all these things so there's certainly an interesting future ahead.
Yak shaving is easy to understand and evaluate, whereas the value in creating a language makes no sense to anyone outside the language scene.
Most people have no way to guess of the new ideas will be influential, but we do know we aren't interested in using niche tools regardless of what they are.
It could be an amazing leap forward for computer science, or a slightly interesting toy, and either way it's above most people's heads.
But not like creating a typesetting system to use to write your book.
It seems like it is shaping up to a pretty nice language. But writing the compiler in itself is very 20th-century. Just add a parser to LLVM or Gcc and call it good.
But don't make the mistake C, C++, and Rust did, using a prefix dereference operator. Pascal got that one right.
BTW: "get" in a pure function name is code smell. More generally, transitive verbs in pure function names are code smell.
> [D]on't make the mistake C, C++, and Rust did, using a prefix dereference operator.
This is only a mistake when the deference is frequently followed by postfix operators, in most cases field and method accesses. Unlike C or C++, Rust does auto-dereference that essentially eliminates such situations and thus a prefix operator doesn't do much harm.
The difference is the original goal of writing a game was frivolous anyway, so it doesn't matter if it gets done. Whereas if you have a book contract, writing LaTeX instead is a bit irresponsible.
The way structured concurrency is implemented in Vale is exactly what I've been missing in every language I've been working, including Rust which gets pretty close. Amazing job!
Though, I do want to be clear for readers, Seamless Concurrency [0] isn't fully implemented yet, we've only just started to play with its first building block, the region borrow checker. It's promising, but I don't want to get anyone's hopes up too early.
Hasn't gone quite as far as making our own language, we did it all in c++.
For us we know doing things this way is a vastly more difficult approach, but nonetheless we plough on. Yesterday I was learning how bezier curves work so we can animate wind effects. The list of interesting maths and physics problems to solve are endless but oh so satisfying, and ultimately its a hobby not something we sell for money.
I decided to use Godot to make a lowpoly online FPS, I don't think it's a great choice, but I've read good things about godot networking...
I first wanted to make it in C++ and opengl, and it did not look like a difficult thing to do, but godot is good enough for a lot of things, it's small, and it allows me to do multiplatform, which is such a big bonus, since C++ is never easy to use on several platforms.
I have no idea if I will be able to implement network prediction with godot.
If someone had told me the second part of that mantra: "... but don't make a game, make an MVP and check with your friends if the game mechanics are fun, first!"
Being distracted building tooling and frameworks is one of the harder things I find with personal projects.
In paid $work, there is a) an imposed direction and usually a schedule from a customer b) often a team of people to distribute work to, and to help keep one disciplined.
Example: I'm writing a VST synthesizer, virtual instrument, as a personal project in my time off between jobs. Maybe I'll make it commercial someday, not sure. I became increasingly frustrated with the half-assed portable GUI toolkit bundled with the VST3 SDK ("VSTGUI"). There's a complete lack of decent cross platform UI options that will work in this context (QT won't do it here, for reasons.)
I realized that there's already a cross platform UI option with millions of man hours put into it: the web. So I have spent the last three or four weeks writing a bridge to embed Edge-Chromium, WebKit, etc. Have that working on Win32, at least (still have to do the work for Linux & Mac, but ok).
Then on to actually making the UI in this platform. Now I'm learning npm, webpack, TypeScript.
Need a nice little HTML/CSS knob for my UI. Most are bundled in a giant framework I don't want. Oh, here's one in pure JS. But, hm. I think I'll refactor this into Typescript. Now it's forked, just for me.
Ok, well, yes I have that mostly working. Some warts, but basically is very similar to the "native" (VSTGUI) UI I had before. But now I want to write a graphical envelope editor. Off to learn HTML Canvas drawing.
Many parts of this whole process could themselves be spun off into separate projects, that I could spend years maintaining, on their own.
And so it goes. The Yak is pretty shaved at this point.
Sounds like it was for the compiler, not the engine itself. IMO Scala is the best general-purpose language going, but it's particularly good for data transformation, so it's a good fit for compilers.
Many years ago I was turned off at Scala for its weird ergonomics (relying heavily on implicits, also the syntax is too wild for my taste) and large build times, along with Project Valhalla still not being finished. Maybe things have gone better for Scala 3?
Scala 3 has put in some specific replacements for the main use cases of implicits, which IMO is a worse approach and a step backwards but I guess you might prefer that. The syntax has been pushed to be a bit more Python-like, but again I don't know if that'll be a plus or minus for you. But on the last point Scala has had "Opaque types" for 3+ years now, and IMO that's a better alternative to what Project Valhalla is trying to do for the cases that it covers.
Can you use opaque types to make “value-like” matrix/vector types like vec3, vec4, mat4, etc.? This was the biggest reason I eliminated the Java platform as an option for using it in gamedev. The alternative for Project Valhalla is to either live with the GC costs or use a hack from LWJGL (MemoryStack) which is very unergonomic to use.
This reminded me of a statement David Zicarelli (creator of Max/MSP/Jitter) made many years ago - that he originally started working on Max in order to make a tool to help him compose novel and interesting music, and then he got so drawn into making the tool that he lost interest in the music composition itself. If we're to call Max/MSP/Jitter "yak shaving", it is a shining star of it since so many artists - both visual and sonic - build their work on it.
The other obvious one is Knuth - inventing TeX and Metafont and Computer Modern typefaces so he can write his books the way he wants to. Another shining star.
Why is there a need for a "parallel" keyword? Can't the compiler decide for you whether to parallelize a loop for you?
If the decision to parallelize depends on the data, couldn't the compiler generate code for both implementations and select the right one at run time?
Or maybe the programmer could describe in code what they expect the data will look like, and the compiler will take a decision based on those annotations (and other signals, such as the HW the program has access to, what the programmer wants to optimize for (memory? latency?)).
How timely! I'm sketching out a visual novel engine that implements a simple DSL (think of it like Ren'Py, but with Ruby instead of Python). Yesterday, I spent hours rewriting the line-by-line preprocessor into an LR parser.
Oh, and I had to write my own FFI library to bind into the MRI.
Oh, and the language I'm using has an SDL2 library available, but it was incomplete the last time I checked.
> So, having learned that lesson thoroughly, I then made the same mistake again!
So true ! I don't know if it is written with a bit of sarcasm, but this one made me laugh !
'cos in the end, it's about doing what one loves. So if you think you like to make games but have fun writing the perfect game engin instead, it's not less fun !
C# is very fast on average, but due to its runtime/GC it won't give you the consistent performance you need for game engine internals, which is what they meant by "slow".
> Unless we are talking about Assembly, all languages have runtimes.
My point was that some languages have heavier runtimes than others (out of the box, at least).
And yes, C# is very popular for gameplay code, but I'm talking about the parts of an engine that typically use systems programming languages. Even then, you can shoehorn C# into that role with some tweaking and AoT compilation (which is a testament to the C# ecosystem's versatility). But I was just explaining why I think the word "slow" was used regarding the C# language in general, even though it's not perfectly technically correct.
Mentioned elsewhere in the thread, the author might be alluding to the quickly-aging Mono implementation as that's common in game engines with C# support (e.g. Unity and Godot).
My last 8 yrs of game development have been in a good part about how to make c# go fast, and it is definitely possible, but you will have to write in a style that is different from the norm.
A few other commenters hit the points better, but mostly it comes down to avoiding allocating objects every frame/tick.
In part this is through avoiding LINQ, lambdas, yield return, async etc. (fine to use in code that is run once like startup, or on relatively rare triggers)
Using struct, arrays of struct/value, Span<>, ref, fixed etc. to keep memory access sequential or on stack.
Use mutable structs, avoiding properties, avoiding struct constructors, moving throws into utility methods, etc. to support (the rather weak) optimizer to do more inlining.
And move data processing of arrays of struct with tight loops, like compression, lighting, meshing, pathfinding into a native c++ dll/so or if applicable gpu. (c++ autovec/simd optimizations or much better than what the clr optimizer currently provides)
Ok, I see, thanks. Why then using C#/.NET at all if you have to do without many (most?) of the conveniences of this technology, and even have to consider to implement parts in C++ for performance reason? Why not directly e.g. C++?
Because the hot paths in the code are not the majority of the code.
C# is (for me) much more productive to write than c++.
More powerful refactoring tooling due syntax that is much easier for tooling to process.
Powerful autocomplete, autorefactoring tooling.
Easy code navigation due to easy to process syntax.
The tooling also responds much faster, c++ refactoring tools seem to take a long time to process code.
Big reduction in footguns/UB etc.
Very quick iteration cycles, edit-and-continue in sub second, stop-edit-restart cycles in the low single second range.
Very good debugging, objects are inspectable and editable, stacktraces reliable.
Edit-and-continue makes for very quick probing of internal state.
The c++ code is around 1% of LOC and 20% of cpu cycles, seems like a good balance.
Bounds checking, lack of dangling pointers/use after free, removes a whole class of hard to debug bugs.
For the same reason that many C and C++ games were actually using them as high level macro processors full of inline Assembly a couple of decades ago.
There are some conveniences that come with the technology and not every code path on the game engine is screaming for perfomance.
If you are on the path for the ultimate performance like some console titles, the C and C++ code on those engines will be very alien to most developers as well, yet you don't seem many discussing that.
Just on the subject, here is a talk I saw recently on the theme,
"Beyond the Remake of 'Shadow of the Colossus': A Technical Perspective"
You should check out the comment section of a woodcrafting (or the like) Youtube channel. I think 'tool obsession' is probably a personality trait and one you're more likely to see in your day to day in programmers than in other crafters due to proximity to the internet. Oh, sewing rooms are another good hit for that as well.
..what kind of equipment do you even get in Table Tennis? I understand there are different makes of paddles but I thought it was limited to a couple materials applied to one or both sides. If you don't mind I'd love to know more.
The wood part is called the 'blade' in English and there are MANY different brands and models. They come in either 5 ply or 7 ply, where it might be full (5 or 7) wood or 5 wood plies + 2 thin carbon wafers. I use a carbon blade (Viscaria) - they are more stiff with less vibration, or feedback, but generally have a higher speed ceiling and larger sweet spot at the expense of a little bit of control at lower speeds (gears).
The other component of a setup is the rubbers, you can have one black rubber and one red rubber (although new colours are soon being made an official part of the sport) - generally they're split into two categories "tensors" and "tacky" or "chinese" rubbers and recently "hybrid" rubbers. Rubbers are comprised of a sponge and a top-sheet - which manufacturers can customise to produce different playing characteristics. Long story short: tensor rubbers historically were favoured by Europeans (on both sides, whereas Chinese would use a hard tacky rubber on forehand + softer tensor backhand) and are more elastic with built in catapult effect. They require less physical effort to produce good spin and speed. Tacky Chinese rubbers are very hard with a very tacky surface, the harder sponge makes them easier to control at low gears (close to the net for short game) and have great top-end spin as well as spin on serves. They require more physical exertion and efficient use of the body to use effectively (although there are also substances called "booster" which we apply to make hard tacky rubbers come alive). Hybrids are a sort of mixture of the two that have become popular with the new 40mm plastic ball and can be used on either side. Typically you will use a harder rubber on the forehand than on the backhand, but it's up to personal preference.
As much as I think the other replies to this question hit the nail on the head, I think there’s more to it than just tool obsession.
Software developers are in the fairly unique position where most of our tools are software defined. We are experts in the discipline required to improve our own day to day work lives.
How many other professions have this liberty? Woodworking does to an extent, carpenters regularly make their own jigs and clamps but rarely venture into the realm of sharpened tools.
Contrast this with anyone working in the medical or retail(?) industries. People working in these fields are close to powerless to improve the tools they use every day.
Embrace the tool improvement life, there’s still a long way to go before software tooling is “finished”
It's hard to tell what benefit there actually is from this kind of thing. There's definitely great new tools developed all the time, but most of them seem to be planned megaprojects.
I've never seen a custom build system or VCS or personal/project specific tooling I'd want to use.
Seems like most of it happens just cause devs enjoy it.
Making your own clamps seems very much the same.
The other reason is there's a real cult of assuming that minimal is always best, and devs resent using any tool that has more features than they absolutely need.
They also resent any more opinionated structure than they need, even if it makes things safer and easier, because they seem to really enjoy blank canvas creativity.
I can't believe all the catty defensive replies. The answer is that programming is designing automation (automatic computation) and functionality of computers. So getting into that mindset naturally leads to "well, what If I can automate what I'm doing too? What if I can make a function that makes these functions?". Not to mention, a gardener isn't tempted to trim his rake into a better rake, because that wouldn't work - the tools are made by a different process than what they are used for. Not so in programming
Why are musicians so obsessed with their instruments? Just use the right tool for the right job, don't call yourself a "pianist" or a "drummer", call yourself a musician.
Playing an instrument is harder than any basic non-mathematical programming. It's almost shocking to finish a project, clock out, practice guitar a bit and realize the difficulty difference.
Buying stuff on the other hand is very easy.
Just like running is(I assume, having never seriously done any sports) way harder. Buying more crap and then not even using it is easy.
Everyone always wants their fast instant gratification hits, regardless of hobby.
Yeah semi-pro musicians are probably the worst. It's really easy to get obsessed with both accumulating shiny new (or vintage) toys, and tweaking your favorite instruments so they're set up exactly how you want.
Because languages are not tools, but rather media. They are the basis for the structured thought that unveils, as such their form and function is critical to the process of programming.
One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
[1] https://duangle.com/nowhere
[2] https://hg.sr.ht/~duangle/scopes
[3] https://hg.sr.ht/~duangle/tukan