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/.
0 Comments
I've improved since I was younger, but time management still isn't my strong suit, and recently that's come back to bite me. It's time to start fixing that. One of the most important keys to effectively managing time is to eliminate distractions. I've recently taken this into account by banning myself from watching any videos YouTube or using any social media (I don't have a lot, but the one chat program I do use eats up substantial chunks of time). It's important to take breaks in order to not become too stressed, but I keep them short and avoid anything that might become a time sink–that means staying away from the TV or starting any lengthy conversations about, say, whether or not a hot dog is a sandwich. One strategy has been to find long playlists of music to listen to instead of constantly scrolling through YouTube looking for another song–this is typically where my problem of getting distracted by non-music videos comes from. I've had also issues with distractions working on a game in class recently, namely because I get caught up with constantly fixing the racetrack or fiddling with minor features. I've tried to rein in this urge to perfect things that are better left alone. When I notice something that can be left as it is without too much consequence starting to take up most of class, I move on. Another key practice is to not waste time waiting for things. I've begun working on homework during free time in class (especially when I arrive early), before school, and during lunch. It's typically something easy like a reading log so I don't get entirely burned out, but it saves time so I can worry about items like this portfolio when I'm at home. I even manage my breaks, such as using the rides to and from school to listen to music or work on personal writing so I don't end up feeling like I've done nothing enjoyable all day. Short deadlines also help productivity. Parkinson's Law states that work expands to fill the time allotted for it–the more time you have, the more you procrastinate. I've started setting hard deadlines for myself that are as early as absolutely possible–for example, I've committed to creating/digging up at least two pieces of artwork for my portfolio by the end of tonight, no excuses. So, to summarize:
Citations:
“8 Time Management Strategies for More Productive Work.” Teamdeck.io, Teamdeck, 7 Mar. 2019, teamdeck.io/project-management/time-management-strategies/. Rampton, John. “Manipulate Time With These Powerful 20 Time Management Tips.” Forbes, Forbes Magazine, 1 May 2018, www.forbes.com/sites/johnrampton/2018/05/01/manipulate-time-with-these-powerful-20-time-management-tips/#4935474e57ab. 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/. This was my was one of my first handheld games (I think it was the first), and for some reason I decided to dig it out again after a couple years of not touching it. The basic premise of the game is to take care of a variety of fantasy pets. This is done via three minigames, one for feeding, one for play, one for grooming. A fourth mini game (known as the "magic world"), unlocked when all needs are filled, allows the player to unlock new pets if they score high enough. It's either one of two types of obstacle course or one of two types of "bullet storm" games, depending on the pet's "element" (there are four). The feeding minigame requires the player to color in as much of the food item as possible in the time limit, with a time penalty for drawing outside the lines. The grooming minigame requires the player to spray the pet with a hose (or similar) while they run around, jumping in what are apparently interdimensional portals in an attempt to hide. The playing minigame has the pet transforming into essentially a living basketball hoop (I was somewhat alarmed the first time this happened) as the player attempts to throw the toy into them with the stylus. No explanation is given for why any of this works the way it does. The minigames (at least the play one and the magic world) get harder the higher on the progress tree your pet is. I'm not usually much of a minigame person myself, but for some reason I enjoy these. I think they require just enough effort to keep me interested. More about progressing: the player starts with a choice between two eggs, which will hatch the first creature. Completing the magic world game unlocks two more eggs. This is organized on a chart similar to an outcome tree. The end goal is presumably to hatch all the eggs and unlock all the pets. It makes sense, but despite incentives to stay on a single pet for a while such as discovering a pet's "favorites" (toys, food, etc), it can be tempting to just race through the tree–and it gets pretty easy to do so after you've practiced. The pet care minigames do get dull after a while. The aesthetic design of the game is very good in my opinion. The graphics are decent, but what it lacks in shiny hyperrealism it makes up for in creativity. The eggs are cool looking (a must if you want the player to be eager about hatching them), and the pet designs are charming and unusual. There are a few recognizable creatures–dragons, flying horses–but most of them are just weird fuzzy animals. My first pet was a lion with wings. Not a griffin, a lion. With feathered wings. At any rate, they're cute. They come in four varieties, presumably "elements" (though it's never stated directly). These appear to be sky, fire, water, and earth, but of course this is never explained either. This mainly affects the type of magic world minigame they play and their appearance as a living basketball hoop. I have not noticed any correlation between element and favorite items. The obstacle course magic world games are definitely better looking than the bullet storm games, if only because of the fantastical 3D landscapes. The sound design is good but nothing extraordinary. Overall, the game is fun for a while, but it can be very tempting to just rush through, as it gets repetitive. It's a good way to kill time, and considering the way most real-time mobile games are played, I think it serves its purpose. So, to summarize:
We've been working in 3D games for some time now. Time to reflect on that. One of the immediate things I've noticed is that 3D is the default, which means a lot of things are easy to manage because I don't have to go looking for the 2D version, or making special accommodations to let the 2D physics work. It seems pretty clear to be that Unity is really meant for 3D. Of course, I do have to take another axis in to account, but it's not nearly as big of a deal as I had expected. Another thing I noticed immediately was the difference in how the game environment is set up. Three dimensions make it easier to lose objects (though you'd be surprised how easily I've done that with only two), and there are things like skyboxes and different camera angles to worry about. One perk of 2D is that it's generally easy to keep everything on/off screen as needed and not accidentally show the viewer the vast and terrifying expanse of the rest of the scene. That was a point of particular irritation for me when working on the Survival Shooter tutorial, as getting too close to the edge of the screen would reveal a bright blue and white horizon, which did not at all fit in with the aesthetic of the game, nor did it make any kind of sense, and in my opinion distracted from the experience. Unfortunately I never got the chance to see if I could turn it to something more fitting, like a dark purple void. Something I noticed further along was that when you take away sprites and start dealing with 3D objects, things get a lot of complicated. I didn't know what a nav mesh agent was last year. I knew what a 3D material was but never realized Unity used them. Lighting and sound are more affected by the environment. It unlocks a lot more potential (unless I'm underestimating the power of 2D), but it's a lot more to keep track of. With great power comes great complexity...and great length of component lists. So, to summarize:
Having recently finished a two-player tank game that's played on a single computer (WASD vs arrow keys), I started to wonder about the history of multiplayer games. "Multiplayer" often makes us think "online" nowadays, but I doubt that was always the case. It started, of course, with arcade games–namely Pong. Released in 1972, it featured simultaneous play (pretty necessary for a ping pong game), unlike most of the turn-based games released later, such as Space Invaders (1978) and Pacman (1980). Most if not all of these turn-based games did not require more than one player–they simple had the option. Two players was the maximum, a measly number nowadays compared to the thousands one might see in an MMORPG. Speaking of which: Island of Kesmai, a PC game released in 1985, is considered the forerunner to said MMORPGs. It was run by CompuServe for $12 an hour, supporting 100 players tops. It's often classified in the roguelike genre. In 1990 came the release of the controversial Doom, another PC game and one of the original first-person shooters. It supported up to four players via LAN. A year later game Warcraft, allowing two-player contests via LAN or modem. In 1997, GoldenEye 007 came out on the Nintendo 64, supporting 2-4 players split-screen. Several other games following this format came out in the 1990s, including Mario Kart 64, Sonic and Knuckles, and Half Life. As the Internet developed to what we know it as today, online play became more popular. Nowadays we can jump into other people's game worlds to play as NPCs (such as in Watch Dogs), or encounter other players in a single world everyone logs into (such as in Destiny). Most of these feature some kind of chat system nowadays. The success of games like the Halo series or World of Warcraft stands testament to the enormity of online play, and in fact, this may become the norm for multiplayer. Split-screen is resource intensive, and is no longer viable on most consoles while keeping the level of graphics we've come to expect. Ironically, we're perhaps less connected that way; it's not quite the same playing with a bunch of strangers. Looks like it might be time once again to break out the single-computer games like the one I just finished–or maybe even (gasp!) the board games. So, to summarize:
Citations:
“Evolution of Multiplayer.” Ohio State, Ohio State, web.cse.ohio-state.edu/~crawfis.3/cse786/ReferenceMaterial/TechTeams/2014/EvolutioMultiplayer.pdf Gartenberg, Chaim. “The Future of Gaming Is Lonely (and Online Only).” The Verge, The Verge, 25 June 2015, www.theverge.com/2015/6/25/8844073/goodbye-local-multiplayer-we-will-miss-you-and-the-goldeneye-days-of-yore. Forgive the punny title. We never actually got to rig anything in the 3D modeling unit, but I figured I may as well do a little research in case I ever have to do it again. First of all, it's important to use the right kind of rig for the character's intended purpose. If they'll never be seen speaking or showing complex facial expressions, the face doesn't need much done to it. Don't try to animate a four-legged character with a bipedal rig, or vice versa. None of this is new to me. One should also utilize control curves, named and color-coded to keep track of them, and hide/lock any controls that aren't necessary to avoid confusion and accidental edits. Add controls as needed. This ties back into knowing what the rig is going to be used for before you start creating it. Deformers are useful for facial rigging. Don't create loads of extra joints if you don't need to. It's also important to make sure the joints and bones are placed in the anatomically correct positions. This will lead to a lot less horrifying and ridiculous deformations. It's also better to skin the rig (attach joints to mesh) with a low-quality version of the model, as this will allow the machine to update more quickly and provide quicker previews, making it easier to know what you're doing. Also, use all the viewports you have to make sure it looks right from all angles. Considering all the little details, I'm kind of glad we haven't rigged anything yet. I still remember last time... So, to summarize:
Citations:
“5 Tips for Character Rigging.” Pluralsight, Pluralsight, 20 Jan. 2014, www.pluralsight.com/blog/film-games/5-tips-character-rigging.Charlie. “Our Top 5 Rigging Tips.” Fudge Animation, Fudge Animation, 19 Dec. 2017, www.fudgeanimation.com/experiments/top-5-rigging-tips/. We're finally wrapping up with 3D modeling. Now that it's all said and done, here are my thoughts on the matter. Besides the programming I did earlier in the year in the 2D game project, 3D modeling has probably been the easiest thing I've done all year. That's not to say it's actually been easy. The biggest challenge is that a lot of the work is meticulous, and small changes can have big effects that might not be obvious until later and are difficult to troubleshoot. During the column modeling project, for example, I noticed several of my maps had not turned out correctly. I still have no idea why, but they were definitely warped, and it was noticeable in some places on the model. I followed the tutorial meticulously, but for some reason mine didn't turn out correctly. It wasn't really that drastic, though, so I still count the column as a success. The meticulousness caused other challenges, though. A lot of projects ended up half-finished due to the amount of time they took being longer than the amount of time there was available to complete them. UVW unwrapping was also complicated, or at least some aspects of it were, and it often ended up messing up without a clear cause. I did enjoy figuring it out, though. It was almost like a puzzle. In general, that's what I like about 3D modeling: you want to make a certain object, and you have to figure out the necessary steps to make that object come into being, and it's a lot like solving a puzzle. As for the program ads Max, I have mixed feelings. I like the functionality, but it's very resource intensive and tends to have difficulty opening–or that might just be the subpar computers. Sometimes the menus are confusing to navigate, especially when icons get changed over updates. Also, a few useful features were changed since the time the tutorials were made for no apparent reason. One of these was the ability to lock viewports, which would have been helpful. So, in conclusion:
I got to playtest a game about loansharking–and in the process learn how not to get ripped off. Lenders are not your friends. Last Friday I had the opportunity to playtest Shady Sam, in which the player is a loanshark working for the titular character. Long story short, you have to pick from three loan options to make the most money off of innocent people who didn't read the fine print. It's sadistically fun, and now I know what to look for to avoid in order to not lose loads of money–long terms are great if you're the one doing the lending. The game also provides a lot of incentive to keep replaying, including an random selection of various rewards to put on your desk; enough different scenarios to keep the end profit from always being the same; a 1-5 star (actually dollar sign) rating; and you even get a cool nickname at the end. I've never been happier to be called "Bad News." All that, and it's only in beta. The game requires you to use your head and look closely at all the terms, and even exercise math skill, all of which you have to do when actually looking for loans. It also throws in other factoids, like student debt figures, types of fees to look for, and how cycles of debt happen. I feel more confident about borrowing money now. However, it did get a little repetitive after a few plays, so a larger variety of scenarios would be nice. Playtesting is useful because it can help find bugs–for example, sprites not showing up, which happened several times. It's also useful because it allows the designers to see how players actually interact with the game, sometimes in ways they may not have anticipated, and if all the features work as intended. It allows the designers to learn about areas of improvement as well as what should definitely be kept. So, to summarize:
It's been a while since the last post. In the meantime, I've been learning about audio/video editing. Let's talk about that. My very first thought is this: using cuts to build momentum was fun. It's easy conceptually but hard in practice. What I mean by that is that it took me quite a while to get everything just right and I had to rematch my own video a probably few dozen times. Even something as simple as a montage with speeding up cuts was difficult when there was an exact time limit, entirely because I had to keep adjusting and readjusting. It's an easy enough idea, though. Audio editing was mostly a matter of trial and error. I went through so many reverb filters just to find the right one. Sound effect placement was easy enough with an audio-only file, but as usual with videos, it took me a while to sync it perfectly. Foley work was complicated in this aspect because when you have things like footsteps, you have to make sure every audible step matches every visible one. This means you either slice up the audio clip, or whoever you record walking needs to match the pace of whoever is walking in your video (this is why I did). Overall, audio editing isn't really that hard, and the most difficult thing is actually recording (partially because I don't have a good mic). Am I ever going to use these skills? Maybe, maybe not. As anyone who's read my previous posts probably knows, I'm much more into programming. My other idea for a career path is to go into the movie industry, which means I may be editing my own short films (assuming I make any), but in terms of game design, the most I'll use these skills for is a video portfolio. Which, admittedly, isn't a bad use to put them to. 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
|