• 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

673 Good

About CombatWombat

  • Rank
  1. I don't know if you're still having problems, but what you are describing sounds like a Trapezoidal Motion Profile. Maybe that search term will help you.    
  2. I don't know.  What happens when the camera dies?  How does the dispatcher know to unregister that dangly pointer?  Seems like this just moves that responsibility to the camera object, which then needs to be reimplemented for every game object that registers functions to the dispatcher.  Unless I am misunderstanding.     How do you handle storing the objects (like the camera) in a container (std::vector or similar).  Doesn't that require a copy?   What is the alternative?  Are you saying that the entire Input->MapToActionsWithAContext->ActOnThoseActions model doesn't work well? Or are you saying that the final step of resolving the action via callback does not work well? How else does the game object act upon the action event?   Thanks to both of you.    
  3. I have made an input system based kind of on this: http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/   I have my raw input -> context map -> actions.   I have a dispatcher / subject / observerable (whatever) that will do the notifying when actions are triggered. Implemented very roughly as: vector<*listeners> I have a listener which registers to the dispatcher to handle certain actions. It is implemented roughly as vector<*dispatchers> /// to automatically unregister on destruction map<actions, std::functions> /// function to call given an action, bound to *this with std::bind I would like to place this listener as a member of any game object which should do something with input. class Camera { Camera(); InputListener m_listener; } Camera::Camera() { dispatcher.register(m_listener, event::CAM_MOVE_LEFT); /// probably occurs someplace else, really. m_listener.addCallback(event::CAM_MOVE_LEFT, std::function<void()>(std::bind(Camera::moveLeft, this))); } Problem #1 I had to use std::bind to bring along the *this so that the callback can call the member function.  This isn't a problem unto itself until... ...The parent object is copied. The callbacks which are stored in the listener are now pointing to the pre-copied-object.  This means that any object which decides to have an inputListener as a member must implement a non-trivial copy constructor to rebind all the callbacks with the proper *this.  Kinda stinks of poor design.   I could make the member static, but then wouldn't *all* cameras move left when this callback occurs?   I'm overcomplicating this somehow.        
  4.   Going to try this.  Might do an index instead of the pointer for round one.   Apparently I'm kinda stuck with something like this.  I tried creating my own texture inheriting from the sf::Texture to add the texID integer in there. Then I started inheriting a new RenderStates type from sf::RenderStates.  But then painted myself into a corner because it's implementation uses an sf::Texture and there isn't really a way I can see to override that to use my type without reimplementing the entire thing.  Kinda hokey.     Yeah, I've seen that one.  Also there's a few good ones on LSpiro's page.  Good explanation of the concept, but not enough ideas for implementation for my programming inept skill level.    
  5. I've read everything I could find on these things, and I'm starting to implement this and questions are arising.  Sometimes I find typing all this out helps get my head in order...A lot of this might be duplicates of prior threads asked in a different way and much of it will be just plain hypotheticals...  Without further ado...   I am using SFML and want to sort by texture, and then by depth (really layer, since this is a 2d game).    So.  I can store all the sf::Drawables in a vector (that gets filled by the scenegraph/culling/whatever system). std::vector<sf::Drawable> allOpaqueDrawables; std::vector<sf::Drawable> allAlphaDrawables; Should these be pointers to the drawable which is instead stored in the game objects themselves?  Should there be a master list of all drawables in the game that "owns" them, letting both the game object and these "sub-drawables-within-the-scene" use pointers to this master list? Some other third option?     Now, I need to sort this.  So I can make a render queue which is just indicies into the vector of all drawables. I'm not positive how to implement this... a first try might be something like: std::map<sortKey, int16_t> renderQOpaque; std::map<sortKey, int16_t> renderQAlpha; // with sortkey being a POD integer type built from the texureID and layer value of the drawable I guess the idea is that the small int16 keys are the only thing that needs to be copied around to sort the map?   1) Is this a sane way of doing this part? 2) Is std::map a reasonable choice for the implementation?   Then the map can be iterated through taking the int16_t as indicies into the vector allDrawables to call draw() on each one.   A few problems: 1) Where to store and generate the sortKey, if it needs to be stored at all?        a) I need an integer representation of a texture.        b) (At least part of) the sortKey needs to be updated if the objects layer (depth) changes.   My texture storage assigns a unique integer ID number and prevents duplicates from loading.  Does it make sense to actually store this value in the texture?  Right now it is only kept in the texture storage (as a std::map<texID, sf::Texture>). I could inheret from sf::Texture and create a version that contains the texID.  Unnecessary?   SFML uses an sf::Drawable which contains the geometry to be drawn as well as the "rules" to draw it (actual draw() call). It also uses an sf::RenderStates which holds... 1) *Texture 2) *Shader (if used) 3) *Transform 4) BlendType   Since this RenderState holds damn near everything I need to generate the sortKey, it almost sounds reasonable to create my own RenderStates which derives from sf::RenderStates so that I can contain the sortKey in it and regenerate the sortKey anytime one of those three items are changed.  Yea/Nay?   I realize most of this is just my thinking out-loud/rambling.  Any feedback is appreciated.      
  6. I would be inclined to treat the wing and tail as two lifting surfaces and then apply some NACA Lift & Drag curves. You could do a similar thing for the fusalage (treat it as a long-chord wing section). 
  7. If it's for a game, it's got to be a pretty strange game where the incompressible assumption causes problems.   If it's for an engineering problem, there are off the shelf products both paid and open to solve fluid problems.  Computational Fluid Dynamics code.   If it's purely to learn and play: When you lose the incompressible assumption it becomes simultaneously a fluid dynamics and thermodynamics problem.  You will need to learn about: Bernoulli / Energy equation Thermodynamic Properties The basic laws of thermodynamics   It's a big subject and it's hard to advise you more specifically without knowing where you are starting from.
  8. I think you're having a hard time because you may not be clear what your end goal should look like.  A well described question is halfway answered.   You say it's on rails.  But then you want to account for angle of attack and wingspan while having a constant force driving you forwards.  You seem to be creating a hodgepodge of rails and physics based behavior.  I caution that such a hybrid may create strange edge-case behaviors and may tend to be unintuitive.   Let's break this down to the simplest forces you need to fly.  Airplane, dragon, whatever. Lift, thrust, drag, gravity.   You can use simple lift coefficient for lift force. Its sounds like you want thrust to be constant forward.  You can use simple drag coefficients to get a drag force. Gravity is gravity.   For your rotional control you have 3 axis. Pitch, roll, yaw.   Here is where you need to better define your control scheme.  Should the triggers roll you directly?  Should they be mapped to angle of attack of left and right wings?  Should they be mapped to give an aileron effect (left wing down, right wing up)?  How do you pitch?  You need a tail.  Ditto for yaw. 
  9. Start by thinking about it as heat energy, not as temperature. You can get temperature from the internal energy by having the mass and thermal heat capacity of the objects. The difference in temperature drives a flow of heat energy between the objects. A thermal resistance slows this flow.   It works like Ohms law.  (E=IR) But with thermal-ness it would be (T = QR) where T is temperature delta, Q is heat flow, R is thermal resistance.   How you calculate R is the crux of how complicated your system is!  For a simple "looks good enough" you can just base it on surface area of the objects in contact with a scaling factor.  For a more accurate effect, you'd have to deal with things like arriving at a convection coefficient which is brilliantly convoluted to calculate.  For round objects there are some natural logs that show up in the calculation of R.  There are Nussault numbers and Prandl numbers.  You can go nuts here.   Your specific example of heat transfer from oil->water is an example of a heat exchanger.   If you can be more specific about what you need to accomplish, we can advise you better.
  10.   Hey, it's not entirely useless if you want to play with microcontrollers.     (Ok, most of them have C compilers these days...ahem...)
  11. First you need a more general description for the velocities.   A differential is a bevel gear implementation of a planetary gear train.  For an automotive type differential where the bevel gear ratio is 1:1, the velocities must satisfy: (VL - VH)/(VR - VH) = -1 where VL = left drive shaft velocity VR = right drive shaft velocity VH = housing & ring gear velocity   You can see the derivation of this here: http://books.google.com/books?id=QNj87rJZIpUC&pg=PA373&lpg=PA373&dq=KINEMATIC+EPICYCLIC+GEARING+DIAGRAMS&source=bl&ots=w9OLebHeMw&sig=1Ut2U15xCnXa53MPhdU8bEHbI_A&hl=en&sa=X&ei=RYZzU7HyHc6zsAT9-4H4DA&ved=0CDsQ6AEwAzgK#v=onepage&q=KINEMATIC%20EPICYCLIC%20GEARING%20DIAGRAMS&f=false (Or refer to any kinematics of machinery text)   Add up net moments on the components: The ringgear/housing has a moment on it from the pinion gear.  (This comes from your engine/transmission model). A reaction moment comes from the pin which mounts the center bevel gear. The center bevel gear in turn applies moments to each output shaft. The output shafts have reaction moments from the tire & brake models. The output shafts have reaction moments between them to enforce the velocity rule from earlier.   The various locking & lsd differentials add more forces/moments to these components.  Exactly which components are effected depends on the specific type. Simple example would be viscous style which has a locking effect as a function of velocity difference between the shafts. Add another moment to each axle.  Essentially (leftAxle Velocity - rightAxleVelocity) * someConstant.   To directly answer your question on "preload". Certain types of lsd utilize friction clutches to couple between the two output shafts.  Usually these are angled to be sensitive to the torque input to the differential.  "Preload" means that even with zero torque transmitted, there is still some coupling torque between the output shafts.    A good search term would be "torque in epicyclic gear trains".          
  12. I think this is similar to the "Piano Movers Problem".  It is motion planning / pathfinding with lot's of degrees of freedom.    This article touches on some of the methods (See configuration space part). http://www.gamasutra.com/blogs/MattKlingensmith/20130907/199787/Overview_of_Motion_Planning.php?print=1   Beyond giving you some search terms and links, I can't be much more help as this is kind of over my head, though...   Good luck.
  13. Apparently I've been reading here on and off since... 2000?    And I still have no idea how to program myself out of a wet paper bag...
  14.   The point P(t+dt) is your prediction of where you will be at the next time step.  If you draw a line from P(t+dt) to the track, making the line end up perpendicular (normal) to the track surface, that is essentially your "predicted" elevation. For example, you find this line and it's length is 5 units.  You want to maintain an elevation of 10 units.  You can now extend that line to make it 10 units long.  The new endpoint of that line becomes P(goal).  Now you just need to rotate your velocity vector to intersect with P(goal). This is very similar to what Lorenzo Gatti said with: "If the current velocity would cause penetration (downwards into the road), you can project the computed velocity along the tangent plane of the road."  Except that projecting the velocity vector will shorten it (slowing you down). Rotating the velocity vector will maintain it's length.  Both are valid options depending on what you want.   If you allow rotating your velocity vector both TOWARDS and AWAY from the track, you will get the "spline following" behavior. If you allow rotating your velocity vector only AWAY from the track, you will not crash into the track, but you will float over jumps normally.   If it were my game, I would go the extra step and compute forces needed to actually create this change in velocity and feed them to the physics engine just like any other force.  This isn't absolutely necessary, but I think it can help to avoid weird edge cases in behavior.