Block Dude port

I'm wrapping up a couple other projects, but wanted to get one step closer to writing a complete game. I've built a "game" that was more of a tool in assembly (MashyMashy) and recently have been rewriting it in C because I have actual experience in C so I'm finding it SOOO much easier. ANYWAY, I thought the best next step would be to write a clone of an existing game to get some experience with all the game aspects without having to have the extra hurdle of game and UI design... SOOOOOOOO

I'm going to rewrite Blockdude (the old TI-83 calculator game) for the NES. Wanted to know if anyone had any thoughts on this... if there's something particularly challenging or if I should worry about TI coming after me or if its just a solid way to get closer to building my own game?

For now I don't really want to talk about anything but a straight clone. I think there are some great wrinkles that I could add, but don't want to get distracted. What I really like about this choice is that the harder parts to emulate for most games (like physics and graphics) are SUPER simple in this game. It also has a couple of decent challenges like a limited window size (yes I'm hoping to limit the window to what you'd see on the calculator) or some light handling of more than 8 blocks on one line. I'm also hoping to stream some of the development assuming I can move at a great enough pace that I can still keep it interesting.

Anyway, wanted to share in case anyone had some helpful advice/lessons they've already learned... or if someone had already done this or tried this... Worst case by posting this I have one less reason to keep putting it off and never getting to it

Texas Instruments didn't make any of the games for its calculators, and the Block Dude concept has been around in some form since the mushroom block puzzles in Super Mario Bros. 2: Mario Madness.

Blocks per scanline shouldn't be a problem if you draw them as background instead of sprites. You can do the window limiting (12 cells by 8 cells) by doubling the sizes of all graphics (from 96x64 to 192x128) and putting sprites at the left and right sides of the scrolling playfield.

Yeah I think there'll be a handful of ways to handle both issues. As for the scaling factor, I'll probably draw it at 1x and see how it looks/feels, mainly cos I think it'll simplify a lot... but either way, a big part of why I'm picking this project is cos decisions like this are pretty limited, which makes it far more likely to be completed.

I don't think I have any great suggestions, but that sounds like a fun project! I've got some fond memories of that one.

I think a number of the mechanics of the game will make it a good first "real" game/early project/whatever. The movement and scrolling were both very simple and on a grid, so you don't need to worry much about complex movement, acceleration, etc... I'd guess you probably won't have to work hard to get the color scheme you want either. The sprites/graphics generally also fit on a grid, which is good. All good stuff, really.

Good luck, and I hope you have fun making it!

This is actually going way faster than expected. There only real challenge I have left is limiting the screen size. Don't think that one feature would block releasing a prototype demothough so if I can do some general cleanup and close out menuing... I'd be surprised if I didn't have something worth showing around by end of month.

So I've been crazy busy, but finally have something worth posting. I have a version I think is ready for beta. It doesn't narrow the screen size like the normal game cos it'd be harder and a worse experience for the player anyway. I also decided not to add sound/color (at least for now) because the original didn't have them. I had originally considered adding new features/levels/graphics, but bc I don't own the idea, I'm now leaning towards wrapping up a complete port and move on to my own game.

ANYWAY, if anyone is interested in beta testing it or checking out what I ahve so far, I've attached a rom and the code can be found here: https://github.com/mitch3b/BlockDude . I only ask that you don't stream it or anything like that for now anyway.

Only two known issues so far are:
1. The "physics" aren't completely the same. While I did some basic eyeball testing of how quickly he moves, etc... I didn't get them as close as possible yet.
2. There's a 1 frame glitch whenever a new screen is loaded. I'm pretty sure I know the cause, but instead of doing something quick/hacky, I'd like to take some time to reorganize how the code executes which will take some time so I didn't want to hold up a beta test.

Let me know what you think! Especially looking for any bugs and if there are any features/settings/etc that you think should probably block launching this/calling it done. Thanks!

I never played the original so I cannot comment about how faithful it is but once you understand the mechanics it is simple but fun.

The only thing that may be a bug is when you press the button to take a box, sometime it will do a back and worth of taking, putting back, taking, putting back which is a little bit annoying. I checked your code and you are not using neslib (at first I thought you did since you made it in C). If you have issue with joystick you could check the neslib library. The method has a trigger mode that allows to know if button was pressed and won't read any future input until released. I'm using this code in my own project and it's quite useful.

What could be interesting is to later make a "nes" mode where color and sound would be added. This way you could play in original mode and nes mode.

Good work

Wow, thanks for the quick feedback!

I'm not using neslib. Haven't really looked into it, but still trying to get a true handle on how the hardware works so trying to avoid it (I already feel like I'm cheating using C instead of asm, but I did my first project in asm and it def made it too tough to do a full game for me). The box logic SHOULD work as you described and I've never seen it do the immediate back, but I also have only tested on emulator and even worse, that emulator is being run on wine on a mac so I'll give it a try using a flash cart later tonight.

I went back and forth on NES mode. I was worried music would take too long and probably come out pretty bad, but you're right. Probably anything is better than nothing. As for color/graphics, I was planning on playing around with it a little. Not sure how much a difference it'll make cos the character is so small and there doesn't seem like much opportunity considering its just blocks and bricks, but its easy enough to try a couple things.

I don't see writing code in C cheating as long the game in the end works I was writing in asm only 9 years ago and I stopped because of lack of time. Using C now allow me to write some logic and debugging it faster. What still need to be written in asm is anything that is time sensitive like writing OAM buffer, decoding metatile etc. It's reminds me of my dos days.

As for using neslib, I did test it when I restarted coding recently and it helped me learn how to interface code between asm and C so it was quite useful. Now I don't use it anymore but the pad function was quite useful and felt it was not worth rewriting when it's working well so I'm using it as-is.

I did the test on windows with nestopia. Now I just did a quick test under mac with wine+nintendulator and the behavior doesn't seems to occur but I see in that case a box in the top/left corner compared to nestopia that is shown/not shown. I'm not sure if it is supposed to be an indicator or a bug. Now I did a few very quick test with fceux and nestopia on mac and the behavior doesn't occur. I will try to test it later on windows again.

As for "nes" style, if I would remake it, I would not keep it that size: I would make it bigger so the sprite would look better. That would change the game a little bit and would require more time to make since the game would need to scroll but it would be better I think. But that would require more time to make so it's not like you have to do it. It could be an interesting project though

Edit:

After more testing, it was my bad. I always set the key the same way for all emulators and I found that only nestopia on windows had this behavior. Since it was unusual I checked my setting and the key was set to auto-fire, thus that strange behavior. So you can forget about that bug, it wasn't one in the first place. The cube at the top left corner, I'm still not sure what it is.

Oh wow, thanks for the extra digging on what looked like a bug.

Haha, I obviously have the same sort of thinking about with C. Maybe I will take a closer look at neslib, but I do want to try to rewrite my game framework first to get a solid handle of how code should execute, especially around vblank and how/when to access PPU registers.

Thats an interesting point about the bigger version. Originally I did consider making it that size from the start, but opted not to bc I was hoping to make all blocks sprites and play with handling more than 8 sprites per line, but when I got in the thick of it, it became obvious that writing them to the background was the way to go. And at this point, I'm more looking to wrap it up and as you said with screen scrolling, it'd prolly take a decent amount of effort to change the size... plus I do think with the smaller everything it does reflect how it felt on the calculator. But if I did, then it totally would mean I could dramatically improve the graphics, which I do think would be cool.

Fixed the scroll glitch (thanks to twitch.tv/Link_7777). Had a reset scroll method that was temp changing it back. Might post more about it in a different thread, either way, latest version is pretty close to "done". just need to verify the physics are as close to the calculator as possible.

If you plan to use more C code in the future and making more complicated project, learning how to interface time sensitive code written in asm in C is important. By looking how neslib work, it helped me to search for the right information to make my own code. So you don't need to use it, just need to review it since it can give you idea how to make your own library too.

After checking it, I was able to interface code I made 8 years ago and now manage the player logic in C instead of asm but the rest which was time sensitive like metatile parsing and buffering is still in asm and working well. Now from C I never touch the hardware directly and intend not to.

I tested the second rom and I still see at the top/left either a line (nestopia) or a block (other emulator). Could it be some sprite that is left dangling? That is the only thing I can think of.

What I think Banshaku is referring to:
The Y coordinate of unused sprites needs to be $F0-$FF, not $00. Setting it to $00 will make the sprite visible at the top left corner, even though some 60 Hz TVs might be cutting it off.

@tepples

I didn't say it explicitly but I think too this was one possibility. Unless I check the code I cannot know for sure but it would be a good starting point for this issue. Since sometime it shows a line only (half shown sprite?) or the complete block.

Thanks for calling this out. Was something that I meant to fix but never got back to. Found a couple other small things so I'll probably fix them all and cut a new version. I also started playing around with adding music. Was hoping to wrap this up this week cos I'm on vaca next week, but realistically I probably won't have enough time, so I'm guessing mid-August is more likely. But I guess that gives me more time to think about what I want to do for the first original game

Fixed the top left visible sprite and the game complete screen which had an extra character. I think thats all known bugs. Just need to add the "NES" mode with updated music/gfx. Will take me a while cos have a lot of adult distractions coming up, but will release officially once I have that piece done. If anyone else ends up testing, please let me know if/what bugs you find Thanks!

mitch3a, how do you feel about me completely redoing my website (since you appear to use it)?

Sorry for the unsolicited comment but you could always keep the old version of the site up alongside the new one for archival purposes and for readers that want to refer to the old posts.

I made pdf copies of all the pages...for archival purposes.

https://nesdoug.com/2018/07/11/backup-pdf-archive/

That bug is now gone. I didn't finish the game but in general it is working fine. I think my current computer setting for the key is too fast so because of that I tend to make mistakes but until I figure out the current level I'm stuck it, I cannot test all of it.

I never was into puzzle so usually they don't keep my interest long (I always was into action games) but I gave it a try. If I finish it and find anything, I will let you know.

Good work!

Yeah in terms of puzzle games, I think this one has fond memories mostly because it was on your calculator so you could play it in class at school, but in terms of gameplay its just OK. Not many levels, and they always seem way too easy or impossible. Originally I was going to build on it to give better levels and more mechanics but since I didn't invent the original and couldn't get ahold of the creator, I figured it wasn't worth it.

dougeff, I think what you have is GREAT. I'm guessing it could always be better, but its got all the building blocks you need and there are little things like the comments, etc that you might lose if you just convert it to pdf. Plus I really like how it feels like you're building your first game and closer to someone learning than a full on expert, which makes it easier to follow as a beginner. Is there something specific about it that makes you want to rewrite it? Obviously I've hit a couple pitfalls but that's an important part of learning. Heck, that's why I did my first "game" in assembly cos I didn't want to skip important knowledge... cos I'd much rather struggle with VBLANK and the PPU at the start of my easy project then get 10k lines into a complex game only to have a weird glitch happen and no underlying knowledge/experience to figure it out.

Finally an update (summers are busy ). I was able to add music and fx. Played with graphics and it didn't add much bc with single sprite blocks, some of the colors were a little messy... plus bc I'm writing the blocks to the background, I would've had to potentially even update code... and at the end of the day, it didn't look like the original so I scrapped the idea.

Basically have a few cleanup things (like volume leveling and testing on a flash cart). If all goes well, hoping to have a release very soon, possibly in the next couple days. Hoping I can convince at least one of you to do a full playthrough and give me any feedback, bugs, etc. I have 2 other folks who are going to do the same, but I think having a dev's perspective could find callouts that a normal player might not notice.

Here is what i think is ready for release. Let me know if you see anything:

I could try to test it bug I never made it to the end (I never was into puzzle, that's my weak point in games ^^;;) so I do not know how much feedback I could give this time. I may be able to test it a little bit tonight.

Officially released this. http://www.romhacking.net/homebrew/104/

Thanks everyone for the help! Hopefully this means I can focus on a submission for the 2018 Nesdev competition!

Congrats!

Kinda reminds me of playing old handheld LCD games.

yeah. As much as I hate the controls, it does feel like the original so I left it as is. The good news is with that out of the way, I (and another dev) should have plenty of time to get a submission going for this years competition.

Does anyone actually know the original BlockDude dev (Brandon Sterner)? I pinged his old/inactive reddit account and at one point found someone who said they might be able to find him, but nothing panned out... I'd like to include this port in the NesDev competition, but knowing that there is unlikely but potential money involved (and the consent to put it on the multi-cart), I'd only really feel comfortable submitting with his blessing.

Game has 1/3 of the Super Mario Bros graphics in the CHR. We might want to remove those.

Crap. Thank you for this. I had started with a chr file i had laying around and while I didn't use anything from the existing file, if there is any data hanging around, i should DEFINITELY remove it. I'll do it tonight and drop a line to NesHomebrew.

Here it is without the mario data in the chr. Thanks again Doug for pointing this out.

You probably also want to remove previous version of ROM from the forum posts as well... =(

Done and done. I guess I should clean up the git repo but might be a pain and doubt anyone will be poking around there. Oh well. Lesson learned.