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.
0 Comments
The last project from class that we had to do was to make terrains within Unity by using tools already built into the program. I did not know that Unity had that capability, so I thought it was really cool. However, I'm sure there are many features to the terrain tool that I still did not even use, so I want to look into some of the other things it can do.
First, the things I know it can accomplish. The tutorial we used covered creating a terrain, editing the height map to create mountains and valleys and everything in between, as well as adding grass and water, and adding textures to the terrain. I also saw that there was a feature to add trees, but we never used this feature in the tutorial. Just by going to the Unity online manual I found an answer to one of the questions I had when going through the tutorial we used in class, which had been created in an older version of Unity. The tutorial talked about creating plateaus, but the method that they used would not work for me. The manual however shows that there is now a specified tool specifically for this purpose. Instead of setting a maximum height on the whole terrain as the tutorial said to, now next to the raise/lower height button, there's a new button, paint height. Here you can enter a target height that the terrain you are currently painting will not exceed. This is really cool because it means that you can make multiple flat areas at different heights more easily. The next page on the Unity manual is a little more interesting: trees. Trees differ from grass in that they are actual objects with colliders. The environments package comes with default trees but also makes it easy to create your own trees from within the program. Then, there's also a setting for tree density, making it easy to quickly place either just a few lone trees, or an entire forest. Unity is very nice in the way that it renders trees so that when you're further from them, it will use shortcuts to keep the program running smoothly (ie maybe making some distant trees appear more flat than 3D until you approach them, and not adding fancy effects like wind to them quite yet.) The tree page also mentioned something called "Windzones" which I noticed had its own page. These are interesting because they can either be components of an object or their own game objects. The manual does not seem to suggest any benefits to using one form over the other. However, they are very useful. This is what will make all of the trees on the terrain sway in the wind more realistically, but can also be used for smaller things, like an explosion that blows back the things around it. While I'm sure there are many other features to the terrain tool, I feel like I've already found a lot of new information, and will continue to learn more as I play around with this tool more often.
Trello is a free program that lets you plan projects out. While it is not something we've ever really gone over in class, it is a tool that Mr. B highly recommends and that I've used for two different projects in the past and will be using for this upcoming year as we create a VR model of our school. I wanted to talk about some of the things I really like about it, and some things I struggle with.
I have earned the title "Queen of Organization" simply for being able to press a few buttons. Literally. The program is incredibly easy to use, I just happened to be the one who put the time in to use it, and for that, I became "the organized one". You make a board for your project and then you can make multiple lists of different things within that board. Each list has cards which can hold information, checklists of things to do, pictures, and more, and you can put due dates on each card. This is my first qualm with trello. Each card can hold an entire checklist, but yet, you can only put one due date per card instead of being able to put a due date on each item in the checklist. Usually this isn't a problem, but if you have a team who is really bad with time management it would be really useful to give more specific due dates for little steps. The best alternative to the checklists would be to make each item on the checklist its own card, and use the sticker feature to put a sticker on each card when it's done. That way, they can each have a due date and still get checked off. The other thing that I wish Trello had was an easier way to share files through it. It is a free program so this may be a lot to be expecting from it, or maybe I just haven't found how to do this yet, but every time I've used Trello I've also had to have a Google Drive folder set up for us to share assets. The nice thing about this is that the link to this folder can be in a card on the Trello so that it's easy to find, but it still would be easier to have everything in the same program. Another feature that I think would be nice is a "calendar view" type thing. If you have multiple lists, it would be easy to miss things. With a calendar view it would be much easier to see which due dates are the closest, and then go to that card. I could always set up a separate calendar, but again for the sake of convenience, it would be nice if it was in the same program and just automatically set up. Overall, I think I would recommend Trello to others though, because for a free program, it is very good, and I don't know of any better free tools (though I may start looking into some other ones just to see). It has been very important in past projects, especially for our Durham game, in keeping everything organized and making sure we were getting things done in time and not overlooking any necessary components of the game. 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
|
AuthorHi, I'm Abi, a DSA student who likes games, drawing, writing, and acting. Archives
February 2020
Categories
All
|