Unity Game Authoring Engine

A short time ago, WaltVader was telling me he picked up a book for the Unity game engine and had started going through it, one step at a time. I like to blame myself because I posted something to that effect in some other thread somewhere, that whole step-by-step theory. I haven't heard very recently if DarthDisney is still plugging away, or if time has kidney-punched his motivations, BUT... more recent than his book, I happened upon a small bundle of ebooks, one of which is a Unity book, and works nicely on my tablet, allowing me to read "over there" and type "over here." Since that post about the floor drain, and our ideas about USING size to alter a game's design, I've been pondering.

So, I'm thinking this could be a good way to record and share notes, tips, and tricks we might pick up from our own attempts at learning. I know Vader's book is a walkthrough of creating a first person shooter, so maybe he takes some code from the book and makes a tweak or two, and creates the most amazing left/right head bob effect for a running character. He could post his code here... just as an example.

To start sharing my learning process, I have to say the woman who wrote the book I have is DAMN long-winded! Worse than me!!! I just hit page 96, which is chapter 3, which is the chapter that starts teaching scripting. The first chapter is a DETAILED history of the adventure game, including companies, games, why adventure games became unpopular, what fans of the genre look for, why adventures games are gaining popularity again... the first chapter was torture! The second chapter was a walkthrough of Unity's GUI (user interface). I've done it before, but trying to stay true to this process, and hoping I would learn a trick or two, I read every page and snippet, followed every command, tweaked my UI exactly as the author suggested, and didn't really learn anything new... but I did it! Oh, chapter 2 also explained to me what a 3D mesh is, and what kinds of parts make it up, and what textures are... sigh. Now it's on to scripting...

Oh, in case it wasn't obvious, the book I have is a step-by-step for creating a first person adventure game. During the last conversation with Vader, I didn't know if they meant like a real-time running around first person, or something like a Riven or Myst pre-rendered point-n-click. I can now happily report that I will learn to allow my players to freely explore a 3D world using the WASD or arrows keys, and the mouse to look around. I will give players the ability to click on objects in view, and get a response, or manipulate the objects, or pick the items up and place them in an inventory. The players will also be able to open said inventory, and manipulate objects inside the inventory, to combine them, open them, break them, ETC... Sounds like exactly what I was hoping for! So... now to see if the scripting kills me. But like the author says, Unity comes with most of the most useful scripts out there, and supposedly all you really need is knowledge of where to put them and tweak them for your own purposes. So... maybe...

Wowee! I found something neat already! Not from a full script point of view, but from a single piece of code. The chapter on scripting starts with making a REAL simple script with only one line. I was happy to find the intro to code wasn't a "load this premade script and change these numbers to see what happens." Anyway, as chapter 2 finished, I was left with a cube in the middle of my main viewport... yay! The code starts with a simple line used to rotate the cube 5 degrees on its Y axis every computer frame. No big deal. The book goes on to explain how the rotation is based on frames, so the frame rates of individual computers will affect the speed of rotation. Makes sense.

In order to make the rotations consistent across different systems, they then show an addition to the code, in the form of a pre-packaged variable called 'Time.deltaTime'. By multiplying the amount of degrees by this deltaTime variable, it makes the cube (or anything else), transform by that many increments every second. The book explains how this is good to make our cube rotate at the same speed on any person's computer. Great. MY first thought was this is how easy it would be to make a simple 3D clock, or anything that needs to rotate to time... which may not sound very exciting unless you think about 3D clock apps for Android or iOS!!! Make the 3D objects, set the hands to rotate x many degrees per second, and BAM... instant clock!

I *cough cough* finished my graphics monthly challenge in the graphics forum I frequent, and have sunk back into Unity a bit. Grand designs require grand learning! Earlier, Vader and I were discussing 3D modeling from a gamemaker's perspective, in regards to Unity. I wanted to share some options for not having to model too much by oneself.

As I'm sure Vader is well aware, Unity has within its walls a Unity Store. There are many models, sounds, textures... game elements... made by fellow peoples. Some are free. Some cost money. Some come with scripts! I've never seen anything WAY too expensive considering the time put into it, and if you find "just the right shotgun," it could be worth dropping $20 or whatever as you can use it in any future game. So, Unity Store is a viable option.

Also, I've always had decent luck with TurboSquid. Free sign up, and it works like a store, even for the free stuff. If you find something you want, it goes into a cart, and from there you download (after purchase if needed). This place is just models and textures, but they have a bit of everything you could want. However, I don't remember what 3D formats Unity can use, and Turbosquid has them all, so that's another thing to keep an eye out for. You have to remember, these are models, and you will probably have to tweak texture UV maps, geometry origins, things like that, to get them to work in Unity. Still, it's possible to find many models FREE.

And another option, available to a select few, is to ask me for something specific. I will let you know if the model is within the scope of my abilities. Here's my thinking: I'm not going to offer up any team efforts in Unity, as I believe that would defeat our purposes at this point... BUT, as long as peops are okay with sharing a model between a few game designs, then why not? I mean, if someone needs a low-poly roll-top desk, I make it, but I reserve the right to use the item in my own works. Actually, that's the way it is with Unity and TurboSquid, but at least with my models there will be a VERY limited access to them. Not only that, but I will make sure before delivery that the model imports into Unity AND the textures work properly! Something to think about... as building a collection of models would only be beneficial in the long run anyway!

Page 180-195 in the Unity book I have. I just got done learning many of the features of the terrain creator and its various tools, and thus I have a nice looking test terrain. The next step was loading up a pre-made object/script to enable walking around in my custom terrain. I should point out to any purists out there that, even in a "pro" game for commercial purposes, using these Unity prefabs is acceptable, as that is the design of Unity, and the prefabs added so you can run a game "right out of the box."

So, WASD to move forwards and back and strafe. Mouse to look up/down and turn. Space to jump. Stock controls, and pretty well scripted. It 'felt' good, and I spent a few minutes just running and jumping through my forest valley. Then the author starts talking about the variables and programming involved with the prefab first person controller. Variables for changing speeds and jump heights without having to go in and edit the script. YAY! So far, it's all making sense.

And then the author and I have a massive difference of opinion on 3D first person adventure games. First, she says we NEED to shut off MouseLook, so the mouse will not alter the camera view. Then, Unity is defaulted to allow WASD and the arrow keys. Well, we need to shut off the arrow keys as alternates for WASD. I started getting a little WTF'd here, and skipped ahead a bit to see what the author is trying to accomplish. Oh. WASD for forward/back and strafing. Arrow keys to replace MouseLook. And that leaves us with a free mouse cursor to click on things in our view window! OH! Great fun! It all makes sense now! Because when was the last time YOU had to use TWO sets of keys to move and change your veiw?! 1995?! WTF is she thinking?!

So now the conundrum... do I keep going step by step through the 700+ pages of book, following her every instruction, to learn to make a demo game that is NOT even close to the adventure game I want? Or do I leave my controls alone and skip ahead to the point where I can make an inventory and pick objects up? Because, if done properly (read as: post-90s), you should be able to WASD around, MouseLook in a 360 degree view, and whatever you put your crosshair on should be clickable! That's only how...oh... EVERY GAME does it now! Maybe I will skip ahead and skim the sections on picking up and inventory, and see if I NEED any particular thing she shows before that. At least I found where to download the book assets.

Still... that WASD+arrows+mouse would SERIOUSLY piss me off... playing it OR making others play with it!

Shadowcrunch wrote:

OH! Great fun! It all makes sense now! Because when was the last time YOU had to use TWO sets of keys to move and change your veiw?! 1995?! WTF is she thinking?!

That made me smile!

I did not skip forward far enough the first time. After shutting off some of the controls and disabling MouseLook, the author then wants us to turn MouseLook back on only when the right mouse button is pressed. That makes more sense, but it still requires the player to either be super ambidextrous, or grow a third hand. I know I have played games like that, either with holding a button down for MouseLook, or having it switch on/off with a particular key. It works, but it sucks.

Going back through what I've learned, I understand the author's motivation. In the first chapter, when she blathers on and on about the history of adventure games, she explains that adventure games are a niche market, and mostly played by the casual gamer. In her logic, that means most adventure game players can't handle the fast-paced controls of the first person shooter, and many of them get frustrated when forced to use WASD. Most of these gamers, in her experience, come from the online flash game background where everything is point and click.

That also makes sense... except... what decade is she making games for?! In MY limited experience, every game since 2005, with the exception of a couple oddballs, uses WASD and the mouse for MouseLook! If she's worried about casual gamers having issues with WASD, does it really make sense to force them to use two sets of keys for movement? Or telling them if they want to look around, they have to hold a mouse button down? If the goal is to make sure new adventure gamers do NOT get frustrated at the controls, the controls should be as simple as possible!

I'm not skipping the chapter, but I am altering the controls...

Just looking at the site for the Unreal Engine, which has recently released version 4 of their engine and UDK. There's a "showcase" of games made with Unreal Engine 3, and a couple made with #2. Just throwing it out there... the Unreal engine is responsible for some of the damn pertiest games I've ever seen! Hell, even going back to the original Unreal and the opening fly-around of the castle on Na Pali... just amazing looking. Not going to start the argument between Unreal and Quake 2 right now, but the list of games on this page should prove the sheer awesomeness and longevity of the Unreal Engine. I bow to them and thank them for years of beautiful graphic worlds.

If I knew anything about C++... sigh... back to Unity...

Taking a short break and getting a little disgruntled with Unity AND Unreal. First, I grew tired of following Ms. Whatsherface and her mad scientist control schemes, so I wanted to test what I've learned combined with what I already knew. I started a new project in Unity, opened Blender, modeled two rooms and a hallway joining them, textured them, baked the textures, imported it all into Unity, added the First Person Controller, and started running back and forth between my rooms. Total time from new project? About 10 minutes. Nice. Went back into Blender, made a door object, imported into Unity and placed it. Uh oh... time to jump into the Unity Asset store and look for a door script!...

Right on the front page: "Hot" and "New" scripts, objects, stuff. What the hell is this neat looking "uScript"??? Visual scripting? Huh? Here's a link direct to the site, so you can bypass the Unity store: Detox Studios Doesn't that look like a neat way to script?!

Enter a video I was watching earlier about the Unreal Engine version 4 and it's new "Kismet" feature. If you want, fast forward to about 1:20 and watch Kismet.


Funny, it looks a lot like the uScript thing for Unity! So why the disgruntledness for both Unity and Unreal? Unity costs $1500 for the full Pro version, plus this uScript is being sold for $95... Unreal has you fill out an application and they will contact you for qualifications because they only give commercial licenses to experienced game makers, but at last search, licensing Unreal is $10,000+. So why are both of these uber game engines only NOW incorporating technology that looks a LOT like Blender's logic bricks, which Blender had FREE going back almost 4 years?!

I swear... Blender has got its shit together. I mean, barely knowing anything going in, I was able to piece together most of that old die roller without serious hair pulling, and I have those logic bricks to thank for it! If Blender could export to a flash or unity file, it would still be a one-stop even for game making! It doesn't change anything... I must still plug away with Unity if I want to have any game project see the light of day, but these guys should start realizing their prices are kindof silly when there's a free program that can do most of what they're offering... just saying...

You know, scripting is frustrating. That's probably why not everyone does it. So far, this Unity book I'm going through has been doing a decent job of making me NOT frustrated. Then I hit that section with the controls, and having to hold down the right mouse button to get mouselook to work... and using two different sets of keys for movement. The latest?

Well, I skipped ahead a bit, just because. Next the author-chick has us make platforms as a reward for getting through the movement scripts. YES! We make an elevator. Okay, sure, I can see that. Then, she shows us how to use invisible planes above our heads to keep the player from jumping over the confines of the game area. Um... might be important, but I'm thinking probably not in an adventure game. THEN, an entire chapter devoted to importing custom cursors, and making the cursor change color when you hover over an object with the right script attached to it (like a clickable object). Okay, that makes sense too... IF the game maker wants to use the ridiculous control scheme cooked up in Dumbestcontrolschemeland!

It's real simple... I want WASD to move, mouse to turn the view. I want a crosshair (even a damn circle), and I want clickable objects to highlight (glow) when I hover over them WITH the above mentioned crosshair. Every recent first person adventure game I've played uses that, and it works GOOD! Why make it harder for the player? Seriously! So... the frustrating script starts getting easier to follow, and then the frustration returns when I realize the "teacher" is going in a completely different direction, and is basing everything on each step that I don't want to take. I'm almost at the point where I think going forward with this particular book would actually be setting me back.... sigh...

Best bet is to just shut up and follow instructions... make it "right" later...

The next time we see each other, I'll give you a copy of the Lynda.com Unity cd's that I have. I also have another disc with a poop-ton of useful stuff!!

I'd really like to add a solution to your situation, but as of yet, I can not. The book I'm using, which focuses on first person, has a section about the collision detection from the point of the player, not reticle/cursor/whatever with a click of a key/mouse/both....

functio OnTriggerEnter(col : Collider) {
if(col.gameObject.tag == "Player") {
col.gameObject.SendMessage("[text input}");
Destroy (gameobject) ;
}
}


This just tells Unity to destroy the game object when the 'player' and object take up the same space, -OR- if the 'player' enters the script activation area of the object. What would commonly follow would be the addition of item into inventory, but I'm not that far yet.

So I resign myself to following instructions, and making a ridiculous control scheme, just for the sake of learning. If anything, it will further my understanding of the character controller scripts. Do this, do that, change these settings, duplicate and rename this file, assign it to the controller, playtest and check the console for your new functions... "The class defined in script file named 'FPAdventurerInputController.js' does not match the file name!" W....T....F...

Reload my scene saved before I started this nonsense. Redo it all, rereading EVERY little instruction to see what I missed. Ah... I spelled a word wrong! FIX. "The class defined in script file named 'FPAdventurerInputController.js' does not match the file name!" OMFG.....

So now I'm on the web, and I found the author's "official" site for her book, with a handy link for her having an official thread to discuss the book on the Unity forums. I wonder, can I carry over some of our custom smileys to the Unity forums?

"Hey author! , "

Does the forum validate her book as being a worthy source of information?

Oh you dirty, dirty bitches! So, the author (Sue something, going by '3D Junkie' on the Unity forums, so su3d from now on) has her official thread about her book on the Unity forums. The first page is an intro, and one particular gent explaining how the book is helping him so so much... also tells when and where the asset package became downloadable. The second page is another gent complaining that the package download did not work, and several people try to get to the bottom of it. Page 3 involves gent#1 talking about how great chapter 4 was (the terrain chapter), then page 4 the same gent is talking about chapter 7. I need chapter 5!

I searched the forum, AND google, and got jack and shit. So I went back ONE more freaking time into the document, and my script file. And I set about reopening the script from the drive, and that's when I noticed it... su3d tells the reader to duplicate the 'FPSInputContoller.js' and rename it 'FPAdventurerInputController.js.' The js is for javascript. The GUI view I'm using (following HER instructions...) only allows me to see some of the text box, so when I click it and rename it, I type in 'FPAdventurerInputController.js'... and unbeknownst to me, because it's a friggin java script, Unity automatically gives it a '.js' extension! SO... my error involved me trying to use 'FPAdventurerInputController.js.js'!!!! SONUVA!!!!

Again, doing exactly as she tells me! Like in chapter four when she tells me to do... whatever the hell it was... just like in picture #whatever, and picture #whatever was actually showing the step she covered like 10 pages earlier. I don't know if it's her, her editor, or her publisher... I'm just lucky I already have a grasp of some of this or this book would kick my ass! I wonder how many blank-slate beginners got this book and quit after the first few edit uh-ohs! So, to anyone learning Unity, '.js.js' does NOT work!!! That's my tip for the day.

VaderXanth wrote:

Does the forum validate her book as being a worthy source of information?

The few people I was reading posts from all agree that her approach to scripting is helpful and easy to follow. They also agree her handling of the information is straightforward and well presented. For the most part, I also agree, as I keep plugging away despite all the stupid little mistakes and the eventual frustrations. One person in the forum even explained that the scripting is so well explained, he/she is skipping the level stuff, and just applying the mechanics to his/her own levels and objects as they go, making their own game using the book instead of making the author's sample game.

The author is active in her thread, and even mentions emailing people fixes for changes in Unity with newer versions. She also mentions that later in the thread she will be updating many book chunks of code so she doesn't have to answer everybody individually. As I said, maybe it's not her... maybe it's the editor or publisher (she did state that she wanted to add more to the book but the publisher was rushing her to close the project).

All in all, the learning isn't bad or extremely difficult. My frustration mostly comes from knowing I'm building something I will not want, but on the plus side hopefully I'm learning to build what I DO want. And my posts are whiny and complainy, but hopefully someone can learn from them (except the ones of me bitching about the control schemes ).

All that bitching about the author's idiotic control scheme... I feel like a right dipshit now.

I just finished the chapter on scripting the controls, and she made it a lot better than I thought she was going to! Get this... WHILE using WASD to move around, MouseLook works flawlessly. As soon as you stop moving, MouseLook automatically shuts off, and you can suddenly move the mouse cursor around your screen, OR even if you're not moving, you can still mouselook by holding down the right mouse button! Now, think about that in terms of a 3D adventure game, and/or a 3D seek-n-find, and that's a pretty damn neat control system!!! I will now officially stop doubting this Sue woman person and follow her instructions... though I still have to change one item in the control scheme, but that's just gravy by this point!

SO... looking at how POSSIBLE this seems now, and looking forward at my own designs, a question for Vader! (OMG that just gave me an idea...) Anyway, since your Unity book is more FPS action-shooting-running-enemies, do you know offhand if there's a chapter or section on basic AI scripting?! I mean, with my subject matter I COULD fake it with scripted events, but even some simple AI would make things more interesting and easier to carry over into future projects. If you don't have AI in your book, I'm thinking we will both be needing some toots or something down the road...

There is nothing about scripting AIs... (and so far, I'm kind of happy that there isn't)

Well, AI is down the road a bit for either of us. More of a catching-up topic... have you covered lightmapping? If so, did yours work?!

I followed the instructions to the letter, and the actual process is automatic, so it's not like I screwed up some script or something. Near as I can tell, it's the only way to get environment shadows in the free version, so it would be damn handy if it worked! Mine made the lightmap, and I can see the 2D thumbnail "texture" of the shadow maps, but I do NOT get shadows under my trees/rocks/bushes. This was like 2 chapters ago, and I'm NOW suddenly wondering what gives...

So in that other graphical forum I frequent, aside from the monthly render challenge, one of the gents challenged the admin to do some modeling of everyday items (MOST of the peops on said forum are long-time Poser users, with little modeling aside from Poser clothes... though MOST have had successful online shops selling said Poser clothes and props and such). One of the other members also did the first challenge, and said it would be nice if more people got involved, so I did. I found out a lot, but that's a different story. The latest challenge was a cordless drill, and since I'm working with Unity I used the challenge to see if I could model a low-poly that kind of looked like a drill. Everyone agreed it worked. The challenge requires a screenshot of the wireframe, and a render... so to validate my model, I used a screenshot from "in-game" in Unity, and there was much rejoicing. I told Vader I would post the drill OBJECT on here when I had textures.

Textures are great, but to really give a game object some OOMF without going high-rez, we use a texture mapping technique called "normal mapping". Normals are the direction an object's individual polygons are facing. Normal mapping takes these directions and applies them to a 2D image that can then be applied to the object to fake details. It is primarily used with sculpting a multi-resolution copy of the model. Basically, you get so many polygons involved, you can digitally sculpt the model like it's a piece of clay. Once you get all the little details, you create a normal map from it, and the colors used in the normal map represent data like depth/height, lighting, and normals directions for all of the new polygons. When you apply this normal map to your original low-poly model, it fakes all of those tiny details at render time, for a fraction of the processing cost!

I fought for quite some time to create a normal map in Blender, and when I finally got it right, I lost my texture and normal maps to a Blender not responding error. Yesterday I started the next chapter in the Unity book, which is importing other peoples' assets, and adjusting textures. Wouldn't you know it? Unity can take a simple grayscale bump map (another OLDER faking technique) and convert it into a normal map FOR YOU! SONUVA!!! BUT... I can see there's still lots of tweaking to be done. My Blender-created normal map looks much smoother, but it still wasn't supposed to make "height details" out of the object's edges, and it did. Just to test the new information, I took my normal map into GIMP, turned it into a grayscale, and allowed Unity to revert it back to a normal map. I have two images here, both from "in-game" in Unity. The first is my drill (have NOT finished texturing, as I was concentrating on normals) with my normal map applied. The second is the same scene, angle, lighting, everything, but with the Unity-generated normal map. Notice in the first image, the details are very subtle and smooth.


And in the second, they are a bit too much! But there's ways to tweak the bumpiness of normal maps in Unity, so maybe this IS the more efficient way to do it...

So, here's an added bonus to what's going on in the Unity book I'm learning from. Remember when I was having issues with the control scheme, so I was digging through the author's official Unity forum? Vader asked if other readers were giving her kudos or not? You know, a few posts back? Well, one of the other readers going through pretty much the same way I am had dropped an "oh by the way..." post around page 4 or 5, just to give a special thumbs up to the author for the generic way she's handling script building. He mentioned that many of the author's scripts would be usable for other game genres without any retooling.

That didn't sink in until two days ago. I am currently working on the chapter about importing other peoples' objects (meshes), and how to activate them (using "my" control scheme) IF the imported objects have animations. The examples I'm working with involve turning a key in a lock to open a chest lid, moving a rock to find said key, and making a flower "revive". All fine and wonderful.

Had a moment of frustration with a bit of the code, or rather how she was explaining it, so it was back to her forum and searching for the damn flower... then digging through individual posts looking for anyone with the same problem. I figured it out eventually (by myself... nothing in the forum), and I came across the post about the kudos for generic scripts again. And THAT'S when it hit me.

The author, in her wisdom, and confusion-making, has given us (mankind) a book and a SYSTEM... a MECHANIC. Hell, it's almost a game engine within a game engine! By the time I'm done with this chapter (and whatever chapter handles "states"), I will have small generic scripts usable for anything down the road! Lemme explain...

The author could have said "okay, let's make a script for the chest lid to open. Now let's make a script for the key to turn." And the reader would learn how to script each animated object they create or import. Okay, that's cool. BUT, what the author decided to give instead is an activation script. You make the script once, then every time you make or import an object that has animation, you drag the script onto the object and BOOM.

These ten objects each need a script to allow them to be picked up? Screw that, one script that self-detects the object it's on, and automatically updates the individual script for that object. Drag it on each of the ten objects... BOOM.

So what? So the author says as you go through, these scripts are YOURS (and mine) since I'm the one typing them in (and troubleshooting them when she screws up). Even for commercial purposes. So? So, somebody is working on an FPS, and needs a quick script to activate a door opening animation... instead of scripting each door, I have the "all door script!" Someone wants to make an RTS, and would have to make a script allowing each unit to be selectable with the mouse? I have the "all objects pickable on mouse down" script, which could then be amended to include selection.

The author may have minor issues, but she's human, so okay. But she's also giving the reader the ability to reuse every little scrap of what she's teaching AND giving! Kudos to her!!!

Fuck me running! I just read something in the Unity book that made me go all philosophical. I have started the chapter about states (conditions). Like, a door can maybe have 3 states: locked, closed, open. Currently, the author is trying to explain with flowcharts how those three states on a game door get very confusing when you include the key to unlock the door... like will you have a state to allow the key to lock the door when it's open? Will you be able to take the key back out and put it in your inventory? A simple three state door with one key can quickly become a script involving 7 or 8 states (in her example).

Anyway, she writes:
"If your head is hurting right now, you aren't alone. Just for fun, try to explain in detail the steps needed to get to the other side of a closed door...to an alien being...who has tentacles. Now you need to specify all kinds of actions and objects that you regularly take for granted. Your brain manages logic sequences all the time without your even being aware of it."

So, even taking away the alien for now, if you actually stop and think about life... if you HAD to think through EACH step (not breathing or heart beat or that crap)...
1. The door is closed.
2. What type of device closes it? Knob? Lever?
3. Is the device locked?
4. Do I have a key?
5. Turn the knob.
6. Do I push the door? Or pull?
7. There is no door... WHOA...

Good gravy! There would NEVER be any time for ANY other thought!!! Pretty sure we wouldn't be able to think fast enough to drive a vehicle. Walking and chewing gum at the same time would be difficult for everybody, not just Soothsayer! And speaking of... if we add the tentacled alien back into the equation, I choose not to open the door cuz lord knows what Sooth's doing with the alien all Hentai-style!

For anyone who might get their hands on the Unity book I'm using, just to cut down on your hunting, I am dropping links to the author's official Unity forum FOR the book, and the location for downloading the HUGE book assets ZIP file. Part of the reason I include the forum is there were several posts where people had issues downloading the ZIP file for unknown reasons, and there's some advice for if that happens.

So, the forum is at: http://forum.unity3d.com/threads/93775-Beginning-3D-Game-Development-with-Unity

And the asset downloads: http://www.apress.com/9781430234227 (scroll down under the "related titles")

On the graphics forum I frequent, the monthly challenge for December is 'Things With Wings.' Luckily, the challenges are open to all art forms, and they are accepting (even encouraging!) about me using the challenges to further my understanding and abilities with Unity! So, to that end, a little Blender modeling and animation, imported into Unity and operated on with the scripts I'm learning in the book, and we have a Thing with wings!

The first few seconds of the video is me clicking objects the author includes to teach things. It's after I turn a good 90 degrees to starboard that things start to go "all me custom." The video and animation are a bit choppy, but that's because my video capture software working WITH Unity ate my system resources up BAD!

That said, here we go!

If anyone is going through Sue Blackman's book 'Beginning 3D Game Development with Unity' and you're using Unity 3.4 or higher, THIS IS IMPORTANT!!!

Throughout the entire book, every script you write contains variables of two types: var and private var. A regular var is visible in the inspector view, and changeable during runtime by way of the inspector view, it is also visible to the rest of the project. A private var is hidden from the inspector view, and is not accessible to change without editing the script itself. Sue has you use private var for any definitions that shouldn't be changed by anyone during game editing or experimenting.

Here's the kicker... pretty much every variable in all of your scripts gets called at least once by a different script, and Unity is good for changing code structure between point releases (3.2, 3.4...). As of version 3.4, private var has become a way of making a variable ONLY accessible by the script it is inside of! So, when you follow the book and make all of those private var statements, you will eventually start getting "SomeObject.someVariable is inaccessible due to its protection level" errors. Unfortunately, I didn't get my first one until chapter 10, but it was a variable I wrote a few chapters earlier and just didn't get used until chapter 10. I simply guessed the 'private' was the issue and maybe the author got gung-ho throwing privates everywhere, so I dropped it to a standard var and it worked.

Digging through some forums, I find that in Unity 3.4 or higher, a variable you want hidden from the inspector but accessible to all scripts in a project has been renamed an internal var. I have since started renaming all of my new 'private vars' as 'internal' and everything is working so far. I still have a bunch of privates I haven't changed, but they must not be called by other scripts so it's okay. I do know that if you fire up the downloaded last chapter project file and try to run it, you will get 66 "protection level" errors, all of which are private variables needing to be changed to internal. SO...

As a hint, get in the habit early of naming the book's 'private var' as 'internal var' and save yourself some red error octogons! (yes, I could have made this a couple lines just by saying that, but I wanted to make sure YOU, the reader, understands WHY this is happening... because we're trying to learn after all...)