Gestalt Asset System: Business Plan
🗡

Gestalt Asset System: Business Plan

Lean Canvas for Gestalt Asset System

👆Ask if you need access to the above link.

image

The Promise

💡
I will to create a future where artists are not beholden to the studios, but instead they choose work based on their passion. I will create a future that the business around artists is only there to fill in the gaps for common services such as marketing, community management, and financial management. I will build a future where all creative projects are derived from the purest of passions of all the contributors. I will use my own passions and skills which cover a wide creative and technical range to combine existing and design future tech to build safe & direct access between the artist and the consumer. I will build the platform to allow artistic expression, non-dark pattern content discovery, and a constant flow of people from the role of content consumer, to fans of an artist, to patrons of that artist's work, and to eventually become fellow creators within the platform. This is why I am building the Gestalt Asset System.

Gestalt Asset System, A Brief History

At first, I was thinking I'd build a bunch of assets AND this system, put this system on my assets, and sell the assets in the store to other "just getting started indie game developers" — but the amount of time I'd have to invest to build all of the assets and the system would be pretty big. I'd then have to support the "just getting started indie game developer", which, to do it right, would require a lot of time invested. And lastly, as I move forward with the system, I'd be adding features and changing APIs, but if a new developer is using one of my assets and I ship an update which breaks their already working drag & drop game, they likely won't have the skill to resolve it themselves, adding even more support ours and edge case bug fixing to my work.

After going through that mental exercise, I switched my thinking over to building the system and then sell the service of applying that system to existing asset developers who have assets already in the app store. This switches my customer base to directly supporting other asset store developers and not to indie game developers, it also skips the need for me to build the assets themselves.

The business value for asset store developers is two fold. First, they get highly flexible, thoroughly tested, self configuring code for behaviors around their asset, making the asset more attractive when compared to other similar assets in the store. Secondly, indie developers building a game with GAS enhanced assets will be driven to other GAS enhanced assets, bringing more active indie game developers to the asset store for asset that are enhanced with our platform.

The big picture business value is that with the Gestalt Asset System, we will enhance the value of all the top tier assets in the Unity Asset Store with a possible exit of catching the eye of Unity themselves, selling GAS to Unity and going along with the acquisition.

The Plan

We build a collection of technology components that, when applied to existing art assets, you get the following:

  • drag and drop the asset into my scene and "it just works" as it was designed
    • a gun shoots, has ammo, can be dropped and picked up
    • a vehicle can be driven, damaged, repaired, fueled, and destroyed
  • a custom inspector UI or custom wizard for assets on initial setup
    • Wizard for initial setup if the imported asset can't detect any other GAS assets with a configuration
    • Links to docs and/or videos explaining each feature in 5 minutes or less
  • Every GAS enhanced asset integrates easily with other GAS managers
    • GAS UIManager
    • GAS PlayerController
    • GAS CameraController
    • GAS InputManager
    • GAS NPCManager (manages pooling, creation, and communication amongst NPCs)
    • GAS NPCSpawner (manages creating of NPCs as well as MOBs. Can have a physical body or just be an area)
    • GAS NPCNeutralBehavior (the behavior of the NPC e.g. quest givers, stores, followers)
    • GAS NPCMOBBehavior (the behavior of a potentially hostile mobile npc)
    • GAS FunctionalBlock (a block that does a thing in the game)
    • GAS NetworkController (network packets that flow around based on game mechanic and client/server typogrophy preference. Gets tuned for the type of game and number of players desired)
    • GAS QuestController (for tracking player's progress through the core game loop
    • GAS EnvironmentController (for weather, night and day cycles, LOD hiding)
    • GAS FXController (direct access to visual and SFX not tied to quest, npcs, or functional blocks)
  • multiple game use cases supported
    • Side scroller platformer (metrovania)
    • rts (moba)
    • fps
    • third person (stealth, infinite runner)
    • rpg
    • puzzler
    • card battle
    • tower defense
    • racing
    • visual novel
    • top down iso (dungeon siege)
  • Medium term: GAS exposes it's methods to be called by other smart assets (bolt, playmaker, game manager like systems, etc)

Gestalt compatible assets use the existing assets in a scene to decide how to behave.

  • Inspector UI shows current "I see X, Y, and Z, therefore I am in ABC mode" thinking
  • Inspector UI allows the developer to force a particular mode so that if an asset detects wrong, it can be corrected
    • Medium term: the indie developer will be able to create a combination game mechanic. So for example, if a top down game has a car asset added, the car asset will want to continue to behave in a top down manner, but perhaps the game designer wants the car to switch to a Mario cart style race car mode, they can enforce that through the properties of the car asset when it is imported into the scene, and when the player walks their character to the car and activates it, the game mode UI, network, controller, and camera all switch from the top down game mode to the cart racing style mode.
  • Inspector UI allows for explicitly pointing to things such as game manager, FX manager, scene manager, GUI, etc via drag/drop public references, but it will always detect and set them when it detects the asset already in the scene.

Example Case

Below is an example case that an indie developer would experience when building a game using our system.

In this case, there are four parties involved —

  • The Indie Developer — the client of our client
  • The Asset Developer — our direct client. The person that creates and publishes assets to the asset store.
  • Our own internal team of developers and which will implement the GAS system
  • The end user (player) of the final game product
  1. The Indie Developer purchases a "HUD GUI" asset from the asset store and drops it into their scene.
  2. The asset will recognize that it needs modules (such as the GAS PlayerController and GAS InputController detailed below) from the Gestalt Asset System and give the indie developer the option to download and import all of those required components.
    • GAS asset system components are free and will be distributed both as importable modules and as assets in the asset store which can be downloaded there.
  3. After import, the HUD has 3 options which the indie developer can choose from -- one for Moba, one for RTS, and one for a Diablo style adventure top down RPG game. It modifies its layout and which events it listens for based on which option the indie developer chooses.
  4. Through a setup wizard which appears in inspector on the first asset import -- the indie developer chooses the RTS HUD option, and the UI configures itself to support all of the things a RTS would need.
  5. The inspector then shows a long list of recommended compatible assets for this game mode including player avatar actors, buildings, visual FX, and Sound FX — all from different Asset Developers, but all configured with the Gestalt Asset System.
  6. The Indie Developer could then purchase and download an "Mage Character Asset" from the asset store.
    • The mage is is built by a different asset developer than the UI — but the indie developer would know that it will "just work" upon import because it is supported by the Gestalt Asset System.
  7. The indie developer will download and import the Mage Character Asset into their game.
  8. The asset would recognize that the UI has been configured for an RTS and setup this Mage Asset to behave like the indie developer would expect from an RTS.
    • As there are some options to detect the indie developer's complete intent, the inspector gives the indie developer the options to choose from — allowing them to make the Mage a spawn-able unit from a building, a "starter hero" unit, a static NPC and quest giver, a mob, or any other role that the Gestalt RTS system supports
    • all options are configured through a wizard in inspector after initial import and can be changed by the indie developer later.
  9. The indie developer would now have a working RTS hero character walking around on a flat surface with a great looking UI and hero avatar.
  10. At this point, the indie developer would go back to the asset store looking for enemy assets, environments, buildings, hazards. All of which are tested and known to work in an RTS game using the Gestalt Asset System.
  11. Once all of the core game assets have been purchased and configured — the indie developer will have a ready to play test game which they can build and begin testing with end users.
💡
Medium Term — we will build game mechanics which the end player can shift between. For example, it would be possible to shift from the RTS view in the previous game where the end user (player) is commanding an army to explore and expand into an area of a large map. They could discover a "dungeon" in the expanded area and then take their hero Mage asset into that dungeon and transition into a Diablo-like adventure RPG style iso interface — using typical iso RPG party mechanics for a limited number of the player's RTS army to join them into a deep dive into the dungeon. A similar transition could happen from an RTS mode gaming into an FPS mode game, or from a first person to a third person perspective. All gestalt compatible assets will simply transition from their RTS mode components into their FPS mode components upon the end user choosing that transition.

How does Gambit Development Make Profit?

Direct Implementation of GAS Enhancement Into Existing Assets

I then sell my services on top of the framework — where I take an asset and I apply the framework to it — making every asset in the asset store drag and droppable "it just works" into unity scenes.

When I make the asset GAS enhanced, it will get priority listed in the GAS recommendation engine. GambitDevelopment will also work to create a community (discord, forums, reddit, facebook, and IG) around these in house enhanced assets — constantly driving foot traffic to that recommendation engine and showing off new assets.

For Asset Store Developers, they can purchase any of the following Packages:

  • Basic implementation of gestalt asset services:
    • apply my code to the customers asset
    • awake in editor work (detect other gestalt assets and game setup / config)
    • custom UI in inspector (enable, disable, check for update, links for support forum, discord)
    • basic branding on that UI
    • 5 minute tutorial on how to make the asset work in the X cases we support in the gestalt asset system
    • support of gestalt asset services via zendesk tickets * 5 tickets
      • I will refund any ticket that is a bug in GAS
    • extra support is done via discord @ $150 an issue (assuming 1 hr of my time)
    • 4 hrs of work * 150 = $600
      • 2 hrs of implementing GAS for one component
      • 1 hr of meetings + UI / UX design
      • 1 hr total spent on 10 tickets
  • Advanced implementation of gestalt asset services:
    • all of the above
    • 4 hrs of UI design of inspector UI
    • up to 3x - 5 minute videos showing off asset in different scenarios
    • unlimited zendesk tickets
    • support of gestalt asset services via discord + text up to 3 cases for free
    • $1500
      • 7 hrs of labor * $150 to make it = $1050 of internal cost
      • 3 hrs supporting it in those 3 free cases @ 1 hr each = $450
      • 1050 + 450 = 1500

The asset developer will send me the raw asset — I will apply the gestalt asset system. They will pay me a fee based on how "advanced" they want their asset + GAS to be.

The asset developer will then decide if they want to charge extra for a "gestalt" edition of their asset, or just include it in their main asset to enhanced the total "value" of their asset, without adding any extra code or testing complexity on their side.

We give them a banner to hang over the corner of their Unity Asset Store image to say "Gestalt Asset Services Integrated" for their asset (exposing the higher value of their asset to buyers on the asset store, and allowing tagging)

Though I will start with my own hours and white glove this (hence the $150/hr cost I'm setting for my sunk times), once I get things together, I will outsource the implementation of GAS and the new assets.

Unity + Gestalt + Gambit Development Assistant Producers

Not all indie game creators are developers. Some may be coming at this from the designers perspective and be willing (and able) to pay for others to do custom develop and art design.

Here is how a game designer will commission an artist to do work, how the work is done, and how the artist will be paid:

  • a game designer creates an rfp / commission through our art collaboration project to add a new texture within a project where the texture will be applied directly to a material in a 3d asset in unity.
  • bids come in from artists capable and ready to do the work
  • bid is accepted and an artist is selected to do the work and the money gets pulled into our bank
  • the work begins
  • At every save of the work, there is some dropbox like tool that syncs the raw work into our system
  • a multi tech notification prompt goes out to the artist asking "would you like to publish this draft to the client, and if so, please provide details as to what is new in this revision of the work"
  • the artist receives and can respond to the notification via every method I can come up with:
    • a local app on their pc
    • a text message to their phone
    • an email
    • a notification on our artist collaboration Slack
    • an automated phone call with TTS to the artist, and voice recognition + the artist voice
    • All communication language will be translated in real time via a "Kim" if need be
  • upon the artist responding to the notification with what the new revision contains (their git commit message), the system then works to "compile" the asset
  • our system can handle many formats, but for what it can't, it hands it off to a "Kim" team member who is trained specifically in importing 2d texture into Unity.
  • Either the system or the assistant producer completes the transfer of the asset into a reviewable asset for the game designer
    • If our assistant producer has to do the transfer of the asset, the process which they follow will get documented so that the system can be updated to start doing this automagically and so that we can pass this document to the game designer and the artist at the end of this commission.
  • A notification goes back to the artist to approve the reviewable asset for the project owner, so that the artist gets final say before the work gets shown to the game designer
  • finally the game designer is able to review the artists new texture, in Unity editor, with the new texture applied
  • Once the project owner approves the work, the system releases the money to the artist and the final copy (including source assets + details on how we converted it and how the project owner can edit the asset and reconvert it themselves either via our tools, or following our "Kim" playbook)

Business and financial logistics for Assistant Producer supported workflow:

The gambit development assistant producer is paid by us.

The artist is paid via the system once the project owner approves the work.

We take a cut of the total paid to the artist.

For every work transfer we can facilitate via automated means, the company makes more profit from the transaction (as we don't have to pay out hours to our APs)

The company is also holding the money for the duration of the work being done, so we can find safe ways to take this money and grow it while the artist is working and the project owner waits for the work to be completed.

We allow project owners and the artist to make an agreement for a particular bundle of work hours, keeping this particular artist available for this project

  • the project owner puts up a percentage of the money up front and pays out the rest directly when each piece of work is complete
  • this grows the amount of time that our company will hold and grow that money
  • if the project expires and the project owner has not gotten agreement from the artist to cancel the work, the retainer gets sent to the artist at the end, where again, we get our cut

Zeroconf + pubsub diagram:

https://drive.google.com/file/d/18KBl91d2MhtgwZ6Yya6QvewejvZCoiSO/view?usp=sharing

image

ZeroConf and Pub/Sub

Original draw.io diagram:

Reading on how to build it: