Home | Documentation | Atomic Chat | Github

Asset Farm Idear


The goal is to make assets readily consumable for your project, 1 click in, 1 click out, no waiting.

–What is an Asset Farm? It is a folder of Asset Packages which the user is interested in, to make their projects grow.

–What is an Asset Package? it is a zip file of things for your project. It can be anything you would add or create with AtomocEditor. The advantage of an Asset Package is it can contain a singe item or a collection of items for use. These items are described in the Meta-Object. Ideally they would be items that would not require further processing to be usable, and you should not need to change the asset to make it function, though there are always exceptions. They should use the “standard” directory structure used by Atomic, Components/Materials/Models/Prefabs/Scenes/Scripts/Sounds/Textures et al. There also needs to be provisions for having common files for a collection of assets.

–Because some assets are really big, there should also an ability to browse other Asset Packages or Farms out on the network, and download the ones you need into your Asset Farm (folder). Yes, it’s a manual process.

–To manage the assets, there will be a Meta-Object that describes EVERYTHING about the asset, It is a json file. and it may also be copied into the project. It will include a PackageName, AssetName, License, Size, Language, IconFile, List of Files(unique,common), Description, VersionNumber .The IconFile is either a picture of the object or an icon for it’s type, and should reside in the same directory as the Meta-Object. The Meta-Object files is also intended to be used to make directory listings or web pages.

–When an asset is added to the project, it will be a copy operation out of the zip file, following the recipe in the Meta-Object. It makes named subdirectories in the “standard” folders, and copies in the needed files, so there are no dependencies back to the Asset Package. To remove an asset, you need the Meta-Object to remove all the offending files.

AtomicEditor Asset Browser
This will be a dialog that contains a list of asset packages, listed like folders, and inside these folders are the list of Meta-Object assets. Each entry has:

  • A button to manage the asset. If its not installed, the text will be “ADD”, if it is installed, the text will be “REMOVE”, and the action happens at button press.
  • A thumbnail of what it looks like, or icon of resource type.
  • A language icon, if appropriate.
  • A use license icon
  • A description tooltip with all the Meta-Object information.
    Most of the internal plumbing for the adding an asset is zip file reading and folder creation, file copying (kicking the Cache) and removing files and folders, it is even easier.

–Making an Asset Package can be as simple as making a directory of stuff, filling out a Meta-Object file, and zipping it up( otherwise it can be really hard to make stuff). You do not need to be in Atomic Environment to create content. There are some simple rules, like asset paths will have to be programmed relative to the copied layout.

Would you like to know more? E-I-E-I-O.


This is great and well thought out, package import and export is really important, would be awesome to have some core packages available too, which are optional, things like first person controllers, mobile touchscreen joysticks, etc

Packages of art resources are relatively simple (other than conflicting resource paths, we may want to switch to UUID for resources instead of ResourceRef(type, name)

Prefabs are where things get a bit complicated, and one thing that is coming up soon are Prefabs 2.0 ( they need a reboot ), I’d also like to support nested prefabs for packages :zap:

BTW, what do you think about moving this topic to Atomic Development category to get some more :camel: grazing on it?


Lemme drop my 2¢ here…

Whatever you guys decide I’m fine with, I just would like to add that in my opinion we should make this ‘online-ready’: make it work nicely with external online ‘repos’ so people could maintain assets say on Github and you point Atomic to them and it will list them nicely and allow you to transfer them seamlessly to your project.

Regarding the optional standard assets, I agree 100%. I’d be happy to provide some components. However, we need to have some ‘guidelines’ for that kind of contribution otherwise we’d end up like Unity in which people solve the same problem in a number of different ways and it ends up quite messy. Since we have access to the octree, I guess spatial queries aren’t going to be a problem (that’s a nightmare in Unity… some people just loop everything and calc distance :rolling_eyes:), but there are still cases in which querying the physics space directly will make more sense (e.g.: when you care about colliders or only care about physical objects), the real problem however is when it comes to more complex logic. When you add a few objects like a ‘player’, a ‘moving platform’, and a ‘switch’, you want to make sure they all work properly together, and for that we need standardized colliders/triggers with tags and stuff like that, and maybe some kind of event system that is configurable in the inspector and works with other scripting languages (Like Unity’s).

In the (hopefully near) future I think Atomic would benefit enormously from something akin to the “Unity Playground Project” and maybe we could maintain a community Github repo for that, but you absolutely need some restrict standardization for that to work and in my opinion it’s best to start thinking about that early on. Judging by the Unity Asset Store popularity and how that certainly played a huge role in Unity’s “Success”, I think that’d be a worthy effort, especially if we manage to have a strong community contributing to it. Having something like that could significantly decrease the entry barrier and make prototyping much faster. It’d be really nice if people could just open a kind of ‘asset store’ and drag and drop some assets around to make, say, a simple but usable 2D platformer. If you look at the other opensource engines, some have plenty of tutorials and whatnot, but the newbie won’t be able to get a decent final product easily. Atomic could help you actually get things done much easier with something like that.

I went way too much off topic though. I’m really excited about the possibilities of having something like that. We reinvent the wheel way too much in game development, but most of the time that makes sense because the closest we have to reusing so far is to ‘frankenstein’ some assets together what is far from decent, especially when it comes to Unity.