We finally did it. While the game was already finished in November 2016, all the other stuff took some time, but now it's available:
"City Trouble" for the NES by Den Kat Games.
Attachment:
City Trouble.png [ 165.21 KiB | Viewed 5637 times ]
The game is published by Mega Cat Studios and can be ordered here:
https://megacatstudios.com/collections/ ... ent-systemA big thank you goes to the users of this very forum. You helped me with a lot of NES-programming-related things.
You gave me the idea of using the nine sprites overflow bit as a second scanline split next to sprite 0, so that parallax scrolling and a status bar was possible without timed code.
You improved CC65's random number generator.
You explained me how to implement jump physics.
You helped me optimizing things in the early develoment phase where my lack of low-level experience put me into situations that made the game unplayable.
And much more, especially regarding Assembly code and NES-specific details.
Without you, this game would have not become the way it is now.
Thank you.
If you have any questions about the game, just ask me.
Edit:
Video of gameplay from level 2:
www.youtube.com/watch?v=Eee0yurkIW4
Cool! Glad to see it released.
I saw a pic of a German magazine with it, what magazine was that?
It's the current issue of the German Retro Gamer:
http://i67.tinypic.com/345o108.jpg
After some difficulties and the necessity to stop the sale, the game is finally available again:
https://megacatstudios.com/products/cit ... ent-systemIf anybody already bought it and got the inferior version (crappy box, crappy label, board with incorrect mirroring), please write to the publisher so that you get a replacement.
What exactly was the issue with the boxes and labels, if you don't mind my asking?
The boxes were created by a company that didn't do a good job: They were too thick and looked quite crooked when put together. Also, the colors were too powerful.
The publisher used another company than the one he usually uses because they were able to create them quicker since I wanted the game to come out early.
The new boxes have the same quality as their other ones: Thinner, better colors and a shiny surface.
The artwork on the labels looked washed-out and the material bubbled up.
Also, there were graphical artifacts that I thought was by the printing process, but then I found out that they resized our template file with nearest neighbor technology, so that single pixels are duplicated.
The second label, from another company, had the colors not staying in place.
Also, they changed our template file without notifying us.
(It was marginal, but I still notice this kind of stuff. And changing my files is a big no-no. They are supposed to inform me and then I'll send them a new file.)
In the end, we took the first company again, but this time the company agreed to print the labels on better, professional material that you usually only get when producing a whole lot. But I guess it was a compensation for their labels bubbling up. And this time I had the publisher tell them that they are not allowed to resize or change anything in the file at all, not even a single pixel.
And this one finally seemed to have worked as you can see in the new screenshots.
Now that the game has been out for a while, I'd like to know what people think about it.
So, what did you like, what didn't you like?
Besides, I'm not one of those people who only wants praise and who is pissed at any negative words. If you have criticism, you can tell me in a direct way.
Since you asked for it, why is there no digital (rom file) purchase option?
Not everyone is a "real hardware purist" or a collector, i just play games.
I was actually talking about feedback on the game, not the business model. But o.k.
There is no digital purchase option because I assume as soon as I offered it, the game would be leaked on the internet.
I will eventually release the game as a free-to-download ROM, but until then, I prefer to only offer it as a cartridge because otherwise, I could just make it freeware right away.
I don't think so, "boxes on shelves putters" seem to live in a pretend world without emulation.
And without a rom nobody can start working on a nude patch...
Maybe you could release a 1 level demo rom? With a picture of the cart package at the end!
For example, i played the legends of owlia demo in an emulator, and bought the game on steam.
If you wrap it in ggvm like Owlia, the ROM can't be extracted from it.
maseter wrote:
For example, i played the legends of owlia demo in an emulator, and bought the game on steam.
"Legends of Owlia" is a huge game, so a demo makes sense.
This one here is a small highscore game. Complexity-wise, it's comparable to "Kung Fu". Demo versions don't make sense for these kind of games.
If you want to know whether this kind of gameplay interests you, the following video should suffice:
www.youtube.com/watch?v=Eee0yurkIW4maseter wrote:
And without a rom nobody can start working on a nude patch...
If anybody's really that desperate to wank to a 16 x 36 pixel sprite, I guess he doesn't necessarily need the game. He can just as well alter the sprite in an image file.
Here, have fun.
Attachment:
Amy.png [ 1.4 KiB | Viewed 2987 times ]
calima wrote:
If you wrap it in ggvm like Owlia, the ROM can't be extracted from it.
This might be an option. I'd first have to check out how this works, though, since GradualGames said that customization is necessary.
The other way, because you wrote it in C, is to keep the game logic and write a new display engine that uses good old SDL.
tepples wrote:
The other way, because you wrote it in C, is to keep the game logic and write a new display engine that uses good old SDL.
Meh. That won't happen.
I didn't do a clear separation of game logic vs. display logic simply because such a separation would take too much CPU time away in an NES game.
For example, the current animation phase of a character is stored as a pointer that points to an array that has all the actual PPU tile numbers for drawing that character plus palette and size information.
The current animation phase in the game logic isn't just an ID which the drawing logic uses to find the drawing data in a lookup table. The current animation phase is an actual pointer to an array of NES-specific data with numbers that refer to pattern tables and palettes.
How should I convert this to SDL?
Should I create the drawing logic as actually puzzling together 8x8 tiles and coloring them on the fly, even though in an SDL game, each character animation phase could be simply stored in a full bitmap file?
Or should I change the meta sprite definitions from a data array to an SDL_Surface (or whatever is used for that)? This way I would have to fiddle with actual variables in data structs that also store purely logic-based things.
Same with the background: The way each slice of a house looks like is actually stored with the corresponding tile values.
And palette information is stored with the NES' specific layout of palette data where one byte stands for a 32x32 pixel area on the screen.
And for drawing tiles anywhere on the screen, like the title screen artwork, I use the first two bytes to actually specify the current drawing starting address of the PPU. I don't specify the x and y tile coordinate of a background tile, I specify the actual PPU address for it.
In any case, porting the game to the PC would not be just cleanly switching out some of the low level files and keeping everything else the same. It would require manually editing stuff in several different files.
Or it would require the drawing logic to behave like the NES PPU.
DRW wrote:
If anybody's really that desperate to wank to a 16 x 36 pixel sprite, I guess he doesn't necessarily need the game. He can just as well alter the sprite in an image file.
Here, have fun.
Well, if you insist!
I had a few minutes to kill before bed, so I roughed out a quick sex loop, in an approximation of your sprite style.
I was going to mock up a full scene, but ran out of time. It's also rough around the edges, but... meh.
Here's an external link, to the GIF on Imgur: (NSFW!)
https://i.imgur.com/5Vvtnne.gifEnjoy!
I can't believe it. He actually did this.
Don't let my graphics artist see this image.
Without the other elements, you may interpret the character as changing to a flesh coloured overall and banging her head though. May work as a head butt move.
I've got a question to the people who bought the game:
Has anybody played the cartidge on an AVS? If yes, have you experienced the problem that you can start the game, but once the level starts, the character cannot be controlled?
John Hancock made a video about our game:
www.youtube.com/watch?v=13_lHMATrt8And he experienced this very problem on the AVS.
My graphics artist tried it on her AVS and there was no issue. And I have never seen anything like that on a real NES anyway.
So, now I want to find out whether it's a compatibility issue with the AVS (maybe only for older revisions) or whether John got a faulty cartridge or whatever else is possible.
Also, did anybody of you ever experience this issue on a real NES?
I don't have an AVS. But, logically... if this was a common problem, I would think you would have had complaints from more customers.
I would have this person send it back to you, and then locate someone nearby who has an AVS. (If you're in Germany, I know at least 1 person there who has one)...and see if it's an AVS specific problem.
In the moment, my primary suspicion is AVS revisions.
John's AVS is from the first batch.
Both, my publisher and my graphics artist checked the game and didn't see the issue. My graphics artist's AVS is definitely from a later batch.
I wrote a mail to bunnyboy about AVS revisions.
If he tells me that they improved the nine sprites overflow bit behavior, then this might be the solution because that's exactly the rarely-used, obscure feature that I need to do parallax scrolling, so that's probably where the game freezes if the feature isn't properly implemented in the console.
Since the music keeps playing (music update happens in every NMI, even if everything else in NMI is skipped because the game logic isn't ready yet), John probably thought the game didn't freeze and it's only the controls that don't work.
If it was a cartridge problem (Pretty unlikely, why would faulty hardware produce section-specific input bugs?), I would simply let him send it back to the publisher and let the publisher test it.
Does the customer have a PowerPak? And are there up-to-date test ROMs for the sprite limit bit?
I don't know whether he has a PowerPak.
For the ROM, I could probably create one.
The current thing that I asked him is whether he would be willing to update the firmware on his AVS.
if sprite overflow is the problem, perhaps he has the 16 sprite per scanline option selected?
But shouldn't the sprite overflow bit still be triggered at nine sprites, independent from how many sprites are actually capable to be shown on screen?
Somebody just confirmed me that it's indeed the AVS 16 sprites option.
DRW wrote:
But shouldn't the sprite overflow bit still be triggered at nine sprites, independent from how many sprites are actually capable to be shown on screen?
I think at least Nestopia does not trigger it at 9+ sprites (which I always lamented) if extra sprites are turned on, if you want something to test with.
Thanks for that information.
And yes, this actually was the reason why the game freezes on some AVSes.
Weird that they would change the behavior of the flag when configured to display more sprites, since that could break existing logic.
IMO this should be a visual change only, specially when the sprite limit is eliminated, not increased. But even changing the behavior so the flag only gets set when the increased limit is broken doesn't really help.
I imagine it would have been very tricky to have the OAM evaluator process both the normal OAM fetch pattern, which is required for increasing the sprite limit, and the pathological diagonal fetch pattern, which is required for accurate sprite overflow flag behavior. I guess the firmware could have treated "9th secondary OAM slot filled" as an approximation of the result of the pathological diagonal fetch pattern when the sprite limit is increased.
Yeah, that's true. You can't easily "break" the evaluation process like the original PPU does and still fetch extra valid sprites.
