Review Unity 3D Game Development by Example, Beginner's Guide by Ryan Henson Creighton

Let me start right off by saying that this book is excellent.  If you paid attention to the title where it says "Beginner's Guide", you'll be very pleased with this book.  In particular, for a beginner, the pacing of the book is perfect.  The game examples that you create are nothing to get excited about, but that's not really the point.  The main point is if you are a complete beginner to Unity and to writing Javascript within Unity, then as far as I know this is the best book available.  Now that I have that out of the way, I'll veer slightly off topic.

I currently have two games published on the Xbox 360 in the Indie Games section.  They are Acid Rain and Acid Rain Heroes.  I am a huge huge Xbox 360 fan.  When Microsoft announced XNA and the Indie Game marketplace I knew it was time for me to dust the cobwebs out of my brain and learn programming again after a 20+ year hiatus.  I previously developed Paladin's Legacy and got it published back in 1985.  I spent 2 years learning C#, XNA and numerous audio and graphics applications in order to publish my games on the 360.  I even formed a company, PermaFrost Gaming.  And all during my development, I watched as Microsoft fumbled and stumbled and most likely even intentionally sabotaged their own Indie Marketplace strategy.  They changed the name.  They changed the pricing structure (lowering it to be competitive).  But ultimately as a business model, the Indie Game Marketplace on 360 is a failure.  As a hobby location for creation and distribution of games, it's a massive success.  Exisiting digital distribution models have proven that you can't put up a bunch of barriers and expect mass adoption of a marketplace.  Barriers like, MS requires you to buy points in order to purchase anything on the 360.  Indie games have a very limited 3 tiered pricing model and there is no free option.  Indie games don't have access to some of the most attractive features available on Xbox Live (Achievements). Indie games by default are under 18 restricted.  My current view is if you want to learn C#, build 2D games and distribute them as a hobbyist, then XNA may be your thing.  But if you have aspirations of a successful business and plan to delve into 3D game development, then Unity is the better choice.  This brings me to this current review.

I made the switch to Unity because Unity allows me to further my knowledge of C# but develop and distribute games on multiple platforms.  Multi-platform development is the future...if you intend to make a business of game development.  And this book is the perfect place to start.

Ryan starts the book off by giving the prerequisite indie game developer warnings.  I love these quotes, "I don't want to set my sights too high, so I'm going to make a game like Gran Turismo, except with fewer cars." and "I'm going to build World of Warcraft with fewer class and about half the items."  He devotes the first couple of chapters to explaining the core mechanics of games and establishing realistic expectations for beginner game developers.  By chapter 3, you're already developing your first game prototype in 3D.  That's the power of Unity!  After finishing chapter 4, I just laughed out loud.  Ryan humorously quips, "Worst. Game. Ever." My thought was, I can't believe what I just created in 2 short chapters.  Awesome!  For the record, in XNA, I intentionally avoided 3D.  Even with the XNA framework library at my disposal, hand coding 3D cameras, lights, viewports, 3D model importing etc. etc. was and still is way over my head.  I could go on and on...... XNA doesn't have a built in physics solution or a particle solution or a menu creation solution but I'll stop and just say that Unity has all of that stuff built in along with almost universal 3D model, audio and texture import functionality. (even native Photoshop files .PSD)  I'm not embarrassed to say WOW!

At this point, I'm just going to highlight the things I think Ryan really got right in this book.  These are things I sticky noted for future reference.  In chapter 4, how to display variables in the editor for code debugging.  You use Debug.log().  In chapters 5-7, using the GUI (Graphical User Interface) tools in Unity.  I would have preferred that Ryan used the GUI feature to build an actual game menu system instead of an entire game.  But one could argue that he killed two birds with one stone by creating a 2D game and a simple menu system all at once using the GUI system.

In chapter 8, you begin crafting your first real 3D game.  He covers 3D Meshes, physics (rigidbodies and colliders) and the FBXImporter used to import models from Blender.  Unity can import from numerous 3D modeling applications.  Blender happens to be free which is pretty cool.  He covers the use of Tags which helps you identify game objects through code.  In chapters 9-10, you begin another 3D game and get introduced to the amazing particle system, Prefabs and audio in Unity.  Prefabs allow you to craft multi-component/object Game Objects and then make an unlimited number of copies of that original multi-part creation.  By making changes to just the original Prefab, your changes are automatically propagated to all prefab copies in all scenes in your game.  In C#, it's the same idea as creating a class with a bunch of stuff and then instantiating that class numerous times in a list or an array thus resulting in multiple copies.  Unity is basically perfecting or evolving the idea of Object Oriented Programming with a visual representation in the Unity editor......and calling it a Prefab.  And that's really cool!

In chapter 11, Ryan introduces the multiple camera setup and the use of layers to control what those cameras see/display.  Yes that's right, Unity allows you to use multiple cameras using layers to define what objects are seen by each camera.  Simply assign a depth value to establish which camera is rendered in what order.  I don't even want to think about the complexity of that in XNA.

Finally in chapter 12, Ryan goes back to the game you created in chapter 8 and introduces us to lights, more layers, more cameras and using the animation editor to animate one of the cameras in order to simulate a 1st person 3D walking effect.

Again, the book is all paced perfectly introducing us to new features in Unity with each few chapters.  The Javascript coding is kept simple and very understandable.

I highly recommend this book to any beginning game developer.

Allan Chaney

Review Beginning XNA 2.0 Game Programming From Novice to Professional by Alexandre Lobao, Bruno Evangelista and Jose Antonio Leal de Farias

(Originally written) Friday, January 9, 2009 at 2:49AM

modify remove organize post follow up

I really liked this book.  About half of the book will be valuable to a complete beginner.  The second half delves into 3D and starts you down the path of shader development, terrain generation and a third person shooter.  I found the third person shooter part to be a relief since most books deal in first person when they hit the 3D section.  I have motion sickness problems with first person shooters so I will never make a first person shooter.  I am therefore a little biased in that regards.  I didn't understand most of the 3D stuff.  So I doubt you will either if you are at my stage in XNA development, which is to say beginner.

I did however like the fact that the authors are uncompromising in their use of Game Components vs. Classes.  My understanding of the history of Game Components is that it was a feature Microsoft included in XNA in the hopes that the community would develop components that could be distributed over the web and used as a sort of "drop in" chunks of game code.   I won't explain how they work here but I will say I was thoroughly confused by them at first.  The previous XNA and C# books I read never even mentioned Game Components as an option.  In regards to C#, I think that's because they are not available in C# regular (don't quote me on that though) only XNA, and as far as the other XNA books, I think it's because the authors were not familiar enough with the concept to feel comfortable writing code using them.  In essence a Game Component is just a form of a class that works differently with the intent of making that chunk of code more modular and thus more conducive to sharing.

The authors make full use of Game Components in their very first game, Rock Rain.  This game is a real treat to code and to run.  I think the authors did a nice job of slowly progressing the building of this game.  They actually finish it in a very basic form which is good for us beginners.  Then they extend it with more powerful features like menus, game networking, health ups, progressing difficulty etc.  That helps to keep the complexity low in the beginning and it gives you a sense for how you can organize your code using game components.  I actually used their rock code structure in my first project.  Instead of rocks falling down the screen, I have raindrops.  And I used a class instead of a game component because I was more familiar with that structure from reading previous books.

It is absolutely imperative that you understand Game Components, in my opinion.  I say this because a lot of the tutorials and examples you see online use them to structure things.  If you check out the code samples at the XNA Creators Club Website , you'll see Game Components all over the place.  I am particularly fond of the 2D particle system.  I implemented this in my current project and it forced me to learn how to use Game Components.

Another piece of code I am using directly from this book is how they handle screenbounds on the Xbox 360.  You can't just declare a screen resolution like you do on a PC and expect your game to work right on the 360.  TV's have overscan, an unused area rim that varies in thickness from TV to TV.  You have to take this into account when developing for the 360 or some players will not see things you put on the edge of your game window.  The authors use the #if Xbox 360 command to separate the screen code "if" the program is running on the 360 vs. a PC.  I thought that was pretty slick.

I used sticky notes to reference key topics that may be valuable to me in the future.  Some of them were, XNA supported file formats, game components, menus, health up object and networking.

I probably would not recommend this as your one and only XNA book.  I think the Rob Miles' "Learn Programming Now!..." book is better for beginners since it only deals with 2D.   But I would recommend this book as your second or third purchase.  Just be aware that the second half may be over your head right now.  I mention a possible third because I am currently reading the new, and as of this writing, only XNA 3.0 book:  Learning XNA 3.0 by Aaron Reed.  I like it a lot so far but I'm not ready to review it.



Review Building XNA 2.0 Games by James Silva and John Sedlak

(Originally written) Wednesday, January 7, 2009 at 12:50PM

modify remove organize post follow up

I read some of the reviews of this book atAmazon and I was pretty disappointed by the immaturity of reviewers.  But I guess that's the way it is when anyone can post whatever they want.  There was one review in particular that made the assertion that Mr. Silva was capitalizing on his winning of the Microsoft game competition where he won a publishing contract for his upcoming Xbox 360 Live Arcade game The Dish Washer: Dead Samarai, by pumping out a book.  This was a really stupid and immature thing to say.  That reviewer obviously has no idea how much effort is involved in writing a book or developing a publishable game.  And the market for these books is so small, Mr. Silva is not going to get rich on book sales.  If anything, Mr. Silva should be commended for taking the time to write this book along with his co-author, all the while, toiling away at his soon to be published game.  A year later and he is still working on that game, though I understand he is one bug from certification.  Publishing is immensely difficult.  I know just a little bit of where he is at.  When I sent my game, Paladin's Legacy, off to Sundog Systems Inc. in 1987 I thought it was done.  I spent another year getting it publishable and that was 20 years ago when code and games were much much simpler.

That brings me to my first point.  This book has a lot of really awesome code in it.  With that said, I have to fair to the beginners out there.  A lot of the code is over your head...right now.  Mr. Silva includes so much code, there isn't a lot of room left over for explanation.  At least that's the way I perceive it.  Consider that in this relatively modest book, Mr. Silva develops an entire character animation editor ("robust, ugly character editor" are his words).  It looks magical to me.  He then proceeds to develop an entire, "robust" fully realized, 2D side scrolling game.  This thing makes the Platformer example included in the Visual C# Express Editor seem ridiculously simple.  That's a compliment by the way.  Visually it blows away anything Mario has been in for the last 15 years.  That's my personal opinion.  He develops a particle system with smoke, fire, blood spray and splatters.  His character is a gun toting, wrench wielding, jumping killer.  He has AI based enemies including regular ghouls and chainsaw wielding ghouls.  There is real time collision based combat.  I could go on and on.  But wait it gets better.

I have a pet peeve with some XNA books that spend a few chapters on 2D and then jump into 3D with all guns blazing.  The fact of the matter is most Xbox Live community games will be in 2D because 3D is just massively complex.  Given graphic content requirments of 3D, most 3D games will require a team of people.

This book is entirely 2D!  Thank you Mr. Silva. 

Looking back at my sticky notes that I use as page markers for future reference, I find I marked the following:

Reading in a text file, character animation system, particle system smoke, fire, particle blood, slow-time effect(like The Matrix), shake screen, blast effect, Rumble, professional HUD, 2D Shaders!.

That's right you saw that last one right.  I have never before seen shaders used in a 2D game.  Usually when I read about shaders, I'm knee deep in 3D code way over my head.  This is the first time I have seen code, in print, that does shaders in a 2D game.  I don't understand it but when I do I will use this code.  He has several shaders; Color Filter, Blurry Greyscale, Bloom, Earth Tones (to give it a non-Nintendo look that I'm so sick of I could just puke), and the frosting on the cake...A Water Effect (rippling, reflecting water in a 2D game).  Who would have thought?  Well James Silva thought enough of the XNA community that he shared this code with us. 

I may not understand all of the code in this book now but I'm glad I bought the book because it shows me what is possible and I know when my knowledge catches up with this book, I'm going to produce a stunning game with some cool Silva-effects.

This is an intermediate level book.  It's definitely worth buying.  Be prepared for a lot of cool code with only modest explanation, that if you are a beginner has great future potential and if intermediate, should impress you a great deal.

Allan Chaney

Review Professional XNA Programming by Benjamin Nitschke

(Originally written) Wednesday, January 7, 2009 at 4:49AM

modify remove organize post follow up

This will not be a long review.

If you are just starting out with XNA or C#, this book is not for you.  There is a reason why the word Professional is in the title.  This book is targeted towards people who have already been programming for some time and may be on a development team making a game.

The book starts right out in part one talking about Unit Testing.  I'm still not sure what that is and I read the section at least 6 times.  What it meant to me is I couldn't make any sense of the code.  Unit testing has something to do with writing your code in a format that isn't the real code but is instead used to test the code.  Huh?  I guess that's something the professionals do.

The author then moved right into Helper classes and more unit testing.  It's a little strange because he goes on to say that the helper classes he has written are really good and should be downloaded so you can use them in the rest of the book.  I got a little worried at this point.  He shows some code and some ideas for helper classes but doesn't really complete the topic of Helper classes before it's on to some more unit testing code.

He talks about agile design a lot.  Again this must be a new buzzword used by professional developers to make things at least sound like they are a little easier or more efficient.

He then quickly jumped full force into 3D, Shaders, your own Game Engine etc.

I was half way through the book and realized I had not placed any sticky note markers as guides for future reference and it occurred to me I was wasting my time.

If you are a professional programmer, this book may be for you but I'm not qualified to make that call.

For a true beginner, you should look elsewhere.

Allan Chaney

Review Learn Programming Now! XNA Game Studio 2.0 by Rob Miles

(Originally Written) Monday, January 5, 2009 at 11:30AM

modify remove organize post follow up

This was the very first XNA book I bought and I'm glad it was my first.  Based upon the 5-6 XNA books I've purchased and read, this book is the most beginner oriented.  Rob Miles does a nice job of trying to hand hold you through basic Object Oriented concepts yet also rapidly getting you involved in XNA code so you can do something exciting.  When I read books of a technical nature, I realize that most of what I read will be forgotten but exposing my brain to the ideas over and over eventually has an effect.  My point is the real value in a lot of technical books is as a reference source.  When you start developing your first project, you'll run into all sort of road blocks.  Hopefully you'll remember reading something in one of your books that provided a solution.  My strategy is I use sticky notes as page markers.  I write on them and place them on the page sticking out the top so I can easily see my note outside of the book.  Later on when I run into a problem, I can quickly browse through my sticky notes to try and find a solution.

Some of my notes include Gamepad Input, joystick vibration, filling the screen, fake 3D text, arrays, keyboard, using a struct to define an object.

Mr. Miles  walks you the development of several simple 2D games.  I particularly liked the Bread & Cheese game which he expands with Tomotoes.  For some reason, I understood how this game was organized.  It was simple, straight forward and became the structural basis for my first game project.

Based upon the XNA books I've read, about 6 at this point, this is the best beginner book for learning XNA.  One reason is that Mr. Miles avoids some of the pitfalls of other books by steering clear of multi-class projects and projects that mix Game Components with classes.  These are very confusing structural topics for beginning XNA programmers.  It's hard enough to learn basic syntax without rapidly getting into properties, parameter passing functions and constructor methods full of passed variables and fields.  Mr. Miles does everything in the main Game1.cs class.  This keeps things simple.  Another major aspect of this book, relative to beginners, is he sticks to 2D.  Most XNA books spend just a few chapters on 2D and then jump into 3D with reckless abandon.  I find this really strange when you consider that most community games on the XBOX 360 will be in 2D.  That's simply a fact.  3D game development is massively complex and not just from a coding perspective but from the graphics.  Developing 3d models, shader code etc. etc. is just way over any beginner's head.  So what you will find is many XNA books are great until they start the 3D stuff.  And then you may as well put them down.  Because if you are at my stage in this, you are not ready for 3D.

I e-mailed Mr. Miles  at his website Very Silly Games.

This was my post and his reply:

Rob,

As a new C#/XNA programmer, I've really enjoyed your book, "Learning Programming Now!" If you don't mind I have a few basic coding questions.

My 1st question is, Why do you use an algorithim to scale sprites to the displaywidth and height in your Bread and Cheese game when it seems that you could just use the scale feature built into the SpriteBatch.Draw method. There is an overload for Draw that includes scale. Would it not be simpler to just use that built-in scale feature in Draw and adjust it relative to DisplayWidth and Height?

My 2nd question is, On the XNA Creator's Club Website in the Getting Started section, there is a tutorial teaching you to make a 2D "Shoot the Flying Saucers" game. In this tutorial, the author uses a seperate class to define his sprites. He calls his class GameObjects and in that class assigns the various sprite fields etc. In his main Game class he then refers to those fields by using GameObjects dot field. (GameObjects.field) However in your book in the Bread and Cheese game you use a Structure to hold the sprite information. Is this simply a personnal coding perference or is one way better than the other?

My Final Quesiton is more complicated so please bear with me. I've read a few books that use GameComponents and Game Services to organize their code. (I'm specifically referring to "Beginning XNA 2.0 Game Programming" by Lobao, Evangelista and Faris.) This organizational structure seems bizarrly complicated to me and it seems to me that it breaks the elegance of using the class structure and proper inheritance/parameter passing between classes that you learn in C#. However the game code works and in some regards it's much simpler because is seems that it gets around all of the inheritance problems that become very complicated using multiple classes.
Since you don't address this type of structure in your book, would you be willing to offer your opinion on the use of GameComponents/Services vs. classes as a way to structure game code in C# and XNA?

Thanks so much for your help.

Allan Chaney

Sorry about the delay in getting back to you. Been awfully busy recently. I've put my answers in line...

My 1st question is, Why do you use an algorithim to scale sprites to the displaywidth and height in your Bread and Cheese game when it seems that you could just use the scale feature built into the SpriteBatch
Draw method. There is an overload for Draw that includes scale. Would it not be simpler to just use that built-in scale feature in Draw and adjust it relative to DisplayWidth and Height?

>>> Indeed I could use the scale. The thing is that I wanted to use this to teach about programming and scaling. Perhaps in a future book I could mention that the method is avaiable.

My 2nd question is, On the XNA Creator's Club Website in the Getting Started section, there is a tutorial teaching you to make a 2D "Shoot the Flying Saucers" game. In this tutorial, the author uses a seperate class to define his sprites. He calls his class GameObjects and in that class assigns the various sprite fields etc. In his main Game class he then refers to those fields by using GameObjects dot field. (GameObjects.field) However in your book in the Bread and Cheese game you use a Structure to hold the sprite information. Is this simply a personnal coding perference or is one way better than the other?

>>> I wanted to start with structures and then move into objects later.

My Final Quesiton is more complicated so please bear with me. I've read a few books that use GameComponents and Game Services to organize their code. (I'm specifically referring to "Beginning XNA 2.0 Game Programming" by Lobao, Evangelista and Faris.) This organizational structure seems bizarrly complicated to me and it seems to me that it breaks the elegance of using the class structure and proper inheritance/parameter passing between classes that you learn in C#. However the game code works and in some regards it's much simpler because is seems that it gets around all of the inheritance problems that become very complicated using multiple classes.
Since you don't address this type of structure in your book, would you be willing to offer your opinion on the use of GameComponents/Services vs. classes as a way to structure game code in C# and XNA?

>>> I've not had a chance to look at this book I'm afraid. If you want my philosophy on game structure take a look at my Starlight game for Smartphone. It is not an XNA game, but it has a lot of stuff about game design and sprite management. It also has some stuff about animation that you might find useful.

http://msdn.microsoft.com/en-us/library/aa446569.aspx

I'm immensely impressed anytime an author both supports their work with this kind of dedication and takes the time to communicate with their readers.  His website is amazing.  He has the code for a ton of his games you can download and learn from.

I highly highly recommend this book for any beginning or intermediate XNA developer.

My only recommendation for Mr. Miles is that he please write another book updating the text for XNA version 3.0 and I think he should spend a chapter or two addressing muli-class structured code and the use of Game Components.  Although these are complex topics, they are unavoidable and Rob Miles is the perfectly suited to explain them to you and me.

Allan

Allan Chaney | Post a Comment | Share Article

in Book Reviews, Featured Posts