Develop

How did the project come about? Had there been any cooperation or dialogue between the studios involved before you embarked on this project?

Darkworks started discussions with the original group of Kylotonn, White Birds and Wizarbox alongside specialised middleware companies Bionatics (terrain middleware) and Spir Ops (AI). Soon after that Load Inc, an Xbox Live Arcade studio, and graphics middleware company Atonce Technologies also agreed to join our group.  All of the studios knew each other before, through Cap Digital but also through professional relationships, but had not worked together.

There were studios that we approached that didn’t want to join – either they didn’t believe in groupware, or didn’t want to divert resources to a project with no immediate business return or, more simply, had no interest in sharing technology – all of which is understandable and we respect their businesses.

What’s the real idea behind the shared technology vision? Why do you think it is so important?

Our vision was - and still is - that securing engine independence is critical from a business and game performance point of view. Building an Xbox 360 and PS3 toolchain is already very risky for a studio to undertake on its own, and when we project forwards to PlayStation 4 the risk is even greater. So our bet was to start a collaborative approach on this generation so we will be ready to face next cycle challenges. We really are thinking that far ahead – it’s a highly ambitious and long-term project.


You've mentioned in the past that you're setting up a dedicated office with 40 engineers – have those engineers come from your studios or have they been hired for this purpose?

It’s a mix of engineers coming from the studios and engineers hired specifically for this project. The technical management is overseen by the technical directors of the five studios. The result is that the team is able to accept new ideas and methodologies while having an in-depth understanding of the studios’ needs.

Admittedly this may be looking far into the future, but once the technology is developed what is your plan for the team? Will they all stay to continue to evolve the tech and to provide support?

Yes, we’d like to keep this team and the technology centre organised as a mutual middleware team. It is really a long-term strategy to put in place such organisation, methodology, tools, licence agreements and support.

How do you make sure you design middleware that isn't too genre- or game-specific while also making sure it isn't too general or too low-level?

The sweet spot is in the middle; the design of the Play All middleware is as open as possible because it has to address all kind of games and a large range of platforms: PC, PS3, Xbox 360, PSP, PS2, Wii & DS.

The project is cut into five sub-projects: the data manager, the unified core engine, the production toolchain, the platform managers and the quality assurance & support. The only specific elements are the platform managers. All other developments are "general case" oriented.

For instance, the production toolchain includes a complete stand-alone editor that is open to users via a system of plug-ins. Developed plug-ins will cover all common needs: an entity editor, material editor, animation finite state machine, three-dimensional sound editing, real-time cinematic editor, and more.

In addition, to test the Play All engine and toolchain, three demonstrators (or prototypes) will be developed by the studios  – a first-person shooter, an action game and an adventure game.


Is the project equally steered by all five companies? How do you solve disagreements – and have you had any yet?

This project is actually atypical in that there is not one technical director but five. There’s a clear technical decision process – a weekly technical committee is held with the five technical directors, where all technical subjects are discussed: organization of the code base, collaborative tools, philosophy of the architecture of the core-engine, sharing out of tasks, etc. At the end of each technical committee, an action plan sums up decisions.

Of course, lots of subjects are not so easy to fix. And that’s a good thing! It proves that the technical directors’ visions exist and need to be discussed and re-oriented on a common objective.

This process has been in place for more than a year, during which time they already agreed a common game engine definition and a common coding standard. We also have a twice monthly Steering Committee with the studio managers, where we present the current state of the project. The committee is responsible for all major decisions like staffing and priorities for the milestones.

But in case of major disagreement we have created a consortium agreement document that rules how to take various decisions during the project’s life (failing partners, IP issues). It is simply based on a voting system relying on weight of each of the partners – but we haven’t needed to use this yet.

Would you be open to expanding the range of who uses this technology in the future - going from Paris-only to, say, all of France or even Europe?

France is our natural boot camp, but to build a game engine and a community of users we need to open Play All to developers in Europe and the rest of the world.

Would you be interested in licensing the tech to developers not directly involved with the Play All project?

Definitely, yes, but the first step is to make it work within five studios. That’s the first real test bed.

We are creating an advisory board to help us set up the right business model. We are looking for key people within the industry who can bring a broad vision of the business. We are developers who have gone through the RenderWare story, so we know the need to come up with an innovative and secure model for studios. We understand how studios feel trapped when they decide to opt for a middleware solution. Our mission is to solve that frustration. And having been in the industry for 10 years we feel the need for more open standards.


If tech is being developed by a studio, in most cases it's going to be used only inside that studio. But with five companies involved, there's five times the users - how do you make sure that all those people can understand and use the technology to full effect?

That’s one of the key goals of the project – it’s a game engine supported by a larger base of programmers and teams. So if a key programmer leaves a team then studios aren’t stuck. Or, should a studio collapse, the team can continue because the tools and the knowledge are backed up in a mutual organisation. Think of all the technology lost when studios dismantle – Play All is our technical safe deposit.

To achieve this we are organised with online documentation, code samples and a knowledge database. We are dedicating a QA team solely to that task.


There's are several colleges involved in the Play All project at present -  what is their involvement? Do they aim to use the final engine for teaching?

Their involvement is mainly the presence of PhD students whose research works are closely related to game technology, such as procedural audio, motion capture or network security.  They also contribute through the delivery of software components related to their research field for the Play All platform.

An important goal of Play All is to make developers more open minded to academic works, so the colleges do aim to use the final engine for teaching.  Additionally, CNAM/ENJMIN plans to use Play All for their student graduation projects and CNAM/CEDRIC will use Play All as their main game research platform.