Return to “Dev Logs”

Post

Re: Adam - Monday, October 2, 2017

#31
Haron wrote:
Mon Oct 02, 2017 3:04 pm
Hi Adam. It was interesting to read you update for me as a developer. Great work! Hope to see new updates from you and Josh.
After reading your post I'm wondering if you and Josh discussed a possibility to use some existing UI libraries (i.e. ImGui is being used in the several game engines as dev UI) before starting to implement your own?
We did. Josh actually dug through the internals of that exact library quite thoroughly at my recommendation. As this is foremost a debug UI I was able to keep it quite minimal and the implementation time was rather short. Doing it from scratch also helps us understand some of the features and API we want from our ideal, real UI. When we get to that point we'll have to reevaluate whether to use a library, roll our own, or extend what I've already built. One of the concerns Josh had with it was our ability to make it look nice. And I'd be lying if I said that 'not-invented-here syndrome' didn't play a small part. Not that we'd forgo pragmatism, but knowing a system inside and out and having complete control of it often leads to a better end product. Especially with the amount of attention to detail currently occupying this office space.

Grumblesaur wrote:
Mon Oct 02, 2017 3:59 pm
Thanks for the mini-update, Adam. You showed us what the old code used to look like with that Lua function -- what would be the equivalent structure with the refactor?
In this mostly-toy example, the biggest things are 1) removing the hasInput parameter and check and 2) moving the input handling to a UI widget that overlays the GameView.

In the code snippet the left click functionality is related to the ship the player is controlling while the target selection is actually related to developer controls that aren't intended to be part of gameplay. This paradigm makes that difference explicit because the input checks end up in different control widgets.

So what started as

Code: Select all

-- Ship.lua

function Ship.Create ()
  -- <stuff>
end

function Ship.free ()
  -- <stuff>
end

function onUpdate (dt, hasFocus)
  if hasFocus then
    if PHX.Mouse.Pressed(PHX.MouseButton.Left) then
      self:fire()
    end
    if PHX.Mouse.Pressed(PHX.MouseButton.Right) then
      self.camera:setTarget(self:getPick())
    end
  end
end
starts to turn into

Code: Select all

-- Ship.lua

function Ship.Create ()
  -- <stuff>
end

function Ship.free ()
  -- <stuff>
end

Code: Select all

-- ShipController.lua

function onInput ()
  if PHX.Mouse.Pressed(PHX.MouseButton.Left) then
    self.ship:fire()
  end
end

Code: Select all

-- DebugPicker.lua

function onInput ()
   if PHX.Mouse.Pressed(PHX.MouseButton.Right) then
    self.camera:setTarget(self:getPick())
  end
end
Which may look messier and harder to follow because now it's all spread out, and normally I'd agree, but in this case certainly appears to be the right choice. These are separate contexts that will be active at different times and shouldn't necessarily be all shoved together. Now when I enable the DebugPicker it's a blank widget that overlays the GameView, which means it 'steals focus' and starts receiving all input. You can imagine each individual piece of game UI being implemented with this pattern and the code is going to scale much more cleanly.
Post

Re: Adam - Monday, October 2, 2017

#33
FormalMoss wrote:
Mon Oct 02, 2017 3:12 pm
if the update comes from Josh, Adam or Nathan, I don't mind, they all are Limit Theory in my view
This is close to my own view as well.

I mostly hope Josh is doing OK when he hasn't commented here in a while. And I do wonder whether the longer the intervals between a poshJost, the harder he finds it to say something that feels worthy of that wait. (Even if that's not necessary.)

But beyond the personal, my focus is on the project. Josh, Adam, and Nathan are the Official Voices of this project -- as long as one of them is communicating evidence of progress, then that is all any of us out here can reasonably hope for. Demanding more, and actually complaining when a tasty update is provided, is not reasonable and not helpful.

So:

Thank you for the update, Adam! I appreciate your taking the time to stay connected with us, as well giving us a peek at the latest technolore.

I understand the value of a clean and non-intrusive UI when trying to understand system behavior. I also appreciate your point -- of which I hope everyone here will remain aware -- that there's not going to be a "completely done!" moment for the architectural stuff any time soon. It is 100% normal to cycle back and forth for some time between gameplay features code and foundational systems; both need to work correctly, perform well, and be maintainable, and it's impossible to guess accurately in advance at every single systemic feature that later gameplay code might need. An iterative process is normal.

Though, naturally, the percentage of architectural rejiggering needs to trend toward 0. I understand you're not there yet, though.

Now, since you asked ;) , there are a couple of things I'd very much like to know more about:

  1. rough number and size (and name) of core tasks remaining to be completed in order to release LT
  2. architectural design for accomplishing continuous macro-AI across multiple star systems

I'm going to guess that first item is probably not something I should hold my breath for. :D But I'd sure like to know more about that second one.

I'm as interested in the dogfighting part of LT as anyone, but I'm also extremely interested in LT as a kind of "living world" system. The multiple-star-system macro-AI (which connects to the local AI, both of which are subject to a LOD manager) is the most crucial building block for enabling the emergence of a gameworld that's worth playing in because it contains characters doing plausible things.

So while I understand there may be a few things that need to be built before y'all get to integrating AI into the dogfighting game, I'd sure like to hear more about the AI scaffolding once that work comes up.

Thanks again!
Post

Re: Adam - Monday, October 2, 2017

#35
Talvieno wrote:Thursday, August 31, 2017

Ahoy there! I know it's been a long time since Josh made a post, so I'm stepping in here for a moment with one from Adam, just to show progress is still being made. For those who don't know, Adam is one of the programmers Josh hired, and this is his first major post. We'll get back to you soon with more regular updates from Josh, but in the meantime, hopefully you can enjoy this one. :)
Methinks the header of the most recent RSS News Thread update could use a small edit. :P
"omg such tech many efficiency WOW" ~ Josh Parnell
Post

Re: Adam - Monday, October 2, 2017

#36
Thank for the update Adam.

Personally I use the updates to see if there is progress made and if the dev team is still alive, having interesting contents are just a bonus :)

And to @Naed YOU have zero respect in the community, and they way you are saying things would demolish any if you had. You need to step back from the keyboard and only come back once you can communicate like an adult.
procedurally generated comment
Post

Re: Adam - Monday, October 2, 2017

#38
Every update is greatly appreciated! As a coder an overall technically oriented I'm very interested in hearing the ups and downs of the development, of all sizes.
Naed wrote:
Mon Oct 02, 2017 11:49 am
The one that the community wants to hear from is Josh. Not you.
Do you speak for the community? Please don't put words in my - or anyone else's - mouth (letters on my keyboard?).

Personally, I don't give a crap who writes the updates, as long as they're involved in the development. Directly, or even indirectly like the CM. It seems I'm not alone in this mindset.

Keep 'em coming Adam!
Post

Re: Adam - Monday, October 2, 2017

#40
First off, if josh cant find the time to update us, i find wonderbyrd a perfectly reasonable and welcome substitute. I'm not sure why that's even an issue, but to each their own. It's not like Josh is going Howard Hughes on us...again.

Second, i think it's actually quite an interesting idea to separate the simulation from the camera, and anything to record it. If a tree falls in a Limit Theory Forest, turns out it does still make a potential-sound even if no one is around to hear it :p. I think this could be fairly nice for a number of modes/mods/whatnot. so yay :)
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can
Post

Re: Adam - Monday, October 2, 2017

#41
Hyperion wrote:
Tue Oct 03, 2017 1:59 am
i think it's actually quite an interesting idea to separate the simulation from the camera, and anything to record it. If a tree falls in a Limit Theory Forest, turns out it does still make a potential-sound even if no one is around to hear it :p. I think this could be fairly nice for a number of modes/mods/whatnot. so yay :)
The main benefit, is that most/all userland crap (like UI, input, viewport) is then handled separately from the core game code.
This means fewer changes to implement new userland toys (like better market views), and fewer changes to implement new game stuff (like new system generators, or ship types, or gameplay types)
And it'll be much easier to support the Multiplayer Mod going forward, as fewer changes will impact the server.
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump
Post

Re: Adam - Monday, October 2, 2017

#45
Miklos wrote:
Mon Oct 02, 2017 11:42 pm
And to @Naed YOU have zero respect in the community, and they way you are saying things would demolish any if you had. You need to step back from the keyboard and only come back once you can communicate like an adult.
Idunno, he has my respect and at least some respect from the community members i interact with ¯\_(ツ)_/¯

Online Now

Users browsing this forum: No registered users and 1 guest

cron