• 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.

MisterFuzzy

Members
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

161 Neutral

About MisterFuzzy

  • Rank
    Member

Personal Information

  • Location
    World 8-3
  1. You see, the first comment you post that actually follows forum rules should not openly rant against the moderators that locked your violating topic, and surely your second and third shouldn't lash out against those who pointed out your mistake. You asked for a job. You almost had one. Then you decided to post a smart-ass reply, and pretty much sank your reputation. Just because a job is simple, doesn't mean that it's demeaning. If you did well, I probably would have asked you to make some music for my game Xenith, a 3D RPG that is nearing completion. But whatever. Your choice.   Anyway, I should probably delete this old account. Too much spam.
  2. Let's say your draw region is 100x100, and positioned from the topleft corner at 256x256. To get the mouse position in the box, you would just subtract the measure of the top-left corner from the mouse XY position to get a relative value. Then, you can use simple checks ( if newX < 0 || newX > 100, then mouse.X is not in the box's x bounds and therefore cannot be in the box, else check newY etc. etc.). That's all there is to it! Really. That's all.
  3. Why are you ending your gameloop? In your loop, it would be far more efficient to have a boolean value DoUpdate that defaults to true. All motion and calculation would be done only if DoUpdate is true, else everything becomes static - just sits there. It still draws (You could use the boolean to control this, too), but nothing will move until DoUpdate was set back to true. Bam! Paused.
  4. Thanks, Daaark! That's exactly what I was looking for .   Yeah, I plan on having each mesh hold a collision sphere, and for each particular mesh collision (on a character or vehicle) the "weight" of damage to be applied will be determined by what mesh in a model was "hit." Of course, a shotgun to a car's bumper shouldn't stop it, but the engine? Not so much. A rocket would kill a vehicle if it hit anywhere :D.   From there, I plan on having an undrawn "collision model" that handles any per-vertex collision that is the same shape as the model, but is far less detailed. It will cover the general area, but with far fewer vertices. It will be subdivided into meshes, so I can handle the "weight of damage" I mentioned earlier.
  5. Aye, I've already been considering the "narrow it down" apporoach, I can detect which mesh in a model was hit to appropriately apply damage (A head shot would be an instant kill, whereas a shot to the toe should do little to no damage): But what I really would like is an article on collision detection of actual Models/volumes. I can't seem to find one that involves just the models without the bounding boxes or spheres. Thanks, though!
  6. Hey!   I'm not exactly proficient with 3D collisions. 2D is fine, but 3D volumes are, needess to say, quite a bit different. I've been reading around the interwebs on 3D collision, and all seem to say the same thing: "Using bounding spheres..." The thing is, for my experimental FPS, bounding spheres can be too inaccurate: Players could be frustrated when they die when a bullet whizzes just in front of their face, or a clear hit travels straight through their target without ever touching the bounding box. My question is, how can I get accurate collision detection without sacrificing speed or accuracy?   (An article would be great, too)
  7. Rendering objects to a render target does have it's perks over traditional spritework. For one, as already stated, it can potentially take a lot less memory to store than large or numerous graphics or spritesheets. Animation can be done by simply iterating through the model's frames, and bones can be moved manually to add functionality that would otherwise be extremely difficult to achieve, such as preserving the character's running animation while holding a large object in their hands (animation blending) or looking at something in the world (bone transformation). Single parts of the body can be scaled and twisted, so that you could easily incorporate things like "shrink potions" or "giants" for the player to fight. Because of the perk of easy scalability (no detail is lost when the image is scaled up), you can easily write a small algorithm that makes the sprites look the same on any computer, taking up X percent of the screen's viewport resolution.
  8. First off, you will never find a game programming book that will specifically cover "making things explode." The purpose of the books is to teach you the general concepts of programming interactive media, not spoon-feed answers to it's readers. Making things explode is something that howto authors expect the reader to figure out on their own using the general concepts discussed in the book. For example, if a book discusses rigid body physics you can use that general info to make an explosion by instantiating smaller models of the vehicle's parts (body, wheels, engine, what have you) and apply an initial velocity to each part based on the car's last speed. Add a few particles and some spiffy sound effects and whammo! You have a car exploding.       Even though this seems a simple enough task, depending on how you want to do this you will need quite a bit of math. First, using a completely transparent "overtexture," you will have to use some fancy formulas to correspond where the mouse/pointer/whatever is over your model to the UV coordinates on the texture. If you want to have part-by-part coloring options (color the door, hood, et cetera), you could have a simple checklist of each part and corresponding color (and simply change the hue of certain parts of the texture). For decals, you will need to find the UV coordinates as stated above and apply the decal in real-time. A little complicated, to be sure, but easy enough for an intermediate programmer to be able to work out. Then, there's directly painting the cars. Not only will you have to calculate the UV coordinate relations with the model, but also skew the paint zone depending on the angle of the camera. If the user sees a circular brush icon, but are looking at the car at a forty-five degree angle, just drawing a circle at the coordinates would produce undesireable results: To fit the brush shape, the new shape would have to be an ellipse!   . . . I guess all I'm really trying to say here is that you can't expect books to address your needs specifically: Just use trial and error to make your own solution that's tailored to your own needs.
  9. Everything is working now :).   I'd recommend normalizing the input from the keyboard to make the player move the same speed in every direction.
  10. Whee-hee. So did many of the other users here. Heck, I'm pretty sure some of the people who post around here are STILL 10-11 years old. However, as stated before, you are asking for someone to just give you the code you want. All that will do is force you to come back to the forums and beg when you can't do the same thing later on. MJP gave you a REALLY easy way to do it, L. Spiro, although somewhat curtly, gave you the answer you needed as well. Just... Listen.
  11. Have you considered NOT drawing the tiles that are not visible on-screen? I'm constantly forgetting to do this myself...
  12. Win7 with AMD Vision A8 laptop, unable to start correctly (0xc000007b). That is all.
  13. You should probably move that bool to when the player[b][i] releases [/i][/b]the jump button, because if it only triggers at the 50px mark, you could make a half-jump but then press the button again to hover.
  14. The root usually isn't your Content folder, it's the application root... So you still need to navigate to your content folder. This may or may not be the case (I usually have to set the directory myself), but try printing a debug string with the value "content.RootDirectory" to see where it's going.
  15. Is there a problem with simply modifying the wheel mesh by rotating it 90 degrees in an external editor? Can't really tell you much if you don't post code...