Return to “Dev Logs”

Post

Re: [Josh] Friday, August 11, 2018

#16
I know that some will think of it as the beginnings of the dark days, but the fascinating UI experiments from years-gone-by were actually one of my very favourite phases of the LT development process. At the time I remember thinking that such experiments were perhaps only possible in a small project like this one, and that we might end up with something truly unique and interesting as a result. As such, if the UI code ends up being hard-coded in C as a fairly traditional interface, I'll be a little bit sad.
Post

Re: [Josh] Friday, August 11, 2018

#19
Lemar wrote:
Thu Aug 16, 2018 4:28 am
At least the pattern didn't change to much of writing and rewriting things. I mean I also do some refactoring but never remembered that I took it to such an extend like refactoring the whole architecture over and over again....
From what I understand, it's not the "whole architecture" this time, just a small but critical portion of it. That's why Josh has accomplished it in such a short time - it's not the whole engine, just a minor segment. This sort of thing is expected for such large projects (especially when the developers don't have any prior real-world experience) - although usually in slightly lesser quantities. :P LT is a highly demanding game concept-wise, though, and Josh wants it to be capable of running on as many machines as possible. Getting the architecture right is critical.

At least he's being realistic about it this time. I find that encouraging.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: [Josh] Friday, August 11, 2018

#20
I meant the architecture of that particular feature not the whole game and I'm still surprised by the level / extend of rewriting, it wouldn't encourage me to have to throw code away I taught was fine. Can just assume that this is the nature of games or that game that you can't predict the performance outcome for the approach you choose and only measure it when it is done.
just a small but critical portion of it
How do you know it is critical? What if the player will spent maybe 1% of his gaming time with that. Wouldn't it be better to make a note on how to optimize it and then move on to other features. You need to reavaluate the performance at the end for the whole game and look at which part are the ones where a player spents most of his time to really measure what has most impact on performance...
Post

Re: [Josh] Friday, August 11, 2018

#21
Lemar wrote:
Thu Aug 16, 2018 12:46 pm
How do you know it is critical? What if the player will spent maybe 1% of his gaming time with that.
I think it's safe to assume that a player will spend a large portion of their time with the UI. Not necessarily fiddling with it, but using it since that's their interface to everything else in the game.
A life well lived only happens once.
Seems deep until you think about it.
Post

Re: [Josh] Friday, August 11, 2018

#22
vector67 wrote:
Fri Aug 17, 2018 4:39 am
Lemar wrote:
Thu Aug 16, 2018 12:46 pm
How do you know it is critical? What if the player will spent maybe 1% of his gaming time with that.
I think it's safe to assume that a player will spend a large portion of their time with the UI. Not necessarily fiddling with it, but using it since that's their interface to everything else in the game.
It's mind boggling that anybody could think that UI isn't one of the most important parts of a game like Limit Theory. No Man's Sky gets shit to this day for its bad UI, and that's after a metric ton of improvements by the devs. Same goes for Divinity Original Sin. And Skyrim. And Destiny.

As for the exact nature of the work, immediate mode UI is procedural in nature, so I can understand what drew Josh to it in the first place. All UI elements in immediate mode are generated. The common issues with it are that it's performance heavy and working with it can get absolutely nightmarish in certain scenarios. Unity3D actually uses immediate mode for its default GUI, and you'll find a lot of devs who despise it.

Retained mode is the old, 'boring', non-procedural way of doing a UI. I believe (in my incredibly limited knowledge) that this is the right choice for LT UI as it's easy to build a complex UI with retained mode and a lot of desktop-like features (think drag and drop) come much more painlessly here than in immediate mode.

So this isn't just another refactoring of code. Josh had two options for the UI, he went for one, found it didn't work, and is now going with the other. Shit happens.

Also, I'm sure Josh will be happy to correct any mistakes I made in my explanation above.
Post

Re: [Josh] Friday, August 11, 2018

#23
In regards to UI, yes it is critical, but given the procedural nature of LT, it can also be left for Beta. So long as it's "good enough" to play the game, its various issues will be weeded out, and polish can certainly be left for Beta.
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: [Josh] Friday, August 11, 2018

#24
A user interface for a game is like a doorway to a treasure room.

There's treasure in there! That counts for a lot; you'll tolerate a door that doesn't work too well if the treasure is tasty.

But there's a limit (SWIDT) to that. A door that's not just poorly hung but that actively prevents you from getting to or enjoying the treasure is is just too irritating, and most people will reluctantly (and maybe noisily) go look for treasure elsewhere.

To further belabor this analogy, what Josh is building is more like a gateway construction kit. Spending another week on this should yield a system that will allow not just Josh but modders to create interfaces that:

  • provide the basic functions (windows, radio buttons, checkboxes, scrollbars)
  • are responsive even when there's a lot of them on-screen
  • are simple to understand and apply from a dev perspective
  • are simple to understand and use from a player perspective
  • stay out of the way unless the player wants/needs them
  • are highly configurable (SLIDERS!)
  • are easily extended (functionally and visually) because the code has been well-factored
  • can talk to each other through a consistent interface
  • adapt dynamically to any resolution and aspect ratio (4:3, 16:9, 16:10, widescreen)
  • (VR-ready?)
  • are most likely future-proofed for post-launch game enhancements
  • look pretty!

That might look like a lot of coding goals, but it's pretty much the bare minimum feature set (other than that VR thing) for a game that's going to be supported for X amount of time after it's released. There might be more.

As amazing as LT-the-game is set to be, it would be a shame not to give it a UI that addresses most of the goals listed above, so that players aren't discouraged from exploring the actual gameplay features.

That said, I sure hope we're not looking at more than another week or so to follow The Other Path for moving the UI system into the core. As Hyperion rightly says, functionality (though, I would add, with at least one eye on the future) is what matters most right now.
Post

Re: [Josh] Friday, August 11, 2018

#27
It's worth pointing out that there are huge benefits to refactoring code while it is all fresh in your mind. Putting something aside for later is all well and good, but programmers don't just hit the ground running when they switch back to something old; there's a cost to doing that, to re-familiarise yourself with what was done before, how it worked in detail, what the issues were, what the revised requirements are, what the intended solution looks like in detail, and any quirks and edge-cases that might be important. Unless it was all written down in detail at the time, it's all too easy to not be able to remember everything that was in your head at the time.

Given that UI is such a pervasive aspect of the game, which so much of the future development will touch on, it would seem a little bizarre to me if Josh didn't follow through with it now while his head is fully in that space. A matter of weeks to iron out a critical aspect of the engine is hardly unreasonable.

Online Now

Users browsing this forum: No registered users and 5 guests

cron