I hate when that happens.
Accidentally making a language, for an engine, for a game
151–160 of 232 posts
Re: Accidentally making a language, for an engine, for a game
#152Earlier quoted context omitted.
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, a…
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.
Re: Accidentally making a language, for an engine, for a game
#153Earlier quoted context omitted.
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.
Can you please elaborate on that, or provide some links?
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)
Re: Accidentally making a language, for an engine, for a game
#154Earlier quoted context omitted.
>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/tool…
What's the point in life if you don't get to work on what you find interesting. Those Yaks ain't going to shave themselves you know.
Nothing wrong with having a nice yak wool coat
Re: Accidentally making a language, for an engine, for a game
#155Earlier quoted context omitted.
Can you please elaborate on that, or provide some links?
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 proper…
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++?
Re: Accidentally making a language, for an engine, for a game
#156Earlier quoted context omitted.
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 proper…
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++?
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"
https://www.youtube.com/watch?v=fcBZEZWGYek
However not every single game out there is trying to fit Shadow of the Colossus into a PS 2 or XBox 360.
Re: Accidentally making a language, for an engine, for a game
#157It's unfortunate that the majority of comments are centered around Yak Shaving rather than the amazing leaps that this small language has done.
Every year millions of CS students invent new languages, and publish SIGPLAN papers about them.
This language is great for the author as learning process, and that is about it.
Re: Accidentally making a language, for an engine, for a game
#158Earlier quoted context omitted.
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…
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 re…
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.
Re: Accidentally making a language, for an engine, for a game
#159Earlier 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…
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.
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.
Re: Accidentally making a language, for an engine, for a game
#160Earlier quoted context omitted.
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 proper…
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.