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