• Content Count

  • Joined

  • Last visited

About lumoludo

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I went to download the API to try it out, but it looks like your latest commit to GitHub in March deleted the actual .js file. The only thing available in the repo right now is the git files.
  2. Should this: if(get_collision_pixel.a > 255) { be a greater than? Looks like you probably want get_collision_pixel.a < 255.
  3. I've made the changes directly to the last example you shared. You can find the code to detect a segment in the create tab. The steps are: Ensure the rotation value you have exists in a 0<->X range, and not a -Y<->Y range. Divide that number by the size of each segment in rads or degrees, and then round the number down to get the segment index.
  4. I'm not sure about a collision detection function, but if you just want to know if a point (the mouse/finger position) is within a certain distance of the edge of a circle, you could use linear algebra to figure it out. If you're only dealing with circles, it will certainly be faster than using a less specific collision detection function. It would look something like this: var dist = inputPosition.distance(circleCenterPosition); var inputRange = 10; //ten pixels worth of distance from the nearest point on the circle if (dist >= circleRadius - inputRange && dist <= circleRadius + inputRange) { // inputPosition is within 10 pixels of the nearest point on the circle // Do the thing. }
  5. Yes, that's pretty much it! You can see that the soft body is build a little differently in Emanuele's tutorial: there is a lot more space than in that Matter.js demo. But, they should both give you squishy things. The important thing is the usage of springs to connect several rigid bodies. In that tutorial they are called joints, but a joint that has the ability to compress or stretch like that can also be called a spring.
  6. I haven't used any of the physics in Phaser, but I have done some game physics in the past. If you want to build a physics game that uses soft bodies like the one that tips4design linked to, it looks like you will need to use the P2 physics in Phaser. Each of those circles in that demo are circle rigid bodies, and each of the lines that connect them are springs. Once you have created all the bodies and connected them with springs, you can try changing the springs' stiffness and damping properties to change how stiff or squishy they are.
  7. For setting up your local web server, I would recommend WampServer. It's a breeze to set up (there are instructions on that site, but pretty much just involves running the installer), and using it is as simple as putting your webpage in the right folder and then pointing your browser at an address like 'http://localhost:8080/mylocaldirectory/'.
  8. I've worked with using Phaser and Cordova together to get a few games out now. By no means an expert, but I might have some ideas that could help. First, here are some quick and easy things you can try: - When you create your Phaser.Game instance, if you are currently using Phaser.AUTO as the renderer, try explicitly using Phaser.CANVAS or Phaser.WEBGL. I have found that some platforms are better suited for different renderers. Now I test the game on a whole bunch of browsers and devices and use that to determine which renderer to use when I start the game. In general, I've actually found CANVAS to perform better more often, at least for the games I'm working on. - You can try using the CrossWalk plug-in for Cordova. It's real easy to use; you just import the plug-in and re-build the project. It adds a significant size to your downloadable file, but it ensures that all devices are using the same browser, which may perform better than the stock UIWebView that iOS devices would use. In personal experience, I haven't noticed much difference, but I have read that others have seen a difference. Next are the hard things. It may just be that your code has some slow elements in it. If you are running on a fast computer, you may not notice the problems until you go to a less powerful mobile device. - Try using the profiling tools available in most web browsers. If you do a Google search for "{browser name here} profiling tools" you should be able to find some tutorials on how to pull them up. These can then help you find what parts of your code are running the slowest, and where you can focus your optimization efforts. There are a lot of other things that you can do to optimize (use kill()/revive() instead of destroy(), limit your use of masks, etc.) but these random things probably won't be of much use until you know what code is giving you the most trouble.
  9. @plicatibu Glad you enjoyed it, and we're grateful you took the time to try it! It definitely turned out to be a lot more fun than we originally thought it would. Our actual design for the game only allowed the player to select numbers directly touching each other. Due to some lazy coding, it was possible to select numbers diagonally. Instead of fixing it, we left it in as a hidden, difficult to perform trick that can be used in a pinch. We actually both play (and are hopelessly addicted to) a mobile game called Puzzle and Dragons that has a similar "trick" to it, so we felt it was sort of a tribute. =D
  10. Thanks for taking a look! When you first launched the game, did you see the hand guiding you? We have a short, wordless tutorial, but perhaps it either didn't appear for you or it wasn't easy to understand. If you could let me know which, I'd greatly appreciate it! Our goal for the tutorial in this game was 1. Use little/no text so that it would be simple for us to localize or for players to play without having English as their primary language. 2. Keep it short, so players get into the game quickly. If we missed the mark though, and the instructions are unclear, that's important to know too.
  11. We just released our latest game: Number Tumbler! (We're really betting on people liking to tumble things, I guess) It's a mathematical game about adding numbers! A number crunch in a time crunch is what we're calling it. Our unnofficial slogan for the game is "It's more fun than it sounds! Really, we swear!" ... at least one of us on the team really needs to get better at copy writing. If you're interested in trying it out, you can play it on our website (on your computer, phone, or smart refrigerator) Or download it in app form on your favorite mobile device (provided that your favorite mobile device isn't a Windows Phone) On a side note, I was just reading the Phaser newsletter yesterday and saw that Emanuele Feronato is releasing their DrawSum game on the app store. Man, we hadn't seen DrawSum before yesterday, but I guess it's just poor timing on our part we happened to just finish such a similar game at the same time. If you take the time to play it, we'd love to get your feedback! Any comments, criticisms, and (most importantly!) praise will be graciously received. Thanks!
  12. I don't see any issues with the example in the link you shared. It looks like everything moves smoothly on my computer at least. One change I would recommend to help with fluidity is in your update function. Instead of adding a fixed number to your rotation when update() is called, it is better to add a value multiplied by the amount of time elapsed since the last time update was called. This is because the update function is not guaranteed to happen at the same frequency every frame, and will happen at much different rates depending on the speed of the computer, lag, etc. The modified code would like something like this: if (rotate_triangle) triangle_bleu.angle += 3.14 * game.time.elapsedMS / 1000; This code will have the triangle rotate 180 degrees per second, regardless of whether it is running on a fast or slow computer. Angle is measured in radians here. Alternatively, you could just set the triangle's angularVelocity value in animate_canvas() and not manually change the value in the update. Setting the angularVelocity is pretty simple, and is measured in degrees per second: triangle_bleu.angularVelocity = 30;
  13. I haven't used the weapon code, but by looking at the docs it appears that a Weapon has a bullets parameter, which is a regular display group. So if you have the instance of the weapon still, you should be able to do something like this: (Keep in mind, this is just my assumption and not a guarantee. I also typed this in here manually, so there's always the possibility of typos.) for (var i = 0; i < myWeapon.bullets.length; i++) { // Print the current x and y position of the each bullet to the console var bullet = myWeapon.bullets.children[i]; if (bullet.alive) console.log("Position of bullet #" + i + ": " + bullet.x + ", " + bullet.y; else console.log("Bullet #" + i + " is dead."); }
  14. What do you mean by kill() doesn't actually kill the sprite? It should remove it from view at least. You can use either kill or destroy if you want to. You can destroy everything if you want, and you can still make a working game. The reason you would use kill is because in many cases it will be more efficient. Are you familiar with memory allocation or garbage collection concepts? It would take too long for me to explain it here, but if you don't know how they work, it may be worth doing some googling to research it. The basic idea is creating a new object causes Phaser to do some time consuming work that is hidden from you. If you revive a killed object, you get to skip that expensive step. If you destroy the object and then create a new one in its place, that expensive step has to happen again. It is especially important for games that have objects that are being removed and added often: things like bullets, constantly spawning enemies, pick up items like coins and power ups, etc. If you want to remove a sprite and never use it again, then it is best to destroy it, but if you plan on re-using it, it is a good idea to get comfortable with kill/revive now. If you design the game to use destroy now and then find out that the game is too slow later on, it can be very difficult to refactor the code to use kill/revive in place of destroy.
  15. I don't think so. Functions should really only be meant to do one thing, and revive()'s job is just to bring a kill()'ed object back into existence. You should be able to just set the X and Y coordinates manually after you revive it, or if you wanted to, you could write your own function to revive() and set the position of a sprite.