next »

[diegzumillo]

I have a feeling I made this topic already but search yield nothing so maybe I'm just crazy.

There is a set of games I like to call grid platformers. Some people call them cinematic platformers but I feel that term encompasses a lot more games, plus that term is silly and I hate it. So the games that really fit this description are surprisingly few: flashback and blackthorne. Prince of persia and others are surprisingly not limited to a grid!

I have been thinking about how to implement a grid platformer lately. I noticed both these games I mentioned have a slated camera angle, which I thought was intriguing but didn't give it a second thought. Until I tried implementing my own system. See, if you partition the screen into a grid of cells where the player can move into. Whenever you are standing on a corner, the slant perspective makes it look like you are standing on ground, it's a clever optical illusion. Jumping to platforms straight up also looks better with the slant perspective.






Anyway, I though this was interesting and decided to share. I'm making a pico-8 prototype, but super mega simple. Not even animations, it will look like chess pieces moving around. This topic has little to do with my current problems

[diegzumillo]

Since I made this topic might as well keep it going with additional thoughts.

My first instinct when coding this was to come up with a simplified representation of the level in a matrix. For example
0 1 1 1
1 1 0 1
1 1 1 1
each index represents a cell the character can stand on. If the above cell is 1 and its neighboring cell is 0, then you can jump to it. But how to make walls? oh yeah, maybe we need additional information. Should I use the same matrix or create some kind of adjacency matrix defining how each cell is connected as well? What if I need more information in this matrix, like doors, objects, enemy placement etc? Let's break each element of the matrix into bits and blalbalba

I keep following this line of thinking for a while until I become mentally overwhelmed. For a quick prototype this might not be necessary. I can just use a tilemap and just use a bunch of if statements to ask what's underneath the player and always move by the same increments.

When performance becomes an issue, or more complex calculations need to be performed on the game grid, then I can make this matrix thing calculated from a tilemap. In any case, level design will be on the tilemap, not on an abstract matrix.

I wonder how the basic mechanics were implemented in those original games.