Newcomer to NES programming

I was bored, and decided to test my pixelling skills, with a somewhat extreme restriction.
1 128x128 page of 256 8x8 tiles. For an ENTIRE game.

I now want to program this into a working ROM. So I have been brushing up on ASM, and doing general research.

How exactly do BG tiles work on the NES? I have read that sprites can be flipped, both horizontally and vertically, while BG tiles cannot be flipped.

If this is the case, do BG tiles NEED to be 16x16, or can 16x16 metatiles be defined with pre-flipped versions of the 8x8 tiles? I am unsure about this, and my reading has not gotten me any futher in the last 5 hours.

I am willing to expand the tileset as needed.

That's correct.


The default palette boundaries for the background are 16x16 (so only one background palette can be used per 16x16 pixel area), but this does not affect which BG tiles can be placed where at all. BG tiles are 8x8. A 16x16 area can be any 4 BG tiles, even if all 4 are the same. It's worth planning out your tiles based around the palette boundaries, but that's all.

Since a horizontally flipped BG tile takes up an extra tile regardless of if it is identical to another except flipped, you may as well make a "flipped" tile asymmetrical. Edit: I guess the exception to this is if you're using CHR RAM and want to save PRG space. Still, the flipped tile will take an extra tile in CHR memory.

So what you're doing with a lot of stuff won't work using just one set of 256 tiles for both sprites and the background. For instance, in the mockup you have a tree drawn with a separate tile for top left and top right, but only the top left of the tree exists in the set. You would also need a top right tile to draw it because BG tiles can't be flipped.

Alternate (more detailed/technical) answer: BG tiles can't be flipped by the HARDWARE the way sprites can. BG tiles can be flipped in software, and as long as your entire "set" (where each flipped tile still takes away from the total number of tiles) is less than 256 tiles. Even if you flip them in software, you still need copies of flipped tiles in the set in memory basically.

There are 256 BG tiles in memory. You can just store flipped copies in ROM, each flip counts an extra tile of the 256. You can flip in software, each flip still counts as an extra tile of the 256. Same result, different process basically.

Edit: What you're planning on doing with the text window has potential to mess with the level palettes. As stated above, the default background palette boundaries are 16x16. Your textbox is 3 tiles tall. (Top of textbox, row with text, bottom of textbox.) This means the row of tiles either directly above or directly below the textbox will become the textbox palette. (Or the textbox will be drawn as the level palette.)

Here's an image I made demonstrating this (Note. The image is scaled 200%):

If the textbox isn't alligned exactly with the 16x16 pixel palette boundaries, either part of the textbox will be drawn with the level palette, or part of the level will be drawn with the textbox palette.

In the gif, the top of the textbox is always 8 pixels below a boundary, so every time it crosses into a new 16x16 boundary by growing left or right, the top part of that 16x16 boundary ends up with the textbox's palette.

You may as well expand both things. 256 separate 8x8 tiles for sprites, 256 separate 8x8 tiles for the background. This is what Super Mario Bros./Donkey Kong use and they both use no mapper. (That is, their cartridge does not allow them to access more data than NES supports by default.)

Edit: Optimization of Cat
If you move two of the right facing sprites up, they're now identical to the first right facing tiles and can be removed. Then all front facing tiles that are flipped are removed.

The moving of the sprite tiles up to make them match wouldn't affect gameplay at all. You'd just draw those animation frames offset down.

Ah, it's good to know that's correct.



Hmm... I kind of figured that would be the case.



Huh. I hadn't thought about sprite optimization. That's not a bad idea. I could do that for a few other sprites as well.

The 16x16 palette rules, is why the water is green below those platforms. I added that textbox last-second to upload to my art gallery, for mock-up purposes. I will fix the sizing when I program it.

If I'm understanding you correctly, something like this would be more acceptable for the NES specs?
My art canvas palettes may be a bit confusing, so I've included my CHR file, this time.

Ah, geez! Now I need to design more enemies. Auuaaagh! I have TOO many tiles, now!

Yeah, that all works. Again, it's worth making the flipped tiles asymmetrical for that sweet extra mile.

Edit: Your sand is clever.

Small things:
1. Your 0(zero) and O(Letter O) are identical. So... you only need one.
2. You only need one sprite tile for what I assume will indicate current location on the minimap. Sprites can be placed arbitrarily, and the two you've got are identical beyond the spacing.

One last thing to note. You probably know, better to say than not if you don't, though.

You get 4 background palettes/4 sprite palettes on screen at one time, but there are no limits beyond that. So if you wanna make every dungeon a different set of colors, you totally can. Or you can make the spiders Red on some screens or whatever.

All in all, would be a pretty graphically impressive NROM (no cartridge to extend NES capabilities) game especially with the many enemies you now have graphical room for.

Your graphics look really good! Even with the intention of saving tiles, it still looks better than any NROM game I can think of.


Kasumi already explained but I just wanted to back him up: palettes have to be placed on a 16x15 grid, but tiles can be placed anywhere in the 32x30 grid.


It seems you already have, and since using 512 tiles still doesn't require a mapper, the game is still as simple as before, technically speaking.

Another important thing is that only 256 tiles can be addressed at any given time for the background, but sprites can come from both pattern tables if they are 8x16 pixels in size. While that means more sprite pixels on screen, it also means your ability to reuse sprite tiles is reduced, so think carefully before deciding on which sprite size you'll use.

Also keep in mind that you can change which pattern tables are used for which purpose (background or sprites) at any time, even during rendering. This means you could, for example, use a sprite 0 hit after the status bar and change which pattern table is used for the background, in case you want to put tiles for another kind of environment in the pattern table that's currently only being used for sprites. It's true that having text in the middle of the screen makes this harder, because you need the alphabet available at all times. Anyway, I'm just saying this so you keep all the possibilities in mind.


That actually worked out quite well, because it looks like transparency, and you can still see the platforms a little bit before the water gets too deep.


As long as you keep it within the limits of NROM, it will still be quite a feat.

I tried for... two hours, to try adding zelda-like doors to the dungeon tileset. I succeeded. But the tile restrictions made the side doors look terrible. I scrapped them. I'll just keep free-form dungeons, and block off boss entrances with... retractable spikes? Stone slabs?

I have redrawn most of the tree, to make it asymmetrical, as suggested. I will re-pixel the shrubs, later. Also, I shifted the entire tileset, to make the extra space, more easily accessible.



While sorting I also optimized and "stripped" the sprites, with an attempt at coding their metasprite data. Am I on the right track with this? Or is something horribly wrong with it?

If you are planning on using 8x16 sprites (and there are reasons both to and to not), you'll need to lay them out such that a vertical pair of sprites is subsequent in the table (e.g. the top half is pattern 0, and the bottom half is pattern 1)

It's a bit tedious to fix this up, but is a bit of a distraction from more core things (like "finishing the sprite tiles" or "writing an engine")

The new tree looks really nice!

It's not tedious at all. It's very easy to just re-order the tiles for 8x16 during whatever export/build process you're using. It'd only be a few lines of python script, for example.

Man, this looks spectacular! All you need is a solid art direction to make a nice looking game, though better hardware could be nice. Which reminds me, what is the potential size of an NROM game? Could this game have the same length of, say, Zelda with just two banks of graphics data? Of course graphics data has little bearing on a game's length, I'm talking about PRG space being sufficient enough.

I'd love to see this on the next Action 53 multicart, perhaps as the highlight game.

40KB. 4KB for sprite tiles, 4 KB for background tiles, 32KB for everything else.

Harder to say. I'd be optimistic and say probably with a smart enough map format. Even if one can't get quite as long, one could still make a decent sized game.

The fact it looks like this just with NROM makes the original Legend of Zelda look notoriously bad.

It DOES look bad no matter what you compare it to. In fact, a lot of Nintendo's earlier titles didn't look very good, I don't think their art got better until, I think, Doki Doki Panic. I wonder what was responsible for everything looking blocky, possibly the fact they didn't have proper art software? I do remember reading that in the earlier days, people had to use LED panels to make up sprites, and some used graphing paper.

If I recall correctly, when making Donkey Kong it was Miyamoto himself who drew the sprites (thereby Mario's design, to make him easier to draw), so I suppose they simply didn't have artists at all in the first place =P But then again that art style was extremely common in arcades in the early '80s (where in fact it wasn't uncommon for a single person to develop the entire game), so I'm not surprised either.

The only criticism I have is that the dungeon graphics are really busy looking, so I have some suggestions:
Edit: Disregard this, check my later posts


This scene in particular was the busiest looking; there's just a lot of contrast and details everywhere.

The first thing I did was remove the highlight on the wall bricks, which toned the contrast down a bit.
Next, I changed the water to be more of a solid color. The water's really nice looking, so maybe changing the palette to replace the black with a blue would help, instead of wiping out the details like I did.
The floor bricks really stuck out to me in other screenshots too. I removed the green highlight, which made those orb objects stick out a lot more, but the blue of the bricks touched the blue of the revised water too significantly, so I shortened the brick height by one. However, without the highlight, the bricks looked too flat, so I played with the shadows a bit to bring the 3d look back. Even though a pixel of blue touches the water, there's still enough of a line left to separate the two tiles.

These are just suggestions, so take them or leave them how you see fit. The rest of your graphics look good.

I agree that this scene in particular looks kinda busy, but if he just removes details like you suggested the game will end up looking as dull as many existing NROM games. Maybe attenuating the highlights by messing with the palette will help, but flat out removing all the details like that doesn't do any good.

Or break up the highlights with a bit of dithering.

But make sure to try the dithering on hardware, in Nestopia, or in blargg's snes_ntsc preview tool* because the NTSC PPU's composite output does funny things with some dithering patterns. Which operating system does your PC use?


* Despite the name, "snes_ntsc" is also what you want to use to scrutinize NES graphics for possible artifacts because the NES PPU and Super NES S-PPU2 produce pretty much the same artifacts.

I have to agree with tokumaru- simply removing all the details might make it more playable, but removes a lot of the shine and sparkle that made it interesting.

Anyway, running the original scene through nes_ntsc shows the difference between tiles and water to be much more obvious:

Here's another where the water's intact, but with my other suggestions still in place. I've enlarged the floor bricks up one and right one to close the black gaps so the floor is bluer to contrast with the blacker water.

Though yeah, with a different NES palette, the graphics seem less contrasty, so maybe the palette was the problem all along.

Edit:

One last version, with the green highlight added back in.

The bricks on the floor HAVE to be thick, otherwise it gets hard to tell that they are surrounded by water. In your first edit it actually kinda looks like the water is above the floor, making it look like some kind of wall instead. The original shadows and highlights do a great job at representing the relative depth of the whole scene, I honestly wouldn't remove any of it. A few palette tweaks might indeed help with the contrast though.

That was my mistake, when I started having second thoughts about wiping out the details in the water, I should've stopped.


It looks like the palette's a little different here. Changing the colors of the floor and of the water definitely helps though.


My first suggestion is garbage, please disregard it. My next two suggestions show that the pattern can be reduced but still have detail. The water's texture is very turbulent, and the floor texture is only slightly less turbulent. By smoothing the floor texture out, the scene becomes easier to read. That's not to say that every single detail has to be destroyed, but some do need to be toned down, especially if all these high-contrast details are filling the screen. If the entire background pops out, it's going to be very difficult to place any kind of emphasis on anything else, short of making it blink or shake or something.

Anyway, those are my suggestions; a palette tweaking will help, maybe seeing some more scenes will convince me that that's all that needs to be done, but as of right now, I'm not entirely convinced.

Honestly I still prefer the original. Maybe the palettes could be tweaked, but otherwise yeah, I wouldn't change the graphics.

Also I can't be the only one bothered by the brick pattern interruption at the corners at the top, right?

After 10 hours of studying opcodes, and banging my head into a wall. I have successfully read from memory, and rendered out 2 8x16 sprites! :O

...Now if only I could make the 2nd sprite follow the first!

Apparently, the sprite indexes require being incremented in units of 4, or it'll overwrite another sprite?
I figured this out, through trial and error. There doesn't seem to any mention of it, anywhere, though.



Also, all the talk of Zelda 1 in this thread, made me wonder what a true Zelda-clone would look like.
So I mocked this up, to NES specifications. CHR included. Not sure what to do with these, yet.
EDIT: Switched the image, I indexed something incorrectly.



I'll try some palette edits, and see if I can reduce the issues, are apparently having with the tiles.



Oh yes. That is a problem I am aware of.
You see, I keep all of my work on a single canvas, including old versions of tiles, and I shifted the bricks on the wall when I was adding doors, to center them. When I scrapped them, and tiled over the mock-ups, I didn't notice the tile-shearing until later. My bad.

Sprite index would be in range 0..63, covering the 64 sprites that are available. OAM index is in range 0..255, covering the 256 bytes of OAM. That means 4 bytes (X, Y, tile, attributes) are used for each sprite in OAM.

Are you familiar with the MVC programming pattern? The basic idea is to separate the model and the view of your game world as much as possible. This means that pressing right on the controller shouldn't directly cause the X coordinate byte of an object's OAM entry to increase. Such hardcoded programming would make your code difficult to maintain, because everything is so stuck together that you can't make changes without affecting a huge part of the engine.

The model is the state of the game world, it's how the game is represented in memory. Things like level maps (including collision data) and objects (including position, speed, health, etc.) are part of the model. The view is just a graphical representation of that model, so that us humans can see what's happening in there, but the MODEL SHOULD BE ABLE TO EXIST AND FUNCTION WITHOUT A VIEW. Another interesting side effect of this design is that you can have several views of the same game world. This is what allows games like Doom or Duke Nukem 3D to be played in 3D mode or map mode. It's the same game world, only displayed differently. In Duke Nukem 3D there were also security cameras that would display other parts of the level, which is another type of view the game uses. None of this would be possible if the enemies were trying to draw themselves directly to your screen.

The NES is a machine with very limited resources though, so full separation isn't always possible. But sprites are certainly one of the things that should be abstracted from the main engine. Most games have a meta-sprite rendering routine. A meta-sprite is a list of sprites that represent one animation frame of a single object. So if your player uses 2 sprites at any given animation frame, each of his meta-sprite definitions will have 2 entries. Now, the main difference between these entries and the regular OAM entries, is that the coordinates of meta-sprites are relative to the object they represent, not absolute to the screen. There are many ways to optimize the space used by meta-sprites (automatic pattern increment - so that only the first index has to be defined, automatic coordinate increment of grid-arranged sprites, etc.), but for simplicity and full freedom each meta-sprite entry can be 4 bytes, just like normal OAM entries.

So, you have the player object as part of the model in RAM, and it has a single set of coordinates that specify where in the current room it is. When you call the mata-sprite rendering routine, it will loop through the entries of the selected meta-sprite and add the relative sprite coordinates to the object's coordinates in order to generate the final OAM entries that will be sent to the PPU later. This may sound a bit complicated, and it is at first, but once you have this routine ready, you'll never have to worry about manually updating 8 different sprites every time a big character moves... just call the meta-sprite routine and you're done!

Like I said before, this improves maintainability of your code. For example, if you decide to change the type of OAM cycling (since the NES can only show 8 sprites per scanline, it's common practice to rotate or randomize the OAM positions for all the objects every frame, so that all objects affected will flicker instead of some disappearing), you just have to modify this particular routine. If the sprite code was hardcoded in each object, you would have to revise every single object in the game, with big chances of missing something along the way.

Does that make sense? It may seem a little overwhelming, but the sooner you realize that math is more important than knowing what each opcode and register does, the sooner you'll be on the right track. You can always look up the documentation for opcodes and registers, but the internal workings of your game should always be clear to you.

So, what you're talking about, is a "state engine"? I've programmed some of those before.
I'm just trying to figure out some of the basic coding methods for this language, so I can get started on my game. I have such a structure partially planned out.

My previous programming experience is on the C64, and the Gameboy. >.>
(and some DOS work, for a German game design company.)

Blah... been sick. But I've been reading up on coding in that time. As of last night, I now have nametable data being loaded from a map offset! Metasprites are only partially implemented at the moment.



EDIT: Oh yeah, a question. On an NROM it seems that map tiles cannot be animated? Is this correct?
If so, I can save 8 tiles for something else... >.>

It's not possible to guarantee all tiles with a certain index can be animated regardless of how many times that index is used in the current nametable, no. To animate a tile on NROM, you would need to rewrite all instances of the index you want to change in the nametable with the next frame's index during vblank. So it's possible, but there are only so many nametable writes you can do during vblank. You'd have to plan around it.

Whoa! Nice graphics!

The detail on these tiles are great, and your foreshortening is just incredible! There's lots of personality in every tile and these would make for some incredible graphics on the NES.

With that being said, I'm really not a fan of your sprite palettes. The black on them works well enough on the overworld screens, but a lot of their details are swallowed up on the darker dungeon screens and they're a bit indiscernible with the NTSC filter. Also, I know it's been said many times, but make your tiles asymmetric! One good application of this would be your dungeon walls, which could have separate lighting on both sides to simulate a lightsource coming from the west:



EDIT:

On another note, how do I create my own NTSC-simulated screens? I know there's an nes_ntsc library out there or I could just load up a nametable into an emulator, but both of those methods are really time-consuming. Is there a standalone executable I could use to get some quick, dirty results?

You could use CHR-RAM with NROM to update a small number of CHR tiles each frame (as opposed to nametable animation), but this is not a common choice for NROM, since this requires you to use your very limited PRG space to store all CHR data as well.

Blargg's nes_ntsc library includes a really simple program called "demo.c" which is what I've been using. Unfortunately, I lack the tools to compile a windows build of it.

Aww, well that's a real shame. I was hoping there would be an NTSC filter out there that wouldn't I download an entire programming library just to run it. Thanks anyways!

There is a way to fake an NTSC filter using GIMP filters. I think I've explained it in another post.

Here, I build it for windows: http://forums.nesdev.com/viewtopic.php?f=21&t=11947

I have used up the entirety of the CHR!
I have managed 15 items, 11 enemies, and three bosses.

I wasted a full 14! tiles, from the 8x16 rule, which is unfortunate. I'm very tempted to go 8x8, and simply reduce on screen enemies in-game. It's not like this game will have scrolling! ...aside from the "screen flipping" transitions. Any opinions on this?



Here are the assembled sprites:


and some of my Nametables, so far:

So...what about the asymmetric dungeon walls or character palettes? Did those not work? Also, I can't help but feel the 8x16 sprites are really limiting your sprites. 14 tiles is more than enough for an entire 4-directional walking character! Not to mention, if you changed this game to use 8x8 sprites, then the space taken up by radially symmetrical sprites like the poof clouds could be halved!

Regardless, this is some really amazing stuff. I'm still finding it hard to believe how you pulled of a Minish Cap perspective using such limitations...

I hadn't been touching the palettes, or the wall tiles much up until now (the wall tile arrangement in the CHR scares even me!) I'll work on those again, once I have the sprites finished.

Though I'm not a fan of coloured outlines on sprites (HUGE oversaturation in the market, with that), I've been playing with the colours a bit.

I made the switch back to 8x8, and managed a few more items, two more NPCS, a new enemy, and a fourth boss sprite! I have 14 sprite tiles left, now. Not sure if I want another boss, or more enemies. My twin sister says I should make a snake boss. I'm not sure if I can pull that off with 14 tiles. >.>

Behold! A 32x32 flip-sprite boss! He's composed of 11 total tiles.


I prototyped an item menu today, and this is what I came up with:



(This is just BARELY to NES specs, with 59 8x8 sprites used)
Is it obvious that the layout was thought out, to keep to the 8 sprites per scanline, rule?

Amazing stuff as usual. I assume that you've already redrawn your ROM tables to reflect the new restrictions, but here's my shot at it...



The x's marked in red are the extra spaces I added. Firstly, for their side-walking animations, your characters can use the same head for both frames. And you don't have to add in the 1-pixel bouncing into their ROM graphics, because that can be done during runtime. So really, if you wanted characters with symmetric heads they would only need 12 tiles for a 4-directional walking cycle. You can also reuse the tops of heads for the swimming animations, too. It looks a little more stiff, I know, but the difference is so negligible the player probably wouldn't care.

As for the rest of your item sprites, I removed anything that could be rotated and for the cloud, I removed the bottom halves of those tiles because clouds are radially symmetrical.

As for your snake boss, my suggested approach is over on the left. You could have big 2x2 radially-symmetrical segments and then smaller 1x1 segments as you get closer to the tail. The head could be drawn using 8 minitiles so total, that's 11 minitiles for the entire boss...14 if you don't want your big segments to be radially symmetrical.

Oh, and sorry for the recoloring. I use a different NES palette than you with a lower contrast, so i had to swap the tiles to blue so I could edit them. I also probably missed a lot of tiles, so go ahead and check over them to see if you missed any symmetrical stuff.

I'm certain this was a terminology failure, but just to be careful: the NES does not support any kind of rotation except 180°, because that is a special case of the native "flip horizontally" and "flip vertically" operations that are allowed for sprites

Thanks, guy! I've been re-learning pixel art for the last 8 months, after a long break. (7 years!)
Yeah, I didn't think to include the current CHR this time. Oops! I should probably sort mine, to make it as nice as your example image! Mine's kind of a mess! I stripped out everything. (horizontal lines.)



Those extra Horizontal sprites for the weapons are actually required. While you can flip sprites, you may not rotate them. So an enemy such as the bone serpent in this future project, would require ALL of those frames, to be displayed correctly.:



Damn! I can't wait until I start using mappers!



Oh!!! I didn't think of making it look like the serpent from StarTropics! Thanks for the suggestion!



Recolouring is fine. My stuff's generally pretty high contrast. I don't think I missed anything.
I also pruned down a few of the enemy/boss sprites, by trimming off extra tiles, and redrawing some parts.

On that subject, I completed the sprite re-palettes, to make them more readable on my dark backgrounds. How are these?



I tossed some of them, onto the old mock-ups. To show the improvement. Better?


EDIT: Ah crap, I just got called into work for a few hours. I'll work on this later, here's the snake so far, with your suggestion.

Awesome, awesome, awesome stuff! Everything in your mockups blend together so well and your atmospheres are great! Have you considered posting your stuff over on PixelJoint?

As for the character palettes, I think they look really nice! And if you're afraid of "blending into the crowd" with palettes like that, why not use the old palettes for the overworld and the new ones for dark areas like caves and dungeons?

Oh, and that newest mockup is looking very nice! Your mixture of gray and pink in your character palettes is a very bold choice I haven't seen before. One thing, though. I can't help but feel that using only 1x1 blocks for your walls looks a little plain. Why not throw some 2x1 blocks into those patterns and see how they look?

SMB had some bad color palette choices. I could never understand why they chose a purplish blue sky, or give mario a brown shirt. Even given the palette it has, there were some BG objects that could've had shading, but don't, such as trees, grass and those weird things in level 1-3, etc.

General inexperience with art assets, I'd assume. That or it was infeasible to have artists or art directors, so all of these early "NROM" graphics could easily be programmer art. I'd also appreciate if we could drop this silly notion that NROM games can't have decent graphics.

I can understand why they chose that sky color though; it didn't look purplish on their TVs when they chose it (nor does it look like that on any TV I've played it on). As for Mario's colors, Mario's colors were chosen based on function rather than design, and it's possible they went with brown because they thought blue wouldn't work well against the blue sky in most stages. Also, they frequently couldn't decide whether his shirt was red and his overalls were blue, or if his overalls were red and his shirt was blue.

Yeah, that color is not purpleish on NTSC. Also his shirt is brown in order for his hair and moustache to have a decent color (although they didn't seem to care about that with Donkey Kong). But yeah, the art style could have been more consistent, it's a mix of flat, contoured flat and 3D-ish.

No. Absolutely not.
I have my reasons for avoiding that community.


Hmm... I may try that!


Those 2x1 blocks are the newest tiles for that set, I haven't decided on the mapping style for that project, yet. It'll be something along the lines of Knightmare II.

Hmm... While sorting BG tiles into metatile information, and creating a HEX reference grid, I noticed that 5 of the map tiles were redundant, if I assigned specific tiles into other sets. I used the extra space, to draw a cactus, and two graphics for bleached bones. The game now has a new locale!

Judging from the graphics, it looks like Cat Quest is trying to be the NES' Links Awakening. Not that it's a bad thing, I just wish the NES had games comparable to it.

I couldn't sleep last night, so have some concept art:


I'm really not much of an artist.

Are you kidding? I'm even more sold now than before! :3

Judging from the picture, is the character supposed to be female? And personally, I'd try to go for a more chibi-esque, less antrho style for the box art. Think something like VGCats.

I completely agree with OneCrudeDude. The image of a furry naked female-shaped body is a little bit disturbing and doesn't match the cuteness of the sprites. If you change that, I think the box art will be much more attractive.

My input on this...

Generally, when I think of NES box art, 4 categories of box art come to mind. I know there are exceptions, but here are my 4...

First, you have the old "black box" art for old arcade ports like Ice Climbers. Then, you have the cutesy Japanese box art for platformers like Mr. Gimmick. There's also the super-gritty box art for more violent games like Castlevania or minimalist, logo-only box art for RPGs like MOTHER and Zelda II.

The problem I think you have here is that you're creating an RPG/Adventure game like the Legend of Zelda, but the way you've drawn the box art makes it look like an action game or platformer. My personal suggestion would be to go for a logo-only design for your box art. It'll also make things easier to draw, since you admitted earlier you're not that much of an artist.

I think box art focusing on the character would be the most appealing, regardless of the style she'd be drawn in.

Looks like a good start. You look to have some artist skills.

Every classic children's show is disturbing? I rather like the Looney Tunes!
Plus, I used "Barbie Doll Censoring", to make it acceptable for general audiences.
The Sims did it, why can't I?! >.>


I tried to make the character look as care-free as possible, she has no idea that the world is soon to be in turmoil, and that she's going to be travelling into Tartarus to defeat the Algol once and for all.

Most wild animals have noticeably shorter legs than humans, including cats in Looney Tunes. Some of the "omg furry" comes when you make the legs as long as those of humans.


Sylvester, © WB

I don't think it helps, that I AM a furry artist! Haha.

Obviously, this is subjective, so some people will find it disturbing and some won't. I honestly don't remember much about the design of anthropomorphic female animals in cartoons, but yours has very well defined breasts and crotch, thick thighs and long legs, features I don't remember seeing in many cartoons for children.


Barbie dolls are still supposed to be sexy, even without pubic hair or nipples.


Didn't The Sims use pixelation for censoring nude characters? Either way, you can do whatever you want, it's your game. =)

Anyway, I'm not a puritan or anything, I just happen to think that the sexy animal thing doesn't fit with the mood of a top-down perspective quest game. The art looks out of place, specially since the sprites don't suggest any sexiness at all, and that characteristic doesn't appear to be relevant to the actual game. She is sexy in the box art "just because", and that looks kinda cheap to me.


That explains it. I guess it will be pretty hard to persuade you into toning down the sexy, then. =)

How about something like this? It captures the character's innocence and the unexpected task she's been given.

Sexy?! That's not what I was going for. Cute and carefree, was my intention. >.>



While that example does look nice, it looks far too serious for this character. That does make me think, to spruce up the logo, however! A gothic font would look very nice!

I've been having some computer troubles, which now seem to be resolved. Chrome is a terrible browser!

I've been porting over some tile data from a java-based dungeon crawler I was making over a year ago. Look how many CHR tiles are NOT being used! There's a few redundant ones mixed in, because I decided to change the mapping format slightly, to save some palettes. I'll find and remove those later.



The goal to this, is the ability to make dungeon layouts, like this:

That dungeon looks really good, probably better than most made for the console! Let's hope this dungeon crawler would be fun and not tedious.

Reminds me of the improved graphics that the Zelda Classic community have.

As for problems with a lack of innocence, let us remember the idea of innocence as a lack of knowledge, and the problem seems easily solved. (Might want to add a sword, though.)

Hi, made an account because this is looking great.



Here's the optimizations you can (choose to) make if you decide to go 8x8:
- Obviously the removal of symmetrical tiles, vertically or horizontally.
- As Kasumi says, you can remove the head tops for the right-facing sprites if you move them upwards and offset them down at render.
- As DragonDePlantino suggests, you may re-use head tops for swimming.
( You may not, however, remove 90* rotations. )
- The longer sword could use the "swish" effects from the shorter one. Just a loss of a line of pixels.
- The third frame of the "falling into a pit" animation could be replaced by the smallest of the three leaf/feather sprites.
- The fourth frame could be modified to also work as the smallest piece of the snake boss.
- Shaving the top off the bouncy gooey thing saves a tile, I've modified the shine to fit.
- Apply Ms. Felis's optimizations to the pigman.
- If you slightly modify the big horned pig monster's top tiles for his left half, you can use it as the top for his right half. I've made this edit (shoulder pixel).
- The bottom-right of the fire could be replaced by a flipped bottom-left.

(Choices) for the BG tiles:
- I personally doubt you'll ever need a semicolon, and probably not quotes either. Maybe even parentheses.
- You could conflate the S and 5 glyphs, along with 8 and B.

If you go with all of these changes, you will have gained 42 extra tiles: 37 sprite, 5 background.
The snake you made will take up 6 tiles instead of 7, leaving you with 31 sprite tiles. That's probably enough for 2 bosses or 5 enemies.

Many of those changes to the sprites were already added days ago. Check the CHR post on page 3.
The text ones just seem silly. I don't need new BG tiles.

Haha, well, it seems like I'm useless at graphics so I won't try again.
But I tried write a theme that an RPG like this should sound like.
There is some other music too I want to give.

I would have preferred to keep the digits 0123456789 in order and delete letters instead, so you use a 0 where O is expected, and so on. I also don't like conflating the 8 with B, though. However, it is your choice to design how you want it, to see what works best for your program.

Yeah, I thought about this as well, because then a number drawing routine can draw a number without having to resort to some sort of table (just additions). Even better, move digits before the letters, so you get 0123456789ABCDEF in a row which will let you print hexadecimal numbers in the same dumb way.

Oh! Don't feel that way! You went out of your way to be helpful, and I respect you for that!
I'd like to see what you could come up with on your own, for this kind of stuff.

I checked out your NSF file, you did some very nice work on that! :O



I was actually thinking about this, when starting on a text table. I finished typing the table in only 30 minutes, simple stuff. So it wouldn't be a huge loss to scrap it.

I've seen the text data to the top of CHR files in commercial games, if I were to do this, wouldn't I need to move the font?

The commercial games you're thinking of put digits at the top so that they can write hex digits directly with AND #$0F and LSR LSR LSR LSR without having to ORA or ADC to reach the digits section of the pattern table.

I would hope so! My goal is to make this play much like Dungeon Master, in that you can visually see the monsters patrolling the dungeons. I have the basic framework of a layout "renderer" somewhat started. The dungeon is stored as "screen chunks", that are written to the nametable. somewhat similar to metatiles, but they can be shaped differently.

Unfortunately, I had to remove the brick detail to make this fit into the CHR.




So it's a more optimal method, then? Good to know. I suppose I could offset the existing nametable data down by two rows. I tried it with the CHR of my un-started rabbit game, for testing purposes.



For those wondering why my imaged CHR, is often coloured, I use this unfinished program to test palette sets, as palettes can be dynamically applied, as on a nametable.

http://www.sun-inet.or.jp/~tkosugi/nesspr.htm

Those are looking really good! Are dungeon crawlers particularly hard to write on the NES?

I wanted to give some more nsfs: a rewrite of the last one, a short looping "underwater" theme, and a looping "menu" theme.
I will also give sound effects soon and more level type music.

I found cq3 just a bit short, and it might get on people's nerves. I extended it a bit for players' sanity.

Honestly I find cq2 to be way more annoying because of the instrument used.

I will note these, thank you.


Is the game planned to play like Zelda, with the classic dungeon system? It would be interesting to see how a linear game would perform.

I like cq4.ftm

Thanks! Dungeon crawlers are not difficult, if you're doing it right.
(Using an X and Y position to check a custom map array (Not the Nametable, that's dumb.), and draw graphics to the screen using a look-up table.)


Oh, wow! Amazing work Nameguy!
If you're serious about helping me with some music, I should probably compile a small list of what I would need for this game. (Freakin' Famitracker lags my machine, like crazy! So I've been unable to do anything.)

On the subject of sound effects, I've never done NES sound before, but I created this nice squeaky "hurt" sound for the player, in NovaSquirrel's nifty SFX editor. As I've at least had tracker experience, before. Not really sure how his sound engine interprets the data. >.>




Really? I rather like it. It reminds me of "bath" from Turrican II.


Cat Quest is planned to be much like Zelda 1, with 4 main dungeons, and a larger final dungeon. I've also been keeping my eye on the map memory budget, to potentially add Zelda 3 style caves, so I can "hide" the 3rd dungeon, up on a cliff, out of reach.

Approximate Map Budget: (all screen data is 16x12, with 16x16 metatiles, using RLE compression.)
Overworld 1x 9x10
Dungeons 5x 8x8 (Not all rooms are used, per layout)
Caves 1x 9x10? (Twisting passages, that can lead to other locations. Or just treasure grottos.)

Thank you. I'll guess there needs to be one song for each of those maps and the title theme? Does anyone know the maximum/average size of NROM music? SMB had 6 songs.

I entered that code into the SFX tool but I'm not sure if this is what it's supposed to sound like.

EDIT: Added "cave" attempt #1.

I'm not too sure about the music size in an NROM game, but I do know that repeated sections of songs can be stored as "patterns", and played back using a timer. Compressing the sound data a decent bit.

Hmm... That's about right. I could have sworn the pitch was slightly higher, but oh well.

How much music can you fit into 3K? Listen.

Having made Driar's NROM build: 40KiB of game consisting of: 8 KiB of music data, 8 KiB of music replayer, 6 KiB of CHR data, 5 KiB of main engine code, 11 KiB of level data, and 2 KiB for opening and closing titles.

Thwaite (NROM-128 with CHR ROM, 5 songs)

• 343 bytes sound effect engine
• 128 bytes period table
• 556 bytes music engine
• 983 bytes sound data, incl. music sequences, instruments, and sound effects

Total: 2010 bytes (12.3% of PRG ROM)

RHDE: Furniture Fight (NROM-256 with CHR RAM, 2 songs)
This uses a newer version of my music engine, supporting more effects such as arpeggio, instrument envelopes, and patterns with larger pitch range.

• 380 bytes sound effect engine
• 128 bytes period table
• 907 bytes music engine
• 1030 bytes sound data

Total: 2445 bytes (7.46% of PRG ROM)

This is not an "average" case for NROM music, though. MUSE (the sound engine used in Driar, written by me) is pretty generic and was not really written with non-banking mappers in mind, so it's typically possible to get smaller results with engines where the feature-set is stripped or configurable; or where you have the option of hand-optimizing the audio data.

Is it possible to estimate a minimum code length for a certain feature set?
For just vibrato, volume control and duty control (no envelopes)?

Damn! That is impressive for 3KB!


Hand-optimizing is what I was referring to, by the mention of sound patterns, as that's how tracker music works. Though, with trackers, they optimize the data for you. I've been optimizing the hell out of my map data, so optimizing sound doesn't really seem too daunting a task, at this point.

I've done this one pattern (two variations) using no effects or instruments. FT says the song data is 827 bytes.

Oh! Very nice! ...good job on the optimization!

I've been having some... problems, with optimizing the snake boss for 8x8 sprites. I've revised the sprite so many different ways, and it will STILL cause flickering. Ah, screw it. I'll make him a gleeok-ish dragon, that breathes fire.

I've been kind of irritated at my transition to 8x8 sprites, and while it does give me freedom to add more, it's a pain for ONE freakin' enemy! I did this mock-up of what an 8x16 mapper-based version of this game, would look like. Maybe one day...

Cat Quest 3!

Great job with the perspective! A lot of people fail miserably at representing perspective in a system that absolutely can't do accurate perspective, but this is very pleasing to the eye.

Thanks! I had actually drawn a much smaller 3x4 version of that house, for the NROM Cat Quest, until I realized that I could fit everything, but the house into the CHR. Oops.

A question related to my "future projects", which will remain as art projects for now. What is the most optimal mapper set-up for a bank-swapped homebrew game? Nothing fancy. Just extra CHR, maybe a few extra KBs for extra map data. I'm not really too sure. It would be helpful to know art-wise, at least. >.>

The most flexible is CHR RAM, and whether you use UNROM or something more complex depends on whether you want highly complex raster effects and whether you want save RAM.

I gave CHR-RAM a proper read-up, and wow! You can dynamically load tile data into a tilebank? I wasn't aware of that!

...and here I was, going to have copies of the Rabbit Knight from that platformer copied across each sprite bank of the CHR! Zelda II does that. That certainly saves me some graphical space! Also, good to know that, for the technically more advanced version of Cat Quest, as well.

No. I won't need fancy raster effects. Reading a compiled list, they do seem helpful, in some cases. But not something I would need. At least, not for anything at the moment.

The beauty of CHR-RAM is that, like any regular RAM, it can be freely modified. The only constraint is that you can't touch it while the image is rendering (the same way you can't touch other parts of VRAM), so during gameplay you're limited to changing the amount of tiles possible during VBlank, which aren't that many. At 16 bytes per tile, you can realistically update only 4 to 8 tiles during VBlank each frame while still having time left for other updates, such as sprites, name tables, palettes, and so on. During screen transitions, when you can disable rendering and keep the screen blank for a few frames, you have enough time to set up your pattern tables however you want.

BTW, most other game consoles (Game Boy, Master System, Genesis, SNEs, etc.) are always like that, with tiles stored in RAM as opposed to ROM, only this RAM is *inside* the console. For some reason (most likely to make the console cheaper), Nintendo chose to put this memory outside the Famicom. This made it possible for carts to use either ROM or RAM for tiles, allowing developers to use what suited their games better.


Then the best thing to do is stick to simple discrete mappers, like UxROM or BNROM, which provide simple PRG-ROM bankswitching and CHR-RAM.

Given that until then all consoles* either used registers or framebuffers (SG-1000 would use tilemaps and sprites, but it was launched the same day as the Famicom), it's not that surprising that the NES hardware has oddities like that. The NES was modeled after the popular arcades of the time, and those used ROM to store the graphics, so I would assume Nintendo used ROM just because that's what everybody was doing at the time. Why later systems modeled after arcades went with RAM I'm not sure, I guess that by then arcade ROMs became so big that it'd have been unfeasible to let console games require so much.

(*well, except the Vectrex which used vector graphics)

The TI-99/4 computer (1979-06), CreatiVision console (early 1981), and ColecoVision console (1982-08) predated the Famicom and SG-1000 (1983-07-15) and used the same tile-based TI TMS9918 series VDC as the SG-1000. The ColecoVision port of Donkey Kong is believed to be the direct inspiration for the Famicom, as 6502freak suggested in another topic.

The one drawback of CHR RAM for a beginner is that it's a bit harder to get Hello World up on the screen, but that's about it. And then UNROM, BNROM, or AOROM should satisfy you until you get up to needing save RAM.

So Zelda switches between mirroring modes (horizontal -> vertical -> horizontal) when panning screens. Is this possible with NROM? If not, would one have to go the Metal Storm route (fade to solid colour, move character)?
Zelda also has the advantage of SRAM. Would this need a password system? Presumably, formatted in a bit per dungeon completed and item found?

I've also started work on a sound engine. It won't get in the way and will be as short as possible.



If you make copies of that house, won't they all have their own vanishing point?

No.
No, there's several ways to achieve continuous scrolling. For example, instead you could accept color artifacts at the left/right edge of the screen, as in SMB3 or Kirby's Dreamland.
Yeah, that would be a way to achieve it.

No, NROM and the simple discrete logic mappers can't change mirroring. But using that for screen transitions is overkill, since it's possible to get even 8-way scrolling with plain old NROM without artifacts. You just have to figure out the best way to set up the name tables, considering the screen layout (status bar? top or bottom?) and the type of scrolling (vertical? horizontal? diagonal?).

Both the original Zelda and Cat Quest have a status bar at the top of the screen. The cleanest setup in this case would be to use vertical mirroring (i.e. name tables side by side), for complete freedom of horizontal movement. The status bar should be kept in one of the nametable only, freeing up some space at the top of the other one, which could be used for scrolling vertically.


In most cases there's no need to sacrifice scrolling. There's a lot you can do with plain old horizontal/vertical mirroring without even having to switch between them.


Long games surely need either battery backed RAM (some games are know to battery back the CHR-RAM! It's a cheaper way to get a few bytes of save data at the cost of a few tiles) or passwords. For passwords, in addition to the data being "saved", some space has to be spent on error detection. Tepples has done some work on passwords, he can probably help with that.


Which is precisely why I said the NES can't do accurate perspective: You'd waste all your tileset (if one is even enough!), and all the houses would have to change when the screen scrolled. So, given the limitations of the system, he pulled off a pretty interesting effect, and as long as houses are reasonable spaced, the conflicting vanishing points won't be so obvious.

A question for a larger game:
Is it possible to create a larger CHR file, for canvassing purposes in yy-chr?

I stripped out the sample file, and have a 32KB chr, but I'm not sure what size is optimal for a UxROM game. I would normally post a chr file, but this one is rather... adult. heh.

The entire point of using RAM is that there isn't a real threshold for where the memory allocation becomes "unreasonable".

As a vague rule of thumb, I'd probably say "not more than half of the entire game data for CHR", but if you're planning on making hardware, all of 128, 256, and 512 KiB PROMs are approximately the same cost nowadays ($1 to $1.50), and there's no real disadvantage to filling as much as you have use for.

I'm aware of the point of RAM, I'm just not too sure about graphics space.
Not more than half? Okay, that's a good approximation. Thanks!

I'm still not sure about CHR files. YY-CHR saves 8KB CHR by default, but I'm not sure how to increase the size.

It's true it's 8KB by default, but if you create a file of a power of two size YY-CHR is usually able to edit it. The file that my YY-CHR program came with that is loaded by default is a 24 KB .CHR file.

If you'd like blank files of X size, I can post them.

If you could, that would be very helpful!
I had 48KB, or 64KB in mind for CHR. Depending on how much room the sprites take up.

EDIT: Oh yeah, the 32KB file I have, is from the newer YY-CHR.NET. I opened it in the old version, ignored the language? errors, emptied the tiles, and saved out a blank file.

Level tiles are super-efficient as in Cat Quest. Though the sprites are fairly large. 24x32 on average. You know what? It's easier to post a picture. Here's a SFW mock-up of the larger project. It's an adult-oriented parody of a classic game.

Here's every power of 2 from 1KB to 256KB. Strange about errors. I'm using a super old version, though. So who knows what might have changed.

So Sir Ababol is a "classic" already? :p

One approach is to make huge monolithic CHR files, which is fine if you're coming from an NROM or CNROM mindset. Another approach that I have tended to use lately for CHR RAM mappers (NROM-256 modded for a 6264 in the CHR socket, AOROM, BNROM, and UNROM) is make a bunch of small (16 to 128 tile) PNG files that an image converter program converts to CHR files. My build process uses GNU Make to automatically call the converter again whenever the PNG files have changed. Then I can include each CHR file using .incbin and copy it to a given address in CHR ROM as it is needed, such as loading the sprites for the characters that both players have selected. Or I can even compress the CHR files and have the NES program decompress them when loading them. Tile compression slows down loading slightly, but it can help squeeze, say, a 144 to 160 KiB game into a 128 KiB chip.

If you plan to distribute your game on a standalone cartridge, it's OK to aim big, such as 4 Mbit (512 KiB) for UNROM, BNROM, or AOROM. That's how big Dragon Warrior 3, Dragon Warrior 4, Mega Man 4, and Mega Man 6 are, though they use somewhat more complicated mappers. Just be aware of two things. First, it takes more effort from your artists and level designers to fill more space; a small cart can help you limit the scope of your design to something manageable. Second, if you want to get your game included on the next community multicart, you'll have to justify the larger size of your game with suitably compelling gameplay.

Oh wow! Thank you! That's far more than I expected! These will be very helpful, for just about any future projects I would have in mind!

Well, It wasn't exactly an error, just a strange visual quirk I noticed. Must be referencing invalid string data, somewhere. Format difference between versions?




I gave the name a google, and found it on Nintendo Age. Wow! I'll have to give that game a try! It looks interesting! O_O
The game is direct a parody of Ghosts N' Goblins. I'd show off enemy sprites, but they're rather... inappropriate. Haha. The Raccoon Lady loses her armour from being hit, of course!



Cat Quest is certainly small enough for inclusion on a community cart! I'm still learning 6502 right now, so it will likely be a while before I can even consider something like that. It's still a slow crawl.

As for this platformer? No, probably not. By "adult oriented" I mean it's a game of a pornographic nature. Certainly NOT suited to a community project!

The interface of YY-CHR was originally in Japanese. It would appear that your copy's English translation is incomplete. The Japanese text appears as gibberish because the program does not use Unicode, and falls back on your computer's default non-Unicode text encoding.

(By the way, it says 通常表示 which means "normal display".)

Well, the vanishing of the house, was carefully measured to it's root position. (bottom, center)
Specifically, so I can do this, to make the world perspective *POP*.



The cliff tiles have only been measured, and are currently incomplete.
Hmm... I may use 4-screen mirroring for that game, make it look like LTTP, on the NES.

Here's a WIP title screen for that adult platformer. The castle itself is incomplete, as it is still a raw pencil sketch.

Clean 8-way scrolling is possible even without extra name tables. It's just a little trickier to code.

Vertical mirroring + cutting off lines from the top and the bottom, I presume? But then you need a way to time where the blanking happens, which as far as I know is not that easy without a scanline counter (sprite zero tends to help, but not sure to what extent when you need to do two splits)

Cutting 16 lines off only the top is enough, and this can be done by wasting only sprites 1-9.

2AM post, after several days of not coding. I can write to the nametable data off-screen. To make maps larger. Right. I forgot. I'm still new to this, haha.

Well yeah, but I figured that most people would prefer to center the visible area instead to look less ugly.

Cool game designs so far!

I don't know how they do it, but a lot of music (+ the player) can be squeezed into a small space. Matt Simmonds' song "Empty" is only 512 bytes!

http://csdb.dk/sid/?id=32845
( http://www.last.fm/music/Matt+Simmonds+ ... 2+bytes%29 )

A question, is it at all feasible to split a larger sprite, consisting of 8x8 pieces into the CHR, and shift the tiles to save space, then apply pixel offsets when drawing the sprite? I can't recall if any of the 200+ NES action games have done anything like this.

It would certainly save a good chunk of room with a run cycle I'm working on!
Note: Her gun-holding arm has already been split off, and optimized from the main sprite.

Given the suggested way to save metasprites, I'd say that not only it's feasible, but allowing that is actually the fastest method. So yeah I'd say feel free to assume that's acceptable. I actually abused that a lot with the astronaut graphics I posted some time ago, the head is a single 8×8 sprite, as are the legs in the first frame.

If I understood you correctly, yes it's very feasible and done quite often. If you want to try that kind of stuff out, there's a metasprite editor in NES Screen Tool (make sure to read the README file).

Yeah! Pretty much that. Thanks for the quick response!
I hand optimized the tile data, and managed to get it from 80 tiles, down to 68.





What I mean, is to keep each tile of a sprite misaligned in the CHR to save space, and then re-align them in-game. I hope I did this right! O_O

If by that you mean being able to place each tile in a metasprite in a completely arbitrary position on screen, then yes, that's possible.

I recommend listening to an interesting interview with the Pickford bros (who made Ironsword, Solstice, etc.) in which they explain how they "enjoyed" working on the NES, as well as how they (& RARE) really optimized sprite tiles on the NES in exactly the same way that we're discussing here.

link: http://retroasylum.com/ep-97-5-pickford ... interview/

Wow! The Pickford Brothers! Thanks for the link! I wasn't aware that they been interviewed!
I gave it a listen, it was very interesting to hear their thoughts on the game industry. Their opinion about indie games more or less summarizes why I keep my distance from most pixel art sites.

I forgot to upload the picture, showing the intended use of the tiles. Everything is WIP:

Mmm, I'm fairly sure they didn't make Solstice. There's that video about the creators of Solstice floating around on YouTube though, it's cool also. At least one other game that I can remember that Pickford bros made is Solar Jetman.

Yeah, whoops! They made a lot of games, including Solstice II... but not the first one.

Here's their softography with comments on each page as to how much of the actual game they handled (sometimes just art, or Jon Pickford was merely the producer, etc.) http://www.zee-3.com/pickfordbros/softography/

A long time since I've done an update-- I've been busy working the graveyard shift at work. Ugh.

I have a technical question, for a silly future project idea I have, that (might) be a first on the NES.
Assuming a map is sufficiently compressed, with a minimal tile index being stored--
(floors and walls. Information would be compared to neighbours, and indexed a metatile on decompression.)

With the use of 8K PRG-RAM, what is the general memory size a single decompressed game screen would use? I'm curious, for calculation purposes. I know that Mario 3 does this.

The idea, is to potentially program a fully functional rogue-like game on the NES.
Complete with seed-based level generation.

(A pseudo-random number would be generated, and would effect the behaviour of a "digger" set from a starting position, to carve out paths, and generate rooms/structures. The game would store these in an RLE-compressed format, de-compressing the map data into RAM, as needed)

I'll be posting some art for this project idea, as soon as I have more time to work on it.

I blocked out some basic wall tiles for dungeon layouts. 32 tiles and two palettes are used so far.
The water and the floor share one palette.



No sprites yet. I'm undecided on the style. Dragon Quest-like? (4-directions) Or still images?
This simple sort of layout is roughly what the map generation will produce.

I'm currently doing some low-level benchmark tests, in C.

This color scheme is great!

Oops! I didn't show this here until now.

This is the 4th boss for Cat Quest, using the last 14 tiles.



Completely possible on the NES, as long as I keep track of the neck segments, and clear unneeded sprites as the boss moves its head down, to prevent flickering.

I've been on some new anti-anxiety medication, and couldn't sleep last night.
I ended up digging up Legacy of the Wizard, and gave it a playthrough on my NES.

I wanted to try the style out, and this was the result:


36 tiles so far. The torch and its holder are sprites.
It may not be correctly aligned to the attribute grid, this was just a test screen.

The bad name, was just a pun. Poking fun at my inability to name things. Heh.

It's as though one of your felines was naming things. bad pun

You know Z1 had the dungeons mingled in mapspace, such that for all 9 dungeons, only two 8x16 maps were used? (Just, different portions.)



Rogue itself was one-way. (Consider the difference between SMB3 and SMB1.)Nethack-alikes would be devilishly hard, because its addition to the genre was saving the entire dungeon, not just the floor you're on.

"fully-functional" could mean a lot of things, unfortunately.

Well, for one, you never need to store the outer wall.

Don't forget to allocate screen space for status.

But really, so long as you don't allow geo-mod (or rationalize "dungeon fixing-crews"), you only need to store ONE thing about each level's layout, to remember the walls (and stair-locations): the seed. (You'll want to have the monster, loot, etc. generation separate, in this case; though traps might be desired to be left in.) Then, you just have to store some number of monsters/objects per dungeon level. Now, you can trim monsters down a bit by assuming they heal up when you leave, but if not, X/Y/HP/ID; items would similarly be in X/Y/quantity/ID. As long as you don't have splitting/breeding monsters, t

Of course, what WILL be likely-to-be-stored in a roguelike is a "seen" map...this can be cut down if we have discrete rooms, to just a few "did they see this room" flags. A maze, however, one can simplify to "did they visit this intersection", to get a 4x or better reduction...

side note: cq4.nsf has been playing in the background for a while and I took no notice. Seems good and unobtrusive and exploration-esque.

And water?
As for dungeon graphics, 32 tiles is a good number; because it'd be a neat bankable slice, once you leave NROM's non-mapper behind. Mind, doors don't seem to be present, as far as common dungeon objects go...

What is with the abundance of cat-themed homebrews? Nomolos, Super Bat Puncher, and now Cat Quest? I've seen other projects that star cats as well. Am I the only one that notices this?

Love your art style by the way. Looking forward to seeing more and being able to play your games on my NES.

I guess... programmers love cats? I know I do, and I also have a cat-themed project.

It's not just console homebrew. Syobon Action, a bunch of SFCave clones starring Pop-Tart Cat, all these...

It's not like there aren't cat-themed official games. A Week of Garfield, Onyanko Town, Felix, Rockin' Kats, The Lion King, Too Cool to Fool, Bubsy, The Cat in the Hat, Super Mario 3D World... Not to mention games where the bad guys are cats, like Wing Commander and Panel Action Bingo.

Pogo Cats and Zero Wing don't count.


WHAT YOU SAY !!

It's not really a huge issue, the game uses an area index to figure out which room to load, based on the player's X,Y on the local map. No "map space" needed. It's all indexed.



I have a solution to "storing" the floors, actually. I was studying how several games encode/decode their password data, and I could apply an offset to the generation seed, whenever the player goes up or down a floor, using a shift byte. Seed generation can create the same data, if done properly.

Speaking of--
The seed will be displayed on-screen to the player, on dying/completing the game.
Because a community playing rogue-likes and exchanging difficult map seeds, is something I miss dearly.



In the case of my rogue-like, by fully functional, I mean that it will use seed generation, and the entirety of floors will be generated by the seed.

Room "patterns" (pre-built rooms) will be used very scarcely. Mostly for shops and such.
No "same 3 rooms in a row", as is common in, say, Rogue Legacy.


Didn't get around to that part, yet.




The seed will be capable of generating the entry/exit locations. Rooms are created based on a set of rules, location, number, min/max size, and potential for treasure/traps.

Splitting monsters would be handled the same way scrolling an enemy on-screen works in most other games, the game may place one, and it may freely split when taking damage, but only if there's a sprite slot available for it.




Huh... I hadn't considered intersections! I just made a note in the project file. Thanks for the suggestion! I have an idea, based on something I wrote for Cat Quest's engine.



It's funny you've been listening to cq4, specifically. As I've been listening to that song, whenever I work on the overworld screens!



Didn't get around to doors, and trap graphics, quite yet. A few may also be "invisible" depending on the player's stats/class.

...Why would I leave NROM?! O_O
Extreme restrictions, are so much fun! =D

Update on Dragon Slayer clone:
I worked on some outdoor locations, and I was stingy as hell with the tiles, when possible.
I have 66 BG tiles left, and I've only drawn a few sprites so far.
I intend on fleshing out that cave background, later.

For being "stingy as hell", that looks pretty dang good.

Top notch!

Fantastic stuff! I loved how you used warm/cool colors to separate the fields of your cave mockup.

Did some more tilework, and drew some more sprites. I'm in need of 6 additional tiles to finalize the cave background, so I've been working on simplifying/moving some things.

I moved some of the interactive tiles into the sprites to get them out of the way.
Pushable blocks, Readable tablets, Doors, etc.
I'm still a few tiles short. Argh.

Also--
I worked on a title screen for this one! Rather than making one as a last minute thought.

TIP: If needed, you can put the "LEGACY OF THE FELINE" tiles in an unused part of the other pattern table and use a sprite 0 split to combine them with the title screen's menu and copyright notice text.

The title screen isn't nearly as good as the rest of the graphics... Big text is always hard, in most cases it ends up looking dull unless you use a lot of tiles.

I know this is an SNES game (ignore the background) but the lettering on R-type III looks nice and I don't think it is using that many tiles. (More than you are currently, though.)


You just kind of have to go for a stylized look. I think the letters in the DOOM logo look really cool and I don't think that it would take that many individual tiles. (Again, more than you are currently.)

Suggestion 1: Ditch the dialogue/status box boundaries and merge them with the title screen letters; that'll save you enough tiles.
Careful palette trickery could enable you to still have them look the same, at the expense of a palette color there.

Suggestion 2: Center the box-borders in the tiles (saves 2 tiles) and move the corner to sprites so you can use flipping to save more tiles (saves 4 bg tiles, costs 1 sprite tile and 4 on-screen sprites)
(side benefit: If you're doing something with Sprite 0, you can do so with a lower or upper corner.) (bottom/right)

Suggestion 3: Use any of the self-contained blocks as the corners. (saves 4 tiles); if you center the boundaries too then you save two more. (left)
Suggestion 4: if you just plain use "real" BG tiles as boundaries you can ditch all eight. (top)

Of course, the palette wouldn't still be that green one.

Separately, you appear to be over-budget on palettes for the screen I picked; unless you put the boundary-foliage and trunk-corners into the sprite table so you can put dark blue on the foliage/grass palette...but then, you've used all but one sprite palette, too. But it doesn't look like a screen where you'll need them.

There must be a good modular font online that could serve as inspiration to create something interesting that reuses a lot of tiles.

I'm really not familiar with the NES, but couldn't you always put the title screen in a separate bank than the level? Unless you plan on putting this game on a real cartridge, I wouldn't think space would be that big of an issue.


I think the game is supposed to use the MMC5, where, If I'm not mistaken, it should work.

All of Alp's demos have been targetting plain NROM:
That said, tepples made the point that NROM is actually two 4 KiB banks, and you can swap which is used for backgrounds and which is used for sprites as you wish.
Galaxian, for example, used this to stuff its title screen into the otherwise rather underused sprite bank. (I'm certain many other NROM games did, too.)

What do chips like the MMC5 even do? I know you can have a separate palette for every 8x8 tile instead of 16x16 and some other stuff, but I'm a bit surprised you can do something like this. Probably not, but could you have something like 4bpp graphics on the NES, I doubt it, but it seems like the PPU inside the NES can be upgraded by expansion chips, unlike on the SNES where only the CPU can. (I'm probably not making any sense. )

No, the attribute clash requiring per-tile paletting is a separate problem, present in the three-tile-tall ocean and the one-tile-thick green ground-cover.
Pal0: Sky/Chimney/Cloud/Mountain: light blue, grey, black, white
Pal1a: House: Light red, medium red, black, ?
Pal1b: Tree trunk/ground/roof: Dark red, medium red, black, dark blue (at the base)
Pal2a: Grass: Light green, dark green, black, dark blue
Pal2b: Foliage: Light green, dark green, black, light blue (around the edges)
Pal3: Ocean: Dark blue, light blue, white, ? (black for BG)

There are only 4 available BG palette slots, so...

The conflict is because of attempted layering over both sky and ocean. Turning some of those to sprites (1b, 2b) lets you get away with that; as there are unlikely to be enemies here, you can probably afford to use the sprites. (You have to have the grass-against-sea be BG, though, because there are a good 14 tiles of it, far more than the 8 sprites-per-scanline allowed.)

The MMC5 does a lot, but the applicable part here is that it supplies additional PPU-RAM that can be used for either nametables or more-detailed attribute tables, allowing palette choice per 8x8 rather than per 16x16. Less applicable here are mapping ROM banks, multiplication, scanline interrupt, sound channels...

The actual colors in the palettes is the only part of PPU-RAM you can't outsource to the cartridge.

Smaller color areas in MMC5 ExGrafix work because the PPU rereads the attribute byte after fetching each nametable byte. The PPU reads the nametable for the left side of a 16-pixel-wide color area, reads the attribute byte, and applies that attribute value to that 8-pixel-wide cell. Then the PPU reads the nametable for the right side of the same 16-pixel-wide color area, reads the attribute byte again, and applies the value it read the second time to that second 8-pixel-wide cell. This means the MMC5 can change the attribute byte between the first and second reads of the same attribute byte.

The PPU also rereads the attribute byte every scanline. In theory, this allows the Game Pak to provide a separate attribute value for each 8x1 sliver of a background tile, not unlike how attributes work on the TMS9918 family VDP used in the ColecoVision, SG-1000, and MSX. In practice, MMC5 ExGrafix uses 8x8 pixel color areas, not 8x1, to save memory. But you still need the same attribute value for all 8 pixels in each 8x1 pixel sliver of the background plane, so you can't just do 4bpp like you're on a freaking Master System.

It watches the memory accessess performed by the PPU, so it knows what the PPU is doing.


Fortunately, the PPU was designed to read the same attribute bits twice for each pair of tiles. Without any memory extensions, the same value is read twice, but since the MMC5 knows exactly which tile the PPU is rendering, it can provide different attribute bits for the second tile. The other expansions work similarly: you can access 16384 tiles in the same frame (instead of only 256) because the MMC5 knows which tile is being rendered, so it can look up extra banking bits in its own memory (ExRAM). Same thing for the 8KB of sprite tiles: the MMC5 knows if the PPU is rendering background tiles or sprite tiles, so it can temporarily hide the background tiles and make more sprite tiles available. It's all about knowing what memory the PPU is accessing and for what purpose, so the mapper can feed the appropriate extended data.


Unfortunately, the bit depth cannot be modified by manipulating memory accesses. The bit depth is internal to the PPU, and the resulting 4-bit pixels are always the result of combining 2 pattern bits with 2 attribute bits, and the attribute bits are only renewed every 8 pixels, so you can't get more than 4 colors in a 8x1-pixel area. You also can't expand the palettes, because the colors are stored inside the PPU itself, meaning the mapper can't feed it manipulated data.

The PPU can't really be upgraded, but a lot of its work is based on reading data from external memory (name tables, attribute tables, pattern tables), and NES cartridges can optionally disable the internal VRAM and route PPU memory accesses to the cartridge, where the mapper can have full control over this memory. As long as the mapper can keep track of what the PPU is doing at all times, it can manipulate that memory according to different parameters and make it seem like the PPU is able to access more memory than usual.

Don't forget being able to use raster effects like in Fighting Road (at least that's what it looks like to me, especially with the areas covered by each palette). Another trick if you can afford to have less colors is to use 1bpp graphics (to store two tiles in the space of one) and then different palettes to choose which of the two graphics in a tile to show.


That's eating up quite a lot actually. OK, you could probably reduce the tile count by simplifying the gradient, but still.

The title screen doesn't use any raster effects (checked). It's just the four palettes and some dithering.

Oh well =/ The idea of using raster effects to give some small slant to the graphics still stands (since you could do that to save some tiles)

I meant the letters, not the space background

I was talking about the letters, they still have some important gradienting and the gradients are unique to each letter.

OI! Had some computer troubles, couldn't post for a bit.

Oh, oops! I hadn't realized that I hadn't gone back to optimize that town shot. Heh.
How is this, for the two issues? I merged a few of the palettes.

For the title screen, I removed six redundant tiles, and used the free space to add a gradient strip. I also re-organized the colour palette to make it more interesting.

The previous one and this one share a problem; really the only bar to getting this on NROM. The ground-green and the dirt underneath are (Technically, you could change the scroll 8px below ground, I guess?) Okay, nevermind, I see that there are still only four colors. Well done with just dark-brown+black there.

To illustrate sprite usage possibility there...
BG color: black
BG0: Foliage/Groundgrass: Green, dark green, dark brown, [black]
BG1: House: Light red, red, dark red, [black.]
BG2: Sky/mountain/statusbar: gray, white, light blue, [black]
BG3: ocean: dark blue, light blue, white, [black]
BG4 (drat, thought it was closer): grass over ocean: green, dark green, dark blue, black
Spr0: (Hero): White, light red, dark red
Spr1: (Foliage over): Green, dark green, black
Spr2: (Tree trunk over): red, dark red, black
Spr3: (unused)

You can maintain the bright colors you had earlier, *almost*- like so, with both layers; you just need to get rid of the grass-over-sea:
(hmm, mind, the gradient-to-black-instead means the tree-trunk-base doesn't need to go to sprite layer.)

Alternately, you could just have a patch of grass over the ocean here or there as sprites, but you might have other needs at ground-level (like the hero and tree-trunk-corners; maybe people?).

e: Nice title-screen, btw.

The title screen is much better!

Hmm... I'll take those suggestions into consideration. I don't really want to go too crazy with sprites in the background, as the towns are to have wandering NPCs, as in Zelda II. Hell, I may just keep the ground grass in towns, and throw away the long grass, and keep for the wilderness. Most towns are well kept, why not?



Oh, thanks! The original was really just a tile memory allocation. I wasn't expecting people to critique it so harshly, haha!

I haven't really had too much time for pixel work, lately, so I'll show the current mock-ups of tile-work for Cat Quest 2 and 3. These were started on the side, just to amuse myself while working on the code for the 1st game. Both of these future games will use mappers, and (possibly) CHR ram.

The dungeon walls in the 3rd game mock-up are *very* unfinished. They were intended as a throwback to the original game, with more of a Zelda 3 style of depth. I messed up my measurements for the bricks, at some point, so they don't line up quite right. Oops.

It sounds like we're moving into DLC territory here...

Isn't Mega Man 2 mostly just "DLC" for the original Mega Man? See tropes Mission Pack Sequel and Episodic Game.

On the subject on Megaman 2--
Once I've made a game or two, I'm considering making a mapper-based DX version of Cat Quest, with the content I had to cut, to memory restriction.

I finally had some free time this evening, so I blocked out dungeon tiles for that zelda-like game from a while back. 143 map tiles, with some extra tiles left for fun. This assumes 16KB of CHR.

Once you have more than 8 KiB, you're either going to be using RAM for CHR, and so there's no need to have any specific size limitation; or else the smallest cheapest available ROM now is 128 KiB. So once you add any mapper at all, don't feel like you need to hold back.

Don't forget about what chip is acting as the mapper though, e.g. if the mapper is just a 74xx flip flop you'll still be able to only use two banks =P (although a 74xx latch may be better at this point, I suppose)

You can't even use any of the single-bit latches without support circuitry anyway. So if you're going to use a discrete logic mapper you may as well use a 74'161 or 74'377 to get a bit more space.

After playing around with tiles for a bit, I settled on a solution similar to Myask's suggestion. (minus the sprites.) I just removed the blue, and transitioned using a "weighted" gradient. (bands of colour, of varying thickness to give an effect of depth.) I'll add the water shine back later.

Also, I decided the full-black title background was boring, so I threw a background onto it, and changed up the text palette.


EDIT: Oops! The Nametable version of the town background, has no chimney on that house.

I *actually* started to code this one! ...and learned some new things I'll be adding to Cat Quest. >.>
(Better map tile collision, and a number of other optimizations.)

I am now programming two games! ...Ugh.

This was, of course after some (rather-amusing) problems:

(I elbow-bumped ONE line of code, can you guess what it was? )

I started working on a scrolling engine, so I wrote some Ruby script, to prototype sprite offset calculation. Maybe somebody here will find it useful? I'll be porting it to 6502, and releasing source, later.

Is the title screen going to use parallax scrolling with the mountains? I think it would look good that way. Also, do you not know 6502 ASM, or do you just not feel like using it?

I have some of the 6502 basics down, background drawing, getting meta-sprites to load, room-switching, and the basics of sprite-to-map collision.

I'm really still learning at this point, that code above, was a test for something, better explained below.

Parallax? I didn't think of that! Good idea! I'll try putting that to use, here.



Perhaps I should have been more specific with this part? My fault, for posting at 3am, heh.

On my initial read-up on 6502, I found examples, stating that sprite-objects were annoying to keep track of, once you started scrolling the screen. So I wrote a re-alignment code in a language I'm more familiar with, to get a better idea of what to do, so sprites don't jitter/collide with blocks incorrectly when the player is moving the screen. I've seen that effect in a number of games. So avoiding it, is ideal. (That platformer will have left/right horizontal scrolling.)

I managed re-format Cat Quest's metasprite/tile data to %60 of it's original size, and realized that it would require re-programming the data. I took the opportunity to re-organize the entire CHR file.



I shifted some sprites that I somehow managed to miss, and threw out some background tiles, that were (basically) useless. I freed up enough space to:
1. Add 4 8x8 sprites to the player, to show her carrying a shield, when she has one.
2. Added two tiles for the top of a cave entrance, to make it less blocky looking.
3. Added a 16x16 tile for "shutter blocks", that slide into the floor, when you clear a room.
4. Generally re-organized the SH*T out of the CHR. Haha.

So... collision storage? How do other people do it? I have my own technique, which I will show here, and it works quite nicely in my engine, so far.

I calculate my sprites from-center, in order to make the code easier to read, and as a nice bonus, in 6502 ASM, this manages to save a fair-sized bit of space, at least, in larger games it would!



The sprite offset data listed below, is compiled from the *two!* collision bytes that are listed below the sprite area boxes at the top. Can you see how the data is shifted? ;D

The data is calculated, and stored into RAM, on loading a new screen, so it's actually pretty fast!

I *would* have charted my metasprite/tile format as well, but I have not slept in close to a week, due to spring break, and loud children. Ugh. (Both formats are practically identical, sitting comfortably at 5 bytes/per)

I apologize for not having posted in this thread - or forum - for several months. I've been caught up with real life and other projects.


Currently, I'm trying to design a very small reasonably-usable music engine. Disregarding the restrictions imposed by the NROM nature of Cat Quest, I am simply trying to design it to be as small as possible as a personal challenge.

Firstly, I will address the period table. Instead of the naive method of storing a 128-byte 64-note table, it's probably a better idea in this case to store a 56-byte 28-note table, addressable using only 5 bits. How is this done?

To use the same key for each track sounds like a limitation, but establishes a throughline for the soundtrack. By doing that, 3 chromatic scales can be stored, spanning C2-C4. However, the diminished second, the tritone, and the major seventh all seem a bit misplaced in a fantasy setting in my opinion; these can be thrown out, yielding 12 - 3 = 9 notes per octave. 9 * 3 = 27, + C4 = 28 notes seem sufficient for a plethora of musical content based on what I've yet written.

The representation of notes only needs 3 values: note duration, note pitch, and note volume. Note duration is rather simple; it is probably 6 bits, in units of frames, meaning a duration of 63 yields a note just over a second long. (63 would actually be 64 frames, because a 0-length note is useless.) Note volume is just 0-15 as usual, which is 4 bits. (Volume is still used for the triangle channel, because a volume of 0 is still semantically useful, and not creating exceptions simplifies the design.)

This means that each note is 6 + 5 + 4 = 15 bits, aligned to 2 bytes to simplify reading the data a little bit, decreasing program size.

Individual tracks are identified using a label in the assembly, which is essentially "compiled away" (need confirmation on this). The metadata header for each track holds a byte that stores the duty cycle for each pulse channel and a "does this song loop" bit, followed by a few bytes holding the length of the track in frames (debating over this - it would be a really big number), and then by pointers to 4 note tables - one per channel. The note tables simply store the notes, each entry being a word holding the 6+5+4 values.

This means only a few bytes of RAM are needed: A global tick counter, one note table index per channel (using 1 byte would limit song length to 256 notes), and one duration counter per channel. (If the duration counters are 6 bits, four can be stored in 3 bytes.) Few CPU cycles are taken on average per frame, because it only takes a few instructions to check whether any of the counters are equal to 0, which is usually false. If one of them is, read the corresponding channel's next entry in the table, send the data to the registers, and increment the index for the modified channel's table. Then, if the global tick counter has hit 0, check the loop bit and reset the note table indices and counters appropriately.

Final note: I nowhere mentioned patterns, which many engines use (presumably; I know little about them) to greatly compress song size. I've omitted them, not only to simplify the design, but to encourage minor variations in my composition of repetitive tracks, rendering the resultant music more interesting.

Is my approach a bad idea? Am I forgetting an integral component? Is there a smaller way of storing music? Is this whole thing a mess? I'd love to hear some feedback.

Go ahead and implement your ideas, and see if you can pack as much into 3K as I did. My music engine, used in three NROM games in each of the first two volumes of Action 53, uses a 64-note or 80-note table (size configurable at build time). Each pattern can see a 25-note window of this table, which can be shifted with a "change transposition" command. This lets me pack a duration and a pitch into one byte.


In a minor key, you'll need both the "natural" seventh for III chords and the "harmonic" major seventh for V chords. For example, E minor needs E, F#, G, A, B, C, D, D#, and E.

You can also store a period table with 12 notes in the lowest octave, and right-shift for higher octaves. If you feel the need to correct for rounding error, you can store an additional table with 12*(number of octaves) bits, but once you take into account the extra code to make use of the second table, I'm pretty sure it would be bigger than your 28-note table.

Octave doubling... it's genius. I wish I'd thought of that!


I do think I'll put the major seventh back in. Adding 3 notes goes from 28 to 31, which is still addressable in 5 bits.

I noticed many of my songs have a high note density, but a relatively constant note duration. For example, a single channel on one of my songs totals 256 2-byte notes, each the same length.

I'm considering using a fixed-duration method, where each channel stores a constant duration in the metadata. (If tempo is stored, the constant could be stored in 2-bit fractional units, letting 4 channels store them in a byte, but that's probably unnecessary.) Removing the duration value reduces the 15-bit notes to 9, and halving the volume resolution (storing 0-7 values and doubling them before sending to register) reduces them to 8 bits, halving the note size.

Since 3/4 the notes alter the volume and not pitch, omitting half the notes would have little audible effect on the music.

Compounding these modifications, the data size for the channel would be 128 bytes, a quarter the original size.

EDIT:
Since pitch doesn't matter when note volume is off, nonzero pitches can be used to issue commands to the engine. e.g. volume of 0, pitch of 1 could change the duty cycle, pitch of 2 increases the all following notes' pitches by an octave, etc. Since the engine identifies these special conditions, it can know to read as many bytes ahead as needed for the command, e.g. several notes for arpeggios.

Oh, cool! You're still here! Being busy with real life is fine, hell, I've been busy with commission (art) work, so this game has taken the back burner for the most part. I work on it whenever I have the free time.



A pattern is just a way of compressing looped sections of songs into a single copy, and calling it as needed. .MOD/.XM music does this a lot.



If your compression method can justify the extra data, go right ahead! I have no problem with that!
For example: I have managed the AI for 18 unique monsters (no bosses yet), programmed in well under 1KB, Their logic loops are only 8 *bytes* each! (I abused the crap out of generalized, modular code for the update loop.)

So far:
Bank 0, contains the game logic (game loops, reading/writing)
Bank 1, contains table data (enemy/object configuration)
Bank 2, contains the maps (2 formats, one for detail (title/intro), the other for game screens)

I haven't even so much as *touched* bank 3 yet, so that's 8KB open to... whatever!
(Actually that's a lie, I'm using 6 bytes for mandatory padding, I hope you don't need *those!* )

@Nameguy
If you're serious about producing the music, here is that list I forgot to post, some time ago, it's been sitting at the bottom of zp.asm forever! Sorry it took so long! :S

If at all possible, I would like each dungeon to have a unique track. Thematic to the location.
The dungeon palette, and my rough thoughts on the theme, are present. Ignore the sarcasm/silly comments. : P

0-title/intro ;Title theme, with a lead-in to an intro. (requires a fade-out? unsure.)
1-menu/password ;Relaxed/Happy music, something simple for a new game, or continuing.
2-overworld ;Explorative music, song length is allowed to be longer. Most common song.
3-underground ;Cave music. That's it. Nothing else to say. Mischief/Tension theme.
4-level 1 ;Forest Temple, Green/Blue, Song should be relaxed, introductory dungeon.
5-level 2 ;Desert Tomb, Red/Yellow, Slow/ominous, or fast/creepy. Not sure. DEATH.
6-level 3 ;Lake Shrine, Blue/Green, A water level, people seem to hate these. Make the song memorable, at least.
7-level 4 ;Mountain Stronghold, Grey/Blue, A more serious/action-y theme. Dragons, yo!
8-level 5 ;Underworld, Purple/Red, Last level, the final showdown with death itself.
9-boss 1 ;Main Boss theme, short and intense. You need to know that you're in danger.
A-boss 2 ;The Algol, possibly a longer, drawn-out song? It *IS* the last boss.
B-ending/credits ;Uhh... Not sure about this part, quite yet. A remix of the main theme?
???? ;Possibly additional data, I haven't given sound data too much thought.

Here are shots of the palettes, applied to a dungeon screen (number $25, I think.)
The first two, show the palette difference between a lit and dark room. This game will be slightly less dick-ish than Zelda, in that you can at least *see* the floor. Enemies will still use a black palette though, but at least you can make out their shadows!



The bottom two panels were from an idea, to possibly add a day/night cycle. The game has a clock (pause menu/password), after all! Why not use it? This would potentially be functional to gameplay, changing the enemy groups on overworld screens.

Well, for starters, you'll want a "Game Over" ditty. It can possibly be an extra bar or two leading into password theme (like how Megaman 2 does it).

Being a Zelda-ish game, you'll probably want "Boss Defeated/Dungeon Complete" and "Item Get" ditties, "puzzle solved" as well, though that's falling a bit into SFX territory.

Sorry, short update.
I was busy today, so a lot of the engine work was done the two previous days. I got the pulse & triangle channels working, and started noise.
Most of today was spent with writer's block trying to do song 1.
It has come out in the vein of MM2 & 3 password screens. Also as short as they are.
However I have a pretty good idea what I want to try for song 0 (title) and a few others.

If it's a good idea to release the source code I'll do that, just not until the code is in a better state.

P.S. Does the phase reset on the pulse channels every time you write to 4003? Currently it's making the nastiest clicking sound every update.

Yes. For this reason, you need to save the last value written to $4003 and $4007 and not write it back it if it hasn't changed. Also avoid vibratos on A notes (or G# on PAL NES) unless you're using obscure tricks with the sweep registers and $4017 to manipulate $4003.

That's the reason for the 60Hz noise on e.g. Dizzy, so I read.

Neat! Sounds good!


Dizzy the Egg! :O
I'm one of about 3 people in North America, who grew up playing these games. Probably.

I tend to work on small pixel pieces while programming, to help myself focus.
I *finally* found a game for that Knight character! It's an NROM-restricted Dragon Quest clone.
(Monsters will take the lower-half of the sprite page, more than enough. That Slime is 6 tiles.)

43 BG tiles so far, 91 counting the 48 for the text.
18 Sprite tiles


If there's room, after drawing all the needed locales, I may add a background for the battles.

Interface is a little on-the-nose for my taste, but looks nice. I'd suggest switching G and E to GP and XP if it weren't for the fact that those fields are the ones that can possibly become 5-digit...unless you reduce the maximum there compared to original-flavor.

Maps are gonna take up more space if you're specifying by 8x8 as on the left rather than by 16x16 as on the right. (One can always calculate when to use edge tiles by surrounding data, but those gaps in the/individual trees/mountains might prove problematic.)

Gonna do character facing like Dragon Warrior or stick with faces-camera-only people like Dragon Quest?

The interface layout is practically 1-1 with Dragon Quests', I haven't decided if I'm going to change it. A scale reduction could work, to improve the readability of the fields, not a bad idea!

Actually, the maps abuse the hell out of 16x16 meta-tiles, and mid-cluster (index 5) auto-tiling to increase the level of detail. That is, the middle forest tile is systematically replaced by the map loading routine. Just a little trick. Not 8x8 at all.

There's enough room for a fair amount 4-directional NPC sprites. (14 total)
I can possibly get tricky with the shopkeepers, and make them direction-locked, to save the room for more important characters.

Ever considered making the text font fancier? (heck, you can even make it use all four colors, e.g. for shading)

Nowadays, the command list would be placed at the bottom, just below the end of the text in the text box, because that's where the player is already looking.


If you can come up with a currency symbol, like $ (dollars) or £ (pounds) or ¥ (yen) or ₹ (rupees, useful for buying lamp oil, rope, and bombs) or Ꝑ (the currency in Pokemon) or Ҹ (ciodanti, the currency in RHDE), it should fit in one tile.


Only if fancy also means readable. The point of text is to convey information. I tried fancy in a few homebrew games over a decade ago, and it caused Cowering to misspell my name.

The "fanciest" I have, is the lower-case half of that "Arcade" font of mine.
I'm currently putting off using it, as it uses 1/3 of the CHR!




Actually, it's funny you mention symbols, I was planning on adding symbols for inventory items, to make it easier to identify things at a glance. (Potion icon for consumables, Sword for weapons, etc.)
If I can figure out a symbol for gold, and exp, I will add it!

（・＿・）

Incidentally the suggestion came because I couldn't stand how certain letters looked (especially the I with its uneven stroke, I'd rather have uneven spacing instead).

*crawls out from under rock*

I gave this some thought, and decided to give it a try. I wasn't even aware this was possible! Neat.

After some tinkering around, I managed to get this method working!
This saves me 33 tiles that I can now use for more background variation.
Less for sprites, but, it's a platformer game, so it shouldn't matter. (Left/Right only)

I marked out how the screen splits will be handled, for the parallax effect.
The water requires shimmering effects for this to work right. I'll add them later.



*silently crawls back under rock*

Recently, I decided to throw out a total of 18(!) tiles previously used in Cat Quest.

First, the auto-map. While not a bad idea, storing the data for a password would just be stupid.
The primary "you are here" map has been kept, though.

Secondly, I condensed some of the metatiles on the Overworld, clearing about 4 more tiles.
Lastly, I cut a transition in the Dungeon tiles, I wasn't using. At all.


The game now has 18 free tiles, and I have *no* damn idea of what to do with them! Go me.



Code-wise, I'm rather pleased with the method I chose to develop for Monster AI:


Those 8 bytes of data, are a generic action script I designed, to handle object logic for enemies, without requiring large blocks of code. "chg_dir" may seem redundant at first glance, but when you consider that I can calculate a new direction for *any* type of object, it makes more sense.

I showed the format to Nova, some time ago, and I've since rewritten it twice for optimization.
Here, 40(!) unique enemies are programmed in 320 bytes, exactly.

Now, to tackle the bosses! ...eventually.

Ending sequence decoration?

Or variations of existing tiles to decorate your existing areas with, such as cracks or dirt on walls or the ground, or slightly different bricks so they don't all look the same?

Not a bad idea, though, to be honest. Much like the intro scene, I was going to more-or-less mimic the Zelda 1 Ending. With credits, followed by the death count, game time, and, since I mentioned it on FurAffinity--

A press B prompt, to start the "2nd Quest Mode" complete with a completely re-worked Overworld map!
But, SHHHH, it's a secret! >.>



I need to be careful with that idea, clarity is far more important than simple variation.
The game has fissures in some cliff tiles for marking the bombable spots, for example.

You don't want to make players suspicious of *everything*, that's bad game design.



So far, I've experimented with:

A: Re-adding the town tiles to the game. 11/18 tiles. (Problem. It'll be hard to make indoor tiles.)


B: Tombstones, to add a Graveyard to the Overworld. 4/18 tiles.


C: A flower tile, to give the Overworld more life. 1/18 tiles. (This one has a catch, it can't be near water.)

I'm two days late, but happy anniversary anyway!

Looking great as always! Whatever else you choose, I think you should definitely use those flowers - most beautiful 64 pixels I've ever seen.

So, it's however many months later, and I have a LOT of musical ideas in the air.
During the summer I put a lot of musical effort into my own game. However, the writing process produced some tracks that I think would work a lot better here.
My academic workload is low so I will definitely be able to flesh out the 12 songs you posted at the end of May. Today I don't have anything to show, unfortunately, but I hope to get something attached by tomorrow next week.

Not long after commencing, I halted work on the music engine as I realized I would fare better with a top-down approach. I'm much more proficient in C than in assembly, so my plan is to prototype the design of the engine in C.

As it stands, the work I've done so far demands a relatively high feature count, so I will be making some compromises compositionally. Once I'm satisfied with the tracks and the engine, I can re-write the engine in assembly, making optimizations a compiler couldn't. All goes well, the result will be a single .asm for the engine, with one subroutine to play a track, and an update subroutine to be called every frame. (This is how the two versions I wrote in assembly work.)

So, does anyone have any tips on 6502 C? I know this article lays the groundwork well, but I'd like to know early on if there are any traps/pitfalls to avoid.

Edit: So much for the low academic workload. Nevertheless, the C prototype is 80% done, and then I will probably write a simple GUI to make sequencing and pattern tables less of a pain. After that I will try to post something more than a 10-second test loop.

Maybe "cracks" wasn't the right word. I meant stuff like an alternate left-half-of-a-brick tile where it has slightly different shading, or it's offset by a pixel or something, and the same for an alternate right-half-of-a-brick tile. Really subtle things like that, nothing meant to draw the player's attention like a giant vivid hugely-contrasting crack-for-decoration or anything like that. Sorry for my bad wording.

DRW's been discovering a bunch, and complainingsharing his discoveries with us.

The big ones are aspects of that the CC65 software stack is very slow, so:
* Use variables in global scope, or declared static, or compile with -Cl
* Correspondingly, avoid recursion.
* Avoid parameter passing when possible, but if you have to, use __fastcall__ with at most one 8- or 16- bit parameter
* cc65 generates stack-using code even with __fastcall__, e.g.
because the value of param needs to not be trashed by any functions that you call from this function – but you can fix this manually.
* Be careful with pointer math (the 6502 doesn't have a native way of dealing with individual arrays larger than 256 bytes)

But, most important:
* Don't be afraid to just write something that works first, and then analyze what's making it slow.

Yeah, Shiru's page says most of the important parts, especially the bullet points under "optimization".

Sorry to be negative, but I thought those were footballs, and kept wondering "what flowers"

I loved the flowers.

I'm looking at it from every angle but I can't see how it could look at all like a soccer ball

I don't understand how this is formatted. The first two bytes seem to make sense if $14 represents a command, but the next two? Also, what exactly does prng do?
Basically, how does this work?

I took a third crack at song $01, the menu theme, this time using the C engine. The instruments here are hardcoded for now as I haven't implemented support for them yet, and after entering individual bytes into an array for a few days, I have definitely secured the decision to write a GUI-based exporter for this music format.

I'd also like to hear from you guys whether the test_song_01 I attached to my last post holds any merit. Of course, it's *much* too short as it is, but I'm thinking I could gut it and stuff its body parts in another skin.

Also, here is my first attempt at song $00 (title) from a few months ago, which I didn't post, that I had done for the first version of the engine.

It's nice, except too short. Honestly, my favorite of the three. Would be nice for BG music for regular gameplay.

(song_01_menu.nes)

The mid range sound is a bit harsh. If you're using Famitracker, could you give it a smoother volume envelope.

(test_title.nes)

It's a good start, but I keep expecting it to break into a fast arpeggio or something more interesting.

He said he thought it looked like this:



Not like this:



Okay, sorry...

Lol I do believe he meant futbols.

I can say that with a certain amount of certainty because I saw it too at first glance.

I'd personally try to get a color in the center of the flower in favor of the dark green or black. Getting rid of the black would also get rid of the whole soccer/football/futbol confusion if that's a concern.

I didn't see the soccer ball until it was mentioned, now I can't unsee it.


Easier said than done when you have such limited palettes. As I see it, the flower is kind of a bonus, something you can use to break the monotony of the grass since you already have a suitable palette and it's only 1 tile.

Oh, I didn't include the formatting, did I? Oops.
...and the current version of the format, isn't documented.

I'll just just explain it, I guess, it's very straight-forward, once you know what's going on.
Each action command consists of 2 bytes, one for the command, the other for timing.

The first byte contains 2, 4-bit commands, letting the engine know what to do.
Byte 1, Left Nibble: Next Action to Perform ($00,$02,$04,$06)
Byte 1, Right Nibble: Current Action State ($00-$0F)

The second byte contains an 8-bit frame timer, that I can also use as an integer, for special commands.
Byte 2, Action Timer (Optional: Integer)

...as for [prng]? That's just "pseudo-random number generation". Which, in this case, is pulling a number out of a look-up table, to simulate random numbers.

So, to break things down:
.db $14,$08,$23,$00,$31,$30,$00,$1E
[prng(8)],[chg_dir(0)],[move(8)],[idle(5)]

$14,$08
0: [Goto: 1], [Run: 4 (prng)], [Int: 08] ; Get a Random Number
$23,$00
1: [Goto: 2], [Run: 3 (chgdir)], [Int: 00] ; Change the Facing Direction TO the Number
$31,$30
2: [Goto: 3], [Run: 1 (move)], [Int: 30] ; Move 8 Pixels, in the Current Direction.
$00,$1E
3: [Goto: 0], [Run: 0 (idle)], [Int: 1E] ; Wait for 0.5 Seconds.

Some enemies are larger, and more complicated, making good use of the GOTO command, and some are smaller, and simplified.

That's an amazing start on the music!

@Espozo

Silly murican, that is a handegg, not a football

Oops. I killed the image links over here, too! Eh... whatever.

This news is 1 month late--
But this game, and all other game-related projects is CANCELLED.

As a consolation prize, have some box art:


Sorry to anybody who wanted to see this game completed.

Any chance you'd be willing to post the source code over at RHDN under 'abandoned' ? Assuming that your code is well labelled/commented.

Maybe someone in the community would complete it for you.

Why do something this drastic? If something is currently preventing you from working on it, why not just put it on hold for a while and resume working on it sometime in the future?

Anyway, the box art of really nice!

Just because you started something doesn't mean it has to be finished. If you know you're never going to finish it, there's no sense leading anyone on about it. There's honour in admitting this to yourself and others.

Most professional game projects get cancelled quietly, in the hopes that people will forget about it and it won't cause negative PR for the studio. This is necessary not just for public perception, but it's harder for a company to negotiate when everybody knows you've just suffered a big loss. For fans that were really excited, though, this is the worst. This is the break-up without even a phone call, just stop answering and hope to never see them again.

Better to know the truth.

I just think it's a bit harsh to go all "fuck all my projects" like this. It gives the impression you never cared about them from the beginning. Commercial games are different, since projects are most likely cancelled for business reasons (i.e. not enough time/money to fix whatever is wrong with them), but for something you love it would make more sense to delay development in the case of obstacles than to outright cancel them.

People have the right to do whatever they want with their own stuff, sure, I'm just pointing out that I find it a bit weird. Personally, I'd rather die an old man still dreaming I can finish every project I ever started.

Apparently due to this: http://nintendoage.com/forum/messagevie ... did=153905

That would be unwise, as the community is the reason that I'm quitting.
They are the LAST people that I would want to touch the code.



I made a post over at NintendoAge, expressing my disgust, at the idea of Cat Quest being put on KickStarter. (I consider it a tool for scammers to make easy money, or for developers to be lazy.) People were confused, and several community members attempted to antagonize me while I tried to explain my views on the subject, twisting my words around, and insulting me after each new post.

I soon announced the cancellation of my projects, and locked my threads.

The community member "Daria", was more down-to-earth after it all, and messaged me on Twitter, trying to get me to go back to the community after a few days. I returned to find that the thread had degenerated into bad-mouthing me, and making porn-shaming remarks about my job. Unacceptable.

It doesn't help that I've been receiving trolling e-mails ever since.
However the hell they managed to get that information.

...I could have sworn that it was under "private", but whatever.
No hobby is worth the stress.

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

I guess I'm not the only one who shares this opinion... It's fine for something like the Retro VGS where you need a lot of supplies, but not something like an NES game. If people really cared that bad about their game, I really feel they could make it without money, considering it's pretty much free to make one. Like I said, KickStarter is good for some things. I remember people giving James Rolfe a hard time having a KickStarter for the AVGN movie, but no matter how hard you're trying to work, that's most certainly going to involve money and not just time.


I can't help but feel it was justified after seeing you know what...

You're still a teenager living with your family, aren't you? One day you'll realize that once you have to support your own family and pay all the bills, you really don't get much free time left for hobbies. If you can get enough people interested in your project that are willing to pay to see it completed, I don't see why you shouldn't go that route.

Developing a game isn't free. If you're a programmer, it's not wrong for you to be paid as such. Same thing if you're an artist, or a musician. Work costs money, which is why companies have to pay people to work for them. And if I am going to be paid for something I do well, I'd much rather be working on a game I'd like to play than developing some stupid company's website that won't be appreciated.

Crowd funding is a way to make viable something that couldn't become a reality otherwise. It's not pointing a gun to anyone's head and forcing them to pay you, and people who dislike that kind of funding are completely free to not participate. But if enough people are interested, everyone who does want to be involved wins.

BTW, I'm not even gonna read that thread because I hate drama. If you don't want to make the games anymore, too bad, the graphics were nice.

That's true. I've just never been too keen on the idea that you can give the people your money, and that the project may not even get completed but you won't get your money back. I never thought that someone would ask for enough money to where they wouldn't still work though.


Yeah, you're probably better off.

I never understand the strong feelings people seem to have about what other people do with their own money.

For the same reason people care about others committing suicide.

Then how else is someone supposed to feed himself while working on a project of larger scope than a single person can handle in the time remaining after a full-time day job, housekeeping, and sleep? If the game's producer is a programmer, he needs to hire artists, or vice versa.


In a market economy, you can't make a game without money. You can't even stay alive without money, as rent and food cost money.

So is there a better model than Kickstarter for funding the development of games larger in scope than the "single-screen puzzle games" that certain regulars here have given me heck for making?


Perhaps someone fears that scamming may become "the new normal". For example, "what other people do with their own money" is buy video game consoles instead of gaming PCs, which forces third-party developers to spend extra money on the overhead of obtaining a console devkit just to make and sell their games. And because "what other people do with their own money" is buy PCs, you can't be sure that GNU/Linux will work on a brand new major brand laptop (see DebianOn listings for T100TA and X205TA).

I can't speak for other developers, but I certainly wouldn't be able to have a full time job (that hardly respects the theoretical duration of a workday, as is common in my line of work), take my daughter to school and pick her up, shop for groceries, cook dinner, clean the apartment, and still find time to develop a complex game.

If I were to develop a game for good, I know I'd have to be paid at least part-time for it, while still doing something else to get the rest of the money I need to support my family.


That's a bit extreme, considering how irreversible suicide is. A lot of people do care about aspects of other people's lives that are none of their business though, such as who they sleep with.

Since I probably am one of these regulars you're talking about, I'd like to take this opportunity and apologize for anything I might have said that wasn't nice. I've always been too ambitious with my own creations, and used to look down on simpler projects. But now I can see the merit of the smaller games, and I'd honestly much rather have one fun, well polished, single screen puzzle game under my belt than nothing at all. You can shine making whatever kind of game you want, just work well and make sure you're releasing a polished product, not a half-assed mess that barely works.

This is an absolutely disgusting comparison to make, and I am strongly offended.

@Alp

I, for one, was looking forward to your game, and I'm sorry to hear its cancellation.

And, I personally have found "the community" to be helpful and friendly. If you don't enjoy it anymore, I guess it makes sense to move on. Good luck with your future endeavors.

[Edit, some comments removed, because I actually do know some of those people, now that I read it closely]

It was a terrible example, but the point I failed to make was that people (to an extent) do care about each other and what's best for them (if they don't despise them). That's the only way we could have gotten to where we are now. Or maybe I'm just looking too deep into this... :/


That's probably more like it.


It seems that some of those people at Nintendo Age were fairly unpleasant. It seems like when he was referring to "the community", it was mostly them.

Different people have different priorities, though. I for example find it silly that people pay as much as they do for a new iPhone, while they could buy an awesome Samsung or Motorola for half the price, but that's their choice, and it would be rude of me to interfere with their decision.

Everybody who works knows how much their money is worth (and those who don't probably don't have to worry about money anyway), and what they're going to trade it for is a decision that only they can make.

It's not an individual app user's choice to make a particular proprietary app exclusive to iOS. It's the same reason you need to buy a Nintendo 3DS to play Animal Crossing: New Leaf or Super Smash Bros. For, even if you use a PlayStation Vita or an Android-powered tablet for the rest of your gaming.

True, and who are we to question the iPhone buyer/owner if he thinks that this app (or any other) is worth the difference?

Hey, it's been a while, so I thought I should probably make an update.
My schooling has taken up more of my time than I expected, so I have been spending less time on this than I'd like, apologies for that.
Anyway, after working on a certain design of music engine for long enough, I realized that with the changes I was making it might have been easier to start from scratch with a simpler design. However, I've yet to re-restart, as I think I should probably design a GUI first - if I have to manually put in one more note I'll explode.
As for actual tracks, I have 8 total, with one or two in rough state, three reasonably complete, and the rest in between. (Most of them aren't yet assigned to a specific level.) I finally got the overworld track written, by fiddling around and stumbling upon something that just clicked. No earlier attempt got an appropriate feel, and even still the one I ended up with is a little pop-like, but it's the best I've done so far, and I'm actually a bit proud of it.
Unfortunately (once again ) I can't really show you guys anything right now, since I haven't been directly using any music engine for writing--
Oh....

I'd love to hear your music.

Just remember, I warned you that these tracks were not in a presentable state: most of them have too few sections, and all the drum sounds are placeholders.
Most of the tracks are single-section loops that I've made to play twice so you can see how they would have looped. Once again, be warned!

Zip of nine mp3 files, 15 MB

Comments for each track, ordered from most to least awful:

dunno.mp3: Shrill, dull, and short. Not sure where it would have gone had I made it less terrible.

lair.mp3: Equally short. To think that it's my best attempt at something that sounds menacing...

0-title.mp3: I'd put this further down, but you've probably heard this track before.

1-menu.mp3: Same.

trash.mp3: One of my first attempts at an overworld/title theme. Obviously inadequate.

fast.mp3: Another attempt at overworld/title; fortunately, less inadequate.

4-forest.mp3: I knew that a lot of my stuff would end up either "sounding sad" or "sounding happy", so I decided to write the Forest Temple first of the temples, because that was the first and most light-hearted.

5-lake.mp3: Sounds like forest, i.e., not really appropriate for any other temple's theme, let alone the water temple's.

2-overworld.mp3: I might have overstated the quality of this track. I'm not proud of how it sounds now - I haven't written any other parts or transitions. Had I 20-30 hours to work on all of these, I would have been able to consider most of them complete AND acceptable.

I like "lake", but it feels more like the end of the game, credits are rolling. But, I think that if you dropped the drums and made it smoother, it would work great for a opening title theme.

Some of these are pretty good. If anyone else is working on a Zelda game, maybe you can still use them.


(On an unrelated note, it looks like Alp took down all the pictures of the game. Two years from now, if someone is looking through old posts and wondering what this game looked like - it was a bit like Link to the Past.)

[Removed at Alp's Request]

The .CHR files still exist in earlier posts: viewtopic.php?p=134663#p134663
Or here: viewtopic.php?p=134769#p134769

I tend to just save everything, because images get lost/artists nuke their gallery/other stuff.

I got a lot of stuff in my pixel art collection that's not on the web anymore.

For those who don't understand what's going on here: Basically, someone at Nintendo Age was talking about kickstarter - offhandedly mentioned Cat Quest, and Alp was offended (apparently he has a low opinion of people using kickstarter)...and they argued, and some people said some insulting things, or at least some things that Alp took negatively. And, that's about all I know.

Sucks, huh? I'd love to see this game finished too.

@Espozo
I was professionally trained in animation at a hentai studio, when I was doing unpaid intern work.
After school, I started drawing porn, to keep myself fed. I don't see what's wrong with that.

My disgust with porn-shaming behaviour, comes from the fact that good artists have left, or worse,
hurt themselves from assholes bullying them about their trade.

Hearing "waste of talent", or "you're a loser" gets to people over time.



@Tepples
A much better option to KickStarter, though it's been abused just as much, if not more--
To be honest? Patreon. I still hate crowd-funding, but this one has dynamic payment, to mitigate scamming.

The content creator wastes funds, or stops producing content? Cut the funding, and move on. Simple.
As far as KickStarter is concerned, scamming IS the standard.



@Dougeff
If it wasn't obvious from the "oops" in my cancellation post, the image removal was
not intentional. I just nuked out my Imgur account, to get my art off of NintendoAge.

I have the image uploads archived, so I could edit my posts to re-upload them.



@Nameguy
I'm sorry about the cancellation, but if I'm making a game for a community like that, it's not worth the stress. A series of rude e-mails in my inbox, was the final nail in the coffin to making games.

Being honest, and telling you, is better than wasting any more of your time with this.

I haven't thrown the game in the trash, I threw it on Google Drive, so I don't have to look at it, anymore.

I may revisit Cat Quest in the future, but that day is far off. If at all.



@Kasumi
Oh, please don't give out my Twitter! I'd rather people just forget about me, and my work.

Yeah, the CHR files are all still there. The image removal was an accident on my part.
Who said I removed my online gallery?! It's still over here (NSFW warning):
http://www.furaffinity.net/user/icelink256/

I did delete my personal portfolio, however. For reasons listed below.



CollectorVision offered to help me finish Cat Quest, but that wasn't the problem. I declined the offer.
After completing some sprite work for him, I will be quitting game design altogether.

As a sign of good faith, I will be GIVING him Anna Fuda: Project Eden, including the script, art and characters.

Here's to my first (and only!) year of making games for the Western market. Amazing.
(To compare, I made games for the Asian market, for 15 years, with minimal issues.)

But who cares what I think? I'm just a "mentally unstable" rich brat, who draws breasts for cash.
Their words (Nintendo Age), not mine.

I'll respect your wishes and edit it out of my post. As far as saying you deleted your online gallery, I was speaking generally not about you. Lots of artists delete their galleries, so I make a habit of saving anything I want to see again. I had no idea about your personal portfolio deletion or any other thing.

Hey Alp,

"Success is the best revenge"

Your work was good. Keep at it...somewhere...maybe PC/tablet/smart phone game development?

NintendoAge is a very insular community. I don't consider them representative of people who are interested in NES games at large. They're a tiny niche within that with a somewhat narrow focus, mostly a collector's forum.

Don't think of them as your audience. They're only a tiny subset of people who wanna play new NES games.

But how big is NintendoAge as a fraction of those willing to pay for new NES games, as opposed to those who play only games released as a download without charge?

Still a tiny fraction, IMO.

I think you're describing NintendoAge vs NesDev. NesDev is not a representative audience either, but it's a completely different cross section of Nintendo enthusiasts (who definitely do largely prefer software, especially free software, over tangible things). This is my point, though, each of these communities is only a small slice of a much bigger hobby. Like minded people collect at these places, you're not getting a good survey from it.

I feel alp brought this on himself. The original comment which set him off over on NA was actually a compliment---saying his game was good enough to be a high-profile kickstarter project. Instead of saying something like: "well, I'm not really into kickstarter, but I assume you meant you think my game is good!" he acted kind of immature. People first called him out on this, and not in an unkind fashion. It began to unravel from there. It all could have been prevented. The guy's talented, but is also massively immature to match that talent, unfortunately. I hope he changes his mind at some point in the future. _{as long as he doesn't put any penises in Cat Quest}

They did not call me out on anything, and what does "maturity" have to do with this?

I said KickStarter is stupid, they said "what the hell", I said "I hate people who are lazy", they said "income" I said "I'm not in it for the money, my family are rich pieces of shit, and I had to work my ass off for what I have now." Implying that, I may have a more extreme view on people not putting effort into their work.

They called me a rich brat, the ONE thing I worked my entire life to shy away from.
So in response, I quit the homebrew community, completely.

Maturity had NOTHING to do with it. Experience does.

Or are you just one of those people who uses the word "age", and "mature" as a way to feel superior to other people you don't like? As an artist, I've had to deal with your type, before. All of them hate pornographic art. I wonder if there's a connection.

I'll have you know, that "Aika", the heroine of Cat Quest was originally designed for a porn game.

Cat Quest has no adult content, but if I ever work on it again (very unlikely), rest assured, I will be adding an opening splash screen with a GIANT DICK, with your name on it!

...How's that, for an ACTUAL act of immaturity?

Alp, I sincerely like what you were working on. That's all I'll say. I think I'm not the only person here or on NA that would love to see it come to life. Though I do think you'll find a bigger audience if you veer away from the porn material.

NA loves to defend their shitty games made by shitty people who don't program anything correctly, stably, or well at all. Who cares about them?

Regarding adult material, I honestly think there's nothing to worry about, and this strange fixation a lot of people have on someone who produces adult content potentially throwing it into their other stuff willy nilly is completely ridiculous. You saw all the games and mock-ups in this thread, you didn't see any explicit adult material, did you? Bingo, someone who's drawn adult stuff before is capable of drawing non-adult stuff and not injecting weiners and boobies everywhere they go! I don't understand why so many people are so weird about this.

I'm much less concerned with the presence or absence of porn---all I want to see is for Alp to stop caring so much about what others think and finish his beautiful game. That's it. I will happily buy it if it gets finished, even if it has me on a penis. I'd be honored.

Well, I wouldn't go as far to say that. I'm a rather well-known hentai artist in Japan!
(I was personally mentored by one of the most influential artists in the industry. He taught me how to animate, which was amazing.)



The reason I hadn't posted adult content here, even my NES-restricted stuff, was actually to avoid being banned for breaking the forum rule of posting pornography, relevant or not--

Also, if corporations like Disney followed that logic, then they'd have no animators!
I personally know 3 people who currently work for Disney who have or still draw porn, and even then, several of their older, retired artists were known to.


This statement is almost appropriate, the only homebrew game I *didn't* drop was an adult game that's just that. Dicks, and boobs, everywhere! But does it affect the quality? No.

This project is a birthday gift for a friend, and uses a programming trick for parallaxing. No sprites are shown here, because dicks are present. (Ignore the skip at the end, that's where I cut the recording.)


It's an adult parody of SonSon, with no pornographic content, just nudity.
It's *not* meant to be taken seriously, it's just a silly, two player arcade game.



I don't care what others think. I care how the community around a site claiming to be a "resource" to developers behaves.

That dick statement was in jest by the way, as an attempt to prove a point about my views.
Simply put, there's nothing wrong with porn.

...If I do decide to finish Cat Quest one day, it will be released quietly, and without announcement.
This was never for profit, or recognition, it was for fun. That fun is gone.

I don't really have anything useful to say... just that I'm sad that this happened.

Alp, best wishes!

Please.

Well, I'm not NintendoAge.

It's usually rendered as "living well", isn't it?


A shame about the forum rules. One wonders if there could be an easement, or if we've got a Two Internets thing going on where our chaining-of-rules goes up to the hosting entity.

Nice parallax, btw.

Exactly. We're NESdev. Just because our compos are hosted by someone from NintendoAge doesn't mean we support NA's policies in general. NESdev is about making beautiful things; NA is about collecting, speculation, and "flipping".


To which rule do you refer?

More precisely, that entailment of that rule.

Yeah, NintendoAge isn't a conclusive representation of the NES homebrewing community, or really the NES community as a whole. They're a representation of what a forum run by and full of teenagers is like, and that's about it.

As you wish.

I had been meaning to re-upload everything ages ago, but *name redacted* sent me a rude PM, and I decided not to.


Clearly you're not, you aren't willing to throw people under the bus, when they don't agree with you.


Thanks! I was rather proud of my code for that effect.

The game loop was threaded directly into the parallax logic, by running certain code after each split, and "compensating" to make sure the next split would happen with the correct timing.



Hah! Yeah. I already tore them a new one a few days ago, by speaking up, when I heard about that. To let people know that it wasn't the first time they've done crap like that, or even the last.

The NintendoAge website has been on an "artists beware" blacklist since October. This event was added to said list, as another example of why to avoid that website as a whole.

As for the compo, I was tempted to enter my WIP Super Mario Bros. clone at one point, but I've since decided otherwise. I'll release the game on its' lonesome, some time in the future.



Oh, don't give them that credit. They're barely a community.



Wow, it's been a long time! I've long-since disowned the majority of my work, shown here.

I have recently teamed up with a fellow porn-artist, and we have formed "Nosey Studios", to create our future games. Our first project? A pornographic action-RPG, with gameplay resembling Crystalis. It is being developed as a NES game.


Cat Quest is long dead, but the main character will be making a cameo appearance in our RPG, as one of the characters the Knight may choose to marry, and have children with.

I don't think I'll be using this thread, anymore. Enjoy the old archived art!

I'll be posting on my Twitter, from now on (Occasional NSFW warning):
https://twitter.com/Alp317

Besides the "OMG it's PORN!!!" criticism, did you ever get criticism from anime fans that you're work "isn't anime-enough"? I've got criticized for things like "not putting the correct number of eyelashes" or that "anime characters are supposed to be X heads tall" or that my drawing style "isn't pointy enough".

What they're saying is "It doesn't look like the anime I watch," despite that it may lie Within Normal Limits™ of anime art styles. For example, not all anime use the tall, skinny, angular style associated with bishie series. Some are rounder; trope wonks call this Puni Plush.

To shut up people who nitpick proportions, draw chibi characters. These tend to run 2-3 heads tall for children and 3-4 for adults.


I can barely draw

But in anime, leaving off the pinky is forbidden for two reasons: four is death and a Yakuza tradition.


So anyway, is there a chance that both porno and non-porno versions of a game can be released, just as Pirates 30 (2005) got an R-rated cut?

The funny thing is that most people's anime fan art tends to be pointier than the actual anime series themselves, as if they've seen so much fan art, they forgot how the real show looks like.

Actually, I haven't. If anything, my animated work has been "more anime, than anime is".
At least, that ugly modern anime style. Ugh!


Now this is an interesting question!

When I was still active on NintendoAge, Optomon had politely requested me to release an all-ages version of my Ghost's 'N Goblins parody. I told him that it would be considered, when the game was further along into development.

However! After the unpleasant community backlash, this is now absolutely out of the question.

Not every future game I develop will be pornographic, just... most of them.
(I've recently started a clean, Super Mario Bros. clone, as a side project, for example.)

That makes me sad. Your work is really incredible, and I want to share it with my friends and play the games together, but I'm not comfortable enjoying porn with someone else.