RPG Time!

Nishi

Member
Wow, I really hope you release the module. It looks fantastic. Would love to make a straight up RPG.
Issue with releasing a module, is the fighting system, monster/character tables, items and so on are all code. Which means there isn't a GUI for people to quickly make changes to the stats, names and so on.

Joe did say he's working with someone on a RPG game and it would be worked into NESMaker. But I don't know where they are on that.

There's still a fair amount of work that's needed for the fighting system. IE: Making healing items usable, weapons/armour, magic, monster abilities and so on.

I actually wanted to have an Alpha out as a proof of concept for people to okay... And that isn't going to happen till next year. šŸ˜‚
 

PasseGaming

Active member
Oh... well that's disappointing. Hopefully Joe manages to finish the one he has been working on, otherwise many of us just aren't going to have that opportunity. Anyhow, I hope all the best with your project.
 

Nishi

Member
Oh... well that's disappointing. Hopefully Joe manages to finish the one he has been working on, otherwise many of us just aren't going to have that opportunity. Anyhow, I hope all the best with your project.
Don't feel bad. Depending on how things go, I may release my code once it's done. But with that said, it would be "As Is" with no support.

I would give documentation on how things work and how to edit, but that's still a fair amount of time down the road.
 

PasseGaming

Active member
Don't feel bad. Depending on how things go, I may release my code once it's done. But with that said, it would be "As Is" with no support.

I would give documentation on how things work and how to edit, but that's still a fair amount of time down the road.
Honestly, I think that is the most anyone would expect from any custom module. Hopefully you do decide to release it, might end up being a lot of work but having a framework is a far better start then nothing.
 

Nishi

Member
So like I shared on the FB group, I'm going to have two builds of the fighting system from this point on.

One that will let me attack dead monsters so I can show and test:
1: When a character is attacked there HP turns red, goes down and then goes back to white.
-I wanted this since without sprites to go off of, there wasn't a way to notice which character was getting hit unless you were watching everyone's HP
2: The "Attack The Dead" build also lets me show that when a character is at 20% or less HP the name will turn red. Name changing colours will also happen when a character is poison, turned to stone, and dead.
This build will also let me test weapons, armour, monster and character stats and so on.

And a working build that will move an attack from a dead monster, to the first living monster in the group.

 

Nishi

Member
So with any JRPG game, they have a save feature so you can save the game and come back to it later.

As it stands games that use Mapper 30, only use two chips one CHR chip and one PRG ROM.

Mapper 30 can use flash memory so games that have a save feature use part if the memory from the PRG ROM to save. Normally an empty bank can be used, but the issue is the ROM chip canā€™t be written to if itā€™s in use and being read from or executing code. So the command would have to be written to the NES RAM first, then executed from RAM to write the save data for the game.

With that said two commands have to be done from RAM. One that would completely erase the bank where the save file is, the second command to write the new save file.

The issue with this is with using the same ROM chip as where the game is. If a ā€œhiccupā€ happened during the save process and it deleted and/or wrote to the wrong bank, there goes the game.

Since the game isnā€™t anywhere close to being done, itā€™s hard to say how big the save file can be (Iā€™m slightly thinking 4 to 6KB). Issue is I donā€™t know how much memory is going to be free at the end. More so since the amount of map data is going to be bigger then what almost anyone has done, and then thereā€™s items, weapons, armour, monsters and the list goes on. Doing the first JRPG that isnā€™t a ROM hack is breaking new ground a far bit.

Boards that support the chips that Mapper 30 uses only have room for the CHR and PRM chips and the lockout chip. Unless you use a board that can switch between V/H scrolling, and/or supports Flashlocking (Makes it so the chips canā€™t be written to again).

So using an empty bank is almost needed to do a save file for the game, which means depending on how big the save file needs to be, something from the game might have to get cut for the needed space.

The other way to do a save file is to do what they did back in the 80s and 90s, via battery save files. So a board with a spot for the battery would be needed, and a spot that also allowed a SRAM chip. Issue is that NONE of the boards Iā€™ve been able to find that have a battery spot and the extra SRAM socket support Mapper 30. But with using these boards as a point of reference, a new one board ā€œcouldā€ be made for the games needs. This way a SRAM chip can be used for the save file, and the size of the file is pretty much nothing to worry about. Itā€™s just clearing the RAM chip every time it needs to be written too and then written to.

So Option 1: Make sure thereā€™s an empty bank with enough space so it can handle the save file.

Issue 1: If a table or stack over flow happen because the player causes a glitch and cause the save command to delete the wrong bank or put the save data else where the cart becomes dead.
Issue 2: Only get about 100,000 saves
Good Part: Keeps cost down.

Option 2: Like the custom fighting system I got to make, I would need a custom board so I could have a battery and SRAM.
Issue 1: Get to custom design the board for the game
Issue 2: Cost of the game goes up because of the battery and SRAM
Good Part: This would also let me flash lock the PRG chip so nothing could be written to it. Save file space wouldnā€™t be an issue and more then one save could be done.

Before people ask, or suggest I have reached out to a few websites that sell boards that offer battery and SRAM spot, but theyā€™re for MMC1/3 mappers and no one knows if I used the 39SF040 on them if it would work. So assuming no just to be safe and save time.

So technically option 3 would beā€¦ Redo the game for the MMC3 and kiss my work in NESMaker bye, bye. And hope my code will work or only need slight changes.

Thoughts?
 

Logana

Well-known member
Iā€™d probably say to go with option 1 because it would be a lot easier although I would say that maybe the actual save code could be reduced like having a designated tile on each screen for the players save spot, or just having designated save spots or stations as a more ā€œcheckpointā€ based save system with issue 2 on that I donā€™t quite understand, why would you be limited to 100,000 saves, I mean itā€™s not really a problem because itā€™s not like your gonna save that many times if your not doing it on purpose. Even with that though I think it would probably be the best and with some proper testing we could find all the possible ways that it could over flow a bank, only really could think of one way that could happen though, if you where on the seem of the next screen. So all in all I think it would be the best solution since it also keeps the price down so probably more people might buy it as well.
 

Nishi

Member
Iā€™d probably say to go with option 1 because it would be a lot easier although I would say that maybe the actual save code could be reduced like having a designated tile on each screen for the players save spot, or just having designated save spots or stations as a more ā€œcheckpointā€ based save system with issue 2 on that I donā€™t quite understand, why would you be limited to 100,000 saves, I mean itā€™s not really a problem because itā€™s not like your gonna save that many times if your not doing it on purpose. Even with that though I think it would probably be the best and with some proper testing we could find all the possible ways that it could over flow a bank, only really could think of one way that could happen though, if you where on the seem of the next screen. So all in all I think it would be the best solution since it also keeps the price down so probably more people might buy it as well.

Giving a player a "Save spot" isn't an issue since that can be limited to towns or a Save Maker. So saving in a spot is easy. The issue is if a player glitches the game and gives themselves more of an item, XP, gold or something else which writes bad commands to RAM, and alters how things run..

Something like glitching Pokemon on the GB to get Mew.

The thing with old NES and GB games doing this could corrupt the save file and/or crash the game. With option 1 for saving, this could kill the cart if the "delete and right new save here" could be sent somewhere else.
 

Logana

Well-known member
Hmm vary complex, maybe you could make it so that when saving the code it checks the amount of things you have and if you have more than say 10,000 gold then it resets to 10,000 so basically
Itā€™s checking the gold variable, if you are using a variable for gold and stating Iā€™d G > # the Set G #, so basically just putting a cap on gold and items since from what I understand is a lot of glitches come from numbers higher than 255 for items and for money having that be more than the space that you have set aside for displaying it to the player, although your last claim could still happen, if the player could some how write over the code that selects the bank to dump then save file or code in this case in, although it would be extremely hard to pull off, probably would have to do a ton or random stuff. But the thing with gliches in pokemon was the original games red and blue where coded over a 4 year period with little to no documentation which definitely made this a lot ā€œglitchierā€ or well exploitable. It is still your choice that is just my opinion, I wish you the best of luck with what ever choice you choose ;p
 

TakuikaNinja

Active member
Reading through this thread might help you understand flash saving better: Lets talk about saving [4.1+]
Note that the thread was written when Mesen didn't support self-flashing yet, so ignore that part.
I doubt there is much to change when it comes to adapting it to version 4.5.X.
 

Nishi

Member
Reading through this thread might help you understand flash saving better: Lets talk about saving [4.1+]
Note that the thread was written when Mesen didn't support self-flashing yet, so ignore that part.
I doubt there is much to change when it comes to adapting it to version 4.5.X.
Already looked at the post a while ago, and used it as a base for what I was doing. But still have to worry about the issue I posted about.

Heck a simple glitch on the SNES for Final Fantasy 6/3, is just changing the window settings and dying 52 times. Depending what you want to do, you can get music to play, warp to a spot in the game, get characters that you don't have yet which at times worked or gave you a glitch character, go to the last battle of the game as so on.

Tested saving while glitching the game like this with different results. At times the save was corrupted and wouldn't load, and if it did different issues would pop up from characters being replaced by Moogles that you can't equipped, loading into zones that you can't walk from, items being glitched and so on.

I tried a few different things to glitch and corrupt the save data at once so all the data was bad and not usable. But could only do one save file. Now with FF 3/6 corrupting a save file isn't an issue since you can just copy over the bad save data with another save file. That and the save data is on a different chip, so even if I was able to glitch all the data and made it useless where even trying to save a new game wasn't able since the tables where the saves are kept on the SRAM are bad (The game looks for the spot where it's told to save, but since its data a headers changed it can't), the easy way to fix this is removing the battery which clears the SRAM.

At that point the game sees the blank memory and then writes new headers, and can save again. The issue with using the PRG ROM to save, is it can't be cleared or have broken data replaced unless you completely re-do he chip

Yes, I studied how games did save files and then tried to break it as much as I could... What's your point? :p
 

TakuikaNinja

Active member
You say the FF 3/6 save glitch is simple, but you need to consider that the requirements are so specific that none of the playtesters nor the majority of players would have noticed it at all.
You're probably breaking the save system more than the average player ever could, to be honest. What do you mean by "saving while glitching the game"? Are you messing around in the memory viewer or something?
 

TakuikaNinja

Active member
Also, you can probably mitigate the issues during saving by prohibiting player input and the like.
The process might look like this:
  1. The player chooses to save.
  2. Disable player inputs.
  3. Go to a blank screen with the usual "don't power off while saving" message.
  4. Enter some kind of pause mode (to prevent irrelevant game logic)
  5. Transfer the flash saving routines to RAM now that nothing will mess with it.
  6. Run the save routines.
  7. Revert back to where the player was.
Another tip: Try to reduce the amount of things that you need to save, no matter the amount of room you have. Compress and/or encode stuff if you can. Spending more time encoding and decoding stuff is better than wasting precious space.
 

Nishi

Member
You say the FF 3/6 save glitch is simple, but you need to consider that the requirements are so specific that none of the playtesters nor the majority of players would have noticed it at all.
You're probably breaking the save system more than the average player ever could, to be honest. What do you mean by "saving while glitching the game"? Are you messing around in the memory viewer or something?
No. I've limited myself to breaking the game and saves as someone would as a player.

I don't edit game data in a emulator or use one in my testing. I actually play, test and break things on my cart and NES/SNES. This way I can see how things are done from the "player level"
 

Nishi

Member
Everything is subject to change, and only showing the sheets with a colour pallet that showed the monsters on them the best. But happy with how things are turning out.

Also a big "Thank you!" goes to Wilson who's been helping me with some of the artwork for the monsters!

Monster Sheet.png
 

Nishi

Member
So when it comes to my ambitious game design for my RPG Yesterday's Heros I came to a brick wall that I need to jack hammer my way threw.

The first issue is that the Map 0 (Over world) is used up completely by my world map. Map 1 (Underworld) is also filling up fast with the few towns and dungeons I've done. Sadly even with the empty banks and taking out what I don't need from NESMaker, I don't have that much room.

Second thing is I don't want any colour swapped monsters. So no Dragon, Ice Dragon Fire Dragon that have different stats but are only colour swapped. With 32Kb... Not going to happen. Even if I put the monsters graphics in the PRG ROM I would have even more limits on what I could be done...

So been reworking/breaking Mapper 30 and the engine so I can have more memory. Which means I need a board that doesn't exists to support the extra memory...

I'll leave this here.

_20210203_224514.JPG
 

CutterCross

Active member
Second thing is I don't want any colour swapped monsters. So no Dragon, Ice Dragon Fire Dragon that have different stats but are only colour swapped. With 32Kb... Not going to happen. Even if I put the monsters graphics in the PRG ROM I would have even more limits on what I could be done...
I think you're misunderstanding how graphics are stored on a mapper like UNROM 512. ALL of your graphics are stored in PRG-ROM, because the mapper uses CHR-RAM. It HAS to store graphics in PRG-ROM to copy to CHR-RAM, which the PPU is able to read 8 KB at once for both pattern tables. The 32 KB refers to the four pages of CHR-RAM which can be swapped out on the fly like typical CHR-ROM banks, except they can be overwritten.

From the sounds of it, I think you're ballooning your scope way too far if you're seriously considering ditching an already large mapper like UNROM 512 for something with even more ROM, especially for a first project. The last thing you want is for this sort of thing to spiral out of control on your first outing. That, or you're not taking the time to consider better methods of approaching the game's design that could fit the constraints you're given. Most of the appeal of NESdev or any other vintage console dev is to do the most with the least possible.
 

Nishi

Member
I think you're misunderstanding how graphics are stored on a mapper like UNROM 512. ALL of your graphics are stored in PRG-ROM, because the mapper uses CHR-RAM. It HAS to store graphics in PRG-ROM to copy to CHR-RAM, which the PPU is able to read 8 KB at once for both pattern tables. The 32 KB refers to the four pages of CHR-RAM which can be swapped out on the fly like typical CHR-ROM banks, except they can be overwritten.

From the sounds of it, I think you're ballooning your scope way too far if you're seriously considering ditching an already large mapper like UNROM 512 for something with even more ROM, especially for a first project. The last thing you want is for this sort of thing to spiral out of control on your first outing. That, or you're not taking the time to consider better methods of approaching the game's design that could fit the constraints you're given. Most of the appeal of NESdev or any other vintage console dev is to do the most with the least possible.
Just going to apologize head of time, if I seem to be rude at anytime. Just replying as a geek.

I know the difference between ROM and RAM. But like I said before I was running into issues with running out of memory. So putting my graphics Into a CHR-ROM, worked by freeing up memory.

The next issue was my maps. Since the world map takes up Map 0, two towns with shops, Inns and keeping things down to story based insides, and two dungeons... I was running out of room 15% threw the story.

Yes I would love to use one of the VC mappers, but I want to keep things to "new parts" only. I'm also trying to keep things inside NESMaker.

With switching the CHR-RAM to ROM. It let's me move from 32Kb to 512Kb for graphic memory, that isn't shared with the PRG-ROM.

Extending the banks to allow the extra chips, will let me keep my maps as they are and work on the rest.

This is my first NES game, but not my first game. I started with things on the TI-83 back in highschool because I was board, and did things on the C-64.
 
Top Bottom