You're alright, kid

I've (finally) been working through the excellent Walker Boys Unity tutorials. First, I want to give a huge thanks for Walker Boys Studios for creating these tutorials. I'm never a fan of video tutorials (I prefer the faster pace of reading along a tutorial), but these are very well done and nicely paced. So on that note, please support their Kickstarter project, Build a Game!

For the most part, I approached these tutorials by getting an idea of what was trying to be accomplished in the particular tutorial video, and just give it a go by myself. Then, I'd watch the video in full and see how the instructor, um, instructed to achieve the same thing. 

I'm hosting my Unity games on Google App Engine over at Start Press Games. Once I tinker with the games, adding and improving upon them, to a level beyond recognition of the original intention of the tutorial, I'll be posting them on GitHub for others to view and (hopefully) learn from, but more importantly, for me to receive constructive criticisms as well so I can improve and be called out on my mistakes. 

So what are my initial impressions of Unity you say? I know you didn't say anything, you really don't care, but you're getting them anyways!

What I Like

1. I'm writing little, to no game engine specific code. Coming from primarily XNA game development, this is nice welcome and a huge boost to productivity. As fun as writing a game engine can be, with my limited time, I'd simply rather not bother. I've yet run into any limitations with the Unity engine itself in terms of what I want to do.
2. True multiplatform. With a few clicks, I'm deploying to desktop, web and Android (I have no Mac machine, else I'd deploy to iOS as well!). Outside of having to implement input for touch control for Android, it's been a breeze to target multiple platforms and various resolutions.
3. Testing new changes is stupid fast and easy. No need to wait for a full build! Just hit play, and test your changes all within the comforts of the Unity editor. This creates a very nice workflow.
4. Asset Store. While I haven't purchased anything yet (I plan to purchase 2D Toolkit this weekend), by browsing the Asset Store, I can see that I'll be able to obtain a proven solution to a problem I (will possibly) face. Is that as bad as copying and pasting code from Stack Overflow? I wouldn't say so, but anything that boosts productivity is a good thing. 
5. The Unity Editor itself. Unity itself is very nice and intuitive and allows for great workflow.

What I Don't Like

1. MonoDevelop. Oh dear God, is MonoDevelop horrible. In fact, the whole scripting IDE situation of Unity is unacceptable in my opinion. Before you judge, do know that a large portion of my job is essentially writing C code in Notepad++ with only Netbeans 3 as a remote debugger (yes, Netbeans 3), so I constantly experience much worse than what Unity offers. I would use Visual Studio 2010, but I really hate that I have to pay $125 to be able to debug in VS2010, and have a decent IDE setup overall (and UnityVS is still missing a lot of necessary features for true productive coding). 
2. Scripting Reference Documentation. It could be better overall. They do provide some decent code examples, which is nice, but the overall structure and layout needs improvement (how method signatures are conveyed, for one). A more minor nitpick, but there's no option to default the script examples to C#, over the current default of JavaScript. 
3. Reflection to determine method implementations. Instead of allowing developers to actually override methods, reflection is used at creation to identify all of the (what should have been traditionally virtual) methods of the Unity engine that the developer implements (such as Update). This was done to optimize performance (only call the methods that are actually implemented), but makes identifying override methods more difficult. The bigger issue is that you can't use IntelliSense to implement the method, and thus need to make sure you have that trusty Scripting Reference web site open and by your side at all times to get the method signatures correct. 
4. Public variables exposed in designer view. Now, I'm sure many people would expect this as an item on my "What I Like List", and I understand that this feature is so that non-coder designers can change variables with ease, and without looking at code, but since I am a coder, I instinctively change the values within code. However, if the value was ever changed within the editor, changing the value in code is ignored, thus a bug. A lazy solution here would be to never declare public variables.

So those are my initial impressions. Since I'm only interested in 2D game development, next on my agenda is picking up 2D Toolkit and re-creating my old XNA game (Deep Space Dog, video in upper right of blog) in Unity. Once I have that done (ignoring how slow I can actually work, I don't expect it to take many hours at all), I will upload it to Start Press Games and GitHub for all to enjoy and make fun of!