2017 NESDev Compo - Rules/Guidelines

Moderator: Moderators

User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: 2017 NESDev Compo - Rules/Guidelines

Post by dougeff »

A technical question: can/will the compo cart use flashROM? Subsequently, would one be allowed to write to ROM within reason?
I feel like this is a "I'm asking about X but really I should be asking about Y" situation. And, will naturally evolve into a S.O. style answer of..."don't do X, you should be doing Y".

Can you describe the actual problem that you need solved. Do you need self-modifying code? Could this be done with a simple conditional if/else?
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by NovaSquirrel »

dougeff wrote:Do you need self-modifying code? Could this be done with a simple conditional if/else?
You wouldn't modify flash for self-modifying code, especially with how slow writing to flash is, not to mention you'd be wearing the flash down.
They meant using the flash to save things without needing to use the battery and extra RAM the Action 53 volumes don't have.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by tepples »

An XY problem is likely, and I encourage FrankenGraphics to describe the goal.

My first guess is that FrankenGraphics wants to write the state of the player's campaign to the cartridge because the game is longer than can be completed in one sitting. The description page for Study Hall brags of "On board flash memory for saving all your high scores/initials and your achievement progress!" This is made possible through the self-flashable variant of the so-called UNROM 512 board.

If this is the case: What all makes up the campaign's state? If it be condensed to 32 bits, an 8-character password becomes practical. The state in The Curse of Possum Hollow is 18 bits (3 for chapter, 6 for bought moves, and 7 for found moves), allowing use of a 5-character password (which provides 25 bits, the rest used for check).
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by FrankenGraphics »

NovaSquirrel and Tepples are correct; We "need" a biggish array to do what we want, which is storing the state of numerous items in One Big Level that's open ended/backtraceable. Unlike a linear sequence of levels, this means we can't just keep track of for example how many keys the player has collected, but rather which specifically which ones has been collected. Same goes for chests and locked doors, maybe boss/es. Not obligatory but neat: health and special status of player character/s. If we're going with switchable characters, they might have different max healths determined by who picks up a container. Even the rooms themselves have theoretically modifiable links which dictates what room leads to another, which enables at least in theory modified duplicates given a switch condition is set or cleared.

If not technically viable, we'll find a way or make do; perhaps downsizing.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: 2017 NESDev Compo - Rules/Guidelines

Post by Myask »

FrankenGraphics wrote:a biggish array
"How long a piece of string do you need?" I hope you're bitpacking "collected/destroyed" bits; you can go far without much memory that way. The dynamic room linkages, however, would add up very fast; depending on how often they're used you might want to only linked-list the alterations to the default grid.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by tepples »

As an approximation, a single character of a password can hold 5 bits of information, or one out of 32 values. This means five 2-state variables (key owned or not), three 3-state variables (key not picked up, key in inventory, key transported to corresponding lock), two 5-state variables (this might be your "special status"), or one of each. But if you end up with more than about 70 bits or 14 characters of data that you need to track, it becomes unwieldy to enter the password at the start of the session. If you run a block cipher over the password followed by a consistency check on what doors can be unlocked before others, you might be able to get away with one or two fewer check digits because the consistency check will pick up more invalid passwords, but that's it.

For more specific information, we will need how many is "biggish".
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: 2017 NESDev Compo - Rules/Guidelines

Post by Myask »

Yeah, we don't want to be the guys with a 104-character password who include a (hidden) apology therefor.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: 2017 NESDev Compo - Rules/Guidelines

Post by calima »

Golden Sun and Zelda Oracle passwords were mighty long, but those were only used once, after completing one game and starting another.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by FrankenGraphics »

We don't want a 104-string for sure, but we do want the freedom to pack in a multitude of items and also some other states. A password system is going to be a tough act of balance.

Bitpacking, yes.
Exact final number of items: Unknown at this point - we're in the process of defining this feature set.
Please treat everything below as hypothesis, not a list of promises:

Some items (examples: finding a weapon, piece of armour, magic trinket, maybe a tri-force like collectible) are rather easy to compress: if chest n is opened, player has its contents in inventory, and a corresponding key can be assumed to have been removed from inventory.

Some items (examples: consumables: lucky clover, garlic, sage, mushroom, potion of y, potion of x, bombs, iron keys, brass keys, silver keys, gold keys) are inherently complex. They might've been in chests. They might've been on the ground or carried by enemies or hidden in breakable metatiles. Assume 0-9 in inventory.

Each opened door lock will imply a key removed from inventory, just like a chest.

Certain save/password rooms may narrow down the needed info. But sequences of rooms/gauntlets that assume a zero-sum economy (like some passages in zelda) where you get a key, spend a key, get a key, spend a key - are relatively boring and we've agreed on a "No True Path" design.

The theoretical dynamic room linking can actually be just one bit per dynamic link; refering to which pointer to use. Dynamic room linkage (in a few select places) is tempting because it would make the most out of the level storage system, which of course relies on reusing portions. 2 versions of the "same" room may change just the reference of a few portions between version a and b, for quite the dynamic effect - Suddenly, a platform has been lowered or a stair has appeared, or a well has been emptied, a hole in the ground has appeared, an item has 'fallen down' from a room above, and so on.

That makes for a whole other experience alltogether, insofar it's implemented.

Considering all this, we are weighing our options:
1) Make a condensed game that's playable in one sitting; cutting content and making paths short.
2) Balance a feature vs ease of use Password System
3) Make an initially long game where the players' memory substitutes a password system/storage method by learning shortcuts. Example: Solstice, which you basically can't beat in one sitting the first 30 something times, but speedrun once you've figured it all out.

4)Ask if there could be a method for storage other than passwords on the compo cart in this year's compo. Hence the original question.

I want all paths explored to be able to make an assessment on features vs hard truths. I'm italizing the fourth since i'm still interested in what the answer might be.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by infiniteneslives »

So the option of including save data on the final compo cart is entirely possible. The challenge is in actually accessing the flash memories on board, coming up with that interface, and having a means to test it during development.

Until we release a volume with saves enabled any entry looking to utilize save data is subject to being the guinea pig. At this point it's best to not rely on the ability to save data to the cart. Assume it won't be available and provide a password system to supplement the cart save data. Then if we're able to collectively pull of cart save data it'll be a bonus.

Not knowing what the compo turn out will end up looking like it's hard to look into the crystal ball and know what the final hardware will look like. Prior to this year's cart we easily fit on 512KByte flash rom, but this year we broke that boundary and had to step up to 1MByte. That jump fundamentally changed how save data would be stored on PRG-ROM flash due to migrating from 5v flash to 3v flash with differing flash algorithms. On top of that, it's possible/likely that a game will see a future release on a future compilation where all volumes are included on on cart. What will the final hardware look like in that cartridge??? Really hard to know, and there may not be motivation to modify your game's code to support saving onto the new hardware design.

Beyond that, it could be potentially dangerous for a single game to be making flash write/erase commands directly to the flash chip. So I'm wondering if there's a better solution we can come up with that abstracts the save process away from the game's code. One way of abstracting things away would be to have some sort of software helper functions provided by the menu boot rom. But that becomes a challenge as well complicating the development of the menu code which is also subject to hardware changes as mentioned previously.

I do have one idea that might be easier to manage from a software standpoint. There being a total of 32KByte of CHR-RAM on board, perhaps a portion of CHR-RAM could act as the buffer save data space. The game would load it's desired save data into CHR-RAM along with some sort of header/signature to denote the data as valid and what game the data is for as the game is played. The user would have to hit reset when done playing, this hands control back over to the menu code. At boot time the menu code could check the designated area of CHR-RAM for the save data signature. If found, the menu would be responsible for copying the CHR-RAM save data into PRG-ROM flash. It could also display some message to the user "game X data saved successfully". On a subsequent power cycle, when the game is selected in the menu system, the menu code would be responsible for loading save data into CHR-RAM before handing control over to the game.

I have other ideas that takes the burden off of the menu code by performing the abstraction mostly via hardware. One option is to simply splurge on including battery backed PRG-RAM with multiple pages/sections games are allowed to utilize. There might not be a great way to prevent games from corrupting other game's save data though.. A more unconventional method would be to add mapper registers with some sort of read/write request structure that interfaces with the CIC. My asynchronous CICOprocessor idea would be much easier to pull off with dedicated mapper hardware, allowing save data to be stored in the CIC's eeprom/flash. Something like that would likely limit the amount of total save data to a few KByte tops, but takes the burden from the menu software, and provides great protection from bricking the cart with a PRG-ROM flash save gone awry.

If we'd like to take the discussion further, perhaps it's best to branch off to a new thread..? Kinda feel like I should have done that with this post..
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by FrankenGraphics »

A split might be good, though preferably after Rahsennor has flagged your post as read if that's ok?

I'm thinking about how your chr-ram idea would play out interface-wise.

Basically, the game would be responsible for either:
1) loading the checkpoint into chrram at every important change of states
2) do the same in a 'save room' or 'save menu'.
-either way, somehow declare with sufficient clarity that the player must hit reset for the game to be permanently stored.
-but also make sure the player doesn't mistake it for needing to reset everytime s/he wants to create a checkpoint.

To what effect can the whole package/presentation help getting the message across?

Battery wram:
At least battery backed WRAM would be separate from prg-rom. If you can't write to prg-rom (if it's not flash or somehow in a read mode that disables writing), the only thing save data can corrupt is other save data. Which it simply must not do, but worst case scenario...
My asynchronous CICOprocessor idea would be much easier to pull off with dedicated mapper hardware, allowing save data to be stored in the CIC's eeprom/flash. Something like that would likely limit the amount of total save data to a few KByte tops, but takes the burden from the menu software, and provides great protection from bricking the cart with a PRG-ROM flash save gone aw
This does sound very good. Is there any other caveat, apart from limiting save space?
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: 2017 NESDev Compo - Rules/Guidelines

Post by pubby »

I feel like it's sleazy to change the mapper rules halfway through for the benefit of one entrant. That's not fair to all the people who have started their programming without feature X.

Also, it is my belief that 64K without extra RAM is a really healthy limit for our contest, and I'm against adding anything extra.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by tepples »

Do the 1 sitting version now, then an expanded version later.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by FrankenGraphics »

Damn, i didn't even think about it being a competition. :? If one entrant finds it objectionable, i won't push for it being part of the compo.

I'd be perfectly fine with staying out of the compo (entering as category 2), but:
-if this hypothetical new hardware feature was reserved for non-competing entries only, it'll probably see less use.
-if it sees less use, it's hard to motivate its inclusion in case it adds any extra cost to either r&d or material reproduction; and/or means hours of extra work for infiniteneslives.
-we're two in this project and i can only speak for myself at this point.

The "third way" i can think of is that as far as the compo is concerned, noone assumes saving: Fully implemented saving (be it score boards, campaign status, level unlocks) is subject to disqualification. Non-functional remnants (like having a save room with no function) is not subject to score setting. Then post-compo, implement anything you want saved in your entry. Games that'd be geared for saving would actually have a disadvantage this way, because the saving isn't implemented for judging although the design might be dependent. I don't feel i have a clear overview if that sort of thing would be interesting enough, though. What do you think?
tepples wrote:Do the 1 sitting version now, then an expanded version later.
That would at any rate be easier in regards to workload. It'll probably be this or some password related compromise.
pubby wrote:Also, it is my belief that 64K without extra RAM is a really healthy limit for our contest
I agree that an upper limit of 64k is quite golden. For future compos though, isn't the ability to store letting people be more creative/making content of higher polish with roughly the same workload/constraints?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2017 NESDev Compo - Rules/Guidelines

Post by infiniteneslives »

I don't see any of this as changing the rules. As mentioned the entry should be able to work without save data on the cart. Perhaps via password (however long), maybe even requiring the entire game to played in one sitting.. The entry would be subject to the same rules as everyone else. At this point, we can't promise that saves will be made available on the released hardware. There's lots of work to do in order to get to that point, so don't rely on it being there.

It's notable that there is significant benefit of a long password system paired with save data on cartridge. It makes it much simpler for the average user to transfer save game progress between carts, emulators, etc. Dumping hardware is not required to make backups even if it takes a couple mins to enter in the password. Maybe the password system is a manual hex dump directly into CHR-SAVE-RAM..?

Asking for new useful features, and then being willing to put the effort forth to be the guinea pig is how improvements like this become a reality. As always any number of improvements and feature/content additions are more than welcome in the ~2 months that are between submission deadline, and rom finalization. If we get the ball rolling now, it's much more likely for addition of support for save data on the cart to see reality. That also paves the way to expand the rules for future compos if such a feature is desirable.

My asynchronous CICOprocessor idea would be much easier to pull off with dedicated mapper hardware, allowing save data to be stored in the CIC's eeprom/flash. Something like that would likely limit the amount of total save data to a few KByte tops, but takes the burden from the menu software, and provides great protection from bricking the cart with a PRG-ROM flash save gone awry
This does sound very good. Is there any other caveat, apart from limiting save space?
Not really on a general hardware basis. Keep in mind that the entirety of this idea is just that, an idea. Lots of work to do in order to realize this idea on functional hardware. I may have more specific caveats you're asking for when hardware development is underway. The other challenge with unconventional features like this is that current emulators don't yet support these features complicating your development and testing.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Post Reply