“Start developing games straight away. Build your first game in the first chapter.” “Fun and fast paced. Ideal for readers with no game programming experience.” “A cool guide to get into the game industry quickly.”
Doesn’t that sound like an advertisement for weight loss, except for well, making games. Those are the lines on the “back cover” (if eBooks have back covers) of game development beginner’s guides. But can you really make a game after reading the book? That’s what I want to find out.
So I grab a copy of Flash Game Development by Example written by Emanuele Feronato).
Some disclaimer, I am not a complete beginner at Unity. I spent maybe a year (two years ago) making technical demos using Unity, for a game art outsourcing company in the Philippines that wants to break out from outsourcing to creating their own games. But I left that company, and country and well, to come to a tiny studio in Taiwan to make iPhone games. So here I am, reacquainting myself with Unity. Hi Unity, I’m Hsiao Wei Chen, nice to meet you (okay, that was lame).
So here we go, first chapter. Chapter 1: That’s One Fancy Hammer. (You can read the first chapter on the PacktPub website) Basically, a little intro about Unity. I don’t think I need to tell you guys what Unity is. And he starts telling us about what type of games you can build with Unity, and he shows us Fusion Fall (an MMORPG game by Cartoon Network)… “You can make an MMORPG with Unity? That is awesome! I wanna make my own MMO!” screams the excited reader. And then he slams that thought by telling the readers to check the credits. You need to clone yourself 79 times, according to the author, and send yourself to school to study various disciplines.
Okay, so no MMO, so what game are we gonna make, Mr. Author sir? Then he points us to games on read about how I stumbled into this whole game making business on Gamasutra, in case you’re interested, but you’re probably not, anyway, moving on). Okay, casual games it is then, because we need to “Walk before you can run (or double jump)”. And then it’s hammer time, head on over to the Unity website and download well, Unity, and then install install, and then launch!
And then he starts explaining the interface. I took down some notes:
(my “notes”, forgive my terrible handwriting)
And then we move on to the next chapter! Chapter 2: Let’s Start with the Sky. Are we going to be making skies? Read on, the author asks us, “It’s time to build a game, right? But how do you start? Where do you start?” Um, I don’t know, you tell me. He tells us, that every game starts with an idea. But the number of ideas you come up with doesn’t matter. “The one thing that separates you from success is not the number of ideas you’ve had or the number of projects you’ve started and abandoned, it’s the games you’ve finished that count.” Is that directed at me? I have a tendency to have a lot of ideas, starting a lot of projects, but never finishing them. That line really struck me, sir. Yes, sir, I will try to finish my games, okay not try, I WILL finish my games.
And then he talks about “The Siren Song of 3D” (how beautifully put). He says that before we even begin, the odds are already stacked against us! That’s a mean thing to say. He points out that games like GTA, Mario or Fall Out 3 is they have “an animated character or first-person camera moving around in a physics-based environment; a rich and detailed 3D world with maps… teams of hundreds of people burning through multimillion dollar budgets…” Okay, we get it, we can’t make MMOs and AAA quality games.
And then he starts talking about features vs content, and giving a lot of examples of games along the way. The summary: “By cutting features from your game ideas, you can whittle your design down to a more manageable size than by cutting content”. Okay, got it. Can we get started now? I want to make some games! (or at least one game, before the night is over).
Chapter 3: Game #1 Ticker Taker. Yeah, finally! So what game are we going to make? Volleyball. He wants us to make a volleyball game, I hate volleyball (or rather, I suck at vollyeball). But he did ask nicely for us to pretend that we are totally pumped about volleyball. Fyeahvollyeball!
*takes a break to do the laundry*
Okay, now where were we? Oh yeah, game, and volleyball. I love volleyball. Read, read, read. The author Is explaining the rules and the complexities of volleyball and he came to conclude: “You + volleyball game = badIdea.” I know right, really bad idea. But then he insists that volleyball is my dream, my passion, that is why we must strip volleyball down to it’s bear essentials and start from there. Okay, he instructs me to get “a red pen and/or machete”, gotcha. Okay, I have my machete, who do we kill? -Sets, teams, multiple players, net, referee, spectators, and then the player. Wait, what? We’re even killing the player? What’s left? A ball. A ball floating in midair. A ball that cannot touch the floor. And something to bounce the ball on. Okay, I can work with a ball (in fact, I think I can even make a 3D model of a ball in Blender).
So let’s go to Unity. Create new project and then add a new object to the scene, a sphere, which will serve as our ball. So we name him, Ball!
(more “notes”, before and after)
He says that our ball right now is between the ground (half above ground, half below ground). And we must move the ball up to the sky. We change the Y position of the ball to 2 (in the Inspector panel). Okay, that was easy. Next, he complains that our ball is too big, so we scale it to 0.4 for X, Y and Z. Okay. Next step? Save the scene.
Now, we have our ball, next is our paddle (the thing that we are going to have our ball bounce on). We create a cube (Game Object > Create Other > Cube), and we name him Paddle, and then we scale him, so he’ll look less like a cube and more like a paddle. Alright then.
And then we add a light to our scene.
(our ball and paddle used to be dark an dreary, now it is all lighted up. like a make up commercial)
And then we test our game! We hit Play. *those black crows from Japanese animes fly by* Nothing happens.
The author is pulling our leg, he wants us “to test your game at this point, even though nothing happened, to pinpoint that magic moment when Unity becomes awesome.” Okay, well, I can’t wait for things to become awesome.
Add physics to our game! Click on Ball in the Hierarchy panel, and then go to Component > Physics > Rigidbody, to add a Rigidbody to our Ball. And make sure that Gravity is checked in the Inspector panel. And we could hit play again (at least he is telling us to hit play again). Our ball fell down and hit the paddle! Whee! It was “especially cool” (he says I can get ten points, if I said that that was especially cool).
Next, we want our ball to bounce. Because, in real life, ball bounce, right? At least volleyballs bounce (I know that much about volleyballs). So we set the Material property of the Sphere Collider of our ball to Bouncy. And press play again, and it is magically bouncy! “Especially cool”! And that’s the end of chapter 3.
But the ball just keeps bouncing and we can’t do anything. So we have to move on to the next chapter, Chapter 4: Code Comfort. So it’s time for some coding. Nervous? But the advertisement says that: “Build fun games even if you’ve never coded before”. I guess this is the part that will decide whether a book can really teach someone to make a game. Well, it’s 37 pages of condensed lesson in scripting.
The question at the back of my head: do I really want to read about scripting?
*will rest a bit tonight, will take on that chapter tomorrow*
Next day, a new chapter. Chapter 4: Code Comfort. Here we go! I’m just gonna read it through for and give you guys a short review of what I read.
Okay, done. This chapter starts from the basics, in an easy to read and easy to understand way for the readers, whom the author assumes has no background at all in coding. For one thing, he compares functions to a hoagie, the curly brackets being the buns, and the scripts inside as well, the tomato, the salami, the mayo. And a variable to a bucket, which contains things, you know. He also teaches the readers how to access the Unity Manual and Scripting guide and how to make sense of it. He also lets the readers try out code every step of the way. All in all, the author is actually quite a fun read, because of his wit and humor, and it is nothing like my Computer Programming 1 professor, who tends to drone. So, I’m done with Chapter 4.
I do realize that this book has 380 something pages and 12 chapters. And this blog post will go on like forever If I continue in this fashion. So um, I’m going to stop here.
Overall, I think this book is easy read, it’s not intimidating in such a way that it bombards you with information, code bits that you can’t even begin to grasp. I think that beginners, even those who have “never coded before” would find this book easy to digest, and might even be able to “build fun games”. For those who are interested in the book, you can check it here.
By the way, you can also read my review of here. But my conclusion after reading that books is: “Overall, I think this book is a very comprehensive guide to anyone, who has a bit of background in programming, and wants to start making games using Cocos2D.” Note, I said that it will be a good guide to anyone with a bit of background in programming.
So can someone who has never coded before learn how to make games by reading a book? That was the question at the beginning of this blog post. I guess it’s hard to tell, I’ll have to say it’s:
( sign from Mythbusters)
By the way, Packt Publishing gave me these books for free to review. Why? It’ because I’m a blogger and I occasionally blog about Cocos2d stuff. You can get free books too, if you are a blogger/ webmaster/ reviewer for a magazine or a popular and relevant website / educator in an academic institution, just email you details to Packt website.