Return to “General”

Post

Re: Remaking Limit Theory - From the ground up

#122
If the problem with float precision is the reason not to use Unity, there are ways around that issue.

You can make an almost infinitely large playspace, as long as you introduce a dynamic system that shifts the origin of localspace relative to the world-coordinates as needed when exploring.
The entities within the immediate space around the player then always have a high enough precision in their transform.
Really far away events by the AI can then be either simulated or calculated "offscreen", as part of a LOD system.

Its not too much additional work, compared to getting used to another engine that is not as well know by users.
Post

Re: Remaking Limit Theory - From the ground up

#126
Talvieno wrote:
Sat Apr 11, 2020 6:37 pm
Damocles wrote:
Sat Apr 11, 2020 1:30 pm
Its not too much additional work, compared to getting used to another engine that is not as well know by users.
I can't imagine the decision to use godot having been made by majority vote, seeing as nobody here uses it.
Shrug, so long as BFett signed off on it, it doesn't matter to us. :V
BFett is their god, and so long as they remember that, then all is well.
It's only a dictatorship after all.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Remaking Limit Theory - From the ground up

#127
Silverware wrote:
Sat Apr 11, 2020 10:00 pm
Shrug, so long as BFett signed off on it, it doesn't matter to us. :V
BFett is their god, and so long as they remember that, then all is well.
It's only a dictatorship after all.
I dont think its bad to have a defined lead on a project. I doubt that a "democratic" approach to making a game or any other complex project would work. That would just lead to agreeing on the smallest common denominator. It either need someone having the last say regarding design, or be like a competition, where people compete and the best implementation "wins".

But I have raised my concern in Discord about not choosing Unity for a specific reason (float precision), as it can be worked around (shifting the origin regularly towards the players position).
Unity is still the most prominent engine, with the larges user, tutorial, asset and code-resource base. And thus should be tried out creating a prototype.

I have also seen many "community projects". That then just fizzled out.

Getting a somewhat fun prototype out of the door would be paramout here to motivate people to stick to it.
Post

Re: Remaking Limit Theory - From the ground up

#128
Talvieno wrote:
Sat Apr 11, 2020 6:37 pm
Damocles wrote:
Sat Apr 11, 2020 1:30 pm
Its not too much additional work, compared to getting used to another engine that is not as well know by users.
I can't imagine the decision to use godot having been made by majority vote, seeing as nobody here uses it.
I am just wondering if silently moving part of the discussion to a new platform is the best way to have a broad community acceptance ;-). Are really all key persons on board?
On the other hand, such a project must have an active core team, so it is good to have a small group going forward - as long as these people are in for the long haul...

Now to a practical question from an absolute noob: I had a look at Godot:
A project seem to be all structured around the 3d world? Basically the core is the visualization? Where is the simulation residing? Can you on runtime make whole new „levels“ (star systems)?

For me it is a bit counter-intuitive: i would first build a universe (see this thread) and then based on a location create/load the assets to make a scene for the player.
In principle, I would (a bit like Dwarf Fortress, which I never played) first create a „living universe“ text and number based and then only populate it, first adding the „dialogs“ to interact with the simulation (commerce, text based mining, fights) and finally instancing the whole in whatever technology we can use (2d, 3d, with pre-defined assets or with assets generated on the fly - it may even be a browser game initially with forms to interact with the simulation).

This sort of guarantees a „living universe“ as it is a simulation running without the player. He can then interact with it, and if the scale of his interactions increase, finally influence/steer the simulation.
This allows paralleling the tasks also, as the core can have its own life and developers as well as the visualization/interface.
But this must be the old scientist/engineer that first want to simulate the system and is happy to read the raw output, before investing time for the visualization.
Image
Post

Re: Remaking Limit Theory - From the ground up

#129
Talvieno wrote:
Sat Apr 11, 2020 6:37 pm
I can't imagine the decision to use godot having been made by majority vote, seeing as nobody here uses it.
It was, actually, regardless of whether you can imagine it. :p
CSE wrote:
Sun Apr 12, 2020 2:31 am
I am just wondering if silently moving part of the discussion to a new platform is the best way to have a broad community acceptance ;-). Are really all key persons on board?
The discord is more meant so people that actually plan to contribute can discuss stuff in focused way.
CSE wrote:
Sun Apr 12, 2020 2:31 am
On the other hand, such a project must have an active core team, so it is good to have a small group going forward - as long as these people are in for the long haul...
Now to a practical question from an absolute noob: I had a look at Godot:
A project seem to be all structured around the 3d world? Basically the core is the visualization? Where is the simulation residing? Can you on runtime make whole new „levels“ (star systems)?

For me it is a bit counter-intuitive: i would first build a universe (see this thread) and then based on a location create/load the assets to make a scene for the player.
In principle, I would (a bit like Dwarf Fortress, which I never played) first create a „living universe“ text and number based and then only populate it, first adding the „dialogs“ to interact with the simulation (commerce, text based mining, fights) and finally instancing the whole in whatever technology we can use (2d, 3d, with pre-defined assets or with assets generated on the fly - it may even be a browser game initially with forms to interact with the simulation).

This sort of guarantees a „living universe“ as it is a simulation running without the player. He can then interact with it, and if the scale of his interactions increase, finally influence/steer the simulation.
This allows paralleling the tasks also, as the core can have its own life and developers as well as the visualization/interface.
But this must be the old scientist/engineer that first want to simulate the system and is happy to read the raw output, before investing time for the visualization.
You can actually do that, yes, because (and this is one of the reasons we picked Godot) you can plug in compiled C++ libraries very easily so we can use that to do the background simulation and use the engine for visualisation and physics and so on.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: Remaking Limit Theory - From the ground up

#134
And CSE, to your point: of course it would be a mistake to try to base an actual, complete "living world" game on a relatively simple piece of 3D ship flight code.

Which is why that's not what's happening.

It would also be a mistake for an evolving group of volunteers who have never worked together on a project before, using an engine that they haven't built code in before, to immediately skip to trying to build a full living-world architectural platform that's also capable of efficiently and attractively rendering AI-driven objects in a 3D space.

Which is why that's not happening, either.

As I see it (meaning that others might have a different take), here's what's actually happening at the moment:

  • People with technical skills are talking to each other, getting to know each other and their skillset.
  • We're exploring Godot to see if it can support an LT-like game. If it can't, we'll switch to something else.
  • 0111narwhalz is banging together a basic 3D flight prototype, working out key concepts of rotation, translation, and control.
  • BFett is prototyping UI concepts.
  • Several others (including me) are studying Godot projects to learn its strengths and constraints.
  • There is discussion of what tools to use for documenting and exposing project resources, feature plans, and development statuses.
  • There is discussion of what gameplay features the actual 1.0 Limit Theory Redux game ought to have.
  • There is discussion of what the core architecture of the first Redux prototype must focus on delivering.

In a word, this is pre-production. And that's just as it should be, because to jump directly to the hard problem of reverse-engineering Limit Theory as Josh proposed it would end this collaboration; that's too hard. Right now we're all sort of still looking around, thinking, "Is this really happening? Can we do this? Are other people serious about this? What can I contribute if this is really going to be a thing?" These are questions that can only be answered positively by starting with simple team-building tasks first, achieving some small but meaningful successes, and making that solid foundation the basis for the much more difficult design and development work required for the full project.

This would go a lot faster if we had Josh's LT code, or could pick Josh's brain. But right now neither of those is available. So the best we can do is start small and see if we can grow that into something playable. And that's what's happening now.

Online Now

Users browsing this forum: No registered users and 1 guest

cron