Interest in a nesdev coding compo?
Moderator: Moderators
I think the games should be maybe NOT be able to change the mirroring, but yet if you write a V game not a H game, the program to move the correct 32K to PRG-ROM and 8K to CHR-ROM (Or RAM maybe?) should also change the mapper for the game. That gives people more variety to make games with.
If we got a MMC1 cart with a 8K CHR-RAM mapped in, Games could either be switched to CHR-ROM or CHR-RAM, But lets make it not both. That was you either have more PRG space for a game, or you have easier animations but less ROM and CPU time. Thats one heck of a decision!
EDIT:
Well on NA, Dain said whatever it takes haha
Thats such a awesome site on Retro support for systems, it's scary how nice the community is. Nice to have a site like that to support such a contest!
If we got a MMC1 cart with a 8K CHR-RAM mapped in, Games could either be switched to CHR-ROM or CHR-RAM, But lets make it not both. That was you either have more PRG space for a game, or you have easier animations but less ROM and CPU time. Thats one heck of a decision!
EDIT:
Well on NA, Dain said whatever it takes haha
Not necessarily... The size of the game does not dictate its complexity. We often get that impression because the smaller games were the first ones to be made. At the same time ROM became cheaper, NES programmers evolved and made more complex programs, but one thing is not directly related to the other.Drag wrote:I think this would be more competitive if there were a size limitation. Not to mention, slightly easier to code.
Also, consider this: say I made the most awesome engine ever and all the code fits in 16KB, so I have 16KB left for data, and this might not be enough for a lot of levels. Using more memory would be much simpler than tweaking the engine and using all sorts of complex data compression to have everything fit in 16KB. Hence, smaller ROM != easier to code.
Still, I agree with the ROM limitation. Regardless of how easy/hard to code the games will be, everyone will be forced to design around the limitation, and it will be interesting to see how far each one managed to go with the same specs (or similar).
^^Indeed I don't think you'll really NEEd the extra space. Another reason to use nrom is to keep it a bit more fair across contestants. Someone might have never worked with mmc3 but will pretty much have to use it because everyone else uses it for its scanline counter, thus giving him an unfair disadvantage (altough I suppose you could chalk that up to skill) Now the judges could take this into consideration in theory...but in practice that could mean hell.
I thought we were judging on fun! 
Yeah NROM should be big enough for a game, I mean, 32K? Thats like 12000 lines of program.
I don't know, I mean, who wants to play a demo? If we do this, I am planning on doing Polarium, a NES port with as many levels as could be added wit NROM (Probably hundreds).....Thats my title, I claim it
Yeah NROM should be big enough for a game, I mean, 32K? Thats like 12000 lines of program.
I don't know, I mean, who wants to play a demo? If we do this, I am planning on doing Polarium, a NES port with as many levels as could be added wit NROM (Probably hundreds).....Thats my title, I claim it
Well how would we consider the coding as part of the compo instead of fun? Going from 2K to 4K and 8K classes is ALOT of space and program difference, shouldn't it be the best game made as based by others rating? We could make the best coding every (The awesome text box demo for instance) but nobody wants to play that, it's more of a program to show what could be achieved if something is amazingly well and would smash others games....Idk I just think fun should fact more in then programming finess.
Taking volunteers to be judges is the same as public voting, just with an extra layer of bureaucracy (and seems very arbitrary too). In extreme example with public voting, making a game based on internet-memes would be the only way to win.
I believe it would be best if the judges were the ones who are sponsoring the prizes (and like I said before, the contestants themselves - just not allowed to rate their own entry or do sabotage-style voting). I could chip in something.
I'm still not convinced the ROM size limit is all that useful.. I believe if someone is skilled enough to really make a large original game, firstly they probably deserve to win, and secondly I'm 99% sure they could still win by crippling the game to fit into 40kB (making it a 'demo version' basically). When it comes to code complexity, there's a point where the ROM size doesn't matter. 32kB of code is HUGE, like 65024U pointed out, around 12000 lines of source. So the size limit is doing nothing more than discouraging extra data - music, graphics, levels, and such, and that kind of sucks. Still, I'd be fine with going along with a 40kB size limit, I just don't think it will affect the voting results at all (if it's not a public vote).
I believe it would be best if the judges were the ones who are sponsoring the prizes (and like I said before, the contestants themselves - just not allowed to rate their own entry or do sabotage-style voting). I could chip in something.
I'm still not convinced the ROM size limit is all that useful.. I believe if someone is skilled enough to really make a large original game, firstly they probably deserve to win, and secondly I'm 99% sure they could still win by crippling the game to fit into 40kB (making it a 'demo version' basically). When it comes to code complexity, there's a point where the ROM size doesn't matter. 32kB of code is HUGE, like 65024U pointed out, around 12000 lines of source. So the size limit is doing nothing more than discouraging extra data - music, graphics, levels, and such, and that kind of sucks. Still, I'd be fine with going along with a 40kB size limit, I just don't think it will affect the voting results at all (if it's not a public vote).
How about we start a topic on forums so that people could post their scores and then there won't be any cheating (Clearning browser and voting again and such) I think that would be the closest to fair, but then others may influence the vote if others read through it possibly.
Well I would like to chip in but really don't think I could :/ 16, No job.....I may do something though later, just not now :/
Well lets see what Jero has up his sleave for this games rules and then we'll just go from what he says.
And I doubt anyone can make any more then 6000 line game engine in a month with music and level data included?
Well I would like to chip in but really don't think I could :/ 16, No job.....I may do something though later, just not now :/
Well lets see what Jero has up his sleave for this games rules and then we'll just go from what he says.
And I doubt anyone can make any more then 6000 line game engine in a month with music and level data included?
My treefiddy:
- Memblers pretty much said all I had to say about size limitations already. The only reason I see for such limitation is if we want to get a multicart produced. That said 32K is a LOT, for me it would be quite hard to fill all that in couple of months I think.
- There should be no limitations for using pre-existing code (impossible to control)
- Releasing source code should be voluntary and IMO the entries shouldn't be judged based on quality of the source code.
Oh yeah and I can donate $3.50 for the prize.
- Memblers pretty much said all I had to say about size limitations already. The only reason I see for such limitation is if we want to get a multicart produced. That said 32K is a LOT, for me it would be quite hard to fill all that in couple of months I think.
- There should be no limitations for using pre-existing code (impossible to control)
- Releasing source code should be voluntary and IMO the entries shouldn't be judged based on quality of the source code.
Oh yeah and I can donate $3.50 for the prize.