Return to “Dev Logs”

Post

Re: Adam - Monday, October 2, 2017

#77
Cornflakes_91 wrote:
Mon Oct 02, 2017 2:18 pm
AdamByrd wrote:
Mon Oct 02, 2017 12:10 pm
If others are similarly disinterested in the other 50% of the Limit Theory team and this is time poorly spent, I'll adjust accordingly.
You could also spend a fraction of the time you spend on writing updates on talking with the community manager who was hired exactly for handling community interactions.
Like outlander suggested, 30 minute skype call and you dont have to talk to the community yourself.
Heck just use Tal for rubberduck debugging and have that done while doing productive work.
That applies to both of you, josh and you.

And may jump into irc at some point to actually get to know the people who kept at least some semblance of life in the forums over the ages.
The same people who made the whole endeavour possible in the first place.
You dont even have to be overly talkative. Just look into the chat and feel the pulse, and dont view the people as a nuisance to be dealt with to get going on the thing that actually matters.

We arent just npcs there to annoy you, we are people who have been hanging on for almost half a decade now for the thing josh (and nowadays you) are building.
We are the people who made it possible in the first place, we are the people who are going to keep it being possible.
I'm sorry, Cornflakes, I missed your contribution to this thread. :angel:

And the input from outlander was also appreciated by me, thanks.
Post

Re: [Adam] Monday, October 2, 2017

#78
AdamByrd wrote:
Wed Oct 04, 2017 9:28 pm
Flatfingers wrote:
Wed Oct 04, 2017 7:29 pm
Moving back to the South from northern Virginia was one of the best decisions I ever made. YMMV.
It's not so much that the south is 'bad', just that I've been here my whole life and I need a change of pace. I was excited to move out of Florida for grad school, but Louisiana is way more culturally southern so it felt more like doubling down than changing.

I grew up in Louisiana, and spent a fair amount of time in Baton Rouge. (My grandparents lived a couple of blocks from where your offices are today.)

So I both fully support your thought that it would be interesting/helpful/fun/enlightening/pleasant to go live somewhere else that's different, as well as the perspective that every place is both satisfying and frustrating for different reasons, and sometimes one discovers that Home wasn't so bad after all.

...all of which is sort of tangential to the thing (LT) that we're all here to talk about, so I won't belabor it further.
Post

Re: [Adam] Monday, October 2, 2017

#79
(I have lived a while in Lafayette, where those Cajuns reside :) ..)

@Adam:

Since your game logic (the simulation) runs at a fixed interval time-step, how do you smooth out the framerate?
Lets say its running at 10 FPS for the updates (logic ticks), and at a 60 FPS rendering speed, there would be 1 "slow" frame (randering and logic), and 5 "fast" frames (only rendering).

Its there any issue with "jittering" with this approach?
Post

Re: [Adam] Monday, October 2, 2017

#80
Did you notice that a lot of what happens here is similar to a meeting of a self-help group?

There is a bit of tension between people, mostly because of dissapointment. And thats why Adam is now kind of a savior to most of the small community LT has left.
Josh was ahead of its time, he emotionally bound people way before the actuall game was released, but the character traits of Josh that made it possible also kept him from maintaining the needs of his gained followers.
Now people have to live a re-awakening of the initial euphoria with Adam as a placeholder for Josh, and this is what confuses some people.
Some take the oportunity to save whats left of their hope for LT, others fear that Josh´s role within the community or LT might be taken over, and there also may be some people who lost some status because of it.

Friendship is measured by the things you had to give up.
Was not there.
Post

Re: [Adam] Monday, October 2, 2017

#83
Damocles wrote:
Fri Oct 06, 2017 4:29 pm
Since your game logic (the simulation) runs at a fixed interval time-step, how do you smooth out the framerate?
Lets say its running at 10 FPS for the updates (logic ticks), and at a 60 FPS rendering speed, there would be 1 "slow" frame (randering and logic), and 5 "fast" frames (only rendering).

Its there any issue with "jittering" with this approach?
We have at least a couple solutions here. The trivial one is just to budget your frame time with the simulation step included. We did this on my last project where the sim tick was 50 FPS and the target render rate was 60 FPS. If you're vsynced then there won't be any difference between frame times and everything is 'perfect'. When you're not vsynced, you will indeed get form of 'micro stutter'. Generally rendering is much heavier than the simulation, though, so at higher frame rates the stutter is probably too small to notice (I say that as someone who is hyper sensitive to things like stuttering and input latency). But I rarely see that case in practice because I always play at 120 FPS with vsync and triple buffering, which I think is the sweet spot for the best experience. (Note those are settings I use playing games at home, not when working on LT).

A second solution is to split the simulation step up into pieces and do it over several frames. Our ECS design is going to make that trivial, as we can just say 'run 50% of the jobs this frame and 50% next frame'. There's a bit of nuance here though,. How do I know how many frames I'm going to get before the sim tick needs to be complete? I can only guess using historical data, and there's a reasonable chance the frame rate will change (e.g. a new ship jumped in to the system during the last tick). Jobs are also easy to thread, so we'll be able to split the simulation tick over all your cores.

We could also come up with more exotic solutions if necessary. Maybe we simulate non-interactive stuff several frames ahead in a background thread to reduce the size the regular sim tick. Maybe we 'speculatively simulate' the entire game a few frames ahead and throw away the results when they're wrong (similar to what Overwatch does). Maybe there are other existing solutions I'm not aware of. I haven't explicitly researched this.

This is something we're going to be keeping our eye on as the simulation gets heavier and naturally we'll choose a solution that yields the best experience.
Post

Re: [Adam] Monday, October 2, 2017

#84
Thanks for the feedback.
I know in most games this issue is not really noticeable, as there is enough "free time" within frames, and the time taken for CPU logic ticks is small compared to the rendering preperations and GPU work.
Its good to have some early per-frame metrics to see if frames get delayed during the logic calculations. (as LT is running a rich and heavy simulation).

Concerning this topic, whats the planned logic ticks per second for LT?
(For RTS games I have found 16 Ticks per second to be more than enough. For a Racing game or Shooter, it probably should be around 60 or even higher though.)
Post

Re: [Adam] Monday, October 2, 2017

#85
AdamByrd wrote:
Sat Oct 07, 2017 10:24 am
We have at least a couple solutions here. The trivial one is just to budget your frame time with the simulation step included. We did this on my last project where the sim tick was 50 FPS and the target render rate was 60 FPS. If you're vsynced then there won't be any difference between frame times and everything is 'perfect'. When you're not vsynced, you will indeed get form of 'micro stutter'. Generally rendering is much heavier than the simulation, though, so at higher frame rates the stutter is probably too small to notice (I say that as someone who is hyper sensitive to things like stuttering and input latency). But I rarely see that case in practice because I always play at 120 FPS with vsync and triple buffering, which I think is the sweet spot for the best experience. (Note those are settings I use playing games at home, not when working on LT).

A second solution is to split the simulation step up into pieces and do it over several frames. Our ECS design is going to make that trivial, as we can just say 'run 50% of the jobs this frame and 50% next frame'. There's a bit of nuance here though,. How do I know how many frames I'm going to get before the sim tick needs to be complete? I can only guess using historical data, and there's a reasonable chance the frame rate will change (e.g. a new ship jumped in to the system during the last tick). Jobs are also easy to thread, so we'll be able to split the simulation tick over all your cores.

We could also come up with more exotic solutions if necessary. Maybe we simulate non-interactive stuff several frames ahead in a background thread to reduce the size the regular sim tick. Maybe we 'speculatively simulate' the entire game a few frames ahead and throw away the results when they're wrong (similar to what Overwatch does). Maybe there are other existing solutions I'm not aware of. I haven't explicitly researched this.

This is something we're going to be keeping our eye on as the simulation gets heavier and naturally we'll choose a solution that yields the best experience.
Aaaaw yiss threaded scripting is what i read indeed :D
Post

Re: [Adam] Monday, October 2, 2017

#86
Different scripts on different cores? No limit to the number of cores? Client-side rendering and dogfighting, with server-side world generation and strategic AI? Do you think it's flexible enough to dynamically switch between local and networked scripting? So that you can switch between the game running entirely on your machine and a server that handles the less frequently updated, but still important background stuff.
Image
When you're trying to fill an infinite multiverse, if you're not willing to consider the entire creative output of humanity as a starting point, you're wasting your time.
User: JoshParnell is accountable for this user's actions.
Post

Re: [Adam] Monday, October 2, 2017

#87
Hyperion wrote:
Sat Oct 07, 2017 4:58 pm
Different scripts on different cores? No limit to the number of cores? Client-side rendering and dogfighting, with server-side world generation and strategic AI? Do you think it's flexible enough to dynamically switch between local and networked scripting? So that you can switch between the game running entirely on your machine and a server that handles the less frequently updated, but still important background stuff.
If the scripting portion of the engine is multithreaded, and you assign a thread for every script, threads will be distributed by the operating system across as many cores as the engine is made aware of.

Unless, of course, you have code that tells the computer to do otherwise (there is always a workaround). Such a model might make scripts that depend on other scripts impractical, since if script B requires data collected or generated by script A and script B's thread is given CPU time first, it might try to access empty or nonexistent data, or have to yield to A and try again later. We're at the mercy of the scheduler here.

What might be better is to execute scripts in order (and perhaps according to a system of priority, since some scripts will run at higher or lower levels of detail) and instead make multithreading available within the scripts so that operations that require logical or mathematical operations on large groups of entities can be farmed out to multiple threads for a quicker execution time.

My understanding of parallel computing is rather elementary; I haven't implemented very many things that use it, so I could be totally off-base here.
Shameless Self-Promotion 0/ magenta 0/ Forum Rules & Game FAQ
Post

Re: [Adam] Monday, October 2, 2017

#88
Grumblesaur wrote:
Sat Oct 07, 2017 9:25 pm
If the scripting portion of the engine is multithreaded, and you assign a thread for every script, threads will be distributed by the operating system across as many cores as the engine is made aware of.
from the Lua reference manual
Lua supports coroutines, also called collaborative multithreading. A coroutine in Lua represents an independent thread of execution. Unlike threads in multithread systems, however, a coroutine only suspends its execution by explicitly calling a yield function.
Now that doesn't stop the game engine using O/S mutlithreading for, possibly as an example, graphics rendering and display.

regards,
Charles
Post

Re: [Adam] Monday, October 2, 2017

#89
charles wrote:
Sun Oct 08, 2017 2:48 am
Grumblesaur wrote:
Sat Oct 07, 2017 9:25 pm
If the scripting portion of the engine is multithreaded, and you assign a thread for every script, threads will be distributed by the operating system across as many cores as the engine is made aware of.
from the Lua reference manual
Lua supports coroutines, also called collaborative multithreading. A coroutine in Lua represents an independent thread of execution. Unlike threads in multithread systems, however, a coroutine only suspends its execution by explicitly calling a yield function.
Now that doesn't stop the game engine using O/S mutlithreading for, possibly as an example, graphics rendering and display.

regards,
Charles
JoshParnell wrote:
Wed Oct 04, 2017 1:13 pm
(note the symmetry with how we store 'as little data as possible' in CTypes by using native memory, pools, static typing, etc.) This means, for example, that an AI player who is travelling to a location does not enter a state where the script constantly checks whether the player has arrived at the destination. This is wasteful and fails to exploit the sparsity of the situation (the probability of arrival is exceptionally low on any given frame). Instead, the script informs the engine of the specific condition(s) upon which it should be resumed: "Dear engine, I am writing to inform you that I no longer require CPU cycles until my client, Sir NotEdisonTrent III, aka 'Trent', arrives within 100 metres of the asteroid @ memory address 0xA513701D.
This is beautiful.
Another reason to use Lua. :D

It's simplicity is amazing, and isn't that the whole concept of limit theory?

Wow, I'm so blown away I'm lost for words :clap:
A coroutine can terminate its execution in two ways: normally, when its main function returns (explicitly or implicitly, after the last instruction); and abnormally, if there is an unprotected error. In case of normal termination, coroutine.resume returns true, plus any values returned by the coroutine main function. In case of errors, coroutine.resume returns false plus an error object.
And in this scenario, the False could be the ship flying into an asteroid (oops!) or got blown up by a pirate! :)
JoshParnell wrote:
Wed Oct 04, 2017 1:13 pm
Alternatively, if my client should be the victim of an attack, I would like to be notified in spite of not having arrived at said asteroid.
JoshParnell wrote:
Wed Oct 04, 2017 1:13 pm
If the underlying logic engine is clever with respect to how it services such a request, then the difference here is the difference between being able to run a few hundred AI units vs. being able to run a few hundred thousand (not that we need to run a few hundred thousand -- but keep in mind that if we consider all the other logic going on in the game, then indeed, we are looking at on the order of a few hundred thousand bits of logic). It's an orders-of-magnitude subject, like many things in computing.
Thanks again Adam, not only are we receiving excellent posts from both of you, we can now link how both of you are working on similar items, I'm not an American, but I just have to say one word: Awesome!
:ghost:

Have FUN! :thumbup:

P.S. The crashing into the asteroid could even be one of those darn-fangled 'roids with engines attached - someone's moving their mobile base from La Grange to a space lane to disrupt transit routes for the Inner worlds. Stock markets will be affected and oh, Sir NotEdisonTrent III, buys the farm.
I'm loving the chances for so many emergent gameplay elements from narky AI, to faction warefare just let rip - am I getting too excited? :monkey:
YAY PYTHON \o/

In Josh We Trust
-=326.3827=-

Online Now

Users browsing this forum: No registered users and 3 guests

cron