I know I promised we would start coding. But as I started reviewing the GameDevHQ videos, I was reminded of why I spent so much time watching even the most basic coding videos. The program is after all, intended for new game developers, even those with no coding experience. But there is so much happening in the background of these videos it’s hard to remember all of it. So, it makes sense, even if you don’t need the code review, to watch them. In fact, as I’m finding out, it even makes sense to re-watch them.
The section on “Creating Game Objects and Applying Materials” is where the game making starts. It’s actually in the “Project Setup” section and is intended just to start familiarizing us with the Unity Editor. But it has several good points that go by fast, worth remembering. In fact, even when we actually start creating our player game object, there is very little code, but tons of good information.
In no particular order, here are some useful tidbits.
- Set the camera position to (0,0,-10). This allows your player object to start at position (0,0,0) and be in perfect view of the camera. Obviously, the exact z-coordinate will vary, but the concept is important to remember.
- When using the scale tool, click and hold in the middle of the tool and drag the mouse to resize all three directions at once.
- The Mesh Render is the visualization component of the game object. This is useful to remember when we start getting clobbered with vocabulary such as rendering, shaders, materials, etc.
- A Material Component can be attached to a game object by dragging and dropping it on the game object in the Project Hierarchy, the Scene View, or by dropping it on the field containing the “Default Renderer” in the Mesh Renderer component of the game object.
- Each component in the Inspector has a “?” icon which is a hyperlink to the Unity API documentation.
- 16:9 is the standard HD ratio which makes it the most common choice for modern screens on a variety of devices.
- Delete the Sample Scene, create a Scenes folder and create a new, appropriately named scene.
- Many number fields can by adjusted as if they had a slider. Fly over the field label and see if you get a bi-directional arrow added to your mouse pointer.
- Ctrl-s often…
- One “unit” in a Unity Vector3 is equal to one meter in “real-life.”
- The [SerializeField] code we put before a private variable to make it show in the Inspector is called an “Attribute” in C#. There are others. The purpose of these attributes is to provide meta-data about the variable, or even code block. This meta-data can be used by C# using a feature called “Reflection.” For the curious, this is how the Unity Editor knows to expose the variable and its value in the Inspector.
- Restore the script value to the variable in the Inspector by selecting the gear icon -> reset.
- Private variable .NET naming convention of _*.
- Using “new” excessively can create a performance hit. Although not discussed, this, along with garbage collection, could cause a re-evaluation of variable scope and creation. Especially at 60 frames per second…
Now, not all of these suggestions will apply in every situation, but they do represent items and concepts to be aware of. Obviously, depending on the situation, you might not always start with the camera positioned at (0,0, -10), but starting position of the camera should be something you make a deliberate decision about. Choosing your screen size is another.
Other suggestions you may just disagree with. For instance, I’m not much a fan of naming conventions, but the videos make pretty consistent use of the leading underscore for private variables. I don’t think I’ll explain my own preferences right now but may do so in a later article. Keep in mind, should you ever be working as part of a team or for a company, they may have their own conventions you are expected to use. That being said, it’s not wholly a bad idea, especially if you are new to coding. The primary point we can all agree on is your names should make some sort of sense.
Any discussion about performance and runtime optimization is useless in a generic sense. Often times, there is not even a good, all-the-time answer. Runtime performance is often a balancing act of many factors.
Note, this is NOT the same as what I would call, “design optimization” which is more about the layout and readability of the code. Design optimization, often called “Refactoring” is an extremely important task. The videos often tell us to “make the code our own.” This is their way of saying you are being showing a very simplistic approach initially. But if you always add code in this manner, things can get more than a bit messy. Again, the videos stop often to do a little code cleanup. This cleanup process can, and should, involve more than just removing working comments and ToDo notes.
As I continue working my through the videos and my old code, I’m sure I’ll add to this list. But that’s it for now. Next, we code! (promise….)