nesdev.com

Did we say we want this to be an annual thing? If so, we have only a few weeks to get the next one rolling. I suggest a few rule additions:

• The main category is for games. In the past, judges have found it difficult to judge entries that aren't games. Thus tools and toys should go in the free-for-all category even if they fit the mapper and size requirements.
• Excessive padding is discouraged. For example, an entry's 10 KiB of PRG data shouldn't be strewn across a 32 KiB PRG ROM; it should instead be packed into 16 KiB. Nor should a CNROM have two CHR ROM banks that are less than half full; NROM with $2000 switching is usually better for that situation. This helps ensure more entries can fit on the multicart.
• The blurb should contain instructions for the multicart menu to display. This is up to 16 lines, each roughly 28 characters long.

Can I impose?

Since we had troubles with uninitialized values, maybe we should insist on a standard INIT routine, so we don't have to do a dozen error fixes.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

I like tepples' suggestions. As for what dougeff suggests, I'd rather ask explicitly for all RAM and VRAM to be properly initialized for an entry to be eligible to be included in the multicart - unless the mentioned INIT routine is designed to be easily portable.

I'm in, of course. We are planning a nice vertical scroller with several levels

_________________
http://www.mojontwins.com

I've been talking with Frankegraphics recently about multiplayer games on the NES. With the increasing AVS popularity, including its native 4 controller ports... and the relative lack of quality 4-player games on the NES, having a themed focus for 4-player games could be really beneficial.

A53 vol 4 could become the go-to suggestion for party games on the NES, especially considering the marketing abilities of "volume 4" being the one known for 4-player games.

Moreover, the judging problems associated with comparing multiplayer games with non-multiplayer games would be taken care of by having all competition category entries be multiplayer. As for judging issues, coordinating some netplay schedules could be helpful, especially if a larger base of other players were brought in through a thread at NA or whatever.

_________________
www.mteegfx.com

I think we need to be cautious of having overly specific requirements of technical and/or game style demands from entrants.

Initialization issues are extremely common, and we're always going to desire some compressing. Having good documentation on do's and do not's for developers to review when questions arise is always good. Just don't want to make a big deal about it to the point where it might deter new developers from submitting entries. If we go to the point of demanding technical items of this nature I think we'll scare people away especially if they're not as experienced.

I think it would be much more beneficial to provide guidance, or perhaps boiler plate code that does perform suggested startup. Going about it in tone of here's some help, and code you're welcome to use is more inviting. Compared to stringent technical requirements a novice may not even understand which could make them feel they don't belong.

Perhaps a good time to direct entrants to the technical list of dos and dont's is after they submit their entry and are awaiting judging. Allow them to submit their efforts even if they haven't made time to compress their entry yet. Having these things well documented to avoid having the same conversation multiple times should make it easier for all.

I have a hard time imagining a successful compo on par with last year's if we require all competing entries to be 4 player. Making 4 player a requirement still doesn't make judging them easier. In general suggestive themes haven't worked out for us in the past in the form of sub-compo either.

Something to keep in mind is that we probably will be hitting our 53 game target with this compo. I think we actually hit 53 entries last compo, but I guess tools don't count. Anyway, if there's something specific we have in mind for the big cart, probably good to address it this compo.

Overall last year's compo was a great success on many accounts. I'm of the mind that we can copy paste last year's rules, etc for the most part. And make sure we announce it on NA, as that was the biggest real issue we had. If there's something that needs changing lets get it addressed. But the direction we were looking for is to have an annual schedule that can be copy pasted from one year to the next. Without letting deliberations on what we should do this time drag on to the point where they delay the compo.

That's my $0.02 take it or leave it

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Maybe this was already addressed in the A53 thread, and since I don't know how the A53 mapper works, this might be a dumb suggestion.

But if initilization is such a big issue, would it be terribly hard for the A53 menu to initialize all 8 RAM pages and relevant registers to zero during its routine for starting up a game?
While this of course differs between emulators, it's my impression that almost all initialization errors tend to assume the value to be zero.

I too see value in exploiting the 4 ports on an AVS and Analogue Nt mini. Here are a few games on previous volumes that are for 4 players or have been updated to be so:

• Super PakPak is on volume 2.
• Spacey McRacey is on volume 3.
• NovaSquirrel has an updated version of DABG.

Perhaps what discouraged entries to the 2014 sub-compo was the size limit. Or we could tweak the prize structure, giving the highest-scored sub-compo winner a first place prize in that category and awarding the main first, second, third, fourth, and fifth place prizes as if the winner of the sub-compo had not entered. Does NintendoAge have members who have competed in game jams and can add thoughts about multi-category competition?


There are a few entries on volumes 1 through 3 that are not fully baked, to put it mildly. That's why I want to have the remix compo as at least a side deal before we release the all-in-one anthology.


Initializing almost everything is practical. Initializing absolutely everything isn't.

The menu needs to set the outer bank, inner bank, game size, and default register (CNROM: CHR bank; others: inner PRG bank), and jump to the game's entry point. The last of these need to be done in RAM because the menu bank is no longer visible. And I can't make code in RAM clear itself; it's not like loading an SPC700 saved state (.spc) on the Super NES, where the last steps of the process can execute out of the I/O ports. Would it be enough to clear nametables, clear $0000-$00F7 and $0100-$07FF to value $FF, and leave eight bytes of code at $00F8-$00FF?


Another thing we could try is to provide a stand-alone version of the ROM builder, so that a developer can test how a game will behave when added to a collection. For this, I might need someone's help with py2exe.

Eh, even if there had been such a rule, it's not like it would have changed anything about Sinking. The space was going to be used by larger title graphics, health issues prevented that, and I was in such a bad shape I couldn't have changed the mapper and packed things more tightly without breaking everything.

Edit: Also, seems contradictory with the call for filler with so much unused space

Now that we have CNROM support, it's not quite as important for CHR ROM as it is for PRG ROM. For PRG ROM, I can fit two NROM-128 entries into one 32K bank using the autosubmulti script, which (ab)uses UNROM (2) and UNROM (180) to mirror 16K into both the top and bottom halves of the bank.

I don't think it should be an explicit rule for submission.

Nobody submitting wants to have bugs in their program, but there's a lot of things someone needs to learn to make a valid NES program. If you're new to the NES, there's a lot of stuff you're just not going to be able to catch your first time. Submitting it to the compo is a peer review process, and a learning experience.

We caught these initialization problems easily, at an appropriate time, and I think in a way that was helpful to those who submitted. Compo rules, on the other hand, aren't very good teaching material.


(FWIW, I think the more common bug category was PPU access outside of vblank.)

While I agree with others that limiting it to 4-player games might be bad, I've been thinking a lot about trying to get a separate 4-player party game multicart going. I also envision a "party mode" where it cycles through one round of each game, keeping score of the various winners. You'd have to get the authors to agree to add hooks for this mode, but I think it'd be an awesome use of the 4-player ports.

Of course, the hard part is finding enough people that want to contribute




As someone who used the compo as a motivator to make my first nes game, I agree. It was helpful to submit first, fix later. (Of course, it would have been much easier if I had just gotten my powerpak earlier so I could have tested on hardware before submitting. I was surprised at how many errors didn't show up in fceux)

_________________
My games: http://www.bitethechili.com

The use of multiple emulators during development it's highly encouraged, because even if none of them are perfect, just the fact that they disagree with each other on the output should be a big red flag.

As for the compo, I play games mostly by myself, so I'd probably have a hard time thinking of something for 4 players, I don't know if any other programmers are the same. Not that the NES is particularly suited for that many simultaneous players in the first place, considering the ridiculously tiny number of sprites that can be in the same scanlines. Anyway, I guess it's OK to encourage the development of multiplayer games, as long as that doesn't push developers away.

True, 4-player is listed in Limitations. But perhaps the idea is to contrive game rules to keep all four players from lining up horizontally. Case in point: Warlords ran on a system with even fewer sprites. Or use 8x16s, like Smash TV and Spook-o-Tron. Or use 16-pixel-wide characters and no other sprites, like Super Sprint and Bomberman.

Really, I'd go all out and just say test on hardware. One of my bugs didn't show up on any of the 3 or 4 emulators I tried



We discussed this at some length in my thread for Spacey McRacey, where my opinion was that some of the fun was, like you said, contriving game rules that work despite the limitations.

_________________
My games: http://www.bitethechili.com

I don't agree with the limitations page on the subject of 4 player "party" games. There are plenty of ways to implement these kinds of games without any of the issues mentioned being a problem at all.
That said, if I were to actually participate this year (around 30% chance maybe....) it would most likely be a single player game, as that's the only thing I could realistically playtest on a deadline.