• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jackolantern

  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. Whatever was going on seems to have just been a hiccup. It is back up now!
  8. 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.
  9. 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.
  10. 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?
  11. Ohhh, those animations @samme posted were nice. I would seriously try to work with those.
  12. 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.
  13. 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?
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. This is probably the direction I would investigate: I would create a 2D array that correlates to the stage. In the elements of this array (with each one representing one tile) you can note whether that tile should be drawn or not. Then you have your actual tilemap object. I would create a "master" tilemap object that will always contain the tiles for the map. But then I would have another tilemap object that we will call the "visible" tilemap object that I fill only with the tiles that are visible. When you run the LoS algorithm, you can set bool values in your 2D array to determine what tiles will be drawn and then use that array to copy tile data from the master tilemap object to the visible tilemap object (or maybe you could do this directly with your algorithm and not even use the 2D array but that may be mixing a lot of logic into one place and could get messy). Then use your "visible" tilemap to actually set the tilemap to be drawn, thus only showing the tiles you want to. Note that I have not done this before and there may be some attribute I am missing that would make this much easier or more performant. You may also be able to use the method call shown in the Fill Tiles example to simply swap out the tiles you don't want to show with a black tile or whatever your background color is (even though this example seems to be messed-up for me for some reason, the method call itself should work). In this case you would still need some kind of object or 2D array to keep track of what the tile is supposed to be when it is visible. You may just need to play around and see which technique is more performant and/or easier to work with.
  19. Remember that JS arrays are completely dynamic, so you aren't limited to a specific size. But there is no such thing as an infinite map. Every map is a finite size and in memory. If you want to make a faux-infinite procedurally generated map, you would do it one chunk at a time with finite-sized maps and seamlessly switch between them. The way I mentioned would work for that as well.
  20. I haven't used the isometric plugin before, so there could be a better way of handling this, but from a logical point of view this is how I would do it: I would create a 2D array that will represent the overall stage or level. Inside each element of this array that will be filled with anything in your stage, add a JS object. Inside this object you can store basic stage info (whether it is a grass, trail, exposed dirt tile, etc., as well as info on warp tiles, door open/closed, or whatever else you need), but also have an array on the object that holds additional things to add to that tile, such as rock, coin, flower, wall, etc. You may also have to store additional info on how to properly render these things, such as their height. So you may have to make each one of those be their own special JS object. This is often how 2D or isometric levels are stored: as multidimensional arrays. This way you can just change your loop to loop over the 2D array, read each element and render each tile, then see if there is that array of additional objects on the tile so you can render those as well. I can't be of much more help on the details since I don't know what all the isometric plugin does for you and what you have to do yourself, but I think this general idea should get you started. Hope this helps!
  21. Yeah, PHP and AJAX aren't a good choice for a lot of online game types. The problem is that you can't easily send messages from the server to players without them making a request. It is possible to do what is called "long polling" where you have every client send requests that are then held by the server until data needs to sent to them but this is a less than optimal choice because it is very taxing on the server and connections will often be timing out and require they be resent, so with the overhead of HTTP, this is not a great solution. Node and WebSockets are a better solution. I remember looking before at Eureca and was turned off from it for some reason but honestly I can't remember what it was so that is probably neither here nor there. If you are going node, you can always just use the very popular Socket.io. But to answer your question, I assume that the "eureca.js" file is probably the EurecaClient.js file in the /lib folder. The client script is the one on the client side that knows how to connect to the server. EDIT: Oh, it is worth noting that in Socket.io, there is a script tag on the client to a Javascript file that isn't found in the source code of Socket.io. That is because that file is generated by Socket.io once the server is running. That may also be the case with Eureca, where the server may specially package a client script for the browser. See if that may be the case for Eureca if the EurecaClient.js script isn't the right one.
  22. I think indexedDB support still is fairly flaky, especially in Safari. You can see a good compatibility table here: http://caniuse.com/#search=indexeddb There are some libraries out there that can make localStorage more like a database. LocalStorageDb is a pretty neat one. TaffyDB is another one. Both of these make localStorage feel kind of like MongoDB or CouchDB, and localStorage is very well-supported among current mobile and desktop browsers: CanIUse Web Storage. However, you will start to use up space very fast trying to encode and store images in it. In most browsers, once you run out of web storage space, the user is prompted to offer you more space. Most users have not seen this message before and many will likely be scared-off or confused by it, so it is best to avoid it at all costs. As Mattstyles asked, if we knew your use-case, there may be a better way, because I think encoding and storing the images in any kind of storage is going to fill up fast.
  23. Have you tried looking for an open source implementation of a Mahjong game to see the logic? There are so many Mahjong games out there that I would imagine someone has to have one open sourced. Typically, when we reach a point where something feels impossible to do in a given system, it is because we have coded ourselves into a corner. There most definitely is a solution to the problem, but the question may be if the solution is compatible with how you are approaching the issue so far. I am definitely not suggesting to just lift code from an open source project, but I suspect if you found one, there will be a major "Eureka!" moment where you realize you were either: A. approaching the problem in a much more complicated way than it has to be, or B. not breaking down the problem into small enough parts. Then perhaps taking a few steps back will catapult you many steps forward. Best of luck!
  24. Have you guys been able to pinpoint the exact function call that is not working? How are you determining if an enemy is off-camera?
  25. Very nice! I will have to check this out. Even though I do like heavy editors like WebStorm, I also like to have a competent text editor for when I just want to work on one file and don't feel like firing up the whole cavalry.