monteslu Posted April 25, 2013 Share Posted April 25, 2013 Did a write up on our implementation of Matt Greer's Breakouts project: http://blog.frozenjs.com/ Quote Link to comment Share on other sites More sharing options...
rich Posted April 26, 2013 Share Posted April 26, 2013 Interesting write-up, although it did feel like it was mostly about getting set-up rather than actually coding the game. The FrozenJS version feels a lot slower than impact or lime for example - I don't believe it's any less performant (although it could be?!!) but rather just that the ball appears to be moving a lot slower and visually is a bit blurry for me (Macbook Pro Retina). It still plays fine though! monteslu 1 Quote Link to comment Share on other sites More sharing options...
monteslu Posted April 26, 2013 Author Share Posted April 26, 2013 Interesting write-up, although it did feel like it was mostly about getting set-up rather than actually coding the game. The FrozenJS version feels a lot slower than impact or lime for example - I don't believe it's any less performant (although it could be?!!) but rather just that the ball appears to be moving a lot slower and visually is a bit blurry for me (Macbook Pro Retina). It still plays fine though! Thanks for the feedback. I did focus a bit on the tooling, mostly because we've spent a ton of time on scaffolding, building, testing, linting, live-reload, etc. Some of the other engines just have you include a script (which we could also do), but we wanted to share the full dev cycle. I probably could have spent a bit more on Breakout's actual code The game is actually getting 60 frames/sec in most places we tested. Funny thing about implementing the game is there aren't any rules in implementing for things like ball velocity, animation looping, or angle the ball is deflected from the paddle. So we just kinda guessed and went with what felt right during game play testing. On a couple other implementations the mobile control felt clunky. That combined with a ball moving too fast, the game didn't feel very playable. So we tried to smooth things out a bit in our implementation and make it something someone would want to play all the way through. I could probably tweak things like the sprite animation timing to make it look faster while keeping it fun to play. Quote Link to comment Share on other sites More sharing options...
rich Posted April 26, 2013 Share Posted April 26, 2013 I noticed that the Quintus demo (I think it was that one) spawned LOADS of multi balls really quickly, like it was showing-off that it could handle it easily and that some versions had multi-balls collide with each other, where-as others didn't. It's a bit of a tricky one really because once you've implemented the basics the rest (velocity, etc) is entirely up to you, which could lead to the game feeling quite different. re: tooling - all that stuff is important, but be wary of scaring off would-be adopters too. Sometimes the "include one script" approach is what you need to have them get their foot in the door. Once inside you can sell them the dream much more easily. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.