Excuse the horrible pun in the title. Anyway, I'm close to being an adult, and that means I have to start seriously thinking about careers, and one of the huge keys to that in the gaming industry is having a good portfolio. One of the main points of GameIndustry International's interview of a team from Carnegie Mellon University's Entertainment Technology Center (ETC) was the importance of a good portfolio. Game programs need to teach students core industry skills, rather than only software-specific information, and give them the opportunity to create a solid base of work. Students have to be competitive entering the industry, and the best way to be competitive is to show proof of one's skills; game companies look very seriously at portfolios when evaluating a candidate. With that considered, I need to start taking this portfolio very seriously, as one day it just might get me a job. That is, to be honest, a little terrifying for me, considering that at least for the moment, I'm more of a programmer than an artist, and producing a full game is going to take a lot longer than making a piece of art–unless making art should be taking me much longer. Additionally, this class isn't even about programming, so I won't be focusing on that anyway. For the moment, I need to start working on art, probably both 2D and 3D, as often as possible, and it has to be good art–which is not my specialty. I guess I have a whole year to learn. There needs to be variety, too, and actual drawing skill, not my sad attempts at creating hilariously cartoonish illustrations based more on Photoshop loopholes than any real talent–or worse, quick photo edits that don't require anything more than basic knowledge of the program. I should probably also learn to use that drawing pad I've got laying around. In my own defense, I don't claim to be a good artist. In terms of revamping the actual presentation of the portfolio, I really ought to fix the sizing of my images, and maybe come up with a better caption format. In the future, this portfolio will obviously feature a lot more code-based works, seeing as I most likely will look for programming jobs. Making your own game is a huge boost to a portfolio, especially a good game. I've done it before, but it was sloppy and unfinished; I've been meaning to fix it up for a while now. I'd most likely have a section under Student Work leading to downloads for my game(s). Videos of gameplay would also be helpful. So, to summarize:
Citations:
“How to Build a Game Designer Portfolio: 2018 Guide.” The Ultimate Resource for Video Game Design, 2 June 2019, https://www.gamedesigning.org/career/game-design-portfolio/. Mann, Simon. “Game Design Portfolio-Building Tips from a Creative Assembly Vet.” Gamasutra Article, 17 Apr. 2018, https://www.gamasutra.com/view/news/316629/Game_design_portfoliobuilding_tips_from_a_Creative_Assembly_vet.php. “Your Game Portfolio Is Your Greatest Asset.” GamesIndustry.biz, 30 Apr. 2014, https://www.gamesindustry.biz/articles/2014-04-30-your-game-portfolio-is-your-greatest-asset.
0 Comments
Assuming I become a programmer, my future career will be full of it. Crunch is the (often unpaid) overtime work most common during the stages just before a game's release. Some members of the "Red Read Redemption 2" team from Rockstar Games worked hundred hour weeks to get it finished on time. French game studio Kalisto, which went bankrupt in 2002, had such an intense crunch culture that each team had a psychologist assigned to it to keep all members working productively. In general, shifts can often last 12 hours or more, and work weeks can last all seven days, which leaves workers with little time to sleep or spend with family, and can lead to health problems both mental and physical. The practice has become so normalized that despite these detriments, many in the industry are afraid to speak up for fear of damaging their careers or endangering their livelihoods. Frankly, I hesitated to write this post in case it hurt my chances of getting into the game industry. It's become so expected that refusing to crunch can end in many losing theirs jobs, and the game industry has always been defined by changeability. Stability isn't guaranteed, especially for contractors. Smaller studios have tried a variety of strategies to avoid crunch and other unhealthy standards. Motion Twin, which came from some of the former employees of the fallen Kalisto, pays all staff members an equal salary–all eight staff members, I should add. This also makes hiring more difficult due to the cost. Croatian game studio Croteam released "The Talos Principle" with only a couple hours of crunch a week. For massive AAA studios, however, many of the strategies of smaller teams simply don't work because of how these companies are designed. Some have suggested unionization as a solution, but again, this comes at a risk of losing one's job. Whatever comes of the debate, I hope (but don't expect) the problem will be fixed by the time I have a job. So, to summarize:
Citations:
Arguello, Diego, and Diego Arguello. “How Crunch Affects the Lives of Game Developers.” Digital Trends, Digital Trends, 21 Oct. 2018, www.digitaltrends.com/gaming/how-crunch-affects-game-developers/. Wright, Steven T., and Steven T. Wright. “Despite Resistance, Crunch Continues to Define the Video Game Industry.” Variety, Variety, 22 Oct. 2018, variety.com/2018/gaming/features/video-game-union-crunch-industry-practice-1202985642/. 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. 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'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:
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:
Playtesting for our board games starts tomorrow, so naturally I'm going to dedicate this blog post to it. Here's what I've learned. Games, be they board games or video games, need to be playtested to see not just if they're good, but in what ways they are and in what ways they're not. I read this article on leading board game playtests, which nicely summed up what the point of playtesting is: figuring out what does and doesn't work. To do this, you have to give the testers autonomy and avoid interfering. Don't give them ideas, and don't discuss strategy, since you (hopefully) won't be in everyone's houses to tell them what to do once your game is available to the world. Let them figure it our for themselves, because chances are, that's what other players will do. Of course, if the testers have to keep asking you to what to do, there's probably something wrong, especially with the directions. Another thing you have to do is keep an open mind and avoid getting defensive. In order to find out how you can improve your game, you have to find out what's bad about it. If you're going to improve anything, you're going to have to have testers tell you all the things that are terrible about your game. You're going to have to change or get rid of things that you put so much work into. As a designer, it will probably be painful to hear, but it will improve your game in the end. These two articles suggest treating playtesting like a scientific experiment. Have a goal in mind and consider what parts of your game you're trying to improve. Collect as much data as you can, on things like pacing, parts of the game that were unpleasant, and strategies players used. Write it down! Analyze suggestions to see why the tester said what they did; suggestions are often made in response to some kind of problem. Take suggestions with a grain of salt, since you don't want to overcomplicate your game, but consider them all. It's also important to have the right kinds of playtesters. You need members of your target audience, to make sure the game will appeal to the people you want it to appeal to. There should be testers with varying amounts of experience; you need to see first impressions, as well as how your game stands the test of time. Most importantly, you need your testers to be honest. Sugarcoating will get you nowhere. So, to summarize:
When it comes to games, you need to think through what you’re doing and how you can keep going with it as your project evolves. What works for now might not work for the future, and a lack of planning is a recipe for disaster. In a few personal anecdotes, I’ll explain why. I first really noticed how important it is to plan ahead when we were working on making character sketches. I came up with something simple (an astronaut) that worked for the project, and very quickly found out that said character and to feature in a storyboard. Luckily for me, space can be a setting for just about anything if you like science fiction enough, so coming up with a scene involving an astronaut wasn’t too hard. However, there was another piece of this project that was very important: the directions specified that the sketch should be clear enough that another student could model the character based on it. It gave me a sneaking suspicion that this was exactly what was going to happen, and sure enough, I was right. There was an unexpected twist, however: someone’s character had to be used as a promotional piece for our board game project. Things like this are the reason why having a versatile and changeable idea is important, because there will be twists and turns you’ll have to adapt to. While I’m still sort of talking about sketches, I’ll share a story about the process of making my character sketch. I failed to plan for the fact that people have arms. I started drawing my astronaut too close to the edge of the paper, realized I didn’t have room for the arm, and had to erase the head and shoulders I’d just put so much work into. There are two things I learned here: keep paper space in mind, and never make your lines too dark at first. Chances are, you’re going to be erasing them. Learn from my mistakes. Don’t jump straight into a project without thinking it over first. So, to summarize:
Our class has been working on board games for a week or two. We did this last year, but the process is much different this time. In this blog post I’ll discuss our current process as compared to the old one, as well as take a more in-depth look at my role in development. DevelopmentLast year we made board games in teams of five, and it didn’t turn out all that well. The end products were hastily put together, and work wasn’t organized. This year, we’re working in teams of three, with a lot more time, a lot more planning, and a lot more structure. We have clearly defined roles and weekly meetings, something we didn’t have last year. Working in a smaller team with clear roles makes the going much easier. Everyone has their own pieces to worry about, rather than a bunch of people all trying to work on one thing and disagreeing. The main concern with the current structure is communication, but by having meetings every week, making a schedule, and keeping a game design document updated with all changes, my team has been able to keep everything organized. Clearly defining who is responsible for each piece of the game not only prevents overcrowding on a particular project, but also makes it easier to pick out problems, since team members know their own work and goals very well. Having a smaller team also makes communication easier, and there’s not as many conflicting opinions. Overall, it’s a lot more efficient. Narrative DesignOn my team, I’m the narrative designer. This means I’m responsible for any and all things involving writing, including ads and press releases, as well as keeping the game design document updated. For this last bit especially, communication is absolutely vital. You can’t document a game if you don’t even know what it’s about. I’ve done some research on narrative design, and I’ll tell you now what the Internet has to say about it. First of all, according to this article, narrative designers are more than just writers. We create stories through action and build the world the game takes place in. Story isn’t always super obvious in a board game, but it’s there, hidden in the game progression. Game progression is definitely something I’ve worked on, since I’m responsible for making the directions. Of course, this requires a lot of input from the production manager, so I’m not just making it up, but I am very involved. I read in this article that games tell a story through game mechanics, much like how books tell a story through words. This relates to my work making the game instructions, as mentioned before. The gameplay in the game I’m involved in making is mostly based around cards, representing problems and the resources needed to solve them. I created the cards, minus the illustrations. While what the player is really doing is drawing and laying down cards, it represents the management of resources to maintain an electric grid. Game mechanics truly are a means of storytelling. 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
|