I’d like to share with you the news about the release of my recent game Not So Flat. This game is a short experimental puzzle platformer where your task is to complete levels by finding and opening an exit portal that leads to the next level. Sounds ordinary, but the “platformer” component of the gameplay is not very conventional (i hope the gifs convey it well):
I’m not sure if the idea is unique somehow, so I’m hoping for your feedback to check this. The game is free, you can grab it at Itch.io (link below). Keep in mind that the game is a proof of concept, so there’re not many levels, but those that exist are quite challenging.
Stand alone version works well here and is very optimized (small).
Downloaded but have yet to check out.
Will give feedback when I play it.
Gifs look great.
Thanks guys, but I’m still not sure that the web version is a good idea. The latest Chrome doesn’t support web player out of the box, and the WebGL build seemingly lacks support for a full-screen glow. To me these problems are more serious than the need to download an archive
Looks awesome.
Couple,of questions. Are you going to make a mobile version? And can you reveal how you are creating the effect of how the player changes panels? So cool. I am guessing cameras, where their view is being projected onto a particular panel?
I have no plans for the mobile version. The game has ended up being quite short, so I don’t feel like it’s worth spending another few weeks on porting it. Maybe later, if there would be more levels.
The idea behind the algorithm is fairly simple and has nothing to do with the cameras The character is a gameObject with a quad attached to it. Each frame I cast many rays from many points and in various directions to detect distances, then having that information and player input I calculate the movement. After the game object has been moved, the algorithm adapts the quad mesh: recalculates vertex positions and uvs, if needed. The moment of switching planes is just a specific case in that process, when the algorithm detects that the gameObject needs to be rotated by 90 degrees (or similar, depending on the case) around some axis. When it’s done, the quad mesh, again, gets adapted to the new gameObject position.
The Offset shader property helps the quad stay ontop of everything else in the level because the geometry is coplanar. In earlier versions I used to offset the quad away from the panel quad by a small amount, but that led to some problems that were more difficult to solve than to just make the character move in the panel planes all the time.
I’m planning to make another devblog post about the technical details and will post a link here.
Not sure what did you actually suggested (just abstract “projection of camera view”), please be more specific Anyway, mesh manipulation is the least expensive step overall - recalculating 4-6 vertices is a joke. Distance calculation needs to be performed in any case to detect in what directions the player is allowed to move. Considering the fact that the game is small and not computationally complex, casting several rays every frame is also not a big performance hit.
I was thinking, for a level, you could map it out, in 2D. A single plane where all objects exist, player at his start pos, all blocks and portals.
Then, you could have 6 cameras, each designated to a specific area. Then each camera projects it’s view onto a specified side of the game “cube”.
:? I have not worked with rendertexture and I don’t know if this is even practical, but it would potentially make level building a snap and save in calculations. Really, it’s just how I imagined you had done it.
But the level is not a cube It has more than six sides, so, if I understood you right, we’ll need as many cameras as there are level planes, each rendering it’s own plane. Also, I can’t imagine how everything else in this method should be implemented. Texture projection, if involved somehow, wouldn’t make distances calculation easier anyway.
