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


  • Content count

  • Joined

  • Last visited

Community Reputation

547 Good

About Kest

  • Rank
  1. Thanks for your help. I really appreciate it!
  2. After two days of working at it, I finally figured it out. For anyone trying to do the same thing, this is essentially what I did: 1. Remove the primitive bind pose from all ragdoll shapes (ie:[b] inverse(ragdoll_bind_pose)*ragdoll_transform [/b]for every ragdoll bone). 2. Treat the resulting ragdoll transforms (after #1) like rendering matrices, and convert them back to raw unrelative animation states. 3. In order to convert to animation states, I had to do the opposite procedure I did to convert normal animation states to rendering states. For instance, if you compute a character render matrix like this: RenderMatrix = ToOrigin * state * ToJoint * parent;. Then you would reverse that as something like this: state = inverse(ToOrigin) * RenderMatrix * inverse(parent) * inverse(ToJoint); And this worked for me. Now I just need to figure out how to turn the top level bone into character motion. Thanks for your help Ashman!
  3. Yes, that is correct. And thank you very much for the correct answer. Just out of curiousity, and not really related to my original question, is there any way to turn this computation: output = JointToOrigin * State * OriginToJoint Into a single (matrix * matrix) multiply? For instance, can I pre-calculate a matrix using JointToOrigin that will allow me to perform this step with one multiply instead of two? Thank you again for your help.
  4. This seams like it would be rather simple, but I'm having some trouble. I have a few matrices: [code]output = the end result of this operation JointToOrigin = some input matrix OriginToJoint = The inverse of JointToOrigin parent = parent->output (the output of this output's parent) State = An input matrix, and the one I want to extract from output[/code] This is how output is computed with these matrices: [code]MATRIX output; output = JointToOrigin * State; output = output * OriginToJoint; output = output * parent;[/code] Now assuming all of these matrices have the same values as the time of above, is it possible to determine the value of the original -State- matrix? Can anyone help me determine the order I would need to do this in? This is what I have tried, and I've tried re-arranging them, but I haven't had any luck: [code]State = Inverse(parent) * output; State = State * JointToOrigin; // because JointToOrigin is the inverse of OriginToJoint State = OriginToJoint * State; // because it is the inverse[/code] Thank you for any help
  5. Hey guys! I've been trying to figure this out for while now, with no luck. My animated characters use a hierarchy skeletal system. Each limb has a rotational state, which is converted to a rendering matrix by multiplying it with its parents. I have easily figured out how to pose my ragdoll for physics start by determining their matrices using the character's rendering matrices. My ragdoll body parts are not in a hierarchy (which is part of what is confusing me). Each ragdoll body part has a bind transform - a matrix that takes the body part from the zero-origin-point and places it at the limb location of the character. So when all ragdoll parts render with just their bind pose, it would look like a character in their bind pose. In order to place the ragdoll parts, I multiply each ragdoll part's bind pose with the character's rendering matrix for that bone. For instance: Ragdoll_Leg->Transform = MUL( Ragdoll_Leg->Bind_Transform, Character->Leg->RenderMatrix ); This works, and the ragdoll starts exactly where my character is posed. However, I'm having a lot of confusion reversing this procedure and obtaining animated states for the character by using the ragdoll transforms. My character's RenderMatrix for each bone is computed like this: [code] void KRaceBone::ComputeHierarchy(const MTX *states, MTX *finals, const MTX &amp;derive) { finals[Index] = MUL( JointToOrigin, states[Index] ); finals[Index] = MUL( finals[Index], OriginToJoint ); finals[Index] = MUL( finals[Index], derive ); // Compute Children for(int e=0; e<Bones.GetCount(); e++) Bones[e].ComputeHierarchy( states, finals, finals[Index] ); } [/code] Note the inclusion of the "[size=2][font=Liberation Mono]states[color=#00FF00][color=#00FF00][color=#00FF00][[/color][/color][/color][color=#008000][color=#008000][color=#008000]Index[/color][/color][/color][color=#00FF00][color=#00FF00][color=#00FF00]][/color][/color][/color][/font][/size]". That is the pure-rotational local state of each bone. That is what I'm trying to convert my ragdoll parts back into. Anyone have any advice? Anything at all is appreciated. I've been pretty lost at this. Thanks!
  6. When I have a header file that defines a class which uses an object: [code] class MyClass { public: void DoSomething(OtherClass *ptr); private: ..... }; [/code] The compiler complains because it doesn't know what OtherClass is. Yet, as long as I don't use specific parts of OtherClass, I can just pre-def OtherClass at the top of this header: [code] // at the top: class OtherClass; [/code] My question is: Is there a way to have the compiler be okay with this, without adding pre-defs for every variable type passed to a function in the header? Perhaps some compiler option (Microsoft Visual Studio 2010)? Or maybe some type of pointer-type-hiding mechanism? Thank you for any help.
  7. Hey everyone [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Is it possible to scan a class in code to obtain information about members in that class? For example, lets pretend I want to make a function that writes all of the data members and member functions of a class to a text file, along with their types, sizes, values, etc. My calling code would look something like this: [code]class SomeClass { public: int CanYouSeeMe; int IBetYouCant; void MyMethod(); }; template <typename vtype> void WriteClassInfoToFile(vtype &class_ref); // the parameter might be different ..... in some function somewhere: SomeClass test; WriteClassInfoToFile( test );[/code] My resulting text file would look something like this: [code] Class: SomeClass Size: 8 bytes Members: CanYouSeeMe - Type: int IBetYouCant - Type int Methods: 1. MyMethod() - return type: void[/code] Is something similar to this possible? My real reason for wanting to do this is to be capable of adding a real game-code structure to a scripting engine more easily. My scripting engine is capable of defining instances of classes, using them to change members, etc, but each class must be defined into the scripting engine by manually defining each structure member. Thanks for any information [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  8. Well, I searched and found a keyboard testing program which reports which scan codes a keyboard uses for each key, and it seems that the keyboard is working fine. Within the program, the ] key reports scan code 27, which is after [, and all other keys seem correct. So it appears that I am some-how getting the wrong dwOfs value in my enumerating callback function. I check the value ASAP within the actual enumeration function, and it is wrong from the get-go. Any ideas on how I can even begin trying to fix this? Anyone have their own direct input program laying around that shows the scan code for keys being pressed? That way, I could determine if my code is causing this somewhere,or if my keyboard just doesn't play nice with DirectInput. Unfortunately, the direct input samples do not include such a program.
  9. Hey guys. Haven't posted on here for a while. Looks like things have changed since I last did. Anyway, I'm testing my game engine on a laptop, which I know has less keys than a standard keyboard, but what I didn't know is that the scan codes are in a different order for some reason. From what I read in the directX manual, DIK_* defines are supposed to line up with the dwOfs member of the [font=Consolas][size=3][color=#008000][font=Consolas][size=3][color=#008000][font=Consolas][size=3][color=#008000]DIDEVICEOBJECTDATA [/color][/size][/font][/color][/size][/font][/color][/size][/font]structure. However, on this laptop, the [ key is at offset=145, while the ] key is offset=26. IE, the DIK_LBRACKET define DOES NOT corrispond with the [ key. In fact, many of the non-ascii type keys, like brackets and symbols, do not match up with the direct input DIK_* defines. Further, when I attempted to use the "code to ascii" conversion system posted here (at [url="http://www.gamedev.net/page/resources/_/technical/directx-and-xna/converting-scan-codes-to-ascii-r842"]http://www.gamedev.net/page/resources/_/technical/directx-and-xna/converting-scan-codes-to-ascii-r842[/url] ), it outputs the wrong keys for these brackets. My question is this: Is this likely.. 1) Typical behavior? 2) Some type of glitch in hardware or software within the computer? IE, badly ordered keyboard scan codes. 3) A mistake in my code somewhere. Here are the scan codes I printed out from my game's log: [code] Key 0 / tszName= Esc / Offset = 1 Key 1 / tszName= 1 / Offset = 2 Key 2 / tszName= 2 / Offset = 3 Key 3 / tszName= 3 / Offset = 4 Key 4 / tszName= 4 / Offset = 5 Key 5 / tszName= 5 / Offset = 6 Key 6 / tszName= 6 / Offset = 7 Key 7 / tszName= 7 / Offset = 8 Key 8 / tszName= 8 / Offset = 9 Key 9 / tszName= 9 / Offset = 10 Key 10 / tszName= 0 / Offset = 11 Key 11 / tszName= - / Offset = 12 Key 12 / tszName= Backspace / Offset = 14 Key 13 / tszName= Tab / Offset = 15 Key 14 / tszName= Q / Offset = 16 Key 15 / tszName= W / Offset = 17 Key 16 / tszName= E / Offset = 18 Key 17 / tszName= R / Offset = 19 Key 18 / tszName= T / Offset = 20 Key 19 / tszName= Y / Offset = 21 Key 20 / tszName= U / Offset = 22 Key 21 / tszName= I / Offset = 23 Key 22 / tszName= O / Offset = 24 Key 23 / tszName= P / Offset = 25 Key 24 / tszName= ] / Offset = 26 Key 25 / tszName= \ / Offset = 27 Key 26 / tszName= Enter / Offset = 28 Key 27 / tszName= Ctrl / Offset = 29 Key 28 / tszName= A / Offset = 30 Key 29 / tszName= S / Offset = 31 Key 30 / tszName= D / Offset = 32 Key 31 / tszName= F / Offset = 33 Key 32 / tszName= G / Offset = 34 Key 33 / tszName= H / Offset = 35 Key 34 / tszName= J / Offset = 36 Key 35 / tszName= K / Offset = 37 Key 36 / tszName= L / Offset = 38 Key 37 / tszName= ; / Offset = 39 Key 38 / tszName= Shift / Offset = 42 Key 39 / tszName= \ / Offset = 43 Key 40 / tszName= Z / Offset = 44 Key 41 / tszName= X / Offset = 45 Key 42 / tszName= C / Offset = 46 Key 43 / tszName= V / Offset = 47 Key 44 / tszName= B / Offset = 48 Key 45 / tszName= N / Offset = 49 Key 46 / tszName= M / Offset = 50 Key 47 / tszName= , / Offset = 51 Key 48 / tszName= . / Offset = 52 Key 49 / tszName= / / Offset = 53 Key 50 / tszName= Right Shift / Offset = 54 Key 51 / tszName= * / Offset = 55 Key 52 / tszName= Alt / Offset = 56 Key 53 / tszName= Space / Offset = 57 Key 54 / tszName= Caps Lock / Offset = 58 Key 55 / tszName= F1 / Offset = 59 Key 56 / tszName= F2 / Offset = 60 Key 57 / tszName= F3 / Offset = 61 Key 58 / tszName= F4 / Offset = 62 Key 59 / tszName= F5 / Offset = 63 Key 60 / tszName= F6 / Offset = 64 Key 61 / tszName= F7 / Offset = 65 Key 62 / tszName= F8 / Offset = 66 Key 63 / tszName= F9 / Offset = 67 Key 64 / tszName= F10 / Offset = 68 Key 65 / tszName= Num Lock / Offset = 69 Key 66 / tszName= Scroll Lock / Offset = 70 Key 67 / tszName= Num 7 / Offset = 71 Key 68 / tszName= Num 8 / Offset = 72 Key 69 / tszName= Num 9 / Offset = 73 Key 70 / tszName= - / Offset = 74 Key 71 / tszName= Num 4 / Offset = 75 Key 72 / tszName= Num 5 / Offset = 76 Key 73 / tszName= Num 6 / Offset = 77 Key 74 / tszName= + / Offset = 78 Key 75 / tszName= Num 1 / Offset = 79 Key 76 / tszName= Num 2 / Offset = 80 Key 77 / tszName= Num 3 / Offset = 81 Key 78 / tszName= Num 0 / Offset = 82 Key 79 / tszName= Num Del / Offset = 83 Key 80 / tszName= F11 / Offset = 87 Key 81 / tszName= F12 / Offset = 88 Key 82 / tszName= Kana / Offset = 112 Key 83 / tszName= Convert / Offset = 121 Key 84 / tszName= No Convert / Offset = 123 Key 85 / tszName= F14 / Offset = 125 Key 86 / tszName= = / Offset = 144 Key 87 / tszName= [ / Offset = 145 Key 88 / tszName= ' / Offset = 146 Key 89 / tszName= ` / Offset = 148 Key 90 / tszName= Num Enter / Offset = 156 Key 91 / tszName= Right Ctrl / Offset = 157 Key 92 / tszName= Num / / Offset = 181 Key 93 / tszName= Prnt Scrn / Offset = 183 Key 94 / tszName= Right Alt / Offset = 184 Key 95 / tszName= Pause / Offset = 197 Key 96 / tszName= Home / Offset = 199 Key 97 / tszName= Up / Offset = 200 Key 98 / tszName= Page Up / Offset = 201 Key 99 / tszName= Left / Offset = 203 Key 100 / tszName= Right / Offset = 205 Key 101 / tszName= End / Offset = 207 Key 102 / tszName= Down / Offset = 208 Key 103 / tszName= Page Down / Offset = 209 Key 104 / tszName= Insert / Offset = 210 Key 105 / tszName= Delete / Offset = 211 Key 106 / tszName= Left Windows / Offset = 219 Key 107 / tszName= Right Windows / Offset = 220 Key 108 / tszName= Application / Offset = 221 [/code] Thank you for any help.
  10. One of my friends found this, and we have no idea what it is. The diameter is smaller than a button, and it's about half an inch tall. It screws apart in the middle, where two watch-battery size batteries go. Under the bottom battery is a magnet, which makes the whole thing magnetic. When you screw it together with batteries, one of the three symbols lights up blue, and blinks on and off. A bit too bright to be a stealthy tracking device. My friend said that at one time, the other side lit up red, and the lights alternated back and forth. Sorry, these pictures are blurry. The middle picture on it looks like a rectangle with 4 lines coming up from it. The top three triangular symbols are all very similar. Does anyone know what this thing is?
  11. There are some really detailed answers here. I really appreciate the time you guys put into it. I'm still looking over it all. Quote:Original post by SiCrane I'm assuming you want all of the vector inputs and outputs to be normalized vectors. In that case you could use: Vector proj = projection of childvec onto stillvec Vector perp1 = childvec - proj Vector perp2 = perp1 normalized float scalar_perp = sqrt(1 - dot_limit * dot_limit) return dot_limit * stillvec + scalar_perp * perp2 Dude, you're awesome for laying the math out in code syntax for me (not sure if you remembered that I absorb it better that way or not). But I'm not sure I understand the first line. What would be the projection of childvec onto stillvec? Do you mean to smash it onto its normal? Something else?
  12. If I have two normalized vectors, and a dot product limitation, is there a cheap gimmick I could use to limit one vector to that dot product of the other vector, without computing angles and performing axis rotations? Here's the data I have: Vector stillvec; // Changes, but can't be changed for this operation Vector childvec; // Rotates around independently of stillvec float dot_state = Dot(stillvec,childvec); float dot_limit; // Probably about 0.5. I want to keep dot_state above this by modifying childvec I know there are a lot of neat tricks to be done with dot products, planes, distances, etc. But I don't know if any of them will help me here. I appreciate any advice.
  13. When I started thinking about this for my own project, I first believed it was just a tedious action to put the player through. That by providing lootable bodies/objects, we're just creating a pointless incentive for players to stop having fun and click things. After some time later, I've started to change my mind. Having to stop to loot things does interrupt the action. But that probably does more good than bad in most situations. The player has been rampaging through an area, ducking for cover, blasting things, etc. With auto looting, it's just off to the next room/hallway to rampage/cover/blast again, then again, then again, until something like a cut-scene takes over. With manual click looting, it creates a change of pace and action to slow down and look around for useful items. With manual looting, it wouldn't hurt to provide clues as to which characters are most likely to have this or that item before the player begins digging into everyone's pockets. For example, maybe foot clan soldiers only carry knives, so the player never needs to consider them. But the ninja masters are heady guys that tote around important things, so it's always a good idea to check them out. The same goes with container objects. If you randomly place very important items in every type of container, it's just going to force players to click everything, rather than use their brain and discretion.
  14. Quote:Original post by theOcelot What has happened to our society when doing what's right for its own sake has become a foreign, "unrelatable" concept? It's not just a matter of doing what's right. It's usually more of a measurement of consequences. For example, normal people don't risk life and limb to help someone they don't know take care of a pest problem just because it seemed like the right thing to do. This is the usual situation in hero-based games, even though the life in question is artificial. The player can bet money that his life is going to be thrown into a blender during the "quest", regardless of what it first seems to be. And the player rarely has realistic incentive to help these people in the first place. He's most likely doing it for whatever artificial reward pops out at the end, such as experience or points. And that's another situation that can be made to seem less artificial. If you want the player to have a realistic reason to want to help someone they don't know, have those people promise specific amounts of money when the job is done, and don't give the player an option to not take the money once it's done. Now he's doing the right thing, getting paid for it, and still feeling good about it.
  15. I don't have great answers to any of your questions, just some random observations. When a hero saves someone at the risk of their own life, most people will smile. When an evil villain saves someone at the risk of their own life, it might be enough to make a grown man cry. It means something much greater. He isn't just doing his job, or doing what's expected of him. He's going against his nature and instincts, and breaking his established identity, because as much as he hates to admit it, he cares. People also like villains that switch over to the good side. Especially if they only did so for selfish reasons, then "accidentally" converted. They usually don't have the artificial appearance that born-as-heroes have. They aren't always nice, and they don't help other people just because they feel like they have to. They usually only help when they can enjoy their power by ripping other bad guys to shreds, or when it hurts what little humanity they have too much to just stand there and do nothing. I think the artificial goals of a hero are the hardest thing to sell. Heroes whose goals are to save other people, at the risk of death, for no particular self-incentive, aren't very relatable to human beings. I think one solution is to come up with practical goals that are a little more selfish. It could be something pretty simple. For example, the character might be battle hungry - always thirsting for conflict. When someone asks the player hero why he's risking his life to weed their garden, it's because he just needs his fix. They have killer plant enemies they can't deal with, and he needs enemies to defeat. It works out for everyone. Something else that I think helps to sell a hero is a lovable population. It's sometimes difficult to enjoy being a hero when the world doesn't even seem worthy of being saved. Sprite based games usually do a good job of this for me, because most of the characters are adorable looking, and I can't stand the thought of them being hurt. But it's difficult with renders or models (Fallout 3 has attractive characters, but most of them were far from lovable). Without sprites, psychology is about the only tool we have to make characters more likable. One solution that might work would be to underdog the general population. If another high and mighty group of people are pushing them around, it might make it easier to jump to their side. That's about all I've got. I hope some of my random ramblings helped somewhat.