Return to “Dev Logs”

Post

Re: Saturday, June 3, 2017

#17
That's the most exciting LT dev log in literal years. For the new team approach to have paid such dividends in such a short space of time, and to have finally settled the huge issue which has dogged development for so very long... my hat is off to you. I'm delighted to see things finally going well on this project once again (and I can only applaud the never-say-die attitude which has kept LT alive -- if not always kicking).

Well done Josh and team. I look forward to the ongoing developments.
Post

Re: Saturday, June 3, 2017

#22
Hi folks,
long time lurker here. I'm continuously amazed by the progress made, but I have a question, a pretty technical one I may add.

I know that this project was previously based on a C++ engine and even in the early days Josh wrote Dev Logs stating that he would implement everything in plain C, if he would start over. And here we are, plain C, even if some code of the old code base was transferred to the new one.
What I don't get is how it is possible to build a more flexible and more usable system (I'm talking ECSv2) in plain C. When I think C, the first thing coming to mind is speed and then simplicity, as I am not forced to know very much about the language, if I'm not alien to hardware and compilers. But it takes a while until I think of ease of use and abstraction capabilities.
From my point of view (C++ programmer) it is possible to build flexible (and sometimes even usable) things using C++ templates with some run time polymorphism mixed in. And again, Josh has already been there, deeming it to difficult to maintain, something I totally understand. I know that plain C is not my strong suit but I absolutely have no idea how this language could provide you with the means of implementing anything but the most rigid structures. Which does not have to be bad, its just contradictory when I read the Dev Logs, at least in my mind.

I get that a "component system" is all about composition, which in it self can be very flexible and is totally doable in C. But in the end, does this really solve all the issues you are presented with? Maybe I'm just to far away from this coding style but it seems to me that the occasional one level of inheritance may solve some issues in a more convenient way, maybe even without paying the run time price.

I would love if someone could give me some insight on this, preferably Josh himself ;-)
Post

Re: Saturday, June 3, 2017

#24
Yet another great devlog. I'm very happy to hear that the FPLT has been officially solved! Great work Josh and Adam. I look forward to next week's devlog and hopefully hearing about getting the old coded gameplay features converted over to LJ.

If this isn't the plan, would it be possible to outline the goals for the month of June? (Even if they don't end up getting reached)
Image
Post

Re: Saturday, June 3, 2017

#25
Cornflakes_91 wrote:You arent allowed to use the multithreading because you always say "nobody needs multithreading, get a better CPU".
This is very literally *NOT* what I say at all.
<insert IRC-Only swears here>

What I *DO* say, is that multi-theading is *HARD*. And that most games, at most, have a Gameplay and a Graphics thread.
°˖◝(ಠ‸ಠ)◜˖°
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: Saturday, June 3, 2017

#28
jonathanredden wrote:honestly 10,000 missiles and 100,000 game objects may seem mind blowing but I honestly believe that that number, isn't that much you should strive for hundreds of thousands of game objects if not millions of game objects, this game is truly a procedural game so these numbers are a drop in a bucket.
Yes, but the quote (emphasis mine) was:
we can perform non-trivial, per-frame logic on >100K entities @ 60 FPS with a good deal of headroom
I certainly anticipate that the game ultimately needs to track an enormous number of things, but I do not imagine that it needs to track very many entities at a per-frame resolution. Anything potentially on screen would need that. Anything out of view/range/system can surely have dramatically slower updates.
Post

Re: Saturday, June 3, 2017

#30
jonathanredden wrote:honestly 10,000 missiles and 100,000 game objects may seem mind blowing but I honestly believe that that number, isn't that much you should strive for hundreds of thousands of game objects if not millions of game objects, this game is truly a procedural game so these numbers are a drop in a bucket.
"Truly procedural" has nothing to do with the amount of objects you have active at once.

Online Now

Users browsing this forum: No registered users and 14 guests

cron