• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jackolantern

  1. I got Pathfinding.js working with Phaser. I just put it up on Github if you want to see it. You can see it here: https://github.com/JackolanternIR/onlinegameproofofconcept I do wonder though about these layers on your maps. I am not sure what game you are making, but typically you will only need to run A* pathfinding on your collision layer, since they are the only thing in most cases that the player must move around. If you also, for example, have a PORTALS layer or something like that, if I remember right you could probably see how to add that to the array of tiles to avoid when pathfinding if you look at my code (inside the public/client/js/clientServices folder you will find the classes that deal with pathfinding). There is also a parent class called "MobileObject.js in public/client/js/classes/bases that deals with moving around the map using A*. Essentially it creates tweens to handle the array of movements. Hope this helps! EDIT: Oh, and here is the URL for Pathfinding.js: https://github.com/qiao/PathFinding.js It really was a breeze to work with, and I felt it was much more flexible to use than EasyStar.js.
  2. I would actually keep sprite objects entirely inside the state and simply keep a copy of whatever properties you need for certain logical purposes in the objects. Since Sprite is a Phaser object, you want to try to minimize its connection to the logic objects, and use methods on your objects to set the value so you can set them to whatever you want in the unit tests. This is the strategy I have decided to use for my next attempt with the pattern since writing this code, actually. In this game, the sprite was completely separate from the logic objects since it was a breeder game and there wasn't a ton of logic-based moving around or other such things. I can post some snippets if you like, but I just kept the sprites totally in the state and didn't need to store much of their properties in the object. I would simply make a new sprite if I was making a new bread in the logic objects, for example. You could do that, or you could choose to keep things like X and Y completely in the state if you only use them for map collisions, etc. Since map collisions is an entirely Phaser-bound process, I don't think it is unit testable (at least without a ton of work). But if you need X and Y for logic that you want to be able to test and for functions that can work entirely outside of Phaser, for example, then you would want to keep a copy in the logic objects and have the state keep them in sync on changes. But if you are going to be using physics or tweens to change the X and Y values, you may have to pass on unit testing them. Honestly, there is still a lot of unexplored territory and game types with this pattern. I believe I will have much better examples and strategies after I work on my next project using the same pattern, which I plan to be a small RPG.
  3. 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!
  4. 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/
  5. Is there anything specifically you are having trouble figuring out? Because in many ways, a top-down game can be more simple than a side-scroller or some other perspectives since you don't typically have any physics, just collisions. The one thing you do have to come to grips with for a top-down game is tilemaps. You are going to depend on them more heavily in a top-down game because now your entire play world is a tile and you will probable be interacting with them more. In side-scrollers, you will typically have empty space or background images for the background seen through your platforms, and you interact with sprites. You will still interact with sprites in a top-down game, but now the entire playfield will be tiles, so you may want to blow them up, change tiles, animate them, etc. So I would do a crash-course on tilemapping in Phaser if you aren't very familiar with it, and then you should be good to go.
  6. Thank you for the response! Actually, the case that made me start to worry about the performance turned out to just be that example program (something I found online and tried to run on my Android phone). So it was probably doing something else that was killing the performance. I have since found some other examples that would likely be in the same ballpark as what I want to do (not sure yet on actual dimensions) and they ran just fine
  7. I have been looking around the Internet and on this forum here to try to find Phaser games heavily using tile maps that have been ported to mobile. Does anyone know of any? Has anyone experimented with using large tile-based maps on mobile who could give any feedback on performance or any tips? I am trying to decide whether to go HTML5 or native for a game idea I am working on. Thank you!
  8. 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!
  9. Thank you for the tips! And yes, what I am going for isn't true isometric. It is like a faux-isometric, or "Ultima slant" as I have also heard it called. And I will keep that in mind as far as the walls as images and collisions. Thanks again! Edit: By the way, that game looks awesome! Did you do the isometric coding custom, or did you use a library (as for the sorting and such; I do see the link to the pathfinding library, which looks great!)
  10. First try disabling all extensions. I know there are a few Chrome extensions out there that try to optimize HTML5 performance, and if you have anything like that it may be messing up. If that isn't an issue, I would probably do a fresh reinstallation. Something has gone terribly wrong there.
  11. 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
  12. Thank you! It will likely just take some experimenting to get things like trees working that players can be both in front of or behind.
  13. I don't think you need to add the 'this' for your hexListener callback (depending on the execution environment, it may even make it break making that change). As best as I can eyeball it, I think it is running on clicks, but it doesn't appear to be doing anything because it can't find the hexClickedText variable. I am pretty sure that is the problem here. So yes, move hexClickedText (at least its declaration) to the top of the page. If that doesn't work, add a console.log("Inside hexListener"); or something like that inside the hexListener, open the Javascript console and see if the listener is running.
  14. I don't think your hexListener can see the hexClickedText because it is local to the create() function. You could either make it global or add it as a property of this. But I think your event listener is setup correctly. You could always add a console.log() to the inside of the hexListener to make sure it is being called when you click the sprite.
  15. I am pretty sure Phaser can do this out-of-the-box. I am wanting to create a graphical style similar to Ultima VI. For those unfamiliar, here are some screenshots (unfortunately a lot of the screenshots are of the cutscenes, but there are several of the game map in there as well). It isn't truly isometric in the way we typically think about it, such as the style made by the amazing-looking Phaser isometric plugin. I believe that would be overkill for this type of style. The ground tiles all seem to be pretty standard overhead perspective, with only things protruding above the ground with somewhat of an isometric slant. My plan is to simply break walls up into standard-sized tiles and just add them carefully to the scene, overlapping with the floor tiles as needed (which I believe the original DOS Ultimas did, as I think I can see in screenshot 19 of 19 on the page I linked), and then I believe everything after that is simply a matter of making sure to add them in the correct order. For collision boxes, on characters for example, the box seems like it would only need to be at their feet, so that their head could overlap with things behind them. I suppose there would also be the matter of making sure walls overlap players as they move around, but that could probably be done with some creative collision code. Does this make sense? Do I seem to be on the right path here? Do you see any pitfalls in this, or implementing this in Phaser? Thank you!
  16. Did you create a .htaccess file in your root folder to allow you to go to hellophaser as the domain? Otherwise, like Rich said, you need to go to localhost. WAMP installs Apache web server, and all of the folders that you drop into the www folder will exist below localhost. For example, say you added a folder called "hellophaser" into your www folder that has the entry HTML file into it for your game. You would go to http://localhost/hellophaser/ to access it.