• Content Count

  • Joined

  • Last visited

  • Days Won


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

2301 profile views
  1. I have not seen one between Phaser-like HTML5 game frameworks. Most of the ones I have seen have been between things like Construct, Game Maker Studio, etc. Also, Phaser just came out with a major version update earlier this year so most anything you would find online now would likely be comparing an outdated version of Phaser. It wouldn't be that hard to make some tests, though. Most of the ones I have seen are just empty rooms that drop a ton of sprite balls with physics on them so they bounce on each other. Making something like that would also give you a chance to see how the engine basics are between several frameworks to check which coding and design styles work best for you. And if you did put the resulting demos up on a website, I am sure it would get some traffic and some kudos
  2. This is not actually how you would create a multiplayer game. You would not run Phaser as-is on the server, since it is doing all kinds of things that you don't want done on the server, such as managing sprite images, drawing the screen, etc. It is crashing with a "window is not defined" error because Phaser is looking for the window object to do all of those things. You will also need to work with websockets, which is not something Phaser will do out-of-the-box. Rather, the general idea is that you use Phaser on the client-side to display the game and share as much of the code as possible through re-use in your server, but the server will be a distinct application that is different from the client. There will be times when the server needs to do things in somewhat of a different way than your client logic because the server has a much wider view of the game and it has to be more efficient. For starters, I would highly recommend reading Gabriel Gambetta's excellent series that outlines the basic concepts of making an authoritative server. It doesn't go over any code, but instead goes through the strategies to handle lag and other obstacles in multiplayer development. I would also recommend the Build New Games real-time multiplayer tutorial. That actually walks through some code for the user to see two different players moving around. As far as using Phaser 3 goes, you could check out the newer tutorial from Zenva. However, I would just consider that a starting point because there are some serious holes and missing parts from the code (such as client-side prediction, interpolation, etc.). I believe it would fall apart when real world latency enters the picture. But it does demonstrate pretty well how to get everything set up with Phaser 3 and could be a good starting point. Then there is also a good Phaser 2 tutorial and github found here. Hope this helps!
  3. 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.
  4. Jackolantern

    Need Help

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

    Need Help

    Wow, very nicely done and with a very minimal amount of code, too.
  6. Jackolantern

    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.
  7. Jackolantern

    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.
  8. 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.
  9. Ohhh, those animations @samme posted were nice. I would seriously try to work with those.
  10. 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. 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. 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. 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. 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. 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.