First Milestone

Background
This is my final year at DigiPen in the RTIS (programmer track). I was really stoked for this year as I was getting to make a two-man game project with one of my favorite developers in my year, Ramon Zarazua. Not many students wanted to make a Senior game, they just wanted to internship-out their remaining GAM credits so I was very happy to have a team.

I was happy to have a nifty game project and a good workflow with my fellow dev. Unfortunately, as the cards would have it, Ramon hit personal issues and had to leave the team, leaving my two-man team to be just me.

Fortunately enough, however, I had already begun getting extremely excited by the content pipeline portion of our game, and had been planning out some grandiose things I would like to do, but would never be able to do since I also had a game to make.

Ramon leaving allowed me to switch gears, smoothly, into this new project. My asset management independent study is the result of this.

Content Pipeline
So, this is one of those things that there's no one definition for and, honestly, I'm not 100% sure, myself. The purpose of this project is to explore and discover that. However, I've got a descent idea of what I think a content pipeline should be and should do.

• Material editing - An artist or designer should be able to quickly see what an asset looks like in the context of the game. No two lighting models look the same, and being able to modify shader attributes is a must for rapid iteration.
• Animation blend editing - Blend systems tend to be per-title (from what I understand), so being able to specify it within the context of the engine is a must. There's no good way of viewing this otherwise.
• Asset description - Creating / updating an asset and linking what model, animations, and material properties belong to it.
• Orphaned assets - Old assets that have since been replaced by different textures take up precious space. They should be removed without human intervention.
• Rebaking - Your model conversion system changed. Now all your assets are in an old, invalid format. You should be able to "rebake" all of these assets with 1-click. This also means a "development assets" needs to be kept as well as a "baked assets" tree.
• Version control - Now that all your changes are made, they should be submitted to the build-server so everyone can see the modifications. Also, if this is done automatically, within the tool, the intricate details of your chosen Version Control System (VCS) don't need to be described to all of your tools' users.

First Milestone
It was strange losing some dev time to re-planning what I was going to do this semester and pitch it my teachers and the Dean's Office, but it was well worth it. This last Friday I had my first milestone presentation with Chris Peters, 1 week after I switched my plan.

It was by no means the best presentation I've given - it was pretty gut-wrenching seeing my VCS wrapper do silly things, and my drag and drop interface crash on things I was demonstrating, but overall I think it was a decent result after only spending a week on a new project.

I've got to say, it was difficult taking my old graphics engine code that assumed that all assets were statically loaded on startup and squish dynamic asset changing into it. That's part of what was causing it to crash, some of the DirectX mesh data wasn't properly being released and reacquired in the switch-over of the new asset.

Though I found a bunch of issues, and my product wasn't as strong as it could have been, I'm so very excited about this project I can't wait to fix these things and get on to user testing!

Now off to go fix some new Lost Device issues I've found... /codecodecode