b10b

Members
  • Content count

    247
  • Joined

  • Last visited

About b10b

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    b10bgames

Profile Information

  • Gender

Recent Profile Visitors

1,462 profile views
  1. @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 ...
  2. 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.
  3. 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?
  4. 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.
  5. @eazylow double check link ... underlying link goes to snake. Soccer - fun concept, how can it be expanded to include AI, obstacles, powerups?
  6. @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*!
  7. @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.
  8. We've rarely found such features to be used by more than a few percent of players (calculated as % of usage of social features from total plays). Our sample groups have been quite large and diverse over the years, across multiple platforms and demographics - so niche groups may respond better? That's not to say it isn't worthwhile to properly design such features into a game, nor to dismiss those few percent of players who use them - because these same players are likely to be the game's most committed and influential users. Optional, non-obtrusive, with in-game rewards unlocked for usage is probably a decent strategy?
  9. Great success story and first hand account on how to leverage HTML5's market reach back to platforms that monetize. Congratulations to FRVR - even if I can't condone pesky programmatic ads
  10. Google "javascript obfuscator online" for several free and easy options. Such techniques can bloat your JavaScript and are easily prettified back again, so not sure if it's a worthwhile strategy? Secret-sauce is probably best kept server-side.
  11. Tough one. Some options are: Support every device by setting the bar so low it touches the ground Support only a finite list of devices and test thoroughly (each device must be owned - use judgement on what is significant market share and what is obsolete) Make games with automatically degradable features or asset sets (intelligently determined based on device capabilities) Endeavour to support Publishers' lists of devices by a blend of 1,2,3 and a helpful dose of their QA feedback Also ask your customer what "support" means to them? Perhaps a simple message to the user that their device is not capable is sufficient?
  12. Likewise, interested in the response to these GPU accelerated headless advances (but for slightly different reasons).
  13. What @mattstyles says. If you want to borrow any code here's a quick and crude version that does similar to what you want: http://b10b.com/mockup?0-http://b10b.com/poppopcandies It's using an IFrame for convenience, which is not ideal for performance on mobile. So I use a server-side useragent check as well - if "mobile" then skip the surround page and go directly to the game. You may not need that if wrapping the Canvas directly?
  14. @True Valhalla, wow you've been busy with retrospective editing of your posts! It is appropriate to wish to correct your originally bullish remarks, but less appropriate to use such corrections to call others names or to promote profiteering click-bait? Suggestion: mark future edits with the word "edit", "addition" or "clarification". For the record I do not think it is appropriate for this forum (which attracts a larger number of newcomer developers) to promote false promises targeted specifically at them.