Return to “Announcements”

Post

Re: The State of Limit Theory Development, 2017 Edition!

#76
Flatfingers wrote: Josh is capable of seeing the potential risks to engaging with backers and fans.
This may be untrue based on evidence shown in the past. There is a reasonable argument to be made for concern about Josh's capability for making an accurate value assessment regarding specific actions. Such as (but not limited to) communication on a timely schedule, the amount of effort (and content) that needs to be put into devlogs or community communication posts, the functional basis of that content, requesting / using assistance as offered, among other things.

One thing I see perpetually on this forum is an elevation of "the Josh" to levels which are beyond human; certainly beyond that of a promising but young college student. The fact is that nobody comes prepackaged with all the answers, and many people who possess great strengths - including intelligence and talent for creation of something - also possess great weaknesses, or blind spots.

It's not unreasonable, then, to suggest that Josh's ability to understand fundamental concepts which are obvious to the majority of people regarding communication (or any other subject) may be foreign to him. It also *might not...* but accounting for the possibility is not outside the realm of diligent consideration.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#77
Ill just add my opinions relating to FPLT to the mix.

First of all i would agree with what other said that cutting features is the first thing that should be done and could easily reduce the size of the problem. A comment from josh regarding this would be nice.

Second in general i don't think there is a solution to this Problem. (besides True AI maybe) And it's not really a Problem specific to LT. Put it might be possible to find a good enought solution to this especialy if features get cut, leading to my third point.

Which is that i would suggest trying to use Haskell as your high level language if Lua turns out to not work. Maybe i am just personally biased as i really like haskell but it seems to fit your needs. It is a high level language that is unsurpassed in it's ability to abstract things leading to a reduced mental load as you only ever need to consdier the current level of abstraction (also less lines of code but maybe more terse). It has good performance comming close to C in some areas. And interacting with the C core library is easy to do.
Downsides on the other hand are that Haskell is a functional language and quite different to usual Procedural/OOP Languages like C/Lua (adding some time for you to get comfortable/productive with it). But it seems LTSL had some functional aspecst so maybe not that big a deal. Then while abstracting allows you to reduce your mental load once you have buildt and figured out how to best abstract things. Doing that in the first place requries a big initial investment of brain power. And lastly Haskell is also garbage collected which you have show to dislike and while Haskell has quite a good one i do see that it could cause issues at times.

Edit:
wow thats my first post. I though i had posted something previously. Guess i was lurking for so long i forgot i had never acutally posted anything.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#79
Ok so I saw this posted last night and I only had today to read it.
So first off, welcome back to the forums Josh, sucks to hear that your anxiety is still giving you trouble. I never required anything shiny, just to see you pop in once every so often.

Secondly, yes, I was still reading, it sounds to me like you've gained a great deal of wisdom and know-how these last two years, I don't think they're wasted at all considering how much you've learned, and I imagine you'll have learned a great deal about yourself as well.

Lastly, a question; did you ever through-out your problem-solving process, consider increasing the size of your developer team to more than one? Multiple perspectives might help overcome a problem faster, and I doubt anyone would be foolish enough not to recognise you as the creative lead.

It's enjoyable whenever I get to be part of your journey, so please, keep sharing! Highs AND lows.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#80
JoshParnell wrote:<3 Josh
The vast majority is happy to see you again, friend. Take care of yourself.
Good luck with LT.



If I may venture a question: At what size does the current system start to encounter severe problems? I know it is not your ideal solution, but perhaps re-defining the playable area is in order, allowing a periodic or low power system to update things not within the player's immediate concern.
I'd hate to see LT gameplay that is still unproven hampered by continued attempts at a difficult technical problem that may be more extensive than you realize. Is it time for a reality check?


If it is at all useful: Frontier's From 0 to 60 Million Player Hours in 400B Star Systems
Yay Metal! Non-backer from the pizza dimension ImageImageImage
Post

Re: The State of Limit Theory Development, 2017 Edition!

#81
But what simulation has ED in the background? I mean... seriously. Most of the "content" is instantiated, the AI is purely for specific purposes and pretty limited in scope, and the economy... well...

LT is supposed to be extremely heavy in the background simulation and that's essentially the problem I guess (*). The RAM tops easy because a lot of stuff in the background must happens in order to make a believable experience. Everything is AI-related, there are no scripted NPCs. We talked about this simulation and the simulation boundaries a lot before in other topics. It seems the thing is a bigger problem as previously thought...

(*) As in "absolutely clueless guessing here".
I have been - and always shall be - your friend.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#83
Anything more I might say about what Josh knows or doesn't know would just be speculation. So to the question of whether incessant negativity and disputation, on every conceivable action Josh might take, may have played a role in the two Great Silences, I will just observe that if so, it's understandable at a human level.

Not right for a publicly-funded project, no. But understandable that someone building a complex creation might need to check out for a while after a constant drone of "anything you do is wrong."

I don't exempt myself here, by the way. I've expressed criticism of some of Josh's choices. So if the never-ending chorus of "that'll never work" and second-guessing ever got to Josh (as it might any creator), a small part of that is on me.

I do try to pay for my criticisms with the occasional constructive suggestion, though. Those are on record here, too.

Having just talked about sounding critical, I'm now going to sound critical. But I'll preface this by acknowledging that I'm far from perfect myself, and this advice is worth no more than every cent Josh has paid for it.

In my first comment to Josh's return post, I applauded and encouraged his statement that he's going to replace Perfectionist Josh with Pragmatist Josh. That's much more easily said than done, so we'll see. But it's a step in the right direction, and it deserves encouragement. Replacing Scientist "100%" Josh with Engineer "90% +/- 5%" Josh would be a major win, for LT and, I believe, for Josh himself.

But subsequent comments here have reminded me: from his own statements, I believe that Josh has had not one, but two voices sabotaging his development. Perfectionist Josh is one of those voices.

Do-Everything-Myself Josh is the other.

Do-Everything-Myself Josh (maybe a cousin to "Showman Josh") insists that there are valid reasons for not letting anyone else help with this project in any way. Letting Francois do the music must have been a very difficult decision... but it appears to be the exception that proves the rule. Josh won't even talk about why he thinks he has to do everything else, from designing to coding to testing to project management to promotion to community management, all on his own, as his very first major commercial project, regardless of whether that insistence means that some of these things go for long stretches without being done at all, and despite multiple people with professional experience in some of these areas repeatedly offering their assistance for free.

I'm sincerely glad to hear Josh say he's trying to replace Perfectionist Josh with Pragmatist Josh. I hope he'll consider the suggestion that real, visible, results-oriented pragmatism may also require saying goodbye to some selected aspects of Do-Everything-Myself Josh.

Again, free advice, worth exactly what it cost. ;)
Post

Re: The State of Limit Theory Development, 2017 Edition!

#84
Very well stated, Flat.

I take only a single exception: though cost may be determined by what a purchaser is willing to pay for a good or service, *value* is determined by the effect (positive or negative) something has upon aspects (and people) of the world before entropy destroys all echoes of it.

Or in other words, you don't get to set the value of your own words, even if you're claiming zero. You can influence it, though, by making valuable (to others, and yourself) contributions, and I believe your post is such a thing. :)
Post

Re: The State of Limit Theory Development, 2017 Edition!

#88
JoshParnell wrote:While I've learned to temper my expectations and wouldn't say that I'm confident that LuaJIT will be the answer, I can say that it's by far the fastest scripting solution I've found.
I'd concur that it is one of the fastest options.

The other options that comes to my mind are Java & the more "scripting" friendly derivatives a lot web stacks use - Scala for example. Compiles slow like a %#%# but there's a reason why Akka and a fair lot of other performance critical web stuff was written in it. Ah, and they are actually fighting type inference and all that, too - but I'd think they got further than you did in the scope of LT. Don't see this as a challenge, though! :D It's good if you make some "ugly" cuts and hacks to avoid actually fighting these problems for another decade or two. You probably wouldn't even be much further than where they are now.
JoshParnell wrote:I have my reservations about Lua being garbage collected, and I fear that memory access, if anything, may make LJ infeasible.
This is worrysome. I understand LT is ambitious, but you might actually need to keep the requirements of <whatever thing the game will do> below the point where you need to tweak and optimize the very fast LuaJIT or its GC and memory that much, for a lot of reasons.
JoshParnell wrote:I can get Python to spit out tens of thousands of lines in milliseconds, based on ~100 lines of my meta-language. This solution is only a few weeks old, and is sort of a 'nuclear' option in the event that the LuaJIT solution doesn't work out. I'm fairly sure that I can get this approach to work, because it's kind of brute-force.
I'm quite confused why this same thing couldn't be just directly written in ~130 lines of C/C++ or Lua code or something.

Besides, even if you had discovered a syntax and function library of the gods that actually was very much better than any of C/C++ or Lua code, I think you might have a fairly annoying issue with compile times & debugging and all that.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#90
Thanks for the update Josh!

Tbh if you find a solution now the minimum we will have 1.0 is gonna be 2 years> and that's if you find a solution now let alone if you still can't find one in another 6 months!

My advice would be to change to UE4 - even better graphics and will probably take just as long. Or unity5?

Anyway I hope you find a solution soon so we see a game.

Thanks again and stay in touch :thumbup:

Online Now

Users browsing this forum: No registered users and 2 guests

cron