mattstyles

Moderators
  • Content count

    1,390
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by mattstyles

  1. Guidelines for posting in this board

    @Viir there are already a couple of threads here that are devlogs, I think we're sticking with them in Game Showcase (for the moment at least).
  2. Using Phaser with Elixir + Phoenix, How To

    There will be certain calculations that will happen on the client (e.g where to render an object) and there are other calculations that could happen anywhere, such as the outcome of Unit A attacking Unit B (for example). For the 2nd case there you could do those calcs on the client, it'll likely be quicker that way (without waiting for network latency) and if you game is a single player experience then thats fine to take that approach (for multiplayer you could do that, but it maybe will be trickier). However, you could perform that attack-example calc on a remote service somewhere, which could be where Elixir/Phoenix is running (I don't know Phoenix, its not a browser client thing though right?). Looking through the docs Phoenix exposes a JS client which I'm guessing helps with this communication. It would be asynchronous so I guess it would be something like, invoke a remote function with some parameters and wait for the response, then do something with the response i.e. invoke 'Attack' with 'Unit 1' & 'Unit 2', your server then returns the outcome of that attack and you do some more client-side JS stuff to render (or otherwise manage) the outcome of that response. This process of invoking a function and handling a response is the same if you were executing a client-side JS function, the only difference being that it becomes a synchronous operation rather than an asynchronous one, but, conceptually, its about the same.
  3. PIXI es6 & Babel

    Ha ha, yeah, you're definitely right, and for 'real' builds I wouldn't care about timing too much, but for incremental builds (i.e. live/hot reloading) it would be a bit of a pain.
  4. PIXI es6 & Babel

    Totally agree that external modules are absolutely fine. I wonder what you're doing though that is causing such horrendous recompile times, I've stuck pixi.js through both Browserify and Webpack and had no issues with incremental builds with no effort on my part at all (the initial build does take a few seconds, but subsequent ones are quick because its only rebuilding stuff that has changed, and your dependencies won't, although that is checked against version number as well).
  5. Physics Bodies Not Moving With Sprite Group

    Seems a little strange, but I'm guessing its because rotating the group is actually changing the positions of all the objects in that group, rather than just changing the visual position. If you see what I mean: the actual positions of things and the visual position (on screen) are different things (or they could be, I'm guessing they are the same here), the physics engine should be calculating based on actual position whilst the visual rendering portion could look differently. I don't know how you'd achieve this with Phaser (I'd have tried doing what you're doing) but is there a way you can apply the 'camera' rotation before render and then unapply it for the update portion? I'm thinking out loud here, but would that solve the issue where physics (during update) would get the actual (untransformed) positions and then the render (during render) would get the applied transform?
  6. Ui testting tool for pixijs

    Anything that works with DOM elements (I think Protractor does that, most do, I haven't heard of Katalon) won't work. Not sure I've heard of one for testing canvas rendered stuff, apart from general screenshot testing. Would be a good tool though for sure if you do find one/make one.
  7. 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.
  8. var/let vs "cached" variables in game loop?

    @TomC Thats awesome! So much for Quantum being quantum-fast! However the difference between 40K and 860K, whilst a lot, is probably totally unnoticeable! Interestingly, Safari on my macbook is super quick, nearly 4 times faster than Chrome or FF Quantum, with Safari on my old iPhone 6S also faster than both browsers on my macbook. Weird. Like you, I'd have thought phones might perform worse for test2 (declared inside) but it looks like only FF has issue. Quite want to check on my quicker machine at home, and check Edge too there.
  9. var/let vs "cached" variables in game loop?

    I can't be certain without a jsperf (or other benchmark), but I'd still bet there would be no to negligible gains. The JS engine optimises loads of stuff like this away during JIT (or during hot-path evaluation whilst running). You might well want to reuse the object for other reasons though...
  10. Recommend me game design materials

    @b10b I haven't played it but I've read some great articles (via Twitter, which has Mariomania), love the idea of explicitly never punishing the player for failure. I was brought up roguelikes and the fairly recent glut of brutal roguelikes (only just roguelikes really!) means I'm a big fan of fairly brutal games, but the idea of the opposite is also very awesome. @mazoku designing games/anything is hard, really hard, almost always far tougher than the actual implementation. Try to read anything by designers on the sorts of games you like, for me this is Richard Garriott, Sid Meier, Peter Molyneux, David Braben etc (I'm sure there are more current examples, I'm fairly/incredibly old school). Most modern high-end games (tougher for smaller shops and indies to have time for it, but there are still plenty out there who enjoy writing about what they do) have blogs (or use medium/reddit—kind of—for the same purpose), try trawling through those. Books, if you can find one you like by a source you like, are great but sometimes don't go into enough detail on seemingly small decisions—from experience, UX stuff generally has no small decisions, things that seem very small can often have very important impacts for users/players. Consider, for example, a fog-of-war style mechanic in a top-down game (which affects field-of-vision), naturally, you might say, just make it so the player can see most of the screen but how much you reveal/hide can have a far reaching impact on how your game feels when played. This decision then moves on to how much you want the player to be able to modify the visibility range i.e. do I even allow them to get a torch to show more of the game? If I do and they light themselves to reveal more of the map then how does that affect how my game feels? Do I lose the claustrophobic or tense feeling that I've built up with a tight field-of-vision? As with all things, its an experience thing, a thing that can be honed be iteration. Make the best decision you feel you can do, but don't get attached to it, then try it out with a group of players and learn from their reactions, then assess again whether it was a good or bad decision. This can be done automatically but there is no substitute for sitting down with players and getting feedback, if you do it in person though just be sure you don't introduce any of your pre-conceptions or judgements, you want to learn from players to improve the experience and you can't do that if you pressure them into a decision one way or the other. Facebook is a prime of example of this sort of user testing, but they do it out in the wild (with focus groups in private also), its equally applicable to gaming, but can be quite resource-intensive and potentially harmful if you test something out that really doesn't work—facebook don't mind if they lose a few users from a group, they'll probably get them back and there are plenty more in any case, you likely don't have that reach so be a little warier of going balls deep on that one. The web is a great place to conduct this sort of user testing as you're not reliant on users downloading/installing your latest builds, although, to be fair, I can't seem to stop Steam games from updating whenever they please (there must be a setting somewhere!).
  11. RadialGradient

    beautiful, strong work
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. 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.
  19. 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
  20. 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.
  21. .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.
  22. 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.
  23. 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.
  24. 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).
  25. 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?