Messages

46

Suggestions / Re: a thought from a c++ software developper

« on: September 18, 2013, 02:16:34 am »

Very well I will contact warboy as it goes to the battlescape development. I will start looking for usable improvements once I will get visual assist x installed for my visual studio ( I will have to get other version than express, as it doesn't support any add-ins).
I have an inquiry tough: do you have all the externall dlls, libs and include files gathered somewhere in one place, or should I download them on my own?

Regards,
djemon_lda

47

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 17, 2013, 03:37:46 am »

I would say that this:

Code: [Select]

Troop* bestReactionist = nullptr;
while( ( bestReactionist = GetBestReactionScoreGuy(spotters, walker) != walker)
{
    FireReactionSnap(bestReactionist, walker);
}

is what I'd prefer. Clear, simple and short. just feed it with the right data, removing guys that can't shoot anymore. btw, as far as I remember this was the exact behaviour: as I remember I had situations when some guys with sick reactions ( around 100 ) they did shot twice in a row after a single action of the enemy. The same was done by ethereal when a low reaction soldier has taken a long run, and when making one of his last steps, an ethereal beheld him.

It isn't the most realistic way of course, but as far as I've learnt so far, openXcom aims make the same functionality as the original game.

48

Suggestions / Re: a thought from a c++ software developper

« on: September 17, 2013, 03:29:33 am »

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

49

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 17, 2013, 01:37:32 am »

@Warboy, or any other openXcom dev:

I've seen the code for the reaction fire (code dwonloaded not longer than 3 days ago), and I think, that this isn't exactly what it was like in the original, and perhaps what is written here isn't what the author had in mind.

Code: [Select]

while (true)
{
if (!tryReactionSnap(reactor, unit))
break;
reactor = getReactor(spotters, unit);
result = true;
if (reactor == unit)
break;
}

The reaciton fire routines finish in two cases:
1) the best "reactor" was unable to fire.
2) all reactors have worse reflexes than the spotted unit.

Only The second case is corresponding to the original implementation. The whole round of checking reaction fire is finished if and only if the spotted unit has the greatest reaction score.
In your algorithm it's either this, or a situation where the shooter fails to shoot the reaction snap, which is fully dependant on what this condition gets evaluated to ( true or false )

if (action.weapon && action.weapon->getAmmoItem() && action.weapon->getAmmoItem()->getAmmoQuantity() && unit->getTimeUnits() >= action.TU)

(the first check btw isn't necessarry and just creates noise - you are using the action.weapon pointer 4 statemnes earlier)

Not knowing your internal architecture with details I cannot say when would the getAmmoItem() return a null pointer, but the rest of the condition tells us, that this returns false when a unit has not enough time units for its action OR the currently considered reactionist is out of ammo.

This in turn means, that if I have sick reactions ( like for example Point Man from FEAR series ), and have exactly one time unit less than I need to fire a time consuming fire action, then none of my buddies will fire.

This makes many situations where good reacionists are stomped by that break invoked because a better reaction guy was unable to perform a shot for whatever reason ( other than problems with line of fire, because this is not checked in the tryReactionSnap as far as I've seen ).

I hope this will help you improve the code and functionality of the product.

Regards,
djemon_lda

50

Suggestions / Re: Continue playing after the Council tries to shut you down

« on: September 17, 2013, 12:01:52 am »

I personally think this would be just too easy... having governments leaving you is a sign of your failure after all. when all countries are lost, then you basically already lost the whole planet ( except for up to 8 of your bases ). I haven't been playing ufo:enemy unknown for quite a time, and after that long pause I had when I've found the openXcom, I've said to myself that I don't want to get destroyed, and picked experienced ( 2/5 ) and in my game it's september 99' and for a few months in a row I scored at least 8k points, while the last 3 months were almost 14k. I have 3 bases with avengers and 5 spotting bases ( no activity except for building a hyper wave decoder and fusion defences there ) which basically gives full coverage of the planet.

so stop complaining - it's time to man up

51

Suggestions / Re: Anti-suggestions

« on: September 16, 2013, 02:31:01 am »

There is already nearly 8k lines of code (and 15k if you count blank lines and comments).  This number can be greatly reduced by removing most of such abstractions.

I am just afraid I would not be able to modify code when you finish implementing bigger part of it.

well 8k lines in a project is basically nothing. I have no picture on how many lines of code have appeared since the last update of this topic, but having proper abstractions - which in turn do not require full knowledge of the whole product right in the begining - reduce the amount of lines of code instead of bloating the code.
Scripting is just another way to reduce the amount of code and boost the speed of production. It is going to be harsh, but I'm afraid that you still need to learn A LOT before you can participate in making some software...

52

Suggestions / a thought from a c++ software developper

« on: September 16, 2013, 02:04:08 am »

Hello forum users, and openXcom developpers. I have been very enthusiastic once I have read about the openXcom project by some wierd coincidence. UFO:Enemy Unknown was undeniably the game of my life. It was extremelly playable, even more than later encountered dune2:battle for arrakis, or starcraft:broodwar years after. It was the very same thing this time - nothing changed. I have installed it somewhere around midnight, and stopped playing just before 6A.M. having full tech and a lot of talented psionics, basically only waiting for the right moment to invade cydonia...

With the same dose of fanatism I have helplessly fallen under the might of the thought to help your development team with maintaining the product, fixing its problems and delivering new, configurable functionality. All that until I've taken a look on your codebase.

I personally think your project could use some help of a system architect. I won't name what I've seen until you decide whether you want some help on the game's architecture or not, but some simple refactoring would facilitate further development and made the code a lot more readible and flexible, giving you productivity and a greater scope of changes you can incorporate to satisfy your audience, alongside with less errors introduced.

It's your call - I will check this forum from time to time for an answer from the dev.

Regards,