nesdev.com

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