[note: the “Search” options seems to be broken on the forum, so I don’t know if there is another subjet like this, if there is, please lead me to and I will remove mine. Thank you]
With every new projects I do I can learn a lot of usefull stuff. Most of the time it is part of the learning process and there is no use to blame it but sometime you find a small tool, or a general process you didn’t knew before and would have saved you a lot of time and made your life easier.
I’m not talking about other peoples script or pluggins, but something tied to the editor, such as a specific class (for coders), a component, a process, a menu or an option you didn’t knew about. Something that makes you feel a bit stupid to not try/look at/ask earlier and you use often now.
What I discovered recently are the Scriptable Objects. I knew the class since my first project, but misread the manual and ignored it for many monthes. I didn’t understood their utility first. I had to implement my own alternative in order to find out what they are !
I was looking for some informations on UA, it was talking about making ScriptableObjects, and it helped me understand what the manual didn’t. I made a step back now and use them in my projects !
Did you have similar experiences ?
Please share since there are many self-educated people using Unity who learned the hard way and didn’t have strict guidelines. They may be missing an essential feature because they misunderstood it, or didn’t saw it as priority.
Given the sheer size of the Unity API and engine in general, I think it’s a safe bet to say it happens to every programmer who is constantly fiddling and trying things out, and who is keeping their eyes open while doing so.
Pretty much. Best practices in general are not the easiest to find topics, and it only gets worse if you start getting into the editor where the documentation gets spotty at the best of times. Scriptable objects in particular are an easy thing to overlook until you start butting heads against serialization. Then there is the serialize field attribute which is another gem that just doesn’t get taught when it should be.
The biggest issue I think is that there are a ton of beginner guides and some intermediate, but very little that’s advanced, which is mostly the realm of systems architecture and workflow management.
That the writing level editor that is both powerful enough to make main campaign and easy enough that anyone can use it to make levels post-game (modding community) is HARD, especially with 3D games. But I’m not complaining and will finish it off, then start working on AI, level interpreter (as level will need to be put together) and start cranking content.
5 big level for IndieGoGo, 100 big levels upon release.
If you are designing something to be used internally, it only has to work well enough to account for very basic use-cases. If you are designing a tool that will be available to general users, take however long it would have taken you to make it regularly, and multiply it by five.
I’ve always thought of it as the user-proofing process. Software for internal use doesn’t have to be bullet-proof. You are the one editing it, and the people using it are people you can talk to directly and train. (and you can modify and bug-fix it as you go) Software for general users has to be nigh-invincible, and user-friendly on top of that. This involves SO-MUCH-MORE work that at times it can be staggering. If you release a tool to the community, they will find a way to break it. They will. The only way that they won’t is if you have designed it from the ground up to never break. And we all know how difficult that is.
As more of a front-end and tools developer, this has been a constant challenge for me. I’m always thinking of the end-user, and how they will manage to obliterate my work with some obscure use-case. It’s kind of a love-hate relationship.
I started to make an Editor Interface for my Katagon Procedural IK Combat and Nav system and ran into the Serializable and ScriptableObject stuff yesterday. Still trying to wrap my head around it as my first forays were unsuccessful and what I wanted to do was not close to the tuts on them and as said…the manual just skips right over stuff. So tell me what you know about them and why they are used. I will offer this up in return.
When using Mecanim you want to find out what state you are i and Unity provides a kludge pot methodology. I early on in the first Mecanim betas figured this out. Create two arrays. One is a set of boolean switches. The other is an array of Strings that hold the names of the states you can transition to that matches the indexes of the boolean switches.
var stateSwitches : boolean[];
var stateNames : String[];
function SwitchStates () {
for (var i : int = 0; i < stateSwitches.length; i++) {
if (stateSwitches[i]) {
animator.SetBool(stateNames[i], true);
} else if (!stateSwitches[i]) {
animator.SetBool(stateNames[i], false);
}
}
}
This keeps things nice and tidy… you loop through booleans which are much lighter weight than strings or kludging thru the mess Unity offers for finding state names and their state…and only one state can be active at a time in the Animator and you can see it in the Inspector.
Getting my head around coroutines was a big aha moment for me.
The other was a bit more of a concept, rather then a specific class. Learning to code via “black magic”. Put in technical terms its something like “You don’t need to understand the specific implementation of a class in order to utilise it”. It sounds obvious now, but there was a lot of stuff I avoided using early on because I didn’t understand it in detail.
For me it was the Marketing of the game pre release. Im a one man band like most and tend to work alone until the thing is complete… Im working on changing that.
Involve the right people as early as possible or as soon as you have a playable fun concept. Not only will it help spread the word early but it will let you know if it sucks and what needs changing/tweaking.
That the biggie for me. Im still learning every minute.
We made this error on our first project, we didn’t have any community, didn’t talked to anyone. But feedbacks help a lot, anyone should build its community alongside building its project.
