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.
Accidentally making a language, for an engine, for a game
71–80 of 232 posts
Re: Accidentally making a language, for an engine, for a game
#72I don’t get why are programmers so obsessed with the tools they use for the job? More than any profession
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
#73It'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…
Re: Accidentally making a language, for an engine, for a game
#74Earlier 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.
Re: Accidentally making a language, for an engine, for a game
#75> 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".
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> 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
#77Earlier 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.
Re: Accidentally making a language, for an engine, for a game
#78I 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 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.
Re: Accidentally making a language, for an engine, for a game
#79It'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…
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
#80It'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.