Re: [pygame] a bit #ot: design for a game board supporting user facing different directions?

[Alex Hall <mehgcap@xxxxxxxxx>]

I am wanting arbitrary positioning. The grid squares are for
positioning objects on the map and reporting the user's location to
give them an idea of where they are.
I think I can do this in Python, using sound_lib
(http://hg.qwitter-client.net), so I am back on familiar ground as far
as the language goes. However, I tried using the equations you guys
gave me and odd things happened. First, here is my move() function,
stored in the Object class, where Object is something on a map.
self.stepLength is how long each step is and is currently at 1
(meter). I use x and z instead of x and y because of how the bass
audio library, on which sound_lib is based, works; y is height, not
forward/backward movement as one would expect.

 def move(self, direction=None, steps=1):
  #move the specified number of steps in the specified direction (in radians)
  if direction is None: direction=self.angle #currently set to 0 degrees)
  print "Moving "+str(steps)+" steps, facing "+str(direction)+"
degrees. Starting at "+str((self.x, self.z))
  for i in range(steps):
   self.x+=self.stepLength*math.sin(math.radians(direction))
   self.z+=self.stepLength*math.cos(math.radians(direction))
  print "Now at "+str((self.x, self.z))

Starting at (0, 0), you would expect the new position to be (0, 2)
since two steps were taken straight ahead, and this does indeed
happen. However, when you turn to 90 degrees, you would expect 2 steps
to get you to (2, 0), but instead you get this:

Moving 2 steps, facing 90 degrees. Starting at (0.0, 0.0)
Now at (2.0, 1.2246468525851679e-16)

What happened to make the second coordinate so far off? TIA.



On 10/30/11, DR0ID <dr0id@xxxxxxxxxx> wrote:
> On 30.10.2011 04:29, Alex Hall wrote:
>> It is real-time. I don't want it as accurate as movement acceleration
>> for stepping, at least not yet, but I am not sure how I would manage a
>> map without a grid. How, for instance, will the computer know where
>> the player is in relation to objects? If the player fires a weapon,
>> how can the computer calculate if the projectile will hit a target?
>> Currently I am planning to manage targeting by getting the slope of
>> the line and the point of the player, then extending the line to the
>> weapon's range and seeing if it intersects a point on which there is
>> an object.
>> For my game creation I am using the Blastbay Game Toolkit, which is a
>> subset of C++ but written specifically for use with audio games and
>> run sort of as a scripting language through an interpreter. For
>> instance, there is a sound class, a tts class for speaking text,
>> sound_pool (sort of like a "world" that manages sound positioning
>> relative to the player), a timer, and so on. Sound_pool, which I
>> subclass for my Map class, relies on a grid to properly position
>> sounds, which is the other reason I am using grid-based positioning. I
>> can't imagine how it would work with no grid. Is there a way?
>>
>> On 10/29/11, René Dudfield<renesd@xxxxxxxxx>  wrote:
>>> Hi,
>>>
>>> a few notes, and questions...
>>>
>>> Is your game turn based?  Or is it real time?
>>>
>>> If you don't have realistic 3d sound, then using a grid is probably
>>> easier
>>> for players.
>>>
>>> Instead of frame rate, think about it like the update rate of your main
>>> loop.
>>>
>>> Before the player takes a step they are standing.  When standing, speed
>>> is
>>> zero.  When stepping, the person gets some acceleration and moves.  Then
>>> they get some deceleration and stop.
>>>
>>> It's more complicated than that, but the more physically accurate you
>>> want
>>> it, then more complex your code will be.  If you're more interested in
>>> making the game, than a physics engine, you might want to consider
>>> looking
>>> at one of the physics engines available.
>>>
>>> Keeping the game movement to grids might make it easier to play as well
>>> as
>>> program.
>>>
>>>
>>> cheers,
>>>
>>
>
> Hi Alex
>
> Do you know about coordinates and vectors (vector math)? This is how it
> is done in most games. If you make your game grid based, I have not
> understand if you want just go from one grid cell to another or if you
> want to allow arbitrary positions in between cells. According to your
> example it looks to me as if you want to go from one cell to another, so
> going diagonal would just move you to the next cell diagonally. Of
> course this means you travel faster because you cover a longer distance
> (diagonal is sqrt(2) longer) than moving orthogonal. You could restrict
> movement to just up/down and left/right and not allow diagonal movement
> at all. If you want to allow diagonal movement then you need to decide
> if you want to move from cell to cell (where diagonal movement is faster
> then) or if you want to allow arbitrary positions.
>
> I hope it helps.
>
> ~DR0ID
>


-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap@xxxxxxxxx; http://www.facebook.com/mehgcap