Homebrew Fireworlds - A DS platformer/puzzle game. (DS Entry)

[Dirbaio]

Now the proper beta2 is uploaded.
I had accidentally included in the zip the .nds from beta1...

 

[Sir_Voe]

The new beta is quite an improvement. The text helps to explain the gameplay nicely, and the "black hole" setting takes the narrative a bit beyond abstract while still allowing for abstract concepts. The ice effect is great too, bobbing in the water emitting snowflake particles. Great job!

 

[Rydian]

In the section part of stage 1, you can get sort of stuck in a floor corner. I've made a little ASCII art diagram with the X marking the spot.

----\
ÂÂÂÂÂÂ\
ÂÂÂÂÂÂÂÂ\x____

Once you're stuck there you can't go to the right, but you can go left and jump.

EDIT: Also I had it crash when coming out of sleep mode, but can't replicate it.

 

[Danny600kill]

Look interesting, might take a look in further development

 

[Shiro09]

Downloading now. Can't wait to try it later

 

[Dirbaio]

In the section part of stage 1, you can get sort of stuck in a floor corner. I've made a little ASCII art diagram with the X marking the spot.

----\
ÂÂÂÂÂÂ\
ÂÂÂÂÂÂÂÂ\x____

Once you're stuck there you can't go to the right, but you can go left and jump.
I know about that. It's the MOST annoying bug I have, and it's really hard to fix... Mostly because the code that handles collisions with the level is reaaally messy.

QUOTE(Rydian @ May 30 2011, 01:10 AM) EDIT: Also I had it crash when coming out of sleep mode, but can't replicate it.

I have that too sometimes. I thought it was because my flashcart since I have ROM's hanging randomly too.
But I see it's not the case

Next version I'll simply disable the sleep mode.
Just one question: did it crash with the red screen of death or just freeze?

 

[boktor666]

this looks very nice, no, amazing. This is truly a awesome homebrew game.. I wish I could vote :/

 

[Aguilera_87]

awesome, really nice work

 

[Evo.lve]

From just the trailer this looks amazing. If I get a vote, which hopefully I do, this will definitely be one of my top picks.

 

[Boriar]

The new version is awesome. Fantastic the training levels doing the game much less confusing

About the sleep mode, i haven't got any problem with that in menu, in game or in select menu. I'm using a DSOne SDHC.
What about let the fireball run on the roof some time while A and D-pad buttons are pushed?

Edit: About sleep mode. Work well on SDOneSDHC+8Gb and DSTwo+1Gb+EOS1.11+FW1.09 both in DSL

 

[Dirbaio]

Thanks for testing

The problem with the sleep mode bug is that it happens veery rarely. So maybe you were just lucky...

 

[Rydian]

I know about that. It's the MOST annoying bug I have, and it's really hard to fix... Mostly because the code that handles collisions with the level is reaaally messy.Yeah I noticed the way you handled level layout and collision and jumping based off of surface normals and it seemed odd to me to do that, but then when I hit the gravity-rotating stage I realized it probably made that a lot easier (and I wouldn't know how to do that otherwise), and it probably allows other tricks I haven't gotten to yet.

Question, is the collision system based on the same models that are seen in the game? I noticed they're patched together a bit to try to form a single-looking mesh. It's a little hard to tell if the character's collision with them is based on them or if they're just the display and it clips through them a bit to the actual boundaries, because the character doesn't have pixel-visible collision areas, what with all the particles it's emitting.

Would you consider making the collision meshes and visible meshes separate? Then you could have proper overlap of the visual meshes to stitch up the current gaps, while possibly reducing some of the physics engine's work as the meshes involved with physics could number less as they wouldn't be rendered so their placement would purely be for physics.

Though I suppose with all the particles the DS is pushed to it's limit so Idunno' if you could technically afford to pretty up the visual meshes in that case (make them look more psychedelic or something), my main concern is the physics system, it certainly caught my interest.

Speaking of physics, if you let the game sit for a minute you'll notice that the character tends to slide a bit. Perhaps you could tweak friction so movement is 0 past a certain threshold? This honestly made the stacking tutorial level annoying, as the stack would slowly slide to the left as I was trying to assemble it.

QUOTE(Dirbaio @ May 30 2011, 04:19 AM) I have that too sometimes. I thought it was because my flashcart since I have ROM's hanging randomly too.
But I see it's not the case

Next version I'll simply disable the sleep mode.
Just one question: did it crash with the red screen of death or just freeze?

Red screen, the guru. I put it in sleep mode a few times and waited to see if it would happen again (even on the same level, which was the multi-stack tutorial one), but it didn't. Using a DSTwo for it.

 

[Dirbaio]

Well, collisions in Fireworlds are simpler than what they seem.

Levels are not meshes, they are simply a set of quads. The fireballs are treated as points, not circles.
When a fireball moves into a quad, I look at the closest side of the quad, and move the fireball to it, calculate the normals, and so on. Then I had a problem: it was possible to go "in between" two quads that were next to each other.

Then came the first hacky solution: All the quad sides have a "valid" flag. If a side is right next to a side of another quad, it's "invalid". (it's precalculated when saving in the level editor, heh) Then I look for the closest "valid" side and send the fireball to that side. That way the fireball doesn't go "between" two quads. It worked perfectly with two quads next to each other but not for corners.

The problem with corners is that when you hit a quad that is inside a corner, both closest sides are "invalid". At first I was sent to the OTHER (valid) side of the quad

Then I made another hacky solution to avoid that, looking for the two closest sides and checking if both are invalid.

This is a design problem: I have no way to know the "good" normal vector in that situation. I need to store some extra info with it. I'll think about it

On the subject of the DS limits, oddly enough, the CPU is not at its maximum. It's the 3D engine. It can only render a fixed maximum of polygons per scanline. If I put some more particles, random weird horizontal strips start to appear when lots of particles concentrate in the same scanlines. The CPU is usually at 30%, up to 50% maybe (press R to see the debug screen

) so I can afford doing more physics calculations, fortunately

Last, yeah, I'll fix the tiny friction. Also, if you get again the guru error, can you take a pic of it please? It's not a serious issue but I'm curious to see what's causing it. It's probably because I'm using lots of real-time stuff (a timer IRQ for the note sync with MIDI, and also ASLib has its timers both on arm9 and arm7...)

 

[Rydian]

I was thinking more along the lines of textures for the world to give it a little more life, would that be possible? I know crap about the DS's GPU, all I've done is text-based stuff for it.

If I get the error again I'll try to get a pic.

 

[relminator]

Well, collisions in Fireworlds are simpler than what they seem.

Levels are not meshes, they are simply a set of quads. The fireballs are treated as points, not circles.
When a fireball moves into a quad, I look at the closest side of the quad, and move the fireball to it, calculate the normals, and so on. Then I had a problem: it was possible to go "in between" two quads that were next to each other.

Then came the first hacky solution: All the quad sides have a "valid" flag. If a side is right next to a side of another quad, it's "invalid". (it's precalculated when saving in the level editor, heh) Then I look for the closest "valid" side and send the fireball to that side. That way the fireball doesn't go "between" two quads. It worked perfectly with two quads next to each other but not for corners.

The problem with corners is that when you hit a quad that is inside a corner, both closest sides are "invalid". At first I was sent to the OTHER (valid) side of the quad

Then I made another hacky solution to avoid that, looking for the two closest sides and checking if both are invalid.

This is a design problem: I have no way to know the "good" normal vector in that situation. I need to store some extra info with it. I'll think about it

Have you considered using SAT?

Just a vector projection of a line:

Tute:
http://imortisoft.no-ip.org/b2b/?Issue_%23...ision_using_SAT

DS binary (I haven't updated this yet as I was gonna use it for simple collision w/o response)
http://rel.phatcode.net/junk.php?id=109

Or just a simple closest point on line to calculate the bounce vector:
Tute:
http://petesqbsite.com/sections/express/is...dex.html#bounce


BTW, nice looking game you got there. ;*) Good Luck with the compo.

 

[Boriar]

Hey!! Guru meditation error!
See that:
http://www.mediafire.com/?4q8oj2yc0qb2nwd

It was at the boot of game. The first time i got it

 

[Ikki]

Downloaded.

I'll check it out later, looks fun.

 

[Rydian]

It was at the boot of game. The first time i got it

The NDS needs to be in the root.

 

[Boriar]

It was at the boot of game. The first time i got it

The NDS needs to be in the root.

Sorry! I had it in the root but at copy some other homebrews to the mSD i forgot that condition and moved it to my games folder.
Thanks Rydian

, was my fault.

 

[BigLord]

I also have a guru meditation error, but I'm positively sure that the .nds file is in the root.

I'm using regular DSTT with retrogamefan's latest firmware (6.59).