For the past half year, I have not really touched any bit of scripting in game design. As someone who has been primarily pursuing art both in and out of class, it makes sense that I wouldn't do much coding, but as someone whose second choice of career would be programming, it does not make sense at all.
And I can genuinely say I miss it. My current work in CTE advanced studies is - while pretty fun to me - pretty time consuming but simple work. I mostly simplify polys of models Julia has made. There's no art in that. But I do enough art outside of class to still be creatively fulfilled. However, though poly simplification often is like a puzzle, it's an easy one. I am not fulfilled with challenges involving logic. Obviously I can not expect this fulfillment to come from class at this point though. That would mean asking people who are currently way less rusty than me to sacrifice the quality - or at least speed at which said quality is made - of the game for me to just have fun. Then, though I would have enough logic-based work to be happy, the lack of progress/working game would make me unhappy. So, this means it's time for independent, outside of school coding time. I haven't decided what I want to do for sure yet, but I think I'm down to three options
Basically, I'm hoping to get back into coding, and though I don't have an exact plan for how to do that just yet, I want to get there by Christmas so that I can start working on a project to sharpen my skills again.
0 Comments
It's been a while since I made a post about, or have even thought about VR, but next year (and for the rest of this year) that is going to be our main focus. I wanted to review what I have learned so far about VR/ things to remember, while also looking into any other tips that I can find.
First I'm going to recap what I learned at ECGC last year, which I made a blog post about a while ago. That post focused a lot on the specific features Unreal Engine 4 had, and unfortunately, our computers at school are probably unable to use this engine. However, my interview with Hurley did give me some more general tips for VR. For starters, keeping your frame rate high so as not to cause nausea. This shouldn't be a huge problem for us, but is something to keep in mind. On the same track of not making your player feel sick, we need to be careful in how we do movement. Sudden, uncontrolled movements, especially with non-steady accelerations can really make a player nauseous. The last thing Hurley said is very different about working in VR is the fact that there are two, oddly shaped screens, and your design now has to accommodate that, usually by using special meshes or slightly different rendering. Now to the new stuff. This article talks about getting into VR by experiencing it and just playing around. It also mentions giving the player a horizon line to look at to keep them from feeling sick, making sure everything is scaled correctly so that your player doesn't feel lost or claustrophobic, and it goes on in detail about designing a UI. It emphasizes not having your player have to do crazy things (ie look down to an uncomfortable angle) just to do basic interactions. Most of the interactions should be easy to achieve without putting stress on the player's spine or neck. The Unity website has some other things to say about VR as well. Basically, it's simple to set up a VR project in Unity. You have to do some extra set up at the beginning, but then it's just a matter of changing the product settings to enable VR. While earlier I said we probably didn't need to worry about frame rate that much, the website pointed out that since it has to render everything for both eyes, frame rate will likely decrease. It also says that if you have a VR camera in the scene, you can't move it alone. It has to be the child of another game object, and then you move the parents and the VR camera will come with it. It also unfortunately will not set up different cameras for different eyes, so you have to do that part yourself., but the website does give an example of how to do so. It suggests not using visual effects since they are often unrealistic and costly to rendering time. Overall, I'm glad that there don't seem to be many differences between VR in Unity and VR anywhere else, but since I haven't done VR anywhere else, I'm sure it's still going to take a lot of learning. I wanted to learn more about arrays and summarize what I learned here. Arrays are extremely important and useful in almost any game in Unity, and I know I will need them for my independent project. I currently have very little understanding of them because most of the tutorials I've done lately have had that section automatically completed.
What I Already Know Arrays are ways to create a set of objects, names, numbers, or whatever else you want to put in a group. This is useful for spawning enemies randomly from different spawn points, or random encounters with different enemies that are all in an array together. You have to set up an array and define what is in it, but then from there you can use many different functions to choose random items from within it, or to act upon each of the objects in the group. However, I don't quite remember how all of this happens or the extent to which this can be used. What The Unity Scripting API Says It describes arrays as allowing you "to store multiple objects in a single variable". Arrays are indicated by the type of objects in the array followed by two square brackets - for instance GameObject[] enemies. Then we can use a foreach loop to do something to every game object in that group, such as instantiate all of them. This could be helpful for loading in levels. The only property an array has is length, or how many objects can fit in that array. You can also choose whether the array is serializable or nonserializable. This just means you can choose whether or not you'll see all of the items in the array in the inspector. There are also other methods to join arrays, remove items, shift the order of items, and add items. What I Learned From A Four Minute Video This video does a great job of explaining how arrays work. It shows two methods of putting items in your arrays. You can either, go one by one (ie array[0] = 1, array[1] = 5, array[2] = 17) or just list the items in order (ie {1, 5, 17}). It also explains the "i" or "iterator" variable, that I never quite understood. Basically this variable just acts as a stand in for the array's length so that then we can use foreach loops to do an action to each object in the array. Was This Worth Learning? Short answer: yes. I have a way better understanding of arrays now. However, I think I still have a lot to learn, but I also think that learning is going to have to come from trial and error as I code. However, this is going to make creating games with many enemies much easier. Summary
This post is going to be mostly just my personal reflection on what's been different about creating 3D games - as opposed to making 2D games - so far, as well as seeing what other people have to say about the difference in logic and production of these styles of games.
One of the biggest differences I notice is working in a 3D space changes the way you have to think about positioning things. Often you must adjust both the position and the rotation to get something in the right spot, whereas in 2D games, often rotation is only important to special effects or if a sprite got imported upside down. In 3D games however, your camera angle is important, and so are the rotations of everything else to choose which way they will be facing. On a forum about this topic, one user describes 3D as "one dimension harder". In some 3D games, the player is in complete control of the camera, which complicates things even more since objects in the game must look good from every angle. Speaking of objects in the game, now they are 3D art rather than normal sprites. You have to have the model itself and the texture map. In itself, 3D art isn't necessarily harder than 2D art, it's just different, so this will be a little more subjective. However, another user on the above mentioned forum pointed out that 3D animation requires rigging and skeletons as well as the aforementioned model and texture, so in that sense it is more complicated. Often 3D game assets will also take up more data, so a lot of times 3D games require more tricks to keep them running smoothly to make up for this - like simplifying models. This article makes some other points that I had not really thought about. It points out that generally, 3D games require more assets than 2D ones, just because of the scope of the world generally. It also mentions that 3D games are so compelling because of the realism aspect that they can bring. Then, it again summarizes my earlier thoughts on controls being more complicated in 3D and general differences in art production. 3D games...
So recently we have returned to working in Unity in game design and I realized how much I've really missed coding. Once we started it was hard for me to stop, and this is during a point where I have had little motivation to do other things I really like, such as art. Coding though has just been really fun. And yes, it has been easy tutorial projects so far, but I've really enjoyed them and I love it when I figure out a solution to a problem.
I've also been thinking about college a lot lately, and for the past year I was absolutely focused on finding programs that would eventually get me to a career in animation. I would get frustrated when people even suggested maybe going to a normal college first and doing art school later if that was still what I wanted to do (granted, I had a lot of misconceptions about how college and degrees work at this point, but I also felt like they were just trying to discourage me). However, now I'm thinking that I really do want to do some more experimenting with possible careers. Of course game design seems obvious as it combines art and coding, but there is also web design and building apps and such as well, and I could always do art or coding on the side if I do decide to commit to a career that only focuses on one of those areas. Basically, all this means is I'm going to try to dedicate more time to improving my programming skills while still trying to learn more about animation too. Keeping my options open at this point is a smart move for me to make, and we'll see what opportunities it brings. Also, since it seems like next year I'll be working on a VR project rather than the 2D game that I had planned to work on, I think I am going to try to create the 2D game at home. This probably will take me a while (into summer or the next school year), but I think it will really help me improve my coding abilities and let me make some fun art and practice keeping a consistent art style. In my last post, I mentioned that we would be starting working with Unity soon. Well, now we've been working in Unity for about two weeks. It's been pretty slow going learning to code in c#, but for me it has been pretty enjoyable, but I haven't encountered as many errors as many of my classmates have. Errors or bugs are pretty common in coding, so of course I've had some, but not any that are program breaking.
As for finding and fixing the errors that I do have, I currently don't really have a system. I check for common mistakes, like missed brackets or semicolons and spelling errors, but after than I don't really have much of a plan set in place. For now, this works for me because I can then compare my work to the tutorials to find errors, and since it's very simple code, it usually isn't that hard to end up with pretty good, at least mostly non-buggy code. However, as we get into more complicated coding, I will need to have system to find errors in the hundreds of lines of code that create more complex problems. Mr. B assigned us to read an article on Debugging by Herman Tulleken, and the article made some great points, focusing on how to narrow down potential causes to find the source of any bug. It sounds like fixing bugs is often very time consuming, and as much as I'd like to hope that I'll never have to deal with any major bugs, I know at some point I'll need to employ the skills talked about in the article to fix a major roadblock. The article also said though that debugging is a skill best learned through practice, so while hitting those bugs is going to be frustrating, it will make fixing other even bigger bugs easier in the future. Basically, taking a systematic and logical approach to finding errors, and taking the time to make your code bug- free seem like the best things to do to have clean and smooth-running code. Although we were going to work in Game Maker, technical difficulties have forced us to jump straight into Unity. This is kind of a good thing because Unity is what we would have used next year anyway. We haven't really started using Unity much yet (due to more technical difficulties that make it hard to access the tutorials right now) but we have watched a lot of tutorials for navigating the interface, and we started working on coding in c#.
So far, the game interface seems a little confusing. The tutorials that we watched just went over the basics, and I think to really learn it I will have to learn by doing. I think that I will be able to figure it out, I just also think that it will take some time. I'm really excited to do some more advanced coding, even though I'm sure it will be very difficult for me. I only really know some basic coding things right now, so I'm excited to get into more complex stuff. However, since c# is, "not a beginner friendly type of code," I am a little worried about it since I often make mistakes and can get frustrated when coding. Overall though, I'm pretty excited just to get started making 2D games, and even though I know my first game isn't going to look as nice as the example games, it looks like the program is capable of doing some pretty awesome things, so I'm excited to learn how to use it. This Thursday we got to participate in Hour of Code. I have also been learning a bit about programming both on my own and at our school's programming club. I had participated in the Hour of Code before, so I was able to go onto a few more challenging exercises, though they were still basic. It was all block coding (as in you were just putting commands written in common language in order rather than writing the actual code out) and had cute little "games" for you to play by programming. Though it was easy, I found it difficult at times, though mostly because I was making stupid mistakes or rushing. The art and color did make it seem a little more fun too, and I can see how it would appeal to people who don't typically code.
The Hour of Code would be very beneficial to beginners in the sense that they will get to try out the problem solving aspect of coding without having to know all of the syntax of JavaScript. It's nice because you can gauge whether or not you will be interested in coding. If Hour of Code bores you, then you probably won't want to start coding full-time, since it will be using the same sort of logic but be more difficult. It even shows the actual code if you want to look at it. Though I doubt most people take advantage of this and actually learn from it, it can be a nice template for similar codes, and an example of good formatting. However, if I ever want to become really good at coding, this simple block coding is not going to be very helpful, at least after the first few times I use it just to learn logic. There are plenty of great online resources that can teach all kinds of different coding languages that are easily accessible. For example, Codecademy has taught me the barebones basics of HTML, Java, and JavaScript. Programming club is also an option for learning Java. However, I am behind on learning since I joined late, and despite my efforts to catch up through Codecademy, Basam said that the lesson had skipped over crucial pieces of information, such as scanners, and that I needed to just work on coding from scratch. However, I don't feel like I have learned enough to begin coding on my own, so I will probably need to either look up a tutorial for scanners or ask for help. Basically what I really need to do is learn all of the basics I need to code on my own, and then just get in a ton of practice. Practice makes perfect they say. |
AuthorHi, I'm Abi, a DSA student who likes games, drawing, writing, and acting. Archives
February 2020
Categories
All
|