One thing I really enjoyed about Path of Exile (before leaving it indefinitely) was that we could go AFK for as long as we wanted.
Any plans for that feature to come to LE? Really hoping it does.
Taking a break or eating that’s more than 5 minutes long without losing your place in the campaign would be pretty awesome.
That’s what the waypoints are for, no?
There used to be no AFK timer but it was implemented a couple of years ago if I remember correctly. Then it was much shorter, 5 minutes I think, and after the community complained about how short it was they extended it to what it it now, which I think is 15 minutes.
It’s about server resources I believe.
Yes, it’s about server resources. EHG has issues with them clearly.
The lack of persistent instances and the AFK timer showcase that fairly well.
So maybe in the future, when they get their network code under control far enough so they can afford it. As well as other optimizations which improve the situation overall.
Even in offline mode maps dont persist so this has nothing to do with servers
That’s because systems are generally kept concruent between online and offline mode. This reduces upeep and the amount of bugs happening.
EHG couldn’t handle preparing their content pipeline for release despite being several years in EA. Do you think they have the capacity to maintain more then a single codebase?
Maybe in the future, but they’re not there yet, hopefully in the future.
You said maps being non persistent showcase EHG struggles with their server capacity.
I am telling you that particular point is wrong because
Don’t need to debate on whether EHG is able to maintain 2 differents code bases. Which would be a bit silly imo. It makes a lot of sense to keep the difference between offline and online as small as possible.
Which is based upon the online situation.
Their codebase is created by taking the online capacities and server situations in mind. The same code is used for offline. Hence offline has no persistence despite allowing the local machine to handle it.
Because we didn’t have ‘offline’ back then but a bottleg strapped ‘online mode’ which wasn’t ‘true offline’. That came later. The game has been developed and designed with a live-service environment in mind.
That’s simply where it’s coming from.
It’s simply happened to be built up this way… and I would enjoy if it weren’t the case as well, but it is. I’m not arguing for or against anything there, simply telling where the stuff which is going on has come from and why.
No, it was the case before online was a thing, even back when I started in 0.7.something. as Vlad has said, it has nothing to do with servers. If it was related to server shenanigans & EHG wanting to minimise differences then pre-mp would have had persistent maps. But it never has. Ever.
It wasn’t “true offline”, but after the login & ignoring chat, everything was offline. There were no (non-chat & non-login) servers for your pre-0.9 client to talk to. And don’t forget, pre-0.9, they did maintain 2 different code bases which is why it took so long between 0.9 & whichever was the previous version because they had to convert all of the offline code into something that would work in an online server authoritative environment. They have said this.
My point is that it happened because EHG planned from the start to make LE a live-service game.
This warranted to make all design based around that, which also caused their non-persistent zones to be a thing as doing it for the server setup in mind.
LE seems to have no flexible loading method in the form of a ‘reality bubble’ like PoE has, which I derive from both the spire and patrol objectives existing. Both warrant a simulation of the whole area rather then a part. This causes a substantially higher load for performance on both a local machine and a server, making persistant instances an issue as each instance would mean a 100% increase in resource allocation to the baseline we currently have. Which is kinda massive.
So I imagine that it came from there to make it as close to a singular code-base instead of breaking it up into both the online situation and the offline situation which needs a good chunk of extra upkeep to allow them to perform properly… and worst-case three code-bases given that lower-end machines would severely struggle even in offline mode to handle more then a singular instance being open (be that the town or a map) at the same. Still happened to be 2 distinct slightly adapted bases… but that’s still a massive undertaking to combine as we’ve seen.
It’s likely rather forethought and limitations of the way EHG uses the engine currently. They’re a garage company after all, I don’t expect EHG to have the fundamental knowledge of dynamic ongoing generation for load and resource footprint reduction. I see that as a more likely situation then it being a simple ‘oversight’… because that’s what it would’ve been back then if MP wasn’t even a thought. But… it was already a thought and the development was done with that in mind from the beginning, even before MP was even remotely implemented it was after all planned.
Yeah, because that’s the actual oversight there, I agree. The lack of taking into consideration a ‘safe’ online environment with proper authentification process. I mean… we’ve seen that right at release being an issue, with things like a proper queue missing to not cause the login-server back-end to overload… plus all the database issues, but those are extra bits.
EHG had no knowledge about MP setups, they at best dabbled in it and finagled their way through before realizing they need to make a proper set up system. Which we’ve seen with 1.0 being tried to do as they’ve needed to combine those 2 code bases into one… which was their initial idea to keep offline and online partially separate.
But as other games have often proven… that’s a massive undertaking to keep up to date, heck… Minecraft can’t even keep their content at the same state between their different systems, and I don’t mean baseline systems like shaders, lightning or render systems… but simply ‘We have this block and that type of world generation’ concruent between platforms. In a game like Last Epoch where we’re talking about regular fundamental code-base changes being needed as it progresses it’s just a non-viable development method… which is why they reduced it to a single code-base allowing all of it to function under a single umbrella and only needing one change and testing phase rather then 2… with different outcomes likely and ever further diverging background systems and hence issues.
I was under this impression as well, even being under the impression Mike said something to this end back when I asked about this, but I have since asked Mike on stream about it and he vehemently said that zone persistence has nothing to do with performance issues. Same for sounds/beacons for filter.
In both I was under the impression this would be the case, but for both Mike said that it was not due to performance issues that they don’t exist, but for other reasons (he didn’t specify them).
Well… if it’s not for performance issues (which I would expect first and foremost)… what other ones?
Lack of knowledge on how to code it? Time investment needed to make it happen? I wouldn’t think causing the offloading of an instance on a separate activity timer won’t be that hard to implement, even with a system in the background tieing a persistant zone together with a character, since that doesn’t exist as there’s no need for it yet. And the first… sounds also a bit off, that’s not one of the majorly hard ones to design, while a bit extensive it’s still a sort of minor background feature compared to the overall needed MP code in place.
So it kinda all sounds a bit ‘odd’ simply and leaves more questions then it answers.
I don’t know what other issues it could be, but one possible reason I can easily see is the need to store the state of multiple maps on a permanent basis. You’d need to store the state of the fog of war for each separate zone on a permanent basis and you’d also have to store the state of the zone itself regarding mobs and opened chests/shrines/etc, for a current session or a new instance.
This would require quite a lot of changes in their database and their methods to load/store zones and character info.
One other reason might simply be that they’ve always wanted to have procedurally generated zones and would rather work on those (which are coming partly in Season 2) and then change the existing ones to that, rather than work on a solution for persistent zones that would later by discarded when procedural ones come into being.
I have no idea either is the reason or not, or even one of the reasons, but there are certainly things that can lead to this not being possible right now and/or being lower on the priority list.
Yeah, that’s very fair, which would be the background system to make it into permanence. After all while you’re in the zone that data already needs to be available, just by leaving it gets offloaded.
So instead of offloading it it would become a separate state with a timer to expire and expunge it upon reaching zero (or a positive or negative value, whatever floats the boat and fits best).
Which returns to… resources in the end because the setup for that shouldn’t be tooooo hard. Sure, definitely a decent amount of effort but those types of permanence systems have existed for a long long time already and are fairly well documented actually.
And yes, the procedural ones is a good reason, but also… same thing there. They’re generated via a seed-system, clumped together and seemlessly interacting with a ruleset to enforce proper joining of segments together. But the permanence once more would be the same system there. Have the seed saved, offload with the current state to the side, recall upon re-visit.
I can understand if it’s not a priority issue, there’s definitely more important things first and foremost to be handled… but for the things actually stopping it? Simply time-investment or resources come to mind, I actually can’t think of any other viable one… knowledge base could be one, but that’s worst-case a single designer - if they can get one, big point - which has relevant knowledge in working on those types of systems already.
This is exciting. And I’m reading a lot into this which Mike will probably say, “lol, what? No, that’s crazy, I never said that”, so, apologies in advance.
What if they use the end-game tree to construct a campaign (or part of the campaign)? Really lean into the 'you are one of an infinite number of adventures working your own way through your own timeline". So, every campaign maybe pulls from the same set of tasks, but is different each time.
Of course I say this as someone who is incredibly bored of the current campaign.
Yeah, I wouldn’t expect anything like that anytime soon. At most, what I think will happen is that they will eventually change the current static zones to a procedurally generated map.
While your idea would undoubtedly be really cool to have, I wouldn’t expect anything like that in the next 2-3 years, if ever.
But I do like it.
They may have planned to, but that’s not what they actually did. What they actually did was to develop a mostly offline game (required online access for login plus chat) that still didnt have persistent zones despite being fully offline at that point in the “player experience” (ie, when you’re playing). Then they worked on a separate version which was server authoritative and at some point (can’t remember the specific time) they decided to bite the bullet & stop developing the offline version in favour of getting the online version working. This is directly in contradiction to what you’ve said.
Yes, though mp was 0.9 not 1.0 (factions, the last 2 masteries).
But yes, they tried their best & hired in external skill to make up for internal deficiencies prior to 0.9.
Yeah, albeit I don’t think that it’s contradictory to what I’m saying there.
After all programming areas to stay persistent needs to provide a underlying system which stores the information, which simply was never made. True that the offline and online components were provided side by side before the release, albeit the persistence feature was likely always a low-priority implementation by itself as it would mostly aid in boss-fight situations or creating more invested dungeons for example. So secondary compared to getting the campaign up and polishing the systems enough to make it release-viable (not that it was in 1.0 with the lacking campaign acts, but that’s another topic).
So given them proceeding a while with that and then backpedaling showcases rather that there’d been a lack of knowledge at the time of just how much work sustaining it going forward would be, and the invested effort being… well… to a large part ‘wasted’ besides getting the respective experience from it. It was deemed not sustainable rather clearly with a properly paced release pipeline initially planned.
Going forward though… with increasing complexity of the core gameplay systems we’ll likely see (and need to see plainly spoken) persistence might become an important aspect though, already fights like Aberroth are a bit… messy without multiple tries.
I’m right there with you. I think to do something like what I was suggested you’d need it to be part of your initial architecture. And probably you’d want everyone to get the same starter campaign. And you’d have to figure out how to handle multiplayer.
I talked myself into it being something awesome without actually thinking about whether it was doable.
Oh that would be such a shame.
The reason the campaign and the echos feels so smooth is because as you learn as a player you become faster. I absolutely HATE how convoluted it is to learn PoE pathing because the campaign maps shift and warp slightly all the time and have several varieties. you cant ever really learn it, you just learn tricks that help you figure out how to navigate the version you are running but I much much much prefer static layouts.
people already complain about backtracking and dungeons which are currently psuedo generated. Do we really need to have normal echos be mazes? I dont think it enhances the replayability while directly annoying the player.