Filler.

I'm afraid that this is more an update of reassurance. Yes, this is still a thing, and yes I'm still working on it. It's just been very short going lately, with a lot of setbacks.

The first major setback was finding out that the vehicle model I spent so much time on was broken. Specifically, some of the meshes had randomly missing faces, so that when rendered in Unity everything looked horrible. Not only did I have to make a new one, but I had to learn a new method to prevent against this happening again. The silver lining is that regardless of how annoying these setbacks are, it forces me to learn and actually gets easier each time. This will be a big help later.

In the interest of time (and perceived progress) I decided to skip designing an entire vehicle and instead opted for the simplest of vehicles; a single tire. No hubcap, no axle, no calipers or discs or anything else; just 1 object that can rotate around 1 axis and move in 1 direction. Simple enough, and exactly the thing I need to start learning to script in Unity.

This offers a new issue though. For all of it's greatness and ease-of-use and compatibility, it's really strange that you don't have direct control over the actual core of the code. If I'm using a standard IDE like VisStudio or Eclipse, you're working with something that's little more than Notepad++*. You type in everything (with some helpful auto-completion), compile, link, build, and run. You write functions, create classes, set up case-switches and if/else conditions and do/while loops. The contrast is that Unity attaches scripts directly to Objects. There is no int main() that governs everything. There's no source files to look at or change. While I had some idea of this before, it never occurred to me how counter-productive it would be. Each object gets a class script that manages how it works, but everything else is done through the ambiguated Unity interface. 


Don't get me wrong though. It's definitely a very clever system. Whenever you attach a script to an object, all of the public declarations are shown in Unity. Want to change a string? There's a text-box right there! Is there a double that you have set to be true only between values X and Y? Not only can you change the number on demand (with safety checks to make sure it's within bounds) but if applicable it gives you a slider for the specified range. These might sound like little things, but I have to appreciate it. It's unobtrusive, automatic, and as far as I can tell it can't screw it up. At worst, it wont bring the values in, which generally means you messed up and have to fix something anyway. 


So, where does this leave things? 


Realizing now that I'm struggling to grasp the basic concepts of what I'm trying to do, I've had to make concessions. The most important is that I broke down and spent money on the project. I'm not thrilled about it, nor do I like making excuses, but it had to be done. I ended up buying 2 books to help me through this. One of this is a reference book for Unity, inside and out. The other is more about game designing in general, encompassing all parts of game making. It sounds a little hokey, but it's actually a good read from a guy who's worked on several recognized titles. I'm not even a quarter-way through the book and it's pointing out a lot more things for me to think about.


The short-term plan is to read the entirety of the second book, the majority of the first book, and then pick up scripting again. By then, I should have a better understanding of this stuff. In the meantime, I'm coming up with a list of details to eventually work out, though I know most are not important right now. 


Also, the official working title for the racer project is now Omniracer. Or possible Omni-Racer.