Return to “Announcements”

Post

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

#18
Thanks for the update, Josh! Here in Austria your post arrived on Monday morning and it made my day :)

I loved your videos and screenshots, but to me as a software developer it's almost as interesting to read about the development process with all its ups and downs. Incidentally I read about LuaJIT and its advantages a few weeks ago, sounds like a very good move!

Regarding fireworks, showmanship, glamorous promises and the like: If I've learnt anything from running a software business, it's that business doesn't really need that. Marketing often does, but since you already have KS backers and a community, you probably won't need marketing until shortly before the release of LT. A company's statement to shareholders always includes a section about risks and negative developments, no matter how well business is running. Telling raw business truths is a good thing imho, it results in realistic expectations. No matter if things go great or turn out to be a dead end, we appreciate if you tell us about it...just as long as you don't attach screenshots ;)
...traveling through time at 1 second per earth second...
Post

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

#19
Thank you for that post, Josh. It goes a long way to providing what I hoped to get from you when I backed LT on Kickstarter.

I agree with everyone else that you don't need to be so detailed all the time, only when you choose to be. Simple updates are good enough, no fireworks needed, ever.

I greatly appreciate the honesty and would ask you to remember that you need feel no shame or upset just because you don't know how to solve the FPLT. Solving that is an architectural issue more than a coding one, and experience and a bit of luck is mostly the only way to resolve it - and you're gaining experience by trying solutions and failing. That's perfectly fine, and is what development is all about. Don't feel bad about sharing that!

My take on FPLT is not worth giving: you'll figure it out, I'm sure.

Ringu

* For anyone else reading this, my experience suggests that the 100k LoC limit is a psychological limit that you break when you realise that you only need to recall architecture in detail; code modules with clear, obvious lines of code will manage themselves. Write code like a 6-year-old, comment the algorithms you use, and you won't need to remember those lines because it's obvious when you look at it a year later what's going on. Remember what the modules do, test the modules, and reduce 1 module to 1 LoC in your head. It takes some time and experience of failed projects before you realise this by yourself, and honestly, it may not be possible to take this on-board without coming to the realisation yourself either. For this reason, it's pretty fruitless trying to tell anyone this.
--
Mind The Gap
Post

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

#20
So glad to have an update, and to know Josh hasn't returned to the dark places.

Flatfingers and charnode say it all for me:
Flatfingers wrote:FIREWORK POSTS ARE NEVER REQUIRED. SIMPLE IS ENOUGH.

Please print out the above statement in a suitably large typeface and pin it immediately above your main working computer.
charnode wrote:I do think, however, that you're misreading the community's expectation regarding desired information. Sure shiny stuff is nice, but I will always take bits of Information on the current state, with or without visuals. Backers went on an Adventure with you, not against you. It was very clear that there was a risk of Limit Theory never happening. As long as it is though, please keep talking to us, no matter however mundane you deem progress is. The suggested every other week rhythm would seem to be a nice middle ground to not distract you too much from working on Limit Theory.
I've backed several games on KS. Some have panned out nicely, some have just panned. KS is a gamble, and I'm fine with that; mostly I just hate the not knowing. Interestingly, I find myself caring more about the developer than the game here. Maybe because you've been so open about the problems you've had? Regardless, fortnightly communications, even "I've made no progress, but other than that, I had a nice week." will satisfy me.

Anyway, glad you're back, & I hope to see short but regular updates starting in a couple of weeks!

(P.S. Seriously, print that out & stick it somewhere prominent. Do it. Do it now.)
Post

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

#21
JoshParnell wrote:With the most practical option shot down, I switched attack vectors and tried what seemed to me the next most practical: splitting the C++ into smaller bits to make it more manageable. I split up what was a 'monolithic' engine, compiled all into one library, into component pieces compiled into different libraries (libltcore, libltrender, libltui, libltai, etc.); this was an attempt to increase both runtime efficiency and my ability to keep all code in RAM. This attempt, luckily, only cost me a few months, as I quickly learned that code is code, and the programmer RAM limit applies no matter how you divvy up the lines. Another solution shot down, another lesson learned.
Sad to see that you have abandoned the likely correct approach. I, too, am a software engineer / project manager, and deal with (very) large codebases, so I know what it's like. But what you need to do, is instead of developing each of those in parallel, develop and complete each one separately, so you focus solely on them and they are 100% built before moving onto the next separate module. Document your code and structures well (each and every bit of logic, each and every function, each and every class, each and every source and header file, each and every module) and keep the same formatting standards, so when you come back (which you inevitably will, to make little tweaks) it is easier to pick up (and it is your code, you know your code better than anyone else). At this point, you should never need to go back and rewrite substantial amounts of code, as you are well versed in what you need to achieve and how to achieve it - nothing should be foreign or require much thought from you any longer. When a module is completed, you can now swap the contents of that memory, and mark that memory area as "available to allocate more memory to", as you will no longer need to remember the entire structure of that module, rather just a high level "table of contents", if you will, so you can easily jump to and track down the relevant and necessary section / information from your documentation that you made. You shouldn't ever need to retain the complete contents of more than one module at a time in your mind as, as you have experienced, quickly suffer burnout. Also, take the weekend off. Don't post status updates on Sundays, do it at the end of the week on Fridays.

If for whatever reason that fails, you should seriously consider hiring a second person to help you complete it - have a team of two, and increase your LOC count / available memory from 100K LOC to 200K LOC. Or go back to university and learn how to properly manage a project.

And with regards to the communications front, just post bi-weekly, or whatever is a comfortable routine for you, even if the posts are simply just, "I have made no progress". No need to sport fancy screenshots, only few in the community want that. More just want status updates.
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill
Post

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

#22
Very happy to see you are still around! :wave:
Reactions...

As a human-being: I am really happy to hear that you are doing fine. I was expecting the worst. If it's "only" code problems, than it is not a tragedy!

As a guy one generation older :shh: :
How long can you still afford (both financially and for your own personal development) to work on LT? Perhaps the correct approach is to have a deadline where you deliver what you have, not a list of feature that must be contained... even if that means a 2D-top-view version of the game or that the game has no fractions, missions, blueprints, research, [insert features]!
An exit strategy may be required!

As a Programmer (disclaimer: this is more than 10 years ago, and I got only to ca. 50000 lines of code):
Similar to Flat, I think you go at it the wrong way: don't try to find a solution that is almost certainly close to impossible, or at least not realistic for a one-man-show (within the LT-scope) to the size vs. performance problem.
I would accept the problem, and simplify the task until the performance hit (both in terms of fps as in terms of "developer's RAM") is acceptable. This may require lowering the details of the models, making scanner scan every 20 frames instead of every frames, and most likely striking whole features: it will have a negative impact on the game. Accept it!
But this negative impact is acceptable in order to get the game out. With a bit of smart, you can even work that into the "history/background" of the game to make it more acceptable. Example: lower definition of models when many ships in system is due to overload of passive sensors (and hidden with an artistic, but computationally cheap local blur); scanners have a combat mode where they deliver much less info (e.g. composition of ore), but quicker...
This means making a profiling study of your code, and not optimizing but reducing/cutting the features that drag the framerate.
(and reducing/cutting features takes the number of code line down, as per primary objective).

As a customer/backer: extremely unprofessional. However great your product is, you took a serious hit in seriosity and trust. For the good of your future: behaving like a professional with clear communication policy: bringing bad news timely to your customers are at least as important as the quality of your code. The reason is that in most situation, with huge projects and teams, the geniality of one member will not compensate for a bad cooperation/information flow.

[Edit for clarity]
Last edited by CSE on Mon Jan 23, 2017 6:47 am, edited 5 times in total.
Image
Post

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

#23
JoshParnell wrote:Is anyone still listening? :shifty: :ghost:
Uhh, what? Yes, of course!

I really don't give two flying rats' arses about glitzy progress reports.(1) It's largely not how the real world works.
With a big team project you could usually show what the art department is working on. Most of the interesting and gameplay-relevant issues get at most one line in a change log.
Like this. This is how the level scaling of zombie / random hordes is set up so that I can keep "data sheets" for the various cases and "load" a certain sheet into the grinder... which then produces copy/paste-ready XML code.
Handling this much data and iterating/balancing it for actual game use would be flat out impossible by editing a text file by hand. Plus 50 new typos and bugs every time you did it anyway. And it was one line in a change log and nothing that would ever be mentioned in a video of any sort. That's real game development. =)

(1) I'm still not sure how the rats in question got to fly in the first place. Was it merely ballistic flight? Are they super-powered rats where talking smack about them would be inadviseable? And what's so special about their posteriors anyway? Would rats' heads or left forepaws not work equally well? Or is that some kind of social convention? The real world can be so difficult.
There is no "I" in Tea. That would be gross.
Post

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

#24
JoshParnell wrote:Cornered and out of options, with a community expecting an imminent RTB post, my kernel crashed. And it crashed hard.
to say it bluntly: Du bist ein Depp! ("you are a fool")
before you crash because you cant keep a promise tell us that you cant keep that promise.
much better than this incommunicado stuff that happened, and much less rage inducing for us and thus less anxiety inducing for you.

Gameplay, yes.
could you share some of those gameplay thoughts with us?
(preferrably in a related thread)
i needs mah fix :monkey:

Q. Sweet, so, screenies?

:3

honestly, its not for better/new shinies its simply because we only have so much stuff to look at and theorise about and want more of that :ghost:

i'll go now hide in the corner of shame for asking you the same thing again :ghost:




Edit: netzbummler 's right
Last edited by Cornflakes_91 on Mon Jan 23, 2017 10:17 am, edited 1 time in total.
Post

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

#26
I have to say first of all, thank you for doing an update.

As already said by some previous posters, these updates don't need to be crazy big presentations. This has been said over and over again by various persons. Either you just disagree or cannot mentally do anything different. Regular small communication goes much further than large sporadic communication.

On screen shots, as said by others, I think you might have missed the point. Yes, we would like to see new stuff, but screen shots showing nothing new is much better than nothing at all. It's not like it takes much time to do a couple screen captures either. So... please? :)

I'm not going to lie, I am somewhat disappointed that most of the progress over the last two years has been "sideways" progress. However, bad news is better than no news in this case.

I do have to ask (and it was asked by someone else before me on this thread), how long can you go before you have to throw in the towel or have to make some cuts to just get it out the door? There has to be some sort of cut off point when you need to find other employment..
My Signature
Post

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

#28
repost from my reddit comment:

Most Kickstarter projects I've backed seem to fall into the same trap of "Well, the backers only want to hear the good stuff, and the easy to grok stuff. So I won't share the bad stuff or the more technical stuff."

Yes, I like shiny.
No, I don't like years of no communication, because there's no new shiny to show.
Yes, I prefer to hear when stuff goes right AND when it's hitting the fan.

I already trusted you with my cash, therefore don't be afraid to also show the ugly side to product development.

To Josh, I implore you, you promise now to have a semi-weekly devlog, keep that promise, pretty please? Even if it's the message: "Well I tried LuaJIT, and I've had to scrap that idea because it didn't improve performance enough. Back to the drawing board."

Also, look at multi-threading...


*addendum* Adding screenshots offers a bit of surety that LT still functions.
avatar made from a photo by abbyreed
Post

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

#29
Nearly spewed coffee when I saw the RSS feed lit up. :?
Strange indeed --mysterious-- that last night, of all nights, in the wee smalls at work, I began to wonder anew (and I don't often) 'What's Josh up to? Is he ok? I hope LT is progressing well...' :ghost:

JoshParnell wrote:Is anyone still listening? :shifty: :ghost:
All ears! The vivid imagery and character of your posts have upon me an unparalleled entrancing power.
Last edited by Baile nam Fonn on Mon Jan 23, 2017 7:42 am, edited 1 time in total.
"omg such tech many efficiency WOW" ~ Josh Parnell

Online Now

Users browsing this forum: No registered users and 16 guests

cron