Synopsis

I plan to build a set of components, scriptable objects, inspector UIs, standalone wizards, unity editor extensions, in editor update mechanisms, and supporting web apps which will benefit 3 distinct parties:

• Asset store purchasers whom are indie game creators and developers
• Asset store sellers whom themselves are just indie developers looking for a side income
• The Unity Asset Store itself (and its owner Unity), in that this will drive UP the value of assets in the store, drive UP the number of successful asset to game integrations, as well as drive UP the number of successfully shipped titles built on Unity with assets from the asset store.

When combined, the work we do here will make it easier for indie developers:

• know that you can drag and drop any of the prefabs from an asset into your project and those prefabs will "Just Work" the way they are shown in the asset store video and demos.
• be able to identify the value of an asset
• be able to know when an asset will work with your Unity version
• be confident that an asset will work with all other assets in the GAS system

And if you are an asset store developer:

• You will know that your asset is QAed and reviewed externally (perhaps even before you publish it to the asset store)
• that a higher value is expressed in the store
• that the combined high value of GAS compatible (and certified) assets acts as a marketing tool for your asset
• and that you will yield a higher number of sales with a lower cost of support based on that value sentiment and the quality engineering processes enforced during this process

Project Goals

• to make asset prefabs "just work" when dragging them into a scene
• to give asset developers a way to distinguish their assets as a higher quality
• to give an internal body of QA people a simple process to follow to certify updates to an asset as compatible with the current GAS platform.
• to provide a new model for business best practice when developing and supporting assets in the asset store
• to eventually sell the entire GAS system to Unity and have it adopted as the asset store standard for future assets

Asset Themes

To dive a little deeper into the question of how our assets will work, each asset will be designed initially for one or two primary themes. A theme is a game type which includes the core game mechanic, or the target platform such as an asset designed to ideally work for smart phone games, or for targeting Unity's Project Tiny.

As an example, lets say that we have a dragon asset that is built to fit into an RTS (real time strategy) or a CCG (collectible card game) theme. The asset will include the 3d graphics for a fierce dragon with multiple texture packs, animations, and behaviors. The coded behaviors and art will have tradeoffs such as limits on the complexity of code for NPC movement, or limits on texture size, polygon count, animations, and sound effects which will be most useful for a game that has its core game loop designed as an RTS or as a CCG.

The reasons for this are pretty strait forward:

• The player's computer will have limited resources to process all the behaviors and graphics of the entire game. An RTS game could potentially have 100 or more dragon assets on the screen at a time, therefore, this asset will be designed with those limitations in mind.
• There are a finite set of behaviors for player driven and NPC driven behaviors for an RTS or CCG game loop, so we can design, test, and continue to refine a completed asset for those two themes in a much quicker iteration loop than we could if we tried to make the same code work across all game loop types.

If the dragon asset is the first asset you pull into your project, you will have to tell the asset which theme to start with, but as you continue to pull in other GAS assets which also work with this theme, they will communicate with the same config element that the dragon asset set up when it was first imported. So if you have configured the dragon asset to work for your RTS game, and then you drag and drop a GAS compatible goblin prefab into the game, the goblin asset won't have to ask you the same questions, as it can just check the config and see that what the dragon asset wrote to the global GAS theme config.

Problems GAS is Built To Solve

After considering my own experience and talking to many other indie developers who primarily work within the Unity ecosystem, it is my opinion that most assets in the asset store are not designed to deliver the value that was promised.

This is not because the developer or Unity are trying to lie or cheat buyers, and often times I find that asset store developers are incredibly smart, hardworking, and creative people who go way above and beyond to help me find solutions to whatever problem I might have with assets I've purchased.

But the problem is that I see an asset in the asset store, I watch the videos, I read the descriptions, the reviews, and sometimes even the documentation, and the idea I have in my head is that I'm purchasing a thing that I will import cleanly into my new or existing project inside of whatever version of Unity I'm running on, and it will immediately add the value I saw in the asset store to my project. I then assumed I could buy another asset and merge those two assets together into the same project to create a prototype game experience which I could start from and then add and tweak until my game was ready for release.

Over the span of a few hundred assets and a handful of years, this has never been the case.

Challenges I see are:

• To Answer the question of who is the ideal customer for ASSET store?
• to me, it looks like most of the assets don't serve the "idea guy", "the early / indie developer", nor the "experienced developer", and they most certainly don't serve the "studio"
• Idea guy: Sees three assets and thinks "if I buy these three, either I can glue them together or I can get some college kid to glue them together over the span of a few weeks, and I'll have my first game prototype in the hands of players by the end of the month.
• Early & Indie Developer: I see an asset with a complex set of systems that I know would take me weeks, maybe months, to build on my own. I can just buy this asset and drop it into my project, and then I can skip ahead to the unique parts of my game development and design that will differentiate my game from others. Also, since I get the code, I can open it up and learn from it.
• The Studio: I need production ready assets that will work on import today, but also still be working 6 months from now when the project is entering its alpha phase and I'm learning about new things my players want from my game and I have to bolt on new features and tweak this asset's features drastically to match my largest target market's expectations so as to have a successful launch.
• From my conversations with a large number of other Unity developers, many people believe that assets will serve these needs and I'm willing to bet that a large portion of asset store purchases happen because of those beliefs, but the results are rarely what the hope was initially.
• When I buy an asset on the asset store, I imagine it as a "lego block" to be added to my game or app project, but in a great percentage of cases, that lego block requires weeks if not months of learning spent mastering how it currently works before I can snap the block into place with an existing project.
• When I buy assets on the asset store, I am using the review star rating, the video and images showing off the product, the price, and the developer's existing forum posts as an indicator for quality for the asset. Even then, I can be mislead and end up with an asset that doesn't load or run in current LTS version of Unity without a bunch of manual fixes being applied.
• There is almost no way to know that until I've purchased, downloaded, imported, and tried to run the asset's demo scenes in my current version of Unity.
• Asset store developers are NOT currently financially rewarded for putting in the extra effort of regularly updating their assets for the moving target that is the Unity editor.
• Asset store developers are NOT audited for their compatibility claims. When an asset claims that it works with Unity 2019.2+, this should mean that this asset imports 100% without error, and that all demos included run properly when imported with 2019.2.20f and 2020.2.11a, etc, etc. In my experience, this has almost NEVER been the case.
• As a novice developer, many of my purchases were direct results of me looking at a set of assets and being inspired to create a mashup game which combines some or all of the elements of the set of purchased asset. The reality of the situation is that once I purchased the set of assets, the work to get just ONE working 100% of the time often quashed my excitement and killed the project before it got past the ideation stage.
• I believe that this is a common problem, as it is practically a meme on the support forums that the new "game idea" people in the forums have just purchased a bunch of assets and believe that they are 90% done in building their dream game. The reality appears to be that they are about 1% of the way there.
• The level of effort to import, refactor, and combine architecture choices between multiple coded assets is OFTEN considered more effort than just building the planned game mechanics from scratch every time, wasting most of the value of purchased assets.
• Asset store code architecture is not guaranteed to be the best practice. This means that even if a developer grabs an asset to learn how the asset did a particular game mechanic (and not with the fantasy of using the asset in their existing project), there is still no way to know that the code architecture and methods which the asset developer used are even a sustainable choice for the type and scope of the target game.
• As an indie developer who plans to make some side income selling assets, my profit per unit sold is hard if not impossible to calculate, as I'd have to assess the amount of time it took me to build the asset combined with the time it takes me to package, document, and support my asset, divided by the per unit profits of sales which based on my own personal purchase history, is likely < $25 per unit sold.
• So this implies that if a developer sells 100 units a year, they get $2500 income, which isn't 0, but if they then have to spend 5 hrs a month supporting the asset in forums or with updates — 5*12=60 * $30/hr = $1800 opportunity cost to future work, bringing their profit down to about $700 a year. This means that if the developer spent more than 23.33 hrs building, documenting, and packaging the asset, they are now in the hole even after their first year of sales.
• Unity asset store sales are opaque for an indie developer like me — probably on purpose. My assumption is that this is so that I can maintain the fantasy of a side income and I go into opportunity cost debt by building and supporting an asset on the store, even if only a small percentage of asset store developers actually make profit from the asset itself.
• The auxiliary benefits of building, publishing, and supporting an asset are not highlighted for an indie developer such as myself.
• Benefits like learning how to build and support an asset professionally, along with the exposure for your portfolio, and the ability to turn asset store purchases into contract client were never mentioned to me as I researched developing an asset for the asset store.
• It was only when I spoke to other asset store developers that I learned of those benefits and started to combine those types of auxiliary success metrics with what I would get when volunteering, or as an intern, or when participating in a hackathon.

BOARDS

Cards from my original work on the GAS