b10b

Members
  • Content Count

    557
  • Joined

  • Last visited

  • Days Won

    11

b10b last won the day on October 16

b10b had the most liked content!

4 Followers

About b10b

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    b10bgames

Recent Profile Visitors

6097 profile views
  1. From the NodeJS documentation: That is, setInterval can only "try" to call in the prescribed time. If it's blocked, then the time elapsed will overrun. Game updates can be heavy and so can easily create blocking scenarios, even at 30 FPS. I don't want to provide code because I'm not yet sure I like the use of setInterval for this purpose? I'd instead suggest reading this and properly exploring all the options: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/ Plus getting a good understanding of delta-time (in respect to game updates) will be a valuable foundation: https://en.wikipedia.org/wiki/Delta_timing
  2. What do you want your IAP service to do? Just collect money and issue a token? If so, because we're talking "web games", that's just regular "e-commerce" not "IAP"! There's no vendor walled-garden here. PayPal will work, there's no need to share your revenue with anyone else. Don't like PayPal? How about Google Pay, Stripe, or any of the other dozens of payment processors? If you want your payment platform to also provide an audience, community, achievements etc then try Kongregate or FB IG and share some of your revenue for the value they add. Maybe because they're in the business of high-volume-churn associated with low-value eCPM? Rather than the high-quality, high-retention user-experience needed for successful premium purchases? Different horses for different courses.
  3. Cool, we have some HTML5 games available for license, partnerships or customisations: https://b10b.com
  4. With NodeJS there are several ways to benefit from multiple cores, or other process distribution. My preference is usually "PM2". Then within your application design you will need to engineer how each instance defines and manages its own responsibilities - e.g. which games it is managing, what happens if that instance fails, and so on. https://pm2.keymetrics.io/ You may also wish to reconsider using setInterval as a reliable thresholded tick? An alternative might be to loop faster than desired, measure the cumulative deltaTime within the loop, and if greater than the minimum tick then run the respective game updates (passing the deltaTime forwards), and resetting the cumulative deltaTime. Additional checks for unacceptably slow deltaTimes can trigger other strategies - such as passing responsibilities to other instances, or spinning up more instances etc. Many challenges lay ahead in this topic - enjoy the journey!
  5. b10b

    Which implementation?

    How about using factor-of-two multipliers? Spells can upgrade at their own rate, likely linearly. Staffs multiply the value. An upgraded Staff is x2 the power of the previous Staff. The primary benefit is that getting a new staff is likely the most significant upgrade, and reaches across all the Spells / upgrades in an obvious way (i.e. the Player knows what they want to achieve and what happens when they achieve it). The secondary benefit is that it'll make testing and progression-design easier as there are more discrete "phases" of power. The approach can also be applied to multiple Weapons. For example Staff multiplies Healing spells, Armor multiplies Defence spells, Sword multiplies Attack spells and so on. But probably only do that if the game is leaning towards mid-core rather than casual?
  6. There are some extra workflow benefits of using an atlas. These might be more tangible than modern marginal blitting performance gains? Separates concerns between what is a production asset (e.g. the raw png) and what is a build asset (e.g. a pngquanted atlas png representing a collection of production assets) Reduces file volume, repository overheads and other potentially slow directory-listing-style issues (these can be painful when dealing with thousands, or tens of thousands of frames) Can be faster to export from animation tooling, and easier to manage in code for technical animation (if using name based states and frame counts) Represents a standard of sorts, which can allows animation artists and QA to test animations in other environments or applications independent to a game which may be work-in-progress Reduces runtime network calls which can significantly improve loading performance for players (and therefore retention) Can significantly reduce runtime-memory by using best-fit heuristics (e.g. removing most of the blank spaces around individual frames, or de-duplicating frames) - which can improve runtime performance dramatically if memory is otherwise exhausted These can add up to sizeable development and runtime performance gains. Drawback is that there's an extra step in the workflow, and potentially another license dependency / fee. There are some capable free tool options, and the commercial tools are usually worth their price. For our games we don't atlas "everything", and there's plenty of reasons why balance and case-by-case decision is important. But we do favour atlases for animation collections.
  7. Free might seem best to some, but I wouldn't presume any unfair intent? Ultimately the portals are in the same boat as the gamedevs: limited revenue from a diminishing eCPM. They have the slight advantage in that they aren't producing the games so have more options from where they source them. But if their imagination for sourcing only extends to syndication services containing "free" revenue-split-in-game-ad-based-games then it's fair to assume that the Player experience will be unremarkable on that portal. Instead look to publishers with more imaginative revenue streams and player experience goals ... or adopt that commercial role for yourself.
  8. A couple hundred bucks a month? For sure. That revenue represents a couple hundred thousand plays (which is quite viable with a small collection of quality games). Yes, we achieve that, and more. Worth it? Not so sure. In 2019 ~$1 eCPM seems to be the web-game normal these days (and trending downwards?) which likely demonstrates that in-game ads are becoming worthless to an advertiser. It's important to take a moment and pause ... perhaps even say this aloud to let the reality hit ... "I've created and shipped a game that has been played one thousand times. I have earned $1. With luck on my side I will collect that $1 within the next ninety days.". Cool!? Also let's follow the money and consider the other side of the coin. From an advertiser's perspective $1 eCPM isn't a bargain, it's probably junk - possibly needing millions of impressions to create a meaningful engagement (i.e a sale). The only consistent winner is the broker, they can trade low eCPM and make their rake at volume. Fortunately advertisers are quickly wise to weak inventory and can move their placements to new supply very quickly (often automatically). Unfortunately games cannot attract new demand so fast (the proposition is narrower), so end up outbidding one another over a tiny pool of all online advertising channels (again often automatically).
  9. @espace Your code returns the correct "1" for me (Chrome v77 desktop). Perhaps this is implemented inconsistently across engines? If so try filtering the array and removing the nulls before the Math.min: var min=Math.min(...arr.filter(v=>v!=null)) A more optimal solution might be needed if your array is large?
  10. Suggestion: include an exe in the github releases. I understand you feel strongly about the subject and thank you for a free tool. Similarly I think TexturePacker serves a particular audience well, and it's perfectly ok to expect compensation / payment when value is delivered.
  11. Without detail I can't offer anything but generic suggestions. FB "banning" stuff is usually because of a breach of rules, or similar claims. Yes it'll feel unfair ... but there is no entitlement to profiteer from FB's audience. How is your quiz "Viral" if it has very low players? Dwindling audience is always due to a "viral coefficient" of less than 1 - rise to that challenge and FB is a great place to be (use shareAsync() to provide relevant and fun messaging, and bots to re-engage smartly). Also remember - new privacy constraints are imposed regularly, and competition mounts daily - so legacy successes always had an easier ride to market share.
  12. Yes, you're right - I'd forgotten about that (recent) extra "requirement"! Thanks for your compliment and good luck to you, whichever platform you end up on.
  13. @128p yes opt-in for iOS seems like a reasonable option, especially initially. I'd imagine from FB's perspective they'd prefer to present their blue app as a consistent platform / experience that transcends device? E.g. it'd be a bit odd if some features were available everywhere except when the user picks up their iPhone? Plus politics ... Apple sure like their rake, so given the lack of opt-out this is an unsurprising (if frustrating) requirement. Questions to consider are ... how are you imagining monetizing your game, and how does FB help you do that in ways that can't be achieved by going to individual platforms directly? The $100 gift to Apple probably shouldn't be the barrier.
  14. That's cool, the benefits of having typed resource addresses include avoiding typos and ensuring required assets exist. In Haxe we do similar with a Macro that directly reads the assets folder (so there's no need for additional tooling or generating a static list). I do miss those macros when working with other languages so its great to see alternative approaches.