[DiscordArchive] The real question is how can you expect implement tests for things like spells ?
[DiscordArchive] The real question is how can you expect implement tests for things like spells ?
Original source
The real question is how can you expect implement tests for things like spells ?
rektbyfaith
03-10-2024, 10:13 PM #1Archived author: Berti • Posted: 2024-03-10T22:13:58.025000+00:00
Original source
The real question is how can you expect implement tests for things like spells ?
Original source
You require a functional test in order to see if the spell is working as should in terms of visual things and that
rektbyfaith
03-10-2024, 10:14 PM #2Archived author: Berti • Posted: 2024-03-10T22:14:35.956000+00:00
Original source
You require a functional test in order to see if the spell is working as should in terms of visual things and that
Original source
Maybe with dmg and that is different but for other things, you require see the things in game.
rektbyfaith
03-10-2024, 10:14 PM #3Archived author: Berti • Posted: 2024-03-10T22:14:58.202000+00:00
Original source
Maybe with dmg and that is different but for other things, you require see the things in game.
Original source
And about OO tell me another way to do scripts for pve without using OO
rektbyfaith
03-10-2024, 10:15 PM #4Archived author: Berti • Posted: 2024-03-10T22:15:18.011000+00:00
Original source
And about OO tell me another way to do scripts for pve without using OO
Original source
You could write a function for each thing that a boss requires, but how you group that together _
rektbyfaith
03-10-2024, 10:15 PM #5Archived author: Berti • Posted: 2024-03-10T22:15:51.909000+00:00
Original source
You could write a function for each thing that a boss requires, but how you group that together _
Original source
?
rektbyfaith
03-10-2024, 10:15 PM #6Archived author: Berti • Posted: 2024-03-10T22:15:52.870000+00:00
Original source
?
Original source
i think the notion that TCs or emulators issue would be an exaggerated obsession with oop is a stretch. the primary entity hierarchy that tc/mangos uses comes largely from the game itself (mapped around updatedata) and rarely maps onto more than a single concern in that regard - the reason things are such a clusterfuck and primary objects are enormous has more to do with what a mess the game is itself and us just tacking shit onto the closest thing that made sense at the time. It's not an ECS, but turning emulators into one would probably do less than you'd expect given the nature of how its logic actually plays out.
in regards to cache optimizations, much of time spent updatedata is just spent assembling it in order (and without extremely complex logic needs to be assembled like that to emulate the game correctly - projects that simplify this _always_ "break" it in the process), which makes it into a large chunk of memory you can't do a whole lot about aside from splitting other O(n^>1) fields out of it - it's already cache optimized for most of its access time. On top of updatedata you then have a massive _generic spell system_, which is despite emulators implementation just a big pile of dynamic dispatch controlling much of the game world at the end of the day - that's just the kind of game that wow is.
there's still tons of cache and other optimizations to be made, and i'd agree the important ones have little to do with parallelized chunk updates, but they similarly have very little to do with primary object hierarchy and much more to do with improving the 3-4 O(n^2) systems that take up the overwhelming majority of congested map update times.
we run all our tests in simulations, i'm sure ascension devs have a better idea of how it plays out in practice, but it's insane how much faster you can make emulators by fixing the few systems that are actually broken
rektbyfaith
03-10-2024, 10:18 PM #7Archived author: <o> • Posted: 2024-03-10T22:18:57.056000+00:00
Original source
i think the notion that TCs or emulators issue would be an exaggerated obsession with oop is a stretch. the primary entity hierarchy that tc/mangos uses comes largely from the game itself (mapped around updatedata) and rarely maps onto more than a single concern in that regard - the reason things are such a clusterfuck and primary objects are enormous has more to do with what a mess the game is itself and us just tacking shit onto the closest thing that made sense at the time. It's not an ECS, but turning emulators into one would probably do less than you'd expect given the nature of how its logic actually plays out.
in regards to cache optimizations, much of time spent updatedata is just spent assembling it in order (and without extremely complex logic needs to be assembled like that to emulate the game correctly - projects that simplify this _always_ "break" it in the process), which makes it into a large chunk of memory you can't do a whole lot about aside from splitting other O(n^>1) fields out of it - it's already cache optimized for most of its access time. On top of updatedata you then have a massive _generic spell system_, which is despite emulators implementation just a big pile of dynamic dispatch controlling much of the game world at the end of the day - that's just the kind of game that wow is.
there's still tons of cache and other optimizations to be made, and i'd agree the important ones have little to do with parallelized chunk updates, but they similarly have very little to do with primary object hierarchy and much more to do with improving the 3-4 O(n^2) systems that take up the overwhelming majority of congested map update times.
we run all our tests in simulations, i'm sure ascension devs have a better idea of how it plays out in practice, but it's insane how much faster you can make emulators by fixing the few systems that are actually broken
Original source
adding to that, on blizz servers a lot more of what we handle with hardcoded logic is a bunch of serverside spells
rektbyfaith
03-10-2024, 10:22 PM #8Archived author: Tea • Posted: 2024-03-10T22:22:12.315000+00:00
Original source
adding to that, on blizz servers a lot more of what we handle with hardcoded logic is a bunch of serverside spells
Original source
which just adds into the "dynamic dispatch" part
rektbyfaith
03-10-2024, 10:22 PM #9Archived author: Tea • Posted: 2024-03-10T22:22:21.427000+00:00
Original source
which just adds into the "dynamic dispatch" part
Original source
and shows that it can actually work
rektbyfaith
03-10-2024, 10:22 PM #10Archived author: Tea • Posted: 2024-03-10T22:22:32.169000+00:00
Original source
and shows that it can actually work
1 Guest(s)
1 Guest(s)