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.
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! 😋
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 :-)
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
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
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.
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!
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! 🥹
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! :)
love monument valley, very cool vid!
It's a great game. Thank you!
Nice video! I loved this game when I was younger
Thanks!!
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.
Perfect video. Thank you
Glad you enjoyed it! Thanks a lot!
Very interesting video - great job.
Thank you!
great video, just subbed 😊
Thanks a lot! Cheers!
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.
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! 😋
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?
so THAT'S why the game is so expensive wow i get it now
asfsdjifsdfii you have my undivided attention
🥲
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 :-)