Any other programmers on here? Want to tackle a thought with me?

[Silverine]

Someone on the suggestions board made a suggestion back in 2015 that when looking at a horse's progeny you should be able to see how many points and how much money that horse's offspring have earned. That got me thinking about the best way to keep track of that.

Here are the parameters:
-Each horse is a node. Each node is the child of two other nodes and the parent of a potentially infinite number of child nodes. (Before the implementation of energy used for breeding a stallion actually could have infinite children. That's not the case anymore, but we'll stick with the assumption for now.)
-Each node has two values - points and cash. These values are updated every five minutes (if they change at all).

So which would be better? Adding two new values to each node - childPoints and childCash - which are updated whenever the values in a child are updated, or fetching and summing the values for child nodes whenever they are needed (whenever a horse page is loaded)?

In my mind, the first option would be faster - you only need to look up the single node when loading a horse page - but would take more memory. The second option would be slower, especially on horses that have huge numbers of offspring, but you wouldn't need to store two extra values for every horse in the game.

Thoughts?

[walnut the hamster]

Someone on the suggestions board made a suggestion back in 2015 that when looking at a horse's progeny you should be able to see how many points and how much money that horse's offspring have earned. That got me thinking about the best way to keep track of that.

Here are the parameters:
-Each horse is a node. Each node is the child of two other nodes and the parent of a potentially infinite number of child nodes. (Before the implementation of energy used for breeding a stallion actually could have infinite children. That's not the case anymore, but we'll stick with the assumption for now.)
-Each node has two values - points and cash. These values are updated every five minutes (if they change at all).

So which would be better? Adding two new values to each node - childPoints and childCash - which are updated whenever the values in a child are updated, or fetching and summing the values for child nodes whenever they are needed (whenever a horse page is loaded)?

In my mind, the first option would be faster - you only need to look up the single node when loading a horse page - but would take more memory. The second option would be slower, especially on horses that have huge numbers of offspring, but you wouldn't need to store two extra values for every horse in the game.

Thoughts?

I think both ideas are great. I like the first better but as you said it would take more space, but its more efficient with horses with lots of foals. I think its worth the extra space. IF I have to choose one I would choose the first idea.

[Silverine]

I think both ideas are great. I like the first better but as you said it would take more space, but its more efficient with horses with lots of foals. I think its worth the extra space. IF I have to choose one I would choose the first idea.

Yeah, that's the thing I keep going back and forth on. For the horses with upwards of 100 or more foals it would be so much quicker. But are there really that many of those? Comparatively there's over two million horses on the game.

Let's take a brief break to look at data types:
-A signed int takes 4 bytes and can store a maximum value of 2,147,483,647 (which is too low for the highest two earners on the game, but is more than enough for point values).
-An unsigned int takes 4 bytes and can store a maximum value of 4,294,967,295 (same problem as above).
-A long takes 8 bytes and can store a maximum value of 2⁶³-1, which should be way more than we would ever need for the earnings.

The top twenty pointed horses in the game have a point total of 2,898,093. The top twenty earners in the game have an earning total of 34,985,781,905‬. Looking at those numbers we probably shouldn't used a signed int for offspring point total and definitely shouldn't use an int of any kind for earnings. So let's assume an unsigned int for points and a long for earnings.

With those assumptions, for one million horses (I've cut the number in half because a very large number of horses are rehomed) we'd need four million bytes to store points and eight million bytes for earnings. That's twelve millions bytes or 12MB. Admittedly not that much space. (Even though 12,000,000 bytes certainly looks like a lot! ) If we assume worst case and use a long for both values we'd need sixteen million bytes, or 16MB. Still not bad.

So after all of that I find that I agree. Data store doesn't seem like it would be that big of an issue. Even if we assume that all of the horses up to the current highest ID (which is somewhere around 2300000 though I don't know the exact number) have not been rehomed that would give us a total size of around 28-35MB.

The problem that would have to be considered would be the ever increasing number of horses.

I'd like to do some analysis on query speed for fetching and summing all of the values, but unfortunately I don't have enough knowledge about that aspect to do so reliably.

[walnut the hamster]

ping

I agree. With the number of foals versus the number of foals being rehomed, I think we would be ok. It should balance things out. Again horses die and they can be rehomed. So if at some point there were a lot of horses groups would be rehomed/die.

[Silverine]

I agree. With the number of foals versus the number of foals being rehomed, I think we would be ok. It should balance things out. Again horses die and they can be rehomed. So if at some point there were a lot of horses groups would be rehomed/die.

We'd still have to keep track of the dead ones, though, as they can have points and earnings that affect living horses.

[walnut the hamster]

I agree. With the number of foals versus the number of foals being rehomed, I think we would be ok. It should balance things out. Again horses die and they can be rehomed. So if at some point there were a lot of horses groups would be rehomed/die.

We'd still have to keep track of the dead ones, though, as they can have points and earnings that affect living horses.

That's true! I completly forgot about that. What if, if the horses have no foals and have no earnings then we could forgot about them. They wouldn't effet the living.

[Silverine]

That's true! I completly forgot about that. What if, if the horses have no foals and have no earnings then we could forgot about them. They wouldn't effet the living.

That could work. Kind of like if the horse dies without competing or reproducing then we act like it was rehomed?

Also - a snag I thought of: if including the data in the horse node all existing horses would have to be updated with the two new data points. The queries for that (if horse info is stored in a database like it is in my brain ) should be simple enough to write, but the processing time is something to consider. Though it would be possible to package an update like this with something else and have the game do some downtime while the updates are made live. Or you could do it by itself, but it's such a small update that I don't know how players would feel about downtime for it. (I also have no idea how much time it would require.)

[walnut the hamster]

That's true! I completly forgot about that. What if, if the horses have no foals and have no earnings then we could forgot about them. They wouldn't effet the living.

That could work. Kind of like if the horse dies without competing or reproducing then we act like it was rehomed?

Also - a snag I thought of: if including the data in the horse node all existing horses would have to be updated with the two new data points. The queries for that (if horse info is stored in a database like it is in my brain ) should be simple enough to write, but the processing time is something to consider. Though it would be possible to package an update like this with something else and have the game do some downtime while the updates are made live. Or you could do it by itself, but it's such a small update that I don't know how players would feel about downtime for it. (I also have no idea how much time it would require.)

You are right, I know I wouldn't mind but I don't know about everyone else. There could be a vote to see how many people would want it and stuff.

[BlackOak2]

Note: NOT a programmer.
This, the first option.
How difficult would it be to have a search-and-update for the existing horses (once profile is opened, it updates itself and enacts the code in real-time), so once opened by anybody the first time, it runs the code just that once, but all newborn after the update already has it running? Thus all the horses that have ever been visited will have it in real-time, but those that aren't simply will have a code that could run, but hasn't.
Therefore the downtime while updating all the horses can be minimized and those that might never be looked at 'again' would simply not take up any room or time for the system?

*************
Personally, though I'm for the second option. Because the progeny already takes time to load anyway and will only load 8 at a time.

I do see it as a potential nicety and problem, but for me, I really don't see an offspring as a competitor unless they're titled, which can be seen right from the progeny page already. But again, that's me.