Recently, I learned how to use a new skill in Unity. Unity terrain building is a relatively easy-to-use way of making terrains for your video game. It uses textures and bump maps so you can create a lively environment. But what are the advantages of doing this over just importing your own assets. Is creating a terrain fresh in Unity really better than designing one in 3ds Max?
The short answer is yes! Unity has created a simple built in way of designing your map. It utilizes a point and click method which allows you to paint on mountains, valleys, hills, and streams with ease. The way you shape terrain in Unity feels a lot like Sculptris yet since it's for the specific purpose of making land it works more intuitively for making land forms. Another advantage of building a terrain this way if that it keeps your project centralized and in one place. You won't need to worry about importing a bunch of models, textures, and other assets. If you can make a beautiful map for your players to explore in your game engine there is no need to build it anywhere else. From what I've observed this is a fully comprehensive way to make a play area offering all the same features that any other program I've used (such as 3ds Max) has offered. -What is terrain building in Unity? -Is it a good option for making terrains?
0 Comments
Next year for my senior project, a several people (including me) will be building a VR tour of our school in Unity. To do this, we’ll need to push our skills as designers farther than ever before to create something truly amazing. I decided to get a little bit of a head start though and do a bit of research on how VR works in Unity and if I could find any tutorials that would get me ready for next year.
What I found was super encouraging. There was plenty of support on the Unity website for designers looking to get started in Unity VR. I even found a tutorial series for VR games which I intend to try and complete before the end of this school year so I will be comfortable coding when the time comes next year. The only worry I have now is about the specs requirements for VR and our school computers. I think we will be able to run Unity VR but I’m worried it will be glitchy due to the bad graphics cards on our school computers. Either way we’ll find a way to make things work and I’m very excited to see where this project takes me. unity3d.com/learn/tutorials/topics/virtual-reality/vr-overview -My senior project -Fruits of my VR research -My worries These past couple of weeks in Game Design, we’ve jumped back into Unity. This isn’t the first time this year I’ve worked in Unity so I didn’t have a hard time getting used to coding or any of the general editing skills necessary for Unity. However there is one key difference between what I’ve been doing in Unity and the new stuff I’m currently working on. That difference is previously I had focused solely on 2D games and in our new unit we’ve entered the world of the 3D.
So what’s different? For a comprehensive list you can look at the button below but to make it simple: Another Axis and Lighting. The first difference is rather obvious and is the addition of the Z-axis. This has major impacts both when setting up your scene and when programming. You have to be careful whenever coding not to forget that objects need three inputs when you transform them them. The third axis also means you need a different kind of rigidbody component for the physics to work. Another major difference between 3D and 2D is using lighting. In 2D lifhting is generally very generic. Using 3D suddenly you need to think of how lighting will affect your scene. If you are using a single source of light what will happen when the player gets out of range? Or if you choose to go with a directional light how will that affect how your scene looks and how objects look a small they move around. -what are we doing in game design now? -what are the diffences between making making 2D and 3D games? -Z-axis -Lighting 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! We were planning to start making games in Game Maker last week. However that was before Game Maker glitched out. On some machines it worked fine for certain accounts. On others it failed to even open. So after a great deal of consideration our game design teacher decided it would be best to simply just start working with unity a year earlier than expected. So far we haven't done much with the program but my first impression is that attention to detail will be the hardest part of using it. This is not only because we will be diving into the c# coding language but also because organization seems to be an important thing to have in order to not lose things in your game. Even more so than in Photoshop making sure you name things things will be important as a LOT of different files and codes will be put into one scene. If you aren't careful it would be extremely easy to lose things amidst all of the chaos of your scene hierarchy. The easiest thing will probably be placing things into our game scene as it seems to be a lot like Photoshop and 3ds Max in how you move sprites around the scene. I'm most excited to learn a coding language in Unity and am really looking forward to making my first game no matter how small, glitchy, and boring it might be.
|
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
|