|
|
Post by GodCreator on Jul 19, 2014 20:05:34 GMT 1
So, I had a game that had the round cube for highest altitude, but, it won't give it to the right person at the game. It just randomly picks someone to win. So, I hope this gets fixed Thanks
Also, Not sure if this will effect the game mode, but on the world I have a huge wall that blocks people from fall off. The wall is higher then the Hill people climb to win the game. Could that effect it?
Also, one more tid bit I want to add as my own opinion, could you guys add a feature on how high you are where the speed shows up when falling? But, perhaps only show it when this game mode is active? Thanks
|
|
|
|
Post by GodCreator on Jul 19, 2014 20:20:07 GMT 1
I also want to add a bug with the Timer, if the timer runs out it won't tell you who won unless a person made the objective. For an example: I had a Kill limit of 30. And I had a 5 min timer. The highest kills was 7 in 5 mins. But, the Timer ran out and no one won. I think the person with the highest kills should of won
|
|
|
|
Post by Jatsu on Jul 19, 2014 22:32:12 GMT 1
The game doesn't use the current height in the winning condition calculation. It uses the highest or lowest height the player reached in the entire game round.
It looks to be intentional, but in my opinion flawed. If for example a creator used the "lowest height" as the winning condition, then a player simply has to fall off the world to win the game.
|
|
|
|
Post by Daniel Everland on Jul 19, 2014 23:39:20 GMT 1
Jatsu is correct, this is exactly how it works. Skinke and I were also confused during playtesting, but I never really favored any of the directions. Say you're doing a parkour game where the goal is to reach the top. If I almost make it to the top and make a mistake, whereas the rest of the players in the project are no where near me, shouldn't I win the game? I suppose you could do it so Reach Highest Altitude checks for the highest ever altitude, whereas lowest use the current lowest, although then you run into the issue of it being conflicting and thus confusing. What are you guys thoughts and opinions? I'd love to hear them  |
|
|
|
Post by GodCreator on Jul 20, 2014 0:02:02 GMT 1
Hmm, still seems iffy to me. Just be better overall if there was a bottom (lowest block or model) and the highest block/model be the top. And it goes by there. And perhaps 1 block=3 feet and it tells you your hieght where the speed should be. Then, I would be happy However, the Kill Limit and Oculus Limit works fine. The only things that seem out of touch is the Lowest and Highest altitude games and the Timer. So, the round cube in general I think needs more editing before release on the EU and the BR servers. (my thoughts) |
|
|
|
Post by Daniel Everland on Jul 20, 2014 0:31:13 GMT 1
What exactly is it about the Round Cube that you don't like? I assume it's all subjective, correct? I'd love to hear and in-depth explanation |
|
|
|
Post by GodCreator on Jul 20, 2014 15:41:25 GMT 1
What exactly is it about the Round Cube that you don't like? I assume it's all subjective, correct? I'd love to hear and in-depth explanation just perhaps a rebuild how it works. instead of it going from how high that one person has gone, i mean it can be unfair that way by having that person spawn up higher then the other players. thats bout it nothing more. |
|
|
|
Post by Daniel Everland on Jul 20, 2014 15:48:21 GMT 1
So you'd like the difference between where people spawn and where they're at when the round ends?
|
|
|
|
Post by GodCreator on Jul 20, 2014 21:25:23 GMT 1
Yes
|
|
|
|
Post by De Lírios on Jul 20, 2014 22:11:59 GMT 1
But the King of the Hill idea isn't about how far you are from the spawn. It's about how higher you can reach and I'm pretty sure that everyone understands it. I think that it shouldn't be modified, works well.
|
|
|
|
Post by Jatsu on Jul 20, 2014 23:17:14 GMT 1
There might be a technical flaw regarding the Round Cube, but it's not game breaking. While the increment interval for the time of the round is constant at 20 seconds a tick, the minimum and maximum time values aren't multiples of each other. This means that you can set the time to inconsistent results depending on if you move the slider bar from the left or from the right. To be more specific, starting from the left at 30.0 seconds, only times of #.10, #.30, and #.50 are available. And from the right at 60.0 minutes, only times of #.00, #.20, and #.40 are available.
At its worst, it's merely only confusing. But on a positive note, it does coincidentally allow modification in 10 second intervals. If a fix is deemed necessary, a logical one would be to set the increment interval to 15 seconds a tick to ensure the minimum and maximum time values are multiples of each other. It would also be beneficial to have available times represented in quarter minutes (#.00, #.15, #.30, #.45) since time is often split into quarters when mentioned in conversation, thus being more easily recognized as valid round times.
Edit:
Subjectively speaking, I'm indifferent about the winning condition update.
On one hand, the winning condition update brings a lot more gameplay to the table than what was previously offered. This alone is good news and good for Kogama. In effect, it allows creators to have more creative freedom in making a game compared to only being able to design a level.
On the other hand, the conditions of the Round Cube can be confusing and thus flawed. This means that creators must design their levels around this system lest it be exploited, which is good in a pragmatic sense of realistic game development but poor in terms of intuition for game design.
Nonetheless, the winning condition update was just released. I'm very grateful for it and thank the devs for their good work, but it's one of my hopes that it will be expanded upon in the future. There are variants of winning conditions that can still be added.
|
|
