2017 NESDev Compo - Rules/Guidelines

Category 1:

• This category is reserved for games. Any tools or toys should be submitted as category 2.
• Mapper 28 compatible entry up to 64KB with NO PRG-RAM
• Prizes as follows:
  1st Place - $512
  2nd Place - $256
  3rd Place - $128
  4th Place - $64
  5th Place - $32
• Limited Edition multicarts for all meritorious entries (at judges discretion)
• Judging criteria and full submission requirements - WORK IN PROGRESS
• Anonymous entries are allowed if you wish to opt out of receiving a prize, but would still like your submission included.
• By submitting an entry into this contest, you are giving full consent to use the entry on the multicart. Submissions must meet multicart standards to be inlcuded (see below under general guidelines)
• See General Guidelines below.

• Contest runs until January 31, 2018.
• Entries should be submitted by February 1st 12:00AM CST
• Commercially released entries, and previously submitted entries with no changes are discouraged.
• Multiple entries are allowed and encouraged.
• Only one cash/cartridge/other physical prize will be awarded per entrant across all categories. If multiple submissions place in a cash winning position, the greatest prize will be awarded, and the runner up will receive the prize. You can only win one cash prize*. You can only win one cartridge**. You can only win one other physical prize.
• Entries must be original. Plagiarism and copyright infringement will result in disqualification.
• Use of existing tools/libraries/code qualify as long as permission has been granted by the author.
• Collaborations are allowed, prize distribution will be decided by those who collaborated on the project. This decision should be known by the person who submitted the entry as they will be our primary contact. Please make these decisions beforehand.
• There are no restrictions on submissions including explicit content.
• Publishers and organizers reserve the right to request changes to your entry for content exceeding E10+ ESRB rating prior to inclusion on published cartridges.
  
  *In the event that a single entrant wins multiple cash prizes, regardless of who collaborated on the projects, the person who submits the project represents the whole. i.e., Project A and Project B won 1st and 2nd respectively. They were submitted by Bob. Larry was a collaborator on Project B. There will still only be one cash prize for the two projects.
  **If the entry is a collaboration, additional cartridges may be purchased at cost for fellow collaborators (or deducted from a cash prize if applicable).

Category 2 (the non-contest):

• Anything Goes - old unreleased stuff, modified existing stuff, whatever. If it runs on the NES/FC feel free to submit it.
• There will be no cash prizes awarded for this category.
• Multicarts and possible physical prizes for all entries included on the multicart (at judges discretion)
• Depending on the configuration of the entry, it may not be possible to include it on the multicart, however, at the judges discretion multicarts and physical prizes will be awarded. For exceptional submissions, extra effort may be done to adapt the game/cartridge hardware to support being included in the multicart.
• Entrants are not required to consent to multicart inclusion upon submission.
• Since this category will not be ranked or judged, it will also not be under the strict submission dates and times. If it is submitted before the multicart is released, then it is fair game. Keep in mind, the sooner it is submitted the better chance it will have at making it onto the multicart.
• Entries in this category will also not be under the restriction of the General Guidelines above, but material you do not have rights to will not be considered for the multicart.

Category 2 is intended to give publicity to homebrewers by having their work placed on the nesdevcompo website, and to encourage entrants to finish their projects.

Please reply on this thread, PM me, or email NESHomebrew@gmail.com with any questions or clarification. Thanks and GOOD LUCK to all entrants!

Don't want to say June 1st is the start date, as it implies that people can't start until then. If we really need a start date, I would use Feb 1st, the day after the previous compo ends. In reality, IDK why we need to give an explicit start date though. We really don't techincally have one in the sense that you can't start working towards your entry until a specific date. So I'd prefer to not list a start date at all.


Perhaps a clearer way to explain this would simply be that the goal of the cartridge release is on par with an E10+ ERSB rating. IMO originally released NES games fall in the E-E10 range, which sets the tone for what people expect from the console's content.

Isn't that kinda restrictive? I mean, I understand (but don't necessarily agree with) avoiding nudity and sex, but such a rating doesn't even allow blood! More often than not, games are about fighting enemies, so guns and violence are frequently present, and being able to represent those elements exclusively in cartoony ways is extremely limiting IMO.

We're all adults here, so it seems silly to me to restrict the creativity of the contestants because of the relatively small number of kids that'll be playing these games. Maybe we should rate the games individually, and possibly isolate or even hide games with "questionable" content, and have the parents monitor their children to make sure they aren't being exposed to content they consider inappropriate, instead of blindly giving them a stack of cartridges and walking away. It's not fair that the whole thing has to be watered down because of parents who don't want to actively monitor what their kids are doing.

I'm just trying to come up with clear guidance beyond "any parent is comfortable with" which is widely open to interpretation, many parents may not even permit video games.

Considering the graphical limitations of the system accurately depicting gore without coming off as cartoonish is a challenge IMO. We have never had a submission with blood before, so I have a hard time seeing the limitation. That said, personally I don't have an issue with 'mortal kombat' blood in general.

It may be best to simply state the goal of E10+, and recommend entrants ask for input on specific content that pushes that limit.

I've brought this up in the past, but perhaps making it this more clear in the rules/guidance would help. The censoring is not on the compo entry alone, maybe it shouldn't be in the official rules at all. Put whatever you'd like into the game, express yourself however you choose. Explicit content does not disqualify one from earning any placement in the compo. But if your entry might have a hard time earning votes from your peers if it's excessively offensive. The censoring is only subject to content seeking approval for publishing on the annual cartridge. If there are enough people that want to create explicit entries and make a separate dedicated release any member of the community is welcome to head up that effort. I may even be willing to publish it myself if there is enough content/interest. If someone disagrees with me so strongly that they'd like to take over responsibility to publish the cartridges I'd happily hand over the reigns if the community supports it.

I don't see the big deal, because if you have to censor your game for the multicart nobody stops you from publishing it unaltered afterwards, elsewhere.

How about this wording for the rules:

There are no restrictions on submissions including explicit content. However publishers and organizers reserve the right to request changes to your entry for content exceeding E10+ ESRB rating prior to inclusion on published cartridges.

EDIT: typo fixed!

Correct the spelling to "ESRB" and I think you have a winner.

OK, the requested changes have been made. Anything else?

Looks pretty good, but I'm wondering if we should change the language to give us more freedom on dev. edition, limited edition, regular edition, numbering etc until we're preparing for the release.


proposing the following instead:
-Limited Edition multicarts for all meritorious entries (at judges discretion).



proposing:
- Multicarts and possible physical prizes for all entries included on the multicart (at judges discretion)
- Depending on the configuration of the entry, it may not be possible to include it on the multicart, however, at the judges discretion multicarts and physical prizes will be awarded. For exceptional submissions, extra effort may be done to adapt the game/cartridge hardware to support being included in the multicart.

Trying to iron out a few question marks i have. If i would team up with more than one competing entrant (doing graphics, sound, and probably have shared design responsibility), how does that work? I take it it's the entries that compete, but we have rules for multiple entries from the same person. Or entrant. The one submitting might be what counts?

The cash prize for teams has been made clear. I interpret it as "submitter wins representing the team, any splitting can be dealt with between team members and should be split". How about cart prizes? A large team winning could be cumbersome economically if every team member gets one (production, shipping...) or is that a small matter - or maybe there's only one cart? If so, wouldn't it be better if the team got a "voucher" representing the cost of making a cart, and be able to split it as a discount for for getting a cart each. Probably not the best way to express it as a rule... just seeking clarity on team rules.

The rule as it stands is that all prizes (including the one cart) are split amongst team members.

I realize this might be lame for a team working on an entry. I've proposed in the finances thread, to allow contributors to purchase regular edition copies at cost. After all, it's not our goal to turn a profit on the contributors themselves.

However considering the state of our funds, there's room to be more generous with rewards to entries with team members. Coming up with a fair way to reward teams vs solo entrants is a challenge, to which I would like to see what others propose.

If we want to reward a team with multiple cartridges per member, at a minimum I think the contributors all need to be listed with their areas of contribution in the submission blurb. Additionally perhaps we should put a cap of ~3 copies..?

An idea in between those two proposals would be to allow the contributors in a team to purchase a limited edition cart at cost. If the entry places high enough for cash prizes, the cash reward would cover at least 1+ copies. Hard to be much more fair that that I suppose..

I'm game if everyone else is to allow collabs to purchase extra carts at cost. Also, any last suggestions before we put things in stone?

User case scenario:
A Collaborant is involved in two entries with different entrants, to an extent that satisfies the rules. They happen to score, say, 4th and 5th place.

Both entries have separate entrants, so as per the rules, both entries win a cash prize. (Besides, having a common collaborant shouldn't disable participation on equal terms for the entrants). How is the cash prize divided, then? What is fair?

I think my suggestion would be:
Since the collaborant scored (via proxy of the submitter) both 4th and 5th place, the highest scoring place is 4. The collaborant gets to split that prize with the submitter of that entry, but not the one scoring 5th. In effect:
Submitter, game A, 4th place: 32$ (half)
Collaborant, game A & B, 4th place: 32$ (half)
Submitter, game B, 5th place: 32$ (full)

Thus, a submitter can't score more prizes than anyone else, but be rewarded for the highest ranking submission s/he contributed significantly to. Same as anyone else.

Is this reasonable? Are there any holes?

I would keep it between the teams. If you agreed to get half with A and third with B, you should get those no matter how A and B score.

My reasoning is that it fixes something i percieve as a loophole where the status of a contributor can give you a better chance at scoring a cash prize than one having the status of a submitter (most often if not historically always the coder or main coder). What's your thoughts on that? Also, the absense of rules on team wins requires actively making deals (which may amount to nothing), repeatedly. A collective agreement is energy and time saving, perhaps a bit more secure, thus encouraging team efforts.

Hm, but perhaps the rules shouldn't explicitly specify how hypothetical prizes are split between team members, though, since contributions can vary, and/or if you think that is discouraging teaming up.

I'm of the mind that typically there is only one main programmer of a given entry.

If one person contributes art/music to two separate entries, with two separate programmers, the fact the programmers are different separates the teams into two different teams for prize consideration.

For example:
Basket ball game:
-programmer: mario
-music: princess
-audio engine: luigi

Football game:
-programmer: luigi
-music: princess
-audio engine: luigi

If the basketball game wins 1st place, and football game wins 2nd place, these are seen as two separate teams. Just because luigi shared his audio engine with mario, and princess composed the music for both, the games were primarily developed by two separate people.

As the rules are written though, I think these would be seen as the same team submitting two entries. It would especially sound that way if a 4th person made the artwork for both games. At that point it might seem like a team is just taking turns who's the main developer/programmer.

Ultimately we can't cover every possible scenario in the rules. I think the rules as they stand are as explanatory as we need. Further elaboration on this will only confuse things. This is something best left to the judgement of the organizers I feel. And entrants are welcome to elaborate on their situation explaining why they should be judged as separate teams, and let the organizers make a judgement call.

These are the two rules regarding cash/collabs:



I don't think adding percentages will solve anything. Every project is going to be different, and we aren't going to fill all the loopholes. I'm going to recommend the following change. Thoughts?

• Only one cash/cartridge/physical prize will be awarded per entrant across all categories. If multiple submissions place in a cash winning position, the greatest prize will be awarded, and the runner up will receive the prize. You can only win one cash prize*. You can only win one cartridge**. You can only win one physical prize.
• Collaborations are allowed, prize distribution will be decided by those who collaborated on the project. This decision should be known by the person who submitted the entry as they will be our primary contact. Please make these decisions beforehand.
  
  *In the event that a single entrant wins multiple cash prizes, regardless of who collaborated on the projects, the person who submits the project represents the whole. i.e., Project A and Project B won 1st and 2nd respectively. They were submitted by Bob. Larry was a collaborator on Project B. There will only be one cash prize for the two projects. Sorry Larry, talk to Bob (or see below).
  **If the entry is a collaboration, additional cartridges may be purchased at cost for fellow collaborators (or deducted from a cash prize if applicable).

But that's a matter of honesty. If you look our blurbs, there are three people involved in my three entries. I might be the programmer and do most the GFX, but Davidian is the sound guy and Anjuel has made quite a lot of input in the design of the game (with a 9 months old baby he's quite busy now). Had I wanted to cheat, I could have entered the contest as three different "entrants", making Davidian and Anjuel submit one game each. In such case, we would have perceived two prizes as we have scored a 4th and 5th position. But I don't find that honest. That would be cheating and taking advantage of a loophole. Not my cup of tea.

Anyways, we are grown up adults and this compo is small enough so special situations can be dealt with personally and solved practically.

I like the idea to purchase extra carts at cost. I'll be purchasing two extra carts for Davidian and Anjuel

This is not critical, as not a formal part of the rules, but I have troubles to understand this sentence:


How does it encourage to finish the projects? According to last year, changes where allowed long after the deadline without making it "category 2" games. Is it targeted to entrant of previous years, to take time to expand their entries? Is it for any kind of game that is finished?

A project in Category 1 is judged as of the snapshot submitted before the deadline. It can progress further, but the build at the deadline is judged.

The idea of the motivation comes from someone having a project they would like to see included on the cartridge, but aren't concerned about winning prizes. The project must be effectively complete to be included on the cart. So they may be motivated to finish their project to the point where it's publishable so it'll get included on the cart. The action53 project effectively provides developers means to get their creations on a physical cartridge without really having to do any of the work involved with publishing physical cartridges.

I have updated the original post. If everyone is happy with the changes made, I'm ready to finalize the rules for this year.

Looks good!

Looks good to me. Thanks for putting this all together!

Thanks for all the input! I'll be picking everyones brains regarding voting soon.

Coincidentally, I had mocked up a Castlevania clone at one point, with Splatterhouse-levels of realistic gore. (I won't post it, don't worry.)
It had two different scenes, one in a run-down cathedral, and another in a hellspawn-infested underground passage.

If it was developed, the game would be too complex to be entered in the compo, as the sprites are quite large, and require dynamic CHR-RAM. (The main character alone, stood at about 56 pixels tall!)

The project starred a nun girl with huge boobs, ripping zombies into chunks, with a metal chainwhip.
Gore is easy on the NES, it's just that nobody has bothered too much with it.

The mockup exists, only because I had read that "Splatterhouse: Wanpaku Graffiti" was made as a joke, and deliberately left out the gore, because they didn't believe that the NES could handle it. (Mighty Final Fight also exists, for a similar reason.)

I'd like to see it, though, if you're willing to share a link!

This.

To be clear, do all entries in both categories 1 and 2 get put on a multicart, or just exceptional entries?

In general all entries get included on the multicart, there isn't a judging score requirement or anything like that to get on the cartridge. Following the rules is generally all that's needed to get inclusion on the multicart. With the exception of judge's discretion for explicit content that was added to the rules this year.

If there are any issues with your entry that would prevent it from inclusion on the multicart entrants will be given feedback on what changes are necessary for inclusion.

The only entries to date that haven't been included were for specific reasons:
-copyright/trademark issues, entry contained audio ripped from NES games published by Nintendo 30+ years ago.
-entry was far from completion, this was actually my own entry and not much beyond sprite collisions with the background.
-entrant decided to withdraw their entry from the compo prior to completion of judging/awards.
-submission(s) that utilized mapper that wasn't supported by multicart mapper.

Does every entrant get a multicart prize, or just the entries that rank?

So far all entries to category 1 have been meritorious AFAIK. If your entry gets on the cart you'll certainly get a contributor copy.

Have the rules been posted publicly yet with official announcement? I thought this was already done, but doesn't appear so.. Need to also make the compo official for NA'rs as we neglected to do last year..

http://nintendoage.com/forum/messagevie ... did=174593

Posted, but no response so far...

The "here" doesn't stand out very much. NA's stylesheet doesn't appear to style links with underline, distinctive color, or anything else conspicuous. This means wording is the only way to distinguish links from the rest of a post, and the reader might not know that the link is under the word "here".

Newbie question here, does it make a difference which assembler we use? I'm using NESASM3 currently and should have something resembling a game in a short while. It'll only be using NROM 128 as I have no clue how to set NESASM up for NROM 256.

Every type of game can be made with any assembler, if you understand how it works and also the structure of a valid .NES file, so you can tell if the output is what you expect it to be. Some assemblers have more advanced features that can make some tasks easier and more dynamic, if you know how to use them, but if you don't think you'll need such features there's little reason to go through the trouble of learning how to use a new tool and rewriting your code.

NESASM is disliked by some (me included) because it uses non-standard 6502 syntax for a few things (indirection, for example) and imposes some restrictions that don't always make sense for NES projects (e.g. PRG-ROM banks are always 8kb large, regardless of how the mapper you're using actually divides the PRG-ROM space), but it can still make any kind of game if you know how to manage these issues.

My assembler of choice nowadays is ca65, mostly because of its powerful macro system. You can even program support for entirely new assembly languages from scratch using macros (I believe someone implemented Z80 support, for example), that's how powerful it is. I make heavy use of macros to help me manage variable and function declarations, bankswitching, NES headers, and lots of things that would have to be done manually with other assemblers.

There is no disqualification for using a particular assembler unless the assembler's quirks make the entry not run on authentic hardware, which I don't expect to happen very often.

In the past, I've had to reassemble a few entries to make them all fit properly in the cartridge. For LAN Master, 1007 Bolts, and Super PakPak, I made a Python script that converts another assembler's syntax to ca65 syntax. But that doesn't happen very often, and not at all for volume 3.

I'll be sure to look into ca65 for my next project in that case, thanks Tokumaru.

Are the resultant carts compatible with PAL systems as well as NTSC then? Just wandering

The Action 53 carts use a region-free CIC, though not all games automatically adapt their speed, and some games' raster effects may break on a PAL NES unless they're specially coded.

Cool, I'll be sure to test on my PAL NES in that case, thanks again XD

It's very easy to make software work on both NTSC and PAL. Things like raster effects and music are very easy to adapt on the fly. Gameplay on the other hand is not as simple, and because of this most games, homebrew or otherwise, simply play slower on PAL.

One trick (which was used in the NES port of Streemerz, IIRC) is to create the gameplay for 50Hz, and when running on an NTSC console simply skip 1 frame (i.e. don't run the game logic) every 5 frames. It worked pretty well apparently.

It works "okay", but it makes the game visibly jerky. I would have preferred if it ran smoothly, even if it meant a faster game.

I believe this made a noticeable difference in difficulty for me, playing on an NTSC system. Smoothness does make a difference when trying to time delicate manoeuvres.

I think the 50Hz framerate thing might have been partly chosen because of the original flash game, though, which did not run at 60 IIRC. (Most flash stuff did not for a long time.) Though also because thefox has a PAL NES?

It's a bit hard to choose between compromises like this, IMO. Do you want the NTSC version to be smoother but faster? Is NTSC too hard or PAL too easy now? Do you want to adjust the speed of everything so it plays similar on PAL? This kinda doubles your playtesting. The skip 1/6 frames compromise works, at least; it has its drawbacks, but they all do.

Not partly, it was pretty much the only reason. I wanted to duplicate the game mechanics of the original as close as I could. Had the original game ran at 60 Hz I don't think I would have worried about PAL speeds at all.

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?

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.

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

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.

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

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

Yeah, we don't want to be the guys with a 104-character password who include a (hidden) apology therefor.

Golden Sun and Zelda Oracle passwords were mighty long, but those were only used once, after completing one game and starting another.

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.

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

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



This does sound very good. Is there any other caveat, apart from limiting save space?

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.

Do the 1 sitting version now, then an expanded version later.

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?


That would at any rate be easier in regards to workload. It'll probably be this or some password related compromise.


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?

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.



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.

Hello. I might enter this year, but my current development is based upon an experiment to use CNROM's extra CHR banks for data. (I'm using 2 banks for patterns and 2 banks for map data).

The cart's mapper "emulation" of CNROM games needs the banked CHR to be copied to CHR-RAM, and this is not going to work with my game. Am I right? Unless there is 32K of bankable CHR-RAM which I believe there is not.

I can make an UNROM port if I have the time, of course.

I was planning a full-fledged UNROM64 game as well but time is tight this year. Let's see.

I didn't even realise the mapper requirements allowed any kind of banking. So you're technically bank-switching between CHR-RAM windows, and have to write to each of those manually?
Interesting idea, providing I'm not misunderstanding it, did any actual NES games use that method back in the day?

Which the menu does before your program starts. I added this feature to the Action 53 menu back in February to support Sinking Feeling.


There is.

Ok, so it's just plain CNROM then
So if I'm not misunderstanding, entrants potentially get a maximum of 32KB PRG-ROM plus up to 4 banks of 8KB CHR-ROM with a CNROM configuration?

"up to 64KB"

So, yes.

"32KB PRG-ROM plus up to 4 banks of 8KB CHR-ROM"

Yes. This is exactly what I'm doing.

We're going to see a lot of CNROM this time around

You actually get a maximum of 64KB of total rom, and there is 32KB of CHR-RAM. Although there are no suggested mappers that bank both PRG and CHR simultaneously. The real requirement is that it's compatible with https://wiki.nesdev.com/w/index.php/Action_53_mapper

I suspect the most sensible way to utilize the 32KB of banked CHR-RAM is to simply develop your game to utilize mapper 28 directly. Tepples will have to back me up on this. To submit the entry, you will have to initialize all the supervisor registers to get the desired banking effect. But that initialization will need to get stripped in the final version as the menu will take care of the supervisor register settings, and the game code can control PRG-ROM and CHR-RAM banking via the user registers.

If there's significant interest to utilize the banked CHR-RAM outside of abusing a CNROM config with it's underlying CHR-RAM, it might be worthwhile to settle on a simple homebrew "discrete" mapper design to simplify the rules and mapper specification for future compos.



With a limit of 64KB PRG-ROM bank bits would only utilize the lower two bits. Dedicating two extra bits would allow room for expansion if rules provided more rom, or rules were broken for exceptional entries. A simpler definition like this that also gained emu support would greatly simplify the definition of mapper 28 to something more tangible for development.

As I said, I can always port it to UNROM with ease. All I'm storing in CHR-ROM is map data which is only accessed screen by screen and unpacked to a one screen metatile buffer in RAM. It was an experiment and I was just wondering if it could go on the cart untouched.

But again, porting it to UNROM would be a piece of cake, really.

About your mapper specification, I think it's a great idea. It can be easily configured to act as anything the compo allows for and I guess less fiddling with the games should be necessary afterwards when building the multicart.

Yup.

I agree!

"data in CNROM CHR pages" is something I've done several times, it's much nicer than PRG banking, if your data fits the model.

You mean similarly to how SMB hides the structure of the logo screen in the last few background tiles of the CHR-ROM?

It's nice, but you can only use it while rendering is off, obviously.

It works for map data in flick screen games, for example

Another idea would be a third user mode that resembles three existing discrete mappers: Uchuusen (78.1), Holy Diver (78.3), and Color Dreams (11).

EDIT: I've moved my proposal to another topic.

What do these mappers allow that the other supported configurations don't?

Cleaner ability to incorporate these games into a multicart, because the game can get access to the full combination of banking supported by the CPLD (PRG ROM banking AND mirroring control AND CHR-RAM banking) without touching the "supervisor" register.

As lidnariq said, primarily a means to bank CHR-RAM, but also provide available features such as software selectable mirroring which most discrete mappers don't provide. By the looks of things there will be plenty of logic to spare if we continue to exceed 4mbit, so perhaps things would be simplified by permitting MMC3 or the likes. Probably best for us to separate the discussion of a new mapper for future compos to a different thread, as it detracts from this thread's discussion of the current 2017 compo to which we don't want to change the rules.

Continue new mapper discussion here.

For purposes of this compo, suffice it to say that if a mapper 28 program never writes to $81 save once at program startup, it should be patchable to work.

When/where can we start entering submissions?

I'm planning on having the details up tonight. I have been holding off since in the past we have had to deal with a bunch of resubmissions which can get cumbersome.

In a progress thread, this was briefly discussed:




My 2 cents: Basically same as na_th_an, but just to make it waterproof: How about we agree to not publish updated ROM:s from the compo deadline up until the judging phase has been concluded?

Elaborating: I think it's simply wrong to give the cart players a different experience to the judges. That makes it no longer a compo cart, but something tangentially related.

Naturally the current way sells more carts, and calling it "shiny fundraiser cart thing that only slightly resembles the competition entries" wouldn't sell well

I feel that most people who buy the cartridge have already played the released roms on the compo page. Releasing potentially buggy or less polished games on the compilation cartridge doesn't make sense at all. Also, most people who play these probably don't download all the interim releases leading up to the competition deadline/cartridge release.

Website updated. I kept the judging parameters the same since I don't feel like throwing any curve balls this late in the game. I kind of had a surprise baby this year lol, so that took a lot of my time so I didn't get a better judging system in place either. I've seen some really impressive stuff out there, so I can't wait to see what people HAVEN'T already shared.

Lets get those submissions in! Only one week to go.

For anyone who doesn't know, this is the official website...

http://nesdevcompo.nintendoage.com/rules/2017/

I'm still working on the website, but here is the complete archive for anyone who wants to check out this years entries!
http://nesdevcompo.nintendoage.com/files/2017/Category%201.zip

Second Christmas indeed, but for me, I consider it the best present for my 30th birthday.
I've basically kept myself from looking at any of the in progress threads, so this is going to be quite exiting to open this up and see what everyone's been up to for the whole year.

Is the site/voting making progress?

The voting surveys have been sent out. If you did not receive one (check junk folder), please let me know. The website will be finished tomorrow evening and will be posted Tuesday morning at the latest.

I got the survey link, but the "click done and be able to continue later" doesn't work. It doesn't let me in again, it puts up "you have already taken this survey".

That should be fixed now. Please let me know if it is working.

Yes, it's fixed. So safe to save & continue now.

I should really know better by now.... Took my laptop into work last night. Part way through, disk problems. It's been "Repairing disk errors" for 6hrs.

so, any update on the voting?

Just waiting for a few stragglers. I'm sending out the final notification today. Feb 28th was more of a guideline. Results will be soon!

It's been 2 weeks. I'm officially logging lodging a complaint.

I don't want to belabor the point, but survey monkey calculates the totals for you. The results should be known. Could you at least give us an idea when the results will be posted?

The results are calculated through a combination of votes by entrants and special judges. I know people have been very busy so I haven't been pushing too hard to get the results in. If it isn't finished by tomorrow, I will call it official closed and post the results.

I appreciate your response.

I've been waiting for the usual screenshot/description page more than the results. Can't really go around linking to just the zip.

That will be posted at the same time, if not later today.

Can't wait to see the results!

Results are up! http://nesdevcompo.nintendoage.com/contest17/

I will have Paul get in contact with the winners!

Are you sure this is correct?
I honestly hoped for 3rd place at best...
Also, a bit minor thing(probably everyone noticed by now, but in any case): Wolfling screenshot is incorrect(shows alfonzo game).

Thanks for catching the screenshot error. As for the judging, I double checked, the results are correct. It may be disappointing, but if you compare these scores to last year, you will see that even last place this year would have gotten 8th place last year. Don't forget, everyone gets a cartridge for participating!

oh no, no, no.
Gruniozerca 2 is my, Mtee and Shirus entry
My best hope was to get a 3rd place, but somehow we got even higher, so Im not dissapointed(but shocked and surprised? yes!) ;d

It is quite impressive to see the level of polish and completeness that was on ALL entries this year. Wasn't expecting ya'll to top last year's compo, but you folks really did. I couldn't choose my favorite game, there were just too many great ones that were all unique in their own way. Seeing the use of 3d by a couple games is exceptionally impressive. Only spent a short amount of time playing each game so far, really looking forward to going back and giving each game more play time. I'm blown away by the entries each year and never see it coming, gets me pumped for the future!

Honestly I'm thinking we may have to step up our rewards/prizes to do the entries justice. I have a few ideas in mind, but curious if anyone else has input. I think it's safe to say the compo budget can afford a quite a bit more.. I'm not sure how, but it would be nice if we could come up with a better reward system as I don't feel the rewards for the entries that ended up in the middle range matches the level of effort put in by entrants. Most of those games could have easily won the compo last year IMO.

Also just my 2cents, Inherent Smile is one of my favorites of all the entries. I really expected it to be one of the top scores. Disappointing to see that not many judges agreed with me, but I think I understand why.

I came in fourth. Not too bad considering how poor that demo looks compared to what I've added to the game since the end of the compo.

man that's close!

congrats, guys.

Thanks! Dungeon crawling does tend to be an acquired taste, and the balance wasn't as good as desired.

Any chance (unless it adds a ton of work ofc) to get the voting surveys with the names crossed out? It'd be interesting to analyse something quantitative. Maybe there's some statistics webapp the results could be fed into.

I think this would be good info to share or at least make available if possible. Something else I've brought up in the past, but not sure how to remember of next judging is if we could have a free form for each entry to make *constructive* comments to the specific developer. I realize these comments are probably best placed in the individual threads, but I think the info would be more likely to be given if a simple means to provide it while filling out the survey if possible.

Congrats everybody for the results. They are impressive. This year has been impressive, overall. The level of polish is ashtounding.

I'm up for individual comments. Knowing what people liked or disliked about the games surely will help in the future.

Now I'll try to implement several of the suggestions made regarding my entry, trying to make the cart version top notch!

Is this anything like what you were looking for?

https://docs.google.com/spreadsheets/d/1RvsiO3pemxlZsJeZzCaBRPFgVPFkQ3JUv_-U1tMyZ8Q/edit?usp=sharing

That's a great overview, thanks! Might help someone come to conclusions to up their game next year, + could serve as a discussion basis for future compos (you seemed to be looking for one in the podcast interview?)

I was more thinking that each game submission is a sheet, y is judgement category and x is all the marks that merit got sorted lowest to highest. This keeps the anonymity of the entrants/judges but gives all the data.

I was first thinking about the raw judgement entries, but even with the names crossed out they wouldn't be anonymous because of giving oneself top marks.

Congratulations to all competitors!
Although there are many impressive games this year, my favourite one is still JamminHoney

Yeah, it caught me off guard as well. Honestly, just happy that the competition let us get exposure along with so many other great titles. It's good company to be in, for sure.

I'm super excited about what more Wolfling has to offer, and have added LightShields to my regular multiplayer rotation.

Honestly once i played Grunioźerca 2 i thought that this was the winner this year within minutes of playing.

There's a future NESmaker user who wants me to do a small commission, and i said that if he could donate $64 dollars to the competition fund i'll do it. He's asking where to.. do you have a paypal for this sort of thing, maybe? It's not that much but there could be more incoming eventually.

Hmm, I'm not sure about donations.. The only financial support of the compo I can recommend is for them to purchase an action53 cartridge. There isn't a dedicated paypal account for the compo, I'm not sure I feel comfortable with someone donating cash. Additionally, nesdev isn't it's own financial/legal entity so I effectively have to maintain the funds as a portion of own my business. It then starts to look like people are donating money to my business which isn't something I want to support nor give the idea that I encourage it.

I'm not sure there's still a means of doing so, but I would rather recommend donations be made to web hosting costs of nesdev or NintendoAge. Additionally there are a number of legitimate charities that could better use donations than the compo, there's a few out there which are gaming related as well and help children in need.

Above all else I don't want to give any reason for people to think there's a suggested/required donation to compete. So it needs to be clear that this is an arrangement between you (the developer volunteering time) and them (game development manager?). Trying to prevent it from looking like an arrangement between them and the compo is part of my resistance towards accepting donations.

I understand completely.


Oh yeah, definitely. But either way i'll refrain from going this route altogether if that's better. I could give him some donation alternatives (nesdev, na, shirus' charity) instead like you suggested.


As for other ideas, someone on that new nesmakers board mused that people would likely be willing to pay for an asm6 tutorial. Personally i wouldn't feel comfortable taking personal gain for anything like a plain tutorial when the knowledge is out there for free if you know where to look. Also almost everything i've learned is thanks to the efforts freeware culture. I do recognize that freeware has its limits at the same time - it requires a special effort and skillset seeking everything out as it is fractured and spread out, which is kind of out of scope for many nesmaker users or else they'd be using asm6/nesasm/ca65 already. So there might be a space for curated knowledge. Maybe a proper e-magazine (pdf, some 32 pages or something per issue) with illustrative figures and articles written with newcomers in mind would be a good way to help them. Maybe charge a suitable (ie low) fee per issue for the benefit of the community. I don't even know if it is feasible, but morals first: yay or boo? Also, let me know if you think ideas like these are a little too outside the scope of managing the compo economy.

To be honest making any NESmaker related/dependent plans is putting the cart before the horse at this point. It will be a several months before the majority of it's user base will be able to touch NESmaker. I wouldn't recommend anyone looking to learn 6502 assembly to pay for tutorials with all the high quality free resources already out there. Part of that is based on my feeling that it's more important to be motivated to learn assembly by actually doing it, than having a top notch tutorial. There's a significant difference between being motivated enough to pay something on the order of $50 to learn assembly, and being motivated enough to invest the time needed to learn it. There are lots of skills I would happily drop a couple grand to know like Spanish & Japanese, but none of that matters if I don't want devote the time to learning it. But if someone were to make a top notch tutorial which people valued it enough to pay for it, then more power to them. For something of this nature it probably makes more sense for the tutorial to prove it's value and effectiveness prior to investing in publication of it (especially when digital publication is near free).

NESmaker related projects aside, I'm always open to putting the compo funds to financing of projects which the community believes to be a worthwhile expense of the funds. In the end I don't feel my personal opinion carries much weight on it's own. What carries the weight is what the community wants to spend compo funds on. If there were a specific project in mind a way of getting this approval would probably be to list poll threads on nesdev & NA with the proposal specifics. I used this method in determining if we would be publishing action53 vol3 CIBs with traditional cardboard boxes, or bitboxes and it seemed to work out well.

On this topic, I think a donation to NA/NESDev to help with hosting was discussed at one time. Should we poll that, or is it a no-brainer?

Also, could someone with forum superpowers make a 2018 compo category. Time to start thinking about the future...

More precisely, i didn't mean for it to publish as a physical release at all (i don't see it being worth it for the same reasons you gave) but rather have it as a pdf zine since that requires no other investment than "just" time. Price would more likely be in the range of 0.99 to 2.99 usd depending on contents per issue. Maybe first issue free. It'd also have a clear % of contents dedicated to code modification tips/how to make the most out of nesmaker, which i think is more in line with what this crowd would want. Then the gain (if any) could be an addition to the fund. But if it's too thematically detached, i'll let it rest.

--

Last idea i had in mind would be to do a custom-painted cartridge and let it go on auction each year. Not much of an addition to the funds in itself probably but still something. Attaching an example of a cartridge i painted for persosnal use. Choosing colours and theme for such a cartridge could be based on that years' winner, maybe.

First off, I've sent out an email to cash prize placing entrants requesting payment info, so prize money will be going out soon.


From what I recall NA has an annual fund raiser for hosting fees, anyone know when that is? I've reached out to whoaman in the past, but it's worth doing again.

I'll put together another financial report ~month after action53 volume3 release. Not much has changed in earnings since the last report where we had ~$2k, only a few volume 2 cartridge sales since. We spent a close to $1k on printed materials for upcoming volume 3 release, and we're dropping ~$1k for cash prizes now. I purchased the sega/famicom bitboxes as well, but I won't count that as an upfront cost, I'll just bill it into the per cartridge earnings like I do with all other cart costs. So effectively at the moment we're probably pretty close to zero balance.

Moving forward I'm sure volume 3-4 and subsequent carts will bring in significantly more funds than volumes 1 & 2 did. To date vol 1&2 have funded the upfront publishing costs of vol 3, and prize cost of vol 4 which is pretty impressive IMO. We don't have a lot of spare funds at the moment, but that's due to the double whammy of not getting past volume released prior to next compo ending which falls on my delays in publishing. Not a big deal, that all will soon change with volume 3 release. I'm also going to be pushing harder to get vol 4 released prior to this holiday season.

So once I put out the post vol3 release financial report we can evaluate diverting some of those funds to hosting fees and such.

What do you mean exactly? Do you mean coming up with a 'special title' for volume 4?

I don't mean to diminish ideas like this but I guess I'm having a hard time seeing how some publication like this would tie in with the compo & carts. I guess part of it is, personally I'm not really looking for more ways to earn funds as the action53 cartridges earn plenty of money to fund the compo. If a project of that (or any) nature were in need of funding and the community wanted to divert action53 funds towards a separate project I'm perfectly fine with that. But I'd rather not have money coming back into the action53 funds as that would now be a whole separate business activity I need to account for and manage taxes etc.



I like the idea of the custom painted cartridge, but there are mixed feelings on auctions for limited edition homebrew releases. If we were to do an auction like this I would prefer the auction proceeds go to charity. The compo funds could cover the material costs and then donate the items being auctioned so 100% of earnings would be going towards the charity. I feel the action53 sales are more than strong enough to support follow on compos. I'm expecting we'll have excess funds that we'll need to figure out how to invest back into the compo and community as a whole.

Is this based on just the scene being larger, or?

Volume 3 has what amount to demos of a bunch of platformers that also had a full cartridge release. It also has the 240p Test Suite, which some people would buy to calibrate their TV or scaler even without much interest in the games.

Nope, I meant this. My wish has been fulfilled.

It's safe to say quality and quantity of games being coming from the compo each year, and being included in the cartridge has taken significant leaps forward. My projections could be wrong on this, but it's a pretty safe bet volume 3 and beyond will earn us more than volume 1-2.

volume1 was limited in it's earning potential due to the fact it was limited to 150 loose cart copies alone.

I believe volume 2 was limited in earnings because we opted to exclude a limited edition version making the clear copies available to contributors alone. That paired with the high cost of printed materials that was just barely recouped. On top of this it took a couple years from compo to publishing as we didn't have enough entries from the 2nd compo to fill the cart. This overly long delay didn't help sales IMO. Sales for volume 2 seemed rather low IMO, but I'm not too surprised all things considered.

Volume 3 is larger than both previous versions, and we'll be having 100 limited edition clear cartridges being sold to help offset the cost of printed materials. I expect we'll recoup printed material costs within an hour of release compared to ~1year after the fact with volume 2.

Volume 4 is on track to be 1MByte in size again, and the level of polish and depth of the games from the recent compo is much greater than we've ever seen IMO. We're finally getting into the annual rhythm we were after from the start and I'm expecting we will be able to publish this year's entries before year's end.

One idea I did have based on the assumption that volume 3 will easily outsell volume 2 would be to offer a discount for purchase of volume 2+3 bundled together. But I'm also not sure if this may conflict with intentions of releasing a compilation cartridge of all volume's titles now that we've hit the 53 mark. I may create a poll thread to gauge thoughts on this idea. I think it's safe to say people will be coming to buy volume 3 who don't own volume 2, and a bundled discount might be appreciated. Something like offering the CIB at loose cart pricing might be nice as we have a much more volume 2 boxes than we'll likely ever use.

Oh, i see. I completely misunderstood your call for ideas then. Basically i thought:
-if prizes need to increase to reflect higher scores/the increased level of quality over years, more funds must go in.
-for more funds to go in, more voluntary work needs to be done, or
-sales need to be increased or distribution costs cut somehow, ergo more work.

It didn't even occur to me that a53 might already sell more than before, haha.

Ahh yeah sorry about that I know realize how I overly assumed everyone else expected volume 3 sales and on would exceed past volumes like I do. Time will tell of course, but that's my current expectation.

One other item is we're publishing on 60pin famicom cartridge form for the first time with volume 3. This will be the first famicom cartridge release on my site, so I largely don't know what to expect from that. But will be interesting to see.