rubygame

[John Joyce]

Wow!
rubygame seems like a royal pain to install!
no luck.
Installed SDL, but rubygame rake install fails with a long error
ending with:

No such file or directory - ext/rubygame/rubygame_gfx.bundle

I hate to be a whiner, but that's just way too much for 1 mortal to
deal with just to try it out.
Gosu was a lot easier to install, even though it's documentation
consists of a single tutorial and features are either limited or just
undocumented. Fairly intuitive, yet still hard to do a lot with at
this point.

I guess Ruby just isn't really ready for making a game in a really
lazy Ruby way.
Back to the Torque game engine I guess, with its strange C# glue coding.
At least it's more useable, even though I will eventually have to buy
a license for it.
Either that or learn Java or Python (pygame).
Pygame has a lot kinder installer, of course it's been around a lot
longer.



Ok, I'm whining.
Funny thing is, until trying Gosu on a whim, I never really
considered building a game before, but now I've got the bug.
(one thing to note here, by game I mean a graphical game. I've built
my own toy text adventure, but it gets boring pretty quickly.)

rubygame and gosu teams, keep up the good work, and I'll be back at
toying with it when it improves!
cheers.

 

[Jeremy Woertink]

I guess Ruby just isn't really ready for making a game in a really
lazy Ruby way.
Back to the Torque game engine I guess, with its strange C# glue coding.
At least it's more useable, even though I will eventually have to buy
a license for it.
Either that or learn Java or Python (pygame).
Pygame has a lot kinder installer, of course it's been around a lot
longer.

Vampire the masquerade bloodlines has a ton of Python in it. If you know
python, you can hack that game like it's cool! I don't know python, but
as for ruby... There is Shattered Ruby that's been in production. It's
pretty cool, still needs a lot of work, but it would be nice to see more
people trying it out and helping with the bug, maybe get the development
on it moving a bit quicker.

http://www.shatteredruby.com/


check it out.


~Jeremy

 

[James Britt]

Wow!
rubygame seems like a royal pain to install!
no luck.
Installed SDL, but rubygame rake install fails with a long error ending
with:

No such file or directory - ext/rubygame/rubygame_gfx.bundle

I hate to be a whiner, but that's just way too much for 1 mortal to deal
with just to try it out.

You'll have to wait a bit until Railgun rocks your world.

http://panelpicker.sxsw.com/ideas/view/475

 

[Bill Kelly]

Gosu was a lot easier to install, even though it's documentation
consists of a single tutorial and features are either limited or just
undocumented. Fairly intuitive, yet still hard to do a lot with at
this point.

I have not yet tried Gosu myself; but just out of curiosity,
what sorts of things did you find hard to do with it?


Regards,

Bill

 

[John Joyce]

I have not yet tried Gosu myself; but just out of curiosity,
what sorts of things did you find hard to do with it?

hmm. Beyond the tutorial? more than fiddling with the tutorial?
Couldn't do much. Maybe I'm missing something.

 

[Bill Kelly]

hmm. Beyond the tutorial? more than fiddling with the tutorial?
Couldn't do much. Maybe I'm missing something.

OK. I guess I'm unclear now on whether you found specific
capabilities lacking or missing in Gosu? E.g. you have a
particular kind of game in mind, and Gosu didn't seem to
provide the functionality needed to implement your idea?

Might i enquire as to what genre of game you had in mind?
I've written several and may be able to help.

BTW, there are some small games on this page, written in
Gosu, that come with source code:

http://code.google.com/p/gosu/wiki/GosuUsers


Regards,

Bill

 

[John Joyce]

OK. I guess I'm unclear now on whether you found specific
capabilities lacking or missing in Gosu? E.g. you have a
particular kind of game in mind, and Gosu didn't seem to
provide the functionality needed to implement your idea?

Might i enquire as to what genre of game you had in mind?
I've written several and may be able to help.

BTW, there are some small games on this page, written in
Gosu, that come with source code:

http://code.google.com/p/gosu/wiki/GosuUsers


Regards,

Bill

Yeah, I checked out some of those. But the code was, admittedly,
undocumented for at least one of those.
To boot, neither one had much in common beyond the basic structure.
That's not bad, but it wasn't terribly helpful.
My goal is to create a knockoff of the original Legend of Zelda. A
fairly simple top-down 2d game.
I was having a bit of trouble getting movement to be only vertical or
horizontal. That's not so crucial.
However, I didn't see any obvious method of collisions based on the
graphic shape.
In one of those examples there was some small degree of sprite
animation, but couldn't make sense of it.
I'm totally new to the game thing, so maybe I'm missing some of the
standard code that would be found anywhere.
My plan is to first work out player movement, enemy movent, combat
between the two, then work out all the littler details of items and
what not.

 

[Bill Kelly]

Might i enquire as to what genre of game you had in mind?
I've written several and may be able to help.

[...]

My goal is to create a knockoff of the original Legend of Zelda. A
fairly simple top-down 2d game.

Cool

I was having a bit of trouble getting movement to be only vertical or
horizontal. That's not so crucial.

If I've understood the Gosu tutorial code correctly, it
looks as though your code would be responsible for rendering
the entire scene, and would be responsible for determining
what should be shown on screen.

If so, I'd expect any kind of perceived movement would be
your code deciding to draw all the sprites and background
at a different offset than the previous frame.

However, I didn't see any obvious method of collisions based on the
graphic shape.

Ah... I noticed on the DesignRationale page:
http://code.google.com/p/gosu/wiki/DesignRationale

Sounds like collision detection is not within the scope
of Gosu.

However, for a Zelda-like game, I think you could get pretty
far on simple axis-aligned bounding boxes.

If that. ...Weren't the original Zelda's strictly tile-based?

If so, it would typically come down to just a simple grid,
and whether a particular 'square' is occupied. (I've never
played Zelda, I'm just looking at screenshots.)

If you're doing a strictly tile-based game, you may not need
to worry about shape-based sprite collisions at all.

If you do want shape-based sprite collisions, I'd recommend
maybe starting out with simple axis-aligned rectangles,
and see how far that gets you.

In one of those examples there was some small degree of sprite
animation, but couldn't make sense of it.

From the tutorial, it looks like there's a helper method
called load_tiles that will dice up an image into an array
of sub-image tiles for you:

@animation = Gosu::Image::load_tiles(self, "media/Star.png", 25, 25, false)

Then when animating, it appears they're just taking one of
these arrays of tiles, and indexing through it based on
elapsed clock time (current millisecond tick count.)

img = @animation[Gosu::milliseconds / 100 % @animation.size];
img.draw(@x - img.width / 2.0, @y - img.height / 2.0,
ZOrder::Stars, 1, 1, @color, :additive)

I'm totally new to the game thing, so maybe I'm missing some of the
standard code that would be found anywhere.
My plan is to first work out player movement, enemy movent, combat
between the two, then work out all the littler details of items and
what not.

Sounds like a good plan.

Since Gosu is hardware-accelerated, you may be able to get
away with simply re-drawing the whole scene every game frame.

Are you planning to have various terrain tiles, like
forest, water, stone, grass, dirt, etc.?


LOL, now I almost feel like writing a little game.


Regards,

Bill

 

[John Joyce]

Might i enquire as to what genre of game you had in mind?
I've written several and may be able to help.

[...]

My goal is to create a knockoff of the original Legend of Zelda.
A fairly simple top-down 2d game.

Cool

I was having a bit of trouble getting movement to be only vertical
or horizontal. That's not so crucial.

If I've understood the Gosu tutorial code correctly, it
looks as though your code would be responsible for rendering
the entire scene, and would be responsible for determining
what should be shown on screen.
If so, I'd expect any kind of perceived movement would be
your code deciding to draw all the sprites and background
at a different offset than the previous frame.

However, I didn't see any obvious method of collisions based on
the graphic shape.

Ah... I noticed on the DesignRationale page:
http://code.google.com/p/gosu/wiki/DesignRationale

Sounds like collision detection is not within the scope
of Gosu.

However, for a Zelda-like game, I think you could get pretty
far on simple axis-aligned bounding boxes.

If that. ...Weren't the original Zelda's strictly tile-based?

If so, it would typically come down to just a simple grid,
and whether a particular 'square' is occupied. (I've never
played Zelda, I'm just looking at screenshots.)

If you're doing a strictly tile-based game, you may not need
to worry about shape-based sprite collisions at all.

If you do want shape-based sprite collisions, I'd recommend
maybe starting out with simple axis-aligned rectangles,
and see how far that gets you.

In one of those examples there was some small degree of sprite
animation, but couldn't make sense of it.

From the tutorial, it looks like there's a helper method
called load_tiles that will dice up an image into an array
of sub-image tiles for you:

@animation = Gosu::Image::load_tiles(self, "media/Star.png", 25,
25, false)

Then when animating, it appears they're just taking one of
these arrays of tiles, and indexing through it based on
elapsed clock time (current millisecond tick count.)

img = @animation[Gosu::milliseconds / 100 % @animation.size];
img.draw(@x - img.width / 2.0, @y - img.height / 2.0,
ZOrder::Stars, 1, 1, @color, :additive)

I'm totally new to the game thing, so maybe I'm missing some of
the standard code that would be found anywhere.
My plan is to first work out player movement, enemy movent,
combat between the two, then work out all the littler details of
items and what not.

Sounds like a good plan.

Since Gosu is hardware-accelerated, you may be able to get
away with simply re-drawing the whole scene every game frame.

Are you planning to have various terrain tiles, like
forest, water, stone, grass, dirt, etc.?


LOL, now I almost feel like writing a little game.


Regards,

Bill

Thanks, I'll have to digest some of that.
Anymore explanation of axis-aligned rectangles? what do you mean axis-
aligned? (i'm new at the game thing)

Yes, I have a plan typed up for tiles and a grid for a screen and a
grid for the map.
Actually, they did use shape based collisions. I found a file that
details a lot of technicals about the game. ROM rippers use that
stuff to decompile and build game console emulators. The old 8bit
nintendo was one of the toughest in the way mapping was done. Many
games have completely unique ways of mapping.
The tiles in Zelda are actually smaller than they seem. Where you
might think there is one tile, there are usually 4 tiles.
My biggest frustration will no doubt be getting the motion I want.

I want to basically recreate the game, though some boss enemies will
be pretty tough to build, but ultimately I'd like to reinvent it with
a new adventure with the same basic mechanics.

It's a classic game. You'll like the original.

 

[Bill Kelly]

Anymore explanation of axis-aligned rectangles? what do you mean axis-
aligned? (i'm new at the game thing)

Considering the origin at the lower left corner of the screen,
you'd have the X and Y axes:

Y
^
|
|
|
+------> X

(Or sometimes Y is inverted, if your preference is to
deal in screen-space Y coordinates increasing from
top of screen to bottom; but anyway...)


In 2D, an axis-aligned bounding box would be a
rectangle defined by two points. The top and bottom
edges of the rectangle are parallel to the X axis,
and the sides are parallel to the Y axis.

This makes collision tests like point-in-rect, and
rect-rect-overlap extremely easy to write.

AABB's (axis-aligned bounding boxes) are of course
usually an imperfect approximation of the various-
shaped objects in a game; however for many games they
are sufficient. (Even recent popular 3D games like
Quake use AABB's for collision detection.)


If/when AABB's turn out to be too imprecise for a
game, there are all sorts of various methods to get
more collision resolution. In 2D, these could include:
collision mask shapes for sprites; other collision
primitives like elipsoids or rhomboids; a quadtree
decomposition of fine-grained AABB's or rhomboids; etc.


But anyway, for your game I'd recommend either going
strictly tile based for simplicity; or going with
AABB's. My guess is most of your game should be
fine with simple axis-aligned collision tests. If
at some point you have some really weird shaped
boss creature that needs something more precise
than a rectangle for collision purposes, you could
deal with that when you get to it. (Often, just
using a few smaller rectangles instead of one big
rectangle can be good enough.)

The tiles in Zelda are actually smaller than they seem. Where you
might think there is one tile, there are usually 4 tiles.
My biggest frustration will no doubt be getting the motion I want.

What sort of motion will that be? Are you talking about
how the whole world scrolls past the screen? Or how
various monsters animate as they move?

I want to basically recreate the game, though some boss enemies will
be pretty tough to build, but ultimately I'd like to reinvent it with
a new adventure with the same basic mechanics.

Sounds fun.


Regards,

Bill

 

[John Joyce]

Considering the origin at the lower left corner of the screen,
you'd have the X and Y axes:

Y
^
|
|
|
+------> X

(Or sometimes Y is inverted, if your preference is to deal in
screen-space Y coordinates increasing from
top of screen to bottom; but anyway...)


In 2D, an axis-aligned bounding box would be a rectangle defined by
two points. The top and bottom
edges of the rectangle are parallel to the X axis,
and the sides are parallel to the Y axis.

This makes collision tests like point-in-rect, and
rect-rect-overlap extremely easy to write.

AABB's (axis-aligned bounding boxes) are of course
usually an imperfect approximation of the various-
shaped objects in a game; however for many games they
are sufficient. (Even recent popular 3D games like
Quake use AABB's for collision detection.)


If/when AABB's turn out to be too imprecise for a
game, there are all sorts of various methods to get
more collision resolution. In 2D, these could include:
collision mask shapes for sprites; other collision primitives like
elipsoids or rhomboids; a quadtree
decomposition of fine-grained AABB's or rhomboids; etc.


But anyway, for your game I'd recommend either going
strictly tile based for simplicity; or going with
AABB's. My guess is most of your game should be fine with simple
axis-aligned collision tests. If
at some point you have some really weird shaped
boss creature that needs something more precise than a rectangle
for collision purposes, you could
deal with that when you get to it. (Often, just
using a few smaller rectangles instead of one big
rectangle can be good enough.)



What sort of motion will that be? Are you talking about
how the whole world scrolls past the screen? Or how
various monsters animate as they move?



Sounds fun.


Regards,

Bill

Thanks Bill,
That clears up a lot. You do games for a living or something?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.
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.

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.

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.

Once this is all done, everything else will be cake. 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)

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.

 

[Bill Kelly]

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:ffset_x(@angle, 0.5)
@vel_y += Gosu:ffset_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.

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

 

[John Joyce]

Used to. Amiga / Atari / SEGA / Playstation stuff.

Excellent. Hard to believe you never saw Zelda in action though!
Movement is similar to any tank game. Slightly better than your
average RPG from that era. Movement is not confined to a grid of the
tiles, only constrained by Objects you can't move over.

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.

What they're doing there would give a very Asteroids-like
movement behavior.

Yeah, first thing you notice on firing up the demo is 'asteroids'-ish
movement, but more of a pacman collecting goal.

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.

Any example of how that would go, roughly? (pseudo code is ok too)
Like I said, this is all new to me.

Any advice on where to find 2D game algorithms/design patterns?

 

[Bill Kelly]

Excellent. Hard to believe you never saw Zelda in action though!

Agreed! I was mostly into the Amiga back then rather than
console games. Plus I had this borderline-unreasonable
disdain for any adventure game that was modal. E.g. I
didn't like the kind where you'd be walking along, encounter
an enemy, then the screen would shift into this static
"fighting mode" where you took D&D-like 'turns' fighting
and then sat there helplessly while the monsters, in turn,
wailed on you.

Just a personal preference, though, of course.

I liked games like FTL's DungeonMaster, where the whole
game was a real-time simulation from start to finish,
with no "combat mode" to suddenly restrict your options.
(In DungeonMaster you could be fighting a horde of
monsters, backing away from them down a hallway, while
swinging axes swords and clubs at them when they
pursued too closely--as well as using range weapons
like crossbows and arrows, drinking health potions,
meanwhile preparing a fireball spell to cast at them,
and slamming iron grate doors on their heads... even
picking up rocks on the ground to hurl at them if you
were running out of ammo...)

<grin> That was my kind of game, for sure.

(Disclaimer: I ended up working at FTL... but that was
right after the first DungeonMaster was released.)

Movement is similar to any tank game. Slightly better than your
average RPG from that era. Movement is not confined to a grid of the
tiles, only constrained by Objects you can't move over.

Cool. Nice that they improved on plain tile-grid movement.

Any example of how that would go, roughly? (pseudo code is ok too)
Like I said, this is all new to me.

I installed Gosu, and found that the CptnRuby example
provided is rather a good fit for the basis for a
Zelda-like game.

The CptnRuby demo is wired as a run & jump platform style
game; however, it is solving the same map rendering and
collision detection problems a Zelda game would require.

I've hacked CptnRuby slightly to change it from run & jump
with gravity, to just free movement up/down/left/right.
(Obviously this ruins the gameplay, as you can now merely
walk and pick up every gem. The point being simply to
demonstrate north/south/east/west movement.

I've provided the source, plus the diffs so you can see
what changed between CptnRuby -> CptnNuby:

http://tastyspleen.net/~billk/ruby/gosu/CptnNuby/

(I also included fmod.dll, because I had to track that down
to get `require "gosu"` to load.)

I think if you study their CptnRuby demo (my changes are
very minor) you'll find solutions to several problems,
particularly in the areas of collision detection and
map rendering.

(They are using point-based collision detection, which
can work quite well given the right constraints.)

To get CptnNuby.rb to run, first download and unzip
Gosu; then place CptnNuby.rb in the examples/ folder
next to CptnRuby.rb. Also place fmod.dll in that folder.
Then, assuming gosu.so is in the parent directory,
cd to the examples directory and invoke: ruby -I.. CptnNuby.rb
(The -I.. is to pick up the gosu.so in the parent dir.)

Any advice on where to find 2D game algorithms/design patterns?

Sorry, I don't know. I googled for "2D game algorithms design",
though, and some seemingly promising book links turned up.

I own the first volume of the Game Programming Gems series,
(c) 2000, but the table of contents reveals it to be
dedicated to mostly pro-level topics, and mostly focused
on 3D games.

(Reading its table of contents is an interesting reminder
of how advanced and complex game programming had become,
even seven years ago, which is about when I stopped following
it closely.)

Anyway; I think there should be a lot of potential in the
CptnRuby/CptnNuby demo vis-a-vis a Zelda-like game.

Good luck; if you get stuck feel free to drop me a line.


Regards,

Bill

 

[Bill Kelly]

Sorry, I don't know. I googled for "2D game algorithms design",
though, and some seemingly promising book links turned up.

I own the first volume of the Game Programming Gems series,
(c) 2000, but the table of contents reveals it to be
dedicated to mostly pro-level topics, and mostly focused
on 3D games.

Sorry, I take that back. Its table of contents[1] is
indeed formidible; but re-reading it, Chapter 1.0
starts out like this:

"Games are made up of two things: _logic_ and _data_.
This is a powerful distinction. Separate, they are
useless, but together, they make your game come
alive."

[...] Idea #1: The Basics ...
[...] Idea #5: When Good Scripts Go Bad

[...] 1.9 : Frame-Based Memory Allocation
[...] 1.14 : Real-Time In-Game Profiling
[...] 3.0 : Designing a General Robust AI Engine

etc.


So this might an ideal book, actually.


[1] http://www.amazon.com/Game-Programming-Gems/dp/1584500492



Regards,

Bill

 

[Matthew Moss]

The Gems series are pretty good, though they are more weighted towards
those who have experience rather than those just learning.

If you're looking for 2d games (ie tile based or isometric?), you
could try some of the articles here:
http://www.gamedev.net/reference/list.asp?categoryid=44

 

[Suraj Kurapati]

Sounds like collision detection is not within the scope
of Gosu.

Have a look at the Chipmunk library (for Ruby and C):

http://wiki.slembcke.net/main/published/Chipmunk

It is the *fastest* and coolest 2D physics library I've seen in ages!

 

[John Joyce]

Have a look at the Chipmunk library (for Ruby and C):

http://wiki.slembcke.net/main/published/Chipmunk

It is the *fastest* and coolest 2D physics library I've seen in ages!

Looked at it, but it's waaay beyond me at this point!

 

[John Joyce]

For anyone using Gosu on OS X, there is a very cool little free app
called Pixen (google it and you'll find it)
It's dedicated to pixel-art, making art like for 8-bit and 16-bit
console games.
The app isn't perfect, and does do a few quirky things from time to
time, but it's pretty impressive, especially considering the thing is
totally free!
Excellent app for making graphics for Gosu or Rubygame games!