I've finished two game tutorials now, and fairly soon I'll have to make my own game from scratch. I'll essentially be a one-man indie design team, which is a thrilling but slightly terrifying prospect. Luckily, I've done some research. I got some very interesting advice from this article. One of the recurring themes I noticed in the advice was to look for inspiration wherever you can find it, but also to stand out. The article recommended going outside, playing other games, and talking to people. It also recommended looking at pre-existing formulas in other games and figuring out how to redesign them. The article also said to remember that what you're making is art and to treat it as such. I find it interesting that the author included programming as a form of art, and this gives me some relief, because programming has been one of my favorite topics this year. The article says to work from the heart and design games you want to make, which I will definitely have to remember when I'm looking for ideas. Another piece of advice was to work with at least one other person, and while as far as I know I won't be able to do that, I will be using free art assets. The article also warned not to let your ego get in the way; respond to feedback, ask other people when you need help, and admit when you're wrong. This, I think, is very important. So, to summarize:
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:
|
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
|