Game mode idea

You have suggestions or want to give feedback to the game or the forum? Post it here!
Post Reply
User avatar
Dr Gains
Posts: 85
Joined: Tue Dec 08, 2015 5:43 pm
Location: Canada

Game mode idea

Post by Dr Gains » Thu Aug 04, 2016 5:41 pm

What if you made a mode where you would have to collect a bunch of gems, coins, etc as fast as you can instead of getting cps. I think it would be fun since it would open up tons of possibilties on routes for the fastest time, especially if the maps non-linear.

Also:
Can you possibly include a full game run, All of the normal single player maps, no medal/time ending until the last map is finished. Unless you are thinking of adding more maps after beta v1. But I supose that you can keep the times seperated from ladder points and remove times upon map updates. Just think it would be another neat thing to add. :)

Also:
The wallclimb bug I dont believe was fixed, still seems like you need to either press jump or press respawn in order to get the max climb height.

Also:
On the map Playground theres a fast shortcut where you run to the green block right of the start. Its easy and can save 3s or so. Id just turn the block blue.
Get involved in speedrunning Celaria and compete against friends and others at
https://www.speedrun.com/Celaria
Full Map List
https://docs.google.com/spreadsheets/d/ ... fUJIZ4WITU
Last Update: Tuesday June 20, 2017.

User avatar
Lewa
Site Admin
Posts: 157
Joined: Sun Nov 15, 2015 1:24 am

Re: Game mode idea

Post by Lewa » Fri Aug 05, 2016 7:21 pm

What if you made a mode where you would have to collect a bunch of gems, coins, etc as fast as you can instead of getting cps. I think it would be fun since it would open up tons of possibilties on routes for the fastest time, especially if the maps non-linear.
I once had something like that in mind, but i wasn't sure if this gamemode would be "different enough" compared to the current time-trial gamemode. (It was at the time where i still was debating with myself if the checkpoints should have a fixed activation order or not.)

But it is good that you brought this idea up. (With the knowledge i have now i can clearly see that this gamemode would allow for different playstyles if the maps are designed in the right way.) Yes, i'll add this to the game.
Also:
Can you possibly include a full game run, All of the normal single player maps, no medal/time ending until the last map is finished. Unless you are thinking of adding more maps after beta v1. But I supose that you can keep the times seperated from ladder points and remove times upon map updates. Just think it would be another neat thing to add. :)
Yes i'll add such an option. :) I'm a huge fan of speedruns (AGDQ anyone?) and allowing players to attempt a speedrun of all the maps with as little hassle as possible was on my todo list from the beginning. Great to see that others also feel that way. :)
(I'll probably add a seperate highscore for this "full game run".)
Also:
The wallclimb bug I dont believe was fixed, still seems like you need to either press jump or press respawn in order to get the max climb height.
It isn't fixed yet.

I attempted to make the wallrun more consistent on the current beta builds of the game (which i have locally on my PC) but i wasn't really successfull with that.
The problem is that jumping in Celaria is a really complex process. (The whole movement is like a really specialized physics engine.)
The current wallrun works like this:

If you jump, the player starts moving upwards depending on the current jumping-force. (So at the frame where you jump you have the maximum force.) After that gravity kicks in and you start losing force/strength.
Now, if you jump and you get in contact with a wall a few frames later you start wallrunning. BUT! You already lost a bit of force due to gravity.

So at the moment where you start the wallrun you don't have the maximum possible "jumping force" anymore.
During the wallrun you still loose energy but it happens slower as the wallrun essencially reduces the gravity.

So the inconsistency comes from the the "airtime" between your jump (from the floor) and the initial contact with a wall where you start the wallrun. The smaller the "airtime" is, the higher you get up the wall (as you lost less force during the airtime due to gravity.)

What i did to "negate" this effect is to reset the velocity to it's maximum value if the player starts a wallrun and his jumping force (after loosing a bit due to gravity during the airtime) is still above a certain threshold. (So you can essencially have a bit of airtime between the initial jump from the floor and the contact with the wall and still recieve the full maximum upwards momentum back once you start the wallrun.)
The issue is that this essencially makes the wallrun even more inconsistent as it also depends on if you started the wallrun while still being in the allowed "margin of error" with your jumping force. (The problem in the current alpha is that this value is way to low to be effective.)

Under normal circumstances (without the margin of error) the player can climb a total of around 16.6 meters. (With maximum vertical momentum and without the green block effect.) In the open alpha v5 you can go a bit higher (due to the margin of error calculation). So you can climb (at best) around 18.5 meters.


Now as the movement in the game is very hard to predict, it's hard for me to make it consistent. (I need to predict how much force the player has to have if he touches a wall and starts a wallrun, depending on the height distance between his original jump and the initialisation of the wallrun.)
But it's extremely hard to do that. (Because there are so many factors affecting the jumping physics of the game. Distance, vertical speed, green blocks,etc...)



What i ended up doing is to increase the margin of error value even more to allow the players to have a fair bit of airtime (like 1-1.5 seconds) before the wallrun and still recieve the full jumping force back at the start of the wallrun. (Which should make it easier to do frontal wallruns.) But this in turn allows the player to get up even higher (around 21.4 meters in the current beta build).

I don't know if i'll be able to fully fix that. The movement was designed to be fully dynamic and not "static" (which would make it way more predictable/easier to calculate and tweak). The dynamic part of the movement makes it very hard to solve that problem.

Also:
On the map Playground theres a fast shortcut where you run to the green block right of the start. Its easy and can save 3s or so. Id just turn the block blue.
I'll look into that. Thanks for the info.

User avatar
Dr Gains
Posts: 85
Joined: Tue Dec 08, 2015 5:43 pm
Location: Canada

Re: Game mode idea

Post by Dr Gains » Mon Aug 08, 2016 4:24 pm

Lewa wrote: I once had something like that in mind, but i wasn't sure if this gamemode would be "different enough" compared to the current time-trial gamemode. (It was at the time where i still was debating with myself if the checkpoints should have a fixed activation order or not.)

But it is good that you brought this idea up. (With the knowledge i have now i can clearly see that this gamemode would allow for different playstyles if the maps are designed in the right way.) Yes, i'll add this to the game.
Wicked, will you be making it so that you dont need to still reach the red goal?
Lewa wrote:Yes i'll add such an option. :) I'm a huge fan of speedruns (AGDQ anyone?) and allowing players to attempt a speedrun of all the maps with as little hassle as possible was on my todo list from the beginning. Great to see that others also feel that way. :)
(I'll probably add a seperate highscore for this "full game run".)
Awesome, cant wait for this. Im also a pretty big fan of AGDQ, would be cool seeing a segment of Celaria on that hey?
Lewa wrote:It isn't fixed yet.

I attempted to make the wallrun more consistent on the current beta builds of the game (which i have locally on my PC) but i wasn't really successfull with that.
The problem is that jumping in Celaria is a really complex process. (The whole movement is like a really specialized physics engine.)
The current wallrun works like this:

If you jump, the player starts moving upwards depending on the current jumping-force. (So at the frame where you jump you have the maximum force.) After that gravity kicks in and you start losing force/strength.
Now, if you jump and you get in contact with a wall a few frames later you start wallrunning. BUT! You already lost a bit of force due to gravity.

So at the moment where you start the wallrun you don't have the maximum possible "jumping force" anymore.
During the wallrun you still loose energy but it happens slower as the wallrun essencially reduces the gravity.

So the inconsistency comes from the the "airtime" between your jump (from the floor) and the initial contact with a wall where you start the wallrun. The smaller the "airtime" is, the higher you get up the wall (as you lost less force during the airtime due to gravity.)

What i did to "negate" this effect is to reset the velocity to it's maximum value if the player starts a wallrun and his jumping force (after loosing a bit due to gravity during the airtime) is still above a certain threshold. (So you can essencially have a bit of airtime between the initial jump from the floor and the contact with the wall and still recieve the full maximum upwards momentum back once you start the wallrun.)
The issue is that this essencially makes the wallrun even more inconsistent as it also depends on if you started the wallrun while still being in the allowed "margin of error" with your jumping force. (The problem in the current alpha is that this value is way to low to be effective.)

Under normal circumstances (without the margin of error) the player can climb a total of around 16.6 meters. (With maximum vertical momentum and without the green block effect.) In the open alpha v5 you can go a bit higher (due to the margin of error calculation). So you can climb (at best) around 18.5 meters.


Now as the movement in the game is very hard to predict, it's hard for me to make it consistent. (I need to predict how much force the player has to have if he touches a wall and starts a wallrun, depending on the height distance between his original jump and the initialisation of the wallrun.)
But it's extremely hard to do that. (Because there are so many factors affecting the jumping physics of the game. Distance, vertical speed, green blocks,etc...)



What i ended up doing is to increase the margin of error value even more to allow the players to have a fair bit of airtime (like 1-1.5 seconds) before the wallrun and still recieve the full jumping force back at the start of the wallrun. (Which should make it easier to do frontal wallruns.) But this in turn allows the player to get up even higher (around 21.4 meters in the current beta build).

I don't know if i'll be able to fully fix that. The movement was designed to be fully dynamic and not "static" (which would make it way more predictable/easier to calculate and tweak). The dynamic part of the movement makes it very hard to solve that problem.
Shame :/ Atleast its not really a game breaking problem. I noticed when The Baconater did the RiseAndShine playthrough, he had a bit of troubles making the wall climbs for his first attemps after climbing from before.
-----
Id also like to add:

Will you be able to make it so that platinum time sets are based on successful runs inbetween cps. Like reset time to a 'saved' time when you hit respawn. It would make times more of a challenge, and prevent times like on the map TowerOfChoices
Get involved in speedrunning Celaria and compete against friends and others at
https://www.speedrun.com/Celaria
Full Map List
https://docs.google.com/spreadsheets/d/ ... fUJIZ4WITU
Last Update: Tuesday June 20, 2017.

User avatar
Lewa
Site Admin
Posts: 157
Joined: Sun Nov 15, 2015 1:24 am

Re: Game mode idea

Post by Lewa » Mon Aug 08, 2016 8:33 pm

Dr Gains wrote: Wicked, will you be making it so that you dont need to still reach the red goal?
Exactly. Once you collect the last remaining gem, you pretty much "finished" the map. (Otherwise you would limit the amount of possible pathways which the players can undertake. That's what the current time-trial mode is for. :) )
So no red block in this mode.
Dr Gains wrote: Awesome, cant wait for this. Im also a pretty big fan of AGDQ, would be cool seeing a segment of Celaria on that hey?
This would be amazing! The chances of this happening is pretty much 0% at this point (i never expect anything that i do to be successfull so i never get dissapointed XD) but you know, it would be amazing if someone would attempt to do that. (Have to finish the game before that thoug. :P )
Shame :/ Atleast its not really a game breaking problem. I noticed when The Baconater did the RiseAndShine playthrough, he had a bit of troubles making the wall climbs for his first attemps after climbing from before.
Yeah, it's a bit of an issue do to the way i coded the whole physics. If i'll have the time i'll try to fix this a second time, but i can't promise anything.
Otherwise i'll stick to the current "solution" which i mentioned in the previous post.
I can also look into tweaking some of the physics values. (The total height of the wallrun is also determined by your running speed before contact with the wall. I could reduce the influence/dependency of the running speed which affects the wallrun height.)

Dr Gains wrote: Id also like to add:

Will you be able to make it so that platinum time sets are based on successful runs inbetween cps. Like reset time to a 'saved' time when you hit respawn. It would make times more of a challenge, and prevent times like on the map TowerOfChoices
That's an interesting idea. I'll definitely look into that. (I'll add this on my "todo/look into" list)
However i can't say when/how (or if) i'll include that. I have other stuff to work on which has a way higher priority (like server programming/multiplayer/gui enhancements, etc...)

User avatar
Dr Gains
Posts: 85
Joined: Tue Dec 08, 2015 5:43 pm
Location: Canada

Re: Game mode idea

Post by Dr Gains » Mon Aug 08, 2016 10:40 pm

Lewa wrote:This would be amazing! The chances of this happening is pretty much 0% at this point (i never expect anything that i do to be successfull so i never get dissapointed XD) but you know, it would be amazing if someone would attempt to do that. (Have to finish the game before that thoug. :P )
Youre doing a fine job pal. And I can see it on there, theres been indie games before, and they will run damn near anything. :}
Lewa wrote:Yeah, it's a bit of an issue do to the way i coded the whole physics. If i'll have the time i'll try to fix this a second time, but i can't promise anything.
Otherwise i'll stick to the current "solution" which i mentioned in the previous post.
I can also look into tweaking some of the physics values. (The total height of the wallrun is also determined by your running speed before contact with the wall. I could reduce the influence/dependency of the running speed which affects the wallrun height.)
Have you tried something like: OnClimbFinish Alarm[]=room_speed(1 second), if player touching floor{reset OnJump speed like tapping reset does}
Read through your post again. For me, I believe Im getting max 22.25m with reset (after jump or respawn) and max 18.5m without reset (after climb, running and trying to climb again). Also, its far more consistent to start your wallclimb jumping from about 4.5 - 6m away from wall on my current version.
-2m is 1 block without stretching, right? O.o
Lewa wrote:That's an interesting idea. I'll definitely look into that. (I'll add this on my "todo/look into" list)
However i can't say when/how (or if) i'll include that. I have other stuff to work on which has a way higher priority (like server programming/multiplayer/gui enhancements, etc...)
Nice, you could even add ability to change platinum times, if someone tries to enter a lower time forcefully set platinum time to run time. :)
Get involved in speedrunning Celaria and compete against friends and others at
https://www.speedrun.com/Celaria
Full Map List
https://docs.google.com/spreadsheets/d/ ... fUJIZ4WITU
Last Update: Tuesday June 20, 2017.

User avatar
Lewa
Site Admin
Posts: 157
Joined: Sun Nov 15, 2015 1:24 am

Re: Game mode idea

Post by Lewa » Tue Aug 09, 2016 12:59 am

Dr Gains wrote:Have you tried something like: OnClimbFinish Alarm[]=room_speed(1 second), if player touching floor{reset OnJump speed like tapping reset does}
Read through your post again. For me, I believe Im getting max 22.25m with reset (after jump or respawn) and max 18.5m without reset (after climb, running and trying to climb again). Also, its far more consistent to start your wallclimb jumping from about 4.5 - 6m away from wall on my current version.
-2m is 1 block without stretching, right? O.o
I did a fair bit of tests on that matter and there doesn't seem to be any bugs with the maximum reachable height of a wallrun before/after a respawn.
At first i thought this was the case (as i experienced the same thing as you) but after more testing (and a lot of debugging) it doesn't seem to be the case. (At least all physics/jumping related variables seem to be correctly resetet after the player touches the ground.)

Also, the reason why you get the consistency by jumping 4.5-6m meters away from the wall, is probably that the game resets your jumping velocity to the maximum value, as you get in contact with the wall within the internal threshold. (So it basically say "yep, you got the wallrun within the threshold, i just give you your maximum jumping strength back, so that you can climb higher.)

The issue is that in order to achieve 100% consistency, you have to jump and hit the wall at the perfect height with perfect timing.

Example:
Let's say the threshold is 2 meters from the floor on which you are standing.
If you jump and get in contact with the wall while your origin point (your feet) are still below the threshold, the game will give you your maximum possible jumping velocity back so that you can climb 18.5 meters. (from the point of impact.)

So if you get in contact with the wall at exactly 2 meters (the threshold limit) you will climb 2+18.5 = 20.5 meters.
BUT!
If you get in contact with the wall at 1 meter, you will only climb 1+18.5 = 19.5 meters as the game does only give you the boost once you get in contanct with the wall (which happens at 1 meter above the floor.)

If you overshoot and get in contanct with the wall at 2.5 meters, you don't get the boost/value reset. (In this case your wallrun is probably going to be pretty bad as your velocity was already decreased by gravity and this in turn doesn't allow you to climb even the standard 16.5 meters as the height you can climb also depends on your velocity at the point of impact with the wall.)

So yeah, to get 100% consistency you have to jump in a way so that you hit the wall at the exact threshold limit every time. (which is impossible for a human being XD)
The issue here is that the physics system (at first) was designed to be somewhat realistic. (and things like this were somewhat intended. So there isn't really a strict formula on how many meters the player can climb. It all depends on friction values, gravity values, multiplier values which i use for balancing, the current jumping velocity at the point of impact, the running speed, etc... and a complex calculation process which is using all those values determines in the end how many meters the player can climb up on the wall. It's all dynamic and interconnected.)
This is now biting me in the a**.

I'll look into that again though.


Also yes, your determined height is more or less correct. My previous height calculation was reffering to the maximum z-value of the players collission box origin (which is the bottom/the feet of the player.) The collission box has a height of 2.5 meters (while the collission box for grabbing ledges is at around 2 meters), so in the current alpha the maximum possible height is 18.5-18.6 meters.

And yes, 1 block is 2 meters in size.
However: You can't rely on it 100% as the textures are slighty scaled/stretched to fit the surface if the scale/size of the block is an uneven number.
(so a block with a scale of 2 and 3 will still have only 1 gridblock on the surface while a block with the scale 4 will have more gridblocks on the surface.)
You can test that out in the map-editor.
Dr Gains wrote: Nice, you could even add ability to change platinum times, if someone tries to enter a lower time forcefully set platinum time to run time. :)
I'll definitely put that in. (Wanted to do this before, but never got around to implement that.)

User avatar
Dr Gains
Posts: 85
Joined: Tue Dec 08, 2015 5:43 pm
Location: Canada

Re: Game mode idea

Post by Dr Gains » Sat Aug 27, 2016 10:25 pm

Lewa wrote:I did a fair bit of tests on that matter and there doesn't seem to be any bugs with the maximum reachable height of a wallrun before/after a respawn.
At first i thought this was the case (as i experienced the same thing as you) but after more testing (and a lot of debugging) it doesn't seem to be the case. (At least all physics/jumping related variables seem to be correctly resetet after the player touches the ground.)

Also, the reason why you get the consistency by jumping 4.5-6m meters away from the wall, is probably that the game resets your jumping velocity to the maximum value, as you get in contact with the wall within the internal threshold. (So it basically say "yep, you got the wallrun within the threshold, i just give you your maximum jumping strength back, so that you can climb higher.)

The issue is that in order to achieve 100% consistency, you have to jump and hit the wall at the perfect height with perfect timing.

Example:
Let's say the threshold is 2 meters from the floor on which you are standing.
If you jump and get in contact with the wall while your origin point (your feet) are still below the threshold, the game will give you your maximum possible jumping velocity back so that you can climb 18.5 meters. (from the point of impact.)

So if you get in contact with the wall at exactly 2 meters (the threshold limit) you will climb 2+18.5 = 20.5 meters.
BUT!
If you get in contact with the wall at 1 meter, you will only climb 1+18.5 = 19.5 meters as the game does only give you the boost once you get in contanct with the wall (which happens at 1 meter above the floor.)

If you overshoot and get in contanct with the wall at 2.5 meters, you don't get the boost/value reset. (In this case your wallrun is probably going to be pretty bad as your velocity was already decreased by gravity and this in turn doesn't allow you to climb even the standard 16.5 meters as the height you can climb also depends on your velocity at the point of impact with the wall.)

So yeah, to get 100% consistency you have to jump in a way so that you hit the wall at the exact threshold limit every time. (which is impossible for a human being XD)
The issue here is that the physics system (at first) was designed to be somewhat realistic. (and things like this were somewhat intended. So there isn't really a strict formula on how many meters the player can climb. It all depends on friction values, gravity values, multiplier values which i use for balancing, the current jumping velocity at the point of impact, the running speed, etc... and a complex calculation process which is using all those values determines in the end how many meters the player can climb up on the wall. It's all dynamic and interconnected.)
This is now biting me in the a**.

I'll look into that again though.


Also yes, your determined height is more or less correct. My previous height calculation was reffering to the maximum z-value of the players collission box origin (which is the bottom/the feet of the player.) The collission box has a height of 2.5 meters (while the collission box for grabbing ledges is at around 2 meters), so in the current alpha the maximum possible height is 18.5-18.6 meters.
Decided to look way deeper into this. There is definatly something going on with climbing a wall and then trying to climb a 2nd wall. I made a little video to show whats happening: https://youtu.be/yWAcLo0YWDI
I can think of 1 possible solution, but its not really the best. You can have the player do a mini jump (like literally 0.02m) after every wallclimb.
Exported the map if you would like to test this out: https://www.dropbox.com/s/rpt4tvsqjahwx ... .cmap?dl=1

Also:
I seen your tweet yesterday. Are you having like a global leaderboards that relate to lp and a server leader board for game end, that would be way too cool. :D
Get involved in speedrunning Celaria and compete against friends and others at
https://www.speedrun.com/Celaria
Full Map List
https://docs.google.com/spreadsheets/d/ ... fUJIZ4WITU
Last Update: Tuesday June 20, 2017.

User avatar
Lewa
Site Admin
Posts: 157
Joined: Sun Nov 15, 2015 1:24 am

Re: Game mode idea

Post by Lewa » Sun Aug 28, 2016 12:19 am

Dr Gains wrote: Decided to look way deeper into this. There is definatly something going on with climbing a wall and then trying to climb a 2nd wall. I made a little video to show whats happening: https://youtu.be/yWAcLo0YWDI
I can think of 1 possible solution, but its not really the best. You can have the player do a mini jump (like literally 0.02m) after every wallclimb.
Exported the map if you would like to test this out: https://www.dropbox.com/s/rpt4tvsqjahwx ... .cmap?dl=1
At first i have to say: Really nice that you are spending your time with looking into this stuff and actively trying to analyze them and find a potential culprit. I'm really thankfull for that. :)
Second: Your video was really helpfull in that regard. (This issue was visually way more notizeable compared to previously.)
As you mentioned in your video, something isn't correctly correctly resetting itself unless you do a reset by jumping once.

Aaaaaaaand i found the issue. XD (It was a really dumb mistake/oversight on my part.)

Basically, the same logic applies as before: If you start a wallrun you can get a wallrun boost if your jumpingforce is above a certain threshold.
The problem was that there was a flag which was determining if the player was allowed to use the boost or not. (I probably added this to prevent some kind of exploit, but i don't remember exactly what it was.)

If the player jumps and recieves the wallrun boost (by doing a vertikal wallrun), this flag is set to "false" and you can't use the wallrun boost to get up higher on the wall. (Then the exact thing happens as shown in your video.)

What i did was to reset the flag once the player collides with a floor after gravity kicked in. And there was the issue:
If you run up a wall with a wallrun, this flag is set to false. If you pull yourself up a wall you still have geometry under your feet but gravity (downward movement) never kicked in, and so this value wasn't reset.

And with the flag set to false, the player doesn't recieve the wallrun boost.

The only way to reset this value is to jump and collide with the floor by using gravity (you jump and once you start falling you need to collide with the floor which resets the value) or by respawning the player (which forces a reset of all flags).

Don't know how i overlooked this previously... *facepalm*

Now it's fixed. But note that there are still "inconsistencies" in the wallrun height due to the way the wallrun boost happens (the previous explenation of the physics calculation still apply.) You can try this out in the alpha. Reset the flag by jumping and perform a wallrun but try to get in contact with the wall (frontally) at different heights.

I would like to add this fix into the current alpha. But i noticed that there were a few other flags (alongside the boost flag) which weren't properly reset. I "fixed" them too, but i have to test if this fix didn't break something else in the movement system. (And thus i'm a bit carefull with releasing this fix to the public.) We will see. But the next build (be it alpha or beta) is going to have the fix. :)

And again, big thank you for pointing this out. :)
Dr Gains wrote: Also:
I seen your tweet yesterday. Are you having like a global leaderboards that relate to lp and a server leader board for game end, that would be way too cool. :D
Well, the server itself is going to have a seperate leaderboard (unaffected by the global leaderboard).
The current build of the server doesn't store the leaderboards permanently as of right now (once a round ends it will send the leaderboard to all connected clients so that they can see how the ranking for this round was and then clear the leaderboard on the serverside and load a new map.) But I'll look into storing such serversided leaderboard stats permanently. (Shouldn't be that hard to implement... i hope...)

Also i plan on releasing the source code of the game server to the public (once it's done) so that others can play around with it and (potentially) extend it with stuff like this if they feel that such features might be missing. :)

I'm still thinking about potentially using the results of runs in multiplayer mode for the global leaderboard.
Basically the idea would be that if you play on a server and finish a run on it then your results would be sent to the game-server as well as to the global leaderboard for this specific map (Basically exactly the same as in singleplayer). This would ensure that you still get LP for your runs in multiplayer.

But i don't know if that's going to be feasable. Imagine a single server with around 32 Players on it. Everytime one of them finishes a run, his stats get send to the global leaderboards (This includes player information, time and the recorded replay...). And now imagine that there are at least 10 other servers online.... (running a master-server which can cope with such a load can be quite costly...)


I still don't know how much traffic/performance limited i would be on a virtual server.
I'm definitely going to run a global leaderboard server, but i'm not quite sure if uploading complete replays of runs to the server might be a little bit to much in terms of traffic.
Additionally, saving replays on the server also costs storage. A server with 100GB storage is "ok" if you only store the .cmap files alone but if you start storing replays of players your storage space will start to fill up extremely fast.


There are still a few questions unanswered when it comes to this stuff. I'm currently trying to work out passable solutions to those problems.

User avatar
Dr Gains
Posts: 85
Joined: Tue Dec 08, 2015 5:43 pm
Location: Canada

Re: Game mode idea

Post by Dr Gains » Sun Aug 28, 2016 5:50 pm

Lewa wrote:Now it's fixed. But note that there are still "inconsistencies" in the wallrun height due to the way the wallrun boost happens (the previous explenation of the physics calculation still apply.) You can try this out in the alpha. Reset the flag by jumping and perform a wallrun but try to get in contact with the wall (frontally) at different heights.
From what Im seeing, you either have max climb or you dont (difference is pretty noticeable), and I think you get your wallrun boost within a range from 0.01m~7m away from the wall. It looks like you start your max climb as soon as you touch the wall, not when you leave the ground. So jumping 0.01m away from the wall instantly gives you the wallrun boost making you climb around 19.8+/- as a min, while jumping 7m away from the wall gives you that 3-4m vertical head-start then starting your wallrun boost making you climb around 23.3 +/- as a max. The only other thing that you might find inconsistent is when you miss the end of the wallclimb threshold (hitting the wall, then trying to climb), which would treat the climb as a 0km/h wallclimb letting you climb around 17-18m high. It all seems fairly consistent to me.

What I think is happening in the code is: When initiating a wallclimb- If vertical speed is '>= this' wallclimb equals 'this value' value. If vertical speed is '< this' wallclimb equals 'this calculated value'
Lewa wrote:At first i have to say: Really nice that you are spending your time with looking into this stuff and actively trying to analyze them and find a potential culprit. I'm really thankfull for that.
Second: Your video was really helpfull in that regard. (This issue was visually way more notizeable compared to previously.)
As you mentioned in your video, something isn't correctly correctly resetting itself unless you do a reset by jumping once.

And again, big thank you for pointing this out. :)
Ahh no problem man, sometimes get really bored and have nothing better to do :b
Lewa wrote:Well, the server itself is going to have a seperate leaderboard (unaffected by the global leaderboard).
The current build of the server doesn't store the leaderboards permanently as of right now (once a round ends it will send the leaderboard to all connected clients so that they can see how the ranking for this round was and then clear the leaderboard on the serverside and load a new map.) But I'll look into storing such serversided leaderboard stats permanently. (Shouldn't be that hard to implement... i hope...)

Also i plan on releasing the source code of the game server to the public (once it's done) so that others can play around with it and (potentially) extend it with stuff like this if they feel that such features might be missing.

I'm still thinking about potentially using the results of runs in multiplayer mode for the global leaderboard.
Basically the idea would be that if you play on a server and finish a run on it then your results would be sent to the game-server as well as to the global leaderboard for this specific map (Basically exactly the same as in singleplayer). This would ensure that you still get LP for your runs in multiplayer.

But i don't know if that's going to be feasable. Imagine a single server with around 32 Players on it. Everytime one of them finishes a run, his stats get send to the global leaderboards (This includes player information, time and the recorded replay...). And now imagine that there are at least 10 other servers online.... (running a master-server which can cope with such a load can be quite costly...)


I still don't know how much traffic/performance limited i would be on a virtual server.
I'm definitely going to run a global leaderboard server, but i'm not quite sure if uploading complete replays of runs to the server might be a little bit to much in terms of traffic.
Additionally, saving replays on the server also costs storage. A server with 100GB storage is "ok" if you only store the .cmap files alone but if you start storing replays of players your storage space will start to fill up extremely fast.


There are still a few questions unanswered when it comes to this stuff. I'm currently trying to work out passable solutions to those problems.
Wicked! :D
As for replays though, wouldnt you only need to store the top 20.. maybe 30 per map, and just remove the 31st players recording to free up space. That way 100Gb could go a long(er) way (Except on any Very Hard maps with a 2hr replay :b). You could still store times (checkpoint and goal) since it would only take up a matter of bytes per person and per map (for players ranked 31 or more). But Im probably just oblivious to how a server actually handles so much data being uploaded and downloaded at a fast(er) rate. :L

EDIT: I just had a random thought to where you might run into problems. What happens when 2 maps with the same name are added into the leaderboards? Should you have something to just prevent that? Theres already 2 Freecity's in the game.

A bunch of things about the map editor:
I just want to point out that sometimes trying to delete a black doesnt work unless you click Save/Load and it exits out of screen.
Im also not very keen on having Backspace an option for deleting blocks since Ive accidentally deleted a block trying to change a blocks value.
Also can you add a warning, or even an option for a warning when exiting to main menu, Ive lost a good amount of work a few times.
And you cannot set a negative value on blocks, and clicking that value, deleting just the decimals and adding whatever else; just becomes positve after.
Lastly, for times you cant change minutes, and seconds/milliseconds in 1 input. But this isnt the biggest deal.

Also: Wouldnt mind being able to press the restart key while on the medal/complete screen.
Last edited by Dr Gains on Thu Sep 08, 2016 4:54 pm, edited 3 times in total.
Get involved in speedrunning Celaria and compete against friends and others at
https://www.speedrun.com/Celaria
Full Map List
https://docs.google.com/spreadsheets/d/ ... fUJIZ4WITU
Last Update: Tuesday June 20, 2017.

User avatar
The Hard Croc
Posts: 38
Joined: Sun Apr 17, 2016 3:33 am

Re: Game mode idea

Post by The Hard Croc » Fri Sep 02, 2016 11:39 pm

Oh my lord a combination of all the maps together is my greatest nightmare but also sounds like a ton of fun hahaha. Super stoked to see this in the future
Check out my channel "The Hard Croc" for awesome Celaria content and more!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest