Jackolantern

Members
  • Content count

    41
  • Joined

  • Last visited

  • Days Won

    1

Jackolantern last won the day on May 18 2015

Jackolantern had the most liked content!

1 Follower

About Jackolantern

  • Rank
    Advanced Member

Recent Profile Visitors

495 profile views
  1. How to define gamesize?

    As far as having elements outside of the game area interact with your game, remember that Phaser is just Javascript. It isn't like Flash or other plugin-based solutions where your game is running in a separate sandbox. Your Phaser game is running in the same Javascript as your page is. So you can have normal JS or even jQuery-based click events fire from regular HTML buttons on your page and it can interact with your game code in any way that you want it to. Just keep in mind that by depending on HTML elements or other elements outside of the main Phaser game area that you are tying your game to a desktop browser client. This can be a major disadvantage to an engine like Phaser that excels at mobile web games and packaged mobile game apps.
  2. Need Help

    Nice stuff again! I will have to look through this code here as I am learning more about Phaser!
  3. Need Help

    Wow, very nicely done and with a very minimal amount of code, too.
  4. Need Help

    Sorry, @samid737 I actually didn't mean drawing the walls. I meant, in a fast game that doesn't need sloping collisions, you could use a calculus function to generate boxes that cover sloping walls with a certain level of accuracy. I think it is an integration except you have a predetermined amount towards the limit to keep it blocky and to prevent too many boxes from being created, but again, I meant to keep working calculus problems so i wouldn't forget it, but that didn't happen. This way you can randomly generate the sloping walls and also randomly generate collision boxes that fit good enough over the walls for the type of game. I am not sure if this is a performant strategy for Phaser, though. I just know it has been done in native game development.
  5. Kiwi.js website down?

    Whatever was going on seems to have just been a hiccup. It is back up now!
  6. Need Help

    When you need to collide with sloped, wavy or in some other way not-straight surfaces like this, the first thing to ask yourself is what kind of resolution you need. Very, very few games require pixel-perfect collision. A big factor in the decision is how fast your game will move. In a fast shmup-style game, your collision just need to be somewhat close. The game moves too fast to tell if you actually had pixels connect, so players will typically develop a "feel" for how close things have to be to collide. On the other end of this spectrum, a very meticulous, slow puzzle game where you are trying to move a marble through a maze (such as a video game version of a marble labyrinth game) is going to need to be closer to pixel-perfect because players will be able to tell. So where to begin with this really depends on the design of your game. Is that ball going to be racing down a tunnel made up of those walls? If so, you could probably just take regular square collision boxes and try to line them up as best as you can to the walls. There are some nice calculus calculations that can help you with this but I have been out of the classroom too long to tell you how to do it. I just know they do exist since it is a very calculusy question. If that ball is going to be hopping around on those walls, bouncing off of them at the correct angles, rolling down them appropriately, etc., then you are going to need a much more accurate collision scheme and a robust physics engine that can deal with sloping angle collisions. I believe P2 does.
  7. Collision detection in 3/4 perspective

    It also depends on if you are going to have obstacles above the ground that can impede the players or enemy sprites. For example, in the Streets of Rage image above, if you planned to have a wall that started a couple of feet off the ground that needed to make players crawl under it, or in some way stop them, it gets more complex. But if you don't need that, you can get SoR-style collision detection by actually using two collision boxes. The first is the movement collision box, and this is mostly around the player's feet. This helps with the design a bit, since you can block off entire upper walls as being a collision zone, giving you less to think about when you need to have a path going up into the top wall or need to give a path down into the bottom wall. Centering the movement (or "environmental") collision box at the sprites' feet allows you to set up stage collision boxes to be nearly the same as the walls and obstacles as they appear in your stage art. Then you can put another collision box around the full sprite to register collision detection for hits, etc. Of course, more collision boxes = more collision calculations. And with certain types of games this can become a problem. In a Streets of Rage type game it would not be a huge issue since you typically only have 3 or 4 characters on the screen at once. But if you needed to have bullets flying all around or dozens of enemies on screen in complex collision-based stages, this is probably not the way to go. In that kind of case I would suggest trying to find a good way to use a single collision box per character.
  8. Kiwi.js website down?

    Even though I mostly tend to use Phaser, every once in a while I go and look at the Kiwi site to see if there have been major updates or any new BluePrints. I am now getting a message that the website has been suspended by its host. It has been like that for me since yesterday. Anyone know what is going on?
  9. Dice rolling with sprite

    Ohhh, those animations @samme posted were nice. I would seriously try to work with those.
  10. Dice rolling with sprite

    Okay, I think that is actually just some nice 2D animation where they have any number of dots showing on the dice as they are rolling, and then the animations would show blank faces up on the last frame and they lay over a graphic of the dots based on a random number generator. That is my guess. Faux 3D is tough, because it leaves a lot of math up to you. I have looked before and have not found anything for Phaser that handles that kind of math for you. There are a few posts about using something like Three.js with Phaser, but I honestly wouldn't go that route. Really, if I was approaching this, you know what I would do? I would get some real dice, get a table and then rig up a camera or smartphone with an app to take strings of pictures pointing down at the table. Then I would take some series of pictures of dice rolling, find the best ones and trace them in something like Photoshop to make them better fit with your art style. Then just leave those last frames blank so you can add a graphic of the dots. And this is if you can't find any dice roll graphics available that fit your needs. I would imagine a lot are out there.
  11. Dice rolling with sprite

    The kind of difficult thing to a dice rolls are that they are 3D. Are you looking to make faux 3D dice or make a 2D animation of some kind. And if 2D, what exactly would it look like?
  12. How would you approach this

    I honestly think I would probably make each of the games separate projects. Since they seem to be discreet, the only real benefit of keeping them all in one larger "game" would be easy sharing of code assets, but if they are quite different there is not a ton of benefit there. You can of course still combine all of the graphic assets into graphic atlases or CSS sprites and load them all up-front. The loading time of the various Javascript files will likely be nearly trivial. Pros? I think it would keep each game lean and focused. It would allow your connecting pages and systems to be what they probably should be: standard web pages with the whole site setup as a standard web application. If players are mostly interacting with these connecting pages like a website where they see information and graphics, and click on icons or buttons to move around, then you will probably be ahead of the curve by simply making that a web page rather than bringing it into the Phaser game loop and managing all of that yourself. Cons? If you ever wanted to package this up as a native mobile app you will have to go with a solution that includes a DOM to power the standard web pages of your site. These of course do exist, but often these technologies tend to be all-or-nothing with either DOM or game engines. They either have a full DOM supported but are completely app-focused with little optimization for games, or they have no DOM at all and are completely game focused. By needing both, your performance for one or the other may suffer. Note that this is getting better, as I believe CocoonJS has implemented a DOM in their game-focused wrapper.
  13. New problem with collision

    This is a pretty basic problem of dying/respawning in games, and honestly, there is an infinite number of ways to solve it. Here are some examples: 1. If you are making something like a Sonic or Mario platformer, you would probably have a death animation and then restart the player a ways away from the obstacle at some kind of check point or back at the start of the stage. Checkpoints and stage start points are specifically placed in safe areas to prevent quick re-deaths. 2. If you want the player to restart near where they died, such as in most beat-em-up games, it is common to give them a couple of seconds of invincibility to get away from the thing that killed them. 3. In the same situation as #2, some platformers respawn players where they died, but instead they programmatically move the player back some and spawn them at the nearest safe location that is before the obstacle that killed them. You usually want to be sure you are respawning them before the obstacle so they don't get a free clearing of it by dying. 4. Some games combine #2 and #3 to respawn them before the obstacle while also giving them a few moments of invincibility.
  14. Smelly sprites, SpriteBatches, Emitters, and createMultiple()

    Glad you got it sorted. But out of curiosity, what is it you are looking to do with your particles having physics? Is it so that they will fill up a room, collect in an area and generally collide? It seems maybe that is the case since you talk about them being "stinky" lol. I am just asking because it sounds interesting.
  15. Smelly sprites, SpriteBatches, Emitters, and createMultiple()

    It sounds like what you need is a particle library. That is really what particles are in Phaser: a ton of tiny sprites. There is a commercial plugin for Phaser called Particle Storm that makes some really nice particle effects with good performance. It could be considered a bit on the pricier side at $32, but I thought it was more than worth the price versus writing something like it myself.