Code; it's a beautiful thing. I've been thinking a lot about user-friendly interfaces and making the scripts easy for the end-user to implement, and stumbled upon EditorGUILayouts. These are just parts of Editor based scripts which allow the customization of Inspector Elements.
So, to create a highly customizable script and set of interfaces for the end-user, I've created an editor script that coincides with my playerControl Script. The outcome of which can be seen below.
Now, the Editor script essentially organizes my variables in a fashion that is incredibly explanatory; rather than just being greeted by a list with which the end-user has no clue as to the function.
The actual playerControl script is very simple, and will have extended function very soon in regards to fluctuation in _heartRate, _respirationRate and _coreTemperature.
The playerControlEditor script is a little more complex, and took a little research to get right; but I am very happy with the results. Ease of use for the end-user is key in a project such as this, the script can be seen below.
The scripts are still very much a work in progress, as the project continues it will become a lot more advanced. So far though, I am happy with the results.
It's a good start to enhancing the usability of the library, though I'd be careful with putting in hard coded "default" values in the strings, it's just something extra you have to remember to maintain if you make any changes to them in the future. I'm not sure if there's a way you could pull the default values of the variables your setting to build into the string, but it would be worth looking into at least.
ReplyDeleteI'd also write a function that contains the repeated EditorGUILayout elements that takes in the dynamic elements (so the variables to look at, the min / max values and the strings). Even better if you can get the strings pulled in from elsewhere (either XML or an array held at the top of the file) to save you hunting through chunks of code if something changes and you need to update the written elements.
As you said, even with the descriptive text, a written manual would also prove useful. Because you're writing a library / API, it will certainly be worth using something that can generate code documentation for you from comments. Take a look at YUIDoc (http://yui.github.io/yuidoc/) for UnityScript and something like DoxyGen (http://www.stack.nl/~dimitri/doxygen/) for C#. It requires writing technical comments in specific ways (irritatingly, both YUIDoc and DoxyGen use slightly different syntax for their comment system) but it will take out a lot of effort when it comes to writing the documentation, especially if you maintain the technical commentary correctly as you work on the system.