gauauu

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.

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

Glad y'all are enjoying it. For those interested in this sort of thing, I wrote an overly long blog post about the process of trying to port this game as quickly as possible.

RLE makes a lot of sense on something like a screen-by-screen game, or a title screen, but (I think?) is harder to deal with on a large scrolling level. You can decompress the level data quickly, but going the other direction (from a screen coordinate back to source data) is harder and slower. So when you want to look up collision data for a certain tile, it will probably be more complicated than a metatile approach would be.

Oh, and performance isn't the only tradeoff -- the other is in readability/maintainability. If you're skimming through your code 6 months later, trying to figure out what's going, simpler is better. My mantra: I ALWAYS optimize my code. But the first optimization priority is for readability. Only when performance or space becomes an issue do you shift and optimize for one of them instead.

Yeah, that's exactly how I felt. Really cool work, but not quite enough going on in the gameplay to make me keep playing.

NNNNNN: A port of the Gravitron from Terry Cavanagh's vvvvvv to the NES, but supporting up to 4 players simultaneously. Featuring music by Chip Jockey. Dodge the obstacles. Stay alive as long as you can. My best time during testing so far is 40 seconds. My family's average time is 3 seconds. Let me know if you see any bugs. nnnnnn.zip

My answer: I've definitely used it. When to use it is a tradeoff of how often you access something vs the space required for it. For a flag that gets used multiple times in a frame in a loop, and isn't part of a giant array of flags, I'd just waste a byte for it. It's so much faster, and what's 1 byte of out 2K? Example: In my current game Halcyon, there's a flag for whether the player is in the tank or out of it. I just waste a byte. No point in packing that for something that simple. But for something that's a big array, particularly if it's not accessed often, then bit-packing is the way to go. In Halcyon, for storing where a player has been (for the minimap), I use a bit per screen. And a bit per item picked up in the global game status. It's a little slower, but for storing that much state, it would be really wasteful to have a byte per item.

Why? (genuine question, not snarkiness)

Every time I demo games at a show, I get asked "oh, did you make this in NESmaker?"

Well, there are 6 people in family already. We just get 2 friends to come over and we're set.

This reminds me of my dream to create an 8-player version of the 4-score. (of course, then you have to figure out how to get 8 people willing to sit down and play Nintendo at the same time)

Hahah, I dunno. It didn't seem to support it in an earlier release but I played Kubo and Wumpus in it today.

NES.EMU by Robert Broglia will play them. And it has the best control scheme of any Android emus that I've tried. Well worth the money if you have any interest in playing NES on your phone.

I played through a little bit of this, managed to kill a few mules. A few questions: - Does loot do anything? - I got the powerup to "throw coins" -- are these supposed to be related to loot? - I got the next powerup about recovering coins, but I didn't understand what that meant. - Are you able to do anything about the flickery transitions between screens, or the slowdown that occurs if I throw too many coins at once? Thanks for making this a free download!

For simple stuff, it's similar. For how you build symbols, how strings get turned into symbols, etc, it has a lot of features that can end up being confusing.

ca65 macros can be really powerful, but it's one of the more confusing macro systems I've used.

I use ca65 for a few reason: The config file for the linker, while really confusing at first, is really flexible and a great way to organize your rom There's a lot of people on nesdev using it, so it's easy to get help/support There's quite a few powerful features (of which I only use a small percentage) cc65 is part of the suite of tools that come with it, and it's nice to be able to mix C and assembly fairly easily That said, in the end, I don't think that assembler choice is THAT big of a difference. I used dasm for Atari 6502 development (because most of the Atari community uses it) before switching to ca65 for NES, and they aren't all that different. My primary suggestion is just to use an assembler that's widely used in the community, so that it it's easier to get help when needed. Any of ca65, nesasm, and asm6 will be just fine.

This is true. But I've found that for a game with a lot of content, good tooling it important to keep yourself from going crazy.

Yeah, the plan is for the US release (at least) to use GTROM. Board cost and flash saves were real selling points, but the large size and extra nametables were a plus. A BNROM build is mostly for support for older emulators.

People have mentioned in that other thread that it's valuable to see what all tools were used in a game's creation. So here we go. Tools Code editing: gVim, Clion, Pycharm, IntellijIDEA Graphics editing: Frankengraphics has her own process which I'm not sure about, but definitely includes Screen Tool. I use GIMP and custom python scripts (we well as a modified pil2bmp by Tepples) Metatile editing: A custom tool that I built using java and javafx (protip: never use javafx. It was easy to write, but is ridiculously difficult to install correctly on newer systems). Metatiles are stored as json files. Map editing: A forked/modified version of Tiled (modified to make it easier to to support screens that are 7 and 1/2 metatiles tall). Maps are stored in Tiled's native json format and converted at build-time by a custom python script. Testing: Primarily Mesen. But also fceux, powerpak, and gtrom boards (flashed by either memblers' adapter or INL's board) Animated Gif recording: SimpleScreenRecorder Version control: git (hosted by bitbucket right now) Building: makefiles. cc65/ca65. Lots of python scripts. Audio editing: we're only using placeholder audio right now Misc: lots of linux built-in tools Mapper: GTROM and BNROM Libraries ggSound for audio used example code from Khan and Memblers for flash saving Resources/Assets Game engine is custom built in C and assembly. Graphics are original by Frankengraphics, or placeholders by surt or found on opengameart.com Audio is currently all placeholder audio made by GradualGames

Once again, there's a huge difference between a tool and an engine. Making it a requirement to label all engines makes some sense to me. Tools does not. The distinction isn't msWord vs notepad. A better analogy is customized SquareSpace template vs homemade website. I'm fine with whatever we decide about labels, but let's please get our analogies right.

Just wanted to chime in and say I completely agree with your categorization, Frankengraphics (hmm... It won't let me tag you from the mobile editor).

First time doing pixel art? That's amazing work.

I'm not sure if you're talking to me or Beau or who, but no, that's not the case for anyone here.