211–220 of 232 posts
Earlier quoted context omitted.
Take a look at Godot. At least then it will be "our own game engine" rather than "my own game engine".
Speaking of making a language for an engine for a game...
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], wh…
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.
Earlier quoted context omitted.
Unless we are talking about Assembly, all languages have runtimes. As for the GC, it can be turned on in critical code paths, C# supports manual and stack memory allocation. Profilers exist, many console games have been shipped in C#, besides Unity, there are Xenko, FNA and MonoGame custom builds for game consoles. Compare the demo on the blog with, https://store.steampowered.com/app/236090/Dust_An_Elysian_Ta... http…
There's also Terraria, which is the 15th best-selling game of all time. Written in C# (XNA).
Earlier quoted context omitted.
There's also Terraria, which is the 15th best-selling game of all time. Written in C# (XNA).
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).
Earlier quoted context omitted.
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.
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], wh…
Oh no, we are on Hacker News. ;-) 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…
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 ;)
Earlier quoted context omitted.
Unless we are talking about Assembly, all languages have runtimes. As for the GC, it can be turned on in critical code paths, C# supports manual and stack memory allocation. Profilers exist, many console games have been shipped in C#, besides Unity, there are Xenko, FNA and MonoGame custom builds for game consoles. Compare the demo on the blog with, https://store.steampowered.com/app/236090/Dust_An_Elysian_Ta... http…
There's also Terraria, which is the 15th best-selling game of all time. Written in C# (XNA).
Earlier quoted context omitted.
I’d go an order of complexity above again. 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 a…
Right which is why in the following sentence I limit it to general purpose game engines like Unreal and Unity. Making a toy browser is something you can do as well.
Earlier quoted context omitted.
> 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, a…
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 wi…
Earlier quoted context omitted.
> 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 proj…
> Blow has shipped two games in 20 years 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…