mattstyles

Moderators
  • Content Count

    1671
  • Joined

  • Last visited

  • Days Won

    24

Reputation Activity

  1. Like
    mattstyles got a reaction from samid737 in Modern JavaScript Tools   
    Might be worth phrasing the question a little differently, what problems do you (as author) or your consumers have with your current workflow?
    By phrasing like this you might get better answers as to how a different (newer) system might help to solve those problems.
    Browserify and NPM primarily give you access to node's commonJS module flavour. Personally I was never comfortable with weird JS namespacing solutions (or revealing module pattern) so access to a proper module system was the problem that these tools solved.
    Partly access to a proper module system is a convenience but it also helps resolve the very real problem of naming conflicts in the runtime environment (i.e. the client). Take for example the following problem:
    * I 'publish' my Eventemitter module for implementing pub/sub.
    * Consumers consume this module by including a script tag which dumps an `EventEmitter` global in to the page, whereby the application code can access and use my module.
    * Someone else publishing a module that also exposes an `EventEmitter` global in to the page.
    * As a consumer I want both modules but now I have a problem as they both conflict over that `EventEmitter` global and there is no clean way to resolve this.
    For large libraries like Phaser or, say, React, or `quick`, this probably isn't too much of a problem as you likely won't have a naming conflict, particularly if the library in question uses an obscure and fairly unique name (i.e. not EventEmitter), but, this brings another problem.
    The Unix Philosophy states that a program/process/module/thing should do one thing well and that complexity is achieved through composing small 'things' into larger things. Including larger catch-all libraries (or frameworks)  works directly against this and when you're worried about conflicts (particularly seemingly trivial things like naming conflicts) it actively prohibits the release of smaller modules, or even individual functions. Take the case of underscore and lodash which are simply a collection of convenience methods, the chance of conflicts between functions named 'map', 'reduce', 'concat' etc is very high if you're after a 'small module' philosophy.
    Using a proper module system, one where the consumer can optionally choose to name their imports, solves this problem cleanly i.e. as a consumer I can name things as I choose if/when required:
    const FooBarBaz = require('phaser') import CrazyUniqueName from 'React' Now I have no naming conflict problem.
    Take this further with named exports and as a consumer I can pick and choose what I want from a module, again, optionally renaming it if necessary:
    const {render} = require('react') import Rectangle as NearlySquareThing from 'Phaser' Now take this even further and introduce additional automated tooling that can take this specification for how modules are consumed and create smarter builds, all in the hands of the consumer, and you're on to a real winner i.e. if I only want to include 'map' from lodash then current modern tooling allows me to take that without dumping the entirety of lodash into the page as a script include just to access one function. You could have achieved this before but it would require knowledge of knowing how to create custom builds of dependencies and that is painful, Bootstrap had several helpers for creating custom builds (for example) but its still a pain and updating the dependency becomes close to impossible when you're using custom builds.
    This is another advantage of using NPM, dependency version management. This is achievable in the old method, just download a new version and include it as a script tag, however, NPM have automated this workflow. I have worked on several complex applications over the past couple of years, all with dependency management handled by NPM, some projects only contained a handful of top-level dependencies but all projects ended up with hundreds (and sometimes thousands) of actual dependencies, imagine trying to update these by hand! It is practically impossible unless you have a huge amount of time, NPM helps (doesn't totally solve) to eradicate this problem via automation (via specification) and mostly it just works.
    For me it almost boils down to these two workflows:
    1:
    * Find a download link
    * Remember the download link
    * Download the file
    * Place the file somewhere, probably inside my repository
    * Include as a script tag
    * Handle naming conflicts
    * Use the global the script exposes
    vs 2:
    * find the module name I want
    * npm install my-awesome-module
    * include module in source code and use it
    Most of the steps from #1 are removed in #2 because it becomes automated i.e. the name of the module you are using is stored in the `package.json` and updating it becomes trivial (of course, the update could break your stuff, which is certainly non-trivial, but the actual update is automated and trivial).
    Workflow 1 highlights another potential issue, if I have a repository do I really want to keep all dependencies in it? Almost certainly no, but you might want to depending on how much of a masochist you are.
     
    I had a look at your main `src/quick.js` file, seems extremely well structured and very clean to me. On the flip-side it also seems super easy (trivial even) to extract those functions to separate files and then include them in an index file (or main) of some sort to expose them and get all the advantages listed above. But, again, if you're comfortable with your current workflow (looks like it works, your structure, I think, is superb, I personally would hate to work on such a large file but I imagine the practicality is that it is easy as you've separated everything up very cleanly) then why change? Do you think you might be more comfortable with an alternate workflow?
  2. Haha
    mattstyles reacted to mentuat in This is how scirra is treating its costumers   
    Oof!  No one came out of that discussion looking pretty!
  3. Like
    mattstyles reacted to b10b in This is how scirra is treating its costumers   
    @unforseen Tom is thinking like a systems engineer and his ask is sensible (... send him the files).  His motivation is probably wanting to help all C3 users simultaneously, not just one at a time.  So help him to help you ... if you've identified a real issue then he can fix it at core (you  helped the community), or if you've got a local issue his expertise will expedite your fix (the community helped you).  Yes, their customer service response was not ideal, and nobody likes having unfair terms quoted back at them - but identify what's the best course for you and your game.  You probably selected C3 for good reasons, wouldn't having it work be best for you?  Good luck 
  4. Like
    mattstyles reacted to blossy in This is how scirra is treating its costumers   
    I don't know about UK laws but the UK is (still) in the EU and if you are an EU country citizen they are bound to provide a refund for any remote purchase if the customer demands so within 14 days (based on the purchase date). Especially if it's a subscription to an online service and not a product that you've already consumed or damaged.
    ... regardless of what ToS you've agreed to.
    Aside from that, I really really doubt anybody would have other sorts of interest in the idea or the code behind an HTML game these days. It's a standard practice to send a test project for reproducing bugs. And they could easily collect the project code and assets if they wanted to - it's an online app after all, isn't it?
  5. Like
    mattstyles got a reaction from Luminous Wizard in Begining HTML5 Game Development   
    There are quite a few threads on this that might be helpful, try searching the forums.
    I think there are a couple of quick things to think about though:
    * Coding is really hard. It is very rewarding (and fun) but quite difficult, be prepared to invest time and effort in to it (you may already be there on that!).
    * HTML5 makes things a little trickier as you have to consider JS, CSS and HTML. If you're coding canvas-based games (as most here do) then it's 99.9% JS.
    * You'll need to do plenty of reading (or listening) but get your hands dirty, write as much code as you can, solve problems in that code,  dive into those problems. This probably means you won't get anything finished very quickly but it will mean you have a much much much better chance of getting things finished in the future, have an end goal in mind for a project but I wouldn't worry if you don't make it first time, what often happens is: Have an idea for game -> write some code -> find issues in the code -> dive into the issues and really learn -> have another idea for a game -> rinse -> repeat. At some point you need to be finishing things, but, not so much when you're learning, its more important to do some deep dives than skim over some complexity only to get things finished (totally opposite if you're earning money from it).
    * Ask lots of questions. Find a mentor if you can, but places like this forum can substitute for a human on the end of a phone or face to face.
    * If there are community JS meetups in your area try to attend them. Try to attend a conference with some topics you're particularly interested in (although this can get expensive). Both of these help to put faces to names and most speakers and people at meetups are very friendly, everyone is in the same boat, or, if they're in a more advanced boat now, they were in your boat before. The coding (and JS in particular) community is an incredible thing, its biggest asset, make use of that and be a part of it. Remember to give back when you make your way to 'Expert Coder' level.
    * Be wary of that 'Expert Coder' label I just used, its garbage! Always be learning, always be moving forward. This is true of any science but seems to be doubly true of JS and Web programming.
    * Be determined, its a hard road, lots of problems to solve, but keep going, the hill is steep at first but it flattens out a little as your knowledge improves, then ramps up again.
  6. Like
    mattstyles got a reaction from spravesh1818 in Begining HTML5 Game Development   
    This is actually part of the learning experience, googling a subject and being able to pick the good from the garbage.
    The problem is that most people writing about beginner subjects aren't much past the beginner level themselves so the info can be a little inconsistent or even incorrect. There is actually a double problem here for the web: because web tech develops at such a fast rate a lot of stuff goes out of date quickly.
    https://developer.mozilla.org/en-US/ MDN is a go-to resource. The W3C website has some similar resources but it isn't as well written or updated, plus its sometimes just inaccurate, but you will likely come across it.
    Just google for blogs and other resources, you'll often stumble across a few content creators you like, make sure you get a feed of their blogs and following them on twitter is a good idea.
    https://www.smashingmagazine.com/ is usually consistently high quality, although I haven't looked at it for a while and not sure how much beginner stuff it has. Not a gaming resource though.
    https://github.com/getify/You-Dont-Know-JS is a fantastic resource and Kyle Simpson is an incredible developer, its not a gaming slant but a fantastic JS series of books.
    That last one is a github link, once you get beyond the real beginner stage you'll need to be looking through any source code you can find, many people who shout about their games here also provide links to their github source code. This is extremely daunting at first though, so probably not that useful when starting out.
    In a similar vein, when you get going you'll probably want to start using third-party modules and import them in to your code. NPM is one such repository of packages (there are millions). You'll find that pretty much everything there is open source and will contain links to the source code. Once you get in to that you'll find you see the same names of people churning out modules, read their code, if they have blogs read them. Again, this is extremely daunting at first so tackle it later.
  7. Like
    mattstyles got a reaction from mazoku in Begining HTML5 Game Development   
    This is actually part of the learning experience, googling a subject and being able to pick the good from the garbage.
    The problem is that most people writing about beginner subjects aren't much past the beginner level themselves so the info can be a little inconsistent or even incorrect. There is actually a double problem here for the web: because web tech develops at such a fast rate a lot of stuff goes out of date quickly.
    https://developer.mozilla.org/en-US/ MDN is a go-to resource. The W3C website has some similar resources but it isn't as well written or updated, plus its sometimes just inaccurate, but you will likely come across it.
    Just google for blogs and other resources, you'll often stumble across a few content creators you like, make sure you get a feed of their blogs and following them on twitter is a good idea.
    https://www.smashingmagazine.com/ is usually consistently high quality, although I haven't looked at it for a while and not sure how much beginner stuff it has. Not a gaming resource though.
    https://github.com/getify/You-Dont-Know-JS is a fantastic resource and Kyle Simpson is an incredible developer, its not a gaming slant but a fantastic JS series of books.
    That last one is a github link, once you get beyond the real beginner stage you'll need to be looking through any source code you can find, many people who shout about their games here also provide links to their github source code. This is extremely daunting at first though, so probably not that useful when starting out.
    In a similar vein, when you get going you'll probably want to start using third-party modules and import them in to your code. NPM is one such repository of packages (there are millions). You'll find that pretty much everything there is open source and will contain links to the source code. Once you get in to that you'll find you see the same names of people churning out modules, read their code, if they have blogs read them. Again, this is extremely daunting at first so tackle it later.
  8. Like
    mattstyles got a reaction from spravesh1818 in Begining HTML5 Game Development   
    There are quite a few threads on this that might be helpful, try searching the forums.
    I think there are a couple of quick things to think about though:
    * Coding is really hard. It is very rewarding (and fun) but quite difficult, be prepared to invest time and effort in to it (you may already be there on that!).
    * HTML5 makes things a little trickier as you have to consider JS, CSS and HTML. If you're coding canvas-based games (as most here do) then it's 99.9% JS.
    * You'll need to do plenty of reading (or listening) but get your hands dirty, write as much code as you can, solve problems in that code,  dive into those problems. This probably means you won't get anything finished very quickly but it will mean you have a much much much better chance of getting things finished in the future, have an end goal in mind for a project but I wouldn't worry if you don't make it first time, what often happens is: Have an idea for game -> write some code -> find issues in the code -> dive into the issues and really learn -> have another idea for a game -> rinse -> repeat. At some point you need to be finishing things, but, not so much when you're learning, its more important to do some deep dives than skim over some complexity only to get things finished (totally opposite if you're earning money from it).
    * Ask lots of questions. Find a mentor if you can, but places like this forum can substitute for a human on the end of a phone or face to face.
    * If there are community JS meetups in your area try to attend them. Try to attend a conference with some topics you're particularly interested in (although this can get expensive). Both of these help to put faces to names and most speakers and people at meetups are very friendly, everyone is in the same boat, or, if they're in a more advanced boat now, they were in your boat before. The coding (and JS in particular) community is an incredible thing, its biggest asset, make use of that and be a part of it. Remember to give back when you make your way to 'Expert Coder' level.
    * Be wary of that 'Expert Coder' label I just used, its garbage! Always be learning, always be moving forward. This is true of any science but seems to be doubly true of JS and Web programming.
    * Be determined, its a hard road, lots of problems to solve, but keep going, the hill is steep at first but it flattens out a little as your knowledge improves, then ramps up again.
  9. Thanks
    mattstyles got a reaction from Soley in Landscape or portrait mode for html5 game   
    Depends on the type of game.
    If you rely on keyboard input then you're likely targeting laptops/desktops, so landscape.
    If you're targeting mobiles then portrait as web landscape is pretty poor in most mobile browsers and you can't lock the orientation for the web (this restriction doesn't apply if you're embedding your web tech into something like Cordova and releasing your app as a "native" application).
    I'd guess mobile market is larger, but, it does depend on the type of game.
  10. Like
    mattstyles reacted to eyo_omat in Ticking time bomb in a game   
    Thanks a lot mattstyles,  this worked nicely, moved the action code to a different function that i called from within the setTimout. Cheers.
  11. Thanks
    mattstyles got a reaction from eyo_omat in Ticking time bomb in a game   
    You're pretty much there you just need to delay things a little, `setTimeout` is your simplest friend here:
    const DELAY = 2000 tntCollision: function (player, tnt) { setTimeout(function () { ...do stuff }, 2000) } Bare in mind that, depending on the rest of the code, you need to make sure that `player` and `tnt` are representative of the state in 2 seconds time, usually (due to closure) those variables can become locked to when the call was initiated, try it and see.
    In your case it looks like your `tntCollision` function wants to do some work when the collision occurs and some other work in 2 seconds (for example) time so you'll have to dice it up how you see fit and use setTimeout to schedule a function to invoke after a set number of milliseconds.
    Also, Phaser has an idiomatic way of scheduling functions in the future so you shouldn't need to call setTimeout explicitly, have a google (or search these forums) for Phaser.Timer events (I think thats what its called).
  12. Like
    mattstyles got a reaction from Outermedia in Canvas Tilemaps - Javascript Help   
    Yeah I know that feeling of being beaten down by a problem to the point where its difficult to even express it! It's usually a clue for a good nights sleep and to be tackled again when fresh!!
    I think I know what sort of thing you're after.
    How to express a tile and entity map has about as many solutions as there are developers out there! A common starting point might look the following:
    So, your map might be a 5x5 2d grid of locations, to simplify things lets express tile types as integers, 1 is a wall, 0 is floor and to simplify our rules even further, you can step on the floor but not on the wall:
    var map = [ 1, 1, 1, 1, 1, 1, 0, 0, 0, 1 ... ] var width = 5 function get (x, y) { return map[x * (y + width)] } This is a simple 1d representation of a 2d tile map with an associated getter function to convert 2d to 1d (which requires knowing the width of the grid), note that [0, 0] is top-left, x going right, y going down (yes, coordinate systems are important but we've just chosen the "easiest" representation).
    Now you need some sort of entity object (you might call it a class, but thats a bit ho-hum in JS):
    var player = { x: 1, y: 1 } You might want to add this player to an array of entities (or, even, an array of alive entities, depends what you want).
    This is about all your renderer needs to get rendering, throw the map array and the width and tell it to draw, then draw your entity on top in the correct location.
    To handle collision detection lets do something really simple, the following is semi-pseudo code:
    function checkMapCollision (x, y) { var target = get(x, y) return target === 0 } function handleMapCollision (entity, desired) { var isOkToMove = checkMapCollision(entity.x + desired.x, entity.y + desired.y) if (!isOkToMove) { return } entity.x += desired.x entity.y += desired.y } function onKeydown (key) { if (key === 'left') { handleMapCollision(player, {x: -1, y: 0}) } ... } Something like this would work (I've done it quickly, might have made a stupid mistake). Attach the `onKeydown` function to a keyboard (or joystick, or mouse, or touch, whatever) handler which responds to a key press event, takes the player entity and checks for a collision with the desired location, if all is ok then it updates the entity position so you either need to re-render or if you're using some sort of rendering loop then the position will update on the next render tick.
    This is pretty much the basis of it. Your next requirement is to check for collisions with entities, you pretty much do the same but rather than a spatial look up against a grid you'd probably want to loop over all active entities and check to see if any of them currently occupy the desired target location, if they do then run a function that handles what should happen when that collision occurs, otherwise loop through the map spatial check (above) and see if the desired target location is ok on the map or not.
    That really is about it, most other systems just add complexity on top of this simplistic model (obviously this is a very mature field pretty much as old as computer gaming, which isn't much younger than computing!).
    Some stuff you might want to look at doing:
    * Sometimes its easier to use [x, y] rather than `entity.x` and `entity.y`
    * Integers are fine for representing tiles and/or entities but you'd want another lookup table that maps that integer to an object which represents the actual object i.e. a wall object might have a flag (boolean) saying it is impassable, whereas a water tile might have a flag that states only flying, swimming or floating entities can enter it etc etc etc.
    * You might want to forego the integer (id) representation and just embed whole objects into your map and/or entity array but consider how distinct each element is i.e. if ALL of your walls are the same in a map and your map contains thousands of them then thats a load of memory you don't need to consume, just keep one wall object somewhere and your map array just references it.
    * If some of your map entities do differ from the blueprint/template for, say, a wall object, maybe you only want to store the differences.
    * The suggestion above notes looping over your entire entity array to find collisions, with 1000's of entities all moving this is expensive. You might want to look at techniques such as Octrees to simplify the search space (this gets technical real fast! but if you're diving in, then dive in!), if you want a warm-up maybe read up on A/B (or Black-Red trees) as Octrees are a more advanced (extra dimension/s) version, again, this gets technical real fast! I'd say its key learning for any developer!
    * Consider using a 2d array (or, an array or arrays) to hold your data, personally I dislike this approach but you might find it easier to use `map[0][1]` rather than using a getter.
    * Think about what to do when you have a collision, do you want a handler that takes the two 'things' that are colliding which decides what to do? i.e. this handler would map a collision between player and wall to a function, between player and enemy to another etc etc etc. As your list of possible colliders grows this can get tricky to manage, so maybe make it a little more interesting and physics based by considering the 'stuff' that makes up objects i.e. if 2 objects are marked as solid then they can't occupy the same space.
    * The above precludes entities occupying the same space, but maybe you want that.
    * The above also assumes only 1 single tile occupies a location, maybe you want multiple tiles on a location, so maybe each location holds an array of tiles at that location, or maybe you want a linked-list if your other dimensions are sparse?
    * If your map becomes an array of locations, which each hold and array of 'things' on that location, maybe you don't need the entity array anymore and they can just live in the map. In some ways this simplifies things, in other it makes things trickier.
     
    Hope that helps you get clear which way you want to implement things, I'd say that if you're not sure have a play with various techniques, personally I love playing with 2d map representations and systems, maybe you will too!
  13. Like
    mattstyles got a reaction from Zenext in Canvas Tilemaps - Javascript Help   
    Yeah I know that feeling of being beaten down by a problem to the point where its difficult to even express it! It's usually a clue for a good nights sleep and to be tackled again when fresh!!
    I think I know what sort of thing you're after.
    How to express a tile and entity map has about as many solutions as there are developers out there! A common starting point might look the following:
    So, your map might be a 5x5 2d grid of locations, to simplify things lets express tile types as integers, 1 is a wall, 0 is floor and to simplify our rules even further, you can step on the floor but not on the wall:
    var map = [ 1, 1, 1, 1, 1, 1, 0, 0, 0, 1 ... ] var width = 5 function get (x, y) { return map[x * (y + width)] } This is a simple 1d representation of a 2d tile map with an associated getter function to convert 2d to 1d (which requires knowing the width of the grid), note that [0, 0] is top-left, x going right, y going down (yes, coordinate systems are important but we've just chosen the "easiest" representation).
    Now you need some sort of entity object (you might call it a class, but thats a bit ho-hum in JS):
    var player = { x: 1, y: 1 } You might want to add this player to an array of entities (or, even, an array of alive entities, depends what you want).
    This is about all your renderer needs to get rendering, throw the map array and the width and tell it to draw, then draw your entity on top in the correct location.
    To handle collision detection lets do something really simple, the following is semi-pseudo code:
    function checkMapCollision (x, y) { var target = get(x, y) return target === 0 } function handleMapCollision (entity, desired) { var isOkToMove = checkMapCollision(entity.x + desired.x, entity.y + desired.y) if (!isOkToMove) { return } entity.x += desired.x entity.y += desired.y } function onKeydown (key) { if (key === 'left') { handleMapCollision(player, {x: -1, y: 0}) } ... } Something like this would work (I've done it quickly, might have made a stupid mistake). Attach the `onKeydown` function to a keyboard (or joystick, or mouse, or touch, whatever) handler which responds to a key press event, takes the player entity and checks for a collision with the desired location, if all is ok then it updates the entity position so you either need to re-render or if you're using some sort of rendering loop then the position will update on the next render tick.
    This is pretty much the basis of it. Your next requirement is to check for collisions with entities, you pretty much do the same but rather than a spatial look up against a grid you'd probably want to loop over all active entities and check to see if any of them currently occupy the desired target location, if they do then run a function that handles what should happen when that collision occurs, otherwise loop through the map spatial check (above) and see if the desired target location is ok on the map or not.
    That really is about it, most other systems just add complexity on top of this simplistic model (obviously this is a very mature field pretty much as old as computer gaming, which isn't much younger than computing!).
    Some stuff you might want to look at doing:
    * Sometimes its easier to use [x, y] rather than `entity.x` and `entity.y`
    * Integers are fine for representing tiles and/or entities but you'd want another lookup table that maps that integer to an object which represents the actual object i.e. a wall object might have a flag (boolean) saying it is impassable, whereas a water tile might have a flag that states only flying, swimming or floating entities can enter it etc etc etc.
    * You might want to forego the integer (id) representation and just embed whole objects into your map and/or entity array but consider how distinct each element is i.e. if ALL of your walls are the same in a map and your map contains thousands of them then thats a load of memory you don't need to consume, just keep one wall object somewhere and your map array just references it.
    * If some of your map entities do differ from the blueprint/template for, say, a wall object, maybe you only want to store the differences.
    * The suggestion above notes looping over your entire entity array to find collisions, with 1000's of entities all moving this is expensive. You might want to look at techniques such as Octrees to simplify the search space (this gets technical real fast! but if you're diving in, then dive in!), if you want a warm-up maybe read up on A/B (or Black-Red trees) as Octrees are a more advanced (extra dimension/s) version, again, this gets technical real fast! I'd say its key learning for any developer!
    * Consider using a 2d array (or, an array or arrays) to hold your data, personally I dislike this approach but you might find it easier to use `map[0][1]` rather than using a getter.
    * Think about what to do when you have a collision, do you want a handler that takes the two 'things' that are colliding which decides what to do? i.e. this handler would map a collision between player and wall to a function, between player and enemy to another etc etc etc. As your list of possible colliders grows this can get tricky to manage, so maybe make it a little more interesting and physics based by considering the 'stuff' that makes up objects i.e. if 2 objects are marked as solid then they can't occupy the same space.
    * The above precludes entities occupying the same space, but maybe you want that.
    * The above also assumes only 1 single tile occupies a location, maybe you want multiple tiles on a location, so maybe each location holds an array of tiles at that location, or maybe you want a linked-list if your other dimensions are sparse?
    * If your map becomes an array of locations, which each hold and array of 'things' on that location, maybe you don't need the entity array anymore and they can just live in the map. In some ways this simplifies things, in other it makes things trickier.
     
    Hope that helps you get clear which way you want to implement things, I'd say that if you're not sure have a play with various techniques, personally I love playing with 2d map representations and systems, maybe you will too!
  14. Like
    mattstyles got a reaction from Outermedia in Make a Text game on HTML   
    Hello, and welcome to the forum.
    Most important thing is to get coding. Just get something up there on the screen in your browser and then keep working forward.
    Your first challenge is just working out how to get a simple message on the screen, this is the start of your text-based RPG and can be as simple as throwing an element in an HTML document and firing it in to your browser.
    Next challenge would be accepting some user input. So throw an input field on there.
    Now things get trickier. Work out how to get user inputted text out of that input field, you'll need to use that. This is a bit trickier but there is loads of information out there so get researching (get good at finding good information, MDN should be a first stop).
    Now that you know how to get user input and display some things on the screen its time to react to the user input. So you work out how to setup a handler that listens for the Enter key, when the user presses this you get the text out of the input field and work out what to do next. You probably want some conditional logic so a series of `if` statement could help, maybe even a `switch` (when you get really good there are some design patterns that can help you here), this is actually the start of your input handler code.
    By now you actually have a game of sorts, you've displayed a message to the user, gathered user input and reacted to that user input, this is 90% of most games. You are also starting to have a bit more code now so you'll want to start researching and thinking about different ways you can structure your code to make things easier for you.
    Where will you stick variables? Do you have any variables that affect your conditional logic when handling user input? If so, how do you make it available?
    The most important thing is to get coding.
    Don't get swayed by the 5000 JS frameworks and libraries out there, yes, lots of them will be useful to you, but its easy to get lost as JS is a very thriving language. Keep to the basics, learn how JS works, learn how it interacts with CSS and HTML, learn how to fire up a local server to get stuff in to the browser, none of these things are particularly trivial so take your time, do you research, and write lots and lots and lots of code, doesn't matter if most of it is crap, learn why its crap and how you can improve on it, even after 20 years of coding you'll still look back on some of the code you wrote last week/month and know that you could do it better, or learn (or remember!) a technique that would have helped.
    The most important thing is to get coding.
  15. Like
    mattstyles reacted to Murali in New to phaser and html5   
    Thank you for a detail pros and cons. I am eagerly forward to explore my knowledge in phaser.
  16. Like
    mattstyles got a reaction from Murali in New to phaser and html5   
    Phaser is a framework and works as most frameworks do across languages, it sets some standards for how to structure and plan your application and contains loads of code and patterns to help you create your product without the hassle of writing loads of boilerplate.
    In short, if you follow the patterns it dictates then it should be a breeze to get things up and running quickly and focussing on the logic that is specific to your application rather than spend a lot of time writing generic things like a state machine, rendering layer or user input handlers etc etc etc.
    Whilst there are lots of modules out there you can consume for the generic stuff, Phaser also does the glue between these individual bits which elevates it to framework status rather than collection of modules.
    Take a look through some of the examples and then start googling, there are lots more user-land examples out there, some very detailed about how to structure and code a game using the Phaser framework.
  17. Sad
    mattstyles got a reaction from enpu in Can a container only have 1 container?   
    How many containers can a container contain if a container can contain containers?
  18. Haha
    mattstyles got a reaction from Ninjadoodle in Can a container only have 1 container?   
    How many containers can a container contain if a container can contain containers?
  19. Like
    mattstyles got a reaction from labrat.mobi in Anyone Using Redux with Phaser?   
    I've got a number of tests for this sort of thing, biggest issue is simply with performance.
    Redux and redux-like libs aren't really designed for state that is changing frequently, the primary use-case being changes resulting from user or network actions, neither of which happen particularly frequently. Things like animations, which do trigger frequently whilst running, aren't usually kept within a centralised store.
    I've tested this with and without the complexity of rendering into a canvas (using Pixi rather than Phaser but the process is the same) and managing large lists of entities, all changing their position every tick, is pretty heavy, very hard to keep up with 60 fps.
    Depending on your use-case though, it is very definitely possible.
  20. Like
    mattstyles reacted to espace in access a link works on web and not on mobile   
    solved :
    //install plugin :inappbrowser in cocoon.io // this.testlink=function(){ var link="https://www.google.com" game.time.events.add(4000,function(){cordova.InAppBrowser.open(link, '_blank', 'location=yes')}) }; is_mobile && this.testlink();  
     
  21. Thanks
    mattstyles got a reaction from mla in Spirit animation not working - JS, Socket io, Express   
    This has nothing to do with multiplayer (express/socket.io) and, to be honest, you're not ready to tackle a multiplayer game.
    This is just a problem with how you're representing your game data.
    We can simplify things down easy enough.
    When the game starts create an array called `entities`. Now enter the main game loop. The game loop is simple and consists of:
    * Clear the current screen
    * Render the new screen
    * Gather inputs
    * Handle logic
    And that is it, this repeats until some exit condition completes (or crashes) your game.
    The bit you mention in your post happens in the `gather inputs` section so lets consider it, the `gather inputs` section is actually pretty dumb, it literally just gathers inputs, the next section deals with handling those inputs. Usually stuff in gathering input would be gathering mouse and keyboard interactions from the player. You're doing multiplayer so things shoot up in complexity as you must also handle network events, for now, lets just assume that we don't care about things like latency and packet drops and that all network traffic is a stream of events, this means they're basically synchronous, i.e. you can just handle them as they come in.
    You need to handle 2 network events, players joining and players leaving. You listen for these events in the gather input phase and handle them in the `handle logic` phase, although these two steps could intermingle (I'm not suggesting that, but it often happens, it isn't great but, depending on how complex you want to go might be the easier route).
    When a player joins give them an id and pop them on to the entity stack.
    When a player leaves inspect their id, find them in the entity stack and remove them.
    Each `render` phase loops over the entity stack and renders them. This is independent from the network and player events you're handling, shared only by read-only access to the entity stack.
  22. Like
    mattstyles got a reaction from b10b in Anyone Using Redux with Phaser?   
    I've got a number of tests for this sort of thing, biggest issue is simply with performance.
    Redux and redux-like libs aren't really designed for state that is changing frequently, the primary use-case being changes resulting from user or network actions, neither of which happen particularly frequently. Things like animations, which do trigger frequently whilst running, aren't usually kept within a centralised store.
    I've tested this with and without the complexity of rendering into a canvas (using Pixi rather than Phaser but the process is the same) and managing large lists of entities, all changing their position every tick, is pretty heavy, very hard to keep up with 60 fps.
    Depending on your use-case though, it is very definitely possible.
  23. Like
    mattstyles reacted to Rezoner in gunfight.io   
    The game is great - it should have been more popular in IO world, I think there are still a few places where you can get reasonable traffic - will send you a few tips that worked for me.
  24. Like
    mattstyles got a reaction from 8Observer8 in Make a Text game on HTML   
    Hello, and welcome to the forum.
    Most important thing is to get coding. Just get something up there on the screen in your browser and then keep working forward.
    Your first challenge is just working out how to get a simple message on the screen, this is the start of your text-based RPG and can be as simple as throwing an element in an HTML document and firing it in to your browser.
    Next challenge would be accepting some user input. So throw an input field on there.
    Now things get trickier. Work out how to get user inputted text out of that input field, you'll need to use that. This is a bit trickier but there is loads of information out there so get researching (get good at finding good information, MDN should be a first stop).
    Now that you know how to get user input and display some things on the screen its time to react to the user input. So you work out how to setup a handler that listens for the Enter key, when the user presses this you get the text out of the input field and work out what to do next. You probably want some conditional logic so a series of `if` statement could help, maybe even a `switch` (when you get really good there are some design patterns that can help you here), this is actually the start of your input handler code.
    By now you actually have a game of sorts, you've displayed a message to the user, gathered user input and reacted to that user input, this is 90% of most games. You are also starting to have a bit more code now so you'll want to start researching and thinking about different ways you can structure your code to make things easier for you.
    Where will you stick variables? Do you have any variables that affect your conditional logic when handling user input? If so, how do you make it available?
    The most important thing is to get coding.
    Don't get swayed by the 5000 JS frameworks and libraries out there, yes, lots of them will be useful to you, but its easy to get lost as JS is a very thriving language. Keep to the basics, learn how JS works, learn how it interacts with CSS and HTML, learn how to fire up a local server to get stuff in to the browser, none of these things are particularly trivial so take your time, do you research, and write lots and lots and lots of code, doesn't matter if most of it is crap, learn why its crap and how you can improve on it, even after 20 years of coding you'll still look back on some of the code you wrote last week/month and know that you could do it better, or learn (or remember!) a technique that would have helped.
    The most important thing is to get coding.
  25. Like
    mattstyles got a reaction from ivan.popelyshev in Adobe Animate Example Game   
    Yeah, I generally agree with TomC, these tools look amazing for trivial stuff but whenever you have to do anything with any complexity they can fall over.
    Having said that, there are plenty of indies here cranking out decent games using tools like this, so maybe I'm wrong.
    I guess it boils down to picking the right tool for the job and as much as you might grow to love a tool, always remember its limitations and don’t grow too attached.