boo (homebrew)

[chromableedstudios 24]

Howdy. This is my Nintendoage origin story-ha

Many year ago I stumbled across super Mario brothers clouds ( https://www.google.com/url?q=http://www.coryarcangel.com/things-i-made/2002-001-super-mario-clouds&sa=U&ved=2ahUKEwjH94rDqK_mAhWDG80KHY8cAEoQFjAQegQICBAB&usg=AOvVaw2KKqvKtd5gC54eU9vND99U )

And after seeing that decided I should make an Nes game (as it has been my favorite game console for most of my life), which led me to nesdev and nerdy nights... And the wealth of Homebrew and information and code shared by folks like shiru, tepples, memblers, Dougef, gg, bunnyboy and countless others has been inspiring and empowering to try and reach that goal.

I'm not sure if this is the beginning or the end of this project, but here goes: a ghost named boo. Thanks!

 

Change log:

12/16/19-Flintstone scroll

Alt link https://drive.google.com/file/d/1V4ZAPAp_lMnSVL4n0MW2uRYRtxs6fVdX/view?usp=drivesdk:

 

booFlintstoneScroll.nes

Edited December 16, 2019 by chromableedstudios

[gauauu 79]

Cool, congrats on finishing a game! Getting your first project out the door is a great feeling.

[chromableedstudios 24]

Thanks!! Somewhere near the middle I wasn't sure if I'd ever ship something for NES. I recently restarted in c though--between that and a few more years of dev under my belt and I've had a bit more luck this go at it.

 

I'm a bit of a noob at game dev generally, and even more so NES, but it has been fun learning and trying. I still need to learn quite a few things to get it to where it would feel like more than a demo, but I was pretty excited just to get a game loop, music, bounding box etc working.

 

Edited December 13, 2019 by chromableedstudios

[gauauu 79]

Yeah, I'm glad you stuck with it! And if you'd like suggestions or specific feedback, I'd be happy to throw out some ideas (and help answer questions about potential solutions). I didn't want to dive into of those yet because it can be really frustrating to show your first demo and get a lot of unwanted semi-constructive feedback.

[chromableedstudios 24]

Sure! My ego is as fragile as the next so I appreciate you asking, if you are willing to share i'd love some feedback though. 

 

I wouldn't say this is my dream NES game yet, I just, you know, if I got hit by a bus tomorrow I didn't want to go out without having accomplished this life goal. That said, this branch of dev is only a few weeks old so hopefully I am not to precious with it.

 

If I find time to continue my first thoughts were:

-Throw out the general level scheme and try to understand how to go from a larger than single screen NES screen tool nam file to a proper vertical scrolling level(I've read through the whole meta tile bg thing but haven't had time to digest or test at all, something will click im hoping)

- increase enemy variety and fix movement (need to figure how to get more sine wavy? Trigger spawn from map?)

-figure out how to write the attributes properly? Ok this sounds really dumb, but I just took a 'game jam' kind of approach and glossed over anything that put up resistance to get to min viable product (I guess it's just nv ram like any other? Confused why nesst doesn't include the attributes in their generated c? Or maybe I'm using it wrong)

-rate limiting the player fire a bit so the stars don't always overlap

-I think there might be a bug where I forgot to clear the enemy bullet active flag between rounds

-create own sfx, using shiru example ones now (thanks/sorry?)

 

Whatchu got?

[gauauu 79]

9 hours ago, chromableedstudios said:

-rate limiting the player fire a bit so the stars don't always overlap

That was one of my main things. If it fits your game design goal, you could compare the currently pressed buttons with last frame's buttons, and only shoot one bullet for every NEW press instead of any time the button is held. That would feel more like a lot of older shooting games where one press = one shot.  (unless you'd rather let the player hold the button, which is perfectly acceptable, in which case yeah, rate limiting would improve the game a good bit).

The other thing is the enemy movement, the way they jerk back to the top as they move. You could have a direction flag for the enemy, and have them move more smoothly upward then back downward, which would feel a lot nicer I think.

 

9 hours ago, chromableedstudios said:

-figure out how to write the attributes properly? Ok this sounds really dumb, but I just took a 'game jam' kind of approach and glossed over anything that put up resistance to get to min viable product (I guess it's just nv ram like any other? Confused why nesst doesn't include the attributes in their generated c? Or maybe I'm using it wrong)

Yeah, attributes can be a pain.  I don't know how screen tool's C export works really, but I find it easier to include the nametable file directly into my binary instead of as C code, which then does include the attributes. The way I do it is to have an assembly file which just declares a symbol name, and incbin's the nametable, but there are other methods:

.export _nametable
_nametable:
.incbin "../gfx/nametables/playfield.nam"

If you assemble that with ca65 and link it with everything else, then you'll have a C symbol named nametable that you can access from your other C code:

extern unsigned char nametable[];

//do whatever with nametable array

 

That said, everyone's workflow is different, so you might have a different preference of how to work with these.

[erac 69]

^ that should be const, you're not going to write to it in ROM.

[gauauu 79]

33 minutes ago, erac said:

^ that should be const, you're not going to write to it in ROM.

This is true.

[chromableedstudios 24]

Thanks!! I appreciate the feedback and the examples.

[TylerBarnes 183]

Congrats on the project!