Hi,
Basically...
- Don't over use global variables for everything and anything, this is bad design practice, look up 'Metadata' on the forum, I explain one way of dealing with common variables used throughout a big feature and many fsm.
- Design first, optimize later, make it work, then worry about performances, the other way around is too much pain.
- iterate VERY often, always publish at least once a day if you are full time, missing out a bug for too long is painful to debug.
- use Github or bitbucket ( coupled with SourceTree client) to host your project, it's never a good thing to rely on zips for backups... it sucks, use a proper code repository.
- Cut down your project is small chunks, they must work individually, think of your project as a Human Body. It's made out of very distinct organs, each replaceable, heart can be swapped with a mechanical pump, brain with a computer
skeleton by plastic or else. Apply the same principle to your project: Nature made it so far isn't it? 'Object Oriented Programming' actually was an attempt at simulating Nature when it was designed.
- Don't attempt your dream project on your first attempt, set yourself achievable goals, and reach them patiently ( one by one or in parallel, to change your mind, else you go nuts...)
- Fsm wise, never fear using several Fsm for a single feature, I often resort to three fsm just for a simple character control, one to move, one to rotate, one to jump, so for more complex designe, this will increase, and it's a good thing, divide and conquer approach allows your project to grow better and stay sane.
- ALWAYS NAME ALL YOUR EVENTS, VARIABLES STATES, FSM GAMEOBJECTS. it's critical, describe as much as you can, use colors ( I always use red for error state landing, with a breakpoint, so any error I catch will trigger the debugger).
- Do not fear starting from scratch a feature, it's a lot more productive than trying to fix something badly started. It took me many years to realize this, now I am ok to bin entire chunk of codes or sections, just because I know a better way, and it's needed for the sanity of the project. Trying to fix the unfixable is a waiste of time. Plus you gain practice, as you already know what you want, and so you'll be faster and sharpen your development skills.
- use '/', in your names for events, it helps organizing them in the drop down menus.
- Always ask on the forum if you are not sure, we are here to help, sharing your issues and struggle is beneficial for everyone, you because you get a chance to solve your issue, others will be able to benefit from your struggle and solution, and to the one who provided the solution, it helps being sharpen skills, by having to explain it.
- Higher level project handling will likely require scripting. It's a good thing, you can write editor scripts that increase your workflow, speed up your designs and needs, so as you want to increase the complexity of projects you want to handle, you need to prepare yourself for learning c#, do this by simply looking at PlayMaker actions, just read them, don't try to do one, just try to understand how it's done. One day, you'll have a need for a custom action, ask us, we'll likely provide, and take this opportunity to learn something out of this, and even try to rebuild it yourself, or do a series of custom actions around the one provided ( to cover more of the features you want to control). This process can take up 1 or 2 years, then you are fine with simple coding, and Unity will reward you with the best possible solution you can dream of to realize your vision. Period...
Bye,
Jean