On the topic of what people would like to see in Limit Theory, a few polls come to mind:

How do you think you'll spend most of your time in Limit Theory?

What has you most excited to play Limit Theory? (December)

What type of ship you will focus on mainly.

What will your occupation be in LT?

I think these give a general idea of what most users on these forums would like the game to entail. Just glancing at the results I'd say people would like a game that: is tactical on a personal level, is fun and engaging for those who like to explore, and has ships of all sizes.

I believe this is the general scope which this project ought to focus on. Does this sound reasonable?

Silverware wrote: ↑

Sat Mar 28, 2020 9:48 pm

IMO, the most important factor for choosing a language is the Speed/Ease of Coding ratio.

If we try to build something that does what LT was originally planned to, and we'd likely have to do large swathes of it in C with custom rendering pipelines to get the performance out of it.
But if we go for something far more modest, we might be able to get away with something as easy to code (but slow) as JS.

I think that at this point, the key is not choosing technologies that will bite us really hard later. Especially in terms of performance and flexibility.

Have you looked at https://ourmachinery.com/? Though it's still in beta, it might offer a good framework to work from. The interfaces are in C, but the modular nature means that if we have to, we can FFI the thing like crazy (please don't...).

Physics, AI, and Rendering in C or a language of equivalent performance, with gameplay attached to a language adapter would work fairly well, I think. The standard engine & script paradigm, really. If we use something like Rust or D linked via FFI, you get both the benefits of a prebuilt framework, and a much more advanced language that is designed with C interoperability in mind.

Really, I think that it offers sufficient flexibility but still provides enough support so that we don't have to write the entire engine from scratch.

Unless you want to write the engine from scratch. I'm game for that too.

Edit: Also, multiplayer support???

Shadowrunner214 wrote: ↑

Sat Mar 28, 2020 9:58 pm

Edit: Also, multiplayer support???

Careful with that one. I wouldn't consider it a "must have" for certain, and while it would be cool to have, it might be better to shelf that sort of thing unless it's particularly trivial to implement with whatever we decide to use.

Problem is, if the design doesn't acommodate for it, it might be nigh impossible to retrofit it later. At least, that's my understanding. I've never attempted to do multiplayer anything.

Multiplayer or not, the core of the engine should end up written around the way MP works, SIMPLY to handle the offloading of systems that arent in use, and coarse calculations on distant systems.

Small tangent, 3D and javascript have come a long way. Here's a demo from the current Babylon JS release...
https://www.youtube.com/watch?v=zHpI-6r2vw8

Not saying that Babylon JS is the best way to go, but it is a full game engine with physics and such. And, it is free and being actively developed.
--

Unity would be another good starting point. C# scripting is kind of familiar to a lot of other languages, large asset store, good community, personal and student editions are free. As a complete game engine, it also supports the structures and functionality for game play.
--

Unreal game engine also has some free options, but I really don't think it would be a good match for a space game. I've seen some people try, but the engine is optimized for FPS shooters. You can fake it, but at the core, you are still fudging its innate behaviors.

So far, Unity sounds like it would probably be the best bet. There don't seem to be as many hard limitations as with other things, it runs quite well, and - most importantly - plenty of people know how to use it. At the very least, Silverware, DWMagus, Black--Snow, and IronDuke are proficient at using it.

Doesn't unity have issues with large size gameworlds? Or did they finally invent doubles in the meantime?

Whatever you manage to cobble together, give it a decent name - and go easy on the dust!

Considering that almost all of the large-scale space-sims I can think of,have custom engines (specifically: all the X-games, Elite: Dangerous, No Man's Sky, Avorion) and the one exception uses a heavily, low-level modified Cry-engine (Star Citizen), I think we'd either need source code access to one of the decent available engines (to plumb in double-precision support, have machine code for the taxing parts of AI ans simulation) or we should build a custom engine ourselves.

While Josh didn't seem to have done a lot of research on available pre-built engines, he did put in a lot of effort into determining what should go into a custom engine. So we have a basis for discussion at least.

Long story short: I'd vote for a custom C++ engine with (Lua-JIT?) scripting support. I think we could swap out OpenGL with Vulkan. This would also open up the possibility to have Mac support again (using the moltenVK lib).

zircher wrote: ↑

Sun Mar 29, 2020 12:17 am

Unreal game engine also has some free options, but I really don't think it would be a good match for a space game. I've seen some people try, but the engine is optimized for FPS shooters. You can fake it, but at the core, you are still fudging its innate behaviors.

Everspace uses the Unreal engine and it seems to work quite well. I don't know though, whether they did some low-level plumbing...

insta wrote: ↑

Sun Mar 29, 2020 4:43 am

zircher wrote: ↑

Sun Mar 29, 2020 12:17 am

Unreal game engine also has some free options, but I really don't think it would be a good match for a space game. I've seen some people try, but the engine is optimized for FPS shooters. You can fake it, but at the core, you are still fudging its innate behaviors.

Everspace uses the Unreal engine and it seems to work quite well. I don't know though, whether they did some low-level plumbing...

everspace has very small levels, not much they'd need to modify.
compare the scale of everspace with what was working in LT
(same with ES2, just with fancier level transitions)

Cornflakes_91 wrote: ↑

Sun Mar 29, 2020 8:31 am

everspace has very small levels, not much they'd need to modify.
compare the scale of everspace with what was working in LT
(same with ES2, just with fancier level transitions)

I agree, Everspace is nowhere near the scope of LT. But it disproves the point that UE can't handle space games (well).
Having said that, IMHO UE would likely require major plumbing under the hood for something like LT.

Dinosawer wrote: ↑

Sun Mar 29, 2020 3:13 am

Doesn't unity have issues with large size gameworlds? Or did they finally invent doubles in the meantime?

The basis of the system is still floating point numbers, but I don't see an issue with precision, really. If 1 unit = 1m, you've got a pretty significant field to play with, and the precision issues are realistically quite small, no?

You're not looking for systems more than a couple hundred kilometres apart, right?

Nathan, what is the possibility of gaining access to Josh's engine?
Considering one option of creating a similar C-based engine, with Lua-jit.
I know there's legalese involved here, but do you have access to Josh's source?
Is there any time limit on accessing that, remember how he said if he was out of touch for x amount of time, the source being released, or some such?
P.S. kinda like a will of sorts, should something happen to him.
P.P.S. I'm just asking, not saying that we should.