At long last, we're moving back into Unity (exciting)! After having worked on 2D games and 3D modeling, we're finally going to start creating 3D games. It's research time. What should a game NOT be? It shouldn't be confusing, but it also shouldn't handhold the player. It shouldn't be too hard or too easy. It shouldn't be devoid of rewards for the players hard work (i.e., it shouldn't be pointless). It shouldn't make players want to give up. It shouldn't be unfair. It shouldn't be full of glitches and bugs. It's very important to make games understandable. The player needs to know what they're doing, or they won't want to play. Integrating tutorials directly into the gameplay is usually the best method, and pretty much standard by now. People usually don't open games because they want to read a long instruction manual. Besides, handholding can feel restrictive and patronizing. Let the players feel like they've actually accomplished something–by letting them actually accomplish something. Let them figure it out. They're not idiots. It's also important that players are rewarded for doing well. This is especially important if the game gets repetitive (which it generally shouldn't, but it's pretty unavoidable to some extent). Most people won't want to complete tasks in-game if there's not some kind of reward. Then it feels pointless. To make sure the game isn't pointless, plan ahead. Throwing things together will lead to poor design, confusion, and less opportunities for the player to fully use the game environment to their advantage. It needs to make sense and it needs to be conducive to good gameplay. On the topic of repetition again, add variety. Unless you're making an arcade game (and I know I'm not), the player expectation is going to be that not everything is the same. Don't copy-paste your game world into existence; it's going to get very boring very fast. So, to summarize:
Citations:
“Keeping Your Players Engaged - Tips for Great Game Level Design.” Pluralsight, Pluralsight, 6 Feb. 2014, www.pluralsight.com/blog/film-games/keeping-players-engaged-tips-great-game-level-design. Staff, Creative Bloq. “10 Tips for Building a Better Game.” Creative Bloq, Creative Bloq ART AND DESIGN INSPIRATION, 17 May 2012, www.creativebloq.com/inspiration/10-tips-building-better-game-5126304.
0 Comments
I mentioned in my last post that I had found new appreciate for the game design document. Our lack of one has certainly made this project difficult. With that in mind, I did some reading. One of the major reasons to have a GDD is documentation. You need to know what's supposed to happen and be able to keep track of everything in order to know what ought to be removed or redesigned. It also helps organize all the ideas and serves as a to-do list. It tells you what you're missing. This would have been a huge help earlier in development. The closest thing we have to a checklist is our Trello board, but there's no one place with all the information. The GDD helps to make sure everyone is on the same page. There's been a few times when I noticed our artist making sprites I wasn't sure when I was going to implement, or found out certain mechanics weren't intended to work as I had thought. On a shorter schedule, this could have been disastrous. It's also important to keep up to date, to make sure no one spends time on something unnecessary. Again, this could be disastrous on a shorter schedule, and even with our current schedule. I'll be keeping an eye on that Trello board. The article I read suggested creating it in stages. Unfortunately, we didn't really have time to plan in stages, and a lot of time was spent at the beginning working on the UI of all things. Suddenly we were in full production mode with little more than a pitch in slideshow form to tell us what to do. The article also suggests having one person in control but receiving feedback from other team members. This idea became a difficult situation for me, since as our previous deadline drew ever nearer and I still was unsure where to go with the mechanics, I was torn between making up whatever I could and following the intentions of our team lead. Thankfully, the introduction of a story script and updates on our mechanics document has helped to fix this. So, to summarize:
Citations:
“How (and Why) to Write a Great Game Design Document.” Game Development Envato Tuts , Tuts , 24 Apr. 2015, gamedevelopment.tutsplus.com/articles/how-and-why-to-write-a-great-game-design-document--cms-23545. I've had two experiences making games with a team. Neither has been particularly ideal. Why? Time to find out. One of the most important things to do is to make it clear who's supposed to do what. This year, we've done that...sort of. We know who's doing the art, and who's doing the programming (me), but it took far too long to figure out who was supposed to do the other things that needed to get done. Two other important things are to set goals and communicate. Communication took awhile–over a week into the project, I still didn't know the mechanics of the game I was supposed to be programming, and even after making a document to lay everything out I still didn't have a clear outline. I'm beginning to appreciate just how useful GDDs are. We did set goals, and kept them organized on our Trello board, which had admittedly fallen behind. I made an effort today to update any cards pertaining to my work. Another piece of advice was to make decisions together. I tried to foster that. I've asked for input from my team lead and artist and have reigned in suggestions when I had to. I can't speak for anyone else here. More tips I read didn't seem to offer answers. I've heard that one should play to individual strengths and put people in roles that suit them. I didn't have much of a say in that, since team leads assigned roles, but seeing as I'm the team programmer, I think we accomplished that. I read that you should get to know each other and develop relationships outside of work. We've known each other for quite some time; this certainly isn't the problem. I read that team members should promote sharing–I did my best to do that. I set up the document and made requests for input. I've done what I could. I read more tips about setting ground rules to prevent arguments and controlling conversations, but a lot of this simply doesn't apply. Based on what I have read, the most obvious issue to me seems the communication and lack of planning. We didn't know what we were doing and who was doing it. That's been improved upon now, and I think we'll pull through. I hope this improves next time. So, to summarize:
Citations:
Mattson, Dave. “12 Tips for Fostering Teamwork.” Entrepreneur, Entrepreneur, 23 Mar. 2016, www.entrepreneur.com/article/270024. “Top Tips for Effective Teamwork.” Uplift Events Blog, Uplift Events, 19 Apr. 2018, www.upliftevents.com.au/blog/top-tips-effective-teamwork/. This is my last personal reflection this school year. Unbelievable, isn't it? Since this is probably the final post of this school year, I've decided to discuss how the year turned out, since I've realized something I wasn't at all expecting. I came into this class convinced I was going to be a 2D artist. The problem was, I wasn't good at it, and the work it took to get better seemed like a nightmare. I couldn't draw well, so I hated drawing, so I didn't have the motivation to improve, so I still couldn't draw well. You can see where that's going. Then we moved on to 3D modeling and animation, and I remembered how much I actually liked it. I wasn't great at that either, but I honestly enjoyed it more than 2D art. Then we moved on to programming. I had felt a growing sense of dread as the programming portion of the year approached. Code seemed like this scary, incomprehensible thing I was going to have to slog my way through. It was something I shouldn't be excited for. Then, we actually started coding, and instead of slow, tedious work (well, it actually was a little tedious) like I expected, I tore through the tutorials. I realized that I actually liked writing code. It all seemed so logical, like a puzzle, and it made sense to me. I always assumed I 'd never get into programming; I looked at it with a sort of disgust. Turns out, "don't knock it till you try it" is right. The topic I thought I'd hate turned out to be the topic I most loved, and the thought that I might not go straight back into coding next year actually scares me a little. At this point I've made three games by tutorial and I'm finishing a fourth by myself. I hate to admit it, but I fell victim to the classic rookie mistake of aiming too high on my first go. I'm having to cut back, mostly because I overestimated what I would get done in the amount of time I had left, but the important thing is that it's still an actual, playable game that I made myself. I've also discovered the mechanics I need to learn more about, and I definitely intend to keep improving my game over the summer. The other big thing I'd like to mention here is that I came to an art school not knowing what I wanted to do for a career but with a a vague idea that I'd be a writer. I entered the game design pathway thinking I'd just use some of the skills, and I meant to do it more as a hobby. I didn't actually expect I'd join the game design industry; that was just a sort of fantasy. Now I'm realizing that while I love writing stories, it's not something I'd really want to do as a job. Game design (especially programming), however, is something I think I really would like to do as a career, and I'm starting to get on track to make that idea into reality. I guess I might become a writer for work after all–just not the kind I expected. That's all from me. I might give occasional updates over the summer on my game or any other interesting developments (pun fully intended) in my game design education, but until next fall, peace out.
I'm officially designing my own game from scratch–no tutorials! I'm thrilled and terrified in equal measure. I'm officially a game developer, so now what? Luckily, the Internet is there to help. The first article I found had five pieces of advice. The first was to figure out if I want to be a programmer or an artist. Well, that's pretty easy. I like art for sure, but turns out I like code more. That's why I'm using free downloaded art assets. The article goes on to mention C# and Unity. Well, I'm set there. The second piece of advice was to enjoy myself. So far, so good! Tip number three was to find a focus within your realm of development. That won't really be possible with this game since I'm working as a one-man team, but it's something I ought to consider for the future. The fourth piece of advice was to get experience. Well, I've finished three games made by tutorial (though I did have to add some features to one of them), and I'm about to start a fourth pretty much from scratch, so I'm already working on that one. It also mentions looking for an internship, which is funny, because I've been meaning to do exactly that. I guess I should get to it. The fifth piece of advice was not to give up. Well, at the moment, I couldn't if I wanted to. That's all great, but what about advice for right now? This article came to the rescue, and I noticed three important things. One piece of advice I noticed right off the bat was to implement and test side by side. This is good advice. I know this is good advice because the last game I worked on mysteriously bugged out and I didn't check it immediately. It's a pain trying to debug when you have to hunt through code unrelated to your problem. Another piece of advice the article gave was to start with a simple game–the example given was Tetris. I'm planning on making a simple platformer, so I think I've got that down. It also recommended playing other games and gathering inspiration from those. I'll have to keep that in mind, because I don't even remember the last time I played a platformer. There you have it. Wish me luck! So, to summarize:
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:
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:
|
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
|