THE ASSET PIPELINE EDITOR - PART 1

Now that the cat is out of the bag, I believe its time to start posting some details about the Asset Pipeline Editor (from now on, "the APE").

So, what is this tool? To answer it, let's travel through time to a point, say, four years ago or so.

To make the long story short, during the golden age of XNA I was in the search of an efficient way to replace the built-in content manager class with my own. So I created my own version of this class, but I was still using XNA's content pipeline.

Then, when MSFT announced that they would stop any development on the XNA Framework, like many of you, I remained captive of Visual Studio 2010 IDE for building xnb's. During this year, I decided not to wait any longer for miracles and start building my own content-pipeline replacement.

Let's face it! How many of you have been lately crying out loud for XNA 5? Or asking where the content pipeline has gone? You still need VS2010 to use the content pipeline if you want to use XNA, Monogame or ANX. And no definitive solution has been provided yet. And even if there is something in the works, is it worth for teams?

Be honest here. You guys know that the in game development a content pipeline is indeed needed, but why sticking to a particular IDE for programmers (like VS) or any other programming IDE in the first place? It could make sense for programmers only, but for teams, artists, or even for solo devs that want to have an independent process, it does not. In fact, it could turn out to be cumbersome.

So, that is why I developed the APE. To replace XNA's content pipeline "in spirit" (since it has key deifferences) for those inhouse projects where I wasn't using Unity, UDK or any other authorware with its own content management features.

I must admit that at first I wasn't expecting to get these results, since I was aiming lower, but as times went by, I realize that -and please allow me to say it- I was creating something really good. So I went on until I said "Wow!".

Now, about its key features:

1. Its not for XNA, only: it works for any kind of custom content, not only xnb's. In fact, if you have your own way to manage content when programming a game or provide solutions (like WaveEngine, for instance), you can use it safely since the tool ends its job when the asset its build and copy to the folder you indicate.

2. It's a highly customizable tool: not only you can tweak the editor to meet the needs for your project (to some extent, of course) but also you can define your own building process: import, process, format, writing. You dream of it. You got it.

3. It eases the task of managing game content: that's it, throughout the whole development process. If say, you just want to use the input files as is, like pngs, jpegs, and so on so forth, without any processing, you can because the editor comes with pass-through units. So you can still use the tool to manage which content goes where, even if there is no processing required.

4. It's independent from any programming IDE: this is heaven for artists! If you are a solo programmer working on a game, having to use VS to build content is fine, but when you're woring on a team with artists this is not good at all. The APE comes with a GUI of its own.

5. Test before you promote units: "why is my custom processor not working?". Say bye-bye to these kind of questions since you can test your custom "units" (as I call them) before using them with the editor. Indeed. You can build your own testing assembly for your custom content/process. And once you give it a green light you plug it to the editor as an add-on.

Here you can see the main editor as of today:

The areas indicated in the picture above are the following:

1. Solution Tree: create a solution, add a project for a platform, and you will be able to traverse all the nodes here. Projects can have two or more containers: self, default and partial. And you can add as many folders as you want to each container. In future parts I post more details about this.

2. Search Tool: if you need to see specific nodes of the tree this is a quick way to do it. It works recuresively over the last search, so you can go on reducing results until you find what you want.

3. Output Settings: for every "raw file" that you want to import, you can define how to process it and format it. And for each project, you can define how to write ("export") assets to disk. These are powerful tabs. More about them later ...

4. Build Tool: here is where you decide whether to build assets for the whole solution (all projects) or for a specific project; and also where you define the compilation profile: debug, release, test, ... you name it ... add the ones you need for the solution. You will be able to watch it on a how-to video, later.

5. Configuration Tabs: so far there are four: general settings, solution settings, project settings and container settings. Basically, you can tweak many properties there and even add/remove entries for platforms, profiles, default importers, default writers, to mention just a few. In a later post I will cover all settings.

6. Log Panel: classic in any respectable IDE; here is where the editor informs you about the state of a given process, whether it succeeds or fails, warnings, exceptions. The usual stuff. It's a real friend to understand what's going on. There is more to it than meets the eye, and that deserves another post.

7. Bars and shortcuts: well, this is not indicated in the picture above, but of course that you have menu items (both, as text and buttons) and key shortcuts for many features. Not to mention, contex menues, where applicable, for example to copy or move content. Ahhh, yes! I almost forget it, drag and drop is allowed.

I don't want to go beyond the scope of this post, but I cannot help adding the following picture:

Above there's an example of a test assembly. When you create your units for a specific type of asset- by the way, using C#, this is where you debug them and see whether everything works as expected. Add break points, switch over text, find offending code!

And finally, for this post: "previewers". When you traverse the solution tree and select a raw file (or source file), the editor shows information about the file as well as a previewer for it. By default, the APE comes with previewers for some image, audio and video formats. Or else it will switch to an icon previewer. But the good news is that if you need to preview more formats you can create your own previewers! What is more, you can replace all built-in ones if you want ....

The picture above is an example of a previewer for an audio file.

Now, before ending this post there two remaining points I would like to address:

1. Current State of the APE: ready for my inhouse projects: the units, besides the pass-through ones, are meant for my inhouse projects, only. Plus, there are some features I would like to add (and even some porting to do) before a public release, if you guys are interested in having this tool, so ...

2. What's next: my idea is to start a fund-raising campaign on IndieGoGo to make a first release of the tool,  and some extended goals like developing some units for XNA'ers and Monogamers (so they don't have to), and even doing some porting to other platforms like MacOsX and Linux (since so far the tool only works on Windows for .NET 4.5). And yes, the link at the end of the trailer is not working right now as the campaign is currently on draft mode.

So, this is all for now.

I hope this post sheds some light on what's the APE about and that you guys are interested. It's upto you guys to define whether this baby eventually sees the public light (if not, I'll continue to use it for my inhouse projects). Your call ...

'till next posts!
~Pete

MY ASSET PIPELINE EDITOR ... FTW!

Hey guys, it's been a long time since I last posted something on my blog! So I decided to share a teaser trailer of a tool I've been working on during this year for my inhouse projects ...
... behold "The APE" !!

Sexy, right?

I guess you know the purpose of this beauty, but in case you don't, I'll be posting more details soon.

So, stay tuned!
~Pete

HOW “OPEN” CONSOLES LIKE THE PS4 OR 720 SHALL BE?

Recently, during the announcement of the Play Station 4, Sony made the promise of bringing the “most open console” for devs.

Discussions have taken place regarding whether by “open” Sony actually means that the new hardware architecture of the PS4 is somewhat more “familiar” than the one chosen for the PS3 console or that the burden to indies will be diminished to some extent.

The phrase is really interesting given that for years the access to dev programs for consoles have been and are still are surrounded by a plethora of red-tape (aka “security”) procedures so that as a rule -as opposed to as an exception, mainly (or if you prefer, only) big companies publish games on their “pro” marketplaces.

To be approved as a professional developer for whatever console, you need to demonstrate that financially you are backed up for the whole development and certification process (upfront fees, updates, deadlines, etc.), you must buy tailored hardware for production to have access to the corresponding SDKs, you need to prove that technically you are up to tough QA checks, and so on so forth.

In recent years, the opening of the XBLIG channel on the XBox 360 console may have seemed for many a change in direction, however, it ended up as a way to bring attention to the console without letting an avalanche of indies stain its reputation and even its status quo to an extent that could threaten the very monolithic model imposed to pros. Never wondered why only a few lucky devs made it into the XBLA channel?

One may argue that by upholding all of the above-mentioned requirements, console enterprises keep low-quality games away from their consoles. To some extent, back in the old days they could have, but today, generalizing the term “low-quality games” with low-budget games or indie games is getting more difficult to sustain (in many cases, such association is unfair).

Ok, but, if this business model has been working fine for console makers, what could make them change to truly support indies?

1. Apple kicked in: like it or not, Apple revolutionized the mobile market for smart phones, smart devices and tablets. But the story did not end there …

On an Industry where sagas were turning out to be far from innovative as well as rather repetitive, Apple was smart enough to truly open the door for indies and their fresh ideas, worldwide.

In fact, and in contrast from what MSFT did with XBLIG, Apple made no difference among devs. Everyone that pays the annual fee has access to the whole pack of features. It doesn’t matter if you are a pro or an indie. Is up to you whether to support any of Apple’s services in your game, develop your own or consume a third-party’s solution.

And every game, regardless its developer, must be tested and approved by a group of Apple’s employees.

All that, the fact that any game (pro or indie) could be picked to be featured on the “AppStore” as well as the growing amount of success stories among indies, contributed to position Apple’s devices on top of the list of target platforms for devs.

2. Google plays: following Apple, Google decided to enter the app-publishing market for Android-based devices, and with NaCl, for browsers.

The amount of devices running Android OS is growing fast and Chrome is strongly incrementing its market-share.

Google’s store, currently named “Google Play” is open for pros and indies, the list of approved countries is increasing, and many games that succeeded in other platforms were ported to Android.

Discussions aside whether you like iOS or Android, there is no doubt that Google Play has served as a model for other big firms, like Amazon and Samsung (with Chillingo), that decided to follow its lead and open a marketplace of their own.

3. The power of the Steam: there are many gamers -particularly hardcore ones- who claim that PC games have nothing to envy from console games. For those gamers, Valve introduced Steam as a means of digital delivery of videogames.

It first started on the Windows platform, then added MacOSX to recently support Linux OS. At the beginning only native-coded bits were allowed, but then Valve allowed managed code.

On recent months, Steam introduced its “Green Light” program, offering new publishing opportunities targeted for indies. In this program, the community decides which games should be granted a green light for publication. One example, is a well-known tower defense game named “Kingdom Rush”.

Steam succeeded where others failed, like Games for Windows, making its services attractive for many devs, globally. The buzz was so loud that now companies like Apple and MSFT have their own stores like the Mac App Store and the Windows Store.

Valve’s next move? The Steam Box console … “Piston” …

4. Secret Wars: imvho consoles as we know them are closer to get obsolete. Why? With current and potential customers buying more and more smart mobile devices over consoles, conditions are changing towards mobility.

As a matter of fact, there is a secret war going on right now among console makers to turn the experience of using a console into a whole multimedia one. Games, movies, music, applications, Internet, and whatever it fits the Cloud-Computing agenda, will be included in consoles.

But it doesn’t stop there … you will be also able to carry that experience with with you on your mobile smart devices. UserId synchronization over the Cloud plays a huge role here. Say that you were playing some game on your console but have to leave, don’t worry, you will be able to continue playing that exact game on your smart phone on the subway without having to start a new match; just resume it and presto! Ditto for movies, music play lists, etc..

Now, you could be asking what indies have to do with this. And the answer is simple, despite their budgets, small companies can react faster to changes in the environment; ymmv, but the larger the payroll and the infrastructure to sustain, the slower a company takes action to accommodate to new conditions on the market, since decisions on a big company usually involves many people on many levels of the organogram.

For each new device, indies would be most likely willing to take a chance. Big companies, unless an exclusivity contract is on the table or at least an exposure/marketing deal, they would wait to see what happens with the device (take the PS Vita for example).

5. Ohhh Yea!: thanks to a surprising campaign on Kickstarter the new upcoming console “Ouya” is about to join the market.

The console will target indies, but this doesn’t mean that you will be able to publish videogames without an approval process.

It’s very soon to foresee the fate of this Android-based console, but if Ouya succeeds, it will put a lot of pressure over traditional console makers, and who knows, all end up being quite positive for indies in the middle run.

So what can traditional console makers do to avoid oblivion?

For starters, traditional console makers must realize that profit is more and more associated to service-based models and less to classic business activities like setting high initial price tags for new consoles.

In this sense, the current monolithic model where dev companies are requested to buy special hardware for production and SDKs, pay high upfront fees, and crazy amounts of money for the QA of updates and patches, could rapidly become a huge stone on the console makers’ shoes.

The more number of games a console gets, the more the makers earn. Plus, they also get a profit from an annual small subscription charged to devs per platform. So the more devs a platform gets, the more profit the platform gets from subscriptions.

The beauty of this equation, is that the console maker always gets a profit from the games you sell and the subscription you pay, even if the game fails on popularity (and you don’t get money out of it). Multiply this income by a large amount of subscriptions and published games and you will have a winning strategy.

Make no mistakes here, this doesn’t mean that games shouldn’t be verified nor authorized before publication, but let the market itself do the ultimate quality-check on published games.

Now, there is an additional key issue to solve in order to assure a critical mass of devs and games. Both, indies and pros should be able to access all official services available for the platform with no distinction. As I mentioned before, on iOS devs can integrate leaderboards, achievements, social interaction, to mention just a few regardless their status as indies or pros.

Last but not least, implementing a proper videogame-exposure built-in system cannot be neglected on each platform. Usually, big companies can run ambitious/aggressive marketing campaigns, so they will likely get a spot on featured areas of the stores. So a way to attract indies is to expose their games as if they were made by pros. The 360’s XBLIG channel is THE example of what NOT to do!

To wrap it up …

The videogame market as a whole has changed big time in recent years. Smart devices introduced new challenges to both, PC and console makers. And thus, to stay in the game one may expect a strategy leap in the middle run on traditional consoles. Or else, these consoles may face an important drop in sells in comparison to previous editions.

How open a console may be deemed will therefore depend on, or if you prefer, will be directly proportional to the less barriers imposed on indies.

Let’s hope that both the PS4 and the XBox 720 consoles get really open to indies this time, by offering an attractive business model, worldwide.

Cheers!
~Pete