• Content count

  • Joined

  • Last visited

  • Days Won


mattstyles last won the day on August 25 2017

mattstyles had the most liked content!

About mattstyles

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

4,879 profile views
  1. JavaScript Factory Functions

    Factory functions are just a pattern, one of many you'll need in your toolbox if you want to be a success. Libraries/frameworks/etc might use that pattern, or they might use a different one, if you're using a framework I wouldn't recommend fighting against that frameworks idioms. The reason a framework works is that it dictates a certain style of coding and you get lots of advantages from working in that way. Frameworks tend to want to 'own' the application and allow you windows in to that architecture to do your own stuff. Great for when you agree with that architecture (or don't know how to create your own) as it saves loads of boilerplate code and will solve a great number of problems so you don't have to. Libraries/modules tend to be the opposite, you'll have to do the glueing together but they'll do the heavy lifting. Great for when you want more flexibility and are comfortable and confident enough to glue things together and deal with issues from doing so.
  2. Whereas in 2014 supporting Android was quite the pain, its now the case that Safari is a pain, hiding browser chrome being a real pain, wait until you try to deal with the taskbar (at the bottom) for Safari! At least its a damn sight easier to package HTML5 inside an app shell and publish to an app store if you wanted to go that route. WebGL and general device power is the biggest change, newer iPhones have as much single-core performance (which is all you care about with JS, usually) as high-end laptops from only a few years ago and I'm pretty sure Android phones are about the same, so, performance shouldn't be a major issue (depending what type of game you want to present).
  3. I started with a bunch of clones, but quickly got bored of cloning stuff and never really finished anything, although it was a good learning experience i.e. focus on the coding side of things whilst paying a bit of attention to what made these clones popular in the first place (i.e. learning the designing aspects as a by-product). I had much more success with stuff that was more 'original', i.e. put twists on games I liked to play, but, crucially, these usually crept in scope—being able to restrict scope, or, perhaps more accurately, to think in an agile way i.e. what incremental change can I make that heads towards this big end goal but is actually a small and manageable increment, is a crucial skill for anyone who builds stuff. This then evolved more in to fully fledged ideas, or seeds, that could become interesting games. I still have terrible trouble restricting scope and as a hobbyist my time is extremely limited to try and realise some of these dreams so you have to take in to account what is actually possible to get done, depending on whether you're a hobbyist, semi-pro or full-pro doing it. Each have different pros/cons to what you will be able to make (not counting whether you actually have the skills to complete your vision). I think @b10b has hit the nail on the head (and I've heard it from several other game/application design professionals), 'build what you want to play'. This gets a little tougher if you want to make a crust from game development, but, you'll have a far far better product if you really love what you're building, even if that is fairly niche. I think most, if not all, of the "best" and most successful games were made by a passionate group of people (or even individual) who really wanted to make that game. As a solo indie developer you'd need one weary eye on how to make it financial (take Concord for example, absolutely fantastic technical achievement but hard/impossible to make profitable so ultimately failed) but your overarching drive should be your passion.
  4. @Balamurugan Sounds like you have a specific question about a specific part of your game, sounds like it deserves a thread of its own. Try putting in a new thread what the exact problem is, what you've tried and what went wrong with what you tried.
  5. How to load next levels without game frameworks ?

    There's no great magic to it, an FSM is just a collection of nodes (states) and a collection of edges that determine mutation when the state changes. Many libraries implement an FSM by including a load of 'lifecycle' methods to the states, which can help determine the edges i.e the transitions. Traditionally transitions are synchronous i.e. changing a game state variable from 'menu' to 'play'. You mention loading, which is inherently asynchronous, so I suspect your problem is to due to treating a synchronous edge as an asynchronous mutation (which is totally possible, but often not worth it). In your case I think you need that defined load state, which handles the asynchronicity, i.e. you enter the load state with a variable somewhere that states the 'next' level, based on this 'next' level variable you load all assets required for this level and then transition to your play state. You shouldn't need setInterval or setTimeout, simply enter the load state, start loading stuff, listen for events when all loads have completed (and/or handle failures) then enter the play state.
  6. Cordova + iPhone X Display problems

    I think viewport cover just handles colour on the body element i.e. it isn't a real way to tell content to go 'behind' the notch. Did you try removing the safe area? edit: actually, I think I'm wrong and that article implies `viewport-fit:cover` should be enough. I'm guessing Construct 3 uses JS functions for determining viewport size to determine canvas size (rather than CSS) and maybe the issue lies there with this new device.
  7. Mousehover events in canvas!?

    The DOM exposes mouse over events but they work at the DOM element level, so, you'd get them for the canvas element but what you actually want is for elements inside the canvas element, however, these internal element aren't DOM elements so you need to map the mouse coordinates into your own in-canvas coordinate system, possibly working out whatever z-indexing method you're using, to work out which canvas element (sprite) the mouse is currently over. Most canvas rendering libs (such as Pixi) handle this mapping for you and expose elements on a per-canvas element (i.e a sprite) level which is akin to the DOM mouseover events, but for non-DOM elements.
  8. 2D Concept Artist & Illustrator for Hire

    Looks like you enjoy drawing bottoms! I whole-heartedly approve! In all seriousness, I'd love to see this more artistic hand-drawn style in more games (which is odd, as I'm a huge fan of pixel art, but, you know, difference is good right?)
  9. Basic Troubleshooting Help

    * Moved to Phaser forum as its Phaser specific about how to add elements to `game` * The button mask is irrelevant here, the error is still telling you (I think) that it doesn't know about the callback (this.checkAnswer). Whilst that function is defined there isn't enough info in your post to ascertain if it is actually in scope at the call site (game.add.button), try `console.log(this.checkAnswer)` in the line directly before the `game.add.button(...)` call. The `game.add.button(50, 250 + i * 75, "buttons", this.checkAnswer).frame = i` implies you have some looping logic, can you show the whole function? It definitely feels like a scoping issue. I'm also not sure that the add and then mutation works in one line, it probably does, but I'd instinctively think you should be doing the following: var button = game.add.button(50, 250 + i * 75, "buttons", this.checkAnswer) button.frame = i But I think this probably evaluates to the same anyway, and, in any case, the error is telling you the callback (I'm guessing this is the click handler) can't be called, which is most likely because `this.checkAnswer` is undefined, which could be a scoping issue caused by the loop I think you're using.
  10. Including API with Gamemaker: Studio

    It looks like this is an SDK approach to using their API (which is good in lots of ways), so you'll likely have to include a script tag in your page which adds the `cmgGameEvent` global function which you can then call. I have no idea how GMS works but I'm going to guess it allows you to add custom events to things like buttons when the user clicks so you'd add these function calls in there, which gives their API a chance to operate and serve the ads. That image is far from an API specification or SDK documentation though i.e. does `cmgGameEvent` trigger an ad to play or just give the API some info about current game state? If it does not play an ad then which function call does play the ad and how do you listen for when it is complete/dismissed? What they're asking seems totally reasonable (are they offering ad share or is that included in the non-exclusive price? actually, it doesn't matter), but it does sound like you need a bit more information about how to implement their ad-serving model. I also love that they've tried to explain how it works and taken the time to actually write in some rationale for it, it reads like they'd be open to a quick chat about it, but without more formal documentation it does make your implementation job a little tricky, things need to be very specific!
  11. radians and degrees conversion

    Most libraries also cache values (at least integer rotational values) and save themselves some processing cycles.
  12. 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?
  13. This is how scirra is treating its costumers

    Wow, that's fairly amazing. I'd have thought they'd just give you your money back, deactivate your account and then try to help you get back on your feet. I don't think Tom is being particularly obtuse though, he does sound like he is trying to get you back your feet with his product. However, when you feel let down and no longer even want to get back on your feet it's pretty bad not to just refund and move on. I naively assume this sort of thing doesn't happen anymore where information is so public, guess I'm wrong. Hope you get your money back without the hassle of having to sue them for it.
  14. 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. 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. 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. 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.
  15. Landscape or portrait mode for html5 game

    I'd totally forgotten about that API! Such a shame it doesn't have decent browser coverage, still, if your demographic are all Android Chrome users you're laughing!