How do you manage assets creation workflow?

Off topic
1

I start with examples right away.

  1. You want to add a new weapon to the game. It actually consists of multiple assets: 3D model which eventually should be rigged and animated, various sounds, and probably some icons and tooltips for inventory menu, reference page or HUD. You probably will collect some source materials from the internet or elsewhere first, like boilerplate model, sample sounds, textures, concept arts, etc. On the output you may also have several options created with some small (or big) variations which you can compare later and choose the best. Now imagine that there are different people involved in the creation of different aspects of the gun, for example one does modelling, one creates sounds, etc. Now imagine that you need to create 10+ different guns.

  2. You are going to release an app on mobile platforms. Your app is already doing its thing, but in order to publish on Android and iOS phones and tablets you need to create like 50+ icons. Big icons, small icons, store icons, splashcreens, banners, advertisement icons, tablet/iPad specific icons, high dpi, low dpi, medium dpi, 9-patch nonsense, etc. Now imagine that you are doing “white label” app and for 20+ clients you need to maintain individual branded set of icons and potentially some brand specific graphics used inside your app.

So, how do you manage your digital assets creative workflows? Is your solution totally okay for your needs, or meh…?

2

Hello !

These are pretty good questions, and by the way, this point is exactly the reason why I take more pleasure developpings apps with BabylonJS than for example Unity3D or UE5 : ASSETS. Natively in BJS, assets are dynamically loaded from network, while in Unity or UE, assets are by default hardcoded in your app, and “eventually”, there is a trick to enable dynamic load from network…

Now about your questions (are they actually “questions” ? :grin: ) I can give you my way, but keep in mind it’s my way. I guess everybody has its own way.

  1. This one I’ll separate in two parts : team, or alone (very different, honestly)
    • TEAM : I used to manage R&D 3D dev team, it was not BJS, neither Unity or UE, but Houdini. But at the end it’s the same : what’s needed is a normalization. You need to put in place a document explaining exactly the way a new asset should be added to the repository (I use Git LFS for assets) and put in place very clearly naming conventions. For example a weapon, it would be :
      • 1 .glb/gltf file in assets/wearables/weapons/ak45.glb
      • Texture files in assets/wearables/weapons/textures/ named Diffuse_ak45.png, Normal_ak45.png, etc…
      • 1 json file in assets/wearables/weapons/ak45.json that the 3D dev has filled following a template. This json file would explicit what can be done with this weapon :
        • Team : Terrorist
        • Wearable : True
        • Stackable : False
        • Textures Types : [Diffuse, Normal, Metallic, Roughness]
        • Damage : 145
        • Precision : 1.25
        • Reload delay : 4.2
        • AmmoMax : 12
      • On top of this, you would put naming convention on all animations which should exist in the .GLB file, like reload, appear, disapear, etc…
      • The most important in all of this : Making so that adding a new weapong is 100% transparent for the rest of the team. You should be able to tell to a 3D modeller (which is not a coder, at all) “Please add 10 weapons” and he adds it, and the day after you test the game and it works, and no line of code has been changed.
      • And then there is a weekly or monthly meeting to be held between 3D modelers and Devs, to discuss the current state of normalisation and its limitation. Maybe a 3D mod couln’t add a specific type of animation because it was not handled by the current API, and he will bring this idea to the devs, and they will think about the best way to smoothly add this feature in a retrocompatible way…
    • ALONE : Very different because you don’t need a file to be given to yourself to explain yourself what you want you to do :joy:
      • For BabylonJS I work a lot with Blender & Python. I still keep some naming conventions, and then I have for example one .blend per asset (let’s say weapon). Each .blend has a (non-embedded, to be updated for all blends) python script. When I hit the run button, it automatically exports the .GLB file along with its embedded textures, and uploads (add or replace) it to the online server
      • That way, when I need to add a new asset, I just need to copy a .blend template, model my stuff, hit “run” on the script, and it’s online, up & running.
  2. I work a LOT with Python for these. And I think either I’m developing in JS for a web context, C# for Unity 3D, or VEX for Houdini, I’ll always to huge usage of Python. It’s just a golden way to automatize all your processes, typically exporting an icon in various sizes and names, following some conventions, etc… All starting from a single “large” version of the icon, for example. The goal is to be able to do a slight modification, run a script, and update 20 files at different names and sizes within a second.

I hope it will help you, and that it’s not too much off topic xD
Good luck !

++
Tricotou

1 Like
3

If anything this

or at least this should be the goal. To put it more bluntly: you want to automate the tedious and boring shit jobs away :grin: This would be one of my primary management goals.

Other than that, I think, unless you are writing your own game editor, it is gonna be messy :frowning: and therefore needs someone managing all the pipelines (incl integration). Taking your weapon example, this is how it looks on my end:

1. 3d model

  1. Design/Edit weapon model in Blender.
  2. Save .blend in a given directory.
  3. Run python script (which handles creating palettes, writing meta data, export as glb etc.)

2. SFX

  1. Design/edit weapon sound in Audacity
  2. Save it as raw, project (trim, loudness etc.) and final version.
  3. Run Audacity macro to do some normalization stuff and ogg compression.

3. Sprite

  1. Link 3d model in another Blender file and render 2d sprite image of weapon
  2. Run pyhton script
  3. Previously this would go into an atlas so there was a texture packaging step. Even before that there were some ImageMagick tasks.

4. Data / “glue layer”

  1. Register the new weapon in game using custom Entity-Component-System (ECS) editor / Excel. (by “register” I mean type in the data)
  2. There is no way you can automate this (can’t you?). A weapon needs attributes like damage. That particular weapon needs an associated model, sprite, sound, etc. How would you derive that? For non-ECS game objects I use Excel sheets which get converted to json.

Necessarily messy. Tasks 1 - 4 are bascially isolated and each have there own rules such as how to trigger the automation scripts, what programmes to use, what manual work etc. The solution, I can think of, would be writing a game editor or using a full game engine.

But I do think that there is a positive side. If these tasks are isolated, i.e. independent from another, people can start working on creating assets early on. The weapon model will be the weapon model no matter what your workflows are. At some later point you probably need to change some names/files/directories.

Particularly wrt

Unit test assets. Regex naming conventions. Check plausibility. Is there a weapon model in the game assets? Then check for data entries and associated other assets.

4

Thank you!

Actually, I meant more like pre-integration stage, because the integration stage might be very different for every app as you say. Particularly, I meant how do you guys manage your digital assets regarding what is done, what has to be done and what do you have as a supplemental/source materials for new potential crafts.

I suppose that the first thing that comes to mind is a shared drive with some documentation on a wiki page about what is where and in which order should be placed, named, etc, complemented with GitHub/GitLab issues for progress tracking. But that approach doesn’t show full picture on the tips of the fingers and I guess makes onboarding more difficult for new participants. Also, the defined rules in this case are easy to violate (unintentionally of course). I guess if I could “attack” this part of workflow efficiently, it could lead to a reduction of the need for those weekly and monthly meetings and making assets production workflow tracking easier. Does the problem that I mention here make sense for anybody else, or am I just imagining things?

Some points that were already mentioned here I find quite useful. For example, name conventions can be enforced on this managing stage. Also, some scripts might be optionally added to verify the crafted stuff that it’s at least exportable in the right formats or already has been exported and stored in a proper way.

5

So wait, are you talking about the real basics here like where to save the .blend file and how to name it? And how describe the saving and naming process in a wiki? Or where are the “raw” project files and where are the production files? Stuff like that?

Assuming so, yeah, this is a complete mess on my end and I have been trying to figure this out since forever. I kinda tolerate that situation because it costs me like 10 mintues once per month in order to relearn a certain workflow. But I do understand that this is not a solution if a team is involved.

re the people aspect (second paragraph)

Just a couple of random thoughts.

  • Onboarding: things are done differently across companies. People learn and understand differently. So whatever you do, I think, there is a good chance somebody doesnt get the workflows. You will have to catch this exception…
  • Eliminating meetings: do team members want that? If so why?
  • rules easy to violate: Whatever you do, if it is not a full solution integrating all your workflows, I would say, you just have to live with violations. Because the instance you have a manual step somewhere (e.g. save file to, name file as) there will be mistakes.
  • General: I would have this discussion with my team and gather their requirements.

Finally, keep asking good questions :slightly_smiling_face: You already have documented that you need

  • asset stages (source, project, production or so) with implications for directory layout
  • asset variations with implications for naming conventions and/or directory layout
  • progress tracking (via github, with scripts?)
  • self-documenting workflows (as much as possible) implying explicit naming conventions (so no files like unnamed002.blend)
  • scripts checking/enforcing workflow/throughput integrity (what language, any directory layout restriction, etc.)
1 Like