Return to “Dev Logs”

Post

Re: Tuesday, January 31, 2017

#46
DWMagus wrote:I thought Josh explained how he was doing the 'skybox' at one point. My forum search-fu is failing me at the moment. Where's Just Ice being our walking LT-O-Pedia when you need him? :lol:
Well, there are numerous references to Josh working on the background, incl. Star-fields, Stars, and Nebulae - which is to be expected. Probably the most relevant reference in this context is the dev log from Saturday, May 18, 2013.

Or, y'know, you could just read Josh's actual reply above. (Which feels awesome to say, by the way.) :D

:wave:
- The Snark Knight

"Look upward, and share the wonders I've seen."
Post

Re: Tuesday, January 31, 2017

#47
Silverware wrote:The big thing, is that it doesnt matter how many stars you have, only the brightest should be visible.
So the fat reds, medium/big yellows, and all the whites/blues.

The distribution should actually end up somewhat linear for star color.
Simply because the majority of stars are small and not luminous enough to be typically visible.

And the star(s) in the system should end up being reasonably linearly distributed because wormholes and jumpgates allow you to connect any system to any system based on a developers whim without breaking any laws. :D
Well, you can imagine in your head that the n stars generated in a system background are actually just the brightest n stars and the computer didn't bother to create all the ones it wasn't going to render.
Shameless Self-Promotion 0/ magenta 0/ Forum Rules & Game FAQ
Post

Re: Tuesday, January 31, 2017

#48
Grumblesaur wrote:
Silverware wrote:The big thing, is that it doesnt matter how many stars you have, only the brightest should be visible.
So the fat reds, medium/big yellows, and all the whites/blues.

The distribution should actually end up somewhat linear for star color.
Simply because the majority of stars are small and not luminous enough to be typically visible.

And the star(s) in the system should end up being reasonably linearly distributed because wormholes and jumpgates allow you to connect any system to any system based on a developers whim without breaking any laws. :D
Well, you can imagine in your head that the n stars generated in a system background are actually just the brightest n stars and the computer didn't bother to create all the ones it wasn't going to render.
Thats what I am saying, your average star color will be less red in this case, and more yellow/white.
Making the stars look pretty and not red. :D
°˖◝(ಠ‸ಠ)◜˖°
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: Tuesday, January 31, 2017

#50
Grumblesaur wrote:
Image Who says red can't be pretty?
Vastly heterogeneous star colors might be unrealistic, but realism isn't correlated to aesthetic or fun necessarily.
*saves*

Now do one in blue or purple! :D

Realistic? Who cares. That looks awesome.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Tuesday, January 31, 2017

#52
Dromeda5 wrote:I also always had the impression that you generate more nebulae around where there are more stars. I don't if that's the case or if it's just easier to note the stars against variation of colors.
Hmm, no, but when the stars are rendered, they aren't just 'pasted' into the sky, they do some math that changes their color / brightness based on the background at that point. So high-density nebulae appear to occlude all but the brightest of stars, nebulae modulate the color of stars, etc...it could be one of those effects that you're seeing.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#53
Hey Josh, good to see you active again. I rarely post, but every few months I've been checking the forum and keeping track of any progress. I still remember uploading prototype gameplay videos in April 2013!

Just want to say keep up the good work, I could always tell you hadn't given up, and I'm still glad I invested in this project. :thumbup:

Looking forward to what the future brings... Good luck on fixing performance issues!

My only main query is how do you feel about the game content once you have got past the current issue? I understand you will have the systems set up, or at least set up in a way that you can quickly implement feautures, but do you have any plans mapped out to turn these feautures into an interesting game?

The prototype seemed like a great start with autogenerating missions.
Post

Re: Tuesday, January 31, 2017

#54
ryryryan wrote:Hey Josh, good to see you active again. I rarely post, but every few months I've been checking the forum and keeping track of any progress. I still remember uploading prototype gameplay videos in April 2013!

Just want to say keep up the good work, I could always tell you hadn't given up, and I'm still glad I invested in this project. :thumbup:

Looking forward to what the future brings... Good luck on fixing performance issues!

My only main query is how do you feel about the game content once you have got past the current issue? I understand you will have the systems set up, or at least set up in a way that you can quickly implement feautures, but do you have any plans mapped out to turn these feautures into an interesting game?

The prototype seemed like a great start with autogenerating missions.
Hi Burial / ryryryan :P Thanks very much for the kind words!

I feel very good about game content. It has been shown several times now that, when technical issues get out of my way, game content is fun and fast to develop. I really enjoy that part! So yes, I do think I know how to turn it all into a compelling game once I'm past my roadblock. Much like I did with the PAX demo, I'll be mapping out a plan for getting it to completion when I finally have the solution that allows me to do so :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#55
JoshParnell wrote:
ryryryan wrote:Hey Josh, good to see you active again. I rarely post, but every few months I've been checking the forum and keeping track of any progress. I still remember uploading prototype gameplay videos in April 2013!

Just want to say keep up the good work, I could always tell you hadn't given up, and I'm still glad I invested in this project. :thumbup:

Looking forward to what the future brings... Good luck on fixing performance issues!

My only main query is how do you feel about the game content once you have got past the current issue? I understand you will have the systems set up, or at least set up in a way that you can quickly implement feautures, but do you have any plans mapped out to turn these feautures into an interesting game?

The prototype seemed like a great start with autogenerating missions.
Hi Burial / ryryryan :P Thanks very much for the kind words!

I feel very good about game content. It has been shown several times now that, when technical issues get out of my way, game content is fun and fast to develop. I really enjoy that part! So yes, I do think I know how to turn it all into a compelling game once I'm past my roadblock. Much like I did with the PAX demo, I'll be mapping out a plan for getting it to completion when I finally have the solution that allows me to do so :)
Awesome, sounds good :)

On a side note, in terms of your kickstarter emails, I think that updating monthly at most is best at this stage. I don't see the need for more regular updates while you work on this technical issue, and the forum's are a better place for the more technical discussion IMO.
Post

Re: Tuesday, January 31, 2017

#56
So,

For the next blog it may be interesting to read about the details of the benchmark and the results of LuaJIT. Additionally, why the previous attempts failed to scale. For instance, why isn't the simulation LOD the answer to the problem? I imagine you want to be able to simulation some set of agents at full resolution, but it's costing too much frame time? Are any parts of the simulation multi-threaded? Why not scale back the simulation requirements for 1.0?

There's a good episode of HandmadeHero that details the how the world is simulated at coarse and fine grain resolutions.

Also, to ask the difficult question; why isn't the shortest path to completion to continue writing the game in c / c++? I know the codebase is large, but modern IDEs can help manage the complexity; code completion and documentation go a long way on large codebases. Too much boilerplate? Compile times too slow? I understand scripting languages are more expressive, but the opportunity cost is pretty high; 2 years in c/c++ or 2 years experimenting with scripting languages. Not trying to criticize, I feel like you needed some one to pull you out of this black hole earlier. Hopefully, LuaJIT yields some fruit.

* ping jblow for an early release of JAI ;)

onwards and upwards,
found
Post

Re: Tuesday, January 31, 2017

#57
found wrote:Too much boilerplate? Compile times too slow? I understand scripting languages are more expressive, but the opportunity cost is pretty high; 2 years in c/c++ or 2 years experimenting with scripting languages. Not trying to criticize, I feel like you needed some one to pull you out of this black hole earlier. Hopefully, LuaJIT yields some fruit.
And who's to say that there wouldn't have been an equivalent or greater opportunity cost trying to figure out how to make a flexible iterative development interface (which as a bonus supports modding) in C++? I don't think scripting languages are to blame here necessarily; I think it's that the programming problem is difficult and that there are tradeoffs to dealing with it.
Shameless Self-Promotion 0/ magenta 0/ Forum Rules & Game FAQ
Post

Re: Tuesday, January 31, 2017

#59
found wrote:So,

For the next blog it may be interesting to read about the details of the benchmark and the results of LuaJIT. Additionally, why the previous attempts failed to scale. For instance, why isn't the simulation LOD the answer to the problem? I imagine you want to be able to simulation some set of agents at full resolution, but it's costing too much frame time? Are any parts of the simulation multi-threaded? Why not scale back the simulation requirements for 1.0?
All good questions. Right now the goal is only to get those agents that must be simulated at full resolution to be performant; I do not even count the LOD-simulated ones towards the 'problem,' since the bulk of the work is in the full-detail sims. Multi-threading is difficult in game logic simulation but is being explored currently. It is very possible that simulation size will be scaled back for 1.0 if that makes the difference between working and not-working (no solution has gotten 'close enough' to be at this point, though).
Also, to ask the difficult question; why isn't the shortest path to completion to continue writing the game in c / c++? I know the codebase is large, but modern IDEs can help manage the complexity; code completion and documentation go a long way on large codebases. Too much boilerplate? Compile times too slow? I understand scripting languages are more expressive, but the opportunity cost is pretty high; 2 years in c/c++ or 2 years experimenting with scripting languages. Not trying to criticize, I feel like you needed some one to pull you out of this black hole earlier. Hopefully, LuaJIT yields some fruit.
No I understand, it's a good question to be asking. Frankly I don't know the answer -- could I have spent these two years slimming down the C++ codebase, refactoring to make it easier on myself / make compile times faster (yes, they were a problem)? Maybe so, maybe it would have been enough. Maybe it wouldn't have. As I've explained, my best intuition at the time told me that it wasn't going to happen with that development style. But it's honestly not really worth asking at this point, because I've already gone down this other road. Thing is, though, I've learned what I feel to be a lot of invaluable lessons with all these attempts and failures. I feel much more equipped to 'handle' LT, even if I don't have the right solution nailed down just yet, I have a much more vast set of tools to work with. I think it's good that I finally came out of my rather narrow world of C++ and only C++.

FWIW, LuaJIT appears to be yielding more fruit every day. Though of course we must not get our hopes up :ghost:
* ping jblow for an early release of JAI ;)
An interesting language no doubt, but I have very little interest in using it TBH -- I'm sure he's designed it for his needs...but personally, watching him program with it, I think his needs are quite different from mine.
FormalMoss wrote: :D
I'm happy someone other than Dino has brought up multi-threading.
:mrgreen:
Threading is being explored. As I've said before, though, (and I don't think some people are hearing me when I say this), threading game logic is not like threading physics simulations or math computations or what-have-you. Game logic is massively interdependent, a perfect storm of a situation for death-by-mutexes or plain old memory corruption. Throw in a scripting language on top and things get even more complicated. Now we have a script interpreter state that can't just be launched on multiple threads. We have to spawn a new interpreter state for each thread -- any shared data now has to be managed somehow by the underlying engine, since (in the case of Lua) the scripting language provides no facilities for sharing data with other instances (in the case of some other scripting languages, it's not even possible due to the global interpreter lock (GIL)).

But yes. It's being explored.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 10 guests

cron