How do i get flexible/easily interchangeable code?
So any programming techniques or tips to create such a free system?The ultimate implementation of a free system is a general purpose programming language (although it has boundaries too).
Anything you add reduces the free-ness. On the other hand, if the addition is in the direction you want to go anyway, the additional restriction is not a problem, it saves work.
This is the exchange you get with a game engine. It pushes you in a framework, and in return you get a lot of functionality pre-implemented. As long as you have no desire to step outside the limitations set by the engine, the benefits are usually bigger than the costs, ie it's a good trade.
"Design" in that respect is deciding what restrictions are acceptable in the context of the problem that you're solving.
The result of this is that you cannot have "flexible/easily interchangable code" in the general sense. Rather than trying to capture the world, it's often better to chop of some of the world that is not likely to be of interest, and design for that smaller world, increasing the added value that you can provide.
I would add that in terms of code design, it's often a bad idea when you try to be as flexible as possible. The motivation can be good, be the result is often bad - leading to overly complex design; and while you tried to "design" for change" you end up with something harder to refactor. Which is well illustrated here:
I would add that in terms of code design, it's often a bad idea when you try to be as flexible as possible.
I wish I could give you more likes. I've seen this problem strike more than a few times professionally. Just about every big major "flexible" system I've ever seen ends up _also_ needing to be rewritten every time a new feature comes online, only it takes 5x longer to rewrite than the simpler "inflexible" code would have been.
That said, I think the OP is asking a more reasonable question closer to: http://gamedev.stackexchange.com/questions/29982/whats-a-way-to-implement-a-flexible-buff-debuff-system
First my apologies for the late answer I needed some time to consider things carefully. Indeed when I talk about flexibility I mean "modular" and "easy to modify", the system does not have to provide all functionality on its own but its has to move out of the way when something new or different is added.
The buff system or any event system are a good example of things i have considered in the past and indeed difficulties tend to run rampant, so much I even looked up a specialized programming language at some point(I think it had something to do with autonomous agents, i honestly forgot).
It is exactly to avoid to overly complex solutions I am asking for tips,
P.S.: I think I was searching for code that instead of listening for parameters with if checks could activate or deactivate based on triggermessages at that point.
Also Sean considering the link you gave me I still need to read everything carefully, right now I lack some concentration to take in the information completely
The simplest approach to get flexibility is to not prepare for any future stuff.
Instead, make it work for the needs you have today, and nothing more.
When you have a new addition (and not earlier), refactor the code to make it all fit nicely again, and add the required new functionality, and nothing more.
You can repeat this as often as needed.
It always gives you the simplest possible code (there is no code you can remove while keeping all functionality), and it executes quickest, as it doesn't take non-existing cases into account.
The rationele behind this approach is that you cannot predict the future. Either it doesn't happen (you changed your mind about some feature), or it doesn't happen as you planned (at the time of actually adding it, new ideas and approaches exist that you didn't take into account during the design).
This also means you don't have to consider future additions while designing, which makes the design a lot simpler and faster.
The most flexible systems I've seen in use started out in their first generation as being non-flexible.
After the first project worked out, a second generation was created which reused many pieces and threw out many pieces, fixing problems along the way.
After the second project worked out, a third generation was created which reused many pieces and threw out fewer pieces, fixing problems along the way.
After six or seven generations, the tool has a great set of options, a library of reusable pieces, and a great amount of flexibility.
You cannot start seven generations out, you need to start with the first. Get something out that is non-flexible yet gets the job done.
