mattstyles

Moderators
  • Content Count

    1671
  • Joined

  • Last visited

  • Days Won

    24

Reputation Activity

  1. Thanks
    mattstyles got a reaction from mobileben in HTML5 game build environment and Cordova   
    I typically use Parcel as my bundler, which also handles an index.html out of the box (requires it actually), so when that 'watch' task runs it performs an incremental build based on what has changed and the output folder will typically contain html, JS, CSS (if generated) and images (if using directly) etc. The output folder becomes the stuff Cordova wants. I haven't fired up Cordova in a long time so don't know if that auto reloads things in Cordova, I never got to the stage of using it much so only ever fired up Cordova for a 'static' build for smoke-testing.
    The stuff such as IAP and other Cordova plugins: the Cordova bridge are just exposed global variables which it tacks on to 'window' at init time so they are available (typically) _before_ your code wants to use them. For in-browser use, you need to shim or mock those exposed globals. I.e. for IAP, it probably does something like expose a function with a callback or a promise, which you can then use to determine what has happened, for in-browser you just need to shim that function/promise with an expected result. I think that many Cordova plugins (such as the persistent storage stuff) will typically expose browser-based versions (where it makes sense) so you _could_ use those instead. Otherwise a custom HTML file with the shims attached in the head (for a dev build) would suffice I expect, although, shimming the entire API you are using (depending on the complexity of the plugin) could be tricky. Your workflow of devving in the browser isn't unusual though so hopefully the plugins you use will expose browser-based shims/mocks/functionality that you can use whilst developing your product.
  2. Thanks
    mattstyles got a reaction from mobileben in HTML5 game build environment and Cordova   
    I agree with Bruno and generally take a two-step approach (not that I've done it much, and only to proof-of-concept stage).
    Use your webpack build during development (using mocks as much as possible, quite a few Cordova plugins I've used actually provide these mocks for browser-based use, or even feature-complete ones browser versions), then use webpack to package it up and then use Cordova to take your built files and turn them in to a whatever cordova needs to run on a device. If you don't use any newer language features you can omit the webpack build step, but, you're using TS and no runtime understands it (yet) so you'll need to transpile it anyways.
    On the dev in browser thing, yes, this is great, but, make sure you do regularly check on a device. If you're on a Mac then the simulator is generally good enough (always always do smoke-testing on real devices though, at least, more is better but more is time-consuming so find a balance), I can't remember what tooling I used to simulate Android devices on my dev machine, I remember there were a couple of options and all worked without too much hassle. Again though, test on real devices. The more frequently you do this the better, but you need a balance because it is potentially time-consuming.
    I'm pretty sure you can set up Cordova in some sort of watch mode, again, you can do a two-step approach here where Webpack builds built files for Cordova, which is watching them and rebuilds itself when they change. I don't think there is any way to get hot reloading or even incremental builds like this though. Generally speaking, devving in the browser (where things like debugging are also easier and tooling is better for hot reloading, incremental builds, shims, mocks etc etc) will be good enough. Just don't forget the real devices, lest you risk something 'funky' slipping through (iOS Safari is the new IE6, there are some oddities you might run foul of).
  3. Like
    mattstyles got a reaction from jonforum in How to make waterfall using pixijs?   
    That's nice using particles. Looks great.
    Using a shader would also be an option for water simulation.
  4. Like
    mattstyles got a reaction from ivan.popelyshev in How to make waterfall using pixijs?   
    That's nice using particles. Looks great.
    Using a shader would also be an option for water simulation.
  5. Thanks
    mattstyles got a reaction from jSwtch in Latest version persists in browser   
    Can you check what you have in your package.json to make sure npm is doing what you think it's doing? i.e. making sure it's explicitly setting 5.1.2
    After that check the package.json inside pixi.js inside your node_modules folder for the version there.
    After that you need to make sure your bundler is not mucking around, as you mention a service worker it looks like you're already looking at this.
    _edit_ ooh, have you checked your package-lock.json file? it could well be the 'caching' issue is in there.
  6. Like
    mattstyles got a reaction from ivan.popelyshev in Latest version persists in browser   
    Can you check what you have in your package.json to make sure npm is doing what you think it's doing? i.e. making sure it's explicitly setting 5.1.2
    After that check the package.json inside pixi.js inside your node_modules folder for the version there.
    After that you need to make sure your bundler is not mucking around, as you mention a service worker it looks like you're already looking at this.
    _edit_ ooh, have you checked your package-lock.json file? it could well be the 'caching' issue is in there.
  7. Like
    mattstyles got a reaction from b10b in A little something to help with demos   
    I've just tidied up speedrun.
    If you want a quick way to get access to a modern JS toolchain for your demos then it might well be useful for you.
    I've also created a quick example project (using pixi, but you can use anything) for you to have a play with, available here.
    Getting Started
    The example project shows a pretty clean way to set up a demo project.
    It requires you to have node (and thus npm, the node package manager) on your development machine, and you’ll need git on your machine also if you want to clone the repository. With these prerequisites (and some knowledge of the command line) the following commands will get the project up and running:
    git clone git@github.com:mattstyles/speedrun-pixi-example.git cd speedrun-pixi-example npm install npm start These commands will clone the repository locally, then traverse in to that repository, then install the dependencies from npm that are required to run the project and then runs it. Running the project means starting up a local server to serve your files and creating a development environment including some features like transpilation of newer javascript language features, use of ES6 modules and hot-module reloading (HMR) as well as a few other goodies. All of these goodies are provided by parcel.
    Some more details
    A modern JS toolchain often includes some of the following features:
    * A development server to serve your files (rather than from the file:// protocol which has some restrictions you probably don’t want to deal with)
    * hot-module reloading i.e. incremental bundling of only the files that have changed, resulting in a faster feedback loop (this is subjective, not all of us, myself included, absolutely agree that this is a good thing)
    * Access to ES6 or CommonJS module systems
    * transpilation of newer language features that may or may not be supported (yet) in your development browser of choice
    This project uses `parcel` the do the bulk of the heavy lifting which gives you a few additional features:
    * Very fast bundling, for optimal feedback loops from changing source code to seeing the result of those changes in the browser
    * Friendly error logging, errors are propagated to the browser rather than remaining solely on the command line
    * Automatic bundling, this allows for automatic inclusion of images and css files
    * Many pre-packed transforms, allowing use of images, css, json, as well as language supersets like typescript or even separate transpilable languages like wasm, rust and openGL  (amongst other available transforms)
    The advantages are all subjective; there is a clear argument that this additional complexity simply is not worth it. However, access to a module system and newer language features is very attractive and projects like `parcel` can ease the problems of writing source code using these techniques.
    Many of us here like to create many small demos and proofs-of-concept, and `speedrun` can help ease the pain of setting up a toolchain for such projects.
    Many people here also aren’t comfortable with setting up a javascript toolchain to get access to things like a module system or newer language features. Speedrun hides this pain so you can get going, but it’s still worth (in my view) finding out how this stuff works, and speedrun or the example project won’t help here as it very deliberately abstracts this toolchain away. Thankfully there are many resources out there if you want to (and have time to) learn.
  8. Thanks
    mattstyles got a reaction from jar4563 in Server javascript code   
    Rightly or wrongly, most JS applications now use a build system of some sort, which means they have access to a module system, which means that they can understand `require` (which is CommonJS format, as used by Node, to complicate things, there is now ES6 module spec as well, using `import` and `export` syntax, mostly, build systems will understand both, mostly).
    As most JS apps use a build system this means that most JS libraries (such as found on npm, which is *not* just for node, its for JS, which includes node and client and IOT and and and etc etc etc) now _expect_ that build system and the module system that it allows. However, many many JS libraries also expose a client-only version of their library for those who do not want to use a build system.
    Even if you are building an entirely client-side application I would still advise setting up a build tool chain.
    Some disadvantages of a build chain:
    * Can be tricky to set up
    * Still not quite as simple as just running code in the browser
    Some advantages:
    * Many cross-browser issues disappear due to transpilation
    * You get access to a module system, helping you to organise your code base
    * Due to module system you get easier access to external libraries by using a service such as npm to access that code (i.e. you no longer have to reinvent the wheel and it is considerably safer than other methods of accessing third-party code)
    If you did want to go down the route of using a build system I think the following steps would get you there, usually without too much trouble, but, it might involve quite a lot of learning depending on how experienced you are:
    * Install node on your local machine, this side-installs npm, the node package manager.
    * Install a command line on your machine (if it does not already have it) and spend a few hours understanding how to use it.
    * Create a new folder for your new project.
    * From the command line run `npm init`, this sets up a new project.
    * From the command line run `npm install -g parcel-bundler`
    * Create an `index.html` file and put whatever you like in there
    * From the command line run `parcel index.html`
    At this point 1 of 2 things will happen:
    1) You will have port access issues on _some_ systems. Resolution to this depends on your machine, google the solution, there will be lots of solutions.
    2) You local server will fire up and will serve your index.html.
    If you run in to point 1, fix it, and you will be at point 2. This is good.
    Now cancel that running script (usually ctrl-C/cmd-C from the command line).
    From the command line run `parcel watch index.html`.
    Now you have a development build running.
    Change the code within index.html, switch back to your browser tab, see those changes instantly propagated in the browser _without_ a page refresh. It is magic.
    Beyond installing node (and npm), these steps are outlined in more detail at https://parceljs.org/getting_started.html.
    Parcel is one of many bundlers you may use, but it is the easiest to get going with (and very good I might add, but you have choices if you don't like it).
    Note that none of this is non-trivial, and its up to you if you think the advantages (which I have barely touched on) outweigh the initial cost of setup.
    Also note that this isn't necessarily the 'best' way to get started, I'd advise some changes, but, you can do those later. This is likely the easiest way to get going with build tooling for JS.
  9. Like
    mattstyles reacted to grelf in Integer pixels improve performance significantly   
    I have recently discovered a couple of useful pages about improving the speed of canvas operations. I will give links to those pages at the bottom of this item but first let me describe a good speed-up I got as a result of reading them.
    In my program The Forest (myforest.uk) I am continually looking for ways to improve the speed of drawing scenes. I have made several improvements already but this new one is very useful indeed.
    I have a Scene object with method draw() which is invoked whenever the observer moves or turns. From its earliest incarnation this method has reported how long it takes, so I can monitor what is going on. Its first line is
        var t0 = new Date ().getTime (); // ms
        
    and its last line calculates a difference and displays it in a status line on the HTML page:
        var dt = new Date ().getTime () - t0;
        forest.infoDiv.innerHTML = me.toString () + ", Drawn in " + dt + "ms (" + this.nDrawIms + " images)";
    I have augmented that so that the constructor of forest.scene includes
        this.drawingTimes = '';
    and a new final line at the end of draw():
        
        this.drawingTimes += dt + '<br>';
        
    I can cause drawing of the same scene over and over again by clicking a button labelled 'Look level' (as opposed to up or down buttons which would draw a slightly different view of the scene). This means I can build up a long string of forest.scene.drawingTimes. Then in a testing version I can press an otherwise unused key to dump those times as the innerHTML of a div in my HTML test page. The <br>s mean that I get a vertical column of values which I can then select, copy and paste into a spreadsheet (I use OpenOffice). Then it is easy to get the mean and standard deviation of the column.
    I did that twice for a large number of values. First with my last released version of The Forest and then with a tiny enhancement so that just before every time drawImage(im, x, y, width, height) is called I do this:
        x |= 0; y |= 0;
        
    Those are bitwise OR operations and their effect is simply to chop off the fractional parts of the screen coordinates x and y. This means that drawing starts on an exact pixel and does not require interpolation.
    The results:
        without the truncation (ORing) the mean time was 140.9ms with a standard deviation of 35.3ms;
        truncated the mean was 85.7ms and standard deviation 23.7ms.
        
    That is a very significant and useful improvement, so it will be going into my next version.
    The scene drawn here involved 1,693 calls to drawImage(), scaling each image (tree, ground, and other features) differently each time. From this big improvement I deduce that once drawImage() starts on an integer pixel then it uses integer pixels in the destination to decide where to get pixels from in the original image for scaling.
    In hindsight this is rather obvious really but I thought it would be useful to others to see how I went about proving the effect.
    I have noted before in this forum that the drawing time varies quite widely (as shown by the standard deviations) and I still attribute that to the workings of the garbage collector in the background.
    I should also point out that so far I have only measured this in FireFox.
    If you want to see more clearly what I am taking about, The Forest is at www.myforest.uk - from the initial map use the button (or key) to go to the scene.
    The pages which prompted this are:
    https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas
    https://www.html5rocks.com/en/tutorials/canvas/performance/
     
  10. Thanks
    mattstyles got a reaction from Jazcash in What is your folder structure for client/server games   
    This is a really tricky question for a generic answer as there are so many variables which _could_ dictate whether your project structure works well or not so well.
    Personally, I'd take any answers with a pinch of salt i.e. there is no single 'best' structure, like, not at all.
    Have a think about what the problems you are trying to solve are and how the processes and concepts you employ for organisation are going to solve that problem?
    To the above question, the answer is usually 'I do not know'. This is fine.
    With the above in mind it is usually better to follow this sort of process:
    Start the project. Put stuff anywhere, it does not matter at this stage. Get something working. Keep going. Now you have a working product and you can start to identify what organisational problems you have and think about how to solve them.
    Until this point you are largely guessing. If you have created several similar projects before your guesses are probably good, if not, then they might not be. It is relatively easy to apply some structure and organisation to a project that doesn't really have one, it can be pretty tricky to change organisational structure (can be, depends on many things again, you certainly should not be afraid to change later on if your current system turns out to be not very efficient).
    There are some rules of thumb that might help you though:
    Small files and folders are easier to manage than larger ones i.e. small in scope, not necessarily small in lines of code. Decouple things as much as possible, this makes them easier to work with, and makes organisation easier to change. Tight coupling is a nightmare, avoid at all costs. Uber objects (and, similarly, uber-projects) are hard to manage, this is really the above concern worded differently. Divide and conquer. UI and logic (rendering and smarts) are good things to separate. Avoid logic duplication, if you end up writing similar logic in multiple places, consider generalising and abstracting it. Utility functions can form a huge part of your codebase and is _usually_ a sign of good organisation. MVC is fine for games. As are other methodologies.
    Go with what you think makes most sense for you (and your team) and the project.
  11. Like
    mattstyles got a reaction from inyourpc in Flash to html5,playstore, Ios store - Suggest Plz   
    I still don't understand.
    Correct, this is made possible by browsers and hardware manufacturers. Not Unity.
    Unity is just one method of creating content for that platform and it is far from the most popular way of creating content. Maybe it'll 'take over' in the future, I doubt it, but maybe it will, but you can't say that right now.
    Unity is incredibly inefficient and clunky on the web, still.
    It provides tooling that, for some people, lets them create content faster.
    Think of it this way, a Fiat 500 is going to be built a lot faster than a Ferrari is, and, it'll get you to the shops and to work and back without any issue at all, but, most of us would 'prefer' to go on a fun drive in the Ferrari.
  12. Thanks
    mattstyles got a reaction from geeksesi::javad(); in What is your folder structure for client/server games   
    This is a really tricky question for a generic answer as there are so many variables which _could_ dictate whether your project structure works well or not so well.
    Personally, I'd take any answers with a pinch of salt i.e. there is no single 'best' structure, like, not at all.
    Have a think about what the problems you are trying to solve are and how the processes and concepts you employ for organisation are going to solve that problem?
    To the above question, the answer is usually 'I do not know'. This is fine.
    With the above in mind it is usually better to follow this sort of process:
    Start the project. Put stuff anywhere, it does not matter at this stage. Get something working. Keep going. Now you have a working product and you can start to identify what organisational problems you have and think about how to solve them.
    Until this point you are largely guessing. If you have created several similar projects before your guesses are probably good, if not, then they might not be. It is relatively easy to apply some structure and organisation to a project that doesn't really have one, it can be pretty tricky to change organisational structure (can be, depends on many things again, you certainly should not be afraid to change later on if your current system turns out to be not very efficient).
    There are some rules of thumb that might help you though:
    Small files and folders are easier to manage than larger ones i.e. small in scope, not necessarily small in lines of code. Decouple things as much as possible, this makes them easier to work with, and makes organisation easier to change. Tight coupling is a nightmare, avoid at all costs. Uber objects (and, similarly, uber-projects) are hard to manage, this is really the above concern worded differently. Divide and conquer. UI and logic (rendering and smarts) are good things to separate. Avoid logic duplication, if you end up writing similar logic in multiple places, consider generalising and abstracting it. Utility functions can form a huge part of your codebase and is _usually_ a sign of good organisation. MVC is fine for games. As are other methodologies.
    Go with what you think makes most sense for you (and your team) and the project.
  13. Like
    mattstyles got a reaction from inyourpc in Flash to html5,playstore, Ios store - Suggest Plz   
    How so?
    Nothing in saying that webgl is almost universally supported implies that Unity is the platform for creating web games.
    There is a saying, never bet against JS.
  14. Thanks
    mattstyles got a reaction from inyourpc in Flash to html5,playstore, Ios store - Suggest Plz   
    Why are you worried about webGL on phones?
    All modern phones (and not-so-modern) support webGL. I don't have concrete stats on _how_ well they support it (i.e. performance) but I haven't heard anything particularly worrying about using webGL via the web on mobile devices.
  15. Like
    mattstyles reacted to SlowCrow in The future of web games   
    There is Unity Tiny - It is in the early stages, but it should do exactly that: https://unity.com/solutions/instant-games
  16. Like
    mattstyles got a reaction from GameQuack.com in How to write game instructions?   
    Not just webgames, any games!
    Not just games, any applications!
    The easier you make it for people to just get going, the less friction they have, and the more likely they are to get to the 'am I having fun?'. Games like Dwarf Fortress take a lot of effort to get going, they lose a lot of players before they get to the 'am I having fun?' question.
    Affordance theory (presented initially by Gibson) is the theory that objects 'project' their usage, the normal example is a door handle, the shape of the handle implies gripping and turning, you can argue whether this is learned or innate but you can not argue that almost every one on the planet knows how to use a door handle without thinking about it. 
    The holy grail is to get your game/UI/app so intuitive that users just naturally fall into a 'pit of success' and are able to perform the actions they need to to meet their goals, i.e. win the game.
    I'd argue that advanced users might want more information, but, ideally that information should be in-game. The opposite view to this was popularised by Minecraft where players were encouraged to discover mechanics together, usually outside-of-the-game (at least initially) via the internet (youtube, forums, etc etc). Minecraft is a bit of an outlier for many practises though, but, its an interesting game mechanic to explore, of course, you need to player base in the first instance to be able to explore it.
  17. Like
    mattstyles got a reaction from GameQuack.com in How to write game instructions?   
    If you absolutely have to provide detailed game instructions, particularly to beginners, you're doing something wrong...
  18. Like
    mattstyles reacted to Gio in Cardlings, a digital board game   
    Hi everyone
    I've made a tactical strategy game (single and multipalyer) with the help of some very talented people, including some active users of this forum too.
    The game will be availble on Steam from June 5th for Windows, MacOs and Linux. Android and iOS versions will follow. Please check out the Steam page or the game's official site for more info.

    The game was made with our own game engine (WADE) which is free to use if you want to make your own games with it.
    I'll be writing some blog posts about the development of the game (what went right and what went wrong) as soon as I get a chance.
     
  19. Thanks
    mattstyles got a reaction from Balamurugan in TypeScript vs JavaScript?   
    Type correctness is a fallacy, and can not be implemented into a dynamic language without injecting into the runtime, which typescript does not do (although alternatives like flowcheck and some other libs for implementing flow do, it still does not make type checking a silver bullet). Much more info in this article.
    Having worked with it for an Angular 2 build (which was a horrific experience coincidentally) I can say that using TS creates so many headaches. Importing simple modules becomes an issue and often breaks your build, do you really want to spend half and hour importing a module you want?? Totally bonkers, it should just be a few keystrokes, a bit of network, and boom, get coding. I continually found inaccuracies in documentation as implementations changed which was a pain. I was worried about how TS performs some of its transforms without producing a horrible tangle of inefficient code, turns out that does happen, although a lot of people do work on making these transforms as efficient as possible, its just that some patterns are either not needed or don't work well in a dynamic language. There is also a barrier for every other JS dev, you force them to use TS and not everyone will want to do that (this depends on your project though).
    The additional killer is that TS is not spec, whilst a lot of what it started considered spec, and certainly its implementation helped the spec to evolve, its a worry. Every time you move away from spec (like Webpack does with modules) you are at risk of moving further away from your chosen language, which is crazy, if your language doesn't support the stuff you want to do then choose another, don't mutate your language beyond recognition, as a web dev you are in a position of luxury here because if the web is your chosen platform then its JS so everything has a pipeline to output JS these days.
    Typing is useful for large teams as it can make the code easier to understand, but I could dispute this by saying that it introduces a load of clutter and types can be gleaned by a bit of inline documentation, although you wouldn't get static checking (but, see the earlier link, static checking won't secure your program, to the point where it could be pointless). On that, the number of times in TS code I've seen the type specified as <any> because devs haven't put enough effort in (or ran out of time, or, sometimes, been forced in to it because typing is square peg round hole for JS) is shocking and clearly unhelpful.
    Having said all this, it is gaining popularity so its certainly worth checking out, particularly if you're fond of strongly typed languages (just remember JS is not, and without killing your performance nothing will make it so).
    Nothing can get you away from this, despite the newer ES2015 class syntax, JS is NOT a classical language. The class syntax is simply sugar around creating a class-like abstraction in a prototypal world.
    There is nothing superior about OOP or classes, it is simply a different style/flavour/design choice.
    The reason I bring it up is that if you keep up with a mindset that one thing is superior over another you will overlook anything you deem inferior which means you won't learn its pros/cons and you'll get stuck in your superior world even when you start working on something where that does not make sense. Feel free to ignore, but I'd be wary of pigeon-holing yourself or your tech choices. Learn it all and learn when each different thing makes sense and when it does not. Particularly in the fast-paced JS world, something only remains superior for 6 months, so unless you want to become a dinosaur, keep moving!  
  20. Like
    mattstyles reacted to grelf in 2D Map Representation as 1D array   
    I have managed to rewrite my scene drawing (in www. myforest.uk) so that it does not reallocate two huge arrays and fill them with freshly created objects every time. This rewriting reduces the scene drawing time by about 30%. There is also less variability in the time taken from one scene to another which tends to confirm that garbage collection and reallocation were taking a lot of the time. Reallocation would be variable because it depends so much on what contiguous chunks of memory are available.
    I have written the following to show some things that developers may need to consider in their own code.
    My terrain is generated by a function of (x, y) position (in fact a method of an object of type Terra). It is a complicated function so it does not want to be done repeatedly for each position; instead its results must be held in arrays for subsequent reference during scene building. Two big arrays hold the results of that around the (moving) observer's current position to enable the scene to be drawn. For each position the arrays refer to an object of type ScenePoint which contains the distance and bearing of the point from the observer and other things (such as terrain details and amount of fogging for distant points). Each ScenePoint object has 10 properties so requires at least 80 bytes, probably more like 100 bytes allowing for the Object structure itself (I think that varies from browser to browser).
    One of the big arrays, around [x][y], goes out to the current view range which is user-selectable and can be up to 400 meters, so the array may have to be 801 x 801 to surround the observer. This is now allocated at the start of the program. Each array value will be a reference to a ScenePoint object so the array itself takes 8 x 801 x 801 = 5.1 megabytes. Then the 801 x 801 ScenePoint objects, also now allocated once at the start instead of freshly in each call to Scene.draw (), occupy about 100 x 801 x 801 = 64 megabytes.
    Another array, ahead , contains references to the same ScenePoint objects but is sorted during scene drawing so that the most distant points come first. This array does not contain references to objects behind the observer and so it is allocated as new Array (400 x 801). It requires a mere 8 x 400 x 801 = 2.6 megabytes.
    So my latest version of The Forest, v19.4.10 (see www.myforest.uk ) allocates just over 70 Mbytes when it starts and then no longer has to reallocate this (in many pieces) every time a scene is drawn.
    I still find it remarkable that my scene drawing is done in a couple of seconds even for the 400 metre horizon range. During that time the 'ahead' array is sorted too!
    When starting to draw a scene 'ahead' has to have all its elements set to undefined because as the observer moves and turns a varying number of points can lie ahead. I rely on the specification for Array.sort() which says that undefined elements get sorted to the end of an array.
    To support all this I have written a new JavaScript file to create one object of type Around. People may be interested to see it (below) but first
    Matt: Having made this change it was then easy to experiment with making 'around' a 1D array instead of 2D, calculating the index from x and y myself. I found no difference in performance (in FireFox).
    // Part of The Forest www.grelf.net (www.myforest.uk)
    // Copyright (c) Graham Relf, UK, 2019
    /** One object of this type is constructed at the start to avoid reallocating
      * big arrays every time a scene is drawn */
    function Around ()
    {
      var el = document.getElementById ("range");
      this.aMid = 0; // The middle index of each x/y array
      // Find largest range user may select:
      for (var i = 0; i < el.options.length; i++)
      {
        var r = parseInt (el.options .value);
        if (r > this.aMid) this.aMid = r;
      }
      var wd = 2 * this.aMid + 1;
      this.aheadChange (this.aMid);
      this.around = new Array (wd);
      for (var x = 0; x < wd; x++)
      {
        this.around [x] = new Array (wd);
        for (var y = 0; y < wd; y++)
        {
          this.around [x][y] = new ScenePoint (0, 0, 0, 0, 0);
        }
      }
    }
    /** Use at the start of drawing a new scene
      * NB: mex, mey are rounded observer coordinates */
    Around.prototype.init = function (mex, mey)
    {
      this.xOffset = this.aMid - mex;
      this.yOffset = this.aMid - mey;
      // Clear previous scene:
      for (var i = 0; i < this.nAhead; i++) this.ahead = undefined;
      this.nAhead = 0;
    };
    /** Only used if user changes the range (and in Around constructor) */
    Around.prototype.aheadChange = function (range)
    {
      this.ahead = new Array (2 * range * range);
      this.nAhead = 0;
    };
    /** Add a ScenePoint object reference to the scene ahead */
    Around.prototype.aheadPush = function (sp)
    {
      this.ahead [this.nAhead] = sp;
      this.nAhead++;
    };
    /** How many active ScenePoint objects are currently ahead */
    Around.prototype.aheadLength = function ()
    {
      return this.nAhead;
    };
    /** Get a reference to the ith ScenePoint object ahead */
    Around.prototype.aheadGet = function (i)
    {
      return this.ahead ;
    };
    /** Sort the ahead array in descending order of distance */
    Around.prototype.aheadSort = function ()
    {
      this.ahead.sort (ScenePoint.prototype.sort);
    };
    /** Get a reference to the ScenePoint object at (x, y).
      * This is so that extra properties can be added to it. */
    Around.prototype.aroundGet = function (x, y)
    {
      return this.around [x + this.xOffset][y + this.yOffset];
    };
    /** Set the fields of the ScenePoint at (x, y) as if freshly constructed */
    Around.prototype.aroundSet = function (distance, bearing, x, y, odd)
    {
      var sp = this.around[x + this.xOffset][y + this.yOffset];
      sp.fogNo = 0;
      sp.tr = undefined;
      sp.building = undefined;
      sp.drawn = undefined;
      sp.clear = undefined;
      sp.d = distance;
      sp.b = bearing;
      sp.x = x;
      sp.y = y;
      sp.o = odd;
    };
    Note that in my previous version of Scene.draw () each ScenePoint object was freshly constructed and subsequently might or might not get extra properties added  (such as .tr or .drawn). That was poor practice really. For easier maintenance it should be clear in the constructor as to what properties an object can have.
     

  21. Thanks
    mattstyles got a reaction from sachu in Phaser Can't Find/Load My Assets and Spreadsheets [HELP]   
    Nah, it probably wasn't you, its the path serving, it can go a bit screwy (depending on the bundler) when you import straight in to your code like that. There can also be a difference (again, depending on the bundler setup) between prod and dev builds. It all depends how they handle asset loading.
  22. Like
    mattstyles reacted to lapamplamouse in Phaser 3 Matter Physics - touch controls   
    Thanks for your reply, but I just got it working.
    Yes, I want the slide type controls.
    I added a sprite for the tiller, and created a touch rotate function for it using 'pointermove'. I then record the rotation of the tiller and translate that to the degree to which the boat turns.
  23. Like
    mattstyles got a reaction from sachu in Phaser Can't Find/Load My Assets and Spreadsheets [HELP]   
    The issue is your bundler. When you add non-standard things to your 'regular' JS, you can't expect perfect interoperability with JS libraries (such as Phaser) which expect you to write in JS.
    The issue lies with however your bundler transforms `./assets/button.png`, usually, this will become a file path, which would work fine if, and only if, the paths are correct. I am going to guess that in your case, they are not correct, hence the 404.
    More strangely, it doesn't even try to insert a path, just the variable name, which either means you're calling Phaser functions wrong, or, the bundler is really mucking you around.
    Most bundlers that allow you to import asset paths also will handle packing those assets and they _should_ also handle serving it for you in the same way they're serving your HTML and other static code assets.
  24. Like
    mattstyles reacted to b10b in What to do if my game is published without my permission   
    Sorry to hear this, it's frustrating and not uncommon for quality games.  Locking a game will have limited benefit, don't blame yourself.  Practical advice is don't spend more than 5 minutes worrying about it (a DMCA takedown should take less than 5 mins once you've done it a couple of times).  Some additional takeaways are: 1) brand future games in multiple ways so stolen traffic still promotes the author and proper licensing channels, 2) develop server-authoritative or partner-publishing strategies for monetization, 3) offer paying customers more value than what they could achieve by stealing, 4) remember a sequel is quicker for the original author to make - and everyone prefers to play the latest greatest - so if stolen games get traction cash in later.
  25. Like
    mattstyles got a reaction from webdva in I hate designing levels!   
    Procedural generation can be a load of fun, but its a butt-ton of work to get working well.
    You could even use a genetic algorithm (GA) to create levels, have an automated actor play them, test the 'success' of the actor using fitness functions and then loop that process until you get levels (again, based on a heuristic function) that are fun to play. The up-shoot is that you can, potentially, create a near infinite number of levels like this. Or at least generate a manageable amount (say, 30) and manually curate them. Depending on how good your heuristics are you can create levels that are harder or easier for humans to play.
    It's a ton of work though. So depends on your mindset. Some crazy people find that a wonderful coding challenge.