Return to “Announcements”

Post

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

#91
@Rad, it's also concerning that rather than create a game within the limitations of languages currently available, Josh seems to be trying to expand what the languages are capable of to suit his (naive?) ideas of what LT could be. He seems to have been wrestling with this for years now and not really getting any closer. Might it be time to scale LT back into something that's actually possible? Maybe that's where the 'pragmatic' Josh comes in.
Post

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

#92
Just a thought since I'm a fan of the language - LuaJIT seems like a fantastic option in terms of speed - one other option you might consider though is D. It's a compiled language, though the garbage collection might be a deal breaker, I do recall seeing a talk on youtube about a game studio that successfully used it as a scripting language by having their engine hot swap compiled .dlls
Post

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

#93
yeswalrus wrote:Just a thought since I'm a fan of the language - LuaJIT seems like a fantastic option in terms of speed - one other option you might consider though is D. It's a compiled language, though the garbage collection might be a deal breaker, I do recall seeing a talk on youtube about a game studio that successfully used it as a scripting language by having their engine hot swap compiled .dlls
It's funny you mention that -- at the beginning of the week I did some preliminary exploration into D, and have decided that it warrants further consideration. I will probably look over it more carefully next week and see if it seems like something worth pursuing.

What would be fantastic about it is that it could be used as a scripting language -- as you said -- as well as the engine language (I don't mean replacing the C library, but the stuff that sits between super-performance-intensive and not-performance-intensive would be a great candidate).

If I understand correctly, you have full control over the GC, and can turn it off and manage memory manually. I'm also impressed by the metaprogramming facilities. Seems like I might be able to write code with similar performance to C++ but far fewer lines if I can get fluent with the metaprogramming. And about hot-swapping .dlls -- I also really like that the compiler is clean and self-contained such that it could potentially be shipped with the game (I think?) and mods could actually be partially 'compiled' into the game, leaving no perf gap.

The coming days will give me a much better idea of how LuaJIT will hold up, but it's nice that I still have quite a few options even if LJ doesn't end up being the solution.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

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

#95
JoshParnell wrote:...
It's funny you mention that -- at the beginning of the week I did some preliminary exploration into D, and have decided that it warrants further consideration. I will probably look over it more carefully next week and see if it seems like something worth pursuing.
...
Another option can be Rust. The biggest benefit of it is safety. It provides a lot of compile time checks that prevents most of undefined behavior and race condition problems from another languages. It also doesn't have GC and promises performance comparing to C/C++. The biggest disadvantage/difficulty of Rust for me was a high entrance level. Even with my 10+ years experience in C++ it took around month to understand and start to use ownership/borrowing paradigms properly. Very big help in this I've got from Rust's compiler. It provides excellent errors description and in most of cases how to solve them so now I'm very rarely get any errors related to ownership/borrowing. And also I didn't see yet any UB or race condition bugs in my code.
So Rust potentially can be a good alternative to C/C++ code.
UPD. Also Rust community is very helpful. Whenever I ask for the help on IRC or forums there is someone who will answer.
Last edited by Haron on Wed Jan 25, 2017 3:52 pm, edited 2 times in total.
Post

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

#98
JoshParnell wrote:
yeswalrus wrote:Just a thought since I'm a fan of the language - LuaJIT seems like a fantastic option in terms of speed - one other option you might consider though is D. It's a compiled language, though the garbage collection might be a deal breaker, I do recall seeing a talk on youtube about a game studio that successfully used it as a scripting language by having their engine hot swap compiled .dlls
It's funny you mention that -- at the beginning of the week I did some preliminary exploration into D, and have decided that it warrants further consideration. I will probably look over it more carefully next week and see if it seems like something worth pursuing.

What would be fantastic about it is that it could be used as a scripting language -- as you said -- as well as the engine language (I don't mean replacing the C library, but the stuff that sits between super-performance-intensive and not-performance-intensive would be a great candidate).

If I understand correctly, you have full control over the GC, and can turn it off and manage memory manually. I'm also impressed by the metaprogramming facilities. Seems like I might be able to write code with similar performance to C++ but far fewer lines if I can get fluent with the metaprogramming. And about hot-swapping .dlls -- I also really like that the compiler is clean and self-contained such that it could potentially be shipped with the game (I think?) and mods could actually be partially 'compiled' into the game, leaving no perf gap.
Technically you do have full control over the GC, but many of the libraries rely on it heavily enough that you have to jump through a huge number of hoops to disable it - recent work on the language has been around making this easier, but IMO it was a bad design decision from the get-go if they wanted to be suitable for real-time applications. It's been a barrier to people adopting it for game development in the past, so be warned. The metaprogramming facilities really are top notch though. Here's that talk I mentioned: https://www.youtube.com/watch?v=FKceA691Wcg

Someone else mentioned Rust - I'm not super familiar but my impression is that it's primary draw is a rather ingenious concept of memory ownership that can be checked at compile time - if you find yourself struggling with null pointer dereferences, memory leaks, or things of that nature it'd be worth considering but IMO if you're comfortable with C it might be more work than it's worth to port the core engine over at this point.
Post

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

#99
Re: Updates (with something to show):

Another KS project which many consider vaporware at this point recently released an update with a table including bars of progress on various goals.

Josh: would something similar to this which includes bars with titles like "testing viability of LuaJIT," "testing viability of D," as subcategories of a supercategory "searching for scripting language solutions to deal with FPLT" be feasible?

It's not screenshots, but (if such a table is updated to reflect progress over time) it would provide a tangible indication of what you've been working on, even if there's not code or game graphics to demonstrate that progress.
Post

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

#105
Starbuck wrote:
Josh, can't you take the LT core c++ code and switch to ue4? Or will the epic subs cost too much?
Dinosawer wrote:
What makes you think that would improve anything?
Well the graphics would be slightly better and the engine is already written so it probably wouldn't take half as long :roll:

Saying that the subs would probably be too expensive although it's only 5℅ of profits paid quarterly and at least we would see a game in the not to distant future lol.

I'm just worried in two years LT won't be finished and all of Josh's money will be gone and he may have to take another paying job to pay to work on LT in the evenings and that means less time on LT and more dark days etc etc and it will take even longer to finish the game hmmm not good!

Online Now

Users browsing this forum: No registered users and 20 guests

cron