Jump to content

JBrawley

Junior Defender
  • Content Count

    11
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About JBrawley

  1. I'm coming up with 32.33, repeating of course, percentage of survival. It would be a lot higher if you'd put points into dexterity. I've told you this, I don't even know how many times, but you keep putting them in intelligence. Maybe you should point a few in wisdom too, eh?
  2. I'm looking into becoming a games designer and I would love to hear from one of your guys. I Summon You Into The Deep Depths Of The Trendy Forums! What you should remember -- 1. Technical proficiency is not optional :: There is no such thing as an 'ideas' only guy in the games industry -- and even if that basically was your role, you wouldn't be able to do it without a really firm grasp on how realistic and achievable an idea was. The better you are at programming/scripting, the better off you'll be. The better you understand the inner workings of your engine, the faster you can track problems and the less likely you are to break things. 2. Communication is key :: Chances are, at some point, a GD has to articulate his ideas to others. If you're really bad at this, its going to waste a pretty colossal amount of your time. 3. My pillars of game design are: a -- Problem Solving -- The heart of design is problem solving, identifying an issue with a design and creating solutions to resolve that problem (ideally without creating new ones you can't solve) b -- Embodiment -- A game designer looks at a system or theme and asks the question "What's cool about this?" and then tries to create systems and interactions that capture or emphasize that. c -- Foresight -- The ability to recognize problematic elements of a design long before its built. Sometimes the exact nature of these problems needs to be witnessed to be understood however. d -- Proactivity over Reactivity -- It's generally better to be taking action in design -- putting forth and trying out new ideas, then it is to be in a constant state of reaction. Reactive design tends to create a chain reaction of new issues that also require reactive design. e -- Elegance / Simplicity -- The more complex your design gets, the less likely it is that its achieving the results on the player you want. All designs grow in complexity by nature, but you need to be able to step back and recognize where complexity can be reduced. Once you've added enough complexity to create the depth you want, you need to remove the complexity and retain the depth. f -- Agility -- It's better to do ten prototypes that fail, then to do one completed system that failed. The faster you can translate ideas from your head to a system you can manipulate and experience, the sooner problems become apparent. The issue is often in the root of a concept, not in the execution -- but you can't generally see this until you can witness the execution. g -- Failure -- Game design generally has to get it wrong before they can get it right. There *are* happy accidents, but they're very very rarely a product of coordinated genius. The vast majority of the time, GD will design something that doesn't quite work. This isn't just part of the process -- it is the process. Making mistakes *is* how you design games. h -- Permutations Matter -- When you build something, you need to see how each component of the system affects the system as a whole. Trying turning things off, trying doubling values, try the clearly unwise. The more you learn about the dynamics you've actually built, the faster you can dispell notions that the system will work "they way its supposed to" (it never quite does by the way). Permutations in design generate insight. i -- Perspective Matters -- It's easy to get too engrossed into a project to see flaws, and usually the ones you miss are fundamental flaws. Sometimes you need to get some distance of separation from your work, or you need to completely flip your perspective to see those flaws. Sometimes you need to throw out fundamental assumptions and rebuild them from scratch. How did I get to where I am -- Well after my first son was born, I decided to stop mucking around and get a real career. I ended up attending the Guildhall at SMU, where I certainly learned a lot about development from a wide pool of talent. It should go without saying though, that my inauguration into design began long long before that, even if I didn't really realize how or why. To begin with, I've been playing pen and paper roleplaying games, probably since I was 8. I was never content to just play the games though. These glorious constructs of logic and math were pretty fascinating to me. I owned roleplaying sourcebooks, probably for more than a dozen tabletop RPGs that I never even had the opportunity to play. I would read and digest the rules, I'd run scenarios in my head, create characters just to build them. I didn't realize it at that age of course, but I was assimilating myself into the architecture of these systems. It wasn't that long either before I started running tabletop campaigns, and then ultimately designing pen and paper RPG systems from the ground up, and running successful and well enjoyed campaigns in them. By the time I started undergraduate, I'd designed at least three board games I can remember, a massive Battletech style tactical campaign game, and at least five distinct pen and paper games. This background helped me cut my teeth on the fundamentals of game design and system design. I'd always been big on playing with editors, although I'd never really built any finished products. In undergraduate I got sucked hardcore into text-based MUDs, and pretty soon I was programming and doing admin on some them. I stayed in that world for a pretty long time (until MMOs and fatigue with the human politics MUDs tend to create pulled me out). Doing work on MUDs gave me background with working with complicated systems, taught me more technical proficiency, and taught me community management, teamwork, and human skills I might not have otherwise learned. Finally, when I got pulled into MMOs (I played WoW, City of Heroes, and DDO) I somehow naturally ended up at the top of those leadership structures, and I sure learned a hell of lot about teamwork and team management from living in that world for three or four years. I decided to go to Guildhall because they had a Level Design program, and it sounded like a perfect fit for me. I felt I had all the background and experience that would make me successful there. When I started at the school, I had this image in my head that I'd be a minnow amongst sharks, that everyone there would blow me away and I'd have to struggle to keep up. A bit to my surprise, I was one of the oldest students in my class and everyone was often looking to me for advice and guidance. The school really gave me a choice to change myself for the better, to fit the role well, and to learn the technical skills I needed and give me a frame of reference for how to succeed in the industry. I ended up at TimeGate after I graduated, working on Aliens. Not to go into excessive detail, but one of my instructors at Guildhall told me I'd probably learn a lot more from working on a total disaster than working on a shining success. That's probably true. After about five months on that project I moved to working on an internal project -- a free to play shooter called Minimum that TimeGate announced shortly before legal issues destroyed the studio. I did a huge amount of level design, and highly technical design work on that project -- tons of prototyping, experimentation, and exploration. I got to work through the whole process up and down. When TimeGate imploded, it happened that Trendy was in need of a designer who did exactly those things, so now here I am.
  3. Does Ice make sure your drinks are cold? HAHAHAHHA +1 No, but he did install this really cool retractable cup holder on my desktop tower.
  4. I'm actually looking into becoming a game developer so if you guys want to give a piece on that I'd appreciate it very much. Game Development is People: People make games People consume the games The better you are at communicating, dealing with people, understanding variant viewpoints and approaches, and the more respectful you are of the professional qualifications of others, the farther, faster, and easier you will go. This is true of all disciplines.
  5. The Huntress - Orlando Bloom Negative, Maisie Williams
  6. 1- A) If this is the case, why hasn't trendy said as much? (in fact why hasn't trendy said ANYTHING >.>) We can speculate all we want on this, it doesn't matter. The system is disliked, and gimmicks like extra keys per wave are just an annoyance. Well mostly, I've been super busy but I am keeping up with this thread. The second component here was that I waiting for the council to dig through the surface and get to some truly useful insight on the system, but I think the chance of that have pretty much dead-ended now. You guys are running in circles and having an argument which has basically boiled down to "I don't think this has a place in the game" against "I think this has a place in the game". B) If it is indeed this, then why keys? Why not just better place the chests? It isn't exactly hard to move a chest spawn point. 2- I've seen this argument a lot, and it just doesn't make sense. if trendy is going through all this effort to squish us down to 2 chests, we need enough mana to still play yes? Well we *barely* have that thanks to 4 people. Why exactly would more chests not equal more mana? Instanced chests have nothing to do with that. The only thing instanced chests do (unless trendy has been adding things to it secretly) is make it so that the mana dropped from a chest you open, is mana that only you can see/pickup. It doesn't in any way affect the amount you get out of it. Let me clarify a couple things before allowing this to proceed. A: The players on a map get exactly the amount of mana we decide they get. We grade the total amount of mana we want to come out of chests in the build phase across two chests right now. B: During combat, likewise, the enemies drop exactly the amount of mana in total as we decide they drop. C: If you feel you're not getting enough mana for all four players out of the chests, that's an entirely different issue than the chests being a limitation -- that simply means you feel we didn't put enough mana on the board, and that's super easy to change. A couple other notes: Why two chests? We want players to travel around the map to pick up chests -- there's a reason why chests tend to be near enemy spawn points, because this process helps you learn a new map more rapidly and helps guide you towards the enemy spawners. When the keys system was first installed, the system defaulted to two keys -- I decided to leave it two keys for two primary reasons: -- I wanted players to move around the map some, but I didn't want players to have to go and retrieve every single chest each wave (this would get annoying very fast for seasoned players) -- In earlier player levels, if you open only one treasure chest, it will need to dump out more mana than you can carry, forcing you to return to the drop point and pick up the remainder. I felt this would be pretty annoying. Chests aren't a perfect solution -- me and one of the GD's debated this system for two days. I've never been perfectly happy with it, but right now it's the least imperfect solution we could reach while still solving the problems we were hoping to solve with it. This is one of the fun things about having everyone play while the game is in-development, we get to put out early systems and make changes accordingly. There are 3 or 4 changes we are adding in to the system as you read this based on feedback from this thread.
×
×
  • Create New...