Link's Walk Cycle - ALttP Engine Basics

[mdtaUK]

UPDATE: Instead of having one mega thread, I am separating out questions/observations into individual threads


I have recently been exploring some concepts on how the various tile drawing, collision, camera, and data structures work in a game such as A Link to the Past, with a view of trying to implement them as I build them in XNA and C#.

As a designer with only basic coding experience, I am relying on tutorials and example code to help me get to grips with what 'building blocks' are needed for such a project.  Ways to store level/map data and various layering techniques etc.

A Link to the Past was the very first videogame I ever saved up pocket money for and even before I was a Zelda fan from the cartoons as a kid.  So it holds a special place in my heart, and if I could build a recreation of how it functions, I would be happy.  And it would allow me to change assets to release it as its own game if it ever got to that stage.  But for now its purely as an educational experience.

Anyway...  I know people here have performed ASM hacks and have been pouring over the various nuances of the game and how it works, so I thought I would start a topic to see if people like MathOnNapkins could perhaps offer some insights from their experience with the code.  Its the basics I am looking to explore.  How tiles are drawn to the screen, how collision is handled, transferring from one map to another (when the screen scrolls from map to map), and handling character state changes, entity and object interaction, dialog, event camera controls etc etc etc.

I am not asking for code examples, or to be told how to do it, I just want to understand the concepts, with a reference to how ALttP does it.  Even if their methods are a little crazy.  And where better to ask these kinds of questions!

[mdtaUK]

Post moved to here - http://forum.metroidconstruction.com/index.php/topic,2274.0.html

[mdtaUK]

I have been looking at Link's walk cycle in a video recording, and am I right in thinking this is how it goes?

As Link moves each frame, the screen scrolls 1 pixel, and then 2 pixels?  So:
1px | 2px | 1px | 2px | 1px | 2px | 1px | 2px
etc.



And Link's walk cycle animation has 8 frames and a few extra when you start moving.
frame number  -  frame image  -  sprite movement
f1 - idle - 1px
f2 - idle - 2px
f3 - walk1 - 1px
f4 - walk1 - 2px
f5 - walk1 - 1px
f6 - walk2 - 2px
f7 - walk2 - 1px
f8 - walk3 - 2px
f9 - walk3 - 1px
f10 - idle - 2px
LOOP STARTS
f11 - idle - 1px
f12 - walk1 - 2px
f13 - walk1 - 1px
f14 - walk1 - 2px
f15 - walk2 - 1px
f16 - walk2 - 2px
f17 - walk3 - 1px
f18 - idle - 2px
LOOP ENDS

[MathOnNapkins]

Yes, because, iirc,

I have been looking at Link's walk cycle in a video recording, and am I right in thinking this is how it goes?

I think you are correct. I do seem to recall that Link's normal walk speed is 1.5 pixels per frame. You are familiar with the concept of subpixels when it comes to game engines, right? Some people really choke on the concept.

[mdtaUK]

Yes, because, iirc,

I have been looking at Link's walk cycle in a video recording, and am I right in thinking this is how it goes?

I think you are correct. I do seem to recall that Link's normal walk speed is 1.5 pixels per frame. You are familiar with the concept of subpixels when it comes to game engines, right? Some people really choke on the concept.

I am practically a noob with game development other than broad concepts.  So 1.5 pixels, would give a smooth movement velocity, but I am assuming the SNES can not display sub pixels, hence why there is a 1px - 2px staggered "rendering" of the pixels to the screen.  Or is 1.5 pixels for some other purpose like hit detection and interlacing?

What I am trying to say is, please could you explain, and correct any observations I make in this thread Sir Math of Napkin!  :lol:

[MathOnNapkins]

I am practically a noob with game development other than broad concepts.  So 1.5 pixels, would give a smooth movement velocity, but I am assuming the SNES can not display sub pixels, hence why there is a 1px - 2px staggered "rendering" of the pixels to the screen.  Or is 1.5 pixels for some other purpose like hit detection and interlacing?

The first rule of subpixels is that you DON'T SHOW SUBPIXELS. The second rule of subpixels is that if you could show them, they would be PIXELS. :)

But really, you're right in that it's a representation of a constant velocity expressed as a real number. Casual observation as you have done might indicate that there's a table of the number of pixels to move for each step in the animation sequence, but that's just not true. Most objects in this game do movement via a velocity expressed as a number of pixels, with subpixels allowed. The general limit is 15 pixels in either direction, plus up to 0.9375 subpixels per frame. The slowest speed other than 0 would be 0.0625 subpixels per frame. Which actually isn't all that slow, really. In one second, it'd move 3.75 pixels (60 fps after all), unless we're talking about a PAL cart, which would probably use slightly different speeds (I think).

What I am trying to say is, please could you explain, and correct any observations I make in this thread Sir Math of Napkin!  :lol:

Asking well separated questions will probably get me to answer a lot more easily.

[mdtaUK]

...But really, you're right in that it's a representation of a constant velocity expressed as a real number. Casual observation as you have done might indicate that there's a table of the number of pixels to move for each step in the animation sequence, but that's just not true. Most objects in this game do movement via a velocity expressed as a number of pixels, with subpixels allowed. The general limit is 15 pixels in either direction, plus up to 0.9375 subpixels per frame.

I am trying to replicate bits of Zelda 3 in XNA as a way of learning and building my own Zelda style game (eventually)  So I am making the game at 3x the size (and 16:9) and it would be the same as me using a float 4.5f value to match the speed, and not worry about pixel precision matching, as XNA supports sub-pixel positioning.

[MathOnNapkins]

I mean, that's up to you how you represent it. But if you're trying to replicate the spirit and feel of the original game, I'd preserve what you can, and leave it as 1.5 internally, multiplying by 3 when you need to do the actual animation. But that's just me... :colonrightv:

[mdtaUK]

I mean, that's up to you how you represent it. But if you're trying to replicate the spirit and feel of the original game, I'd preserve what you can, and leave it as 1.5 internally, multiplying by 3 when you need to do the actual animation. But that's just me... :colonrightv:

Initially I will be making use of the ALttP sprites and tilesets while building the various movements and interactions.  But 256x244 is far too small a screen size to be working with, so all the tile sizes and pixel amounts I am multiplying by 3, so  the 16x16 tiles that make up Link are now 48x48.  So if Link moves 1.5px every frame (60fps) then at 3 times the size it would be 4.5 pixels a frame.  Also at 16:9 aspect ratio, my screen size is 1050 x 591.

[snarfblam]

If you're trying to write a game engine in XNA, I think it's important to understand the difference between duplicating the feel of an SNES game versus duplicating the under-the-hood-mechanics of the SNES game. Granted, it's fun to delve into and understand what makes these games tick, but with XNA you have a whole different (and much bigger!) set of features out of the box.

For example, XNA is vector based, which means you get scalable graphics for free. You can write a game engine that can work with any size tileset, so you can scale it down for Windows Phone and scale it up for XBox. If I were you I would be thinking in terms of tiles per second rather than pixels per frame. If you store the player's position as a float (maybe scaled so that 1.0 = 1 tile), you don't need to worry about something like a 1 px, 2 px pattern. Just move the player by (elapsedGameSeconds * tilesPerSecond).

[mdtaUK]

I understand that XNA is a much richer offering, but my goal is to try to replicate the actions, capabilities, functions, and style of the game.  Paying attention to the small details from ALttP is my way of answering the little questions such as, How fast should the player go, or what kind of objects can the player interact with.

I am not going to be drawing individual pixels onto the screen as with the SNES, nor will I be keeping all the limitations of the hardware (limited colours, only 3 screen layers, storing level data as bits and bytes, etc).

I am not a programmer really, nor am I a pixel art god.  I am just a Zelda fan, learning C# while designing WP and Win8 apps.  And this project will focus on little things like loading in a map, collision types, drawing the player sprite (made up of at least 5 individual sprites offset from each other AFAICT), and interacting with objects.

[Mon732]

This page might be worth a look at if you need to get an idea how to use C# and XNA. It helped me quite a bit.

http://xnaresources.com/default.asp?page=TUTORIALS

[mdtaUK]

I am splitting this thread up into multiple threads to make it easier for people to answer individual questions.