castiboy

Looks and plays pretty nicely, I really like the visual style. A few comments nonetheless: the background gets boring after a while. maybe add more visual variety in there, likes different colored tiles, or different textures. actually, while the grid structure is useful for distance evaluation, it doesn't really have an implact on gameplay, so why keep it?widescreen doesn't seem quite right for this kind of game-play, you have almost twice the visible range on one axis than on the other, but the action is the same in all directions.the shot range seems way to short when shooting horizontally (in part because of how "far away" one can see in that direction probably) maybe animate the bullets so they burn out before disappearing? that way it's also less of a surprise.the sound effect when your shots hit an enemy is too loud, it should discretely inform of a successful hit, but it's actually distracting in an already very saturated soundscape. it should contrast with the sound of destroying an enemythe sound effect when you're low on health is very annoying, and way too loud.But really nice game nonetheless!

(also on Hacker News: https://news.ycombinator.com/item?id=7899214) Hey guys, I posted about this a few weeks ago but the games weren't quite ready yet so it didn't get much attention. This time I made a video ! Please have a look at http://short.epfl.ch/paprika/ to test the games and know more about the project! I hope you like the games, and I would really appreciate any feedback concerning the framework itself, any sort of informal evaluation really. So, the story: As part of a school project I've been working on a adapting an AR markers library called Chilitags into a very simple, very easy to use, more abstract JavaScript framework called Paprika. In short, what it does is allow you to use AR markers as input for your web application (with property binding and condition triggers for position, rotation, specific orientation, visibility, card flipping, tilting, stacking.) I created 3 games/demos with Phaser which are far from perfect, but serve as experiments to test paper interaction. I hope you enjoy these and I'd love to hear what you think of them! Asteroids:http://chili-epfl.github.io/paprika/phaser_demo_3.htmlIn this game you control the orientation and color mode of a spaceship using a card. Plays like Asteroids, with color mode mechanics inspired by Ikaruga.It uses one 2-sided card and tests rotation tracking + flipping detection.Traffic Management: http://chili-epfl.github.io/paprika/phaser_demo_2.htmlIn this game you control which lane gets a green light at 4 crossroads, the objective being to let all cars through in the shortest time possible without letting (too many of) them crash.It uses four 1-sided cards and tests orientation.there's also a simpler, 1 crossroad version of it here http://chili-epfl.github.io/paprika/phaser_demo_1.html)Ball Maze: chili-epfl.github.io/paprika/phaser_demo_4.htmlIn this game you control a ball inside a baze by tilting a piece of paper as you would the ball maze. the objective is to get to the goal without hitting the walls in the shortest time possible.It uses a 1 sided card and tests tilting and tilt orientation.

One very easy way to rotate the wheel would be to simply do something like this (excuse the pseudocode): if(go right) { sprite.angle += angleDelta;}else if(moving left) { sprite.angle -= angleDelta;}Shouldn't be too hard to add in there, specially if you already have a similar "if" there for handling the movement logic. No need to think about physics really (although a bit of a bounce on landing could be cool.) Depending on

Looks pretty cool but it's hard... I would definitely move the balls almost all the way down so there's more time to react. Also: While technically not "mid-pixel interpolation," it's interpolation nonetheless (but I guess it's a matter of style really.) Have you tried it with "game.stage.smoothed = false"? (edit: nevermind, I see it's already set to false.) About upscaling in the browser: From what I understand "game.stage.smoothed" controls the rendering of scaled&rotated graphics inside a Phaser canvas (if false, they shouldn't be anti-aliased, but it looks like they are here.) Here, from what I see, the game is rendered in 32x32 canvas which is then upscaled. The standard answer to that problem should be the "image rendering" CSS property, but for whatever reason Chrome still does not support nearest-neighbor interpolation. (more info here.) Apparently there's a solution for upscaled canvas that you could try: http://stackoverflow.com/a/11751817

Hey everyone! As part of a school project I've been working on a adapting an augmented reality software library called Chilitags into a very simple, very easy to use, more abstract JavaScript framework called Paprika. In short, what it does is allow you to use AR markers as input for your web application (with triggers for position, rotation, specific orientation, visibility, card flipping.) More info on it here: http://chili-epfl.github.io/paprika/ (I would really appreciate if anyone wanted to give a shot at making a small game using Paprika, or adapting one of your existing games/demos to use it, as any feedback from developers would help me with further development. Don't hesitate to contact me privately or through this post if interested.) Anyways, my approach was to implement paper input functionality along with 2 game demos created with Phaser. These demos are far from perfect games, but were mostly done to experiment with the interaction and test the different functionality developed for the framework. But hey I'd still love to hear what you think of them! (ideally you'd have to print the marker cards but there are PNG images which you can download to your phone and show your webcam, detection is pretty robust and works just as good either way.) Asteroids game: http://chili-epfl.github.io/paprika/phaser_demo_3.htmlIn this game you control the orientation and color mode of a spaceship using a card. Plays like Asteroids, with color mode mechanics inspired by Ikaruga.It uses one 2-sided card and tests rotation tracking + flipping detection. Traffic Management game: http://chili-epfl.github.io/paprika/phaser_demo_2.htmlIn this game you control which lane gets a green light at 4 crossroads, the objective being to let all cars through in the shortest time possible without letting (too many of) them crash.It uses four 1-sided cards and tests orientation.(edit: there's also a simpler, 1 crossroad version of it here http://chili-epfl.github.io/paprika/phaser_demo_1.html) I hope you enjoy these!

The invaders example shows a nice way of managing bullets. I just adapted it for an "Asteroids"-like game I'm making it. I had to add one line though (otherwise it would run out of bullets, not being killed I believe.) bullets.setAll('checkWorldBounds', true); // <- extra line to make it work bullets.setAll('outOfBoundsKill', true);I'm running into a different problem with this code though... I want to "shoot" elements from outside the screen, and I want them killed when they exit the screen... this method kills them at creation.

Hi, thank you for the fix, I ran into the very same problem and this is a major time saver! You don't have to explicitly define the bounding box first though, you can take it as is after creating your sprite and simply translate the body by half its dimensions. Here, this worked for me: var sprite = group.create(x, y, "sprite");sprite.anchor.setTo(0.5, 0.5);sprite.angle = angle; // I'm using degreessprite.body.translate(-sprite.width/2, -sprite.height/2);sprite.body.polygon.rotate(sprite.rotation);sprite.body.translate(sprite.width/2, sprite.height/2);I agree that it would be more than useful to have an easier way of keeping the sprite and and bounding box in sync.

That's a very good question and I was looking for an answer to it as well. I did the very same thing not long ago in Flixel, where I needed to sort objects of different kinds for display (in a display group) and manage their behavior separately (in two logic groups.) Right now I'm trying to do something similar with Phaser and noticed that adding an object to two groups is not working as I expected. The example does show you how to add the _container to another group but as you mentioned, we actually want the sprites to be part of both groups, not to have groups within groups. Maybe there's a simple solution around this problem that we're not seeing... EDIT: thanks for the answer rich, that makes perfect sens. I managed to reorganize my game logic in an efficient way that doesn't require multiple object lists.