[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

rubygame

John Joyce

8/30/2007 10:42:00 PM

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.
20 Answers

Jeremy Woertink

8/31/2007 12:10:00 AM

0


> 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.shattere...


check it out.


~Jeremy

--
Posted via http://www.ruby-....

James Britt

8/31/2007 12:57:00 AM

0

John Joyce wrote:
> 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/idea...

--
James Britt

"MVC applies to the Web about as well as RPC does."
- Bill de hOra

Bill Kelly

8/31/2007 1:07:00 AM

0

From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>
> 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

Terry Poulin

8/31/2007 1:17:00 AM

0

Jeremy Woertink wrote:
>
>> 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.shattere...
>
>
> check it out.
>
>
> ~Jeremy
>
> --
> Posted via http://www.ruby-....
>
>

To compare Python and Ruby would be like comparing C++ and Java respectively
(IMHO). Python is a good language for many things but I've always found the
documentation rather dull but rather good if you can follow it.


Ruby for ever... :-)


--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ip...

John Joyce

8/31/2007 3:28:00 AM

0


On Aug 30, 2007, at 8:16 PM, Terry Poulin wrote:

> Jeremy Woertink wrote:
>>
>>> 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.shattere...
>>
>>
>> check it out.
>>
>>
>> ~Jeremy
>>
>> --
>> Posted via http://www.ruby-....
>>
>>
>
> To compare Python and Ruby would be like comparing C++ and Java
> respectively
> (IMHO). Python is a good language for many things but I've always
> found the
> documentation rather dull but rather good if you can follow it.
>
Who's comparing? I like Ruby a lot. I don't know Python yet.
I do know Python does have a lot of well developed libraries that are
well documented. Much like Perl. (it shows when people basically
create Ruby versions of the Perl or Python library)

That's not bad. It's just that I want to do something, and the Ruby
tools aren't there yet. But I don't want to write the tools. I'm not
a super C person, so I'm not going there.

John Joyce

8/31/2007 3:29:00 AM

0


On Aug 30, 2007, at 8:06 PM, Bill Kelly wrote:

> From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>>
>> 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?

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

Bill Kelly

8/31/2007 4:40:00 AM

0


From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>
> On Aug 30, 2007, at 8:06 PM, Bill Kelly wrote:
>
>> 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.

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...


Regards,

Bill

John Joyce

8/31/2007 5:06:00 AM

0


On Aug 30, 2007, at 11:40 PM, Bill Kelly wrote:

>
> From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>> On Aug 30, 2007, at 8:06 PM, Bill Kelly wrote:
>>> 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.
>
> 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...
>
>
> 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

8/31/2007 5:55:00 AM

0


From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>
> On Aug 30, 2007, at 11:40 PM, Bill Kelly wrote:
>>
>> 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/Desig...

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. :D


Regards,

Bill

John Joyce

8/31/2007 6:49:00 AM

0


On Aug 31, 2007, at 12:54 AM, Bill Kelly wrote:

>
> From: "John Joyce" <dangerwillrobinsondanger@gmail.com>
>> On Aug 30, 2007, at 11:40 PM, Bill Kelly wrote:
>>>
>>> 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/Desig...
>
> 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. :D
>
>
> 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.