nesdev.org

I am in process of programming my own homebrew game, which I might want to release as a cartridge and sell it (much like sivak did with his Battlekid games on Retrousb).
What do I have to consider? Any issues with patents when I for example use graphics or music from other (licensed) commercial games?
If anyone has already experience or does know where I can aquire good information on this topic, i would really appreciate it.

I don't believe there are any significant remaining patent issues.

However, you should not use music, graphics, code, or other content from other games. That's a copyright violation. Copyright lasts much, much longer than patents.

good to know, that copyrighted material actually must not be used. So my ideas of cameos in the game will be dropped....

Now, if i changed my mind and were to release it as free homebrew, is there also any issues using copyrighted material?

If you want to use someone else's copyrighted material in your own work without buying a license, ask a lawyer first about what does and does not qualify under "fair use" rules.

Copyright law does not care whether something is "for profit" or "freely redistributed". However, some corporations may elect to not care if you're not making a profit.

Also, bitmap fonts (i.e. letters, numbers, punctuation) are deemed not copyrightable in the US, so you could probably get away with borrowing that portion of something else ... not that finding or drawing a font is much effort.

Ok, well, it seems like it might not be worth going through the hassle and stress of getting some copyrighted material into my work.

Another question:
Is there a way of securing rom data from being pirated?
I know i could implement a new custom mapper of which only i know how it operates. But for someone motivated enough, it would be no problem to "crack" the mapper.
Does anyone have an idea on how to secure rom data (and possibly chr) from being accessed by anything other than the nes? This would be pretty interestening.

You can make it a royal pain to deal with ... but crackers tend to like puzzles.

SNgamer wrote:Does anyone have an idea on how to secure rom data (and possibly chr) from being accessed by anything other than the nes? This would be pretty interestening.

That's a curious request coming from someone who was JUST NOW considering using music and art from existing games!

Anyway, there's very little you can do to protect your data. Even if you find a way to heavily encrypt everything, at some point it will be decrypted (it doesn't matter if by software or hardware) to be delivered to the NES, and it can be easily intercepted by crackers then.

Every time this subject is brought up in these boards, the consensus is that the best you can do is digitally sign each ROM (something more complex than a string at a fixed memory location, please), so you'll at least know WHO to blame in case it does get distributed. Letting people know about this might discourage them from distributing their copies.

If you know it's signed, all you need are two different copies and you will know where the signature is. From there it should be straightforward to obliterate. I think this method is more likely to catch someone if they are unaware it's signed. i.e. it's better for punishing someone after they've already leaked it, than as a deterrent.

Honestly, there's no good way to do it, and even if there was you wouldn't want to speak of it here in the open.


BUUUUUT

The vastly harder task is to actually make a game worth stealing. You need to do that first, and you haven't even started on that one have you?

rainwarrior wrote:If you know it's signed, all you need are two different copies and you will know where the signature is.

Not if they're shuffled differently. I made a preprocessor that shuffles the order of instructions, subroutines, and variables in a source code file. Factorial growth means that even for a simple little NROM game, there are more possible ROMs than atoms in the observable universe squared. See also old discussion about keeping prototypes secret.

From there it should be straightforward to obliterate.

I don't see how given that each copy has its variables and subroutines in a different order. An IPS from one version to the other would end up covering virtually all of the PRG ROM. To make a shuffled ROM untraceable world require at least as much effort as doppelganger expended making the disassembly of Super Mario Bros.

I think this method is more likely to catch someone if they are unaware it's signed. i.e. it's better for punishing someone after they've already leaked it, than as a deterrent.

In any case, the shuffle methodology would probably provide strong enough evidence to identify and go all Capitol v. Thomas on the offender.

Ah, sure, a complex reordering of the game code could do it. Still, all you have accomplished is naming your leak. If your game is worth putting in enough peoples' hands, it will be leaked by one of them, and then everyone who wants it will have it. You can try to sue the leak at that point, but you haven't stopped the piracy. All that effort was just to take revenge on a single person.

Personally, I'd be too afraid to do something that drastic. Software never works entirely as expected, and you're going to have bugs that manifest differently or not at all depending which build it was. To me, that's a maintenance/stability/testing nightmare. Some people are willing to take this kind of risk in the name of anti-piracy though.


If it's just to protect a prototype, I could see how it would be effective enough. Given only to a pool of people small enough to be intimidated, and bugs are expected in unfinished software, so maybe that part isn't an issue either.

I can't imagine ever wanting to try this method, myself, but good luck to you with it.

I have come up with a method that, in theory, would allow for encryption of specific banks within the PRG-ROM. Code running from a different area of memory would be unable to read valid data from it. And almost any external cart readers would be stopped from reading it.

It was fun to think it up, but who knows if I'll actually want to implement it.

I'm moving this thread, lets keep any homebrew-related posts out of the repro forum.

tokumaru wrote: That's a curious request coming from someone who was JUST NOW considering using music and art from existing games!

Yeah, as i said, i had the idea for some cameo appearances which of course would have needed those licensed graphics and sprites, but i dropped it in favor of not wanting to go through a lot of hassle and stress to include these.

rainwarrior wrote:The vastly harder task is to actually make a game worth stealing. You need to do that first, and you haven't even started on that one have you?

Actually, i have started with it, but of course you are right on making it worth stealing

to the ideas posted:
if the game would be cracked and distributed, i would not think of taking any legal action. so being able to identify who the leaked the game is not neccessary, thus its not neccessary to sign every single copy in order to do so.
i thought more of making it just very hard to get a dump of the rom, so it would be secured at least for some time, if not forever if it was too hard


But I should probably focus on getting some work on the game done before even thinking of security measurements.

SNgamer wrote: i thought more of making it just very hard to get a dump of the rom, so it would be secured at least for some time, if not forever if it was too hard

Look up tapedump and realize you not only need to design a new mapper (not that tapedump supports every one, but it can be modified to support known ones), but also need globtops. Can't just do one or the other. Without a custom mapper, I figure out what mapper you're using and write software to dump it. Without globtops, I desolder and read your eproms and then have to do a little work to figure out your bank switching. (This is probably the one to choose if you're only going to do one, though.)

Even with both, someone will do it. Especially if the game is worth dumping.

But I should probably focus on getting some work on the game done before even thinking of security measurements.

Indeed.

Even without chip-on-board packaging ("globtops"), putting some of the bank switching logic and possibly even game logic in a tamper-evident microcontroller (or MCU) was a common method of protecting arcade games. Bootleg arcade machine makers had to program a high-level emulation of what the MCU was doing in their own bootleg versions. This is why the arcade version of Bubble Bobble was emulated wrong until 2006 when its MCU was decapped: the HLE got the EXTEND randomization and the "monster pecking order" behavior (where only the first monster near the player follows the player) wrong.