I was in the middle of responding to xracer, so I will just divide the replay into two.
@xracer:
Hello, and thank you for a warm welcoming word. I prefer to wait for the comments of the development team. It is fully in their hands to decide whether they wish my influence on their codebase or not. All in all - it is their piece of work, and a lot of their effort.
Regards,
djemon_lda
@SupSuper:
I'm afraid you've misunderstood what I've had in mind. I didn't mean to insult you or any other developer, and as a part of that I didn't want to start off with lists of what I deem to be a problem without anyone from the dev to actually show interest in such a talk. How rude would I be then? I have, tough, made an exception from that rule, because I have found a reason in the code, for what some people were complaining ( and which also bugged me a bit ) - reaction fire, yet I've only explained the problem in code, without proposing any solutions - after all, exception or not, I still didn't have any approval from your side - and believe me I really respect the code of other people and I am not fiery tempered as it goes to estimating overall programming skill of a team of programmers based on a project they've developped - I do understand that the current state of the project is a creation that is evolutionary in nature - you can only build up on what you've already have.
I've had in mind an image of many changes in the development team during the lifetime of this project just by taking a look into the code. Keep in mind, that nowhere have I judged anyone, and didn't name the codebase with the epithets you've suggested - all I've stated is that in my opinion it could use some help of an architect, which means nothing more, that I could propose some improvements, that are - as you stated relating to all code - debatable and either can be seen as helpful or as being yet another problem.
I know the problem of "long term temporary solutions" and I have faced them many times in the projects I have been working on. The mature state of the product is a big virtue, but it still isn't 'ready' or 'done' - depending which naming convention is closer to you. For example it crashed when a battleship has flown into a base with no soldiers inside with a message box about not supporting RTTI if I recall correctly. How effective would fixing that be with the current codebase, team and familiarity with code? BUT I also know that no product can survive without continuous refactoring and claryfying it's internal language. The better the domains are defined, the better are the classes responsibilities defined, and the lower the coupling is, the easier it is to avoid/track/fix bugs, and the easier and faster it is to implement new functionality. Pardon me if I am repeating something widely known, but I wish to present my view, and nothing more.
What I'd like to propose is far from breaking the thing apart and trying to put it back in different order. What I think would boost your productivity is to grab a little code here, a little code there, and make a functionality out of it. For example giant sections of if/else/switches could easily by handled by clarifying responsibilities, which would not only make the code a lot easier to read, but also to extend and test and you also wouldn't need enums flying left and right. It would be a lot easier to introduce different AI for different alien races and civillians on terror missions - even differentiating aliens by their ranks. If, on the other hand, we will consider the use of the enum BattleActionType then we can actually facilitate the code, to make it - from if/else/swiched things - to a simple one-liner that takes into account the responsability of an action type. Having actions like shots Auto/Aimed/Snap that determine how many projectiles are fired, what are the moddifiers to the accurracy, time units cost and so on, you could just use those objects instead. Giving more responsibility to BattleUnit you wouldn't need to use those a->b->c->d calls to determine if an action can be performed in terms of time units ( a CanPerform(Action& ?) ), the same goes with things like GetReactionScore() etc.
And again - it is up to the team to consider if this would help you, and if you need /or not/ my assistance in any dimension and in the specific way. I might just propose changes, I might participate in development, or I just might alert if something in the code looks like a bug. Whatever suits you best.
Decide if you need such help - and again don't treat this like "dicking around" - I'm simply not a native speaker and it might be necessary to take it into accound while reading.
Kind regards,
djemon_lda
