Each bike needs it's own leaderboard. | Forums

[ComradePete]

I don't think it would need additional space - just a filter on the leaderboards so it would display times by a particular bike. All they need to add is a new way to display the information already there.

[Scruffy McGuffy]

I disagree it would take a lot more storage space. Only a fraction of players are going to use more than 1 bike, and only a fraction of those would use all 8. I doubt replays take up much room, but even if they do, store only the top 1K or whatever, and keep your own replay of your best run (and split times at checkpoints) for that session only. How much space is a leaderboard anyway? It's probably a 32-bit hashcode for each user id, and they could easily fit the bike and time in 32-bits. That's 8 bytes per entry. Even at 500K entries in a leaderboard that's not even 4MB. Go up to 4M entries if every player used every bike, that's still only 32MB for a track. For 320 tracks with every user using every bike, that's 10GB. I have 100GB of online storage in my psn cloud!

Let's be honest, the real reason is "don't care".

[LIONDEN1]

Maybe i missed something but what other trails games had separate leader boards for each bike?

[TyrianMollusk]

I don't think it would need additional space - just a filter on the leaderboards so it would display times by a particular bike. All they need to add is a new way to display the information already there.

The current leaderboard only stores one run per player. To have different bike leaderboards, it has to store a run for each bike for each player. The extra bike runs are not already there.

I disagree it would take a lot more storage space.

Leaderboard stores userid, time, score, faults, and bike. They might be able to fit that in 32 bits, but I seriously doubt they tried, especially given their level of code savvy. Probably stored each value in its own table column. At least score is a separate value. To have individual bike leaderboards, the bike would have to be separate, too. Replays store a fair bit of data, since it's a 30fps input map. Not a lot on its own, but for every player for every track they ever touch with every bike they tried over the life of the game... definitely adds up when you have to filter through all that or every player glancing at a leaerboard (you can bet this overhead is already why they don't just show leaderboard summaries anymore, and make you specifically open them, and why leaderboard scrolling is already so slow).

Most players will ride more than one bike. Not just to try a combination or because they didn't take the preferred bike, but because contracts require specific bike runs all over the built in tracks. Separate leaderboards will also certainly create a lot of extra bike runs, too. It won't take the maximum possible space, but they'd be looking at a lot more, regardless.

Lets also not forget there are some existing back-end issues on the leaderboards. They said the "no run recorded if over 30m" problem was a limitation of the Ubisoft leaderboards, like they aren't actually in charge of the leaderboard storage system. That could be a bigger dealbreaker than storage and management.

Not bigger factors than "don't care", but significant nonetheless.

[Scruffy McGuffy]

Maybe i missed something but what other trails games had separate leader boards for each bike?

What relevance is that? Nobody is complaining that it's a previously included feature removed for this iteration.

It's more important than ever in Rising because:

1) With 9 bikes (so far...), there are already more bikes than any previous Trials.
2) Publishers love engagement these days, and this would obviously encourage more engagement.

[Scruffy McGuffy]

The current leaderboard only stores one run per player. To have different bike leaderboards, it has to store a run for each bike for each player. The extra bike runs are not already there.

Leaderboard stores userid, time, score, faults, and bike. They might be able to fit that in 32 bits, but I seriously doubt they tried, especially given their level of code savvy. Probably stored each value in its own table column. At least score is a separate value. To have individual bike leaderboards, the bike would have to be separate, too. Replays store a fair bit of data, since it's a 30fps input map. Not a lot on its own, but for every player for every track they ever touch with every bike they tried over the life of the game... definitely adds up when you have to filter through all that or every player glancing at a leaerboard (you can bet this overhead is already why they don't just show leaderboard summaries anymore, and make you specifically open them, and why leaderboard scrolling is already so slow).

Most players will ride more than one bike. Not just to try a combination or because they didn't take the preferred bike, but because contracts require specific bike runs all over the built in tracks.

Lets also not forget there are some existing back-end issues on the leaderboards. They said the "no run recorded if over 30m" problem was a limitation of the Ubisoft leaderboards, like they aren't actually in charge of the leaderboard storage system. That could be a bigger dealbreaker than storage and management.

Not bigger factors than "don't care", but significant nonetheless.

Fact is, if you run the numbers, storage concern is simply not a big deal. And if replay storage was considered too much, that's very easily solved by limiting that to the top X saved. I did forget fault count, that's max 500, which is 9 bits. Score can be computed from the other stored information.

This is the first I've heard that they blame the "no run recorded if over 30 mins" on Ubi's LB system. In fact I've never even seen them acknowledge this long-standing Trials bug. Besides, that's irrelevant here unless there's some cap on total storage space allowed, since entries should always be stored, with or without a replay attached. Again, if total storage available is an issue, easily fixed, only the top 100 get a replay, boom, solved.

[LIONDEN1]

I was just wondering, Fusion was my first Trials game, dont know much about HD or Evo. I'd be all for separate leader boards for each bike. but still need to keep over all leader board even if its only for the top 1% since most people cant compete because of ninjas.

[Scruffy McGuffy]

I was just wondering, Fusion was my first Trials game, dont know much about HD or Evo. I'd be all for separate leader boards for each bike. but still need to keep over all leader board even if its only for the top 1% since most people cant compete because of ninjas.

You can get Evo on Steam and it includes Trials HD. It's often on sale down to about $6 iirc. You're obviously a Trials fan, so you should definitely do that. You can also get Trials 2 Second Edition on Steam, though the physics on that... take some getting used to.

[LIONDEN1]

I have HD and Evo now, just not a fan, When Fusion is your first taste of Trials, the older bikes are totally funky, lol. Evo isnt bad actually, but Rising came out as i started playing it. I'm sure i'll get to them one of these days. Just having too much fun on Rising, especially the Editor.

[TyrianMollusk]

Score can be computed from the other stored information.

You're suggesting they live-sort/index on a value calculated from encoded data (on top of suggesting adding another index to sort by bikes). Such suggestions are not even remotely realistic.

Besides, that's irrelevant here

Not being able to change leaderboard parameters is pretty relevant to changing leaderboard parameters.

Again, if total storage available is an issue, easily fixed, only the top 100 get a replay, boom, solved.

You've thrown out playing against friend ghosts for basically the entire playerbase as well as having a chance to call hacking on a run outside the top 100.