This was my second full year of blogging my experiences in the DSA Game Design pathway. This blogs initial goal was to help me think and reflect on the things I do in class (as well as being a forced grade by our evil overlord Mr.B :)). But has it truly achieved its goal? This isn't a simple question. I now have blog posts dating all the way back to September 2015 and yet it doesn't feel like I'v been bogging for that long. My blog has seen everything from long random musings to short reflections. It has seen my successes and failures. With all that my blog has becoming a living archive of how I've experienced and continue to experience the game design pathway. It shows the hard work, the fun games, the evil assignments; everything that makes the DSA Game Design pathway unique. Every year our pathway has trouble pulling in new students. Many rising freshmen students are already set in what art they want to pursue and without a middle school course game design gets left out. Many more quit the pathway as it values quality work and won't give out easy grades. However what I feel this blog has let me reflect upon is all the good fun times I've had in Game Design. There's never a dull moment as we zing from topic to topic creating funny animations and complaining loudly about 3ds and state quizzes. So in the answer to the question what has my blog taught me about Game Design? I see it has taught me that despite the work, frustration, low grades, buggy programs, broken scripts and all the tough times I've had, I love Game Design and that is one hell of a good lesson.
0 Comments
When I decided that for my AP US History end of the year project I would make a Tennis For Two inspired game in Unity using my newfound game making skills, I had no idea what I was in for. First off one cannot overestimate the value of previous codes. Up to that point, I had nothing even close to the style of game Tennis For Two is. I also didn't realize how frustrating programming problems can be when you don't have a nice tutorial script to compare to your own creations. This meant I had to learn the importance of research. Looking through pages of forums and manuals to find the fixes for errors or swatches of code which would help realize the ideas in my head became large amounts of the time I spent working on the game. In fact I estimate that for each script I made I probably spent up to four times as long fixing it than I had spent creating it in the first place. In the end though the skills I took away from making this game alone were invaluable. It taught me how to keep my cool when things aren't working and helped give me a much deeper understanding of coding logic. This was an exercise that I recommend any aspiring game maker to take as it tests the patience and drive of the game maker.
Before diving into making games in Unity we started by taking a 24-ish video long series on getting started with C# coding in Unity. The aim of this was to give us a solid base of coding knowledge before diving into the more complex side of coding a complete Unity game. What I soon figured out however was just how large this leap in coding logic was. So just how effective were the tutorials in their initial purpose? The answer is while they didn't help me in the end with the initial purpose of getting my head around computer logic as it pertains to gameobjects and other important items, it did introduce me to a lot of the jargon I needed to understand for later tutorials. When I started making actual game in Unity the first couple of scripts went entirely over my head. The logic I had to use in order to get a sprite to animate and move across the screen was too different from what I had been doing. However, over time I was quickly able to get used to this more complex coding because of the base the tutorials had given me.
For the last couple of months we have been working extensively in Unity making 2D games. Now that the year is winding down I would like to devote a blog post to reflect on my time working in Unity and see what conclusions I can pull out of the mess of successes and failures I've had.
First up is my experience with Unity's interface. I cannot express how easy it was to not only learn it but also be comfortable enough to explore its limits and truly see what I could do in Unity. In the beginning, I won't lie, the interface was very intimidating. Just watching Unity's tutorial on where everything was made my head spin and I was timid going into Unity for the first time. This was mostly caused by a lack of knowledge in what everything did. Going in as someone who had never made a computer game on a "serious" engine I had no way of knowing things like the difference between the console tab and the assets tab. The confusion which resulted from this really threw me off in the beginning and only went away with time as I used the interface more and discovered that it was rather intuitive once you got in to coding and were able to see some off how the computer processes you're inputs to make a complete game. In the end the conclusion I draw is this: Listen to tutorials and watch carefully mimicking the teacher exactly. This will give you the needed confidence to get of the ground in the Unity interface until you get comfortable enough to use it on your own. The second thing I learned during my time working with Unity can be summed up with the acronym TAB and are a godsend when things go wrong while coding. T: Think about the problem. 100% of coding problems are your fault. I don't say that to be mean but instead to encourage you to think about what's wrong. What do I want to happen? What is happening instead? Why aren't they the same? A: Ask for help. Many problems get solved by just two brains and having four eyes scavenge for miss placed semicolons is much better than just two. B: Be calm. Coding gets people frustrated. Something that seems perfectly obvious to you isn't always the same way to the computer and fixing problems take time, research, and a good attitude. Problems won't solve themselves and the number one thing that I see delaying my peers and myself is when we get frustrated and give up on looking for a solution. These are my major takeaways from Unity this year and while they definitely haven't been easy lessons now that they're over making games is actually turning into the fun work every nerd dreams of doing. I hope these lessons get read by some other people so that maybe, just maybe, they can find a passion for making games and all the hard, complex work that entails. It has come to pass that our game design class may be switching from Unity over to Unreal Engine next year. This being the case we were asked (ordered) to check out the Unreal Engine website to learn about the program and its differences from Unity. The main difference between Unity and Unreal is how the two engines handle coding. In Unity we had gotten used to doing code through c# scripts which we typed out in Monodevelop. Unreal Engine uses a more graphical format to code called blueprints. I personally like the idea of blueprints. They can be used to keep things in order while you code; something I, myself, am not very good at. By using arrows and connectors, they also help the casual viewer follow the logic of the code more easily. In fact they look very much like what I try to imagine in my head while writing scripts in Unity. This would no doubt help me create game faster and not have to spend long periods of time scouring over my script looking for misplaced semi-colons and open-ended brackets.
However the one thing that does worry me about making the switch is that the code is based on c++ a code language related to but not exactly the same as c#. I think that by the end of the year I would get over this problem but still the combination of learning the interface of a new software (something that will be very important while making blueprints), and altering my coding logic will make for a very confusing couple first months for coding. In the end though I believe our class is up to the challenge and look forward to seeing if we actually will get to use this exciting new software newt year! |
AuthorSamuel Henry is a Senior at DSA in NC. He has 3 years of prior experience in the game design pathway and he's looking forward to becoming a great game designer. The views and opinions expressed in this blog are solely those of the author and do not represent those of Durham School of the Arts or Durham Public Schools Categories
All
Archives
May 2019
|