Day/Night Cycle

[frozen plinth]

I agree but the choice of the default day/night stay really important bc a lot of people will stick to the default setting

[magic lava]

I think having one night/day cycle is really important

Because ideas like season events can all by done in one day if the cycles are really short

And vise versa... it'll take really long to get seasonal events if the cycle is really long

[acoustic sapphire]

**IT'S RAINING COINS <:coin:541384484201693185>**

Type CATCH (once) to collect some coins! The reward depends on how many players join
Coins per player: 300 ~ 25,950

if you don't want these events to spawn with any message -> "rpg config"

Players: Oasis

:moneybag: Everyone got 988 coins

Find more commands with help

if you don't want these events to spawn with any message -> "rpg config"

[grim gate]

Yeahh i agree with this, seasonal events wouldn't line up for everyone which may be difficult if frog eventually wants to implement interactions between friends

[magic lava]

Yea I was going to mention friends but didn't know if it was a 100% feature

[somber folio]

Multiple day/night cycles would probably be really hard to not only implement (saving/loading) but also manage with all the different events n such

so instead ill try my best to polish and implement a day and night cycle that fits everyones needs :)

and yes I was planning on adding friends/some kind of online thing if I can!

[light flume]

@uneven scarab

idk if this is what ur looking for but maybe

[uneven scarab]

yea it is ty!!

[barren thorn]

I think that this might work:

Ok so you could have a variable for each froggy world that would represent the time from when the world was first created. When you create the world at first you can set the time. There could be a like slider and a 'safe' area shown in the gui and you would be warned if you tried to go out that area although you would still be allowed to.

Then in the world you can count the days, but the days would be based on the variable set at the start, and for every day there would be like a day time just like there is in minecraft were it counts from 0 to 24000 ticks each day. The 'day ticks' would be the same ammount no matter what you set the day cycle to but they would be longer or shorter inbetween them.

When you do it like that you can still count days and the ammount of time passed in the day no matter how high or low you set the total day time at the start, but this should allow for longer daycycles.

I don't know wether or not I have missed anything but I think this could work.

[somber folio]

Ahh I see

I'll definitely look into it in the future, but for now I'd like to first just get the basic gamplay down :)

[barren thorn]

Okie

[mental flume]

the variable would have to be normalized between 0.1 and 2 or something so you can multiply the time by that

currentDayTick += 1 * settings.timeMultiplier

[barren thorn]

No, i think you understood it wrong. There arent more day ticks even tho you up the time its just the time between those ticks being incremented that changes.

[mental flume]

settings.tickMapsTo = 100 // ms

🤔

"they would be longer or shorter inbetween them" means "the day ticks would be longer or shorter in between days"?

i think this would require two kinds of ticks if there are 24000 ticks per day, if tick means this: https://gaming.stackexchange.com/a/210195

so the frame tick would go up 60/s normally, but the day tick would be lerp(0, 24000, (frameTick * settings.timeMultiplier % 24000) / 24000) if settings.timeMultiplier is between 0 and 2

[barren thorn]

What i meant is that you have a tick counter could be frame but fixed is prolly better. Then everytime that ‘ticks’ you would add to a counter. When this secondary counter reaches a certain number (this is the number that changes based on what you set the day length to) it would increment the amount of time that had passed in that day. This time would always remain the same but the amount of time it takes to reach that amount will change.

[mental flume]

well, there is Engine.get_process_frames() for an absolute tick count

then that would have to assume the game is always running at 60fps

how many times the current frame tick has "overflowed" the setting:

overflow_count = floor(Engine.get_process_frames() / settings.framesInDay)

example — if 48000 frames have passed, and there are 24000 frames in a day, it's "overflowed" 2 times, which means 2 days have passed

[barren thorn]

Well this could work but what if the game is only run at somewhere between 50 and 60 fps? This would make it not smooth even tho it is most likely unnoticablr. Isnt there like a physics tick or something? (Sorry i havent used godot)

[barren thorn]

let DAY_TICK = 60; //This is the default value and this it what should be changed when the day sh ould be longer or shorter
let current_tick = 0; //This will reset once it reaches the DAY_TICK value
let current_day_tick = 0; //This is the amount of time passed in a day

//This should run every tick (We are assuming it runs at 60/ticks a second right now)
fn tick() {
if current_tick == DAY_TICK {
current_day_tick += 1;
current_tick = 0;
}
else {
current_tick += 1;
}
}

This would make it so that if you set the DAY_TICK to 30 the day would be twice as fast and if you set it to 120 it would be twice as slow.

[mental flume]

get_process_frames() is independent of the render loop, from the process itself
there is get_physics_frames()

[mental flume]

this is good

but can be reduced:

fn tick() {
    current_tick += 1;
    current_day_tick = floor(current_tick / DAY_TICK);
}

if current_tick is 778595, and DAY_TICK is 60, current_tick / DAY_TICK = 12,976.583, floor()ed to 12,976
then to run it every frame (_physics_process is framerate-independent)

func _physics_process(_delta):
  current_tick += 1;
  current_day_tick = floor(current_tick / DAY_TICK);