Hi,
Moonlight Requiem, is a fan game, largely inspired by the RPG Platform Castlevania episodes ( pretty much all of them since Symphony of the night )
We (our small team called 2Dee2Doo) started the project on RPG Maker VX in june 2008;.. we had great ambitions for it, and for me making a platform game in RPG Maker, was new and interesting.
But its engine is very badly written and limits ruby capabilities ( uses an embedded version of v1.8.1 when it was released last year... >_<) , can't call C-extensions... windows only, no opengl etc... ) Pretty cool and easy ( super high level ) and can do some cool stuff, but can quickly run out of ressources ( doesn't seem to use hardware acceleration ).

Anyway, after writing X version of tiled -collision engines that would try support pretty much any kind of slopes ( basically all the shapes you have in N/ N+  games ( I ported the collision from flash to ruby but not ideal for our game, and uses too much ressources) )
I'm now looking a lot at Gosu+Chingu , and chipmunk, as they seem to be pretty efficient together, and started a new version of the engine :).

Remember Queen; "I want to break Free!"

You can have a look at our website here: http://castlevania.trebor777.net to read more informations about the gameplay and see screenshots and videos :)
But that's all RM stuff.

So all the message I'll post in this topic, will be for showing screens, or asking some help from you people; Master's of Gosu !

My plan, for the moment is to familiarize myself a bit more with Gosu+Chingu possibilities, in order to get used to it. and trying to reproduce some stuff from RM. ( the way they handle animation is pretty well done for example )
Then, using chipmunk aswell.
I have a question about it :)   The window is the camera , and some level are bigger than it :) ok i put my stuff into space at some absolute coordinates that seems to be the one on screen,   is there a way to translate the space in order to move everything (emulating the camera move), ?

then :) reading the map data, to get the shape of each tile, and generate the chipmunk data from it and place it as required. shouldn't be too hard i think.

As it's moslty porting for the rest of it, it shouldn't take too long after that before seeing some awesome stuff ;)

Thanks for reading !

Hello ... wow, impressive project! I had a look at the video on your website and you have some serious graphics going there =).

I'm the author of Chingu btw, so I be here answering your questions about that.

About using Chipmunk, I would really think it through. Chipmunk is obviously very cool .. for the right project. I've started 2 game prototypes where I tried to use it for platformers and I just ended up trying to mold it something it wasn't supposed to do. Common problems examples:

- Stop the player on the spot when player releases move key .. could be solved with using surface friction instead of velocity
- Using surface friction will create some problems of it's own though, like a player running very fast uphill but slower on a horizontal plane.
- hard to polish player movement details.. either you accept how Chipmunk behaves or you try to patch it somehow, which becomes ugly.

Also, ruby isn't as supported as the C version, so there can be extra work when trying to find the latest Chipmunk features and good docs for it.
Of course it depends on what you're going to do, but from the look of your video.. I would almost recommend not using it.

Basic physics are pretty easy to implement yourself, as you probably are are very well aware of, gravity is just a downwards acceleration, jumping is acceleration upwards. On the other hand, if you want a lot of game objects falling, tumbling and interacting realistically, Chipmunk is most likely needed.

If you want to know more about Chingu and how it does stuff I would check out my github account, 'ippa' .. I got 2 active game developments at this time, 'pang' and 'ghost'.
Pang is a joint project and Ghost is for the mini LD game compo this weekend and will see the most action in the coming days. Anyhow, the point being,  both projects are pretty clean good examples on how you can structure your code / game flow with Chingu.. since it adds a layer on top of the Gosu, like game states, a basic game objects, bit different input handling, traits, timers etc.

Looking forward to see where this ends up and help you out where I'm able too.

Thanks :) a lot!

Yes I think the problem will always be with slopes, We'll see how it goes.
But yeah we intended to have some physics puzzles and destructible stuff that'd fall apart nicely :). And I think it would act nicely for Boss made of several parts to animate them ( some sort of IK or FK )

Most tutorials for simpler platformer  put constraints on the level design like you can't put a slope leading to nowhere.. or leading to a wall...because in the code they propose, it doesn't handle those cases. Or the slope must always be at 45° ... that kind of boring stuff.

In the End; the N engine  was handling all the cases nicely, except that the character would slide down 1px every two frames when on slopes due to how it detect the collision ( it wasn't a problem due to gravity, but of collision response)... I tried to patch that in so many different ways...
but failed... But N doesn't have dynamic collision response like chipmunk.

Anyway :) that would be a pretty awesome project for Gosu :) if we manage to pull it off :).

I'm not sure what the N engine is?

About collision detection / physics.. I haven't done any games built up of tiles with different sloping-angles, so I don't know about the various techniques there.

But I've done quite some of pixel perfect collision detection, which has been straightforward and working well. Maybe it's something you could consider in your project.
I've done it by just checking 1 pixel at the players feet. Logic goes something like:

- Is there a terrain-pixel bellow players feet? If not, move him downwards until it is. (falling down or walking downwards)
- Is there a terrain-pixel On players feet, move player upwards max 10 pixels until there isn't any longer. (walking upwards or climbing steep, max 10 pixel high, obstacles)

It would take just about any terrain your throw at it.

You can do this with banisters gem "texplay" which plugs nicely into Gosu. According to banister reading 1 pixel is at the speed of reading a value from an C-array.
But I think you'll need to have the whole terrain on 1 image for optimal performance though... maybe the levels can be saved as images, or constructed as images (from your smaller tiles) at runtime.

As a matter of fact :) the tiles are only used for collision and are invisible ingame.
We use several parallax backgrounds for the level. and one of them is the "level" where the player is.
We could have the possibility to generate masks from the tiles as well... :) and use them for collision detection. (instead of reading the background, as there could be parts we don't want to collide with)  (Edit... i just noticed what you've written at the end)

What I call the N engine, is the mechanics behind the game  "N" ( a flash game , ported to several consoles as "N+", if you haven't played it , I suggest you do, very simple design, but addictive. It's free on PC), They put  a tutorial explaining with the source code on how works the collision detection in game.

Bear in mind the player will not be alone moving around, and several enemies will move as well... hopefully we're using a quite small resolution ( 480*272 ).

But I guess you check another pixel to see if you can go left or right? ( as colliding with a wall?) Also the player is quite tall (about 48px), and i fear that some part of the body would pass through stuff... instead of blocking... so that would make several pixels to check, isn't it?

You may consider bounding box collision. I implemented it in Dimensions because originally I was using the collision detection in the Captain Ruby Gosu example game, which essentially plotted four pixels on the character for collision. This was ineffective as it allowed my own character to get impaled on ledges by blind spots. Instead of filling in these blind spots with more pixels, I looked at http://www.gamedev.net/reference/articles/article735.asp.

You only need four numbers to define a rectangle - two x's and two y's. From the values of two rectangles comes only four check statements to tell whether the position of one box intersects with another box/pixel. This turned out to be a very efficient way for handling collisions in my game.

From what it sounds like, this won't be applicable to collision with your map, but your player and other entities can use this method to check their boxes against the map's pixels rather than 50+ of their pixels against 50+ of the map's pixels. Much fewer pixels to check. Does this help any?

Well, I've already look up BB ages ago :) one of the 1st thing tested. I've implented it with circle collision as well, as (BB vs BB , C vs C and C vs BB ) for check between enemies and player, or player vs projectile, or projectile vs enemy.

Basically that's how a map look, this is a map that i use to test the engine, as it has pretty much every case one it. If you have an idea that'd work perfectly for all of those case :) ( the character is a tile and a half high (48px), actually it should work for any kind of character size. )
I'll love you forever...

But for me chipmunk seems to be the best solution.



:) For the nostalgic here's the debug room ion Symphony of the night.

I admit that I cannot offer any ingenious collision engine substantially better than what Chipmunk has to offer. I just supposed that, from what I understood about your game, BB collision would be a useful little trick to implement as opposed to pixel iterations. I am an advocate of neat little tricks like these that provide very practical framework in few lines of code. As brilliant as chipmunk may be, I personally prefer to "learn" and "own" my code rather than plug in a "do it all for me" library. I feel just as reluctant to resort to chipmunk as I would hiring some technician to fix my computer because I'm too unlearned to do it myself.

Because Chipmunk is open source, it's not so much of a big deal. It saves a lot of time for someone who has higher priorities than setting up an original collision framework. I'll probably wind up using it sometime in the future, but not until I have some kind of idea how it works.

Ah, N.. that ninja running around, played it, didn't know they also made a collision detection tutorial though, sounds interesting.

About 1-pixel collision detection. I did it like this in my game prototype:

#####
#####
#####
#####
##o##  <-- full sprite, "o" marks the pixelcheck. basically at the sprites feet.

I didn't have any special check for left and right and it works out better then expected.. sure they player will go halfway into the wall before the stops but IMHO it doesn't matter, it doesn't look unatural. It will nicely follow upwards and downwards slopes.

Now, with that said, checking more pixel then 1 at the players feet is probably needed for a full game. The above sprite would happy jump through the roof (until the feet hits the roof).
It would also walk right through pointy objects that hits the player in the head or tummy but not the feet.
If you want to keep ultrasimple with 1 pixel check, don't make pointy horizontally terrain.

But as you suggest, you might as well check 4 pixels, something like:

##o##
#####
o###o
#####
##o##

This would stop the sprites head from going through the roof. The problem with 4 (or more) pixels is that if terrain has something very pointy that you jump into .. the player can get "stuck", since (when jumping forward) the rightmost pixel could hit something solid from above.. while the bottom pixel is in the air.

Now you might have written off pixel collision days ago.. but just wanted to share my experience with it.

Btw, kind of interested in your CC <-> BB collision detection code.. I would love to bundle that in Chingu :) (Now I have somewhat basic BB <-> BB and BC <-> BC)

One of the 1st problem I had with N, is that it only supported character as high as a tile. So in order to fix that I created a proxy shape, that contains several shapes (made of circles and/or BBs ) that would be smaller than a tile :) It was allowing me to have a precise mask. Furthermore after I created a small editor were you would define those shapes for each frame of animation, but that's another story.
Here is the code!

In the code, xw and yw  in the AABB method, refers to the half-witdh/height of the box, not the full dimensions.

http://pastebin.com/f417bfa9b

Ippa:

Yeah, that was exactly the Captain Ruby collision that my game used to have before I switched to bounding box.

> This would stop the sprites head from going through the roof. The problem with 4 (or more) pixels is that if terrain
> has something very pointy that you jump into .. the player can get "stuck", since (when jumping forward) the
> rightmost pixel could hit something solid from above.. while the bottom pixel is in the air.

I knew that pixel collision was circling the drain when my dude got impaled by a platform.

The combination of CC and BB to create a collision mask for an entity sounds like a good idea.

pixel based collisions are not the best solution in most cases but sometimes they are appropriate. In selene (http://www.youtube.com/watch?v=iS7NvYaCdRY) i use them to detect meteor collisions with the terrain.
Also worms-style and lemmings-style games are implemented using pixel-perfect collisions (http://www.youtube.com/watch?v=FngoadE1nEc).

However i would not use just pixel-based collisions for a generic platform engine. Nonetheless a combination of pixel and bounding box collisions is often a good compromise - you use the bounding box intersection to determine whether two objects are in proximity (broad phase collision detection) and then within the region of intersection you do a pixel-based check to see whether the objects really did collide (narrow phase collision detection)

More info here: http://www.gamedev.net/reference/articles/article754.asp

From a short glance, this algorithm covers how to do pixel-perfect collision, not why. WHY? Is there any big game out there that actually uses pixel-perfect collision? (I really don't know :)) From my gut feeling, bounding boxes 1-2 pixels smaller than the actual objects work better in almost every case. I never understood the obsession with that topic :)

Just my 2 NT$ because I hate seeing man-years of development time being invested in this all the time. Of course, checking against the landscape can be pixel-perfect, and should be for some kinds of games :) But that's only one side.

FWIW, is there a discussion in the articles on whether to use a for-loop for every pixel of movement? I think doing it as a for loop over the tiles is actually often better, but that only works if the tiles have favorable shapes ;)

Hey, sorry for this topic revival :) but the project is back on its track again!
So expect to see some updates soon ( probably during next week).

I've today managed to get a nice fullscreen stretch mode thanks to those new transformation features. :3

Anyway, I'm running more tests than actually coding features, as it's been ages since I've coded something ( was last november/december I think ).
I've been very busy with my studies in games art... ( yey 3D ) >_< But finally got free time to work on castlevania. Woot.

I was also wondering if anyone would be interested in working with me :) though I'm not expecting anyone as it's not a big call for help.
it's more for having feedback, and making progress more quicker on the project.