Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


mattstyles last won the day on September 12 2019

mattstyles had the most liked content!

1 Follower

About mattstyles

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

8854 profile views
  1. Polling for keyboard events in the browser is unless as everything is event driven, so there is no need to poll, you can use event listeners to react to things like user input rather than continuing asking _if_ something happened. Regarding the OPs question, there are multiple ways that would be good: * Embrace the event and react immediately * Keep track of the _last_ key (or all keys) pressed since the last update, then within that update react to that key press (or sequence of keys) As you're a web dev you probably are used to the first method, and that totally works for
  2. 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
  3. 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 r
  4. That's nice using particles. Looks great. Using a shader would also be an option for water simulation.
  5. 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. 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 know
  7. Welcome to the forums @esocane If that is your first attempt, I can't wait to see what your tenth will look like, they were great! Well done! (edit: oops, misread, not necessarily your first attempt, they're great games though anyways!) I have some feedback (I played caves and oakwoods): * Map is great, I missed it in caves * Level gen felt more structured and less random in Oakwoods, I don't know if this is intentional or just coincidence. Random level gen is ok, but, its gets old really quick for players, there are some good techniques out there to help structure a level
  8. https://github.com/mozilla/BrowserQuest This one is really old, but still very very good
  9. Welcome to the forums @MrRitzy This sounds like great fun, but, yes, you are correct, it is quite complicated. But, I do not want to discourage you! Nothing worthwhile was ever trivial, so great cracking on it! You're going to need some javascript to make this all tick, so you'll have to make sure you have some skills there. Once you have some JS skills (sounds like you probably already have at least some, maybe you're already very good) you're going to need to work out how to persist some data. As its idle people are going to leave the tab/browser hosting your page/s, so you're
  10. 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
  11. mattstyles

    Game Data

    The answer depends on your use-case. Local storage is a great option for many use-cases. Some use-cases where it definitely is not a good solution: * Users playing from multiple devices/browsers (local storage lives in one browser and can not be shared) * Local storage, in theory, can be nuked at any time by the browser (I've never seen or heard of it happening, but, browsers make no guarantees)
  12. mattstyles

    Game Data

    What's wrong with your current system? If you answer that then you'll know what you need in a _better_ system. Without knowing an answer to the above then you're just mucking around. The options for storage that you have are reasonably limited. You can use an in-browser database (modern browsers all support indexeddb, edge will soon add it for v2, websql isn't completely supported), or send your game state off to a remote server to store how you like. None of these are better or worse than local storage, they're just different methods and what works _best_ for you is dependent on you
  13. 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
  14. Not a stupid question! This is the web and JS so there are, of course, multiple ways of skinning this cat. https://codepen.io/personalurban/pen/dBQQaK here is one way I knocked up. Its a canvas element on the page, with the spinner element also in the DOM. The order of the DOM dictates rendering order, but you could apply z-index via CSS if your DOM structure was different. The CSS is copy-pasted from https://projects.lukehaas.me/css-loaders/ after a brief google search for CSS spinners, there must be several thousand of these such sites. I've used a couple of set tim
  • Create New...