How about a Sling? Incorporates the plentiful ammo aspect of rocks as well as can utilize a unique firing method, such as holding the button down to start swinging the sling, which gains power, then release to throw. You could even add in aim disruption as you hold the button for longer to increase the difficulty of power shots. Make it weak with extra damage to the head and an additional bonus when undetected by the enemy. Difficult to use effectively, but infinite ammo and stealthy (unless you miss, of course).
I like this idea, I've certainly not seen a sling used as a weapon in this capacity. I remember having sling weapons in rogue-likes but those were purely probability based.
if you put logic and data into one component the logic inside the component can only use the data which is also inside the component. That means you have to implement a message system to send messages between components or something similar. And there will be a lot of messages.
But what if you make the components self sustained, so they don't have to access data from other components? This can of course mean moving of more data.
Or do you mean the order of updates to data in components depends to data in other components? You'd have to order the updates anyway, either in logic in system, or by building ordered update of components so no stale data is accessed.
Also, surely a system only access the components in it's own domain, and passes messages to other systems?
The way I see it, you don't want components to communicate to each others, becouse that would be logistic nightmare. And you don't want to put all component's logic in one system, becouse you'd have one system per component type (or one massive system per multiple component types). Maybe some kind of subsystem, recurse the general idea.
That's actually a good argument. I can already think back to times when the message passing overhead inside an object has gotten to silly levels.
I've been thinking about this Problem, too, but I believe I've found a Way to solve ist: The Strategy Pattern. Yes, ist is a tiny violation of the Paradigm, but I don't see any disadvantages. There would be two ways to go about ist:
1. Have an AI Component that has the Fields it needs (Aggro List, ...) and additionally,it has a function pointer to the ai subroutine it uses. 2. Have an "ExtendedFunctionality" component that has a vector of std::functions that are to be executed each frame. One being the AI routine..
These functions take their entity as parameter (imagine it being the this pointer), and then do their magic without virtual functions and inheritance
I'm aware this breaks the "No Logic in Components" rule, but it's the most sensible thing i can think of. Maybe someone else knows better tho...
I'm not sure where this rule of "no logic in components" comes from because it makes no sense to me. Logic needs to go somewhere, so if it doesn't go in components, where does it go? As yet, I've not seen a good argument for behaviours and components being separate, other than vague claims that separation is good therefore separate logic and data is good.