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.

On 12/9/2019 at 3:07 PM, TylerBarnes said:

I see, that definitely makes a lot of sense. When the space saving starts to impede on performance of a commonly checked bit, it starts become more of a con than a pro. 

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.

18 hours ago, KHAN Games said:

Yeah, it's super impressive but not something I'd find myself playing without some sort of computer opponent. The music is awesome too. Would love to have something added during gameplay.

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.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.

1 hour ago, arch_8ngel said:

That is distinctly less problematic than people assuming the game is a hack IMO.

Why? (genuine question, not snarkiness)

 

3 hours ago, arch_8ngel said:

This actually makes me sad that there are people out there assuming that some of the best known homebrews are hacks of existing games.

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

16 hours ago, Mugi said:

you make a 8-score and then what? good luck finding 8 people to test it with lol.

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.

5 hours ago, dougeff said:

Do you know any app that can play NESmaker games on an android device?

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!

5 hours ago, FrankenGraphics said:

But, is there a significant difference in how it handles macros at the level  asm6 or nesasm3 is able to use macros? ie, make a macro, pass some parameters, no .ifblank directives etc. 

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.

23 minutes ago, Alder said:

spent a few hours trying to convert it to CA65 but had trouble with the macros.

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.

5 minutes ago, Orab Games said:

That's a lot of tools!

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.

1 minute ago, Raftronaut said:

Are you planning to release this on GTROM boards as well? That seems like a natural fit for this project. I am still learning about this mapper, which features of the board did you find most appealing to your project? 

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

3 hours ago, fcgamer said:

No labels please, but if we use labels, make it a requirement for all tools, for all games. 

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.

10 minutes ago, Mugi said:

ah so you are indeed just butthurt that the tool was not available for you to use when you made something, so now you want to shit on everyone using it to self-gratify your own creations then. Thanks for the clarification.

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