I mean like, there are lots of factors to take account when calculating target velocity to reach a position
we might calculate some velocity on which will lead us to a terrain that has a high friction value or the wind might just change or something else that will screw up our calculated velocity
@Henri This is not velocity calculation, it's path finding
user92578
10:02 AM
Seriously do users not see their questions after posting?
user92578
How do people not go "Oh, whoops, my post is a total mess because I can't manage to format my code, better fix that so people can focus on answering me instead of fixing my formatting"???
Cross-post on Reddit and Quora and you probably get your answer quickly.
Generate a few accounts in case you get banned.
user92578
IMO we need a mechanism to prevent users who put no effort into their questions from posting before completing some kind of gamified formatting tutorial
I feel like there's not a lot of appreciation that this site represents a community of collaborating human beings. Folks often treat it like a code vending machine, without considering the perspective of the users who need to read their question to help them, or learn from the exchange in the future.
So i need a way to listen for value changes of components inside my ecs... is double buffering the only way to realize this ? If so i have a little problem, in c/c++ i could simply copy the struct into new memory... thats a bit harder in java :/
I'd love to chat through ways we might be able to turn that around and encourage more community-mindedness/community-building around our site. ☺
@genaray Setters are a common way to catch changes - is that applicable in your situation? It's generally cheaper to mark the change when the change is made, than to try to compare all your data after the fact to find the bits that changed (which are often the minority)
Observer design pattern (or any pattern for that matter) doesn't care if you use Java, C++ or a Turing machine made out of rocks (the API for the latter suck though).
To follow up on patterns, though, I recommend starting with game design patterns. It's more approachable than the hallowed Gang of Four classics (which aren't bad, but aren't tuned for game dev & a bit more dry).
@Pikalek Best site ever... i love the prototype-pattern :) Type-Object is also very usefull... not sure if you can implement that one into a ecs nicely. Service-Locator is my main source for decoupling :p
ECS kind of is a form of the Type Object pattern. Instead of defining different classes for all your entity types, you form them out of data as different combinations of components and component parameters. ;)
But on a more micro level, there's nothing to stop, say, a Tile component in an ECS tile map from referencing a TileType object that stores shared terrain information used by all Tiles of one kind.
Similarly, my Weapon component could hold a reference to a WeaponParams object that defines the rate of fire, bullet spread, etc. attributes shared by all similar weapons, rather than duplicating that data in every instance of the component (getting into the flyweight pattern here)
Yes, used carefully. Applied indiscriminately, eventually you can effectively remove the advantages of your ECS. Which underscores: patterns shouldn't be used as straight jackets or silver bullets.
As you say though, there's nothing stopping one from applying a change to a pattern when it serves the greater good of the project.
That makes sense ^^ thats something i could do once i have a usecase for this... currently theres only the "basic" stuff like... position, movement e.g... :D
So far I've only implemented achievements once, for a jam game. Other times I've been lucky enough to only have to design them and set up their data, not do all the hard plumbing. ;)
I think on the Nintendo DS, you could have game features that would depend on something like "at most" one year from now. It had to be "hackable" by changing the console clock.
