What I have mostly learned, is that doing something that is fun makes motivation come the easiest , compared to anything else I have ever done in my past. Making a game is probably one of the most fun things I have ever attempted. Doing the work, though apparently harder for most, is the absolute easiest for me. I get at least two hours a day, every day, every week. Doesn’t sound like much, but include a marriage, two toddlers, a few teenagers, four worthless cats and a full time job, ten hours a week is pretty freaking awesome. Jake knows what this is like as well, and the fact we have gotten this far is a true testament to what it means to us. Most can relate, but hopefully we become part of the elite who actually finish projects 
The last post is a to-do list I published about twenty days ago. I have been eating away at it, and am about two thirds done when I realized first, how little I have done, and then, how much I have done. Its amazing what a little optimism can do for your day, and your week, and any project you might be working on.
I am currently working on the inventory controller and realized I have learned a few points in my journey so far, and just wanted to post it. Mainly so I don’t forget, and to help others confirm their own findings.
First off, do not start a part of the project without finishing it. Maybe this seems redundant, and I am sure there will be times in the future where I fear I might get confused coming back, but really, if the script is working 80% or so, and there is a couple things implemented that arn’t working as expected, continuing on with the intention of coming back to fix it is being lazy. Coming back to it costs more energy, and working on other parts with that bug glaring at you is no fun either. Bottom line: Do not add something unless it works. Don’t implement something and then not finish it because it isn’t essential at the moment.
Secondly, fractal the shit out of it. This project could have probably used a better fracturing system, but hey, I got it now. I did a good job of realizing what should have been fractured in the beginning, so it probably won’t become spaghetti down the road. Most of my mistakes come from starting a script with the intention of it only doing x and y , and before I know it, its a thousand lines plus and does about every single function that object could possibly do. Luckily, my ability to do this within a script is on par, but doing it within relating objects needs a bit more work. Practice makes perfect.
Thirdly, the next game I do, I want to start with the soundtrack first. Really, I have no logical reason why, just seems like a good idea LOL!
Fourthly, write tight code from the start. I am not sure why I didn’t plan out how I was going to name things, but part of the problem was I didn’t know how the libraries were names – and I should have, because it is apparently standard naming procedure. Do not save “clean up” for a later step.
