Jump to content

StepanK

Former Developer
  • Content Count

    4
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1 Neutral

About StepanK

  • Rank
    BI Developer
  1. StepanK

    AT/ M136 / RPG7

    (pardon me, I really can't read whole thread, so I just picked one thing I saw:) we have just one reload time for all the rpgs. We decided now to make it play longer, we'll see how it'd work. as for the rest - the bad thing is that once anim plays, it can't be interrupted in some cases at all. Ex.: if we didn't create extra states, the ugliest effect would be - imagine that one would start to reload and if shot, he'd first finish that move and then would finally die (we avoid these things in most cases for long anims, but it costs some work, as always nothing for free). Sorry, no chance to store state of the reload anim to stack and revert to that state and continue on. This also means that getin/out cars looks as you see because player would have to finish whole complicated realistic (eg into tank) getin move prior he'd again be able to decide what to do next. If someone started shooting at him, there'd be no chance to interrupt the move at all, which'd be bad. Actually, these things tend to create so complex space of states that it tends to result in completely physically+behaviorally simulated characters - and just one engine I am aware of can handle this, Endorphine from Natural motion, LucasArts licensed that. But - it is so CPU expensive that we hardly could go that way as you'd probably want army simulation rather than one perfectly simulated character and the rest of the world dead because of CPU overload (again, sorry I couldn't read whole thread so I probably missed some interesting opinions) Regards, Stepan
  2. StepanK

    AT/ M136 / RPG7

    just to let you know why reloading looks as it does: we designed it as you see after some internal discussion a while ago: 1/ though real RPGs are typically just for one use (mentioned above), we, because of the engine configuration and abilities _do_ allow reloading. Actual rpgs often are prepared for fire quite complicated way, which would mean long complex move specific to each RPG type. And they are normally stored in backpacks. Too complicated for actual gameplay, we worry. 2/ reloading speed: because the reloading is unrealistic at all (because of above), it is hard to estimate how it should look like. Yes, as AI fires RPG quite fast now, group of AT specialists ambushing tanks can really be very deadly.. 3/ It is uneasy to decide what helps the gameplay and what is too much arcade like: * None of you actually would be happy reloading for 20 secs without chance to move or go prone at all, I'd expect. * on the other hand some people advise arcade like things - e.g. throwing grenades in full sprint, but in reality that might be one of last stupid things one could do - grenades ARE deadly explosives and nothing more funny than to stumble at that moment with others around you. And from practical point of view - imagine animation designer: what to do, if you are reloading and suddenly player decides to go prone - in reality reloading would somehow continue prone, but for game, it is impossible at all to continue as that'd be different move and if one allows to go prone at any moment, then it might result in virtually infinite variations of the moves.. Perhaps we could give up in that case and return RPG rocket back to man's ammo stock and let RPG empty or so.. what'd be better? 10 people = 10 different opinions, you know. often there are things that look straigthforward, but once one thinks of consequencecs, they may find it would have some bad impacts elsewhere, it is about compromises. Regards, Stepan
  3. StepanK

    Motion Sickness ?

    Oh, right, this is also a change. It was a decision to do it like this to avoid problems in other moments that might be more visible - it'd distort transitions erected>kneel, rearming and so on.
  4. StepanK

    Motion Sickness ?

    Hello, in Arma, we changed the behavior of external camera, everything else should behave much like it did, probably. External camera trajectory is smoothed, that is quite stable camera moves above terrain and man shakes in front of that when running etc. instead of ext camera hardlocked to man causing all the scene except of player's upper body shaking. Stepan
×