Greetings, glorious testers!

Check out Alpha Two Announcements here to see the latest news on Alpha Two.
Check out general Announcements here to see the latest news on Ashes of Creation & Intrepid Studios.

To get the quickest updates regarding Alpha Two, connect your Discord and Intrepid accounts here.

Importance of unpredictability

This is a very common promise which has never been met but you dev guys seem to put your heart into AOC and if anyone can pull this off it is you. I am talking about NPC unpredictability in their behavior.

What flatlines my MMO experience is to see mindless NPC bot creatures that move back and forth a simple pattern, chase you for $range meters, switch to retreat indestructible mode and continue their pattern. Or creatures that seem more complex but after googling you got that standard pattern that works every time reducing it to a test of muscle memory.

I know in the end it is just parameters and patterns but how about adding some chaos into equation? Give creatures something called “nature” which affects their decisions, make their nature affected by weather, number of close by players, time of year, mating season, wind, balance of the zone or maybe even some developer set global chaos parameter that they set when having morning coffee break.

By applying this to NPCs you could make their behavior an indicator of their actions / threat. Players could learn to recognize threat from the actual behavior: beasts more powerful are not scared of you, some want to eat you and beasts weaker will flee. Some are maybe curious, some don’t even notice you, some want to make friends.

This kind of decision tree is hard to pull off but once you get it working it should just be there for whatever creature you will come up with.

Comments

  • CawwCaww Member, Alpha Two
    It would be fun to not know what the h*ll that crazy thing (NPC) is doing, talk about keeping you on your toes.
  • VoxtriumVoxtrium Member, Alpha Two
    I know they have said they will implement randomness to the likelihood of a raid boss using an ability.
  • DygzDygz Member, Braver of Worlds, Kickstarter, Alpha One, Alpha Two, Early Alpha Two
    edited April 2022
    AI is a programming limitation.
    The design for this game does not have a goal to try to overcome those limitations.
    That being said:


    One of the design elements that we're implementing into our raids is that the raid will not be exactly the same every single time. You're going to have variables that can't necessarily be pre-planned out for. You can pre-plan out for a lot of the raid like how many DPS do you need and healers and support; where the key position and all that kind of stuff; but I think the compelling aspect of Ashes raiding will be the difficulty in achieving this content and having that content change from session to session as well. We want there to be variables that get manifested by you know what type of node got developed elsewhere. Is he going to have acolytes or cultists? What will the acolytes have skills [available] to them? What kit is the boss gonna have? What available skill repertoire will the boss be able to [wield]? ... A lot of those systems are influenced obviously by world development. So the raid kind of takes into account at what stage has the world developed: Are there two metropolises now available in the world? Okay well let's activate this skill in this skill. Now you have five metropolises, well now all these skills have been activated. Are there are they all economic nodes? Are they all military nodes? That we can change things based on that stuff. And it really is a threat assessment from the environment against the players.
    ---Steven


    Combat itself will be pretty intricate mechanics-wise. We're going to have different phases of the bosses, there's going to be a lot of adds stuff, there's going to be random oriented skill usage. We're not going to have telegraphed templates on the ground, but we will have telegraphed animations, so it's going to be location, mobility, strategic. It will be something that can not be repeatable in the exact same way from raid to raid, but has a variance between the combat, so raiders are going to have to be fluid in thinking on their feet.
    ---Steven
  • peksipeksi Member
    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.
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    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.
  • HumblePuffinHumblePuffin Member, Braver of Worlds, Kickstarter, Alpha One, Alpha Two, Early Alpha Two
    *snip*.

    They already do plan to include variance to bosses (“Ashes of Creation utilizes an adaptive artificial intelligence (AI), which means that different encounters with similar creatures will yield different player experiences”) and I don’t think it’s too far out of the scope for the game ashes wants to be. You also already see this in some current games.

    Legends of Arceus(new Pokémon game), has some Pokémon that attack like normal when in aggro range, some run away as soon as they see you, some run to you interested and will follow you around. Murlocs in WoW run away when their scripted brains realize the fight is lost.

    Not minimizing how much more complex this would be in an MMO with multiple players in an area and other factors, just saying that adaptive A.I. is already planned to be in game and there’s definitely a chance we could see many of the things listed in OP.
  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    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?
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • VeeshanVeeshan Member, Alpha Two
    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.

    its also non raids oldschool games suchs as everquest had patroling mobs that could appear out of no where at times and make a fight interesting when you agro more than you expect, you also have mobs that run which can agro more, they even had higher level mobs patrolling lower level zones to keep you on the toes (WoW BC Fel reavers) if the only other instance i can think of that has anything close to that.

    One reason i enjoy open world PvP is i treat those as patroling bandits and they provide the now absent unpredictability in MMORPG, i cant play any game that dont have open world pvp these days because i find current pve so boring and stale without the possibilty of being jumped by somone.
    PvE players who are like nope i wont ever pvp i say just consider Pks players as smart AI patroling the landscape to add a challenging experience :P

  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    Azherae 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.
  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    Azherae 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.

    Hmk, I can't speak to procedurally generated dungeons, but I can say that the main MMO I play at the moment dynamically changes the following based on certain weather conditions in a zone and in some cases the current moonphase (time of day also).

    1. The spawn points or spawn capacity of certain creatures.
    2. The aggressiveness and pathing/patrol of certain creatures.
    3. The effectiveness of certain detection abilities used by both players and creatures
    4. The effectiveness of elemental magic abilities based on the attuned day of the week as well as the current weather
    5. The AI for which attacks the creature uses based on the 'known' diminished effectiveness of the spell or ability, i.e. an enemy healer will default to a protective spell + regeneration spell on the day of the week when healing spells are at their weakest.
    6. (Theorized) - The difficulty in a Beastmaster successfully charming a target mob to get a temporary companion

    I can't say with certainty how quickly this updates, but I would not have any expectation of difficulty in coding this, the server is doing the arbitration on things like damage anyway, and the server 'knows that it just started to rain' in a zone regardless. I've definitely had that moment of 'casting a spell and in that moment, a thunderstorm officially starts, a Thunder Elemental spawns, and detects me (they aggro to magic) and now I have to fight it'.

    There have been hints of this in various places in discussion here, and it's a fairly common thing in MMOs, with the new Throne and Liberty, for example, implying that it will be one of their mainstay features. FFXI, the one I refer to above, is 20 years old now, and the list I gave is actually only half of the things that change dynamically in enemy movement and strategy (the others don't change in response to weather, moreso other factors).
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    @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.
  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    @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.

    I'm not sure where that perspective comes from, but I can assure you that in my professional experience, the server load for that specific type of calculation is not a relevant point in a good implementation. I'm also not aware of any reasons it would require processing power or bandwidth on the user end.

    For your reference I am a former technical director at a certain enterprise search engine company and part of a small design team currently. The language I usually use to implement this sort of thing where the servers have to handle such interactions is 'as seen in sig', lol, but there are definitely better options, such as diving straight into the optimization at the assembly level (my experience with this is only intermediate).

    I'm therefore interested to learn what you perceive the additional processing power on the user end to be, and I mean that truly, since if you have such information relative to any of the current design suites in use by other designers, I feel it's in my best interest to become familiar with it.
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    @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.
  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    @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.

    Ah, my bad, I think I came off differently than I intended to by trying not to jump to a specific conclusion.

    Short version: I am an expert, working with other experts. While what you say is true, and cannot ever be 'denied', it's not really part of the system, the very first 'assumption' in your chain is 'wrong'.

    Long version continuation:

    "Numbers generated by the server to determine AI patterns have to be sent to the user PC."

    This isn't what happens, at least I really hope not, or we have another New World on our hands. AI patterns are handled by subprocesses or actors on the server side, entirely. The only time this would get close to being true is if the player used an ability to cause a behavioural change, but since all player activities should (I'd like to say 'must', but once again, New World) be sent to the server for processing and authentication anyway, only the speed of the server farm and the number of processes the server can handle, matter to this. In particular, communications and parsing can be linked in through all sorts of methods so that the processes running the macrostate of the server don't have to interact as rapidly. If anything you'd be worried about caching or inter-process lag, but without getting too into that, let's just say that a single (Erlang) VM can run hundreds of thousands of such processes at once, and over a distributed server farm.

    MMOs suffer because of rollback and netcode issues due to action invalidation, and enemy AI isn't technically one of those places where rollback is a meaningful bottleneck to performance or has high requirements, any more than any complex damage calculation.
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    @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?

  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    @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.
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    Azherae 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.
  • AzheraeAzherae Member, Alpha One, Alpha Two, Early Alpha Two
    Azherae 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.
    ♪ One Gummy Fish, two Gummy Fish, Red Gummy Fish, Blue Gummy Fish
  • RevengeRomanRevengeRoman Member, Alpha One, Alpha Two, Early Alpha Two
    Azherae wrote: »
    Azherae 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.

    Thank you for taking the time to provide this insight. It's actually fascinating to me reading more into these things. Especially in that I hope to one day work in that field in a couple years time.

    Having seen 1300 "player" environment running, it definitely would appear that they have significant head room available. Though I believe that was more of a render test than a test of net code. It will certainly be interesting to play come A2 and seeing what I can break lol.
  • NoaaniNoaani Member, Intrepid Pack, Alpha Two
    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.
    I agree with you here.

    What I personally doubt though, is whether such things are in the scope of the game.

    If I were developing a game where250v250 battles were possible (potentially 500v500), then I would likely make that the focus of my game from day 1 (as Ashes has done). If I were developing a game where AI was used to add some unpredictability, then I would likely make that the focus of my game from day 1.
  • peksipeksi Member
    To introduce more variables into the ai behavior I think a viable solution is to delegate the new variable calculation to a external system or systems. I think the biggest challenge may be data transfer between these distributed systems due millions of parallel transactions.

    But the player driven world in itself introduces a lot of unpredictability to the game already which is incredible.
  • VaknarVaknar Member, Staff
    Dygz wrote: »
    AI is a programming limitation.
    The design for this game does not have a goal to try to overcome those limitations.
    That being said:


    One of the design elements that we're implementing into our raids is that the raid will not be exactly the same every single time. You're going to have variables that can't necessarily be pre-planned out for. You can pre-plan out for a lot of the raid like how many DPS do you need and healers and support; where the key position and all that kind of stuff; but I think the compelling aspect of Ashes raiding will be the difficulty in achieving this content and having that content change from session to session as well. We want there to be variables that get manifested by you know what type of node got developed elsewhere. Is he going to have acolytes or cultists? What will the acolytes have skills [available] to them? What kit is the boss gonna have? What available skill repertoire will the boss be able to [wield]? ... A lot of those systems are influenced obviously by world development. So the raid kind of takes into account at what stage has the world developed: Are there two metropolises now available in the world? Okay well let's activate this skill in this skill. Now you have five metropolises, well now all these skills have been activated. Are there are they all economic nodes? Are they all military nodes? That we can change things based on that stuff. And it really is a threat assessment from the environment against the players.
    ---Steven


    Combat itself will be pretty intricate mechanics-wise. We're going to have different phases of the bosses, there's going to be a lot of adds stuff, there's going to be random oriented skill usage. We're not going to have telegraphed templates on the ground, but we will have telegraphed animations, so it's going to be location, mobility, strategic. It will be something that can not be repeatable in the exact same way from raid to raid, but has a variance between the combat, so raiders are going to have to be fluid in thinking on their feet.
    ---Steven

    Very well said, @Dygz !
    community_management.gif
Sign In or Register to comment.