One topic that didn’t make it into the final video is just how much work goes into the aesthetic side of Monument Valley’s perspective puzzles. Beyond the clever mechanics, the visual design plays a huge role in selling the illusions. For example, shadows and lighting must be carefully controlled to avoid breaking the effect. In my recreation, I built a custom shader to color each face of a platform (top, left, and right) independently, mimicking the lighting and shading techniques from the original game. The team behind Monument Valley likely crafted countless subtle details like these, resulting in their iconic and seamless style. Monument Valley is a masterclass in blending technical solutions with artistic goals to create something truly unique. This video marks the beginning of a new series where I’ll dive into fascinating game mechanics and (attempt to) recreate them. If you have suggestions for future topics, feel free to share them on Discord. Thank you for watching! I hope you enjoyed the video as much as I enjoyed making it.
Really like how you explained this. I knew the game NEEDED orthographic projection and figuring out how paths connects based on object rotation and camera rotation
That's an interesting and pretty straight forward way to solve the problem! It seems a bit finicky, puzzle games usually have a pretty well defined core and generate the geometry from that. But as development progresses it usually ends up in a healthy blend of state machines and theatre illusions anyways. Hadn't thought about the rendering side of things, making it seamless is an impressive feat, especially when you consider shadows, gradients etc. The choice of a minimalist style helps a lot, makes a lot of sense now. Great job and thank you! Best regards!
oh monument valley, i always could recognize the game from screenshot alone, even though, i didn't know its name yet, thats powerful! also, i remember following your steps to creating this video in the discord, and i have to ask, is creating a devlog series on youtube even worth it? or should i just share my game around in discord servers, like i did with your server (yes i was that one to first post on the feedback channel!)
Thanks for the comment :) Honestly, I have no idea, hehe. I guess it depends on what you're hoping to achieve... If you ever figure out the perfect approach, let me know :P
I would watch Jonas Tyroller's interview-video on game marketing! It is very pragmatic and I think it answers your question way better than I could with a comment.
Wait, the level designer decides when things are connected and has to manually edit that in? Isn’t that quite error-prone? Could perspective calculations be used to make that determination automatically?
It's only my assumption, I can't speak for the actual game, but I'm pretty sure it's just easier to do it manually... any ideas on how to make it automatic? It's an interesting challenge for sure!
With the projection to 2d you could at least detect all overlaps and then choose the connections. I think the easiest way to do this would be to assign special colors that are not rendered to each surface and let those that abut be connected in the graph. You’d have to set those colors but it’d be a step up from if (lever in position A and walkway in position B) {connect()}. Beautiful video btw
@@NewbieIndieGameDevMaybe it would be possible to have a few grids of possible faces, where each square face of a body that isn’t at an in-between angle, and is visible to the camera, corresponds to a face on one of these 3 (or more?) grids. When there is a body which has a face corresponding to a face in one of these grids, that face of the grid is active. Then, say the player character can move between two adjacent faces in the same grid when the two faces are both active. Ah, but this doesn’t yet handle when a player has to walk behind things… Well, if the player is walking behind something, the faces of the thing that is in front of them belong to a different grid, right? Otherwise it would look like something they should be able to walk on instead of able to walk behind it, right? So maybe if you just counted a face of a body/object as being “visible” when it is facing the camera rather than away from the camera? Of course, for this to make sense there needs to be a way for which grid the player is on to change. This could either be by having the player’s actual location be tied to the bodies/objects rather than the grids, and having them rotate, or by having special objects with curves or something that connect the different grids.
It depends on how you store your level data. Here we have two representations. The visual and the navigation. The navigation graph actually represents the level's geometry. So a next step would be to edit at the graph level for level data, and generate the visuals from that. But then you would basically need to DIY your own level format along with tooling/level editor. Which, depending on your scope, might not be worth it.
If you consider the patches to all be "the same space" then the add/remove paths becomes simpler no? If at the 4:08 mark the last node on the blue path and the patch node prior to the rotating red are considered the same when the red is in that orientation there's a continuation of the path. When the red is at 90 degrees (5:13) then the path will be automatically broken.
I‘m really intrigued by the whole „render layers“ solution. You said it like it’s not a big deal, but some object need to be in front of and behind the same object at the same time! Did you just split the geometry into more parts where needed? Are the layers of the objects fixed or do they change on runtime?
Haha all great points! And the answer to all these questions is yes! 😂 Indeed, in the video I don't really get into it, but in some cases even more layers are required, and sometimes they have to be dynamic in some way, for example making objects change layers as the architecture evolves. That said, I only needed to introduce this complexity for very specific interactions, for most cases there was no need. Let me know if this helps, and great catch! 😋
In the original game there are some moments where the camera changes angles, if I remember correctly (maybe it's the level that rotates?). I was curious to see how you would implement that using your method.
@@NewbieIndieGameDev It wasn’t as I remembered as it’s been a very long time since I last played the game. But I think I was referencing to the whole map that rotates at certain parts in the game. As it can be seen at 14:18 in this video: th-cam.com/video/u06z3FItlhU/w-d-xo.html But maybe as you said at 6:17, it’s just that the blocks have been done really well in a way that doesn’t break the whole illusion when the whole map starts to rotate.
With this approach, it is perfectly fine to rotate or move a platform while the character is standing on it. That said, the original game limits this behavior in most cases, I'm not sure why... maybe to make the experience a little less complex for the player?
This is such a beginners way of trying to implement this and it's just not correct at all. half way through your video, I've noticed practically everything you said is incorrect about how this game should be designed. although, you are correct about perception tricks within the game world and this is a valid way to achieve this effect, it is simply not the correct way to do it, and you are educating people poorly becasue of it.
Can you give any _specific_ examples instead of just grilling the OP? Without those it sounds just like "I'm clever, you're stupid" - even if your point is actually valid.
@dman-tm What a strange comment... Please watch "The art of monument valley" by GDC 2025. The original game designer explains how they created the game - and it's exactly how it is explained in this video by Newbie Indie Game Dev. Btw. it's by far my favorite Android game and after watching this explanation I can't wait to replay this game after quite a lot of years.
Puzzle games that are grid based are usually represented using integers, then used to generate the world coordinates for rendering. In that first integer representation it should be pretty straight forward to calculate the possible paths automatically at build time, instead of manually like OP is showing. However! I think the most important factor is getting projects finished, so whatever technique that builds momentum and gets you there is the correct answer :-)
@@ivanmoren3643 You guys obviously do not understand how impossible these buildings (like Escher's optical illusions) in this genius game are. There's no way to linear move in such a world. Of course you can move partially in a straight line... but then you would NEVER reach the WRONG sides of the buildings :-)
@@kpunkt.klaviermusik I hear you, all I'm saying is that you don't need to manually calculate which moves are possible from a given state. The combinatorics of that would be a nightmare when developing the game further, especially with the dynamic parts of the game (totems etcetera). You just need a more mathematical model as your base. It is a similar problem domain to a game like Fez.
One topic that didn’t make it into the final video is just how much work goes into the aesthetic side of Monument Valley’s perspective puzzles. Beyond the clever mechanics, the visual design plays a huge role in selling the illusions. For example, shadows and lighting must be carefully controlled to avoid breaking the effect. In my recreation, I built a custom shader to color each face of a platform (top, left, and right) independently, mimicking the lighting and shading techniques from the original game. The team behind Monument Valley likely crafted countless subtle details like these, resulting in their iconic and seamless style. Monument Valley is a masterclass in blending technical solutions with artistic goals to create something truly unique.
This video marks the beginning of a new series where I’ll dive into fascinating game mechanics and (attempt to) recreate them. If you have suggestions for future topics, feel free to share them on Discord. Thank you for watching! I hope you enjoyed the video as much as I enjoyed making it.
it would be extremely awesome if you recreated viewfinder's mechanics :0
@AdventureMase Such a good mechanic. I have it on my list, I'd love to give it a try! Thanks for the suggestion!
Really like how you explained this. I knew the game NEEDED orthographic projection and figuring out how paths connects based on object rotation and camera rotation
Thank you very much! Glad you liked it.
Monument valley mentioned 🔥🔥🔥🔥🔥 this game is so relaxing
A great first video of what I’m sure will be an awesome series! I can’t thank you enough for making stuff like this 💚
Wow, thank you so so much! Both for the donation and the kind words, it truly means a lot.
One of the few channels where I turn on the notifications and actually watch every video! Fantastic work!
Wow that's so nice, thanks a lot! 🥹
Monument valley is one of my favourite series. I've only finished the second one and I found the game to be so beautiful
Such a good game.
That's an interesting and pretty straight forward way to solve the problem! It seems a bit finicky, puzzle games usually have a pretty well defined core and generate the geometry from that. But as development progresses it usually ends up in a healthy blend of state machines and theatre illusions anyways.
Hadn't thought about the rendering side of things, making it seamless is an impressive feat, especially when you consider shadows, gradients etc. The choice of a minimalist style helps a lot, makes a lot of sense now.
Great job and thank you!
Best regards!
Thanks! Cheers :)
never expected to see a video on this masterpiece of a game
That's fantastic!
It's also an excellent idea to try to copy something you admire so that you learn more about it.
Thank you! Cheers!
oh monument valley, i always could recognize the game from screenshot alone, even though, i didn't know its name yet, thats powerful!
also, i remember following your steps to creating this video in the discord, and i have to ask, is creating a devlog series on youtube even worth it? or should i just share my game around in discord servers, like i did with your server (yes i was that one to first post on the feedback channel!)
Thanks for the comment :) Honestly, I have no idea, hehe. I guess it depends on what you're hoping to achieve... If you ever figure out the perfect approach, let me know :P
I would watch Jonas Tyroller's interview-video on game marketing! It is very pragmatic and I think it answers your question way better than I could with a comment.
Absolutely fantastic video! Thanks for making it!
Thank you for the kind message!
Another great video! I like your work! Thank you for sharing!
Thank you!!! Cheers! :)
I like your the editing style 🔥🔥
Thanks! I work with talented people 🙇
love monument valley, very cool vid!
It's a great game. Thank you!
Nice video! I loved this game when I was younger
Thanks!!
Looking forward to watching you reach and surpass 100k subs!
Thanks for the words of encouragement! :)
Great explanation!
Glad you think so! Thanks!
Perfect video. Thank you
Glad you enjoyed it! Thanks a lot!
Excellent story telling
Many many thanks!
Underrated
🥰
Quick note: you can also use sorting groups and not layers to determine the render order. *Should* work in 3d.
Great video!
Thanks!!!
Very interesting video - great job.
Thank you!
great video, just subbed 😊
Thanks a lot! Cheers!
Awesome video!
Liked and subscribed.
Thank you so much!!! Glad you liked it.
Wait, the level designer decides when things are connected and has to manually edit that in? Isn’t that quite error-prone? Could perspective calculations be used to make that determination automatically?
It's only my assumption, I can't speak for the actual game, but I'm pretty sure it's just easier to do it manually... any ideas on how to make it automatic? It's an interesting challenge for sure!
With the projection to 2d you could at least detect all overlaps and then choose the connections. I think the easiest way to do this would be to assign special colors that are not rendered to each surface and let those that abut be connected in the graph. You’d have to set those colors but it’d be a step up from if (lever in position A and walkway in position B) {connect()}.
Beautiful video btw
@@NewbieIndieGameDevMaybe it would be possible to have a few grids of possible faces, where each square face of a body that isn’t at an in-between angle, and is visible to the camera, corresponds to a face on one of these 3 (or more?) grids. When there is a body which has a face corresponding to a face in one of these grids, that face of the grid is active. Then, say the player character can move between two adjacent faces in the same grid when the two faces are both active.
Ah, but this doesn’t yet handle when a player has to walk behind things…
Well, if the player is walking behind something, the faces of the thing that is in front of them belong to a different grid, right? Otherwise it would look like something they should be able to walk on instead of able to walk behind it, right?
So maybe if you just counted a face of a body/object as being “visible” when it is facing the camera rather than away from the camera?
Of course, for this to make sense there needs to be a way for which grid the player is on to change. This could either be by having the player’s actual location be tied to the bodies/objects rather than the grids, and having them rotate, or by having special objects with curves or something that connect the different grids.
🤯😂
It depends on how you store your level data. Here we have two representations. The visual and the navigation. The navigation graph actually represents the level's geometry. So a next step would be to edit at the graph level for level data, and generate the visuals from that. But then you would basically need to DIY your own level format along with tooling/level editor. Which, depending on your scope, might not be worth it.
If you consider the patches to all be "the same space" then the add/remove paths becomes simpler no? If at the 4:08 mark the last node on the blue path and the patch node prior to the rotating red are considered the same when the red is in that orientation there's a continuation of the path. When the red is at 90 degrees (5:13) then the path will be automatically broken.
Very interesting behind the scenes :D
Glad you enjoyed
I‘m really intrigued by the whole „render layers“ solution. You said it like it’s not a big deal, but some object need to be in front of and behind the same object at the same time!
Did you just split the geometry into more parts where needed? Are the layers of the objects fixed or do they change on runtime?
Haha all great points! And the answer to all these questions is yes! 😂 Indeed, in the video I don't really get into it, but in some cases even more layers are required, and sometimes they have to be dynamic in some way, for example making objects change layers as the architecture evolves. That said, I only needed to introduce this complexity for very specific interactions, for most cases there was no need. Let me know if this helps, and great catch! 😋
so THAT'S why the game is so expensive wow i get it now
What did you use for all the animations? Everything is so smooth and cool
Mainly Adobe After Effects, thanks!
Wow is amazing it makes it feel much harder to get into programming is it ?
What knowledge do I need
You could make a platformer or snake with impossible architecture.
Cool idea
In the original game there are some moments where the camera changes angles, if I remember correctly (maybe it's the level that rotates?). I was curious to see how you would implement that using your method.
Hey! Do you have an example for me to check out?
@@NewbieIndieGameDev It wasn’t as I remembered as it’s been a very long time since I last played the game. But I think I was referencing to the whole map that rotates at certain parts in the game. As it can be seen at 14:18 in this video: th-cam.com/video/u06z3FItlhU/w-d-xo.html
But maybe as you said at 6:17, it’s just that the blocks have been done really well in a way that doesn’t break the whole illusion when the whole map starts to rotate.
Maybe sketch ideas first...
...and do rotators function when a character is standing on it??? I do want more levels!
With this approach, it is perfectly fine to rotate or move a platform while the character is standing on it. That said, the original game limits this behavior in most cases, I'm not sure why... maybe to make the experience a little less complex for the player?
I can't remember the name of the game or the creator but there was a similar game with a character that wore a Fez hat
Are you thinking of FEZ? 😝
@NewbieIndieGameDev lmao was it actually named after the hat? 😅
I could have sworn it started with "ortho-" haha
Didn't somebody make a video just like this a few years ago?
* 5 years ago:
th-cam.com/video/hetaWVfaLQc/w-d-xo.htmlsi=6erzVVeeYzi9dTjK
Yes, that's a great video! You can find more related videos that I enjoyed linked in the description in case you are interested.
🫶
asfsdjifsdfii you have my undivided attention
🥲
Your mic needs a pop filter or put a high shelf filter on your voice audio because the ess is highly distracting
The Editing is hat's off
Thank you!
This is such a beginners way of trying to implement this and it's just not correct at all. half way through your video, I've noticed practically everything you said is incorrect about how this game should be designed. although, you are correct about perception tricks within the game world and this is a valid way to achieve this effect, it is simply not the correct way to do it, and you are educating people poorly becasue of it.
Can you give any _specific_ examples instead of just grilling the OP? Without those it sounds just like "I'm clever, you're stupid" - even if your point is actually valid.
@dman-tm What a strange comment... Please watch "The art of monument valley" by GDC 2025. The original game designer explains how they created the game - and it's exactly how it is explained in this video by Newbie Indie Game Dev. Btw. it's by far my favorite Android game and after watching this explanation I can't wait to replay this game after quite a lot of years.
Puzzle games that are grid based are usually represented using integers, then used to generate the world coordinates for rendering. In that first integer representation it should be pretty straight forward to calculate the possible paths automatically at build time, instead of manually like OP is showing. However! I think the most important factor is getting projects finished, so whatever technique that builds momentum and gets you there is the correct answer :-)
@@ivanmoren3643 You guys obviously do not understand how impossible these buildings (like Escher's optical illusions) in this genius game are. There's no way to linear move in such a world. Of course you can move partially in a straight line... but then you would NEVER reach the WRONG sides of the buildings :-)
@@kpunkt.klaviermusik I hear you, all I'm saying is that you don't need to manually calculate which moves are possible from a given state. The combinatorics of that would be a nightmare when developing the game further, especially with the dynamic parts of the game (totems etcetera). You just need a more mathematical model as your base. It is a similar problem domain to a game like Fez.