Didn't you say something about that in an interview with Rhykker? Maybe I hallucinated but I'm pretty sure you said that we will unlock the rewards and be able to change between all the unlocked rewards at will.
There are some details still not quite locked in but something very similar to that is being worked on.
It don‘t actually would need full customization but just to being able to select male or female so from a view of development to have fixed models at first would cost much less resources than a full customization feature. And I‘m sure all people would already be happy having the option to choose between genders!
A less feature rich version of just a character template selection with a few options would probably satisfy most people's desires and that feature would require less work than full customization. However, it's more of an, only 90% as difficult, situation than "much less resources". There are a lot more little things that go into this than you might think. The related systems just aren't set up to accept it at the moment and we aren't prepared to attempt it yet.
Fair enough. I can accept it if there was a specific reason behind the skill access order and not that it was just sorta random.
Thanks for the explanation Mike (at least I think this is Mike).
Yea it's me, but don't tell anyone, I'm in disguise. It's not a very good one though, check the first 4 letters of my username.
Edit: and we do very carefully pick the unlock orders of skills.
Which skills are granted in which section of the passive trees is surprisingly important to how the skill and passive trees and unique items are designed. Making the skill unlock order variable would cause a complete audit of every node of every tree in the game. We would have to change, move or remove many nodes.
It's a cool idea that would have a much bigger impact than you might think.
It's not feasible to implement at this time if we did decide we wanted to do it.
Just a bug that snuck in. It wasn't doing that in testing.
Can you make a tldr version of that thread lol? Thank you for your effort.
The answer from Judd on September 6th 2023 is probably the best tldr as it was from an interview done just as Gamescom was wrapping up.
Nice thank you ❤️. BTW the story is super dope. It hits perfect for an ARPG not to deep, not to shallow just enough to make you remember the important stuff and keep you immersed gudos to the team for it.
thank you :)
Any chance we get some ultra-widescreen QoL. Like being able to put the forge/shop panel being next to the inventory panel. I know asking for movable panels like in FF14 is to much but having the inventory on the right of my screen and the forge on the left makes me feel like going on a road trip every time I need to move the mouse from one end to another 🤣🤣🤣
This is not currently planned for 1.0
Wait what? The story ends how it ends now? I mean I understand why but I was hoping 1.0 will reveal what’s next in our journey
No, we have a few more chapters before the campaign is "complete". More story stuff will happen after that but the core campaign that we initially set out to make isn't done yet.
We already have a thread going on this topic. Locking so people don't just make more.
https://reddit.com/r/LastEpoch/s/Vr2ZJOQy67
While getting a new bill in the mail is never fun, we don't have all the information around this topic yet so we are going to wait and let things settle.
We aren't entertaining the topic of switching engines roughly 3 months before launch.
System, you say?
Also, why update systems and not just story at 1.0, given bug potential?
Because there is room for big wins in gameplay experience and we aren't adding more story chapters at 1.0
That system and panel are slated for 1.0 updates. No details at this time.
The padding around the glyphs in the font atlas is too low. It's something we will have to fix.
wouldn't that state information also have to be on a server with costs? I'm sure you know what you're doing, but it is very cool that y'all talk with us players about this stuff. a lot of game companies want to be opaque about their internal functions which probably makes sense for optics, but this way is joyful.
I'd assume in an ideal situation, the information the server keeps for an active player in a zone would be as small as possible and would closely match the amount of information in the "state information". while you may want to make it so the zone the player left is inactive, players probably expect it to keep living: monsters move and regen etc during this time. on the other hand, this is such an unimportant issue: this game is quite fun the way it is and I don't mind going through enemies again if I tp. if I didn't like going through enemies, I wouldn't play this game!
While it does matter what the server is doing for associated costs, just having one dedicated to that empty zone at all is the majority of the cost. Storing the static data of what that server looked like with the intent of being able to recreate it is WAY cheaper to do than allocating a server to sit there and remember the game state. Like orders of magnitude cheaper.
I've not played multiplayer much, but if one of you leaves and comes back, the state of the map should persist for the person who stayed, right? So surely this isn't an issue if a player is staying there right? A fix could be to make a virtual player (perhaps make a parent class to the player that includes the functionality that keeps a zone active but without the other unneded player stuff, and then make this virtual player an instance of that or something that inherits it) that stays behind in the zone when you tp?
Given the server cost associated with each instance, they have no close fairly quickly upon exit. We wouldn't have to leave a dummy character there to keep it open. The state information needs to be able to be stored and restored to implement this.
u/ekimarcher
maybe something sorta like this (little generic but hopefully helpful)Save following on TP
- Map generation seed- current "living" monsters and their positions
- dropped loot + positions
- TP location = Player's return location- ... etc
Save this map state data to player (last_dungeon_data)
Then when you TP from town back into the zone then load the map state setting everything remaining back to it's position before you TP'd
Yea, that's what we've been unsuccessful in making so far.
Maybe expanding upon the town portal function then? Whatever method you guys used to get that to work properly could maybe be duplicated. Possibly each instance that the player enters could be essentially stored in an invisible town portal that is attached to the player character. Interacting with a waypoint with a certain hot key combination could allow them to access those portals.
The in-game rationale could have something to do with visit previous timelines or something.
If I sound like an ape that’s because I essentially am. I know literally nothing about programming but I did watch Silicon Valley.
Hope you are able to solve your problem with relative ease some day soon. I really like what you guys are doing. Keep up the good work.
You're on the right path of where we started. The town portals don't work though, that's the problem OP was talking about. We have been trying to do exactly what you suggested, there are some problems that I don't understand either.
The PoE approach may be your best bet. You can have players continue to automatically reset zones if you’re unable to fix that and institute a way to store previous instances that can be accessed later.
Yea, that's the problem, storing the previous instances.
Eh, I suppose always resets is better than never resets until you get it working right
Oh I wish we had never resets as an option. I could fix that no problem.
Have you tried asking the monsters nicely?
Yea but they won't come to the bargaining table. It's just kill kill kill with them.
devtrackers.gg