mattstyles

Moderators
  • Content count

    1,228
  • Joined

  • Last visited

  • Days Won

    11

mattstyles last won the day on March 4

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

3,238 profile views
  1. @Nesh108 You can't send UDP from a browser, webRTC can send unordered-unreliable packets but its really really tricky to get it to do so (even agar.io won't touch it, not yet anyway).
  2. One thing that I does strike is that most of those modules can be stand-alone, possibly when you include them into your framework you add some glue, but it would be a good thing to be able to install only parts of a larger framework. Things such as noise generators, terrain generators, UI components etc etc all have value standalone, even if their primary use-case is as part of a larger framework. Given that multiple instances of these types of modules already exist I've no idea why people (outside of a learning endeavour) code these things themselves but if you're going to, I'd look in to making them standalone and then work on including them in your framework project. So many benefits for both you as developer and for your users.
  3. Yeah, there isn't much getting around this, small objects are often created frequently if the state changes frequently, as it will do with gaming, and it can be/or is a problem. If you take the Elm architecture (implemented by Redux if you're familiar with that library) is that state for the entire app is kept in one structure and then it is recreated for every change to the structure. For a situation where your state tree contains hundreds of entries and you just change one boolean somewhere in there a naive approach would be to recreate the entire state tree, even though you're only changing one value, which is very wasteful, however, you might be surprised at how good the JS engine is at compiling such changes to reuse as much as you can at it'll do this underneath JS so you can't (and don't really want to, so long as it working!) touch it. ImmutableJS takes this recreation of state a step further by creating changes that reuse as much of the data structure as it can at the JS level. See Another key thing to employ here is memoization, which can be extremely easy with pure functions. Memoization is the process of remembering previous operations (often just the last one) and just returning the memoized value if inputs are the same, this means there is just an equality check to hit perf which is super cheap. Libraries like reselect implement this to great effect. Of course, you don't have to stick with FP techniques for everything, for example, you might choose to use it for your slower-paced UI elements and have your main game camera/screen using other techniques. I imagine that might get annoying but it would certainly work well.
  4. Yep, platform detection is always one of those things, "it works today", no guarantee it'll work tomorrow and you really don't want to keep a matrix of detection up to date, not to mention that whatever you are expecting on that platform could change (depending on what you want to do of course). See if you can find a library that can handle this, one with enough resources working on it to keep it up to date. Although far better is feature detection, as that is about as future-proof as you get with JS.
  5. That's awesome, and don't be afraid to have some local state for components, often it makes more sense to put it there. I sometimes think about it by treating the main state object (in this redux, but there are lots of other data libs out there) as a permanent store, i.e, if I refreshed what state would I need to replicate the previous (pre-refresh) state, if I could do without some state, such as whether an input field is focused, then that is a candidate for local component state (unless its trivial to add it to 'global' state). I checked out your project, worked great (although I got some casing warnings about certain libs, React vs react, which hints that something pretty odd might be going on, stupid webpack), had a quick glance at the code, looks great. Interesting to see react used to render svg as well, you mention pixi, have you seen react-pixi? It bolts pixi on as a renderer to react so that pixi can respond to react diffs, I tried it a little while ago and it seemed to work well but I'm itching to kick the tires on it more as FP can be a little hard on the performance for frequently changing apps (such as most games). I've been playing recently with different ways to render and update very large tile maps, an interesting challenge to get performant. I created a lib before redux came out (it is very very similar functionally to redux but a slightly different implementation strategy) and have been working to get it more performant alongside, challenging but fun stuff. Also, I see you're using redux-thunk, thats a great lib but quite limited, if you find you're doing more and more logic, particularly asynchronous data changes, check out redux-saga, its a simply wonderful library. I've been using it for nearly a year now on a complicated ecommerce project with lots and lots of data handling, mostly async, and it keeps getting better and better, a truly incredible library.
  6. Just google it, there are loads of copy-paste scripts out there that will attempt to detect pretty much every common browser/platform out there. Browser/platform detection is pretty rubbish though, try to use feature detection instead.
  7. Good job finding a solution, and thanks for posting it, it'll surely help others in the same situation
  8. I love this statement, but it would never apply to my dependencies (although I am often tempted). Users don't care how you made your app/game, they just want it to be fun. If the framework/library/tool you use to create games means everything comes out smelling samey then thats a failing of the tool. Most of the big frameworks mentioned in this post are flexible enough to create most styles of games. The problem with smaller maintained, or smaller used, frameworks/libraries are what happens when it goes wrong, how quickly can the community or the maintainers get you back on your feet? If its OSS I could make the changes myself and contribute, but, I'm using a framework so I don't really have to. How quickly can they make performance, security or other updates? without good docs and a good community how are you going to learn it? Pick through their code, yep, that would work, but slow going. I'm come to the opinion that peeps can create and maintain small modules in their spare time and most will accept some latency in responding to issues, but for anything mildly complex it really needs a dedicated team, at least part time dedicated, to make it work. I totally agree with these 3, in my view a great set of criteria for judging dependencies.
  9. Whatever code you are using for grabbing keypresses is probably calling `event.preventDefault()`, this stops default actions from occurring for the keypress. There is a pen here that shows it. Note how prevent default works, there are two handlers here but only one prevents default, this is enough to kill other actions from happening (such as cmd/ctrl+r to reload the page and input fields from getting inputs) but both handlers are still triggered. It's not particularly intuitive really, and I've only tested Chrome, probably all browsers behave the same but its the sort of thing that they might handle differently. You can remove the `event.preventDefault` which will get your input field back working, but your game code will also register the presses, so if you typed 'was' into the input field you'll see your character moving around (or whatever) beneath the input, which probably isn't what you want. You probably need to add some sort of switch when an input field gets focus to disable game keys from working, then reinstate the game keys once the input field loses focus.
  10. This is the exact situation that a time-based approach is designed to solve, rather than effectively just speeding up your simulation as the inverse of FPS. FPS just describes the view in to your world, the simulation should usually just chug on completely independent from framework. So, in your situation, if the FPS drops the worker still collects resources at the same rate, you just don't see the unit move as frequently. By differentiating simulation and render speed you vastly simplify a whole load of stuff and don't have to deal with all the pain of a variable time step in your game.
  11. "Fixed" probably isn't what you want, although if its working then don't worry about it. `position: absolute` and some z-indexing is probably better. MDN is probably the best resource for this stuff. The DOM has a 'flow' to it, although certain conditions can break that flow, which is what you want. Starting on the MDN page for position is a good place to start learning about how the DOM positions elements.
  12. There was another thread on this. My approach to this (which does not involve Phaser, but I'll only outline the theory anyway) is to wrap the keyboard event handler to emit events with a timestamp, when each new keypress comes in it adds the new one to a list of keypresses and removes any that are older than X ms, this way each keyboard event emits stuff like: [{ key: 'E', timestamp: 100 }] and [{ key: '<right>' timestamp: 100 }, { key: '<down>' timestamp: 110 }, { key: '<left>' timestamp: 120 }, { key: '<space>' timestamp: 130 }] I then query against that array of recent keypresses, in the case above: 'HADOUKEN' (well, almost!). I use streams to handle this, which makes things very very easy, pretty much just this function https://github.com/mattstyles/raid/blob/master/packages/raid-streams/src/keys.js#L67. To consume this stream I use something like the following https://github.com/mattstyles/raid/blob/55f21cfa613010e830555e37208bb14ccd3bf65c/examples/mount-screen/index.js#L48 which just makes a string compare against all the recent keypresses, rudimentary but plenty good enough (and fast) for many many use-cases.
  13. function mobAttack(1) { //add all the variables and values (attack speed, life, etc.) of the mob 1 here. } function mobAttack(2) { //add all the variables and values (attack speed, life, etc.) of the mob 2 here } This almost looks like function or method overloading, it isn't quite, but JS can't do that anyway!! If you do go down the route of declaring your entities then I'd probably suggest something like: function basicAttack (mob) { // do stuff } function specialAttack (mob) { // do stuff } var mobTypes = [ { name: 'mob1', offset: [75, 248], attack: basicAttack }, { name: 'mob2', offset: [50, 248], attack: basicAttack }, { name: 'mob3', offset: [55, 248], attack: specialAttack } ] This is starting to get a little more advanced at this stage. The `basic` and `special` attacks take a parameter, a `mob`, this is so they are a little separated from things, making it easier to refactor or reuse later. I've then passed a reference to this function to the mobs declared in the `mobTypes` array, notice the lack of '()', this is important. '()' invokes the function, executing it, and returning anything is might return (in our case there are no returns from the function which means it'll returned 'undefined'). By passing a reference to the function we can call it later, its almost like a cheap mixin. function addMob (id) { var mob = mobTypes[id] game.add.image(mob.offset[0], mob.offset[1], mob.name) mob.attack(mob) } It seems slightly odd to pass an instance of itself to a instance method, but, this does actually make the functions more flexible. Feel free to investigate with binding the function to the object so that `mob.attack(mob)` works maybe closer to how you want, pros and cons to each approach. You'd have to be careful though, currently that array of mobs is treated as base data, if you bound functions to the objects in there you might end up mutating objects in that array, which you likely don't want, you probably want a create mob function somewhere that creates a new instance of the mob (from the data in that array), then you have separate instances to work with. You're now getting firmly into the realm of creating objects, possibly classes if thats your thing. As you add functionality you might want to have a little refactor and rename some of the functions, currently showing the mob causes it to be added and attack, when you create the mob you might want to work that out as there is a tight coupling at the moment i.e. you can not reuse the showMob function as it currently also attacks.
  14. I agree, frameworks tend to be fairly inflexible. Frameworks tend to want to own the application and allow small windows in to them for your stuff, this blanket can be time-saving and comforting, but, can also be restrictive. Libraries/modules tend to be the opposite, in that they can be used and composed together to do what you need, although you may have to do more boilerplate and glueing together. It's not a bad ploy, however, games have fairly different primary concerns than your average web site/application. Take React, for example. React wants to re-render views from data on every change, for your average web app changes are fairly infrequent and tend to be as a result of a user interaction or some sort of data loading. Games tend to change extremely frequently, often every tick so re-creating the entire scene is potentially a performance killer. This, of course, isn't a clear divide, I'd just be careful of using games as a way to get in to more general web development as they have problems to overcome that often do not exist in an average application. Having said that, writing games often instills more passion than learning through creating a to-do app or tinder clone, so, I'd probably say, go for it. Start small, create a pong clone, or a 2d scroller, or a top-down game, keep the scope really tight and focus on getting it finished, or, at least, to a state where you've learned plenty of lessons. As you've already made (and sold! thats amazing!) game with GM2, you shouldn't have too many issues pumping out a couple of quick games in vanilla JS, or using a framework like Phaser, or using a library like Pixi. A more complex game is often just an extension of a simpler mechanic. It sounds like you've done a lot of reading/researching, and whilst everyone learns differently, its almost universally true that you'll learn more by doing than by reading, so get stuck in there! Look forward to seeing what you churn out! If you need some inspiration I'd love to play a nice, simple, little top-down procedurally generated RPG not the easiest thing to get going with though!
  15. No, and they likely never will, native apps have a number of key advantages over the web as it currently stands. But this isn't your problem. The question should be: "Can I create {non casual games} using {web technology} on {mobile devices}?" The reason I added web tech in there is because thats what it sounds like you'd prefer to learn. If you currently do not know a language and want to make a game then just use something like GameMaker, I believe there to be plenty of coding involved also. If you just want to get a game out, why not use Swift or Java and target the platform you want? If you're dead-set on web tech then just choose a library or framework and get to work. Just get stuck in. Dive right in there. Sounds like you're over-thinking things, just get in there and get building, JS is great for this as its so permissive. Hybrid JS solutions get more and more powerful, they're still really quite severely hamstrung compared to native experiences, but its getting better all the time. Will it be a good fit for every type of application? Probably not. Will it be a good fit for your project? Well, thats the question. A good developer uses the right tool for the job, it doesn't matter if that tool is old and gnarly or new and hyped, the right tool for the job.