RevengeRoman wrote: » *snip*.
RevengeRoman wrote: » I think technology is a limitation here realistically. Not that randomness couldn't be implemented to an extent, but that doing it in runtime on a live server has some extensive hardware limitations and software limitations that would need to be sorted first. This may be theoretically possible. But I feel in the spirit of what you're asking for, it is currently outside the scope of Ashes of Creation in its current goals. Definitely something that could be cool for immersion down the road though.
peksi wrote: » If MMO is too predictable it results in bored endgame where all the mysteries of the game are demystified in thousand youtube howto / build videos leaving nothing to solve. This is what happened to New World. Dynamic, unpredictable content will be medicine for that. Narc sums it up nicely in his YouTube video.
Azherae wrote: » RevengeRoman wrote: » I think technology is a limitation here realistically. Not that randomness couldn't be implemented to an extent, but that doing it in runtime on a live server has some extensive hardware limitations and software limitations that would need to be sorted first. This may be theoretically possible. But I feel in the spirit of what you're asking for, it is currently outside the scope of Ashes of Creation in its current goals. Definitely something that could be cool for immersion down the road though. I can't say what the Ashes team is, or isn't, capable of, but there are multiple models that do this fine. Randomness and Finite State Machine style responsiveness for enemies in an MMO setting is at least as easy as it is in flight combat games because the decision trees for single combat with smaller environmental factors are easy. On top of that, if the enemies were going to be predictable in most ways if you didn't do this, then there's not often huge downsides to implementing it. Hardcore players might find a way to 'cheese' or 'exploit' a creature or boss' decision tree to lower how threatening they are, but that's a form of emergent gameplay that a lot of people really like, and singular patches to enemies would probably make it through without issues, especially with the amount of testing they intend to do. I'm really interested to know what technical limitations you would expect to exist in this case, therefore. Maybe you're visualizing a level of AI behaviour that is far beyond what I'm thinking of. I admit that most things in Alpha-1 didn't show anything beyond rudimentary rotations, as one might expect from a technical Alpha where they planned to revamp the combat, but based on the other parts of it, I dunno what you're seeing. Thoughts?
RevengeRoman wrote: » Azherae wrote: » RevengeRoman wrote: » I think technology is a limitation here realistically. Not that randomness couldn't be implemented to an extent, but that doing it in runtime on a live server has some extensive hardware limitations and software limitations that would need to be sorted first. This may be theoretically possible. But I feel in the spirit of what you're asking for, it is currently outside the scope of Ashes of Creation in its current goals. Definitely something that could be cool for immersion down the road though. I can't say what the Ashes team is, or isn't, capable of, but there are multiple models that do this fine. Randomness and Finite State Machine style responsiveness for enemies in an MMO setting is at least as easy as it is in flight combat games because the decision trees for single combat with smaller environmental factors are easy. On top of that, if the enemies were going to be predictable in most ways if you didn't do this, then there's not often huge downsides to implementing it. Hardcore players might find a way to 'cheese' or 'exploit' a creature or boss' decision tree to lower how threatening they are, but that's a form of emergent gameplay that a lot of people really like, and singular patches to enemies would probably make it through without issues, especially with the amount of testing they intend to do. I'm really interested to know what technical limitations you would expect to exist in this case, therefore. Maybe you're visualizing a level of AI behaviour that is far beyond what I'm thinking of. I admit that most things in Alpha-1 didn't show anything beyond rudimentary rotations, as one might expect from a technical Alpha where they planned to revamp the combat, but based on the other parts of it, I dunno what you're seeing. Thoughts? @Azherae Let me clarify, I don't think it's unreasonable to expect that AI patterns or bosses should randomize to some extent. I was under the understanding that OP was speaking about procedurally generated dungeons or mobs that change behaviors based on seasons, months, or other global variables. Given that the hardware, server side and PC side, would allow for such calculations while still maintaining the relatively low minimum system requirements and user bandwidth requirements. These things are not impossible, but I believe they may stray outside of the immediate goals for the launch of Ashes. Maybe Im wrong, I have not seen anywhere where the team have talked about global variables affecting anything other than cosmetic stuff. An example being the Turtle from the October 2021 dev stream where the environment on its shell reacts to the weather and seasons. With that said if anyone has some further technical input as far as feasibility is concerned, I'd like to hear it. My knowledge on these systems stems from the college courses I'm taking now on networking and is fairly limited in scope.
RevengeRoman wrote: » @Azherae I guess really the question is whether this is on the pre-launch road map or if this is something we shouldn't expect until post-launch if at all. From a Technical stand point, the numbers I've found online suggest that FFXI sees about 2.5k-3k players on their most populated server. That's according to the below reddit post though.https://www.reddit.com/r/ffxi/comments/fhktcl/whats_the_most_populated_ffxi_server_in_2020/ Here is another forum post that seems to corroborate the first. If not in numbers, in sentiment.https://forum.square-enix.com/ffxi/threads/57779 That said the per server player count seems significantly lower on FFXI servers than Ashes servers will likely be. Not saying it can't be done. But I am saying that scale is a huge factor in what's feasible for Ashes. The deciding factor I imagine will be on how it affects the minimum specs. Yes the majority of these calculations can be done server side. But it still takes additional processing power and bandwidth on the users end to implement such systems. I don't have exact numbers nor will I claim to and it's something I'd be interested to see, purely out of my own professional curiosity. That said it is just something to keep in mind.
RevengeRoman wrote: » @Azherae My perspective is based purely off of the little I've learned in a year and a half of college Computer Information Technology (Networking). Take anything I say with a grain of salt. Most of it is based on what data I can find openly on the internet and trying to use basic trains of logic to assess things. My train of logic in this instance is fairly simple; Numbers generated by the server to determine AI patterns have to be sent to the user PC. | | / MMO's that currently exist on the market have stability issues, either as a result of bad net code, poor infrastructure, or both. | | / Ashes is an ambitious MMO with 2x-4x the players per server and a much more detailed open world than has been attempted before. | | / Theoretically more data must be transferred to supply the info live to the AI meaning more bandwidth is necessary and more processing power is necessary to direct those variables to the correct groups, etc. Again, I don't have exact numbers, nor do I claim to. I am not an expert, just a dude who loves networking and technology wondering aloud about how these systems would affect the minimum requirements to run the game. It's entirely possible Especially considering the bandwidth bit. I have trash internet out where I'm at in the middle of nowhere. Even basic games struggle with my internet sometimes. Hopefully my Starlink set will show up eventually though.
RevengeRoman wrote: » @Azherae I think I understand, so basically speaking; On the Server side most, if not all, calculations pertaining to the world persistence should be performed. Whether these are damage calculations, weather status and type, time of day, season, AI behavior, etc. These would be performed server side, and then the client side would just be updated on their status and then rendered onto the screen for the player? I take it then, the server side variables like those mentioned above very rarely have any significant impact on performance when coded correctly? I am genuinely interested in the technical aspects, I don't suppose you have a Discord account or would otherwise be willing to communicate more at length about some of these topics?
Azherae wrote: » RevengeRoman wrote: » @Azherae I think I understand, so basically speaking; On the Server side most, if not all, calculations pertaining to the world persistence should be performed. Whether these are damage calculations, weather status and type, time of day, season, AI behavior, etc. These would be performed server side, and then the client side would just be updated on their status and then rendered onto the screen for the player? I take it then, the server side variables like those mentioned above very rarely have any significant impact on performance when coded correctly? I am genuinely interested in the technical aspects, I don't suppose you have a Discord account or would otherwise be willing to communicate more at length about some of these topics? Generally when I'm discussing these sorts of things, I do them right in forums. Depending on whether or not it would derail the topic. I feel like, this time, it's relatively on topic to discuss outright. Yes, all those calculations are performed server side in games not made by Amazon. The ways in which you code and 'trick' the system into not needing to do too much work differs by design and by goals. For example, in one of my designs, an underlying variable similar to that one, which is known to not be able to change too rapidly, will 'broadcast' its result data to any process that pings it with very little overhead (the scheduler suffers a lot more than the processing, and is optimized separately according to the game). If two separate processes ping for the value at the same time, it simply provides them both the data required without actually doing the calculation part twice, and certain (somewhat dangerous) optimizations allow the 'answer given to Process B' to be 'the location in memory that it just provided to process A' or an equivalent without even an internal access flow. It is definitely true that for large scale games with many players on the server, problems can arise, but I can assure you that Ashes' current development incorporates at least some 'sub-world' processing, as my group encountered bugs in Alpha-1 that were directly related to edge cases in the 'shards' (no worries, reported with probably too much information). If Intrepid found that these things were causing a performance hit in large scale battles, with many players in the same place, the system would almost certainly switch to an alternate function with a static value that was obtained at the beginning of the instance. I believe this is actually already how it is coded partially, based on the bug we encountered. (not that it switches, but that functions of that type with pinged statics exist relative to shards) So if the Frost Dragon caused a blizzard, and 500 people came into the area to fight over it, it wouldn't run the code that 'checks if the weather changed' as part of 'did this ice spell do extra damage', but when thousands of players are spread over the 'SW' map, the processes must be running anyway. So in short, yes, there will be too many issues if anything but the most basic, or most explicitly chosen, of the game's calculations, are done on the client side.Except in this case, of course.
RevengeRoman wrote: » Azherae wrote: » RevengeRoman wrote: » @Azherae I think I understand, so basically speaking; On the Server side most, if not all, calculations pertaining to the world persistence should be performed. Whether these are damage calculations, weather status and type, time of day, season, AI behavior, etc. These would be performed server side, and then the client side would just be updated on their status and then rendered onto the screen for the player? I take it then, the server side variables like those mentioned above very rarely have any significant impact on performance when coded correctly? I am genuinely interested in the technical aspects, I don't suppose you have a Discord account or would otherwise be willing to communicate more at length about some of these topics? Generally when I'm discussing these sorts of things, I do them right in forums. Depending on whether or not it would derail the topic. I feel like, this time, it's relatively on topic to discuss outright. Yes, all those calculations are performed server side in games not made by Amazon. The ways in which you code and 'trick' the system into not needing to do too much work differs by design and by goals. For example, in one of my designs, an underlying variable similar to that one, which is known to not be able to change too rapidly, will 'broadcast' its result data to any process that pings it with very little overhead (the scheduler suffers a lot more than the processing, and is optimized separately according to the game). If two separate processes ping for the value at the same time, it simply provides them both the data required without actually doing the calculation part twice, and certain (somewhat dangerous) optimizations allow the 'answer given to Process B' to be 'the location in memory that it just provided to process A' or an equivalent without even an internal access flow. It is definitely true that for large scale games with many players on the server, problems can arise, but I can assure you that Ashes' current development incorporates at least some 'sub-world' processing, as my group encountered bugs in Alpha-1 that were directly related to edge cases in the 'shards' (no worries, reported with probably too much information). If Intrepid found that these things were causing a performance hit in large scale battles, with many players in the same place, the system would almost certainly switch to an alternate function with a static value that was obtained at the beginning of the instance. I believe this is actually already how it is coded partially, based on the bug we encountered. (not that it switches, but that functions of that type with pinged statics exist relative to shards) So if the Frost Dragon caused a blizzard, and 500 people came into the area to fight over it, it wouldn't run the code that 'checks if the weather changed' as part of 'did this ice spell do extra damage', but when thousands of players are spread over the 'SW' map, the processes must be running anyway. So in short, yes, there will be too many issues if anything but the most basic, or most explicitly chosen, of the game's calculations, are done on the client side.Except in this case, of course. So then theoretically speaking IS wouldn't even need to have the system perpetually check the status of say the AI behavior of X mob. IS could simply say every two weeks is a new season and have it check on specific dates at specific times and change the AI behavior then without having to have that process perpetually taking up resources.
Azherae wrote: » RevengeRoman wrote: » Azherae wrote: » RevengeRoman wrote: » @Azherae I think I understand, so basically speaking; On the Server side most, if not all, calculations pertaining to the world persistence should be performed. Whether these are damage calculations, weather status and type, time of day, season, AI behavior, etc. These would be performed server side, and then the client side would just be updated on their status and then rendered onto the screen for the player? I take it then, the server side variables like those mentioned above very rarely have any significant impact on performance when coded correctly? I am genuinely interested in the technical aspects, I don't suppose you have a Discord account or would otherwise be willing to communicate more at length about some of these topics? Generally when I'm discussing these sorts of things, I do them right in forums. Depending on whether or not it would derail the topic. I feel like, this time, it's relatively on topic to discuss outright. Yes, all those calculations are performed server side in games not made by Amazon. The ways in which you code and 'trick' the system into not needing to do too much work differs by design and by goals. For example, in one of my designs, an underlying variable similar to that one, which is known to not be able to change too rapidly, will 'broadcast' its result data to any process that pings it with very little overhead (the scheduler suffers a lot more than the processing, and is optimized separately according to the game). If two separate processes ping for the value at the same time, it simply provides them both the data required without actually doing the calculation part twice, and certain (somewhat dangerous) optimizations allow the 'answer given to Process B' to be 'the location in memory that it just provided to process A' or an equivalent without even an internal access flow. It is definitely true that for large scale games with many players on the server, problems can arise, but I can assure you that Ashes' current development incorporates at least some 'sub-world' processing, as my group encountered bugs in Alpha-1 that were directly related to edge cases in the 'shards' (no worries, reported with probably too much information). If Intrepid found that these things were causing a performance hit in large scale battles, with many players in the same place, the system would almost certainly switch to an alternate function with a static value that was obtained at the beginning of the instance. I believe this is actually already how it is coded partially, based on the bug we encountered. (not that it switches, but that functions of that type with pinged statics exist relative to shards) So if the Frost Dragon caused a blizzard, and 500 people came into the area to fight over it, it wouldn't run the code that 'checks if the weather changed' as part of 'did this ice spell do extra damage', but when thousands of players are spread over the 'SW' map, the processes must be running anyway. So in short, yes, there will be too many issues if anything but the most basic, or most explicitly chosen, of the game's calculations, are done on the client side.Except in this case, of course. So then theoretically speaking IS wouldn't even need to have the system perpetually check the status of say the AI behavior of X mob. IS could simply say every two weeks is a new season and have it check on specific dates at specific times and change the AI behavior then without having to have that process perpetually taking up resources. This is how I would do it for most related things on the level of 'time of day segment'. Weather is harder to judge but probably not too overloading. Another useful way (but players abuse if it is too tightly correlated) is to tie certain aspects to things that the mob must have anyway. AI behavior in most games doesn't even have to actually be 'intelligent', just 'a confluence of random factors that result in a useful probability distribution'. At least, in order to achieve the goal brought up by @peksi in the OP. There are a lot of things that must be logged and tracked for a mob's behaviour that can be easily fiddled with to create AI, in an MMO. The server performance is usually the last thing to worry about, nowadays the skill of the designer will almost always be the limiting factor. If they can get 250x250 sieges running in a Siege Map instance, I'd definitely assume that 'unpredictability' and 'nature' are within reach.
Azherae wrote: » If they can get 250x250 sieges running in a Siege Map instance, I'd definitely assume that 'unpredictability' and 'nature' are within reach.
