I’m excited to announce the release of my Observed Unity asset, a collection of scripts that allows you to easily create and use observable variables, collections, and dictionaries in your projects. Observed is a powerful tool for tracking changes in your system and responding to them in real time, making it easier to create dynamic and reactive systems.
The Observed asset is well tested, with over 100 unit tests covering a variety of scenarios and conditions to ensure its reliability and robustness. You can trust that the observable variables and collections in the Observed asset will perform consistently and smoothly in your Unity projects.
Observed variables, or Observed, are variables that can notify subscribers when their value changes. This can be useful in game development for tracking and responding to changes in various game states or variables.
ObservedCollection is a collection that can notify subscribers when its contents change, allowing you to track changes to the collection and respond to them in your code.
ObservedDictionary is a class that allows users to subscribe to changes made to the dictionary.
ObservedQueue is a queue that can notify subscribers when its contents change, allowing you to track changes to the queue and respond to them in your code.
ObservedSet is a set that can notify subscribers when its contents change, allowing you to track changes to the set and respond to them in your code.
ObservedHashSet extends the .NET System.Collections.Generic.HashSet class and adds the ability to notify subscribers when the set is modified.
And many more! Check out the online documentation.
Both of your tools sound interesting, but that you compiled the code for these simple tools into a DLL is not to my liking. Why hide the code for something that is a relatively straightforward editor tool?
It cannot be copy protection because I could simply decompile the DLL and output it as human-readable C# source code with a tool like Rider with a few clicks. Unless of course the DLL is obfuscated, but then I’d question why to go such great length all the while crippling the asset?
Because assets like these are tremendously devalued if I cannot just change the code on a whim’s notice. There’s ALWAYS something not quite to my liking or needs to be improved/fixed in some way, so that I personally do not buy assets that needlessly hide their code in a DLL.
Thank you for your feedback. I understand that some users may prefer to have access to the source code in order to modify it to meet their specific needs. The main reasons for compiling the code into a DLL are to protect intellectual property and improve performance and security, I’m open to considering alternative solutions that could meet the needs of users.
As an alternative to modifying the source code, you may also be able to extend the classes provided by the Observed asset in order to customize their behavior to meet your specific needs. By subclassing the classes and adding your own methods and properties, you can add additional functionality without modifying the original code.
It’s important to note that if you do choose to modify the source code and run into problems as a result, we may not be able to provide support or assistance in troubleshooting the issue, as we will not have visibility into the changes that you have made. If you have any specific suggestions for how the asset could be improved, I would be happy to consider them.
Please don’t hesitate to reach out to me with any feedback or suggestions.
A DLL does provide some level of intellectual property protection, as it makes it more difficult for others to access and view the source code.
That being said, I understand the value of being able to access and view the source code, and I plan on releasing a source version of the asset in the near future for those who may be interested. In addition to releasing the source version, I will also be adding more Observable classes to the asset, including ObservedQueue, ObservedSet, ObservedSortedSet, and ObservedStack. I will also be adding unit tests for all of these classes to ensure that they are working correctly. Let me know if you have any questions about this.
Please note that it may take up to 30 days for the source version to be released, as the review process can be time-consuming
The added difficulty isn‘t actually there. As with any code, I just click on „Go to implementation/definition“ and I see the code as is, be it a source file or part of a .NET DLL.
The only thing the DLL adds to the process is a minimal decompilation overhead for the first access, and slightly more clicks to decompile and save the entire DLL code to files. Anyone who you might rather not to see your code knows how to do this.
I am happy to announce the addition of several new classes to the Observed Unity asset in an upcoming update. These classes include:
ObservedBinaryFile: This class allows you to create an observed variable that represents a binary file on disk. You can use it to track changes to the file and respond to them in your code.
ObservedBitArray: This class allows you to create an observed variable that represents an array of bits. It can be useful for scenarios where you need to track changes to a sequence of binary values.
ObservedHashSet: This class extends the .NET System.Collections.Generic.HashSet class and adds the ability to notify subscribers when the set is modified.
ObservedLinkedList: This class allows you to create an observed variable that represents a linked list. It can be useful for scenarios where you need to track changes to a list of items and maintain references to both the head and tail of the list.
ObservedQueue: This class allows you to create an observed variable that represents a queue. It can be useful for tasks such as managing the order in which units move in a turn-based game or processing events in the order that they are received.
ObservedSet: This class allows you to create an observed variable that represents a set. It can be useful for situations where uniqueness is important, such as tracking unique items in an inventory or unique player IDs in a multiplayer game.
ObservedSortedDictionary: This class allows you to create an observed variable that represents a sorted dictionary. It can be useful for scenarios where you need to track changes to a dictionary and maintain the elements in a sorted order.
ObservedSortedList: This class allows you to create an observed variable that represents a sorted list. It can be useful for scenarios where you need to track changes to a list and maintain the elements in a sorted order.
ObservedSortedSet: This class allows you to create an observed variable that represents a sorted set. It can be useful for situations where uniqueness is important and you need to maintain the elements in a sorted order, such as tracking unique items in an inventory or unique player IDs in a multiplayer game.
ObservedTextFile: This class allows you to create an observed variable that represents a text file on disk. You can use it to track changes to the file and respond to them in your code.
IndexedObservedCollection: This is a class that allows you to create an observed collection where subscribers also get information about the index of the changed element. It is similar to ObservableCollection, but provides additional information that can be useful in certain scenarios.
These new classes join the other classes in the Observed asset, which allows you to easily create observable variables, observable collections, and observable dictionaries in your Unity projects.
I’ve put a great deal of effort into ensuring the reliability and robustness of the all the Observed classes, now there are over 100 test cases covering a variety of scenarios and conditions. I’m always working to improve the Observed asset and adding new features that can help make your Unity development experience better. I hope these new classes will be useful to you in your projects.
I concur, it doesn’t make sense to provide this as a dll, anybody will use .net or Rider to inspect the code and it is just adding a layer that interferes with faster and iterative development. Imagine I have to do a major change on it then I would need to decompile it entirely and import it as the source. So what exactly is the developer trying to prevent? Intellectual property or fast and iterative development? Because it only effectively impacts the later.
As mentioned previously, it is possible to modify the original code without the source code by utilizing techniques such as extension methods and inheritance. If you are unsure of how to do this, I am more than happy to assist you in learning these techniques. This is a common practice when working with standard C# classes in Unity, which are also typically provided as assemblies. Additionally, many of the methods in this asset are marked as virtual, allowing for further customization even without access to the source code.
For those who still prefer to have the source code, I will still be releasing a source code version of this asset. It should be released in 1-2 weeks.
Good news! I’ve updated the GitBook documentation with some amazing new content - Use Cases! These pages provide concrete examples of how to utilize the asset in your Unity game development projects.
These examples aim to assist you in making the most of this asset, regardless of whether you’re a beginner or an experienced developer.
If you haven’t already, head over to the GitBook page now to check out the new Use Cases pages. They’re sure to provide valuable insights for your Unity game development projects.
If you have already purchased the non-source version, but are interested in upgrading to the source version, I would be more than happy to assist you. Simply send me an email with your receipt for the non-source version and the source version and I will issue you a refund.
This looks cool that I’m considering using with uNode. Appreciate that there’s a source code version available. Appreciate that there’s users who may want to use it as an end user and not a power user, and support becomes more involved with source code (and risk).