Space Race

You guys have inspired me to start work on my first nes game. It's going to be pretty simple compared to the other entries, but having the competition deadline be a motivator for me might help me finish! My goal is a 4-player party-style game, a sort of space shooter/race combination.

It doesn't look like much yet (I'm learning as I go, and don't have a lot of time per week to put into it), but the fact that I have almost 6 months gives me hope!

(And thank you, Tepples, for your nrom template on your website, that was really helpful to use in getting started the first time)

I see 4 scoreboards. I hope you don't plan to do a 4 player mode, that would be very hard for judges to test.

"I see 4 scoreboards. I hope you plan to do a 4 player mode, that would be totally awesome because there are not enough 4-player games available!"

Corrected that for you.

An emulator with netplay?

Are there any NES emulators with netplay as robust as that of games using GGPO, with transparent rollback and reemulation if Internet lag causes the received presses to differ from what was guessed? It'd require saving a state every frame, but I imagine that with only 10K of RAM in compo-eligible games, keeping a log of the past quarter second of saved states would be practical.

I'm absolutely planning for it to be 4 playered. You can play with 2 or 3 instead, although the game is primarily designed to be played with 4 players.

I didn't realize the competition was geared towards single-player games only.

Two-player games are fine.

The only problem with 4-player games is that it's relatively hard to come across a NES 4-player adapter.

Make whatever game you want. Maybe somebody has a 4 Score. I don't. I don't even have 4 controllers.

Nope. Or none that I know of.

But our community (tecmo super bowl) has been using nestopia with p2p kailerra for years for netplay. You get very smooth 60FPS emulation with anywhere from 1-5 (2-4 most typical) frames of lag depending on where the two players are playing from.

If one person has a high or "spikey" latency problem then you get the dreaded FPS slowdown or temporary "freezing" as the emu+kaillerra is waiting for the inputs to arrive before continuing with emulation.

If there were more 4-player games you might

(I bought one awhile back, but have always been disappointed at the low number and low quality of the 4-player games available)

I don't think it is geared towards single player games, it's just easier to make a single game compared to a multiplayer game (at least in my mind).

Agreed. I've always felt this peripheral was under utilized. I'm often hanging out with more than one friend, and there are very few 4-player NES games worth playing. I remember playing with my brother and two cousins when I was a kid and the only games I really remember for it were Super Off-Road and Super Spike.

Slightly different system but my favorite use of the multi-tap is probably Secret of Mana, granted it's not always easy to find two friends with enough time to play through an RPG cooperatively. I also liked the addition of multiplayer for FFIII (IV) even if it's only two players. With a game format like that, adding a second player is minimal effort for the possibility of a great enhancement to gameplay.

Although I'd suggest having a single player option for sure as this is probably the most frequently used gameplay mode.

Apart from obvious flicker if all four characters get on the same line, being able to tell the four players' characters apart is part of it. All three ways have limits.

1. Palette swaps: Four characters use up all four palettes, leaving no room for anything else on the screen.
2. Not palette swaps, CHR ROM: Four characters use up all four MMC3 sprite tile windows (2-5, mapped at $1000, $1400, $1800, and $1C00), leaving no room for anything else on the screen.
3. Not palette swaps, CHR RAM: Four characters animated at 15 fps with 128 bytes per cel (the Battletoads/Haunted: Halloween '85 solution) use up all the VRAM update time, leaving little time for anything else on the screen. Because player-controlled characters are less predictable than NPCs with simple AI, the predictive double buffering method used in HH85 is less effective.

Using a TurboTap, Team Player, or Super Multitap on the fourth-generation platforms is more effective for a couple reasons. First, the memory controllers on the Genesis and Super NES have DMA to rapidly copy in all four players' cels. The TurboGrafx-16 CPU has block transfer instructions to do the same thing. Second, the TurboGrafx-16 and Super NES have eight or more sprite palettes. The big limit is that coprocessors in Super NES cartridges (notably the Super FX) draw too much power to be used with the Multitap, as do specialized controllers such as the Super NES Mouse.

Wait, what will happen if you have the Multitap and a Super FX game in at the same time? Will it fry the SNES for trying to draw too much power, or is there like a circuit breaker in it? (I don't know too much about electricity... )

I just hope the SDD1 doesn't draw too much power, because that's the only chip I've considered using.

I'm going by what I read in Fullsnes, and there's probably something in the official developer's manual about it. But you probably don't want to risk burning out the Control Deck's voltage regulator over time.

The other practical problem with 4-player games is that you might not be able to find enough willing players nearby once you've graduated from the after-school use case. It's not like PCs and modern consoles, where Internet play is the norm. I had enough problems finding play testers for RHDE: Furniture Fight, and that was only 2 players.

Well, it's kind of forced to be at this point...

This just involves designing your game around the limitations. Mine is going to use all four palettes, but that's ok based on the full design. I also might end up using different sprite graphics for each, but again, I don't see it as a limitation.

I'm not even worried much about flicker. The game design means if all four players are on a scanline (ie 8 sprites) there won't be any other sprites there at the same time.



We old people might not play as OFTEN, but finding players shouldn't be hard. We had a blast last time my friends came over and played Atari Warlords and TMNT Arcade (on mame). We were looking for good 4-player nes games to play, and were disappointed. Plus, I want more old-school 4-player games to play with my kids.

This is possible for some games, not for all. Anything with projectiles, for instance, would have had to both make the projectiles player-colored and use tiny 8x16 pixel player characters. Or they could just delay 4-player mode until a sequel on a less limited platform.


Are you referring to 16-pixel-wide sprites with no projectiles or 8-pixel-wide sprites with one projectile each?


The problem is that they have to be both local and retro gamer friends. Nowadays, "friends came over" can mean hundreds of dollars/euros/pounds in airfare and lost wages due to unpaid leave. Or you might have found local friends the majority of whom happen not to be gamers or who exclusively prefer 3D games on modern platforms. Or perhaps my failure at subconsciously learning to find local retro gamer friends as an alcohol-shunning adult with no car and a mild case of autism is an edge case. Should we revive a topic from last year about finding play testers for a multiplayer NES game?

That's my point. 4-player mode isn't tacked on, it's designed based on the limitations of a 4-player nes game.



Or 16-pixel wide characters with projectile(s) that travel vertically (faster than the players), so you will never have a character and it's projectile(s) on the same scanline


I realize my statement made it sound like just because I could find friends to play, that you should also. That wasn't intended, and I apologize if it sounded that way. That being said, in my experience, they don't have to be retro game friends. it's less about finding people who prefer one type of game to another (retro vs modern 3d games, gamers or not gamers), and more about managing a social event. Because I enjoy retro games, I'll plan a social event around playing some retro games. My friends will come for the fun and social interaction, not just because they like retro games (some do, some don't). The harder part is just making friends at this age. It generally requires having a Third Place. Not having a car can make finding a Third Place harder, (I guess shunning of alcohol might as well, but most of my friends either drink very little, or are teetotalers -- it all depends on the nature of the crowd and the Third Place) and asperger's could make it harder to develop those friendships within the third place, I guess.

Either way, there will be people for whom it will be difficult/impossible to find friends to play this game with. They aren't my target market. I'm my own target market

Oh man, between a 4th child on the way, and then deciding to buy a new house, I'm not sure I'm going to get this game into the condition I'd like to be able to submit it. It's all working, but I really hoped to add AI so you can play 1-playered. (Currently, it's multiplayer only.)

From testing, it's fun with 3-4 players, but not sure a multiplayer-only game with mediocre graphics will do so well...

Even if it's multiplayer-only on initial release, I plan for there to be a remix compo focusing on improving past entries.

Thumbs up. Good idea.

Sounds good.

Although I'm more likely to start on a new bigger-scoped project after this one. The goal of this was a small game to get used to the NES quirks. Next, I might start on another 3-year journey to try to make a larger-scaled adventure game. We'll see

The idea of the game seems good.
Does a schematic of a discrete logic multitap exists?

Famicom multitap is astoundingly simple:
Simply connect an ordinary controller to D1 instead of D0.

NES multitap isn't too hard if you can build all-new hardware and don't require being able to plug in existing controllers. (nesdevwiki)

It's still not that hard if you do want to use existing controllers, but it requires an actual schematic (as well as donor sockets).

Well, I found this post at NintendoAge of a guy trying to expand the fourscore to also "switch" D3 and D4:

I think this can be modified to work as a original fourcore, does it?
I also have read about a signature fourscore sends to the NES, so, maybe the circuit above is not completelly apropriated to simulate a fourscore, but can be used as a base to do so.

A guy have made a 4 palyers Bomberman game for NES.
It can be found here, at the games section.
Seems nice and he shares the source.

Unfortunately, that schematic is missing the requisite signature bytes that games use to detect the Four Score. You'll need to increase the counters from 4 bits (each half of a '393) to 5 bits, use 74'153s instead of 74'157s, and add two shift registers.

But it's pretty close.

Well, I managed to squeeze in some mediocre AI, so I think I just might have time to finish up and submit it. Looks like my powerpak isn't going to arrive in time for proper hardware testing though :-/

Like others have said: I'd love to ear any specific feedback about my game. (Spacey McRacey -- the title changed along the way). I know it's a pretty simple silly game, and I'm quite content with where it ended up compared to so many amazing entries, but post-mortum feedback is always helpful.

Thanks!

I really enjoyed it. It is a simple design that works extremely well. The punchy music is just what the game needs. The game is frenetic in action and still let some time to rest between stages. Even the competition's ranking is not bad: the only multi-player game to beat a single-player game!

If we have to find bad points and become pedantic on details:

• Rules are not explicitly stated: as I read the blurb I do not know if it is hard to figure out
• It is not clear that 1-player mode exists: the title screen says 2-4 players and nothing blinks when adding the first to say that it can be started

Oh, and if you want to see somebody (my wife and me) play it: https://www.youtube.com/watch?v=s2nRzuzp_GA&t=360s

Thanks for the feedback!



Yeah, that's what one of my local playtesters said. I haven't figured out the best solution yet (a wall of text won't help. Maybe an animated example at the beginning would have been better)


You're right. The 1-player mode was a last-minute addition. I should have made it more clear.

I appreciate your thoughts!

I noticed in a hex editor that you used 18K of the 32K PRG ROM, and there's a whole bunch of repetitive stuff elsewhere in PRG ROM. Is there a way you could trim 2K off to fit in NROM-128?

I'll see what I can do.

Some quick spot checks and counting show me a few hundred bytes I can easily shave off by removing redundancy. 2k might be tricky though unless I cut a song, unless I'm missing an obvious chunk. I'll look further.

Updated version that (I hope) properly clears nametables at the beginning. I'm in the middle of a move to a new home, so I haven't had a chance to test this as well as I'd like....

So this is really bizarre and I can't even begin to imagine what the bug is.
When I play this on fceux, there's background music.
When I play this on console via Power Pak, there's no background music, but yet there is sound effects!

Usually the only differences I ever see between emulator and console are scrolling jitters and corrupted palettes and tiles due to writing to an active PPU outside of vblank.
But in this case, an entire chunk of logic is somehow skipped over, and without affecting game play.

The game uses "Main thread only" with NMI just incrementing a flag, this also uses a sprite zero hit scroll split.

if I wanted to debug this, how I should begin?

Using FCEUX's "Config > Ram Init" option, I find if I initialize RAM to $00 the BGM plays, if I initialize to $FF it does not.

I don't know if there's much to debug beyond that, but basically this ROM does not appear to initialize most of RAM, aside from wiping its OAM upload page at $0200, and also clearing ZP. Thus, many variables end up being used before having been set to any specific value.

(I personally like to leave FCEUX's RAM Init option set to "random", and strongly recommend initializing as much of RAM as is practical at startup.)

Edit: I just realized the "Ram init" option is not in 2.2.3, it's only in more recent interim builds: download page

Ugh, I've spent the last few evenings trying to get my new PowerPak to work. I've been through 2 different CF cards and 3 different computers, but it can never get past "loading game"....so I've never tested it on real hardware yet



Good catch, thanks Rainwarrior. I tended to initialize variables in subsystem-specific init routines, but never did a full wipe of RAM, which I guess means I missed some memory needed by the music engine.



Yeah, I guess I need to do that. Thanks.

Attached is a new version where I attempt to clear ram. I'll try on my powerpak in 2 days when the new CF card I ordered shows up. JRoatch, if you happen to try it before then, let me know.

Thanks for catching that bug.

It would be this, I'm embarrassed that I didn't try this. Thank you.


I'm not sure if anything changed in this. It still does not initialize $0300-$07ff and behaves the same as before.

I've made a simple IPS patch that will fix is by initializing RAM.

patch source:

Now that I'm off work, I can take a look tonight. I added code to do just what your patch did. Maybe somehow I uploaded an old version. Thanks for your help and I'll take a look further here.

Derp, I'm a moron. I had a stupid off-by-one bug in my clear loop that made it exit after the first time through. New version attached.

If the file menu shows up, I'd expect the CF card to work as well. Make sure some other problem is not causing the loading to fail (like missing mapper files).

Yeah, I tried a few times to reformat the card, re-download and extract the POWERPAK directory (tried both 1.34 and 1.20), and then launch the demo nes rom included in that directory (as well as other rom images). Same issue. Both CF cards were ancient tiny cards, so I've ordered a new one which should arrive tomorrow. We'll see if that makes a difference....

How tiny were they? If at least 120 MB, you could try reformatting them as FAT16 instead of FAT12.

32MB

But if it boots and you can use the menu then surely the problem can't be the CF card, right?

Well, got my new CF card today. It works with it. I think the problem was the CF card somehow.

That said, ugh, my game has problems on real hardware. Flickery stuff where the background jumps around improperly. sigh.

Sounds like what I'm seeing now: all sorts of scrolling jitters. Any advice or tricks for finding where I'm messing it up? (Other than just buckling down and examining everywhere I write to PPU?)

If it's PPU writes outside of v-blank...

In FCEUX, open the debugger, click back on the game, press the back-slash key, will pause it at exactly the start of v-blank. Press the 'run line' button a few times until one of the things says Scanline: -1 (or scanline: 260, I don't know which)

Now set a breakpoint for writes to $2000-2007. Click back on the game, press the back-slash key again. If any writes happened during the frame it will 'break'.

Repeat a few times. (May have to double-click on the breakpoint while you hit the 'run line' button and double-click on it again when you want it to work) Shouldn't take you more than 5 minutes.



If it's not PPU writes outside of v-blank. Perhaps you are just forgetting to reset the scroll after some PPU write inside v-blank.

Thanks. Turned out to not be related to accidental PPU writes during rendering, but instead the timing of my purposeful PPU writes during rendering: my sprite0 mid-screen scroll. Not sure exactly what the problem was (none of the emulators I tried would reproduce it), but tightening up the timing of my mid-screen scroll code cleared it up.

There's still one error in the title screen where I do write to the PPU at the wrong time, which messes all sorts of things up on hardware, but that's unrelated to the scroll flickering I was talking about. (Interestingly, the powerpak lets me accidentally overwrite my CHR ROM at run time. oops!)

Thanks for the help, all. Still trying to wrap my brain around the quirks of the NES.

From another thread:



Does the powerpak actually do that? With the following header, Spacey McRacey has a mis-timed write to PPU that ended up changing my graphics in CHR-ROM on the powerpak. Is that to be expected?

PowerPak mappers do write-protect the RAM used for CHR when the ROM uses CHR-ROM, but the protection can fail if the write happens during rendering (it messes up the timing of PPU's memory control signals). I fixed this issue in PowerMappers.

Details at viewtopic.php?f=9&t=11339.

In addition, the Action 53 multicart engine uses CHR RAM, and I had to patch a few games on the first volume* to eliminate writes to the pattern tables. So I recommend fixing the corruption rather than relying on the cartridge to ignore it, because the production cartridge won't.


* Including my own, because I'm terrible.

Yeah, I definitely intend to fix it, the mis-timed write messes up some other things as well. Working on it tonight, hopefully will have a fix by this weekend.

Ok, attached build fixes the 2 timing issues that I was seeing on hardware (scrolling glitches, accidental writing to CHR-RAM)

Could you maybe add support for the Famicom 4-player adapter in the future?

Seems like a good idea. Do you know if there's an emulator that supports it? (I don't have one, so I'd need some environment to test with)

Unfortunately, I don't know what emulators support it, and it seems to be impossible to find schematics for it, which is weird considering it's just some wires connected to the expansion port. This would also make it easier to implement since it doesn't use multiplexing unlike the FourScore.
EDIT: Here's documentation for it at least. http://nesdev.com/ffpa.txt

Yeah, I found some documentation about how to read it, but without knowing how to test it, I'd be shooting in the dark. Do you have one that you could test with if I send you a build at some point?

Unfortunately, no. I have tried to get a hold of one myself, but haven't been able to find one, I might get one in the future though.

There's no schematic because there's no parts to it. It's exactly the same as the ordinary controller, just connecting players 3 and 4 to the (&2)s bit that's read instead of the (&1)s bit.

It also never existed as a "four player adapter"; rather it just adds two more players to the two built-in tethered controllers that are part of the Famicom.

Hori did make a version that turned the expansion port into 4 ports, enabling all 4 players to use their own controllers.

Then they bald-facedly lied. There is no way for player 1 to be connected to the expansion port, at all.

Are you really sure?

There is quite literally no way for an external peripheral connected to the expansion port to put bits in the correct place to be read as player 1 by the CPU.

The Famicom expansion port connector provides access only to player 2 ([$4017]&1), player 4 ([$4017]&2), three other pins used for other expansion port devices ([$4017]&$1C), and player 3 ([$4016]&2). There is no connection to player 1 ([$4016]&1).

Software could be written to read the extra controllers off one of the available pins that are there, but that requires a software intervention, not a hardware one.

For Famicom games that are only 2 player anyway, 1=3 and 2=4 as duplicates of each other, as per software conventions.

Has anyone looked at the 4-player Famicom games' controller reads? Maybe there's a redundancy for the missing J0 bit 0?

(It's also entirely possible that the Hori adapter doesn't quite work as advertised.)


Edit: Here's one of the Technos games, Nekketsu Koukou Dodge Ball Bu:

So... appears to only pay attention to bits 0/1, and I would not expect this to work as claimed with 4 controllers in the Hori adapter.

Also looked at Kunio-kun Nekketsu No Soccer League, which is the lastest-made Technos game in that list, and it was the same. The only non-Technos game on the list was Wit's, but it also appears to only read bits 0/1.

So... no, the Hori adapter should not work as it claims, to the best of my knowledge.

FCEUX for Windows supports Famicom 4-player. Famicom games for 1 or 2 players treat controller 3 as controller 1 and controller 4 as controller 2.

In Config > Input, do this:

1. Change Famicom Expansion Port to 4-Player Adapter
2. Change Port 1 to Gamepad and click Configure
3. Change Port 2 to Gamepad and click Configure

Speculation I: If the Hori thing does actually support four players, then perhaps it's like the Hudson Multitap: two controllers while strobe is 0 and the other two while strobe is 1.

Speculation II: The diagram shows the built-in controllers being disconnected. Perhaps at least input 2 works when built-in controller 2 is internally unplugged. Who can translate the Japanese?

The games I mentioned above do not do this. Everything is read while strobe is 0. Only 8 reads of each of $4016 and $4017. Only the low 2 bits are used.

android translate says the left is
"When using a genuine controller"
and on the right is
"When using an optional controller"

The rest of the text on the box either doesn't get OCRed correctly, or is irrelevant.

[PowerPak]
yup. More so on Ludicrous Speed or when there're shots on screen.

Fun enough on one-player. Are powerups supposed to persist between stages? They do…

edit: oh, and I got some weird CHR corruption on title when I touched the NES to change to another game. A mistimed write hit the blank tile with some nonblank maybe? Or could just be something hardware.

Did you see those problems on the latest version?. I fixed all the issues that I saw when running it on the powerpak. (I haven't yet put the newest fixed version on my own website, so if you downloaded from there, you have an older version that still shows these bugs on hardware)



No, but the 2nd round (Battle Round) starts you with all the attack powerups, which might make it seem like they persist? (you should be back to a single shot with a long cooldown when you get to the ludicrous speed round)

Yeah, everything works nicely now.

How many kinds of rounds are there? Standard, battle, speed, kamikaze…

There's 5. The four you mentioned plus one with a really narrow Hall. (I forget what I called it, will have to look it up later)

is it perhaps "Trench run"?

Other simple notions of modes:
Sudden Death: no respawn, win on points
Last Ship Flying: no respawn, win by surviving
Deathrace: no respawn, 10-20-30 bonus points for being second/3rd/4th eliminated (/surviving) (Alternately implementable as starting with 30 and penalizing 30-20-10 for 1st-2nd-3rd eliminated)
Reverse

That would be better than what I picked: "challenge round"



Those would be interesting. Although you die so easily, that the round might be too short. Maybe giving a life limit (ie 5 lives) would work better. Sounds like a fun idea though.



Does that mean going down instead of up? Or something else?

Down, yeah…with the ships still facing up, and still shooting up, but having bumper to down (so, sort of like kamikaze)