I'm one of the developers who worked on this project. Happy to answer any questions.
More info on the project here: https://www.littleworkshop.fr/projects/5milliondevs/
Great work, it really captures the feeling of Marble Madness. Its maybe to deep of a thought, but I really fancy the spin of the marble, something that the original was not conveying as fancy as your version does.
Thank you. The physics engine we're using (Rapier) really does most of the work to make the spin of the marble look realistic. But we spent quite some time tweaking the controls to make them as enjoyable as we could.
The marble has the perfect amount of friction, I'm able to "drift" around corners which feels really nice.
You did a great job. The physics seems about as enjoyable as those of Rocket League and they must've have spent a considerably larger effort.
As a MM fan, I wanted to second this. Great work, engaging enough to make me finish it and wish there were more mechanics like the catapults and enemies.
Nice work! In level 5 there are three bounce green boxes and if you fall on one, it bounces you to second, which bounces to third and you "fall into the void" like noclip through the platform and you respawn under it and instantly die forever. Buggy and not going to start from beginning. Open source it!
This was really fun. Right before this little hole on the second level, my macbook started running a bit slow and the collision detection somehow sucked the marble into the floor.
Physics collision bugs are more likely to occur during frame rate drops. We’ve tried to address this by implementing an auto-respawn mechanism to handle cases where the ball gets stuck inside a collider, but it seems this sometimes fails. Anyway, thank you for playing!
Nice work, love to know more about the technical bits: what framework did you use for 3D scene, objects? how did you handle camera movements to track the ball? What library for sound as that was a nice touch. How did you do physics? Thanks!
Thanks. The WebGL rendering is based on Three.js. We're using Rapier for the physics simulation, and Howler for the audio. Our game engine is responsible for all the controls and updating things like the camera position (which follows the position of the ball at every frame).
Why did you choose to do things this way instead of using Unity WebGL?
It's okay if the reason is, "because we make websites and the programming we know is Javascript" or whatever. It doesn't have to be about some objective comparison, like optimization or whatever, which isn't going to be true or necessarily matter anyway.
Unity WebGL is not supported on mobile and we needed the experience to be playable on both desktop and mobile browsers.
However, mobile browsers will be supported with Unity 6 web exports, still experimental currently AFAIK, but that should become a viable option soon.
> Unity WebGL is not supported on mobile.
Hmm... Unity WebGL has worked correctly on Mobile Safari since 2013. Support has probably been flawless since around 2019. It has been supported in all the ways that matter for a long time.
I wasn't aware of that. The Unity 6 Preview announcement from just this year had a lot of stuff around iOS and Android browser support:
From the article:
Android and iOS browser support has arrived With Unity 6 Preview. Now, you can run your Unity games anywhere on the web, without limiting your browser games to desktop platforms.
https://unity.com/blog/engine-platform/unity-6-preview-relea...
I should have said that it's not officially supported. For client work, we prefer not to choose an engine that may not work on a few devices and which we have no ability to fix.
I don't know if it's just my system or the particular games I've been playing, but Unity WebGL stuff always seems to take a long time to load. TFA loads seemingly instantly.
How many people worked on this project and how long did it take to develop? Nice job!
Besides people from the Netlify team who helped write the content and worked on some back-end aspects, the design and development of the game took around 8 weeks for a team of two.
Congrats on your work! You mentioned "using our custom render pipeline and shaders", can you please elaborate more on that?
add a built in timer and I bet people would speed run this thing
Thanks for playing. Actually, your time is displayed once you finish the experience (there are 5 levels in total).
During the project, we discussed adding a speed-run mode but ultimately had to drop this feature due to time constraints. However, we intentionally included some shortcuts in the level design with that intent in mind.
the purpose of the game was to force marketing upon the players. a speed run version would defeat the dwell time of the marketing on the screen. i'm sure the marketing department would not be a fan
Surprisingly, you have to sit on the opening screen for a second or so before starting every run to get the best speedrun cycle for level 3. So I would say also with fast resets, it would be enough marketing even in the speedrun lol. (Coming from someone has spent hours speedrunning it so far)
Perhaps make it such that once you've completed it at 'normal' speed all the marketing messages are disabled, enabling the speedrun.
For what it's worth our head of marketing was the one asking for a speedrun mode, but it just couldn't make the cut in terms of scope :)
and physics bugs, there are a few edge spots you can clip into and really send yourself flying!
There is a glitch on the momentum level, where the marble gets stuck behind a wall after dropping into a hole.
I got stuck in the spiral slide on the same level. I got the impression framerate glitches are affecting the collision detection (common physics implementation pitfall). I could be wrong though.
Still, very cool. Too cool to waste on marketing in fact :)
Only the OP would know for sure, but it might be the case that this never would've come into existence were it not for the project to land the messages about the company.
Yeah, sometimes the ball does some crazy things due to the way collision detection works. We tried to optimize and avoid most of the issues but it can happen.
There is code in place to respawn the ball if we detect that it's stuck inside a block or wall, which can occur due to frame drops during the physics simulation. I'll try to reproduce this issue. Thanks for reporting it!
I was being malicious and dropped down onto the hovering pink cube outside the play area on the final level. Once you roll off that pink cube your respawn point is on the cube, leaving you stuck and unable to get back to the main course.
NBD but sharing in case you want this kind of playtesting feedback!
I ran into the same infinite respawn. Here's where it happened to me:
I seem to have dropped through a wall while taking an elevator on the elevation level, it keeps respawning me in the void, so that was a game over =)
I hit the same thing. It killed me while I was dropping into the hole, then respawned me into the block, ending my game.
Did you employ any specific practices to keep it running at framerate in JS?
You might be interested in this nice write up: https://shopify.engineering/how-we-built-shopifys-bfcm-2023-...
Thats a great writeup for GPU perf improvements!
I was personally looking more for details on dealing with JS and its GC and keeping things smooth on that front.
How is the gameplay related to the information? The connection seems pretty contrived to me.
The glowing line represents a timeline of Netlify's milestones that you have to follow in order to discover their journey. No particular reason for the physics-based gameplay except to have a bit of fun.