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

[Alex Hall <mehgcap@xxxxxxxxx>]

Never mind, I found it. The result is very small, but not quite 0 due
to Python's standard floating point numbers not having the precision
to go further. I'll just check for this sort of thing and assume 0 if
the result is too low.

On 11/2/11, Alex Hall <mehgcap@xxxxxxxxx> wrote:
> 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
>


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