0111narwhalz wrote: ↑Fri Dec 07, 2018 6:31 pm
ddabrahim wrote: ↑Fri Dec 07, 2018 5:17 pm
The only thing I don't understand, why Josh was developing a custom engines from scratch?
There are so many engines and frameworks out there that could have been perfect.
Unity
Unreal
Godot
MonoGame
Urho3D
UrhoSharp
NeoAxis
CryEngine
Xenko
I may be wrong, but I got the impression that existing, publicly available engines simply cannot do what needs to be done for a game as ambitious as LT. Josh's earlier engine iterations couldn't do it either. We thought the C-Lua iteration could, and it looked like it all the way up to the end, but
something went wrong. I don't know what it was, but I hope for the community's sake that it wasn't a repeat of the FPLT.
Not really because it was "ambitious", but more because it had entirely different needs and there weren't any game engines out there at the time that could remotely handle what he wanted.
The tl;dr is simply that what Josh wanted was so niche that there wasn't a game engine out there that caters specifically to what he wants to do. And what does he want to do? Pretty simple: He wants a very large number of objects, powerful AI, lots of auto-LoD, procgen tools, and pretty texture graphics. In exchange for this he was willing to mostly drop physics, high-poly counts, advanced lighting and shadowing, and decent sprite handling.
This is the
exact opposite of what most developers want. Your average developer is content with (at most!) a couple hundred objects loaded in at a time, very basic AI, little to no LoD, no procgen. They
do, however, want lots of physics, high poly counts, and advanced lighting and shadowing - and especially decent sprite handling, because most newer developers find 2d much easier to work with than 3d, making it a more popular option overall.
What Josh needed simply didn't exist. It's no surprise he had to write his own engine. Star Citizen is trying to do the same thing and look at what their team of hundreds has managed to do with CryEngine. (I mean, just look at that framerate!) As a single coder, Josh needed high accessibility... and engines with high accessibility are typically a lot slower... unless you designed it yourself, of course.
Please keep in mind that Unreal Engine 4 didn't come out until 2014 (two years after the KS) and Unity was a sluggish mess back in 2012. CryEngine 3 had terrible performance too. These are probably the biggest factors in "why did Josh not go with a ready-built engine", but assuming we ignore that and ask "Why would someone make a custom engine for LT
today":
(Grain of salt before I begin: this is all hearsay. I've not personally used any of these engines. I've just talked to people who have and gotten their opinions over the past... six or seven years. Some of it may be slightly outdated.)
- Unity: Unity is written to be as generalized and accessible as possible: the "general case" engine. This means it's sacrificed other things to get there, such as performance and flexibility. Take a look at KSP for a decent example. If you make a single rocket ship too large, things start to act... strange. The framerate can slow to a crawl, too, especially if you're running on a lower-end computer. And the graphics? Certainly not anything to write home about. While Unity can be pretty, it doesn't do "pretty" and "performant" at the same time, and if you're trying to write a lot of AI code in addition to high use of the physics engine... haha, nice try sonny boy, but it ain't gonna fly. (Not to mention thousands of moving objects at once! KSP can struggle with the parts of a single spacecraft.)
- CryEngine: Poor documentation, lack of learning materials, clunky architecture for basically everything, archaic technical art pipeline by modern standards. It does one thing really well: Outdoor terran environments. Everything else isn't worthwhile unless you really want to pull it to pieces, and even then you're in for an uphill climb. Taken a look at Star Citizen recently? Even with a single station at minimum graphics it can pull my FPS down to < 5, and they have a team of hundreds. A single guy making the same thing isn't gonna happen.
- Unreal Engine: Absolutely not something you want to use if you're a single coder (aka Josh) because there are so many facets that it takes a team tackling different areas. Very steep and lengthy learning curve. Game data tends to be bloated, so games using Unreal tend to take up a lot of harddisk space; procgen really isn't something they were going for at all, especially not procgen textures - lighting needs to be baked as well if you have any sort of attachment to framerate (making it much more unsuitable for Limit Theory).
- Godot: Very limited use and difficult to find tutorials of any sort. Render is written specifically to be compatible with much older OpenGL and web support; graphics engine is a lot more limited than other engines. Multipass rendering (essential for LT no matter how you slice it) requires some difficult and costly hacked-together solutions. Josh would probably have to custom-write/rewrite a large portion of the engine just to make things look half the way he wanted - and given the tiny community and lack of documentation, this is a very tall order. The Kickstarter would probably never have happened in the first place.
- Monogame: Best at 2d. Platformers, top-down roguelikes, and isometrics are what it does best at. With a good deal of effort, you can get some 3d going too, but support for this is very limited. Non-windows IDEs are difficult to use, aren't free or open-source, and can do weird things at times. Very little documentation. Tiny community.
- Urho3D: Little documentation, and the engine code is poorly commented. Any changes you make require it to be recompiled through CMake or similar. Community so small you're not going to find anything to get it to work at all. It was "inspired by" Ogre, which is an engine designed purely as a renderer and had poor performance on large sets of objects to begin with, and struggles with things like complex AI. Obviously not ideal.
- NeoAxis: Only on Windows. Zero Mac or Linux support at all, last I heard. The community is dead and gone, and never coming back: the creator of NeoAxis silenced them (yes, destroyed his own community) back in 2016 because he couldn't handle criticism (even constructive). There have been no updates of any kind. NeoAxis might as well be considered dead. Apart from all that, and the documentation, it's terrible at things like AI to begin with.
- Xenko: Haven't even heard of it. With a precursory google search I can't find much in the way of documentation or even people talking about it. Doesn't look like something oriented towards what Josh wanted to begin with anyway.
As to "where Josh went wrong" at the end that made him start redoing the engine: As I see it, it's pretty simple, honestly.
Bigger grain of salt than the rest of this post! I have no direct confirmation of exactly what went on, and only able to assemble a picture of what happened based on what I saw in the push/pull logs and the conversations I'd held with both of them much earlier this year.
Adam and Josh are two entirely different types of programmers. Josh is a graphics programmer. Adam is an engine programmer. Josh just wants things to go fast, even at the expense of physics - he even
turned off physics collisions entirely for most of the dev videos! Adam, however, approaches it from a different standpoint: to him, physics are important. Second, Adam likes to use pre-built libraries and tools, whereas Josh wants to make his own. This was a common theme throughout LT's production cycle.
Some of the first major stuff Adam did with Limit Theory was all about engine work. He found different resources online and tried putting them into LT, with the goal and making collision detection work "decently enough". And it did! Unfortunately, collisions were still... strange. Collision detection does not a physics engine make, and if you hit an asteroid, there's no telling what direction you would've bounced off of it. Without a physics engine, you can definitely tell when one object collides with another object (for example, shooting a weapon at an asteroid), but if you want to model a ship hitting an asteroid, or two ships colliding, or semi-realistic docking? You need a physics engine too. This is something that I imagine bugged Adam a fair deal, seeing as he's an engine coder.
Enter the Bullet Physics Library: a modular, pre-built physics engine that you could plop down into the custom engine of your choice. It's built to be generalized and accessible, and, as is a common theme in this post,
generalization and accessibility do not play well with performance. Adam started implementing it back in... June? July? Somewhere around then, I think. About that time most other forward progress on the game seemed to grind to a halt. I don't know anything specific about what happened, so again - grain of salt - but I get the feeling that Josh found that Bullet Physics played havoc with LT's framerate - especially with the large number of ships and asteroids that Josh wanted to have.
And what does Josh do when he finds out the engine is running too slowly for what he wants? He doesn't change his requirements to suit the new restrictions.
He refactors.
Unfortunately, I've not gotten to hold a conversation with him in a long time, so I can't do much more than speculate about what went on between him and Adam, and why Adam left. I don't think speculating about that sort of thing will help anyone.