I concur, modding functionality is essential for community development of content. It will also off load work for the engine crew and provide a viable path for adding game elements so there is less hard coding of resources. It will also allow more options for testing systems since you can build a mod specifically to test a feature. I also have a preference for multiple systems. I could even see something like a series of clusters where 'winning' one campaign mod allows you to open up a new one. Leveraging the mod system as a means for linked missions/operations.

I think Josh nailed it, although time, money and patience caught up with him in the end.
We have gazillions of code that Josh placed on this forum.. why not use it, and help us understand a way to program LTCe (LT Community Edition) with the concepts that Josh banged out.
At the end of the day, I see LTCe as being a beacon (and a nod) to Josh, as the father of this community.

Moddability has to be in, so that we can create a multitude of systems to play-test with.
C/ C++ as the core engine, with a LUA-jit/ JS scripting language, that is easy to read, yet powerful
Have an option for both fixed and multiple star systems.. start off with 2x and scale up.
- Yes, flying about with nothing to do or see is boring, but we can scale down the distances so that we can use the warp rail system to view the planets/ Ai as they go about their daily routine.
- No quests, use jobs as a way to entice people to help out corporations as they see fit

I can't remember the other points, as you guys are so quick to reply to this thread, I can't keep up

P.S. I'm not talking about taking Josh's code, btw, but the concept of what he was trying to overcome, by posting the code, can give us insight on how to avoid other pitfalls, and possibly come up with better solutions.

Shadowrunner214 wrote: ↑

Mon Mar 30, 2020 12:41 pm

Talvieno wrote: ↑

Mon Mar 30, 2020 12:17 pm

n regards to AI entities (ships) perhaps a few hundred at the very most.

Could you have a functioning economy with that? I suppose it depends on the granularity of the simulation, but if you have raw materials that you have to refine, then construct components, then build the final product, you're going to need a supply chain, with actors at each level. A couple million is probably too much, honestly, but I don't know that a few hundred will be enough.

Absolutely! I even did a little simulation myself that handles something economy-like without any problems at all. It just takes a gentle hand, a good sense of direction, and a clever, well-thought-out execution.
http://talvieno.com/sims/civiliansim8.html

FormalMoss wrote: ↑

Mon Mar 30, 2020 2:10 pm

C/ C++ as the core engine, with a LUA-jit/ JS scripting language, that is easy to read, yet powerful

I'm still in favor of using Unity, simply because so many people here use it and it's such a popular tool. Complicated and/or lesser known tools are great if you're a solo coder or are working with employed professionals. We're not doing that here. If there's something else that could be used instead of Unity that ticks the same boxes, I'd be on board with that too. The important thing is to include as many contributors as possible in order to accelerate the pace of development. Even if we have to make sacrifices somewhere else. As I said before, I'd prefer we finish a game that is "less" than Limit Theory than half-finish a game that is Limit Theory. We've already had the latter happen, after all, and I don't think we want a community remake of that adventure.

Definitely would go with something like Unity. Building an engine is a special beast. If you don't have any experienced people in it (and it seems to me there are none until now), you could spend 2 years reinventing a wheel and will most probably end with a shitty wheel on top of it.

I just finished reading posts of this thread and here are my thoughts and ideas.

But before that I'd like to tell a bit about myself and my experience. I have about 10+ years of C/C++ and 5 years of C# coding. Also have quite some experience in other languages like Python, Java, etc. Now I'm using Rust as my hobby language. I was working in a different types of companies, mostly server side backend projects in C/C++/C#. Even in one game company at the beginning of my career . In my current company I'm working on AR project on Unity.
I don't have much time but depending on situation can spend several ours per week for this project.

First what I'd like to say is to make this project run properly organizational structure is most important. What I mean by this is that there should be a core team that will make a final decisions about what and how to do. This should be a team of designers, architectors and developers that will define a direction in which project should go. Of course it's should not be dictatorship and they should listen to others but final decision should be done by a dedicated team.
Otherwise I had a lot of examples when even in a big and solid company people can f**k up a project if there is no responsible manager/architect to define a proper roadmap for a teams. In such a situation different people and teams do whatever they wants and at the end different parts of the project just don't work together.
This core team should not be very big and people of course will join and leave it but it should be.

Now I'd like to talk a bit about technical things. Probably at this moment it's more reasonable to talk about higher level design and gameplay but I think that some technical moments can (and should) be discussed now as well.

First thing is a core of the game engine. As it was already mentioned by others for the game of such a size performance is very critical. I think nobody wants to repeat Josh's path. So as a core language we need something that gives the highest performance. This requirement immediately throws away most of garbage collected and scripting languages. So for me only C/C++/Rust and similar languages will be suitable. I would prefer Rust despite my big experience with C/C++ and about my reasons I will talk below.

Second thing is modularity/moddability. As other people already said in this thread this is a collaborative effort and we need this project to be modular. To achieve this we have to choose what communication interface to use between this modules. Only option I see in sense of speed and support by different languages is C FFI.
Also I think we have to support 2 types of modules: scriptable and native. Scriptable modules will be used for quick prototyping and and not performance critical things. So one can write a module in Python or Lua and quickly test it and if it works properly rewrite it in low level language if needed. The other idea that I have is that we can embed some modules in the game core. The way like it'd done in Linux kernel: you can load module dynamically but also you can embed it in the Linux kernel to gain better performance by avoiding intermediate layer. But this is just my idea.

As third, I think it should be decided at early stage whether to use existing game engine or to write custom one. Both of them have their pros and cons.

Game engine pros:
- A lot of architectural design decisions already made and a lot of code written.
- Most of existing engines have a good tooling and IDE's.
- Big engine community support.
- More developers that know this game engines are out there that can join the project.

Cons:
- It would be hard to optimize existing engine to the desired scale of our project.
- Programming language usually strictly specified by language. Some engines allow to use other programming languages but usually with performance and/or usability cost.
- We will have to deal with a bugs in those engines. Some of them have a big delay in bug fixing, some are not open sourced and it would be hard to track those bug down.

As an option Unreal, Godot or similar engines with a low level core languages can be selected. I would not advise to use Unity despite it's IL2CPP backend. What I see in my currnt project IL2CPP of course speeds up a code but steel not enough. It's ok for small and some middle size of data but when it comes to customer data size we still have a performance problem. But it's only my experience.

Custom engine pros:
- We can make it as fast as possible.
- We will choose in which language to develop it.
- Architecture of the engine can be developed with taking in account all desired features.

Cons:
- A lot of architecture design and coding work. Can be hard to support a big codebase.
- Can became a mess at the later stages of development if wrong architectural design decisions will be made at the beginning.

At the end I'd like to explain why I think Rust is a better option as a core programming language for a custom game engine.
As I mentioned above I wrote a lot of C/C++ code but what learned from it is whatever coding practices you follow, how hard you can try to make code correct you will always have all those annoying crashes, memory issues and my favorite (and hardest) multithreading bugs. And when project grows it became worth: different people have different styles of coding and not everybody follow advised coding practices. And simply you can be tired and miss or forget something. We are all human at the end.

I suppose some of you had such an experience when in a big company you have big and old codebase and main principle is: it works? - don't touch it. And if you have to change some code you usually copy paste some function instead of refactoring it. Bug fixing can be even more "exciting" (I remember one multithreading bug my team was hunting for a several weeks).

And here we come to Rust. I don't want to say it's a silver bullet but it let developers avoid a big amount of common problems: most of memory issues and also data racing problem. So here are some pros and cons of Rust from my point of view.

Pros:
- Prevents most of memory issues and data races problem at compile time. Developer just won't be able to compile code if it contains such an issues.
- As an consequence of the previous pro it is much easier to make modification in the existing code: you can be sure that your changes won't introduce any memory or data race problems (of course you can still introduce logical bugs but that's why we write tests ).
- Rust has a very good type system and because of that its compiler can generate very optimized code. Speed of the generated code if comparable with an equivalent C code or sometimes even faster.
- Very good and easy to use package management system (similar to npm).
- ...

Cons:
- Relatively hard language to start with. Learning curve is pretty steep for the most of developers.
- Not so much developers knowing Rust at the moment.

Don't take this as advertisement of Rust. It's just my thoughts.

It was pretty big post but I hope it will be helpful for someone.

Edit: Turns out that just restricts the types of licenses available, similar to Unreal.

The problem with using Unity is its licensing.

Part 2.6 (e) General Restrictions of the Unity Software Additional License prohibits:
"do anything that could cause or result in the Unity Software (including the runtime portion thereof) being subject to any open source license (or similar license) that requires as a condition of use, modification or distribution that the Unity Software (including the runtime portion thereof) or other software combined or distributed with the Unity Software be: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge"

In essence, it can't be distributed for free.

Unreal engine does allow you to use an open source license, but only of the very liberal kind a la MIT, BSD, Apache, and the like. However, any patches to the engine itself are (I think) still closed source.

Edit: link https://unity3d.com/legal/terms-of-service/software

Shadowrunner214 wrote: ↑

Mon Mar 30, 2020 3:49 pm

Part 2.6 (e) General Restrictions of the Unity Software Additional License prohibits:
"do anything that could cause or result in the Unity Software (including the runtime portion thereof) being subject to any open source license (or similar license) that requires as a condition of use, modification or distribution that the Unity Software (including the runtime portion thereof) or other software combined or distributed with the Unity Software be: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge"

In essence, it can't be distributed for free.

Actually, I think that prohibits you from making a game engine that's just a reskin of Unity. I don't think that applies to game applications that are created with Unity.

Yeah, thats about altering the engine so it's opensource.

The code on top? That can be as open or closed as you want.

Haron, read through your post (quite excellent and informative)! I agree with most of what you say, and it mostly makes sense, but this part stood out to me in particular regarding Rust:

Haron wrote: ↑

Mon Mar 30, 2020 3:35 pm

Cons:
- Relatively hard language to start with. Learning curve is pretty steep for the most of developers.
- Not so much developers knowing Rust at the moment.

In my opinion this is a very, very strong argument that more or less precludes Rust from being usable for this project, as there would be very few developers actually working on it, which means slow progress and a great loss of interest from most individuals involved.

RE: Custom engine: If Josh couldn't finish his engine in four years despite it being a full-time passion project he got paid for, I don't think we're going to manage to write our own engine as a ramshackle group of coders working on this as a voluntary hobby project in our spare time. Harsh to put it like that, I suppose, but we don't want to fall into the same trap Josh did. Whatever we decide on using must either:

1. Be very easy to learn
2. Already have a good number of people here that know how to use it
3. Both of the above

zircher wrote: ↑

Mon Mar 30, 2020 4:51 pm

Actually, I think that prohibits you from making a game engine that's just a reskin of Unity. I don't think that applies to game applications that are created with Unity.

I think you're right. I've seen a lot of Unity projects released for free.

Talvieno wrote: ↑

Mon Mar 30, 2020 7:50 pm

RE: Custom engine: If Josh couldn't finish his engine in four years despite it being a full-time passion project he got paid for, I don't think we're going to manage to write our own engine as a ramshackle group of coders working on this as a voluntary hobby project in our spare time. Harsh to put it like that, I suppose, but we don't want to fall into the same trap Josh did. Whatever we decide on using must either:

1. Be very easy to learn
2. Already have a good number of people here that know how to use it
3. Both of the above

I think that that's a very valid position to take on the technology that we may use. Perhaps we ought to focus on pinning down the vision for the project first? I'm just as guilty of losing myself in the shiny technology, but I think that it's so early in the process that it may actually be counterproductive to be making this a key facet of the discussion right now.

Let's focus on what we want to build before we think about how we're going to make it. We can adjust the vision freely to fit the tools that we have, but we have to have a vision of what we want first.

Shadowrunner214 wrote: ↑

Mon Mar 30, 2020 9:39 pm

Talvieno wrote: ↑

Mon Mar 30, 2020 7:50 pm

RE: Custom engine: If Josh couldn't finish his engine in four years despite it being a full-time passion project he got paid for, I don't think we're going to manage to write our own engine as a ramshackle group of coders working on this as a voluntary hobby project in our spare time. Harsh to put it like that, I suppose, but we don't want to fall into the same trap Josh did. Whatever we decide on using must either:

1. Be very easy to learn
2. Already have a good number of people here that know how to use it
3. Both of the above

I think that that's a very valid position to take on the technology that we may use. Perhaps we ought to focus on pinning down the vision for the project first? I'm just as guilty of losing myself in the shiny technology, but I think that it's so early in the process that it may actually be counterproductive to be making this a key facet of the discussion right now.

Let's focus on what we want to build before we think about how we're going to make it. We can adjust the vision freely to fit the tools that we have, but we have to have a vision of what we want first.

Two things need to happen at the moment:

We need to write a community GDD, to both compartmentalise discussion as well as get the designs down in a concrete, also more compartmentalised format. The current format of forum thread containing big bricks of discussion and no concrete information is detrimental to actually finalising decisions.

The second is that the base technology, being the engine and subsequent language needs to be decided. This is less pressing than the design documentation, but is a necessary discussion. It actually has a section in moth documents.

Bitrage/Shadowrunner helpfully creating a document containing a somewhat more concrete listing for features. My recommendation is that discussion of adding or removing features is made as commentary within this document. (The contents of the list are only initial thoughts, and will need revision, so comment away!)
https://docs.google.com/document/d/1tSq ... sp=sharing

Furthermore, a dedicated Game Design Document for expansion of the finalised design decisions should be contributed to. I've set up a document below, and will be adding in relevant headings to a GDD as a start. It should be noted that this is probably not something that will be immediately contributed to, as we first need to actually figure out what's actually going into the game. (It's a lot harder than designing on your own, as a side note) :V
https://docs.google.com/document/d/1IVK ... sp=sharing
Additionally, a core group of people should have editing permissions for these two documents, to make final decisions on the commentary and discussion regarding the contents (as was mentioned earlier).

Now, someone please volunteer to get editing permissions. BFett? Tal? :V

I'll volunteer, Black. Officially, though, I'm asleep right now. (As tends to be the case at 4am)


EDIT: Shadowrunner214 is now known as Bitrage, as he requested a nick change. Just to clarify things with everybody.

By the way, seems that Godot might be worth considering as well (as game engine)
https://old.reddit.com/r/godot/comments ... hour_game/

Multiplatform, open source, supports 3D, supports low level and high level scripting (C++ and a python-like custom language resp.), and the upcoming release supports vulkan and stuff)
https://godotengine.org/features

Dinosawer wrote: ↑

Tue Mar 31, 2020 2:45 am

By the way, seems that Godot might be worth considering as well (as game engine)
https://old.reddit.com/r/godot/comments ... hour_game/

Multiplatform, open source, supports 3D, supports low level and high level scripting (C++ and a python-like custom language resp.), and the upcoming release supports vulkan and stuff)
https://godotengine.org/features

I was also thinking about using one of the open source engines.
Godot or OGRE might be good starting points.

Dinosawer wrote: ↑

Tue Mar 31, 2020 2:45 am

By the way, seems that Godot might be worth considering as well (as game engine)
https://old.reddit.com/r/godot/comments ... hour_game/

Multiplatform, open source, supports 3D, supports low level and high level scripting (C++ and a python-like custom language resp.), and the upcoming release supports vulkan and stuff)
https://godotengine.org/features

Godot has been gaining traction in game dev communities recently. I don't know much about it, but I think it's safe to say that it'll require more work than Unity to get to the same place due to the obvious differences in development time, and resources.

It's worth noting that the backend of Unity is built in C++ though. I'm not sure how much of the performance issues that might alleviate, but any engine integrated functions should be faster. If Unity is used, it's also probably ideal to try and use DOTS. It's not in the best state documentation wise, but its performance is far beyond anything the standard setup could accomplish, and it's sort of the next generation of Unity, rather than being left behind.