LyRCC - Runtime Compiled Components for Lumberyard

Dear C+±Fellows!

Based on the ideas of Matthew Jack and Doug Binks, we’re currently working on a nice C++ hot-reloading solution for Lumberyard. Version 1.0 is almost done and will be released soon after we’re finished evaluating our distribution options. You can find more information and a demo video about our current progress on our Homepage.

We definitively want to release this Gem to the public for a small fee, so that we can continue improving LyRCC further.

Currently supported features:

  • Live-C+±Coding: Create your own Lumberyard components in C++ while immediately seeing the results in the editor.

  • Play/Pause-Support: Regardless if you’re currently simulating your physical world or not, component changes will always be reflected in the editor.

  • Debugging: Debug your new changes at any time in your IDE of choice.

  • Property-Reflection: Changes to component properties will be automatically reflected in the editor.
    Roadmap:

  • Property-Value-De/Serialization: Currently property values of changed components won’t be saved during recompile.

  • Precompiled-Header Support: To further improve compile times, we want to add support for precompiled header files.

  • Mixed-Configuration-Mode: Compile everything in “Release” or “Profile” mode but leave your own components in “Debug” mode. This way you get the balance between good runtime performance and the flexibility of debugging your components.
    If you want to support us, please subscribe to our newsletter on our Homepage.

We’d love to hear any feedback which LyRCC features you’re missing and really would like to have in your Lumberyard projects!

Thank you very much! :slight_smile:

// Edit:
LyRCC 1.0.0 out now!

We’re happy to announce that we’ve just released the initial version of LyRCC. You’re free to download an evaluation version on our homepage.
Please give us your feedback, so that we can make LyRCC even better!

Great, congratulation for the progress so far getting to 1.0 and to release is always a great achievement.
Still, advice you to ask Lumberyard team for specific distribution options first to take any decision they surely know their users and can put you in the right direction to be successful.
The roadmap is very interesting and really completes the offer.
The only doubt is the kind of release you plan to do:

Source get a big edge here as with an engine in beta and big changes in any version a binary release could potentially break at any time and no one assures us about your capability to update as soon as it happens as it is out of your direct control.Probably a lot of people are not in the position to freeze the engine version in a project as we have many key systems in a preview stage.

Thanks for the explanation.Of course, if your gem can be really enabled and disabled without major code changes in the components in development while you catch up with the API changes the constantly updating environment should be not an issue.

As Uriah said possibly Amazon could be possibly interested in acquiring the source or a variation on that formula.

It will be great if you could come up with an evaluation version too.

@Uriah Do you know that @VitaminCpp team is working on an arcade jet racing game Wings of Revine ? Maybe you can have a chat with them about your flight physics simulation.

Thanks for your advice. We definitively will contact the Lumberyard team directly to ensure we’re on the right way.

Regarding your concerns about source code updates… This is a valid argument, but nothing new in the software industry. Software fortunately evolves rapidly and API changes from time to time. With that in mind, we’ve designed our Gem to be as non intrusive as possible. So as long as the Lumberyard team doesn’t decide to drop their component-entity system, we’re able to fix minor API changes ASAP. If for some reasons we’re not able to release an update soon enough, you’re still be able to simply deactivate our Gem and work on your code base as before. But we can assure you that it’s also in our interest to release updates as soon as possible, because our own Game heavily relies on this Gem.

Anyways thank you very much for your feedback!

This will be a great addition to our development environment. Nice work! I would certainly pay a “small fee”, as the time it will save will pay off fast! Although maybe you could work something out with Lumberyard to ship this Gem with LY by default and they would pay you to maintain it for future versions. Seems like the kind of feature they would be remiss to miss :wink:

Regards,
Uriah

Great news.:wink:

Please give also a look at custom script canvas nodes, they also may benefit a lot from runtime compilation even for skipping editor restarting.

We’ve already contacted Amazon a few days ago, but they seem to be a bit busy at the moment.

Regarding your idea on an evaluation version… We’re currently working on this and we will release a time limited version soon on our homepage.

@Uriah If you’re interested in our project please don’t hesitate to contact us. But don’t be disappointed, because our flight/hover/underwater physics have to be a bit simpler (more arcade style) than the ones in Star Citizen. :slight_smile:

Hi @VitaminCpp, I sent you a message via your website’s contact form. Cheers!

Great work and I second @Uriah about “work something out with Lumberyard to ship this Gem with LY by default” . It would be best.

@TAN Thanks very much! First I would like to close this thread, because we’ve moved LyRCC to the “Completed Projects” thread here.

This indeed would be a reasonable option and we’ve already tried to contact Amazon in October, but since now they didn’t respond.

Heya @VitaminCpp, sorry to hear you haven’t received a response from us :frowning:

If possible, could you please email ly-community (at) amazon (dot) com?

@Amonster_LMBR We’ve already sent an email a month ago… But still… No response! Sorry guys, we try our best to get in contact with Amazon, but it seems like this feature isn’t currently important enough. LUA is nice for some sort of things like UI and that stuff, but I don’t think a game like Star Citizen would be very efficient if they wrote everything in LUA. :wink: