Dragon Age News Thread

I meant no sarcasm either, and think that my replies were as straightforward as I could possibly make them. Maybe I am not good at explaining myself to someone who may not be a fellow coder. I honestly think that the logic as I presented it is the correct one, and would be extremely surprised if that wasn't the case. I may not be a game dev, but I have done coding for two decades now.

OH MY GOODNESS. It's not just me.

I'm not a programmer... But my husband has a master's degree in mathematics but assures be that this Grand Knowledge (I have math phobia) does not make him qualified to be an accountant. Coding /=/ logic. Someone else's job is the logic, I'm supposing? I'm in Ultrasound and people think I have this knowledge about all the medications on the market. HA, no. That's a nurse's and Doc's job to memorize all those pills and dole them out. Point is, we're a specialized society.

Anybody who claims to understand math (I seriously began writing 'magic' at first) is a secret Reptilian. There, I said it 

Tea, come on now. The only answers he could have given to "Are you familiar with maing games in Frostbite?" are "Yes, I am." or "No I am not.", with the likely answer being the "No" b/c he probably doesn't work for EA. And what would your response have been? Guessing something along the lines of "Well, then you don't know the exact problems they're facing."?  (IE, exactly what you do in the second paragraph of this quote.) There was no point in you asking the question otherwise. You weren't being sarcastic, but you were being persnickety.

I think Gileadan has a point. He should tweet it to the devs. Politely. Maybe ask "Couldn't you just set the death/dying condition to less than 1 to avoid that?" or something. They may have a good counterpoint. They may say "That's exactly what we ended up doing. Good catch!". They may just not know and he'd be giving them a good idea for the future. Bioware is wizards at many things, but there's always room for improvement.

I'm learning some programming currently and logic is kinda part of the deal. If you want to reach an end goal with your code, you need to work out the steps to get there. Unless you meant something else by "logic" and I'm not understanding?

Am I famous now?

Fernando Melo‏ DiscoBabaloo
Great thread on some behind the scenes dev woes...
[Mark Darrah's Dying / Dead posts]

Justin Edmond‏ @iamsparkkie
This is why I always loved that the web/mobile team switched over to a declarative style programming. It solves a lot of those issues.


Jesse Houston‏ @gtez
We added an interactive resurrection state to player death.... What were we thinking.

Mike Laidlaw @mike_Laidlaw
YOU ARE MADNESS

I wish there was a time lapse before the dissolve, perhaps a couple of minutes? It's a neat visual that plays into the whole Breach thing, but it feels gamey.

BUT!!! I much prefer the DAI method over exploding bloody chunks from DA2, let me make that very clear!!

On the one hand, having bodies remain adds to realism, which I appreciate. On the other hand, I don't need to actually see a bunch of dead bodies lying around. I think Skyrim solves this in a decent manner, actually. There is cleanup code in the game. Bodies do disappear if you haven't visited an area for a while. I don't mean just reloading a cell, but days or weeks of in-game time. But it can be buggy, yes, so I see the concern there.

I imagine hrungr dodging conversation like shells in the trenches to bring us our tweets

Give them some credit. You can't base a judgment like that just on a short tweet. We don't know what else was going on. Large software systems are often more complex than any one person can comprehend.

For the record, I've never worked on Frostbite directly -- though, apropos of nothing, I do know some DICE developers that work on the engine, through a rather roundabout software coding connection -- and I'm not a AAA game developer. But I am a software developer who has worked with AAA game developers, and I do work with large, complex pieces of software with line counts that meet and exceed the one posted for DAI (or was it ME3?), so I can make some reasonable guesses at why dying/death transitions are hard.

Agreed. And given that the whole tweet starts with "state transitions", this sounds like a classic FSM problem, in a multithreaded environment. There's absolutely nothing "rookie" about that.

FSM stands for Finite State Machine and is a common pattern used in software and computation. Check out the wikipedia article for more details.

Plus, there could be any of number of additional complications going on that make this problem very difficult:

• Native engine code owning part of the FSM, while a game script virtual machine owns other parts. Critical information might be in the wrong part of the system at a critical time. Briefly, there are usually two separate types of code that can run in a game: native and scripting. For reasons that would take too long to explain accurately here, just accept on trust that sharing information between the two systems, native and scripting, is hard and error-prone.
• Multithreaded -- this is just intrinsically hard, period. It's analogous to the difference between listening to just one person talking on the phone and 15 people all taking at once in a voice conference.
• Frame rate -- the game simulation has a finite amount of time to update all necessary state variables, the time between one frame and the next. 60 fps means just 17 milliseconds to visit every object in the visible 3D scene and give each enough compute time to update. Given that combat tends to be the heaviest compute load for a simulator, it's no surprise that some lower priority state transitions might get starved for compute time. Would you rather have every death transition computed accurately, or every weapon/ranged attack you triggered 3 milliseconds ago hit the intended target?
• Notice that Darrah mentioned "atomic" and "sub-frame", meaning, changes that you thought should change all in one go -- without being interrupted by anything else -- and quick enough to happen in less than one frame update, respectively. If neither of those are true, insuring that the update happens correctly every time is exponentially more difficult, because now you have to know about every possible interrupt, and you have to save enough information between frames to know which your updates are still in progress.
  

The last bullet is worth some additional elaboration.

"Sub-frame" vs. multi-frame. Ideally, between one frame and the next, you want to start over from scratch. It makes bookkeeping simpler, because you don't have to remember anything. Just start from the beginning of the frame update as if everything in the simulation is brand new. The more exceptions to that "clean slate" rule there are, the more complex things get, and the more time the CPU has to spend figuring out what needs to be remembered and when to forget it.

"Knowing about interrupts." This one should be easy for anyone to understand. The more people working independently on the same project, the more coordination there has to be. And since, in writing code, any one line of code could have a profound effect on every other line of code, it's possible for someone to introduce an interrupt that has an impact on an FSM that was written by someone else, maybe days, weeks or even months before. It could be rock solid and thoroughly tested, and then up-ended by a one-line change someone made in a seemingly unrelated piece of code, like a memory manager or, likely, someone trying to make the framerate go faster as a performance optimization.

So, you ask, why not just insure that all changes are atomic -- that is, can't be interrupted -- and avoid the whole problem? Well, because making everything atomic makes everything run slooooooowweeeeeeer. And you know how gamers love their 60 fps. So even if the dying/dead state transition may be relatively easy to comprehend, making it performant could be very complex indeed.

Not really. If you have total freedom to choose all of the technology you build a system with, sure, building declarative from the ground up can solve state transition problems easily. Whether that system will perform well, have a deep pool of field-trained talent to hire for, and be easy to maintain, is a different story. Besides, it's rare to be able to control the entire technology stack. You either have legacy code to deal with or licensed code. The latter applies to Bioware. We know Bioware licenses Frostbite, and Frostbite is an imperatively programmed engine, not declarative.

It's like saying that, when I was in France, speaking French solved a lot of problems, therefore speaking French everywhere, including on the International Space Station (Frostbite), should work great -- nevermind that all the control panels are in English or Russian.

I think it depends on a person. Too much caffeine makes my temples pounding and certainly not in a mood for sleep - so I stick to tea.

But that whole 'Solas dislikes caffeine because it makes it difficult to enter the Fade' also means that Solas should dislike chocolate