What do you think?
Rate this book
Learning C# by Developing Games with Unity: Get to grips with coding in C# and build simple 3D games in Unity 2023 from the ground up
Learn C# programming from scratch using Unity as a fun and accessible entry point with this updated edition of the bestselling series. Includes invitation to join the online Unity Game Development community to read the book alongside peers, Unity developers/C# programmers and Harrison Ferrone. It's the ability to write custom C# scripts for behaviors and game mechanics that really takes Unity the extra mile. That's where this book can help you as a new programmer! Harrison Ferrone, in this seventh edition of the bestselling series, will take you through the building blocks of programming and the C# language from scratch while building a fun and playable game prototype in Unity. This book will teach you the fundamentals of OOPs, basic concepts of C#, and Unity engine with lots of code samples, exercises and tips to go beyond the book with your work. You will write C# scripts for simple game mechanics, perform procedural programming, and add complexity to your games by introducing intelligent enemies and damage-dealing projectiles. You will explore the fundamentals of Unity game development, including game design, lighting basics, player movement, camera controls, collisions, and more with every passing chapter. If you're a developer, programmer, hobbyist, or anyone who wants to get started with Unity and C# programming in a fun and engaging manner, this book is for you. You'll still be able to follow along if you don't have programming experience, but knowing the basics will help you get the most out of this book.
- GenresProgramming
458 pages, Kindle Edition
Published November 29, 2022
29 people are currently reading
11 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 2 of 2 reviews
March 3, 2023
Best Unity, C# book I've read
I came into this book with intermediate knowledge of other programming languages, but no knowledge of either Unity, or C#.
Harrison's book introduced me to C# without feeling simplistic - he explains the "why we do ..." as well as the "how we do ..." and gives meaningful examples that helped the information gel.
Harrison's approach made learning Unity and C# a fun experience, rather than just a necessary step in my programming journey.
For those who purchase the physical book, a link is provided in the Preface to download a PDF with color versions of the images in the book.
I would recommend downloading the color PDF, since IN SOME CASES the color image makes it easier to see what is being shown.
In some of the (full interface) images it's difficult to see menus and such, but you will notice Harrison tells you exactly what he is showing for those images and the menus are not needed within the context Harrison is describing.
Where Menu context IS needed, Harrison focuses in on that section of the interface that he is discussing in that section and the images show the topic of discussion clearly.
I came into this book with intermediate knowledge of other programming languages, but no knowledge of either Unity, or C#.
Harrison's book introduced me to C# without feeling simplistic - he explains the "why we do ..." as well as the "how we do ..." and gives meaningful examples that helped the information gel.
Harrison's approach made learning Unity and C# a fun experience, rather than just a necessary step in my programming journey.
For those who purchase the physical book, a link is provided in the Preface to download a PDF with color versions of the images in the book.
I would recommend downloading the color PDF, since IN SOME CASES the color image makes it easier to see what is being shown.
In some of the (full interface) images it's difficult to see menus and such, but you will notice Harrison tells you exactly what he is showing for those images and the menus are not needed within the context Harrison is describing.
Where Menu context IS needed, Harrison focuses in on that section of the interface that he is discussing in that section and the images show the topic of discussion clearly.
June 20, 2023
I noticed there seems to be a large number of aspiring game developers that dive into Unity without learning C# first. Although I think it’s a good idea to learn C# first, game development is a different way of thinking, and Unity’s codebase doesn’t conform to C# standards in many ways.
The book even claims it’s a good book for those who know C# but “need to get hands-on with game development in Unity”. So, does this book do a good job of teaching C# in the context of Unity? I’d say no. The problem is that a lot of the content is either poorly described, ambiguous, or misleading. Then sometimes the writing style is more conversational/casual (perhaps would be harder for non-native speakers): "we’ll be diving into that in the next section—hold tight.". "To Unity, it walks, talks, and acts like any other component, complete with public variables underneath the component that can be changed at any time."
I’ll discuss some of the ambiguous and misleading elements of the book:
“It could simply call the SendMail function from the PostOffice class, as follows: PostOffice().SendMail()”. This isn't true because PostOffice isn't a method in his example - it is a class. Therefore the syntax would require the "new" keyword.
Does this explanation actually make sense or aid comprehension? I find it a weird analogy:
“Variables hold values like mailboxes hold letters; methods store instructions like recipes, to be followed for a predefined result; and classes are blueprints just like real blueprints.”
He initially declares variables in PascalCase, then claims that is the C# standard, yet Pascal case is for Properties and method names. Then in Chapter 5, he switches to camelcase, then occasionally uses an underscore prefix in subsequent chapters.
"While explicit access modifiers aren’t necessary when declaring a variable, it’s a good habit to get
into as a new programmer. That extra word goes a long way toward readability and professionalism
in your code". Apart from the fact that he is specifically talking about fields. If it is a local variable, then the access modifiers are completely invalid. Access modifiers are necessary in certain contexts, so that's not a correct statement anyway.
In regards to using time.deltaTime, he describes it as “This is the standard way of normalizing movement effects in Unity so that they look smooth no matter how fast or slow the player’s computer is running.” It’s quite an important aspect of Unity programming, and a basic explanation isn’t really good enough. It’s not so much as looking smooth, rather than actually being the correct calculation over time. At a low framerate, nothing is going to look smooth.
“By default, all arguments are passed by value, meaning that a variable passed into a method will not be affected by any changes that are made to its value inside the method body.” It’s a bit complicated, but this isn’t really true with reference types: MSDN even says “If the method modifies the state of the object referred to by the parameter, those changes are visible from the caller.”
I thought there were fewer mistakes in the latter half of the book, but then I also think I was skim-reading more frequently, so maybe I wasn’t paying attention. In conclusion, I think there’s way better resources for learning the basics of C# out there, and there’s way better books for learning Unity.
The book even claims it’s a good book for those who know C# but “need to get hands-on with game development in Unity”. So, does this book do a good job of teaching C# in the context of Unity? I’d say no. The problem is that a lot of the content is either poorly described, ambiguous, or misleading. Then sometimes the writing style is more conversational/casual (perhaps would be harder for non-native speakers): "we’ll be diving into that in the next section—hold tight.". "To Unity, it walks, talks, and acts like any other component, complete with public variables underneath the component that can be changed at any time."
I’ll discuss some of the ambiguous and misleading elements of the book:
“It could simply call the SendMail function from the PostOffice class, as follows: PostOffice().SendMail()”. This isn't true because PostOffice isn't a method in his example - it is a class. Therefore the syntax would require the "new" keyword.
Does this explanation actually make sense or aid comprehension? I find it a weird analogy:
“Variables hold values like mailboxes hold letters; methods store instructions like recipes, to be followed for a predefined result; and classes are blueprints just like real blueprints.”
He initially declares variables in PascalCase, then claims that is the C# standard, yet Pascal case is for Properties and method names. Then in Chapter 5, he switches to camelcase, then occasionally uses an underscore prefix in subsequent chapters.
"While explicit access modifiers aren’t necessary when declaring a variable, it’s a good habit to get
into as a new programmer. That extra word goes a long way toward readability and professionalism
in your code". Apart from the fact that he is specifically talking about fields. If it is a local variable, then the access modifiers are completely invalid. Access modifiers are necessary in certain contexts, so that's not a correct statement anyway.
In regards to using time.deltaTime, he describes it as “This is the standard way of normalizing movement effects in Unity so that they look smooth no matter how fast or slow the player’s computer is running.” It’s quite an important aspect of Unity programming, and a basic explanation isn’t really good enough. It’s not so much as looking smooth, rather than actually being the correct calculation over time. At a low framerate, nothing is going to look smooth.
“By default, all arguments are passed by value, meaning that a variable passed into a method will not be affected by any changes that are made to its value inside the method body.” It’s a bit complicated, but this isn’t really true with reference types: MSDN even says “If the method modifies the state of the object referred to by the parameter, those changes are visible from the caller.”
I thought there were fewer mistakes in the latter half of the book, but then I also think I was skim-reading more frequently, so maybe I wasn’t paying attention. In conclusion, I think there’s way better resources for learning the basics of C# out there, and there’s way better books for learning Unity.
Displaying 1 - 2 of 2 reviews