|
 [slight rant] Sometimes I get really frustrated with trying to learn games design (specifically combat and encounter design in this case). It seems like unless it's level design, the only ways to learn how and get better are:1. practice 2. be willing to accept that not every idea is inspired genius, in fact most of them are probably crap 3. practice 4. read what little material there is on the subject. 5-10. practice And it's not like I'm adverse to doing any of those, but a little direction here or there would be nice so I would know when to give up on some stupid mechanic, or more quickly recognize if/when something has promise. In certain respects, it is entirely "feel" (ie, weapon tuning/balance) and I totally understand that. When a weapon you're tuning "feels" right, there is a tangible thing there it's very obvious. But when it comes to something like making an encounter, or even just coming up with a combat system, how do you know when you've hit something good? You can't really get a good perspective on the encounter simply because you made it; you know exactly what is going to happen, when. Getting others to play it helps to find the glaring issues, but fine tuning is purely a subjective thing, and everybody who plays it is going to add their $0.02 of where to put something, or change the spawn timing or whatever. The combat system is almost the opposite problem. During the prototyping stage, it's going to suck. Prototypes always do because they're hacked in systems with litanies of bugs, borrowed FX, no audio, etc. And I know you have to look past all of that and use your imagination to fill in what's missing in order to find the elements within it that are fun and keep developing those. But how do you choose between the small elements that work well in a prototype and the ones that don't? Maybe there's something in there that is just the stupidest pile of bullshit in a prototype, but if you were to for example; design an encounter around it. It might be huge amounts of fun (But should you ever do something like that? It seems like that would obfuscate the mechanic and give it the false impression of being better than it is.)? How do you develop that sense of knowing exactly how fun something could be? Is it purely by trying and failing over and over again? When is the right time to just give up on an idea and wipe the slate clean? And when is it worth it to put in the extra time? I'm sure a lot of this sounds incredibly naive, or maybe like I'm punching above my weight. I just get frustrated sometimes with some of the stuff I make where I'll play it, and then sit back in my chair and go "Was that fun? I have no idea if that was fun?" Or even knowing when, where, and why something isn't fun but trying to fix it just makes it worse or overshadows another element. Or maybe I'm just being too much of a perfectionist about all of this. But yeah, I just needed to vent that.
|
#
?
Jun 5, 2011 00:37
|
|
|
|
| # ? May 16, 2024 17:14 |
|
|
I think the issue is that the answer to all of those questions is "It depends entirely on personal preference". Some people scrap ideas before they've even started coding them, others prefer to try to massage things that don't work into things that do work rather than get rid of them entirely. Ultimately you're going to want a mix of both, and it just comes down to intuition knowing when to throw something out and when it just needs work. I realize that's not a very helpful answer, so I'd also like to direct you to a blog called Lost Garden which discusses a lot of game design issues from a development perspective, many of which are very similar to the things you're asking about, and reading through the archives may help you get a better sense of what it is you're trying to achieve. Here's a few entries to start you off that you may find particularly helpful: Creating gameplay vs. creating levels The creative process, and sifting through ideas to find the good ones (This one in particular covers a lot of the same ground that you're asking about) The Cheshire Cat fucked around with this message at 00:45 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 00:42
|
|
|
19orFewer posted:Sites like to have a rolling set of ads, give ads as packages and autorefresh stuff randomly to get new eyes - I'd be willing to bet they had those ads ordered weeks ago (and no solace admittedly) may have filled the post weeks ago too. This makes sense, and lord knows I haven't been programming c++ itself for LONG, but the coincidence is heart-breaking 
|
|
#
?
Jun 5, 2011 01:12
|
|
|
Blocko posted:
I'd add - play every game you can get your hands on that is relevant to your field (and of you have no field yet, everything) Then while playing them analyse them, look at what works, how you'd improve it, what you like, what you hate. Find the worst, most reviled games of the genre and play them trying to answer "Why was this made this way and what can I learn." Try never to play a game without taking something away as a lesson - and accept that the more you hate a game the more you should try to understand it. Try to write down a brief summary and see whether your logic is defensible when some awkward person disagrees. The old maxim about learning by mistakes is true - but thankfully you can learn a lot through other people's mistakes. Steam specials and sales are a glorious way to obtain total junk for almost nothing  This goes back in part to the other current discussion in the thread, about playing games at work. If you get the opportunity, don't squander it having fun - make yourself miserable with a shocking game or two and you'll learn while being mocked by everyone else :P
|
|
#
?
Jun 5, 2011 01:16
|
|
|
Aliginge, Alterian posted:Be better. Appreciate it, guys. I admit, my normals are a weakness and I guess it shows. I thought the lighting was okay, but I should probably go back and re-render a bunch of them with more dynamic lighting. You're very right, I was trying to make everything as visible as possible. I have some experience with the UT3 engine. Is there a better engine to render them in that you'd recommend? Also, what should I be saying in an introduction email that's something between "Here's my crap, look at it" and a wall of text?
|
|
#
?
Jun 5, 2011 01:38
|
|
|
For showcasing stuff I occasionally use Laurens Corijn's 3dsmax viewport shader http://www.laurenscorijn.com/viewportshader http://www.laurenscorijn.com/articles/viewport-shader-setup It's how I did this:  But yeah, UE3/UDK would be good also. GeeCee fucked around with this message at 01:44 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 01:41
|
|
|
Blocko posted:And it's not like I'm adverse to doing any of those, but a little direction here or there would be nice so I would know when to give up on some stupid mechanic, or more quickly recognize if/when something has promise. Play all the games you can, pick them apart, and learn to feel out your design for fun or consistency or whatever it is you're going for. That's pretty much "it." As for knowing where to start with a system, or rough rote rules? You develop those by doing stuff you've done before. You've already made a few melee combat systems, so know that X Y and Z never work right. You've already made a 3rd person shooter, so you know to keep in mind A and B. Etc. It's the same for programmers and artists - experience is king. EDIT: my approach, for whatever it is worth, is to take things to prototype as quickly as possible - but realize that I draw from my background as a programmer, so testing/developing things by building them is just what comes naturally. I have no faith at all in spreadsheets being a way of finding fun. Spreadsheets tell me if my numbers break at level 30,000, but they don't tell me how it'll actually feel in practice. I similarly don't believe in hyper-detailed design documents, but I don't think anyone in the industry does either. You should design out the backstory / anything that isn't playable, have a rough-in of your entire flow, rough plans on level design, backstory for regions, yadda yadda yadda, but think twice the nanosecond you start to write things like "Overhead Hammerthrow - Speed: 6, Damage: 2", and I would be very leery of sketches of level designs that were anything more than grossly symbolic of the level's flow. To that end, I am seriously in love with Unity and UDK, and Stencyl is courting me lately with promises of uber-fast 2D prototypes. I'm actually considering building future design documents in google docs, with specific hyperlinks to zipped-up tiny prototypes of systems where numbers might have otherwise gone. "Combat System: See [this]". It'd be neat to always know that those tiny prototypes existed to show the system off, and google docs makes collections like that really easy to maintain indefinitely. Shalinor fucked around with this message at 02:02 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 01:53
|
|
|
The Cheshire Cat posted:I think the issue is that the answer to all of those questions is "It depends entirely on personal preference". Some people scrap ideas before they've even started coding them, others prefer to try to massage things that don't work into things that do work rather than get rid of them entirely. Ultimately you're going to want a mix of both, and it just comes down to intuition knowing when to throw something out and when it just needs work. Oh awesome! Thanks a lot, I'll check those out. Before this I had been reading a lot of Tip of the Sphere as it was the best thing I had found about combat design. It does kind of go into the sort of weirdo, nebulous topics I'm talking about but generally the advice it gives is "don't worry, you'll get better." 19orFewer posted:I'd add - play every game you can get your hands on that is relevant to your field (and of you have no field yet, everything) Then while playing them analyse them, look at what works, how you'd improve it, what you like, what you hate. Find the worst, most reviled games of the genre and play them trying to answer "Why was this made this way and what can I learn." Try never to play a game without taking something away as a lesson - and accept that the more you hate a game the more you should try to understand it. Try to write down a brief summary and see whether your logic is defensible when some awkward person disagrees. I had a film professor tell us something similar when I was in school. He said "the biggest mistakes film students make are only watching good movies. Doing that you're only seeing half the picture, each and every one of you should watch everything you can get your hands on. Good movies show you what to do, bad movies not only show you what not to do, but why." I started doing exactly what you're saying a few months ago. My steam list has exploded, and I've got a notebook full of random-rear end notes of game mechanics, what works and why, what doesn't and why, how it could be fixed etc. Sometimes I wonder how valid any of that is though, I mean games (like movies) are such a hugely subjective thing. Just because I think something is dumb doesn't mean it actually is, maybe I'm just bad at it or I don't fully understand the mechanic (though that in itself is a failing of the design to some extent, it's more a failing of lacking an adequate tutorial, or other form of explaining poo poo to the player like a gun barrel glowing red when it overheats for example). Having said that though, over the past few months I've learned a shitload about why good level/combat/encounter/narrative design is so good. Which I suppose is the key ingredient, because it's one thing to recognize when a design is good and just do that. But if you know why it's good, why it's fun then you're in a better position to make your own system that may be better suited to your end goal. At least that's what I think anyways, time will tell if it's a load of bullshit or not. Shalinor posted:EDIT: my approach, for whatever it is worth, is to take things to prototype as quickly as possible - but realize that I draw from my background as a programmer, so testing/developing things by building them is just what comes naturally. I have no faith at all in spreadsheets being a way of finding fun. Spreadsheets tell me if my numbers break at level 30,000, but they don't tell me how it'll actually feel in practice. I similarly don't believe in hyper-detailed design documents, but I don't think anyone in the industry does either. You should design out the backstory / anything that isn't playable, have a rough-in of your entire flow, rough plans on level design, backstory for regions, yadda yadda yadda, but think twice the nanosecond you start to write things like "Overhead Hammerthrow - Speed: 6, Damage: 2", and I would be very leery of sketches of level designs that were anything more than grossly symbolic of the level's flow. I've noticed the background thing really affects how you work. I always have to prototype something as fast as I possibly can. The ideas in my head play out as if they were in a movie, or in a perfect situation so I have to throw it out in a game to get a proper sense for how it handles when the player breaks it. As for the design docs thing though, I find that I just write an explanation of how the mechanic/weapon works and then further explain how those mechanics affect the game/players choices. quick and dirty example: quote:Super Mega Awesome Gun secondary shot is more effective against shields - With less body damage being done it’s effectiveness against health is more clear. (2 shots will drop the shield, but an additional 4 shots to kill the enemy.) Players are still able to kill with the Super Mega Awesome Gun, however finishing off an enemy with a different attack or weapon will do so much faster. Is that too detailed? Should I not discuss pseudo-metagame elements in a design doc? Blocko fucked around with this message at 02:36 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 02:11
|
|
|
Vodvillain posted:Appreciate it, guys. I admit, my normals are a weakness and I guess it shows. I thought the lighting was okay, but I should probably go back and re-render a bunch of them with more dynamic lighting. You're very right, I was trying to make everything as visible as possible. I have some experience with the UT3 engine. Is there a better engine to render them in that you'd recommend?
|
|
#
?
Jun 5, 2011 02:38
|
|
|
Blocko posted:Is that too detailed? Should I not discuss pseudo-metagame elements in a design doc?  To me, that's fine, but I would tend to drop the numbers, or generalize them. It does more damage to shields, less to health - and then end it, and figure out the precise ratios in prototyping. I like to lean more toward rough valuations, like "little", "average", "lots", "tons", etc. Think like how you bid project length in SCRUM - no precise numbers, just rough guesses that are rough enough to be recognizable as guesses. EDIT: Oh, I would at least recommend The Art of Game Design: A Book of Lenses if it hasn't already been recommended. It gives you some handy tools to analyze a design, and some directions to try and push things. Shalinor fucked around with this message at 03:27 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 02:40
|
|
|
Vodvillain posted:Appreciate it, guys. I admit, my normals are a weakness and I guess it shows. I thought the lighting was okay, but I should probably go back and re-render a bunch of them with more dynamic lighting. You're very right, I was trying to make everything as visible as possible. I have some experience with the UT3 engine. Is there a better engine to render them in that you'd recommend? BUY THIS THING HERE: http://www.8monkeylabs.com/tech/toolbag It's the standard model viewer in the "I need to make my portfolio better" industry. Extremely intuitive. Your email body = your cover letter. I'd look up some cover letter examples and then ease off on the stuffy-ness. Above all, be professional and use proper language and punctuation. Say whatever you want to say, really, but make sure you mention what you do and why they should give a poo poo about you at some point in there. Bonus points for mentioning any titles you've played that they made. Don't bullshit.
|
|
#
?
Jun 5, 2011 02:46
|
|
|
There's really no special formula to game design. It comes down to this: 1. Good idea 2. Playtest 3. Iterate 2 and 3 are repeated forever. 1 is really optional.
|
|
#
?
Jun 5, 2011 03:07
|
|
|
Vino posted:There's really no special formula to game design. It comes down to this: Yeah the only difference skill makes is how many times you need to repeat the process.
|
|
#
?
Jun 5, 2011 03:12
|
|
|
mutata posted:BUY THIS THING HERE: http://www.8monkeylabs.com/tech/toolbag Unless you really want to spend money the pay version of marmoset isn't really worth it. You can use UDK free, or 3 point free and paid (looks better than marmoset imo.) Download the trail and see if you like it first.
|
|
#
?
Jun 5, 2011 04:26
|
|
|
I posted my CV in the last thread and got a lot of feedback, and after writing it from scratch I actually got some interest. I got an email back off Codemasters after a few days and they asked me to complete a level design evaluation and I'd hear back once they received it. It's been almost two weeks and nothing, so should I move on? I've emailed back but I'm not sure if my default email is getting filtered, I was just hoping to hear back because level design + F1 would pretty much be my perfect job.
|
|
#
?
Jun 5, 2011 05:16
|
|
|
Vodvillain posted:I moved out to Vancouver to get closer to more Canadian offices, so if anyone local knows of any opportunities, please share. I'm not in Vancouver any more, but what I hear out of there is that with all the layoffs and studio closures there, it's tough trying to break in against all the experienced people losing their jobs. Sorry
|
|
#
?
Jun 5, 2011 05:40
|
|
|
Lord of Sword posted:I posted my CV in the last thread and got a lot of feedback, and after writing it from scratch I actually got some interest. The first week's checkin email is easy ("I just wanted to thank you again for the chance to do that evaluation..."), then by the second try and have something new ("So I just added X to my portfolio, thought you might want to know..."), and then it gets a bit trickier but you get the idea. Generally, just work to make it more than just a please-don't-forget-me email. Shalinor fucked around with this message at 05:48 on Jun 5, 2011 |
|
#
?
Jun 5, 2011 05:45
|
|
|
A HUGE FUCKIN BLUNT posted:Yeah the only difference skill makes is how many times you need to repeat the process. game.design = idea.someone_will_pay_for_it game.how_many_times = polish.enough_to_please_client for i = 1, game.how_many_times do game.improve() end game.ship()
|
|
#
?
Jun 5, 2011 06:38
|
|
|
Imajus posted:Unless you really want to spend money the pay version of marmoset isn't really worth it. You can use UDK free, or 3 point free and paid (looks better than marmoset imo.) Download the trail and see if you like it first. Eh, UDK is too bulky for just a model viewer. Marmoset is 60 times easier and faster to use, especially out of the box. It's true you can't beat UDK's price, though.
|
|
#
?
Jun 5, 2011 06:52
|
|
|
mutata posted:Eh, UDK is too bulky for just a model viewer. Marmoset is 60 times easier and faster to use, especially out of the box. Its also really good to put on your resume that you know how to use UDK!
|
|
#
?
Jun 5, 2011 13:40
|
|
|
Smegbot posted:Started a new job today, this chap sits at the desk next to mine: Haha, I think I know where that is too. If it's where I think it is, then I used to work in the same building. (Assuming I'm not confusing your username with someone else, and you're working in Scotland) Monster w21 Faces posted:I say put all the money in games courses. It's not like there aren't a bunch of other unis in the surrounding area. If I were running Abertay, I'd probably do the same thing, given that the game and computer related courses do more for their reputation than any other course.
|
|
#
?
Jun 5, 2011 14:45
|
|
|
Alterian posted:Its also really good to put on your resume that you know how to use UDK! This partially addresses a nagging noob question I've had for a while. As of right now, I've been working pretty exclusively with a Maya-to-Unity pipeline for stuff, but is Unity looked down upon as an engine and/or editor? Would I do better to use Unity for quick mockups only, and UDK for the final thing? I guess what I'm asking is how they stack up side-by-side in terms of how useful they are in terms of bullet points on a resume, as well as what I can actually do with them. They seem pretty similar to me in a lot of ways but I'm starting to feel a bit limited with Unity's shader set, for instance, so I feel like maybe I should try something new.
|
|
#
?
Jun 5, 2011 18:19
|
|
|
Alterian posted:Its also really good to put on your resume that you know how to use UDK! That's why I use both. 
|
|
#
?
Jun 5, 2011 19:16
|
|
|
Yeah I use both as well but prefer Marmoset. I'm always running into issues with certain areas of my models with UDK whether it's how it renders my mirrored UV seams etc, but I never have those issues with Marmoset. Also to customize UDK's post process effects, lighting, shadows, depth of field, cubemaps, etc all at once is a pain in the rear end compared to Marmoset.
|
|
|
#
?
Jun 5, 2011 19:20
|
|
|
SpecialAgentCooper posted:I guess what I'm asking is how they stack up side-by-side in terms of how useful they are in terms of bullet points on a resume, as well as what I can actually do with them. They seem pretty similar to me in a lot of ways but I'm starting to feel a bit limited with Unity's shader set, for instance, so I feel like maybe I should try something new. Unity is used by indies, mostly, and almost exclusively on small projects, as it isn't well architected to scale beyond such. It's also much newer, and though it has theoretical console potential, no one trusts it enough for that yet. So it isn't so much that it's looked down on as they've each got their own use and target market. Unity just isn't a grand fit for most mid to large studios, whereas it is a good fit for micro studios an indies making smaller-scoped games. Personally? I'd try and have both. Unity is great for prototype, UDK is great for larger-scope projects, and you might as well use both for what they're great at.
|
|
#
?
Jun 5, 2011 19:48
|
|
|
Lord of Sword posted:I posted my CV in the last thread and got a lot of feedback, and after writing it from scratch I actually got some interest. Their HR is a bit rubbish if that helps. They took three weeks to get back to me after interview, which is fine except that I found out subsequently that HR had received confirmation of my hiring on the same day as I'd interviewed. So yeah, turnaround on those sorts of things is a bit cack.
|
|
#
?
Jun 5, 2011 20:14
|
|
|
SwatJester posted:Too much drama in the old thread over the prior title. Time for a new thread. Old thread is here if you are interested.
|
|
#
?
Jun 5, 2011 20:18
|
|
|
Chasiubao posted:I'm not in Vancouver any more, but what I hear out of there is that with all the layoffs and studio closures there, it's tough trying to break in against all the experienced people losing their jobs. Sorry Yeah. Toronto or Montreal are better choices these days.
|
|
#
?
Jun 5, 2011 20:20
|
|
|
The Oid posted:Haha, I think I know where that is too. If it's where I think it is, then I used to work in the same building. Yup, I'm at 4J Studios in what used to be the VIS building (made evident by the giant VIS sign that's still up outside). Apparently the seagull's called Steven, by the way. Steven Seagull...
|
|
#
?
Jun 6, 2011 00:16
|
|
|
Is C# worth learning, or does most of the industry still use C++?
|
|
#
?
Jun 6, 2011 01:21
|
|
|
C# is generally used for tools. The core game programming will be in C++, unless you're doing iPhone, which will be in Objective C. Social games will generally be PHP/ActionScript.
|
|
#
?
Jun 6, 2011 01:24
|
|
|
Dominoes posted:Holy gently caress, you really do everything. Yeah my strengths unfortunately are in breadth not depth.
|
|
#
?
Jun 6, 2011 01:39
|
|
|
mastermind2004 posted:C# is generally used for tools. The core game programming will be in C++, unless you're doing iPhone, which will be in Objective C. Social games will generally be PHP/ActionScript. Note that if you're using a pre-built engine like UnrealEngine, you'll probably be doing most of your gameplay code in a scripting language.
|
|
#
?
Jun 6, 2011 02:34
|
|
|
Just passing on a question from a friend and want to get some industry inside views on this if I may, it's an art and tech-related question but I'd like input from anyone willing to lay in. But with the advent of the new Nintendo handheld and the PSP2 and talk that the latter's visual fidelity rivals current gen consoles while Iphones/Ipads, mobile and such very much heading in the same sort of direction - what avenues do you guys see for low-spec specialisms, lower-polygon, hand painted textures only, that sort of thing? I mean, there's a lot of artists out there who are amazing at low poly work but might have been left in the dust a bit when it comes to learning the absolute newest next gen tech. I presume the answer is going to be adapt-fast-or-die for these guys - or do you guys see there being some kind of niche for such skills? Will such lower-resolution specialists become niche like sprite art specialists from the days of capcom/SNK old, are they just on their way out or is some new tech going to spring forth and start from 8 bit graphics quickly moveing to PS2 era like watch-games or something? GeeCee fucked around with this message at 04:37 on Jun 6, 2011 |
|
#
?
Jun 6, 2011 04:34
|
|
|
Edit: Too harsh. Never mind.
|
|
#
?
Jun 6, 2011 04:53
|
|
|
Aliginge posted:Just passing on a question from a friend and want to get some industry inside views on this if I may, it's an art and tech-related question but I'd like input from anyone willing to lay in. In my opinion, all game artists should be prepared to work on either at this point. If someone wants to be a character artist, for example, he'd better be able to make characters low-poly with hand-painted textures as well as high-res zbrush sculpts and normal bakes if he wants to be widely marketable. Even if you get a job doing one, you may lose that job pretty quick and you'll want the horizontal mobility.
|
|
#
?
Jun 6, 2011 05:16
|
|
|
Blocko posted:The combat system is almost the opposite problem. During the prototyping stage, it's going to suck. Prototypes always do because they're hacked in systems with litanies of bugs, borrowed FX, no audio, etc. Dunno if I agree with this. Polish goes a long way, but I subscribe to the school of thought that says your core gameplay prototyping should always be built around a nugget of fun that's visible even through block models and hacks. If you are relying on new FX, models, or particles to add the fun it's never going to be standout. You cited Jaime Griesemer's blog which I'm a fan of as well - I think if you look at a lot of the elements he breaks down, they apply equally to making a good prototype as a final game. Cadence, role, etc. The biggest gap I can see is if you have no animation support for prototyping a combat system that's just not gun-based, because that's the hardest thing to "fill in" mentally if it's completely missing. That said, you don't need anything more than some barebones anim support. We've had a lot of success using block models - basically cardboard box men with arms and a head - and having our animators crap out whatever we need as fast as they can to support an early prototype. My go-to (though I don't work on heavily art/cinematic driven single player experiences, so my opinion may be invalid for those) is that a really good, fun, core mechanic should be fun in a vacuum. We like to tell our new guys that Gears was built on top of it being fun to shoot the Lancer in a greybox level against enemies as a representation of this idea (I don't work for Epic, but we had people that worked with them / helped out on Gears). icking fudiot fucked around with this message at 05:21 on Jun 6, 2011 |
|
#
?
Jun 6, 2011 05:18
|
|
|
Sam. posted:Is C# worth learning, or does most of the industry still use C++? It depends on why you're asking this question. You need to know C++ inside and out. Fully grokking pointers is pretty fundamental. Console development is generally done in C++, maybe with some scripting language (like UnrealScript) on top of that. So if you're looking to start with something, C++ isn't a bad place to start, even if it is a lot more complicated than other languages. But if you already know C++, you should learn it just to learn a new language. Seeing different paradigms in use can really expand your thinking. And I mean really dig into it, not just write C# code as if it's C++ without pointers. Delegates and lambdas, LINQ, and all that other fun stuff is really useful. Maybe it'll even convince you to try some of the scarier advanced C++0x/Boost features to hopefully help bring the industry into more modern programming practices. And who knows, maybe Microsoft will do something crazy and make their next xbox XNA only or something.
|
|
#
?
Jun 6, 2011 05:59
|
|
|
LINQ is the greatest language feature I have used in C#.
|
|
#
?
Jun 6, 2011 06:02
|
|
|
|
| # ? May 16, 2024 17:14 |
|
|
Aliginge posted:But with the advent of the new Nintendo handheld and the PSP2 and talk that the latter's visual fidelity rivals current gen consoles while Iphones/Ipads, mobile and such very much heading in the same sort of direction - what avenues do you guys see for low-spec specialisms, lower-polygon, hand painted textures only, that sort of thing? I think it's a terrible idea for anyone new to the industry to try to specialize in what amounts to 'previous gen' style. In addition to burnout, there is a very real group of folks who grew up and got married and had kids and their skills hit a ceiling and they haven't learned new ones. These are the ones competing for the top of these jobs, which means fewer opportunities for advancement, and while you're working in these positions you're not learning new technology or skills gradually which means more time spent outside of work learning 'cutting edge' techniques. There will always be some market for older art techniques for a variety of reasons (nostalgia, development cost, processing power, etc) but the notion of someone new to the industry trying to specialize in it seems like a poor idea. I think the golden rule, above all else, is to be really good at what you really want to do, and if you're good enough, you'll get there and have a job and enjoy it. I don't doubt there will be work for these things but there is a built in industry atrophy that leads to the creation of specialists in these areas already, so I think trying to be one is a fools errand.
|
|
#
?
Jun 6, 2011 06:06
|
|