This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
When you're talking about engine development at different studios, do you let them naturally make the decisions on what direction they want to take once you've presented them with information? Or is it more like you have a personal vision on how tools and tech should be deployed or developed?
JM: We could certainly spend some time to talk about the technology strategy and the way I work. As you know, I'm working as a team; I'm working on different fronts. I'm working obviously on structural enhancements; working on basically how we grow from an HR perspective of the group, how we work around the talent, how we attract people, etcetera. And the working conditions that are extremely important for teams to perform in good conditions.
I'm fixed also heavily on knowledge management -- that, for me, is a fundamental aspect of technology development within the group. There are two other parts, that are basically all the development support aspects and basically the technology innovation bits.
And when it comes down to technology, really, over the years I think have attended a few conferences as a speaker, and I've been also talking pretty often about live editing and realtime editing.
I think workflow is one of the most fundamental things to really enable content creators to deploy their vision and also implement their vision and tweak it and tune it and have a really fast iteration cycle through the development of the game, which is fundamental for pre-production, but fundamental for production as well -- and the last bit of the tuning and the tweaking that is involved before getting to beta.
So that's obviously an area where I really define pillars and I really define what I'm looking forward to get from the tools pipeline and workflow.
And then there are fundamental breaks of technology that are really the ones that will enable live editing. So, from the graphics perspective, you need to have an approach that is compatible with realtime editing, so it really needs a lot of things from a lighting perspective; from dealing with materials and things like that.
But outside this, I think one of the big areas I'm really focusing is especially online; I've been also talking a lot in conferences about the long tail, the importance of social and community features, and we have some technology development that is really pushing these aspects and focusing on developing that a lot more, with the importance of services and social features and the connection with the community in games. I think that this an area we really have to invest in.
And there are still also aspects that we need to fundamentally cover related to graphics and animation and AI. I think there is huge room for improvement there, and it's clearly one area that we're focusing on.
It seems like AI hasn't gone as far this generation in becoming as advanced as I think, maybe, I anticipated at the beginning of this generation.
JM: Yeah, I think there's a huge problem with AI. It comes from many different aspects. First of all, it's just very difficult fundamentally. even if you remove the technology aspects, to define an AI that could be extremely convincing in gaming, that's something that is a lot more complex than working around material or lighting technology or just physics engine.
AI has something that is tremendously difficult first of all just from a design perspective. Designing a good AI, a convincing AI, is something that is totally not straightforward. I think that also, on top of that, the hardware that we have today is totally not adapted to making great AI.
I think also that the software that we have, the type of C++ language -- having to potentially move away from it and designing scripting languages -- that's all complex to just get together. As soon as you're trying to work on a scripting language, you have to, obviously, write your own language -- so, potentially, your own compiler, your own debugger, or your own interpreter -- basically, there's a lot of work that comes on top of designing a scripting language.
So not only is it difficult to design an AI, but on top of that, I think that the hardware is not suited to AI. And second, I think that the type of programming languages and software that we have are not also suited to that. So I expect that slow progress will be made on AI, and I'm really looking forward to the next wave of platforms, and to look at what type of hardware will be available by then, and how we could take advantage of it from an AI perspective. I hope it will be a lot more suited to AI than the current one.
You were talking about scripting -- and you weren't necessarily talking about this in this exact context -- but it made me think about some of the debate there is over whether gameplay designers should have to script or whether their tools should present them a place where they don't really have to work at that level. What do you think about that issue?
JM: I think it's interesting to provide a flexible approach -- so, to basically to provide a system where designers or level designers can to a certain extent do a lot of the easy stuff. Then, when it comes down to the complex stuff... When things start to be "complex", and you're having to deal with your AI, you're starting to touch a lot of different things with your AI...
Programmers have a very good understanding of data, how to articulate, how to play with the data, and how to architecture code around that. So when you are doing simple stuff, I think it's very important to give access to designers and level designers. When it gets more complex, I think that, because of the programmer profile, they become suddenly very important to help make it work.
One way I tend to look at it also -- and what we tend to do -- is that when the programmer is not really needed in the process, then we tend to use the programmer in the post-process; like when AIs have been written down, and basically we have programmers who are looking at how things have been architected and reviewing that to either make things perform better or to make things more flexible to reuse moving forward.