mattstyles

Moderators
  • Content count

    1,379
  • Joined

  • Last visited

  • Days Won

    13

mattstyles last won the day on August 25

mattstyles had the most liked content!

About mattstyles

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    github.com/mattstyles
  • Twitter
    personalurban

Profile Information

  • Gender
    Not Telling
  • Location
    UK

Recent Profile Visitors

4,051 profile views
  1. Group and foreach

    Deffo not a stupid question, JS scoping can be a little misleading, or, surprising, particularly if you come with any knowledge from real classical languages. There is another option using arrow functions: .forEach(item => { // do something }) However, some libraries will try to scope your function (using .bind usually) so it won't always work as expected. Also also, arrow function scoping is even more confusing.
  2. format json problem

    Why would you ever want to store extra bytes into local storage? Just stringify it `JSON.stringify({foo: 'bar'})` on the way in and parse it on the way out, don't worry about making local storage formatted, totally pointless.
  3. Group and foreach

    I'm not sure how `enemyPool` or the `forEachAlive` function works but often this sort of thing is a scoping issue (although the error you've reported is slightly wrong for a scope issue). The problem is that JS is sometimes a little unexpected for scoping and so any time you use a class or object you have to work with `this`, which is a common cause of issue. In your case I think that (maybe) you should just scope the callback function, you have some options here: this.enemyPool.forEachAlive(function(enemy){ enemyTween = this.game.add.tween(enemy) }, this) Notice the following `this` after the function declaration, usually the `forEachAlive` function can accepts another parameter that defines scope. You can also do this explicitly by calling `bind` yourself: this.enemyPool.forEachAlive(function(enemy){ enemyTween = this.game.add.tween(enemy) }.bind(this)) `bind` sets the `this` of a function. You have another potential issue though: enemyTween: function(){ this.enemyPool.forEachAlive(function(enemy){ enemyTween = this.game.add.tween(enemy) }) } You're overwriting `enemyTween`, hard to tell without seeing the rest of the code but its probably bad.
  4. Saving and Loading

    Minecraft (I don't think) saves all those blocks either, nor does it have to, if you've used git source control then you'll be familiar with the concept of 'diffs', which I think is how Minecraft saves world data. In any case the following limits the amount you have to save, you need 2 things: * A pure deterministic world generation algorithm * Understanding how to store diffs against the deterministic world The process is actually really simple: Generate a seed (number, string, anything, doesn't matter) and use that seed to generate a world, the algorithm must be pure (referentially transparent) i.e. the same seed always produces the same structure (world map), an easy way to achieve this is to use the seed to seed a random number generator. No-one wants to make their own RNG, so pick one out there that allows supplying a seed (note that RNG is proper tricky, inside a computer people actually use its normally fairly easy to maintain entropy, on a server it can be trickier, mostly whatever OS you are running handles keeping entropy up). If your world map is immutable then you only ever need to store the seed, that'll deffo fit in local storage as it'll likely only be a few bytes. In this case it doesn't matter how much of the world has been explored on a previous visit, you can generate it on the next playthrough from the stored seed, so long as your algorithm is pure then you know the world will always be the same, so long as you can generate the world fast enough as your player moves around you're laughing but you'll have this problem anyway. If your world map is mutable (like vanilla Minecraft) then you'll have to work a little harder. Storing everything you've generated is the naive approach and, as you've noticed, doesn't work very well. The thing is, not much of your world will actually change, so just store the changes, this vastly reduces the problem space. Just store the diffs between world gen and current state. You'd also want a way to overwrite previous diffs where necessary, i.e. I place a stone block at [10, 12], then a wood block in the same place, well, you only store the diff between world gen and placing the wood block and nuke the previous diff that mentioned the stone block. On the next (loaded) play through you generate the world using the seed, then apply the stored diffs to regain where the player left off. To further reduce save/load times save/load only what you currently need i.e. when a player leaves an area save it, when they enter an area load it.
  5. do people still go to web portals to play games?

    If they still exist then they're still making money, which means people are playing
  6. Text based game

    A prologue/demo to test the water is a great idea. I've got about 3-4 proof of concepts and rough designs for games that would fall in to that category and I've just started to really kick the tyres on creating a game that has 'a dark room' has inspiration (although its ended up very different). I love text adventures and looking through iOS app store saw quite a few, although most looked like variants based on the same framework, no idea how popular. A dark room (and the follow up) was very successful, but text-heavy/graphic-light stuff is (and pretty much always has been) fairly niche, niches can be good but I'm not convinced you'll ever make money out of it, but, it sounds like you're more interested in people playing than money making (very good if that is true!) so I'd say there would be a small market, problem might be targeting potential players, but thats pretty much try of any product.
  7. oh, ok, you can conditionally add a script tag later (which is how many analytics or font loaders work), something like this should work: var script = document.createElement('script') script.src = 'src/main.js' document.body.appendChild(script) You have to append it to and let the browser load it normally, technically you could grab the text and eval it but you don't want to do that! Just add the script tag and let the browser work as normal. You don't need the global flag either with this method, you just whack in script:src='main.js' if you host it outside of canvas+, and use the small script above to add scripts to the page when you are in canvas+ land. If you have a couple of files just extract that script above into a function that accepts the src/main.js and creates and appends those scripts for you.
  8. Typescript vs Javascript

    There are quite a few threads on TypeScript adoption, have a search through for some fairly detailed discussions of pros/cons. The very very very short (not putting them as pros/cons as some could be pros or could be cons depending on your point of view): Javascript: * Won the browser war, browsers don't run anything else so whatever you write your source code in, it'll need to be JS by the time it hits your platform (i.e. the browser, or browser-like environment such as Electron or Cordova). * A very permissive language capable of making a good stab at a number of different coding styles * A growing language, due to great support JS regularly adds new stuff to the language (some of the recent new stuff has come from subsets like Typescript and Coffeescript) * JS runs in a browser, browsers implement JS engines sometimes differently, leading to unexpected results. Not really a language problem, but something to be aware of. If you transpile your code (i.e. write source in Typescript but compile it to JS) then this can sometimes round off the nasty edges with browser incompatibilities, sometimes create more problems. * JS is generally an easy language to pick up, some of its ease-of-use results in nasties and inconsistencies further down the line. * Writing in the language that your program will be running in (i.e. vanilla JS) will always have less friction than requiring a transpilation step (i.e. Typescript -> JS) Typescript: * Adds rudimentary type support to JS, I say rudimentary because JS does not support types and so (if being absolutely brutal) its a massive hack. It does this via static analysis, although TS have recently added something to do this at runtime (during a dev build, it adds a big perf hit), other type systems (such as Flow) have had this capability for a long time. If you want to perform code branching based on types then TS isn't going to help, its just a checker. * As a documentation tool it is useful, although your code will become more verbose, but, knowing expected types is useful (I say expected because JS can not enforce it), magic comments also get you there, but aren't as elegant. * TS compiles back to JS so there should be no perf problems when it hits the browser, infact, the transpilation is so good there may be cases where it writes it better than you could (ditto for other top transpilers like Babel). * Generally speaking working with types is slower for you as a developer, but as your product matures you may find some benefits later on if you have your typed all laid out * TS has a typed get-out-of-jail-free card by using <any>, to ignore typing, try not to use this * Using TS with external modules is not friction-less, infact, it can be a major pain in the butt * TS will not (generally) catch any bugs, not tricky ones anyway, don't believe the hype, write unit tests if you value your sanity, TS can help pinpoint some common coding errors but it won't help eliminate anything non-trivial
  9. Drawing the UI with the DOM

    Ha ha, I think you do realise that these two things are very tightly related! The reason other frameworks have deviated away from two-way binding is because perf gets tricky. What I think you really want is just an abstraction so you don't have to think about it when your unit stats update themselves. I like to use HTML for UI layer/s, for reasons you've stated, but, if you data is changing as frequently as your 60 fps main screen maybe throwing it all though canvas would be better and you just take the hit the actual coding of responsive stuff inside canvas (I recently did a quick summary of modules for rendering loads of data into tables, a canvas based module was pretty conclusively the fastest across almost all tests). Put it this way: Why observe changes to every object when you can react to those changes before (or whilst) they happen? If that doesn't make sense consider the following: * Trigger a function that updates an object * Observing function triggers on the update * Some stuff happens due to the observer triggering -> probably calculate what changed in the UI and redraw The system that causes mutations to your object (point 1) and the system that watch it (point 2) look decoupled, but, in practise you'd probably punt those together i.e. when you create an update to an object you also fire an event to say 'I've changed' from the same place. All things like Redux (and other stuff like Flux, designed to work with React) do is take away the mutation part, so you have a trigger, which causes a mutation, which causes a redraw. You don't actually want 2-way binding like Angular 1, you just want a way to implement stuff that React/Vue/Ng2 do without really thinking about it (I think). I think what complicates it is that you have 2 competing data stores, you game data, and your reducers (for redux) and you don't want to mix the two, which is fair enough. You don't have to use the usual React mechanism of triggering redraws only when something in its state changes, you can take that responsibility away from redux. The redux issue I think you are facing is that you are creating references to objects, when they change redux doesn't know about it and even if it did (i.e. you fired a message for redux to evaluate, which is impossible, but, imagine) it typically performs '==' or '===' evaluation which wouldn't understand that an object has changed, only that the reference is the same, so, the change becomes invisible and it doesn't rerender. However, YOU know the update took place so just force React to re-render, that impossible message above becomes trivial, if effect its the observer function from point 2 above, just have React re-render itself (you may additionally have to do some work with the `shouldComponentUpdate` method to make sure it re-renders). To be honest, Vue or Ng2 might make this easier by doing some of this heavy lifting for you, I don't know, and I don't know if there would be any perf hits from doing this.
  10. .io ending of multiplayer games

    It wasn't cheap May 11th either They've always been expensive. This explains a little https://gigaom.com/2014/06/30/the-dark-side-of-io-how-the-u-k-is-making-web-domain-profits-from-a-shady-cold-war-land-deal/, its from 2014.
  11. With canvas+ you specify the index.html right? Which might be different than the one you would use to push it to a url, for example. So, the absolute simplest way is to just add a global to the page for the canvas+ implementation: <script> window.isCanvasPlus = true </script> Then in your code just use an if to check for this variable: if (window.isCanvasPlus) { // run canvas+ code } As JS is permissive about variable types the above will continue to work as isCanvasPlus undefined will be falsy.
  12. Yeah, its an optimisation thing so really you should have decent tests in place to make sure that its working as intended, but, I think with object pooling most peeps just take the opinion that they're going to run into issues without it at some stage so start out with object pooling in mind.
  13. Personal Journal for New Developer

    Sounds awesome, very commendable thing to do! Yep, that tends to be the way with frameworks, but its absolutely essential (in my opinion) that developers really learn how to do this stuff by implementing it themselves, then the dev has an idea why the frameworks make the decisions they do. Once you've learnt all that stuff then you'd want to use frameworks to do all the heavy lifting for you, with the added benefit that the framework should be well tested for both reliability and perf, not to mention that a decent framework will always be looking for better ways to do things and by continually updating that framework you get these benefits largely for free whilst your time is freed up to work on your actual game i.e. features that give real tangible benefits to your users (in addition to bonuses in performance you get from the framework of choice continually becoming better).
  14. Should pixi.js webGL work in electron?

    I literally had no idea there was this switch, I'm guessing pixi will use webgl for you in chrome right?
  15. This is an incredibly dangerous thing to promote, its also untrue, whilst there is no 'intrusive' ui common to advertising there most certainly is an effect on the hardware of the device running the software, what would you rather: dismiss an annoying advert or replace your expensive phone/computer because the GPU is fried from all these apps molesting it? At the very least you should clarify that there ARE effects on your game players, probably better to remove mention of the whole thing (unless you do infact endorse this practise, in which case you have far bigger problems). Not to mention every serious browser is actively trying to combat these sorts of shenanigans.