Scrolling KS?

  • 2 Replies
  • 5523 Views
*

Offline Pumpkinbot

  • 1134
  • 20
  • No terrain is too hard. Not even dragons.
    • View Profile
    • My DeviantART page
Scrolling KS?
« on: January 17, 2011, 01:14:22 »
I was just thinking about something. I prefer to play Knytt Stories on the DS with KSDS instead of the computer because I like how it scrolls. KSDS, unfortunately, has a small resolution and a lot of glitches. Would it be possible to make a Knytt Stories mod that makes the screens scroll instead of with transitions? You could add kind of barriers where you don't want the screen to scroll or something so you wouldn't see into an adjacent room that's supposed to remain a secret or is part of a shift sequence.

Would this be possible? If so, how game-breaking would it be?
A God, a Messiah, an Angel, a King, a Prince, and an All Terrain Vehicle.

*

Offline Pie_Sniper

  • 109
  • 14
    • View Profile
Re: Scrolling KS?
« Reply #1 on: January 17, 2011, 06:55:08 »
It is certainly possible (if challenging to implement -- I have never worked with MMF), but I think it would be impractical for many existing levels. A typical level does not attempt continuity between adjacent screens, especially if they cannot be traveled between directly, and in some cases even if they can. The jarring graphical transitions would degrade the quality of the experience. Modifying the scrolling mechanics with special objects or world.ini notation could be confusing (for example, jumping in one place would not cause any scrolling, but a few squares over it would) and would draw attention to lack of continuity or hidden rooms.

Most levels would have to be modified in places just for smoothness and playability. Many screens are surrounded by unreachable void areas that, presumably, should be shown the player is near to the edges of those screens. Although the program could simply stop scrolling upon reaching a void, it would again draw attention to the limits of the world (and what about those few surreal levels that rely on players passing through void screens?). Ambiance changes would be more noticeable if they were not paired with screen changes, though perhaps two neighboring ambiances could be blended together (which poses problems for levels using ambiance as looping music). Some designers use screen changes to incorporate surprise into their levels, which could be lessened by scrolling (and, again, blocking scrolling would signify that a surprise was coming, which is a paradox). Parts of some screens could also become impossible to see. For example, if a screen only had low ground and yet had important puzzle information at the top, the puzzle could be rendered insolvable.

There could also be issues with warping and shifting. Imagine five screens in such a configuration:
Code: [Select]
_1_
234

5
Let's say screen 2 has an exit on the right and screen 4 has one on the left, but while the exit in screen 2 simply leads to screen 3, the exit on screen 4 warps to screen 5. If you are at the bottom of screen 1, what should be displayed below you? This is, admittedly, an obscure case, but with the convoluted shifting/warping of many levels available, I have no doubt issues would arise, and using the scroll blocking technique suggested would indicate that the world is not actually linear, a fact that level designers often try to conceal.

Finally, it is important to note that Knytt Stories does not keep track of any other screen than the one you are in. This is why creatures instantly reset when you leave a screen and reenter or shift to an otherwise identical screen. Besides adding to the amount that the program must keep track of at any one time, it would have to be determined when to release such information -- should it act on individual objects or entire screens, and should it happen immediately when they are out of view or at some arbitrary distance? The exact manner would influence designers' choices.


However, all of that said, I think that levels specifically designed for the mod, with these caveats kept in mind, would definitely be excellent and highly entertaining, and it would be awesome to see such a mod developed. In fact, in finding all the issues present in existing levels, I have imagined an exquisite scrolling level that would take complete advantage of the new gameplay aspects that would be introduced. Perhaps someone will someday take on the project.

*

Offline egomassive

  • 1852
  • 250
    • View Profile
    • egomassive games
Re: Scrolling KS?
« Reply #2 on: January 17, 2011, 07:14:56 »
Pie_Sniper posted while I was writing, but I've read the source code so my post is a little different.

I'm going to say it's possible, especially since KSDS does it within screens. However, extending the scrolling to multiple screens is no easy task. The one screen at a time view is a fundamental component of the game engine, and much of the game was designed for this framework. Issues I can think of off the top of my head:
  • Screen construction is preformed in whole screens when screens are changed. You don't notice the performance drop because of the switch. Constructing screens as you scroll, presumably for 3 screens at a time depending on the direction you're heading, would have noticeable performance issues. So, it probably needs a new map building routine with limitations to 2 tilesets per contiguous area.
  • Certain enemies that float off screen, e.g. spiked blocks, will delete if they move a certain distance from the stage. This is part of a default property in MMF2. Objects that don't need this function enabled may have it. All objects will need to be checked and updated to prevent premature deletion.
  • Others objects work in sets to increase performance. If you have 2 seed shooting flowers on different rendered screens, then the one that spits may not be in view. Every objects behavior will have to be examined and rewritten, so that only objects in the current stage* are active.
  • Warps and flags will have to be pre-checked so the correct screens are rendered. But, what happens if warp left is set and you just came from the left? The last screen is still in view. How are repeating rooms handled? With flags, If the next screen is already rendered and partially in view when a flag it depends on is tripped, what happens?
Long story short, I think you'd be better off making a new play state** from scratch and borrowing code from the old play state, like the character movement engine.

*The visible play area.
**As opposed to the menu states, install state, etc.