shift your issues into data

whether you place constants in a text file, then read them in, or place them in a .cpp file and compile them makes little difference with respect to the fact that you have to define new constants every time. with almost every new select target routine, some new condition has been added to the "system". they are not just a different subset of existing conditions. they are typically a subset of existing conditions, plus one new type of condition. so somewhere in the code it has to go ok, if enum 1 is set, check condition 1, and so on. So if you add a new check every time, you end up modding the system every time. saves you a bit on the cut and paste of the code that doesn't change, but you then have to go and set all those flags. probably easier with a "system" built upfront. the reason why i didn't is because as i said, going into this i had no idea i'd end up with over a dozen different types of AI behavior. and thus lots of different "select a valid target" routines. If the AI wasn't done, and i anticipated adding more, i'd likely re-design. but maybe not, the code doesn't really lack clarity yet. it just has some redundancy. Until i have to mod it in a major way, the price i pay is a few milisec longer for build and a few more bytes to the exe file. I'd guess half a day to re-factor it. i could spend that time taking a shot at the rock toss mini-game using the combat engine. it didn't quite make the cut-off line, due to complexity. At the moment i'm working on SIMSpace, while I wait for the new PC to arrive so I can finish Caveman.

In the end it boils down to the fact that i don't refactor cause i don't have to. sure the code could be better, but its good enough for now. re-factoring now gets me nothing right now, only maybe something in the future. and as the code is done, that's unlikely. and the next version - if there is one - would most likely use something like unreal engine. Its simply too much work for one person to build both a graphics engine and a reasonable sized game in any reasonable amount of time. So the code is basically one shot disposable, and is unlikely to ever be touched again. If it is touched again in major way, then i'll consider re-factoring. but at each step, there's the how long to refactor everything to the new system, vs simply adding the capability to the existing system. As the exiting system grows in capabilities, the time to refactor can become significant vs the time to add a new capability. for example, the cut and paste took maybe an huor at most from the time i fired up the compiler, til it was done and tested and moved from the todo to the done list. refactoring everything would be half a day, maybe a day. so sometimes not-refactoring can make you more productive, but with less elegant code. like i said, its not for everyone. i can get away with it case i'm a solo gamedev and have been coding for decades, so i have a pretty good idea when things need cleaning up and when they're good enough. obviously, this not a safe-for-work policy. So don't try this at work kids! <g>.

Honest question, Norm: why do you bother asking for advice on these forums if all you ever do is argue that it doesn't apply to you?

Honest question, Norm: why do you bother asking for advice on these forums if all you ever do is argue that it doesn't apply to you?

Looking for silver bullets i guess.

In this case, it seems nothing will change the fact that as new condition checks are added to the system, the system will need to be modded.

The same way that an ECS can only use components that have been pre-defiinded in the engine, A data driven or enum driven version of "select target" could only use conditions that had already been implemented in the system. Since every new "select target" routine pretty much called for some new type of condition check, I would have been modding the system all the time.

The nature of the checks makes an all-in-one system not necessarily an obvious choice.

Each routine checks (iterates though) 1 to 3+ lists - band members, animals (including NPCs), campfires, etc..

If i mash all of them into a single routine, i get two loops with a ton of branches in them to handle the dozen or so different cases.

the other option is a dozen or so dedicated routines with no branching in the loops. faster execution, more readable code, but you have a lot of routines.

Once I got to 3 or 4 select target routines I should have thought about changing the design. but do you go for two big ugly loops with tons of branching? and adding a new branch every time? or do you make it separate iterations for each enumerated or data driven check? not very efficient... a dozen dedicated loops may be the best compromise. its entirely possible I split it into separate routines early on due to excessive spaghetti due to branching in a single select_target routine.

In this case, it seems nothing will change the fact that as new condition checks are added to the system, the system will need to be modded.

I find your terminology really hard to follow, so I'm not sure what you're talking about here. Of course if you want to modify the system you have to modify the system; that's just common sense, not something you can "silver bullet" your way out of.

So I'm guessing there's more to this than "I want to add stuff to my game without touching the computer" ;-)



You talk at length about having too many branches and too complicated logic and all these downsides. But it seems to me like you don't really address the suggestion itself, i.e. put your relationships in a data table and don't hard code them!

Take every entity type in the world and assign it to a faction. Each faction has a numerical ID. Now you can express the relationships between any two entities (assuming they follow faction rules) in an O(1) lookup from a NxN matrix where N is your number of factions.


How does this turn into nested loops and branches and complicated lookups? If you want to add a faction, just fill in a new row and column in your data matrix. If you're really bad about dynamic allocation, increase the size of the matrix's static array dimensions in code. DONE.