Author: digm520admin
//
I wanted to note this as a possible useful source since my thesis work will involve spawning a lot of objects, and in varied and rather precise positions. With how important of a focus it will be, I figure more sources on the generals of spawning objects would be good to know to give me as many tools to use as possible.
//
My pulley system needed to create a rope with objects attached to it, as well as objects which act as the pulley wheels which will support the rope. The positioning of these wheel objects must be in line with the rope, but below it. Using the HFF system, the rope gets generated and then falls, draping itself over any objects below it.
Keeping those requirements in mind, I also wanted the system to be able to generate a varied amount of these pulley wheels and place them in varied positions below the generated rope. Having the option for multiple wheels became more important when I noticed that sometimes ropes with heavy objects attached can break through rigid body wheel support objects, but having more (therefore more support) can sometimes alleviate this issue.
So to summarize, I wanted a system that could choose a varied amount of positions along a randomly determined line, with extra rules dictating how far these positions should be from the ends of that line, and how much of a space buffer should be given to each position (so when an object is instantiated at one of these positions, it does not collide with another instantiated object).
To keep the system simpler for now, since the system needs to fall into place anyway, I was specifically randomly generating the rope on the xz plane at some height y. The wheel positions are then generated on basically the same line, but some distance below that line (to ensure the wheels are within the rope line, but below for the rope to fall on them).
The difficult thing with this position range system is that choosing a position for an object removes a specific range around that position to account for the space needed to instantiate an object at that position. Because of this, I needed a system that could update the range options everytime a position was chosen. I came up with a system that could determine how to update the ranges everytime a position was chosen, and could also determine if a range needed split into multiple.
The first range is the easiest to determine. It is just the full range of values between the beginning and the start of the wheel positions, with a buffer at each end factoring in the value for distanceFromEnds that we want to give to keep objects from instantiating too close to the ends.
With this first range created, we choose a random position within this single range. After that is when the adaptive range system comes in. Depending on the position selected, there are several possible options to account for the options that have been removed from the range:
One issue with a system that creates multiple ranges is that these ranges can be different sizes. So if at some point in the process I am randomly selected a range first, to then select values from, each range will inherently have the same chance of being selected, regardless of its size. To remedy this, I used a weighting system.
Each range has a weight in the range (0, 1] (The minimum bound is exclusive, as nothing should ever have a weight of 0, but the maximum bound is inclusive since if there is only 1 range it is the only option) representing how much its individual range covers amongst the total coverage of all the ranges within a list of ranges. This is easiest to explain with an example: We have 3 ranges: (0, 2] (2, 5] (5, 10]The total range coverage is: (2 – 0) + (5 – 2) + (10 – 5) = 10The individual weights for these ranges are then:Range 1 (0, 2]: Weight = (2 – 0) / 10 = 0.2Range 2 (2, 5]: Weight = (5 – 2) / 10 = 0.3Range 3 (5, 10]: Weight = (10 – 5) / 10 = 0.5
So when we go to select a range, we randomly roll a number in the range of (0, 1] and use this to determine which range to pull a value from. This works by checking if the rolled value is less than or equal to the first range’s weight. If this is satisfied, that is the range to choose from. If not, it moves to check the next range’s weight. To fit this within this (0, 1] range, each time a range is not used, its weight is added to a pool to add to the next range’s weight. This helps move the weight check along the range of (0, 1] with many values significantly below 1.
To follow the previous example to show this in action:Our randomly rolled value to select a range is: 0.75General Formula:Check range n: Is rolledValue <= (rangenWeight + weightCheckPool)? No, add rangenWeight to weightCheckPoolCheck range 1: Is 0.75 <= (0.2 + 0)? No, add 0.2 to weight check pool and move to next rangeCheck range 2: Is 0.75 <= (0.3 + 0.2)? No, add 0.3 to weight check pool and move to next rangeCheck range 3: Is 0.75 <= (0.5 + 0.5)? Yes, use this range to select a value from
//– Basic setup
– Objects attached to both ends of a rope
– Rope hangs over something
– Setting Up First Basic Instance
– Ropes
– these are very touchy in HFF
– they usually use a setup where there is a start and end transform position, and several
rope segments get instantiated between these two points to produce a “soft body” object
– need to make sure neither of these points is deeply within another rigid body object,
or physical interacting object as this can lead to a constant state of colliding
– constant colliding causes the rope system to act erratically on its own
– Attaching a Physics object to both ends of a rope
– the original rope objects use a physics object at one end, and a fully fixed positional
object at the other end
– we need both ends to use a physics object
– This is done by:
– Making sure both objects are rigid body objects
– In the Rope script:
– Make sure to assign “Start Body” as one object, and “End Body” as the
other object
– Using “Copy_YellowMetalMechMediumCradledPlatform2” as other physics object
– this prefab initially has a hinge joint attached to it
– there is something about this that fixes the entire platform in place
– removing this allowed it to work as intended
– I dragged the reference of this main object in as the “Connected Body” for the Fixed Joint
component on the RopeStart gameObject in the pulley setup
– Issues
– I was using “Copy_YellowMetalMechSmallWinchSpool1” as the central wheel for the pulley setup, but sometimes the rope would break through it
– Appeared that such massive objects can cause the rope to clip through this sometimes
– I alleviated this by having the rope go over two winch spools (similar to the setup found
in the Demolition level)
– this also broke through one of them eventually while I was increasing the mass of the ball in Play mode to see if I could raise the platform
– Constructing “Create Pulley” script
– Needs:
– Rope
– Physics object at each end
– Total: 2
– Pulley wheel object
– Total: >= 1
– Parameters (words)
– Rope
– Length
– Start Point
– End point
– Physics objects attached
– Type of objects
– Mass
– Start point
– End point
– Wheels
– Quantity
– Position
– Important Relationships:
– Wheel(s) must start below the rope
– Must be on a similar plane, but lower on Y position
– End position must be “length” away from start position
– Length = End Position – Start Position
– This can be done with using Random.OnUnitSphere to pick a random
direction in 3D space
//
I have been using private fields more often in my coding, even if it is not particularly necessary in Unity, as it is considered a better practice to keep control of the scope of your variables. I have also been working with code that needs to communicate outside of its own scene in Unity, which requires unique work as well. Both of these have led me to use various getting and setting techniques, and I am trying to clean up my code and do it more properly by learning more about creating properties and using getters and setters better.
It is my hope that these three sources cover everything that I am looking for, as well as giving me a better understanding overall of the capabilities of using these properties.
//Unity Learn Course – Beginner Programming
This has basic coding principles, like formatting code files, naming conventions, namespaces, and effectively using comments. These are all concepts I know about, but only have some experience with so seeing another view should be beneficial. One of their main principles is “Consistency trumps style”.
The main points for this section are: value of conventions, anatomy of a code file, and formatting guidelines and tips.
Conventions provide a consistent look, make your code more accessible, makes it easier to maintain and extend, and shows your understanding.
Starting basic script structure: At the top there are using directives for namespaces. This is followed by the definition of the class. This defaults to deriving from Monobehaviour, and creating methods for Start and Update.
You can change your code formatting preferences in Visual Studio on Windows by going to Tools -> Options. Here, you can find “Text Editor” and find a bunch of formatting options, some for general purposes and then others for specific languages. Under C# for example, it breaks down even further into “Code Style” and more formatting options. These can be used to change how Visual Studio does default spacing for you, bracket placement, etc.
The values of conventions (again) are: provide consistent look to your code, makes your code more accessible, makes it easier to maintain and extend, and show your understanding.
The benefits of naming conventions are: tell us what something represents, tell us what something is, leverage capabilities of modern IDEs, and (although less common currently) can indicate scope.
As usual, they say make your names descriptive (without being too wordy) and be consistent.
The capitalization techniques are: Pascal Case and Camel Case. Pascal Case capitalizes the first letter of every word, and single word identifiers are capitalized. Camel Case starts lower case, and only capitalizes every word after the first. For single word identifiers, camel case leaves it lower case.
General Naming Guidelines:
Use Pascal Case:
Use Camel Case:
There was an older convention to prefix field names with an underscore, an m, or both. This is not done as much anymore, but it is good to mention since you will come across it often. These were originally done to show a difference in scope between variables (i.e. local and non-local variables), but it has been deprecated with the advancement of modern IDEs. They will show you the scope of a variable just by hovering it.
These are spaces or containers for names. The benefits are modularity and avoiding naming collisions.
Modularity is accomplished by helping group types, classes, delegates, interfaces, etc. logically under a specific namespace. For example, the UnityEngine namespace contains a lot of commonly used tools such as Monobehaviour or Debug.
Fully qualifying the reference: This is when you precede something with its namespace to directly specify which reference you are using.
Including the namespaces used in the using directives at the top of your code file tells you and others that see it what types of objects they can expect to see in the file. Namespaces can even include other namespaces.
This occurs when the same name is used to reference different variables representing different things. Modern IDEs help minimize this issue, but it can still happen.
It is not mandatory to put your own code in namespaces, but it is strongly recommended to use in larger projects with project specific features to help keep your code organized and make it easier to maintain.
Regions are technically preprocessor directives, but they are used often in Unity for their visual purposes. They provide collapsable sections of code to help focus on what is necessary.
Regions are declared with the word region along with a “#” and the name of the region. Everything within the region is contained within a set of brackets. Finally, you end the region with the keyword “#endregion”.
As expected, a lot of this is covering topics I already know, but it is good to confirm some of the practices I use and go over the terminology again. For example, I do still see a lot of underscores used for indicating scope of fields but it is not something I particularly use so it was nice to confirm that its less standard practice now with modern IDEs. These tutorials consistently use all the proper programming vernacular, which is a very nice plus over a lot of other learning sources I use that just want to get across the end game result as quickly as possible.
//ARTIFICIAL INTELLIGENCE FOR GAMES – by Ian Millington, John Funge
This was just an interesting reading I came across for a gaming AI class, so I wanted to note it for the future. It looks like it covers a lot of interesting topics so it could serve as a nice foundation for starting to understand a lot of the basics on gaming AI.
//UnityLearn – Intermediate Programming – Pt. 01
Unity Learn Course – Intermediate Programming
Many parts of your game will need to communicate with one another. You can directly makes these connections between different objects as needed as a way to accomplish this. This method however does not scale well, and becomes very complicated and hard to debug.
This is where the concept of having a GameManager comes in. This provides a central location where systems can communicate through. They can also hold important central data.
The tutorial’s basic definition of a GameManager was “A central location for data” which can serve one of the following purposes or both:
This Swords and Shovels tutorial will specifically use their GameManager for rule management and some informing.
The GameManager needs to be accessible to all the systems that need it. The GameManager should be globally accessible for the life of the game.
They reference Scenes and Prefabs as Unity Containers. They represent collections of assets and use particular scripts to connect them. In Unity, Scenes are generally large collections of assets, while Prefabs are for smaller collections.
One technique is to have a persistent scene which contains all of your managers, since it will most likely even have responsibilities for loading and unloading other scenes. This is the technique that will be used in this tutorial. This also happens to be the technique I was using on my personal tower defense scene management project.
You most likely will not be able to design and construct the perfect GameManager for your game immediately. Games are organic objects and you will need to change and adapt your systems as you build in most cases. With this in mind, it is important to build in a way that supports growth (but without over designing).
When starting to make your GameManager then, you want to layout the basic requirements you know it must have. The requirements for this tutorial are:
This part finally gets into working with the Unity project. There was a package to download that contained all the necessary objects to get you up to speed to start working at this point.
When you create a script named GameManager in Unity now, it gets a unique icon that looks like a gear. This does not particularly do anything special, it is just a visual to help you identify the GameManager since it is normally a more important class.
This step mostly just wanted to have you get the package loaded in, create the GameManager script, and make a new Boot scene that will handle starting everything (as well as put that scene in the build settings). It also mentions how it is important to put all your scenes in the build settings to make sure they are accessible with your system.
There is a actually a lot going on with the package I obtained for this tutorial, so it may be worth looking into the beginner part of this tutorial before progressing with this part. Even though it will most likely cover a lot that I already know, I think there is still a good bit of valuable information for me to gain from going through it.
//Unity Learn Premium – First Look Tutorials
The Humble Bundle had a sale on a lot of interesting Unity content, including a year subscription to some learning tools such as Unity Learn Premium so I decided to finally grab it and look into it. There are definitely a lot of courses and videos I am interested in checking out, so I just wanted to quickly go through and list a few to do as soon as I can.
I am not sure how well these links will work since they will mostly be through this paid service of Unity Learn Premium, but I am hoping they at least work to get me back there when I want to use them.
Unity Learn Course – Intermediate Programming
Unity Learn Course – Advanced Programming
Unity Learn Tutorial – ScriptableObjects
These three stood out to me very quickly as useful tutorials and courses to look into. The courses will be very helpful at just covering general programming in Unity. Even if they cover some topics I have already done, it is always useful to find new and different ways to build systems or implement certain programming techniques. And finally, the ScriptableObjects tutorial just covers a topic that I still need to look into more and just have not yet.
//
The first link leads to the following youtube video list that contains the full course on HLSL shader fundamentals. This may be exactly what I was looking for (although apparently the course was first published in 2007, so some of the information is a bit dated). Regardless of age, this is supposed to be a very good run down of HLSL and shaders in general. This will help my search for understanding the basics of shader language while I continue to learn about Unity’s shader graphs separately.
//
This tutorial actually dealt with using the Unity Animator to create a sort of state machine setup. You can add behaviours to animation states, which are already setup in a very similar way to the last AI State Machine tutorial I did from Joey the Lantern (Tutorial #2 in this recent tutorial list).
These behaviours already have methods such as OnStateEnter, OnStateExit and OnStateUpdate (as well as several other more animation focused methods). This tutorial uses these to setup the logic for their state machine.
While this seems nice for getting something running very quickly, especially from an animation focused perspective, I think I would rather use the setups from the other tutorials that start more from scratch and allow you to develop the full system yourself. I would much rather follow Tutorial #1 and Tutorial #2 than this one.