Return to “Dev Logs”

Post

Re: Friday, August 18, 2017

#16
Hyperion that is an amazing idea. As someone who is working on a game and hates art, i know it would help all of us artistically-retarded people out there an amazing amount. The possible uses for something like that are just so vast.
oh and i think this is my first post so:
Josh, the work you do here is inspiring, your work and dedication is just amazing.
Adam, I think we are all a little envious of you getting to work with josh, but all so so thankful for your input furthering this great project .
Sean, pity i didn't get to say hello to you before you left but thanks for giving us a way to make space battles even more glorious.

These last we months have been so great to watch as LT comes together.
So thanks to everyone making my most followed game of the last few years a reality.
Post

Re: Friday, August 18, 2017

#20
Hyperion wrote:
Fri Aug 18, 2017 7:42 pm
All this performant work makes me wonder if there will be some sort of GUI to play with these tools in addition to coding, making more of a "Game Engine" feel to things, giving LT something akin to a Procedural Unity or UE4 where you can generate infinite similar models or scenes.
That's a really nice idea, Hyperion. I had basically the same thoughts after reading that one sentence up there :D

It's like an evolution system that you steer artistically in the direction you want. Such a system could be used with R&D where you research a new technology and the game creates several designs and you choose the ones you like the most. Even the AI could use something like it for almost everything that it needs to build & develop. Generating ships and selecting the best designs to continue with, based on battle performance, cost, availability of construction materials, etc. It's also something for generating the backstory / history of the game universe.
professional lurker since forever
Post

Re: Friday, August 18, 2017

#23
JoshParnell wrote:
Fri Aug 18, 2017 11:01 am
  • Native memory types can be defined on-the-fly in Lua; behind the scenes they are 100% as compact as the equivalent type would be in statically-compiled C; accessing the memory is extremely fast due to fancy, custom memory-pool allocation magic done automatically by the engine. All of this complexity is hidden from the user, so code remains very easy to read and write.
  • Types can be nested in other types, enabling 'component-based' design, as demonstrated with Health and Weapon. Of course, since this is a full-blown type system rather than an ECS alone, we can do things like have multiple health components, which ends up being useful sometimes!
  • 'Member functions' can be attached to these types and called in the idiomatic Lua manner; convenience + performance = winning!
  • Generic functions like 'Weapon:damage' can be written without concern for the type of the target object and still 'just work,' despite the fact that we're using direct field access instead of table lookups like most dynamic languages (if you're a programmer and understand what I mean, that should blow your mind a bit :) )
  • (Here's the even-more-mind-blowing magic) Functions that can operate on different types of objects (like Weapon:damage, which could be used to damage stations, hardpoints, etc) will be traced by LuaJIT and end up running as fast as equivalent statically-compiled constructs (in C this would require a switch statement or function pointer, in C++ this would require a template or virtual tables; here it requires nothing extra!!); this is a HUGE win for both performance and simplicity!
  • Although I didn't show it above, types can be built in a piece-meal fashion rather than defined all at once. In particular, mods have access to type definitions and can inject their own fields and methods as required to support extra, mod-related data and functionality (I showed something like this in a devlog a while back). As always, giving modders the ability to add just about anything conceivable to vanilla LT is really important to me!
Josh, I hate to suggest this, but can I ask that you talk to the Lua/LuaJIT community and ask about possibly extracting these things into the language/compiler itself? This is very good work that not so many people could pull off, and I have a feeling that it could improve the language and the compilers/interpreters for everyone - I think it's important enough that it transcends LT and needs to become a language standard feature.

I really don't want to distract you from LT, but I think your work here is more important than "just" a game.

Very well done, indeed!
--
Mind The Gap
Post

Re: Friday, August 18, 2017

#24
Ringu wrote:
Sat Aug 19, 2017 12:10 pm
JoshParnell wrote:
Fri Aug 18, 2017 11:01 am
...
Josh, I hate to suggest this, but can I ask that you talk to the Lua/LuaJIT community and ask about possibly extracting these things into the language/compiler itself? This is very good work that not so many people could pull off, and I have a feeling that it could improve the language and the compilers/interpreters for everyone - I think it's important enough that it transcends LT and needs to become a language standard feature.

I really don't want to distract you from LT, but I think your work here is more important than "just" a game.
There are often tradeoffs involved that make this kind of facility inappropriate for incorporation into the mainstream. For example, if the speed is achieved by sacrificing safety - by ignoring type-checking and error handling - then it may be appropriate for a high speed game but not appropriate to put in front of a novice programmer.

And if it does not sacrifice safety, then incorporation into the mainstream can have huge costs to the originator. There is both the impedance mismatch between the coding style and documentation style of the two bodies of code _and_ the typical 'bikeshedding' where the mainstream question, sometimes stupidly, sometimes wisely, every major and every minor design decision. This could easily become a task to occupy several years of his life.

And if both the above can easily be overcome, then this is hugely valuable IP for Josh. He should keep it carefully and only give it in return for something very valuable to him. And who are we to say what that value is or should be? It could be the quiet pride of public contribution, having his name associated with the code, a masters degree, or several million dollars or something else entirely.

regards,
Charles

Online Now

Users browsing this forum: Bing [Bot] and 3 guests

cron