The Mog Pipeline is a mixture of traditional asset management, worflow automation with a light twist of version control. Projects using the Mog Pipeline can reduce many tedious processes to a single click; greatly reducing the technical requirements asked of the artists. Furthermore, the workflow automation features can greatly improve a team's performance streamlining the process of moving new or existing content into the game.

• Single User Workflow
• Team Workflow

Single User:

To provide quick and reliable conversion from source data editors like Max, Maya, Photoshop to an optimized asset ready for the game environment is an essential design goal of MOG. Using the MOG pipeline users need only set up the process of converting that data only once and MOG will handle all subsequent conversions of that asset from that point on.

To illustrate the workflow process of a single user, lets take a hypothetical user (Todd) and a 3D asset that is built in 3D Studio Max.

The MOG Manual Approach

Initially Todd would retrieve his MAX file from the teams Asset Versioning system(Shared drive, Perforce, Alien Brain, etc...) for editing within MAX. Once in MAX, the asset is adjusted and modified.

• 1. When ready for the game, Todd would perform a MOG import. Typically we have seen teams export the MAX source file as an ascii representation of that asset.
• 2. Once imported into MOG the asset would show up in the Drafts folder of the MOG client.
• 
• 3. Todd would then Rip this asset invoking MOG's distributive processing system that would run a series of team configured conversion tools that convert that ascii file to an optimized platform specific game asset.
• 
• 4. This processed asset can now be copied to Todd's Local Workspace.
• 
• 5. Todd can now run his version of the game to take a look at his 3D asset within the game itself.
• 

The MOG Auto Approach

With the help of two easy checkboxes MOG can run in auto mode. Within this mode, assets are automatically moved through the pipeline to become game ready assets. For example, an artist clicks on a single button in Max/Maya that exports their asset into MOG where it is automatically processed and then updated to their local workspace. MOG will even package assets automatically so artists only need to switch between Max/Maya and their Editor making fast iterations a reality.

• 1. When ready for the game, Todd would perform a MOG import of his asset. MOG would then automatically perform all the ripping and packaging of that asset in the background allowing Todd to switch directly over to his editor or game where he can immeadiately view his change.
• 

After Todd duplicates this process numereous times till he is satisfied with how his new asset looks within the his runing game environment, he performs a MOG Bless that pushes his new version of the exported binary as well as the optimized processed version into the teams Master Repository or Gold data pool.

Conclusion

Providing a duplicate-able, distribute-able, batch-able atomic approach to asset preparation is really what makes MOG a pioneer among asset pipelines. We have consistently seen users celebrate the improvements to single asset iteration while not sacrificing the ability for a game to perform large batch re-optimizations on those same assets later in the game lifecycle.

Team Workflow

One of the key considerations for MOG was its ability to facilitate team collaboration. We have always seen the importance of isolated design groups working in tandem to explore or complete a new game feature or milestone item.

With that in mind, MOGware coined the use of Inboxes. Each user within a project would recieve his own inbox that would contain a Drafts, Inbox, Sent, and Outbox.

Each team member would not only have this private box but would be able to browse the inboxes of all other MOG team members, enabling users to share, collaborate, and test other users prepared game data without having to commit or bless these assets in to the main asset repository.

As shown in the graphic above, Sara and Todd would like to view the new blue asset that Jim has been working on. By browsing Jim's Inbox Sara and Todd can see and merge Jim's blue asset into their local workspaces. MOG delivers the asset directly into their respective builds. Now they are both able to play their versions of the project with their changes in relation to Jim's new blue asset. With all parties satisfied, Jim can now bless his blue asset into the master MOG repository. Once blessed, Jim's new blue asset will be delivered to all team members requesting a 'Get Latest' from the MOG server.

Lateral asset sharing allows users to view each others data within their own local builds improving the sub-team synergy found in great projects.