Like most things in coding, the right algorithm to use largely depends on your requirements and boundaries, and this is especially true for sorting algorithms, since each one has their pros and cons.
If you need to sort a list only once without having to update it anymore, you can generally use quicksort.
If you need to keep a sorted list at all times and have to continually add and remove elements, you generally use binary trees (there are several implementations, but the base idea is the same, reduce the time complexity of anything to O(log n)).
That is to say that you need to give more info on what exactly you intend to do with this list, and what kind of changes that list will have over time: is it generated only once at the start of the game? Is it updated over time? Is health really the starting health or the current health? And so on.
For example, if you intend to have a sorted list, which is updated over time with monsters being added and removed from it, but you only care about the starting health, then one assumption you may be able to make is that the same type of monsters will all have the same starting health.
Under this assumption, you could have a list of buckets rather than a simple list, where each bucket would represent a list of monsters with the same starting health, and from there you would just need to sort the buckets and not the monsters.
So if you have 1000 monsters, rather than sorting through 1000 elements, you would need only to sort unique starting health values, reducing the problem to something with 1-10 elements in practice, and at that point you can use any sorting algorithm you wish, be it an optimized one like quicksort, or a naive one with O(n²) time, it won't make much of a different when the number of elements is small.
But this only works if this is indeed your requirement, otherwise you need to provide more info.
TheDane wrote: ↑Tue Jun 30, 2020 11:43 am
Is there any particular reason the original code that sorts the players by score in the scoreboard class cannot be altered to fit your needs?
The problem is the algorithm that code uses: it's somewhat fine for small tiny lists, but it will wreck performance with longer lists, since the time complexity of that function is about O(n(n+1)/2), which is almost as bad as O(n²).
It may be used however if Barbie opts to use bucket lists like I suggested above, since at that point a large list of monsters becomes a small list of buckets to sort instead.