From: “John J.” [email protected]
Thanks Bill,
That clears up a lot. You do games for a living or something?
Used to. Amiga / Atari / SEGA / Playstation stuff.
As for motion, pretty simple. But needs to be just so…
The player and enemies should all move N, S, E, or W only. (remember,
the original Nintendo’s D-pad is only 4 directional)
Movement should come to a complete stop when no D-pad button (or
arrow keys) are depressed.
In Gosu’s tutorial, there is a velocity factor that I haven’t quite
got a hang of. The acceleration is ok, but needs to stop pretty
abruptly.
OK. Keep in mind that the acceleration shown in the tutorial
is not part of Gosu at all. I.e. there’s no magic going on
behind the scenes. The few lines of code in that Player class
are doing all the work, and you could substitute that code
with anything you wanted.
Also, I’d like the movement input to immediately change direction if
a new key is pressed, so that a new direction key overrides even a
previously depressed direction key. Couldn’t figure out how to do
that. I tried some while loops, even inside of if’s but the app
always crashed or went infinite on me.
Hmm, that’s strange about the crashing. (Maybe Gosu doesn’t
handle an object being drawn way off-screen or something,
although it should be nice about such things. Can’t guess
how or why it would end up crashing. Sounds like a bug.)
Anyway… This is the tutorial code I’m looking at:
class Player
def initialize(window)
@image = Gosu::Image.new(window, “media/Starfighter.bmp”, false)
@x = @y = @vel_x = @vel_y = @angle = 0.0
end
def warp(x, y)
@x, @y = x, y
end
def turn_left
@angle -= 4.5
end
def turn_right
@angle += 4.5
end
def accelerate
@vel_x += Gosu::offset_x(@angle, 0.5)
@vel_y += Gosu::offset_y(@angle, 0.5)
end
def move
@x += @vel_x
@y += @vel_y
@x %= 640
@y %= 480
@vel_x *= 0.95
@vel_y *= 0.95
end
def draw
@image.draw_rot(@x, @y, 1, @angle)
end
end
What they’re doing there would give a very Asteroids-like
movement behavior.
They load some sort of space ship sprite, and they maintain
a position (@x, @y), and a 2D velocity vector (@vel_x, @vel_y).
The #move and #draw methods would typically be called each
game frame.
The #accelerate method would be called once per game frame
IF a ‘thrust’ key were held down.
The #move method simply increments the ship’s current position
by its velocity vector, then wraps the ship at the edge of a
640x480 playfield, similar to Asteroids. Finally, it applies a
deceleration factor each time, so without any new thrust
applied by #accelerate, the velocity will slowly decrease.
If you wanted to stop the ship dead in its tracks, you’d only
need to clear @vel_x and @vel_y.
Anyway, for a Zelda game, an acceleration + velocity model
is probably not an ideal fit (however, I’ve never seen Zelda
in action, so I don’t know what the player movement looks
like.)
I’d think you could dispense with the velocity vector and
simply increment the position by a constant, depending on
which of the “north, south, east, or west” movement buttons
is pressed.
I think I can hack out the sprite animations, from other examples it
seems to use something similar to a CSS rollover effect, with an
image that actually is only displayed partially, but what part is
displayed is changed.
Right. When it comes down to it, Gosu leaves determining
which sprites to draw where totally in your hands, which
is good. So animating a sprite becomes just indexing
through a sequence of images that you keep track of
yourself. (Gosu provides a load_tiles method to help
dice up a large image into tiles; but you don’t have to
use that. Ultimately, the animation is produced when you
decide which sequence of images to render in succession
at what location on the screen.)
The screen should only scroll for transitions from screen to screen,
pretty common effect on 8 bit Nintendo games and Game boy/ Advance/
DS games.
OK, in that case I’d worry about the scrolling later.
Just make the screen-to-screen transitions “snap” at
first. Scrolling won’t be hard to add, but it sounds
like it’s just a transition effect.
Once this is all done, everything else will be cake.
Actually, I thought you just described the easy part.
Almost every
other feature is simple event driven stuff, easy to insert into
existing methods or functions. (play a sound, or video when something
special occurs)
You’ll also need logic for what kinds of tiles the player
and monsters are allowed to walk on. (Or fly over if there
will be some flying monsters.)
If monsters will roam around in the game looking for the
player, you may need some shortest-path finding algorithms
(for example, breadth-first search.)
I spent last night getting pygame installed, and though it is
installed, I know zero about python. It’s pretty established so I
will try it out. Maybe the tutorials there will give me ideas for how
to do things in Gosu.
Cool, always fun to learn new stuff. However, I can confidently
say that Gosu is more than capable of handling the animation
requirements for the game you’ve described so far.
Regards,
Bill
