• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

hymerman

Members
  • Content count

    487
  • Joined

  • Last visited

Community Reputation

221 Neutral

About hymerman

  • Rank
    Member
  1. Thanks raigan, that's actually a really interesting article. I totally agree with his "this is something that should be really commonly known but for some reason isn't" sentiment!
  2. Aha. The second category of answer. Well now I feel stupid. I also wonder why nobody ever gave me that answer before :) Thanks very much in any case!
  3. Here's something I've been wondering about which I would like to do correctly: I want to blend smoothly from the current value to an ever-changing target value, but want to do this in a frame time-independent manner, i.e. not jittery and consistent irrespective of frame rate. By blend I mean smooth arrival at the target value, should that value remain constant for long enough for the current value to catch up with it. By consistent I mean the motion should follow the same path, albeit 'chopped up' in a different manner due to differing frame times. The specific application here is actually in making a camera smoothly track a target. Here's the essence of what I've got so far, to hopefully clarify things: position currentPosition; float someConstant = 0.5f; float lerp(float from, float to, float t) { return from * (1.0f - t) + to * t; } // this is called every frame, with dt being the frame time void blendToTarget(float dt) { position wantedPosition = calculateWanted(); float t = someConstant * dt; position newPosition = lerp(currentPosition, wantedPosition, t); currentPosition = newPosition; } Using t = someConstant means some proportion of the distance is travelled every frame, which obviously will change when frame times vary, so that's immediately ruled out. Using t = someConstant * dt makes the distance vary depending on frame time, which looks like it should be nearly right but of course isn't, since shorter times mean more steps taken, and each step takes into account the distance travelled since the last, so overall higher frame rates will actually make the current value arrive slower than it would at lower frame rates. Taking this to the extreme, should a frame take a very long time to complete, the current value could catch up in one frame, or even overshoot the target completely. At work whenever I've asked people about this they say someConstant * dt is good enough, and it doesn't really matter since the frame rate will be locked eventually anyway, but that's not the kind of answer I like! What I'm looking for is either the proper way to calulate t, or for someone to tell me I'm being an idiot and that 'lerping' every frame isn't the way to accomplish this at all. Can anyone help?
  4. I recommend Pivotal Tracker. It's nice and simple, yet does a lot. Very good for organising features and work. Doesn't come with all the extra guff like source code viewers and wikis and so on; it's just for tracking tasks. That may be a good thing or a bad thing for you of course!
  5. Tell them that in the interview :) I'd be a useless programmer if I didn't have access to Google and Intellisense. I remember for one test I was expected to do some things I considered silly. I had to write an A* search in Java but wasn't allowed to use any of the Java standard library, and had to write my own queues and so on. But I used them anyway, and wrote comments telling them how mental I thought that requirement was, hoping they'd like the cut of my jib. They disagreed, but offered me the job anyway.
  6. It depends a lot on your degree and other experience. I got £25k just after graduating two years ago, but I graduated from a good university with a first class MEng and had been developing some small games in C++ in my spare time too. This is in the Midlands. Apparently I was given slightly over the odds, though I had the same offer elsewhere. Strangely up north the offers were slightly higher than down south. And of course the offers are much higher the further from games you go (I had a job offer for £30k from one vaguely games-related studio, and an invitation to an interview for a £30k job not in games). I haven't increased from that salary much since then, mind, but that's a story nobody wants to hear. Another way to bump up potential salaries is to have several offers on the table. Then you can do some simple bargaining by just telling them what other offers you have - if they like you they'll offer a higher salary (which in turn you can feed back to the other potentials). It's a bidding war in your favour :) Definitely don't just go for one interview. I think I went for 5 in total, and turned down a few others for various reasons.
  7. Ok, maybe I'm just being overly pedantic! I know it was nice that once I'd made the loops all nice I could dead easily select some loops and bevel them, and I'll really easily be able to e.g. add a ledge all the way round the tower. It's nice being able to do edge slice or that alt+click thing. Thanks for your help again, you can have another level of 'rate up' :)
  8. That's exactly it, Kwizatz, thanks :) BCullis, I've now added the scale to 0 and set coordinate trick to my toolbox, thanks! And I've been reconstructing faces all over the place, it's worked a treat. Only thing is, to keep edge loops tidy I'm finding I'm cutting edges and making nice square polys all over the place, resulting in a lot more geometry than is needed, but I guess that's the right way to do it - optimisation will be the last step, or even an automated one, rather than something to do along the way.
  9. Sorry, I'm not explaining myself well again! If I do that, the edges on the tower will be wonky, i.e. not aligned with the rest of the structure. That's no problem in this simple example but could become messy when adding this kind of feature to something more detailed. But as I say, I could probably just set the vertex coordinates of the vertices on the tower but not part of the little wall; I can't think of any situation that wouldn't be possible or desirable...
  10. Hah, sorry, I must have misunderstood :) I edited my post while you were writing yours though, hope you like it :)
  11. That's what I was looking for :D (EDIT: sorry, that sounded like I'm discounting your advice Kwizatz! You've been helpful too and I've rated you up) How would you make sure the quads lined up? Say you extruded from the rampart upwards, how would you make sure you extruded exactly as far upwards as the quads you'd made in the tower face? If you get it wrong you'll either make the little fence bit wonky or end up with wonky edges on the tower face. I suppose it's easy enough to enter vertex coordinates manually though.
  12. Sorry, the 'one-sided' doesn't make any sense, I should have left it as 'manifold', i.e. no holes, topographically. Just deleting a face will leave a hole in the mesh, which doesn't play well with physics, even if the hole wouldn't be able to be seen as it's flat against another face. Also I should have been clearer, this is just a single game object, not part of a level. I don't think CSG would be appropriate really :) And in any case, I know there are plenty of ways to achieve the shape I want, I'm just looking to expand my modelling knowledge with a quick way to do it using standard 3D modelling tools, rather than moving vertices around and creating faces manually. So the question is really: if you had a model without that little fence, and wanted to put the little fence there but avoiding holes and internal faces, using standard polygon modelling techniques, how would you do it?
  13. I wouldn't want to just delete the faces, I want to keep it manifold in case I want to e.g. use it as a physics mesh in future (quite likely), and because I don't like the idea of dangling one-sided polygons :) Maybe I'm just being too programmer-y about it though. I'll tidy up the skinny polygons later, I know they can cause problems with physics and so on, and I think I can do that fairly efficiently. Thanks for the tips, I think I could fix it up now, but how would you go about creating this arrangement from scratch? So you have the tower and the flat bit the little 'fence' is on, but no fence, and no skinny polygons (they were created because I split edges on the flat bit to have something to extrude from). There has to be a more efficient way than doing it the dumb way and fixing it up vertex by vertex. If doing simple things like this are that complex, you artists have just earned a whole lot of respect from me given the stuff you produce ;)
  14. Egad, I didn't expect that to work as well as it did. I've read all sorts of nasty things about boolean operations but that produced something very clean indeed. I wonder how well it will perform when used on a non-toy example, where the objects are lined up by eye rather than having their transforms entered by hand... Thanks very much Erik :)
  15. Lets say I want to model a cylinder sat on top of a cube, where the cube has a width slightly smaller than the diameter of the cylinder, like in the image below: How would you go about doing this cleanly, all in one mesh, and without any funny faces that nobody can see? I had a go, which involved finding and creating vertices at the intersections of the edges of the two shapes and creating lots of faces using these, but it ended up being a right mess, with edge loops going mental and faces rendering oddly no matter which way round they were told to face. Hopefully someone here will have some idea of how to do this nicely (i.e. nice enough to carry on working on!). I'm a programmer, and if it's not made of boxes, I can't model it :)