The code for the second game (more of an interactive novel) I made from scratch consisted mostly of a nightmare chain of eighty-something if statements. Let that sink in. Obviously I considered every method I could conceive of to not do that, but with the start of production bearing down on me, I conceded to the ugly solution (in my defense, it did work). I have, however, learned some things about efficiency: code reuse. It doesn't usually refer to copy-pasting bits of code, though I've done that too. Take one of the most recent tutorials I've worked on as an example: there were three types of enemies, with different health, attack damage, and score values, but they all did basically the same thing. Now, it would have been perfectly possible to make all three different objects in the code, but considering their similar functionality, that would have been, frankly, stupid (I say, remembering the time I did exactly that on a project from last year). Instead, make a single enemy object in all the scripts, and make three copies of the enemy manager script with different models and values set in the inspector, as they all use the same functions. Another way to do this is with classes. If they use a lot of the same functions and variables, make a class and have the objects inherit from that. Essentially, if you can use a larger template to manage smaller assets, you should. Another way to reuse code is to create function calls. I could have made a scene transition function and called it several times during my many if statements in that one notorious project instead of rewriting the code to enable and disable the necessary objects every time. Creating a new function allows you to edit the details in one place instead of, say, twenty, or fifty, or a few thousand. There are also Dynamic Link Libraries, which I am not familiar with, but the gist of it is a set of already written programs to make your life easier. I hope to look into this in the future. Of course, I said this wasn't about copy-pasting, but I will admit to looking back over old projects to see how to get a camera to pan properly or a background to scroll. No sense in figuring things out over and over when I can quickly jog my memory looking at how I've already done it. So, to summarize:
Citations:
Zeeshan, Ahmad. “What Code Reuse Is and Why We Use It.” C# Corner, C# Corner, 28 Mar. 2015, www.c-sharpcorner.com/UploadFile/201fc1/what-is-code-reuse-and-why-we-use-it/.
0 Comments
A few weeks ago I had a problem with my first game. The player character had developed a mysterious attraction to the top of the screen, but all my code was correct. I went through every setting, but nothing was wrong. Turns out, I accidentally applied a collider to the camera. This was what made me realize I'd officially reached the level of coding where things were going to go wrong and I wasn't going to know why at first glance. In addition, I'm going to be coding without a tutorial very soon, which gives me lots of opportunities to mess up and not know what's wrong. Hopefully this research will help me avoid that. According to this article, one of the most common mistakes in C# is mixing up values and references. It's advised to look at the object type definition. Structs are for value types, classes are for reference types. It's also important to remember that value types can't be null; they have default values. In situations where you might think to check if it's null, you need to check if it's equal to its default value to see if it's initialized. I learned that using the Equals method is better than == for comparing strings. It goes byte-by-byte. Using the comparisonType will also make you think about what kind of comparison it is, which is important. I learned that LINQ works with any enumerable collection and that declarative statements should be used instead of iterative ones. It can save a lot of time and code, though it is important to remember it can come at a cost to performance. It's important to consider the objects and their format when it comes to LINQ statements. Remember that an extension method has "this" on its first parameter, setting it apart from other static methods. Make sure you're using the right type of collection. Make sure to use the IDisposable interface and Dispose() method to free up resources and avoid resource leaks. Don't be afraid of throwing exceptions, as it can help detect errors more quickly. Most importantly, don't ignore compiler warnings. Letting them all pile up but doing nothing can lead to big errors that are hard to find. So, to summarize:
Having finally finished with the basics of C#, I’m about to move on to actually coding games. Admittedly, that is a little terrifying. So, as usual, time to do some research. From these two articles, I’ve learned some useful tips for first-time game programmers. I’ve got no idea what exactly the future holds, so hopefully these will help me out. One of the tips I read (and have heard before) is to start small and not get discouraged. Better to have a small, finished game than a large, unfinished one. I also heard to get feedback. Once again, I’ve heard that before, but it’s an important step. Something very interesting I read was to focus on the content and be willing to redesign if needed. It’s easy to get attached to your vision, and this is definitely a trap I see myself having to avoid, but if it’s not working it’ll only lead to getting stuck. I also read not to get caught up in doing things from scratch when there are already tools to get it done. Reuse elements from within the game or from previous projects rather than create new ones. In the case of things like keyboard controls, always follow the rule of DRY, or Don’t Repeat Yourself. This ties back into what I said before: you might want to do everything your own way, but that won’t always work. Another thing I read is not to commit too much time to a project. This is another trap I see myself falling into, but sometimes you just have to move on. One other important thing: don’t think you know everything. Admit it when you’re stuck. Of course, it’s important to try and solve the problem on your own, even if that means doing some research online. So, to summarize:
Writing C# code has been going well, but there's a long way to go. Time for research as usual. I read this helpful article and learned a few interesting things. One of these was that you can actually put comments (using a //) on the end of lines, after the semicolon of course. You can check if two objects are equal without knowing if they're null by using an Object.Equals method. This is much shorter than some other ways of writing it. In a similar vein, Extension methods allow you to add new methods to existing types without having to modify or recompile. I'm still learning how to use methods, so I don't quite understand this yet, but I predict that I will soon. I also read this article. One very useful thing I learned is that you can use tuples to return multiple values from a method. Since I'm working with tutorials I probably won't be doing this yet, but it's good to know for later. I also learned that you can flag enums to access the enum values. Another thing I learned is that data types can be changed using a Convert class. Most of these tips seem to have a couple of things in common. They're about keeping things organized and avoiding the creation of long and unwieldy code. Efficiency is key. So, to summarize:
As mentioned in my previous post, in the past week or so I've been coding C# in Unity Engine. This is the major step in the path towards actually making playable games. That means it's time to do some research for the future. I learned some incredibly useful things from this article. One of these things was how to identify Unity errors using site searches. This is done by typing "site:unity3d.com" and the error message. This will search through all the Unity site's pages for information about the error. Another useful thing I learned was that garbage collection (GC) can cause stuttering frame rate. One of the pieces of advice the article gives is to create game objects early on to enable and disable as needed, rather than constantly using instantiate and destroy. Another way to do this is avoid concatenating strings with + when not needed. Multiple words can be used within a single string, so there's no point separating them using a + when they can be placed in the same pair of quotation marks. This will merely slow down the program. I also learned that when developing a game, there is likely to be duplicate code at some point. Instead of bogging yourself down with more code and more maintenance, create an interface. There's no point in coding the same thing twice if it's not necessary. The article recommends not to overdo it, though. I have not yet learned how to create interfaces, but I will keep this in mind for the future. So, to summarize:
I'm finally learning to write code! Using the program Unity, I've been coding C# for about a week, and already I'm thoroughly engaged. Here's what I've learned in my first week. One of the first things I learned is that syntax is very, VERY important. A single mistake can wreak havoc. Double check everything, as it will save you a lot of errors. I also learned that getting a second party to look over your work can be very useful. I once spent several minutes going over my code with no clue what was wrong, when a classmate glanced over it and pointed out a simple mistake in naming a file. This was also where I learned to look for the cause of errors in places you wouldn't necessarily expect. Another example of this is when I couldn't get the right number to print, despite it being in the code. The problem turned out to be that the previous default was still in the Inspector and had to be changed. I had assumed that changing the default in the code would change the value in the Inspector, so I didn't think modifying the value in the Inspector would change anything. I later learned this wasn't the case and also learned that making assumptions is a bad idea when coding. The computer simply does exactly what it's told, so it's important not to jump to conclusions. Test anything that might have an effect, or better yet, ask someone else like I said before. So, to summarize:
|
AuthorI'm moving on to my 4th (and final) year as a Game Art & Design student at Durham School of the Arts. I'd like to call myself an artist, but I'm a programmer at heart. Archives
February 2020
Categories
All
|