|
GetWellGamers posted:I did this last time, but I'm going to complain again about your "I want to start in QA" rant. You should make the distinction that Publisher QA is an unloving hellhole whereas Developer QA has ample room for advancement if you do your work. As someone who currently works in a Senior Developer QA position and previously worked Publisher QA, I agree with this sentiment. I'll write up a post on how the two differ once I finish this smoke test 
|
#
¿
Jun 1, 2011 19:27
|
|
|
|
| # ¿ May 16, 2024 21:45 |
|
|
Chernabog posted:I haven't had to work overtime a single time and I have been in the industry for almost a year. Granted, I'm at a casual studio, so it is probably a lot more lax than a big one. I've been doing 12 hours a day for the last 6 months. Most of that has been learning other stuff/prototyping little ideas I have. But even so I'm young, single and actually don't mind staying so I can afford to do crazy poo poo like this.
|
|
#
¿
Jun 3, 2011 18:31
|
|
|
 [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
|
|
|
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
|
|
|
treeboy posted:Well I've got a phone interview with Vigil Games this afternoon for an entry level character animation position. Wish me luck! Good luck! The Vigil guys are really cool people.
|
|
#
¿
Jun 8, 2011 18:10
|
|
|
|
| # ¿ May 16, 2024 21:45 |
|
|
Sigma-X posted:Congrats dude! Hope it still feels like a dream when you realize your job is to clean up mo-cap of a dude taking a dump, forever "The normal map on this turd is fantastic!"
|
|
#
¿
Jun 9, 2011 20:16
|
|
