I sense danger.
As professional software developer, my perception of it: I worshipped the developers of the ancient age, when I was young and innocent and I still worship them (Especially the people behind Bullfrog, who had been magicians as team).
But I would not trust them to develop a spacecraft software system. First of all, the amount of bugs even in the old and simple games had been huge compared to modern standards in gaming - and modern games are of the same size as the software complex of a spacecraft (which involves space and ground software) - but with about 20 times more bugs than acceptable in spaceflight.
And then, modern games are very little programming today and a huge lot of game design, graphics, audio, you name it. You don't need to develop solutions for technical problems anymore in most cases, only people who develop graphics engines have to look into concepts how to turn theory into reality. And still, you can't use them for the spacecraft - wrong workflow and likely the wrong personality. People who develop huge distributed information systems (which MMORPGS actually are, though at a lower quality standard) are more suited, especially in the financial industry. People who are used to the fact that a single execution of a bug can cause hundreds of millions dollar in damages.
Spacecraft are less about finding new exciting solutions, than about extremely boring, formal, but also very reliable development. Its all about quality. Performance comes second.
If I would set up a team for making spacecraft software, I would maybe only hire one former game developer, if he can think outside the box - but such a person must not be game developer at all. It could even be somebody who has never programmed in his life. And rather invest into QA, software architects and mathematicians, together with a foundation of experienced, reliable developers. Its mostly standard tasks, so better get people who deliver such standard tasks perfectly every day and make reliable time and cost estimates, instead of looking at creative, but buggy and unmanaged solutions.
Also look at the people who developed the Gemini Math Flow... those are wizards. Look at the algorithms, the complex flow charts... and then remember that such a function has to be implemented with maximal 256memory locations for instructions and two registers, and you only have 16 different instructions to do this. The software has not done anything revolutionary. Bigger computers had been calculating such stuff easily twice per second. But finding out which instructions in which order are really needed and which could be left away, how you can form different entry points to make a function cover different tasks... that's cool and elegant.