b10b

Members
  • Content count

    255
  • Joined

  • Last visited

1 Follower

About b10b

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    b10bgames

Profile Information

  • Gender

Recent Profile Visitors

1,806 profile views
  1. Scared of Typescript

    Build commands ... I suggest using Webpack with TS and have it running in "watch" mode, so as a file is saved it'll auto recompile. That way the TS compiler aspect is effectively hidden from the hands-on workflow. Result is: 1) write code, 2) save it, 3) view the HTML5/JS in browser, 4) repeat.
  2. Use arrow functions?
  3. Good job on the beta and I enjoyed your 16-bit nostalgia, hidden features and retro aesthetic. Some feedback you may wish to consider: 1) controls didn't work on mobile (when I tested last week), 2) the tight scrolling view is unhelpful when playing a Pac clone, 3) trademarks. Good luck!
  4. Which Typescript IDE

    Yes, I'm a daily TS user and would say since TS2 that VS Code has become my go-to IDE (small, mostly quick, does the job out-of-the-box and is linked to the release cycle of TS). I used Atom prior and it had some nice workarounds for the limitations of TS1 tsconfig, but I found it increasingly unresponsive dependent upon the size of project, and the workarounds were no longer of benefit (to me). Both of these IDEs use a webview, which may be the cause of the graphical performance issues I encountered - notching them into fullscreen modes can improve things.
  5. JavaScript Framework's

    I understand the appeal of a hidden army, and I agree for trivial issues or initial learning curve this is valuable beyond words. However I've repeatedly encountered long-term frustration with any external dependency (no matter how large or stable today) because we're betting our future on other people's agendas - and the two will diverge over time. Whereas self reliance and the ability to fix / invent / adapt is the key to being original (more of a cultural thing than a purely technical thing) plus it provides resilience through diversification opportunities. Perhaps picking a framework that can easily make what exists today paints us into a corner to make more of the same? Or perhaps it's obviously the best choice for today?
  6. JavaScript Framework's

    I wanted to provide an alternative perspective on picking frameworks: actively avoid those with large adoption, high issue counts, frequent updates, easily read documentation, etc . Intentionally buck the trend. Why? Because the opportunity to stand-out rarely exists if we follow the herd - and in the crazy game of games standing out is crucial to survival. Instead abstract the selection criteria a little, spot the trend of the trend, take a chance and pick an obscure and non-obvious solution - prior to "crossing the chasm". Rely on three arbitrary yet tangible review questions to derisk: 1) can we get something deployed using this tool within a few hours, 2) has someone else produced something noteworthy using this tool, 3) does this tool reflect our personal style, preferences and goals.
  7. Unsure about Phaser specifically, but a general solution is to use a color map. E.g. the same orchestra bitmap would have a secondary bitmap with each instrument block colored with a unique color index (gaps between instruments would be blank). Then, based on pointer click, the color map is pixel sampled at the click position, and the resulting color key used to reference a list of instruments. Simple by design - but if using this approach be aware that different browsers can interpret color information slightly differently, so "closest value" is often better than "exact value". An alternative, simple-geometry method is to have predefined center points for each instrument, and then find "which is closest" to the pointer click using sorted Pythagoras. The result is a field of overlapping circles that often works surprisingly well for bulky objects.
  8. @scheffgames my friend, one day you're going to be huge! So don't muddle your brand "Exonplay" with the global might of "Exxon". Rebrand now - because it is day 1 and costs nothing to do so. Tomorrow will cost more ...
  9. AirConsole Latency - worth a read: https://docs.google.com/presentation/d/1t40cmrv7NT45rRwsJUXqZC2uOmZBS0Cbs9jG1J_Jdzc/edit#slide=id.gd83ddb292_1_76 AirConsole has some degrading network tiers built in, so if WebRTC isn't available it'll fall back to WebSockets, and then down to long polling / HTTP. On paper it looks very good. However in practise a Node + socketio (or variation) may work just as well (in many scenarios) and keep 100% of the control (and issues) in your own domain? But, technicals aside, the challenge with secondary-device-as-controller approach is two fold. First a decent arcade style game can't afford even a 50ms delay in controller input to visual feedback, let alone 300ms. Second a touch device is a poor joypad - much worse than a keyboard or actual joypad - so where's the use case? Such challenges suggest new game genres are a better fit - for example turn based games where the controller shows information not available on the main screen.
  10. a community mega game

    I'm usually skeptical Without massive persuasion the chance of content providers adopting a new walled-garden platform is near zero. Questions include: What is the incentive to early adopters? Does anyone in the founding team have prior success at such platforms? Has the market cried out for such a platform? What alternatives currently exist - and what stops such competitors from delivering this new solution faster than a newcomer? Basically the list of risks (at first glance) is bigger than the list of opportunities. So perhaps consider taking the enthusiasm and new ideas into an existing project that fulfills some or most of the goals - contributing to that with an existing team in place may achieve more?
  11. Good luck / make it work! Small daily revenue targets might sound like a more realistic goal than higher daily revenues - however future-income ambitions must properly account for the initial development time / cash-flow gap either way. For example if it takes a gamedev 4 months to develop a handful of games that go on to generate either $100 or $100,000 a day the cost of those 4 months still needs to be covered upfront irrespective. Or, in other words, there is no benefit in just aiming low. Looking forward to reading your next article on CodeCanyon (and other related-diversification!) because you will identify ways to leverage your skills and assets across multiple markets - effectively diluting your upfront cost.
  12. @eazylow double check link ... underlying link goes to snake. Soccer - fun concept, how can it be expanded to include AI, obstacles, powerups?
  13. Using Phaser with Haxe

    @Antriel and @Blank101 I just wanted to say thanks for producing and maintaining externs for others to use - a rather tedious and thankless task, so *thanks*!
  14. @Alectora Firebase looks pretty solid to me, although I'd say they aren't really targeting games devs?. I used it once as a quick way of hosting a project on third-party https, and I also briefly researched it for a client's web app requirements. The APIs are what they are - if that's all a project needs then fine, but chances are a game or advanced application will quickly evolve to needing more than a simple record base (i.e. bespoke server-side logic) and that may be where Firebase becomes more limited.