Jackolantern

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    Jackolantern reacted to NoxBrutalis in Phaser as Multiplayer Server   
    Indeed, your back end should be dealing in game abstractions rather than phaser data types etc. It would also be very bad for efficiency having those data types passed back and forth between the client, when simple numbers and strings could do. It's a lot like creating save game files and serializing data in that sense. When you save a game, you don't save all the objects and state and literally everything  - you save simple data types that act as signposts for rebuilding your types/objects/state etc. 
  2. Like
    Jackolantern got a reaction from NoxBrutalis in Phaser as Multiplayer Server   
    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. Like
    Jackolantern got a reaction from imacomputertoo in 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. 
  4. Like
    Jackolantern reacted to samid737 in Need Help   
    Collision test based on circle and line intersection, the intersectsLine returns true or false, but it can also return the intersect points.
     
     
  5. Like
    Jackolantern got a reaction from samid737 in Need Help   
    Wow, very nicely done and with a very minimal amount of code, too. 
  6. Like
    Jackolantern reacted to samid737 in Need Help   
    @Jackolantern  Thats a nice trick too, fused it with the example to give more ideas  :

    in this case without integration, but the rectangles are distributed and the numbers can be adjusted to increase or decrease them... the curve is higly adjustable  and this time no p2 physics so thats nice. It really depends on what kind of collision model @Manecz needs I agree.
  7. Like
    Jackolantern reacted to samme in Dice rolling with sprite   
    I don't think you need an accurate physics simulation. Start with https://github.com/Rinirihiriro/dice/blob/master/dice.png, pick an end face at random (⚀⚁⚂⚃⚄⚅), then choose a "path" through the atlas frames.
  8. Like
    Jackolantern got a reaction from jsantos in 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. 
  9. Like
    Jackolantern reacted to GreatBigBore in Smelly sprites, SpriteBatches, Emitters, and createMultiple()   
    My characters need to be able to find their food. They can smell things a certain distance away -- each guy is attached to a big, circular (invisible) sprite that represents his smell range. I need to detect the overlap between the smell particles and their sensor, so they know the food is there, how much is there, how far away, what direction, that sort of thing.
  10. Like
    Jackolantern got a reaction from alessandronunes in Hide portions of tilemap (fog of war)   
    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. 
  11. Like
    Jackolantern got a reaction from PhasedEvolution in Phaser isometric basic tiling   
    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.  
  12. Like
    Jackolantern got a reaction from P4nch0 in Phaser multiplayer map realtime   
    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. 
  13. Like
    Jackolantern got a reaction from PhaserEditor2D in Rayo, a desktop and lightweight text editor for Phaser   
    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. 
  14. Like
    Jackolantern got a reaction from drhayes in Unit testing a Phaser application?   
    I actually made a Phaser-powered game that was unit testable. I will try to release the source code in the coming week or so, but there were some other people who worked on it, so I will need to get the OK from them (a couple of people said they may keep working it into a commercial product). 
     
    Essentially, I used a pretty radically different pattern for game creation with Phaser that I just off-hand dubbed MSC (Model-State-Controller). I think it would work quite well for a large-scale game, and am actually going to be trying it out fairly soon. The general idea is that you keep all of your data stores in either JS objects or a localStorage database-like system, such as LocalStorageDB (if you are going to have a ton of data) and data-access classes to set and get that data, and your logical objects exist completely outside of Phaser and have no knowledge of Phaser. I chose to use a modified "revealing module pattern" for my classes. Essentially it uses a combination of factory methods and closures to have the ability to create infinite instances, have full inheritance and public and private members that inherit correctly. Here is an example of both a base-class and a child class inheriting from it (by the way, it was a bread-breeding game, so yes, the classes are for breads that breed): 
    read.BreadClasses.newBread = function(breadList) { //private fields var mature = false; //public fields var o = {}; o.breadInfo = breadList; o.instanceName = ""; /** @return {bool} - Whether the bread is mature */ o.isMature = function() { return mature; }; /** @param {string} inName - The instance name for the bread. */ o.setInstanceName = function(inName) { this.instanceName = inName; }; /** @return {BreadInfo} - The bread data for the bread. */ o.getBreadInfo = function() { return this.breadInfo; }; return o;}; As you can see, it is a function that starts with a JS object and adds members to it, and then returns it, so the function itself is a factory to create as many copies of the object as you need (no "new" used here!). 
     
    And here is an example of a class that inherits from it:
    /** Factory for the AdultBread class, which inherits from Bread @constructor @type {{AdultBread}} @param {BreadList} breadList - An instance of a BreadList info object. @return {AdultBread} - The new AdultBread instance created. */Bread.BreadClasses.newAdultBread = function(breadList) { //private fields var isInBasket = false; var breedingTimeLeft = 0; var basketNumber = 0; var maxBreedingTime = breadList.breedingTime; //inherit from Bread class and public fields var o = Bread.BreadClasses.newBread(breadList); /** Reduces breeding time by 1 */ o.decrementBreedingTime = function() { breedingTimeLeft = breedingTimeLeft - 1; }; /** * Checks whether the bread is in a breeding basket. * @return {boolean} - If the bread is in a breeding basket. */ o.checkIfInBasket = function() { return isInBasket; }; /** * Put the bread in a breading basket. * @param {boolean} inBasket - Sets whether the bread is in a basket or not. */ o.setInBasket = function(inBasket) { isInBasket = inBasket; }; /** * Set the basket number for the bread. * @param {int} basketNum - The basket the bread is in. */ o.setBasketNumber = function(basketNum) { basketNumber = basketNum; }; /** * Get the breeding basket number of the bread. * @return {int} - The basket the bread is in. */ o.getBasketNumber = function() { return basketNumber; }; /** * This method returns whether the bread is growing up and needs to be removed from the collection. Always returns false for adults. * @returns {boolean} */ o.isGrowingUp = function() { return false;; }; /** * Sets the current breeding time. */ o.setBreedTime = function() { breedingTimeLeft = maxBreedingTime; }; return o;}; Using this setup, your core game objects exist outside of your game states. Phaser states are then more like the "View" in an MVC application. You create their visual representations inside the state (you can store the Phaser sprite name inside the object for easy reference), and feed them data relates to the changes of the game state, but the core game logic should exist inside your game objects. Only the logic related to displaying the game should be in your state. Of course if you store game data in something like LocalStorageDB, you will have to mock that in your tests.
     
    The one place where this code does fall down is that I do not use dependency injection enough, and that ended up making certain things difficult to unit test, so I had to go more with a chaotic integration test for some parts of the application. If anyone uses a setup like this, definitely do not hard-code your base objects when inheriting. Those should be injected. You could inject the factory methods used to create the base class. In fact, that could create some pretty amazing flexibility. If the idea of an entirely dynamic class hierarchy makes you nervous, simply add a "type" member to each object and name them so you can check that the factory passed in was of the type you expected. 
     
    For games such as RPGs, strategy games, breeder games, etc., you can pretty much load up all of your logic objects into an HTML page, open the console, and run the entire game from the console command line, getting text feedback, so they are definitely testable. I like using Jasmine, but of course you can use whatever framework you prefer. Action games are a bit more complicated because they rely on the timing that only your objects being run in the state provide. But even in that case you will still be able to unit test the logic of your objects. You will just have to rely a bit more on traditional play testing. 
     
    Hope this helps! 
  15. Like
    Jackolantern got a reaction from georgejfrick in Unit testing a Phaser application?   
    I actually made a Phaser-powered game that was unit testable. I will try to release the source code in the coming week or so, but there were some other people who worked on it, so I will need to get the OK from them (a couple of people said they may keep working it into a commercial product). 
     
    Essentially, I used a pretty radically different pattern for game creation with Phaser that I just off-hand dubbed MSC (Model-State-Controller). I think it would work quite well for a large-scale game, and am actually going to be trying it out fairly soon. The general idea is that you keep all of your data stores in either JS objects or a localStorage database-like system, such as LocalStorageDB (if you are going to have a ton of data) and data-access classes to set and get that data, and your logical objects exist completely outside of Phaser and have no knowledge of Phaser. I chose to use a modified "revealing module pattern" for my classes. Essentially it uses a combination of factory methods and closures to have the ability to create infinite instances, have full inheritance and public and private members that inherit correctly. Here is an example of both a base-class and a child class inheriting from it (by the way, it was a bread-breeding game, so yes, the classes are for breads that breed): 
    read.BreadClasses.newBread = function(breadList) { //private fields var mature = false; //public fields var o = {}; o.breadInfo = breadList; o.instanceName = ""; /** @return {bool} - Whether the bread is mature */ o.isMature = function() { return mature; }; /** @param {string} inName - The instance name for the bread. */ o.setInstanceName = function(inName) { this.instanceName = inName; }; /** @return {BreadInfo} - The bread data for the bread. */ o.getBreadInfo = function() { return this.breadInfo; }; return o;}; As you can see, it is a function that starts with a JS object and adds members to it, and then returns it, so the function itself is a factory to create as many copies of the object as you need (no "new" used here!). 
     
    And here is an example of a class that inherits from it:
    /** Factory for the AdultBread class, which inherits from Bread @constructor @type {{AdultBread}} @param {BreadList} breadList - An instance of a BreadList info object. @return {AdultBread} - The new AdultBread instance created. */Bread.BreadClasses.newAdultBread = function(breadList) { //private fields var isInBasket = false; var breedingTimeLeft = 0; var basketNumber = 0; var maxBreedingTime = breadList.breedingTime; //inherit from Bread class and public fields var o = Bread.BreadClasses.newBread(breadList); /** Reduces breeding time by 1 */ o.decrementBreedingTime = function() { breedingTimeLeft = breedingTimeLeft - 1; }; /** * Checks whether the bread is in a breeding basket. * @return {boolean} - If the bread is in a breeding basket. */ o.checkIfInBasket = function() { return isInBasket; }; /** * Put the bread in a breading basket. * @param {boolean} inBasket - Sets whether the bread is in a basket or not. */ o.setInBasket = function(inBasket) { isInBasket = inBasket; }; /** * Set the basket number for the bread. * @param {int} basketNum - The basket the bread is in. */ o.setBasketNumber = function(basketNum) { basketNumber = basketNum; }; /** * Get the breeding basket number of the bread. * @return {int} - The basket the bread is in. */ o.getBasketNumber = function() { return basketNumber; }; /** * This method returns whether the bread is growing up and needs to be removed from the collection. Always returns false for adults. * @returns {boolean} */ o.isGrowingUp = function() { return false;; }; /** * Sets the current breeding time. */ o.setBreedTime = function() { breedingTimeLeft = maxBreedingTime; }; return o;}; Using this setup, your core game objects exist outside of your game states. Phaser states are then more like the "View" in an MVC application. You create their visual representations inside the state (you can store the Phaser sprite name inside the object for easy reference), and feed them data relates to the changes of the game state, but the core game logic should exist inside your game objects. Only the logic related to displaying the game should be in your state. Of course if you store game data in something like LocalStorageDB, you will have to mock that in your tests.
     
    The one place where this code does fall down is that I do not use dependency injection enough, and that ended up making certain things difficult to unit test, so I had to go more with a chaotic integration test for some parts of the application. If anyone uses a setup like this, definitely do not hard-code your base objects when inheriting. Those should be injected. You could inject the factory methods used to create the base class. In fact, that could create some pretty amazing flexibility. If the idea of an entirely dynamic class hierarchy makes you nervous, simply add a "type" member to each object and name them so you can check that the factory passed in was of the type you expected. 
     
    For games such as RPGs, strategy games, breeder games, etc., you can pretty much load up all of your logic objects into an HTML page, open the console, and run the entire game from the console command line, getting text feedback, so they are definitely testable. I like using Jasmine, but of course you can use whatever framework you prefer. Action games are a bit more complicated because they rely on the timing that only your objects being run in the state provide. But even in that case you will still be able to unit test the logic of your objects. You will just have to rely a bit more on traditional play testing. 
     
    Hope this helps! 
  16. Like
    Jackolantern got a reaction from MichaelD in Hello! Top Down Game?   
    Ohh, you meant an isometric game? Quite different from a typical top-down game. Well, I don't have much experience with that type of game. I find asset production a pain, but I am not an artist, so take that with a grain of salt. Phaser does have a dedicated isometric plugin that looks pretty slick, so maybe start out by looking into that! http://rotates.org/phaser/iso/
  17. Like
    Jackolantern got a reaction from feudalwars in Looking to create semi-isometric look of old PC RPGs   
    Oh very nice! I had not seen that example. That will help me out! 
     
    As for collision vs. pathfinding, I would say you are both right, since it does matter what the input scheme of my game would be (and which I didn't mention). I am not sure what I was thinking when I said "creative collision code" could solve the wall/player overlap problem, since I am planning to have click-to-move with strict tile-based movement, so there would be no collisions. The more I looked at that pathfinding library, the more I think that will work great for me. I was planning on rolling my own following this tutorial, but why do that if this fits my needs perfectly?
     
    Thank you both for all of the help! I also think just digging in to Tiled and the Phaser sorting methods will help me to work out a lot of this. I am still quite a ways from that point, though (still working on the design doc). It was more that I was wanting to get the graphical style nailed down while in the planning phase before investing resources into having them made, only to find out I would need to use a Phaser plugin or something like that, which could have had further implications on the assets. 
     
    Thanks again!  
  18. Like
    Jackolantern got a reaction from paul_nicholls in Can't get sprite input events working   
    The Javascript console is brought up in a browser while you are running your game. In Chrome, you press Ctrl+Shift+J to bring it up. Debugging games can be rough because of how games work (calling functions many times per second to move things just a tiny bit), so being able to send out arbitrary messages to check values, make sure functions are running, etc. is very important. Learn to use the Javascript console well