Hmm, I've implemented fighting in a rather silly way. Hence, I could use some advice from those who've written these kinds of games before.
Basically, when 1 Captain/Army attacks another Captain/Army, a function is called from the attacker's state which compares the sizes of the armies and then assigns each entity their target entity and then changes their State to Attack and all is well until one is defeated and then the entity asks their Captain who to go for next (if he/she is still alive, if they ain't, go home and make some tea...).
This was working quite nicely, until one army (A) attacked another (B) whilst it was already in combat with another army (C). After Army (B) defeated Army (C), Army (B) wandered off into the sunset with Army (A) walking along behind them, oblivious to the fact they were being poked in the back with pointy sticks, oblivious to their comrades shouting "ooh, my spleen" before collapsing face down in the daisies.
So... this simple Attack/Defend system doesn't work too well. (and, I seem to recall this happened in the original Powermonger as well... as it was a rare occurance in reality.)
I had an idea to maybe create a new Singleton class called "BattleMatrix" which contains ordered pairs of IDs (Defender ID, Attacker ID) and through which every entity in the game knows who is coming after it and who is still on it's "hit list" after other distractions (like pathfinding etc.).
Is this a good route to go down (before I end up writing masses of redundant code), or am I missing some obvious game logic somewhere?
In other news, I've been plowing my way through the Scott Meyer series of books (Effective C++, More Effective C++, Effective STL) whilst learning French and Russian at the same time, so brain may explode like that chess player. (don't worry, it turned out to be a hoax, but was a fantastic urban myth for a while)
Good to see you're still working on this.
ReplyDeletePerhaps if a unit gets attacked by another unit from a team that it isn't in combat with, it should alert the general and allow the general to make the decision as to when and how to switch attackers?
Hey, good to hear from you!
ReplyDeleteIn the end, I decided to just add a "bool bFighting" to the first inheritance class that's involved with fighting.
This way, whenever an entity in an Attack state, they first check to see if the target IsFighting(), if not, send them a message that they are being attacked and should defend. This way, they can have an opportunity to react (and even call the Captain / Settlement for help if he's close enough).
I'm beginning to think Settlements should have the same powers as Captains, to an extend. i.e., if a Captain with a small army strays too close to a large settlement, the settlement should attack.
I'm on hols for the whole of December, so hopefully I'll be able to plow through a ton of this code.
Alternatively, I guess I could give each entity a "list<Entity*> target" where the front is the main target and you can just append more targets. Once the main target is dealt with, it pops it off the list and checks if the list is empty. For each entity, check the distance/threat and pop them off if they are dead or irrelevant.
ReplyDeleteI guess as most of the lists will frequently be empty and accessed relatively rarely (in relation to game loop cycles) it shouldn't affect efficiency much.
hi nick its mr wares here, sorry lost touch. been trying to get in contact for years but had no luck. email me on wares996@gmail.com
ReplyDelete