Improbable Icon

That moment when

v12-0-4

#1

You rebuild your code 10+ times trying to figure out what you did wrong and then you realize you didn’t export prefabs… -.- lol.


#3

I had same situation yesterday :smiley:


#4

dies inside

what can we do to help with this? Some sort of UI marker for when prefabs in editor are “dirty” and need exporting? Some sort of exported versioning tool that workers can use to say “I’m using version “blah” of the exported prefabs” that you can compare in your editor?


#5

I’m not sure :slight_smile: pop-ups in some time delay (in loop) xD “Hey! Did you export entity prefab if you make some changes in script?! No? Just do this!”

:slight_smile:

PS . This is joke of course ^^


#6

Hmmmm, you could maybe make like an editor script that checks all prefabs once every 15-20 minutes or something and see’s if any are changed, if so then highlights in the improbable build window the export prefabs button in red? maybe have it be an enabled or disabled option, that way when you get to really high prefab counts you could turn it off to save performance.


#7

In general, I’d love to cut down on the number of steps that are involved in a rebuild.

Right now, I have to:

  • Quit (CTRL+C in terminal) my running local deployment
  • Rebuild prefabs
  • Rebuild UnityWorker
  • CTRL+R to Rebuild the current scene (UnityClient)
  • Run the local deployment.
  • Play in Unity.

Some of these steps take up to a minute, which means I have to be on standby for multiple minutes to execute the next step. If it was one single — perhaps 5 minute — process, I could at least go out and make a tea. What happens currently is this: I open my browser to kill time between each step, I get distracted on HackerNews, I come back and forgot which step I did, and I start over :joy: .

I would create a build script on the terminal myself, but — and I think this is the main obstacle — you can’t build a Unity project from the command line while Unity is open. Otherwise, these things would probably be easily solved using a makefile (that defines dependencies) or something similar.


#8

:rofl: I had the same problem. I regulary forgot which step i did!! :rofl:


#9

@noio not a bad idea there, though I would still have the single options in tandem, like you could build all, or just rebuild prefabs, ect.


#10

FWIW - versioning the exported prefabs would be an amazing addition I think and I think it would be relatively straight-forward to mark “dirty” prefabs in the editor or give some other visual indication when the prefabs need to be exported.

I like the idea of having the ability to just run a small part of the build process but also to run through the gamut of things that need to be done from within Unity as a single step. Presently, I find myself regularly quitting out of Unity to do a full clean/build cycle because it seems that the options inside of the editor to do clean and build don’t necessarily always get it all, especially when I’m iterating on a component and changing things around. Sometimes I seem to end up with old components being “stuck” on prefabs that I can’t get to clear without a full clean/build from outside of the editor.


#11

Thank you @noio, @spigot, @bonkahe and @krnlpanick for your excellent feedback.
As a game developer myself; I do get it. Don’t get me wrong; the 5 minute build time is WAY better than the 44 minute unreal engine compile - but its absolutely something we should improve :slight_smile:
I shall make sure this gets read by the relevant people!
Cal <3


#12

I read this thread with great interest. While I can’t promise any concrete plans/solutions for tackling the issues mentioned in this thread, let alone timelines for until you will hear more from us on that matter, I just wanted to let you guys know that we hear your problems/concerns and are thinking about how we can improve the development workflow.

Just as an fyi: You can package your Unity workers in the two following ways:

  • Streaming assets (the current default setting): Worker executables are not shipped with all assets included, assets are stored in separate files that are either streamed from disk at runtime or downloaded from the assembly service (the cloud) at runtime. This way of shipping workers makes a lot of sense for production grade games.
  • Local Assets: Project assets are bundled as part of the worker, worker executables are self-contained as they do not rely on streaming in asset data at runtime, Note: Prefabs do not need to be exported if this setting is chosen. This setting might be more suitable during early stage development, precisely because prefabs do not need to be exported.

Please see https://docs.improbable.io/reference/12.0/workers/unity/configuring-build#loading-assets for more details.


#13

@Jonas this is excellent advice; frankly I never thought of configuring my development environment to use Local Assets instead of streaming them, and to your point this completely eliminates the need to do the export at all. Perhaps as a interim solution 2 things could happen that would make it easier, especially for those new to the platform.

  1. Capture this as a step in the tutorial. This simple addition and callout in the documentation with a brief explanation (like you’ve done here) and a link to the relevant detailed documentation would be a great addition that would help inform developers and ensure that they made the right choice for their own development style.

  2. And/Or; shortcut this in the unity editor by adding an option to “Use Local Assets” in the spatial editorwindow. This could be “enabled by default” for development builds and “disabled by default” for deployment builds. This would allow developers to more easily use the platform without having to remember to export their entities all the time; on the flip-side this may be too transparent for new users without some visual notification when “Use Local Assets” is enabled in “Deployment” builds. In most scenarios that would probably be less than ideal; so a simple warning in he console would probably suffice (or as output in the spatial cli when built outside of the editor and configured for local assets during a deployment build or deploy.

Just thinking out loud here, but I think either or both of these approaches would be valuable in the short-term


#14

I approve this comment. It will be a good addition to the documentation.
And not only for this point. Add some tutorial will help to understand the concept (I’m more visual). Sometime, when I read the documentation, I not sure how to use or how to adapt to my project.