Live data from Hacker News

Accidentally making a language, for an engine, for a game

verdagon.dev

71–80 of 232 posts

Re: Accidentally making a language, for an engine, for a game

#71

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.

The first page of results for "table tennis ej" on Google has all the answers. I had no clue about it either.

Re: Accidentally making a language, for an engine, for a game

#72

I don’t get why are programmers so obsessed with the tools they use for the job? More than any profession

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”

Re: Accidentally making a language, for an engine, for a game

#73
post #19

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…

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 optimi…

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.

Re: Accidentally making a language, for an engine, for a game

#74

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.

The rubber and the wood (or other material) itself, that is enough for people to delve deep into. Different rubbers on different sides.

Re: Accidentally making a language, for an engine, for a game

#75
post #64
post #58

> These languages are mostly fine... but C# is slow,.... First of all, it is a matter of which implementation we are talking about. Second, all major implementations wouldn't have had any issue dealing with the demos shown on the blog. I guess it was a good learning process about compilers for the author.

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...

https://store.steampowered.com/app/985890/Streets_of_Rage_4

https://store.steampowered.com/app/107100/Bastion

https://www.pcgames.de/Arena-Wars-Spiel-18141/Tests/Arena-Wa...

All of them done in regular C#, not even taking into account Unity and its DOTS/Burst C# subset.

Re: Accidentally making a language, for an engine, for a game

#76
FTA :

> 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 !

Re: Accidentally making a language, for an engine, for a game

#77
post #60

Earlier quoted context omitted.

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 optimi…

Depends on the game engine, most 2D ones are quite comparable.

No no, browser contain components similar to a game engine, browser are way more complex, and frustrating, because you do not control the specs.

Re: Accidentally making a language, for an engine, for a game

#78

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…

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.

[1] https://www.pouet.net/prod.php?which=50131

Re: Accidentally making a language, for an engine, for a game

#79
post #19

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…

I pondered this for a while, still not sure why.

It could be the connection to the physical world. There is something satisfying about working with geometry and differential equations.

The realtime constraints force you to care about performance, which many people find a fun challenge.

Your output is the frame buffer instead of the DOM. It's more of a blank canvas.

Most web development is utilitarian, whereas games are more artistic.

I am not sure, but I would love to be a game engine developer in another life. I have zero interest in web framework development.

Re: Accidentally making a language, for an engine, for a game

#80
post #19

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…

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.
Post reply on HN