How do you optimize for KSDS?

I don't have a DS myself, and therefore cannot test my levels on KSDS. I was wondering what sort of changes I should make to my levels if I were to release KSDS versions of them.

For example, in my latest release there are animated sequences that flash by. I know an entire room cannot be seen at once when played on KSDS. So, these animated scenes won't work too well on that platform. I'm thinking I should allow the player to advance the action rather than have it timed. And how does the game handle focus? If I hide Juni in the left-bottom corner and the game focuses there does that break the immersion?

Also, since it uses mp3's instead of ogg files, should I export all the custom ambiance and music ahead of time? Would that just serve to confuse the KSDS enthusiasts? Do they go in the typical folders?

I'm sure there are other things I'm completely unaware of. (By the way, this is not a promise that I will release KSDS versions of my levels.)

As for the cutscene/focus problem: If that is indeed and irrevertable problem, you could make two versions of the cutscene, one centered in a KSDS sized window in the bottom left, and another in the full KS style. All it would take to switch between KSDS cutscenes and regular cutscenes would be a flag warp, with the flag set (or not) by user's choice at the beginning of the level.

Just my two bits.

These are the things you have to keep in mind:

• The screen focus is on Juni all the time. For example, in a A Knytt in Time, the 'Some Time Later' screen isn't centered, so you can read the text either by scrolling the view or by looking at the full screen view in the top DS screen (which, in this case, was barely readable)
• Switching from a screen to another one causes a noticeable delay (more than one second, but I guess it depends on the flash card you use); therefore you should adjust your level to that, for example by avoiding Shift sequences or the player to need to switch screens often (like a jump up one screen and back down)
• Areas with too many objects may cause slowdown. The point at which this starts to happen is surprisingly high, if you consider the limitations of the DS, but it's still something to keep an eye on. For reference, I don't think A Knytt in Time had that problem
• Try not to include very long music tracks, they may cause the game to freeze. I don't remember the limit, but I guess under one minute length is fine

Also, regarding the OGG to MP3 conversion, you shouldn't do that yourself: KSDS users still have to unpack the level by themselves before putting it on a flashcard, so having them do the conversion isn't too much of a bother. There's also very few of them, and including the MP3 tracks in the level just for them isn't worth the extra size of the .knytt.bin file, I'd say.

Basically, when you want to play a normal KS level in KSDS, you have to unpack the .knytt.bin file using a PC and convert all .OGG sound files. The music has to be converted to MP3, but the ambience/cutscene sounds needs to be converted to uncompressed RAW audio (8-bit signed, mono, 11KHz). So, if you want to release a separate DS-optimized version of your level, this is the first step. This will save the players a lot of trouble if there are a lot of custom music/ambience files in your level.

Then, you can follow AA's advice and edit your level a bit. KSDS doesn't handle screens with lots of enemies very well, so you might want to remove a few of them. Screen transitions are slower than in the PC version, so automatic shift sequences should be avoided (you could replace them with normal cutscenes). Also, it's easy to run into memory problems if the custom music tracks are too long and/or if file size is greater than 1.3MB. Try lowering frequency and bitrate to reduce the file size (also, downmixing from stereo to mono). 48-32Kbps 22KHz should be fine in most cases.

Finally, the cutscenes can be formatted to fit the DS dual screen. Instead of using a single 600x240 image for each frame (which you need to scroll using the tactile screen), you can include two 256x192 images. Name the files Scene#A.png and Scene#B.png (# being the number of each frame). The Scene#A.png image will be displayed in the upper screen, and Scene#B.png will be displayed in the lower one.

Very interesting. Thanks guys. I had no idea that you could see a zoomed out version of the room in the top screen. I thought there was some kind of automap up there. I like that you can take advantage of the dual screens with special cutscene files. However, making cutscene images is excruciating for me. I'm not a cartoonist and it's obvious. I'd hate to do it twice.

Overall, I'd say my levels are bad candidates for conversion. I use a huge amount of shift-work. I like the music tracks to fit the areas, and I lean towards large areas. I think the auto cut-scenes are kind of gimmicky,  so that shouldn't be a big issue. Oh well, I'll keep these things in mind when designing future levels, but I can tell you the PC version will take priority.

I had no idea that you could see a zoomed out version of the room in the top screen. I thought there was some kind of automap up there.

There's both of them: you can switch between screen view and automap anytime. The screen view also has markers for enemies and knytt/fluff, if that could influence your level design.

I only have a couple of things to add (very detailed instructions, guys!  ):

• Long music tracks are fine, as long as users convert them to a suitable format that is smaller than ~1.3 Mb. For example, the main music track of "Sky Flower" is 8:02 long, but compressed to 16kbps/22kHz it works (OK, it does not sound very good, but it works...and it is soooo beautiful...).
• KSDS can handle screens with plenty of enemies, although problems usually arise when many enemies shoot bullets (consume lot of CPU) or when there are many different types of enemies in one screen at the same time (consume VRAM memory)

Then, rain shouldn't be a problem? I typically use 25 of them, enough to cross the top of the screen. Plus a smattering of drops (makes it appear as though it was already raining when you enter.) The same thing goes for snow. I have to assume the processing is more simple than bullets that arc, float randomly, seek Juni, etc.

Then, rain shouldn't be a problem? [...] The same thing goes for snow.

Rain & Snow & other particles are not a problem: as you said, their management is more simple, and they are optimized to not overload the CPU/VRAM too much  .