haphazardlynamed

Members
  • Content count

    773
  • Joined

  • Last visited

Community Reputation

340 Neutral

About haphazardlynamed

  • Rank
    Advanced Member
  1. Flywheel attitude control...

    Quote:Original post by Speeder Being more direct to those that do not understood: How I convert energy into impulse? Make up any engine efficiency coefficient you want. Higher for easy mode, lower for difficult mode. Since ship 'powerplant' capacity is just an arbitrary number itself, it really doesn't matter what values you use. Just pick something that works reasonably well for gameplay.
  2. AI Movement and Acceleration

    The simple acceleration->velocity->position motion model(like a rocket thruster?) is not appropriate for humans. Humans have feet which effectively attach to the ground(really high static friction) then they change shape(leg joints) to move one foot in front of the other in turn. This lets them stop nearly instantly, since no sliding is involved, he simply stops changing the shape of his leg position. And they can get moving again nearly instantly too, I'd say an acceleration comparable to gravity, since running is just falling forward, right? Don't model the character as a hovercraft, because he isn't one.
  3. Creating objects in portal engine

    Most games leave the gun position as purely a graphical effect, and just make the bullets spawn from the player's center. course this is annoying as heck in Halo3 Sniper games... where the bullets come out of the other guy's head thats peeking over a wall... no gun in sight. But its seems largely accepted to do it that way.
  4. best way to make something orbit

    Depends if these planets are purely graphics effects or if you'll actually want to know their real locations for gameplay/physics inereactions.
  5. Hello, For a recent new project I've been working in a new area for myself, limited hardware. I've only got 16bit numbers... and Fixed Point is pretty new for me. I've now run into a new situation... Wanting to multiply very large numbers by very small ones... in 16bits. So far been ok with stuff like 12.4 and 8.8 fixed point, changing system as needed but mostly keeping them in separate areas. but with the large vs small situation, I'd be trying to do something like 512(2^9)(representable as int16) mutliplied against something like 2^-8 (representable as 8.8fx) since theyre multiplied against one another... I cant really pick one notation system against another cause they can each only be represented at the opposite ends of the spectrum.... So I'm guessing, maybe theres a special algorithm for handling very large vs very small numbers without overflowing or underflowing the bits? Can anyone educate on where to find this? Thanks FYI, the situation where I'm getting this issue, is using PD Controllers to move a spaceship(arcade). The PD would need to output tiny values for controlling acceleration, yet the input distances to target would be very large coordinates...
  6. Rotating a character

    anything wrong with just putting a check right before the acos function call where you clamp the values to Valid ranges before using it? floating points arent ever going to be exact, you just have to be safe about the potential innacuracies...
  7. regarding collision check redundancy: foreach object A foreach object B if &A>=&B break else checkcollision(A,B) , etc saves you the trouble of having to track each object as being checked or not-checked this frame
  8. Traversing a racetrack (Car AI)

    To decide if you have passed a node or not. Take the dot product of (cars position relative to current node) vs (position of next node relative to current node). When it's negative you're still behind the current node, when it's positive you have passed it. Basically the difference in position of next vs current node defines a forward direction vector. Then the position of the car is compared to that to see if its forward of the node or still behind it. This should be a lot cheaper than doing line intersection tests, and give probably the same result. (note, this is based off the centerline nodes only, dont care about the left/right wall nodes) wall avoidance is a separate issue
  9. Suppose I have two interfaces, Physical and Renderable, both of which have a method called 'update()'. And now I create a GameObject class which will implement both of those interfaces. When I define a new update() method in GameObject, how do I specify which of those two interfaces the definition is implementing? Not sure how this kind of conflict gets worked out. Thanks
  10. Sprite/Projectile Management

    I dont have experience with this, so if someone suggests better... please do.. But I would figure its a bad idea to have some collision detection friend class to your existing sprite stuff. They should be pretty separate. Perhaps create a separate physics_base interface and have your game objects multiply inherit from that and your sprite_base, then have two separate managers handling sprite vs physics aspects? Or maybe, have a higher level class called gameobject, which has both a sprite and a 'collidable' as components within itself, each component is then tracked by separate sprite and physics managers. And complex gameplay events are handled by the gameobject itself(kill, spawn children, etc) and it has the ability to send commands to either of the managers?
  11. Space Gravity issues, need help

    Quote:Original post by nahid569 About my spaceship, I knaow it should keep going but if that happened then it owuld be cool but then there would be NO way for the user to stop his ship. Maybe I can do that but wouldnt that be a weird game where the user never stops. You slow down by rotating the ship to face backwards and firing the main engine. Similarly, to make turns, you point the nose of the ship towards the desired center of the turn, then fire the engine and throttle it to provide a centripetal force. Play Asteroids? or Escape Velocity? they tend to be pretty good examples of this working out pretty well.
  12. Please help with moving a particle in 2D space.

    I'll mention, that simply applying an accceleratng force directed towards the target will in many cases result in your object 'orbiting' the target instead of arriving at it. Especially if it has some inital velocity directed elsewhere. It's the velocity, not the acceleration that needs to aim at the target. think along the lines of: acceleration = goalvelocity-oldvelocity
  13. 3D Space Game AI Ideas?

    Seems to me, that more than just going towards your enemy, you'd want to try and intercept his future position based on current velocity and distance. And if trying to escape, do the opposite, by trying to move towards his inverse velocity. Might also be good to consider enemey's current orientation, since thats the direction the main engine can fire to alter his current velocity, as well as where he can shoot. Probably a good attack position is a combo of those factors, interecepting velocity, while also 'behind' the direction facing.
  14. This example made sense to me: http://www.gaffer.org/game-physics/fix-your-timestep/
  15. Your Board class is going to need some sort of data structure to store the ships and bullets on it. Probably a 2d array full of ints where the number indicates if the cell contains a ship, water, or a bullet. Then you'll need some function to populate the array/grid with ships. write some utility function that takes a coordinate, direction, and ship length; then fills in cells accordingly. the hard part will be checking special cases, like ships overlapping or hitting the end of the board. probably have it return true/false to indicate if the request was sucessful or not. you'll need some kind of access funtion that tells if a requested coordinate on the grid contains a ship or not - used to shoot bullets and see if a hit is scored and probably something to draw the ships on the grid...