BioWare is the developer of triple A role-playing game franchises such as the Mass Effect series and the Dragon Age series. Both series play similarly in terms of their RPG elements, and share many gameplay features. While at MIGS, I attended a session held by Blake Grant from BioWare. The session was titled Convergence for Success. The title was vague and I had no clue what it would be about, but I went anyways.
The session began with an explanation of how the Mass Effect and Dragon Age series shared many features, and highlighted a few like the dialogue wheel and real-time cut-scenes and whatnot. The speaker then revealed - at least to me this was a revelation - that the games were built on two different engines. Mass Effect was built on the Unreal Engine, while Dragon Age was built on BioWare's own Eclipse Engine. So while the two game shared many features, the work was basically done twice when a lot of it could have been done once had they developed both games on one engine.
Now once development had started on both franchises, it would have been difficult for either team to switch to a new engine and redo all the previous work they may have done in developing a framework around their respective engines. It would have also taken time to sift through all After the development of Mass Effect 3, the company decided to plan for a way to share the work between BioWare RPG games to reduce development costs and development time by moving to EA's Frostbite Engine.
However, moving to Frostbite alone still presented the same problem to both the Mass Effect and Dragon Age teams; they still have to add new features to their respective games, and seeing that they are being developed at the same time, this means that work would have to be done twice. The next step for BioWare was to create their own version of the Frostbite engine named BioWare Frostbite. The BioWare Frostbite Engine would contain all the shared features that both development teams would require.
The next step for BioWare was getting all BioWare development teams (Mass Effect, Dragon Age, and a third new team) to communicate with each other to determine which features would be shared, and in turn added to the BioWare Frostbite Engine. Shared features could range from something very genre specifc, such as the previously mentioned dialogue wheel, to things like artificial intelligence behaviours and even shaders.
The communication is the hardest part to manage for BioWare but the process of convergence and sharing the work has proven to be extremely successful in the early stages. The first game to go into production was Dragon Age:Inquisition BioWare's first next-gen title. Out of 141 man-months worth of work, approxiamtely 60-70 of the work is being used in both the next Mass Effect title, and BioWare's new IP. The process of convergence in my opinion has been successful at BioWare; the Dragon Age team has cut-down the development times of both the next Mass Effect and their new IP by sharing the work.
Other EA studios are also moving to Frostbite, however whether or not they are implementing convergence is another story. I could definitely see this process being implemented in many large studios, not just EA. It makes me wonder if games like Assassin's Creed, Watch Dogs and even Prince of Persia would benefit from a development process like this.
I find the process of convergence is simply the next logical step in the development of game engines. Convergence introduces a third layer in the process of developing a game engine. As opposed to having a general purpose engine, then a game specific layer, we have a general purpose engine layer, a more game genre specific engine layer, and then the game specific layer.
Saturday, November 16, 2013
Thursday, November 14, 2013
Designing an Engine with Live Operations in Mind
This week I went to MIGS and went to a talk that touched on the subject of games as live operations. A live operation or live-ops, refers to games that have already been released and the game is now being treated as a service. The idea is that you release the most viable version of your product, or put another way your 'base' product first. Then whenever you want to add a feature, you do a quick and dirty implementation, test it with your customer base, take the feedback from the tests and either add support for it, improve it and test again, or chuck it out the window. The focus of the talk was actually about how to use metrics and player feedback to change your game design, and also focused on community management in regards to live-ops.
For this blog, I would like to focus on how I might go about actually designing an engine with live-ops in mind.
When it comes to live-ops the development team has to be flexible and open to change. This is no different when it comes to the game engine itself. As I mentioned before the initial product that is released is relatively lightweight. It usually only includes core game features. Once the game is released the team starts collecting data, analyzes it and then based on the analysis new feature requests or changes are added to current or near-future plans. Even without metrics being collected from players, the team itself may want to add or test new features,
This means that the engine has to be built in such a way that designers can implement and test features quickly. In other words, the engine has to be modular. This can be achieved through a scripting engine, and implementing all game features using script. This would effectively allow designers to implement new features, alleviates pressure from the programmers themselves to implement and test features, and this also means that for players, updating their games doesn't take excessive amounts of time since script files are extremely small.
If the test version of features prove to be successful, the team could write better more optimized script, or if the features is important enough to be a core of the game, they could add it to the engine itself.
Metrics collection is extremely important when it comes to live-ops. As a developer you want to know what your players are doing, when they are doing it, and how often they are doing it. All this information is then used to improve your product. But this isn't done automatically obviously, it has to be integrated into the engine itself.
I thought about how I would collect the data for a while. The main thing I made note of while brainstorming was that while we might want to collect all the data related to what players are doing, when and how often they are doing it, we don't necessarily need all of it. Nevertheless, I am assuming everyone is uncertain about everything and so we want to collect everything.
The second thing I made note of was that even if we limited our metrics collection to select features, we'd still have the problem of reading it, because in the end it's all just numbers. So organization of the data collected is also important.
A word that constantly comes up here is data. It's all about the data. This made me think about MMOs and how data is stored on servers and players use a client to access (pushing input, pulling output) the data on those servers.
Basically, the best thing to do if you want to maintain flexibility and perform effective metrics collection, is to have your game related data stored on a server.
Processes for collecting data at a high level using a server:
In terms of the processes for pushing new features or updates for players:
As far as I can tell most the of the game engine design principles we have already learned are applicable to designing an engine for live-ops. The major difference is that your game has to be online in some way or form to maintain the level of speed necessary when it comes to updating a game.
For this blog, I would like to focus on how I might go about actually designing an engine with live-ops in mind.
Flexibility
When it comes to live-ops the development team has to be flexible and open to change. This is no different when it comes to the game engine itself. As I mentioned before the initial product that is released is relatively lightweight. It usually only includes core game features. Once the game is released the team starts collecting data, analyzes it and then based on the analysis new feature requests or changes are added to current or near-future plans. Even without metrics being collected from players, the team itself may want to add or test new features,
This means that the engine has to be built in such a way that designers can implement and test features quickly. In other words, the engine has to be modular. This can be achieved through a scripting engine, and implementing all game features using script. This would effectively allow designers to implement new features, alleviates pressure from the programmers themselves to implement and test features, and this also means that for players, updating their games doesn't take excessive amounts of time since script files are extremely small.
If the test version of features prove to be successful, the team could write better more optimized script, or if the features is important enough to be a core of the game, they could add it to the engine itself.
Metrics Collection
Metrics collection is extremely important when it comes to live-ops. As a developer you want to know what your players are doing, when they are doing it, and how often they are doing it. All this information is then used to improve your product. But this isn't done automatically obviously, it has to be integrated into the engine itself.
I thought about how I would collect the data for a while. The main thing I made note of while brainstorming was that while we might want to collect all the data related to what players are doing, when and how often they are doing it, we don't necessarily need all of it. Nevertheless, I am assuming everyone is uncertain about everything and so we want to collect everything.
The second thing I made note of was that even if we limited our metrics collection to select features, we'd still have the problem of reading it, because in the end it's all just numbers. So organization of the data collected is also important.
Flexibility + Metrics Collection: How to Manage Both
A word that constantly comes up here is data. It's all about the data. This made me think about MMOs and how data is stored on servers and players use a client to access (pushing input, pulling output) the data on those servers.
Basically, the best thing to do if you want to maintain flexibility and perform effective metrics collection, is to have your game related data stored on a server.
Processes for collecting data at a high level using a server:
- Player opens game client
- Client checks for updates and pulls.
- Player plays the game.
- If the player is in an area flagged for metrics collection, the server should know and begin collecting data.
- For example, let's say we want to know if players are entering certain dungeons or levels, we'd simply log every time they actually enter the level. If we wanted to know how long they take to play through the level, we'd log the time they enter the level and log the time they' leave the level.
- The collected data is stored on the server, at which point designers would have their own client that pulls the data. The client would be able to take all the data and present it in a readable form for designers to analyze and interpret.
In terms of the processes for pushing new features or updates for players:
- Designer has feature they want to test.
- New level, new item, new mechanic
- Designer has their own client which can simply push these small updates to a test server (an exact copy of the live server) where they will test their update to see if it breaks the game.
- Designer's new feature has been tested and is now pushed to the live server.
- Player plays the game and data is collected.
As far as I can tell most the of the game engine design principles we have already learned are applicable to designing an engine for live-ops. The major difference is that your game has to be online in some way or form to maintain the level of speed necessary when it comes to updating a game.
Subscribe to:
Posts (Atom)