HOT RELOAD - Edit Code Without Compiling!

Hey everyone!

I’m excited to share a new product we just launched - Hot Reload for Unity. It allows you to make code changes and see the updates in real-time. No domain reload, no waiting for editor compiling, and no project changes required.

Check out the demo video here:

The developers in our studio used to struggle daily with very slow iteration times. Our project is currently 2M+ lines of code, and even with months of work our biggest assembly still takes ~45s to compile, not counting startup of the game (~15s), and getting back to where you were (easily ~30s)

That’s why we created this extension - to allow for much quicker interactions and iterations.

After several years of using the product in our studio (40 people), we can confidently say that we have a hot reload product that just works - even on massive and complex projects. Our solution does not involve waiting for Unity to compile, nor a Domain Reload; all your in-game state stays exactly the way it is.

You can get it on the Unity Asset Store (Unity Verified Solution) or on our webite

Please let us know what you think!

UPDATE: We recently changed our pricing options, including a cheaper one-time purchase pricing model for individuals and small teams! See the pricing page on our website for more info.

Links
contact@hotreload.net
Walkthrough video
Discord
Issue Tracker

29 Likes

Sounds too good to be true, which I hope it isn‘t. :slight_smile:

Can you elaborate, at least on a high level, how this works? What are the main limitations or caveats?

4 Likes

Hi CodeSmile.

To make it work, we built a custom C# compiler integration (yes, really), and only compile the code that changed. And with that output, we patch up the existing C# code while it’s running (this part has been done by many games already).

One drawback is that most edits, but not all edits, are supported. For example we’re still working on supporting adding/removing arguments in method signatures (at the moment this still requires a normal compile in the editor). This is answered in more detail in the ‘What kind of code changes are supported’ question on our FAQ.

That said, we’re working on it; hopefully in the next week or so, we’ll release an update to also support those (undergoing internal beta).

Overall I guess the main drawback is that we’re monetizing it rather than open sourcing for free, though we hope to still support some people with the free trial and a permanent free tier.

We’d love to hear your feedback though!

4 Likes

Monthly subscription is often difficult to handle inside company,
rather have fixed price, then optional paid updates every year or version or so…

*of course it has possibility to save time and that amount of costs in many companies (in saved compilations times),
but in our case it wouldn’t be used in every project, so would prefer fixed…

Hi mgear.

We’re definitely open to price suggestions, so thanks for the feedback. Can you please clarify what you mean by “in our case it wouldn’t be used in every project”?

Hot Reload should work in every project, and I believe it’s useful even in the smallest of projects. But maybe you mean something else?

Yeah i mean outside game dev, at work,
if we do projects for different customers, most of those wouldn’t really need hot reload… (if scripting is really simple too).
But for example if its mobile or quest app with more complex scripting or so, then of course this would be more useful during that time. (but often not so many of those projects)

Thanks for clarifying. I suspect our upcoming free tier will be sufficient for project with minimal scripting, but I understand what you mean about the subscription being active even though you might not always need it.

We’ll re-evaluate pricing in a few days, based on your feedback and feedback from a bunch of people that are currently trying it out.

If you have any feedback on the product, feel free to leave a message here!

1 Like

We just released a new QuickStart Setup & Demo video which pretty much goes through the whole process from downloading it to getting it running in a demo project. Took less than two minutes to get it running!

Check it out:

4 Likes

Does this support projects with significant amounts of code generation?

I’m thinking about how this could apply to Unity DOTS where even a single line change that contains SystemAPI would require a complete regeneration of the entire system class / struct. Does your modified compiler recognize and follow the changes in code generated files along with the original file?

And how does this work with Burst and Burst compiled methods / jobs?

5 Likes

I haven’t tried this yet, but if it’s as effective as advertised this could be very cool indeed. However, at the micro solo indie level that I’m at, I can’t justify the fairly steep price. Selfishly, I’d like to see an indie license that does the free if revenue below X thing.

If this doesn’t support Burst - which I imagine it won’t - that may put a bit of a dampener on things.

It’s somewhat embarrassing if this delivers on Unity’s infamous 500ms reload promise which they’re still orders of magnitude away from themselves. Probably the best thing for everybody would be for Unity to buy this out and incorporate it officially.

I’m curious about the “C# compiler integration” - do you mean that you’re using the Roslyn API to create IL patches?

1 Like

Our compiler works the same way as the default compiler used by the Unity Editor. Changing many files is by itself not a problem, dependencies between files are tracked correctly.
So it’ll work as expected, so long as all the edits made are inside functions (currently newly created classes/field require a full recompile. But we’re actively working on implementing support for it).

In our own projects, we have only tested editing code handled by the default C# compiler. I’m not fully aware of all available Burst setting, if there’s a setting to compile using the default C# compiler then Hot Reload will just work.

Feel free to let me know if Burst support is very important to you, we might be able to support it in the future.

Thanks for the feedback, I suspect/hope our upcoming free tier will cover a large part of the use-case for smaller devs/indies. But we’ll definitely re-evaluate after it people had a chance to try the free tier.

Hypothetically speaking, if the free tier isn’t suffficient, would you a larger one-time purchase make more sense for you? eg $200

About the implementation, we have large amounts of self-written compiler code, Roslyn only supports a small subsection of what’s needed. I hope this helps to understand the price point, a massive amount of work and expertise was required to pull this off

I assumed that was intended as more of a demo. 15 reloads per day is a tiny number. The value comes from being able to iterate rapidly like you show in that video, where you do 4 reloads in 30 seconds. I’d burn through the 15 per day in five minutes - it’s essentially useless as far as I can tell. Perhaps I’ve misunderstood the indie license.

A one time purchase would be easier for me to justify, but I probably wouldn’t pay that much at my current size. I can see that the value is easily there for sizeable teams, but at my level I would struggle to justify that - especially if it has lots of caveats around Burst, as most of the logic I would want to tweak ends up in Burst code.

However, if you had a “free if your revenue is below $50k per anum” option, your product would probably become an essential part of my workflow and you’d get my money when my business grows.

Wow okay, that’s incredibly fair with regards to value. I’d urge you to see if you can find a way to get paid by Unity rather than by individual users. They’ve got bags of cash, they know that their iteration times are a painful joke, and 500ms is one of their most famous broken promises. This should be the default Unity experience for everybody.

I’m a little worried by the compatibility of your custom compiler situation. Unity - particularly in Burst and DOTS world - does a lot of custom IL rewriting as part of its compilation pipeline, as well as calling out to the Burst compiler. How much of that is supported by your current process, and how much is reasonably supportable in the future?

2 Likes

$99.99/month for a Plus subscriber for just hot reload when I pay $30/month for the whole Adobe suit, and around $10 for Rider. As much as like the idea of hot reload, the pricing seems a bit overstated and Indie license includes only Unity Personal as far as I can tell. But even then $30 a month for just hot reload is hefty when it doesn’t offer near the value of my other subscriptions, yet costs the same or more.

I guess for massive projects where compile times are actually in minutes; it makes sense financially. But you’re unlikely to attract the indie crowd at this price point and with Unity Personal limitation.

4 Likes

I understand what you mean, if I’d be iterating on something very specific, I’d also use tons of reloads. I had a wrong perception because at the stage in the project where we are now, many our developers get through almost the full day with only 20-30 reloads. But I think it’s quite specific to our workflow, hence the disconnect.

So overall, an unlimited free tier for Unity Personal makes sense to me. We’ll include it one of the next releases!

I hope you guys don’t mind me asking, but at what price would you consider it affordable?

For example, this is Rider’s pricing

  • $14.90/mo ($12.4/mo yearly) for Individuals
  • $41.9/mo ($34.9/mo yearly) for Organizations (Rider charges companies this price regardless of yearly revenue)
3 Likes

One of the devs will have a look and get back to you (pencilbow9)

1 Like

Hey. I can guarantee that our solution has exact compatibility with the default C# compiler. DOTS and
Unity.Jobs work fine, tried it just now.

Burst compiled functions are unfortunately incompatible, edits to a [BurstCompile] function won’t apply, it’ll just be ignored.
Of course you can still edit other functions, even if they’re in the same file or assembly as the burst compiled function. We’ll fix it up so BurstCompile/BurstIgnore attributes are taken into account and give a more descriptive error/warning.

As a quick workaround, you could consider removing the [BurstCompile] attribute in the editor if you need to quickly iterate. Eg you might add a compile flag around the attribute, so that you can easily disable it if you’re working not currently working on performance.

I do understand this is still a hassle. If Unity would grant us access to use the burst compiler, I’m sure we could integrate it seamlessly. But with Unity’s ToS/ Distribution License, I believe we’re not allowed to decompile or modify in the way we’d need to.

As a small aside, I’d love to hear if you have an feedback on the existing asset. In case you do try it out, we should have the permanent free tier before your free trial runs out (7days), so you’ll be able to continue using it.

3 Likes

I’m evaluating it now. I get this error on file change:

[HotReload] Step 3 was not successfull: error CS7038: Failed to emit module ‘Assembly-CSharp’: Changing the version of an assembly reference is not allowed during debugging: ‘Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ changed version to ‘11.0.0.0’.
UnityEngine.Debug:LogWarningFormat (string,object[ ])
SingularityGroup.HotReload.Editor.HotReloadWindow:RegisterWarnings

The file I am changing does not use Newtonsoft.Json. Is there anything I can do to work around this error?

This has great potential, and, in my scenario, it would be worth $30/month. I think the pricing is steep given that it exceeds what I pay to license an accounting system and Unity. But I think it can work because it will save time in the long run. The holdback for me is that I am not going to give up having an attached debugger.

OK, one more question. If directory changes are disabled for this plugin to work, what is the alternative guidance on refreshes? Do I need to refresh the specific file and/or directory when assets are imported?