gamedev is difficult

So... im simulating timers inside my ecs. They actually have four states. Started, Running, Completed and aborted. I wanna react to them inside my ecs. I have found two possible ways to achieve this. I could either create 4 different "Marker" components and simply mark my timer entity with those. Or i could create a "State" component that contains an enum of those four states.

I would like to choose the first variant due to performance reasons ( should be quicker, because we only iterate over what we want and dont need to check ). But currently those components stay forever... such a marker should actually only stay one single frame ( Started, Completed, Aborted ). How could we achieve this ? Whats the proper way ?

@Tyyppi_77 So some sort of generic solution ?

Alright thanks ^^

hi

how are ya?

waiting on class to start, fiddling around with a card game I wrote with Python in, like, 30 minutes

I'm screwing around with linker scripts with barely any understanding of what I'm doing.

lol

@genaray somewhat late to the party, but:

Why not store the remaining time in a component on entities that should have sth happening after that time? If necessary also store a ptr to whatever function should be executed on the entity after time. Then have a system that simply decreases the timer by the delta between executions, calls the function at reaching <= 0, and removes the component

not really arbitray though?

I mean the proposal of storing a function ptr is mainly to reduce the amount of systems you need running; could also have different systems for each functionality, or have a switch reacting to arbitrary markers

I'll agree with Tyyppi_77 here: when you have some code that is stored in the system, some code that is stored in a component, some code that is injected into a function pointer, some code that is in "special entities", it becomes hard to figure out where to look for the code, and where one should put new code.

Now that is another matter though. In practice the code should reside where other code resides. The function pointer pointing to that code is set on Componentcreation then

yes. Maybe. I don't have code in my components ;)

But the component could store a lambda that is declared in a system. Or preferably a non-lamda. But that would apply to the ECS I wrote. Others may have approaches that make as much sense as the way I did mine.

If one can come up with simple rules as to where to put the code, and they make sense, then I guess it's possible to have code at multiple places.

@Vaillancourt that's basically another name for a function ptr

But yeah that is the gist, and reason to sometimes strictly apply patterns. I got a simple rule for where gamecode goes: Systems

so i start looking there if sth don't work

Yep, that's what I did too.

I suppose it depends on how it's done.

System-execution in a very naive implementation here

If you go fancy you can have another system for execution down the pipeline and buffer the callbacks

also: tesselation is awesome

@Tyyppi_77 Do you not know when the function pointer is executed?

@Tyyppi_77 what does this have to do with files..?

Absolutely, sounds smelly

I agree. On the flip-side, it allows for "greater flexibility".

Probably, but I am trying to point out that I do not see what seems so obvious to you, and attempt to show that I am willing to work to understand

Well yeah, but that is going to happen anyway due to delayed execution due to using a timer?

The point is that you can no longer follow the code step by step because the code simply puts a function pointer somewhere and that's the end of it. Also on the other side you see a function pointer being called but not which one. This makes understanding the code rather complicated.

Event-based systems tend to have this problem of it being impossible to follow what code is actually being executed, even with a debugger.

And if you put a breakpoint in the function, you still don't have a clue who created it and when it was assigned.

I would like to beg to differ, but I got a good decade of experience working with systems that are heavily decoupled and event-based (i.e. webservers, etc.) so I am biased

I'm not saying event-based systems are bad, I'm saying they have the problem of making following the program flow rather difficult. With your experience you should know that.

I def agree on the 'who created it and when' part, videogames tend to be notoriously nondeterministic due to all manner of randoms being applied everywhere

@nwp yeah no i got that, sorry if that didn't show from my writing :)

Randomness when you roll damage is not the same as randomness when you don't know which functions will be called when.

that sounds pretty scary

It's hard to follow indeed. Usually you'd assign ids to events and such so you can track them through logging; if you fear runtime impacts you could use #debug macros or similar

But then there's technically no need to use a proper eventsystem for that usecase(?) (just tell me to stop if I'm overdoing it, I really enjoy the subject right now so I will go deeper and deeper)

That was the point, yes. Not using a callback would be better because it would avoid the issue of the code being difficult to follow.

I guess depending on your use of callbacks that is true. But callbacks don't automatically make your code harder to follow, no.

@dot_Sp0T We had some interesting Q&A a while back about a similar wrapping scheme... gamedev.stackexchange.com/q/162223/39518

I've got a few answers about neat tricks you can use with geodesic grids too, to work in familiar 2D coordinates even if the tiles themselves wrap around in 3D. gamedev.stackexchange.com/a/108683/39518

oooh looks nice

gonna look into it later i think

rn I'm doing some camera work first to make sure these transforms all work

Another answer about flattening a geodesic sphere into rectangular charts: gamedev.stackexchange.com/a/141032/39518