81–90 of 232 posts
Maybe I would make a good game dev after all: I have no interest in making a language, would be happy knocking one up in JS
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 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…
That just seems like poor discipline. 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 nam…
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.
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…
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.
Earlier quoted context omitted.
In Table Tennis we call it "being an EJ" or "EJ-ing" where EJ stands for Equipment Junkie.
..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.
Earlier quoted context omitted.
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. 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…
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.
Earlier quoted context omitted.
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.
"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.
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.
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…
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.