• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by b10b

  1. To nod at what you already discovered ... a Context is a mysterious thing (likely subject to ever changing compliances around personal settings, permissions, territories, and privacy?). The Promises returned by FB IG SDK are another layer of mystery, often yielding more false-positives and false-negatives than true anythings. One solution is to check the contents of the response, avoiding expectations as to what it may be (or pondering why it isn't). And be prepared for it to change.
  2. You might be able to narrow it down if you first decide on a canvas rendering library? Else I imagine the problem with finding a gui lib for "raw" canvas is that it still needs some kind of basis to manage assets, interactions, basic scene graph etc - therefore soon becomes a rendering library with opinions of its own? Whereas the non-opinionated gui exists by default - conventional html and css. Both CreateJS and PixiJS have mature third party gui / component libraries. Also, do properly consider the html route - I've seen many game guis realised with React as a layer over the canvas, it can be a good separation of concerns.
  3. There are many other more critical criteria before approval, some of which might feel obscure. But yes, >3MB is not a specific issue. 10MB is probably a sensible cut off for developed nation audiences? Whereas for "Instant Games Lite" you'd need to aim for <1MB. That's a technical challenge and will likely need to adopt some postloader techniques like @plicatibu mentions. https://developers.facebook.com/docs/games/instant-games/guides/lightweight You should evaluate as to whether the "Lite" pros outweigh the cons for your particular game design and intended audience.
  4. Not so long ago games needed to fit on a floppy disk ...so 3MB is a luxury imo To keep things small consider these easy wins. Javascript minification and dead-code removal. Lower bitrates for audio (combined with shorter duration and more imaginative looping). Pngquanting (8bit) bitmaps whenever possible. Keep every asset pristine, making every byte count. Example: https://b10b.com/grandprixhero/ (2.9MB total) And 3MB is by no means a hard-edged requirement, it's a recommendation based on FB's observations of their audience. If you can achieve it then the game may get more exposure and higher retention, but heavier games can still be viable too. What's most important for FB IG is virality and social connection.
  5. Yes, this is the better route imo (any remote data can be spoofed too, it is only remote validation that ~can't). I would serialise the "days" that have been redeemed against the prizes that were redeemed. A quick review of the data could reveal any inconsistencies and a punishment / reset can be issued if detected. All this being said ... if the player chooses to muck around with their clock to boost their game stats ... maybe let them and post their "hack" on YouTube ... enjoy the referrals and return to designing compelling game mechanics that reward play / skill!
  6. Ok?!? I understand this is a perfect example of why the OP is uncertain whether making a complex game in HTML5 is even possible. "Space Jumper" may be complex to @geralsoft and there's no shame in that, but by modern standards this is not a complex game. This is a gamejam scope game - a week or less by a single pro dev? It is not representative of the multi-team feature-rich examples provided by the OP or of the upper-tier potential that web games can deliver in 2020.
  7. Unity exports to a WebAssembly and WebGL output, no "plugin" needed. But that's not to say it's ideal for web, especially not mobile web (search up Unity "Tiny" instead) Possible yes ... but consider this first ... Motion Twins' "Dead Cells" is authored with Heaps, a Haxe based game framework (which has Javascript WebGL output options). Also Motion Twins' catalog before this title was predominantly web games so they clearly have web capabilities. Therefore ... it's reasonable to conclude there's no all-blocking "technical" reason why there isn't a browser version, but there are likely many commercial or user-experience reasons why such a game isn't being published on web (yet). Same issues would likely apply / hinder any other similarly scoped game intended for web, irrespective of authoring tools? Conclusion, as always, is ** understand the audience ** ... on what platform do they want their game (big, complex, small, tiny) to be on. Or ... make web games that absolutely require, embrace and leverage the "web".
  8. I don't recommend anyone set out to make money from games. Instead I propose generating something else of value from games, e.g. insights, influence, expression, loyalty. Money will be attracted to anything exceptional. @plicatibu Your post is a good description of those indie-web-game-niche-monetization-possible-paths and you've methodically and enthusiastically listed lots of detail. Thank you for your contributions.
  9. That was true many years ago, but not any longer. Standart HTML5 output from Unity is effectively a WebAssembly blob that runs in all modern browsers, and it's possible to hook it into other Javascript (in or out) quickly enough. It has it's advantages and drawbacks. The new tooling, aka Tiny, is using ECS approaches to modularise things to an atomic level - and is very smart if you are impressed by such things. But the takeaway is there's really no current reason to think that the output from Unity can't be as efficient (or more so) as something like Phaser given some of the techniques it now employs. It's just that most developers aren't especially efficient in using the tools available As for the other points I think there's big risk in explaining "all the ways to make money" because most will result in high hopes, reality crunch, and loss. Why? Because it's easier than ever to make a game, so it's harder than ever to make a dollar from that game. Instead move creative thinking to value generation: find a problem, fix it, get paid, repeat.
  10. If you are asking this question then you are probably planning to make a game first, then hope to find an audience / monetisation second. If so use whatever tool you like - it really won't make much difference to the financial outcome but will make a huge difference to your enjoyment and productivity in the meanwhile. Be mindful that Unity is proprietary, it is offered as a service, there is no entitlement to it. Therefore Godot might be worth a direct comparison for similar tooling.
  11. Also I'd recommend any game intended for FB IG is specially designed for that particular audience and that particular SDK - i.e. play to the strengths of the platform, or don't play at all. So think about social competition, social messaging, social calls to action, bot interactions, tradeables - make all design decisions inherently multiplayer, asynchronous and viral - think of the game as an unfolding "conversation" (or tic tac toe on roids). Such a design is likely not going to work off-platform because there is no (easy) social graph to bind such a "conversation" together. Better yet is to find multiple platforms where the same social paradigms apply, then spread the risk (as being entirely reliant on any single proprietary platform isn't smart business). Therefore some abstraction in the implementation is wisest and can, theoretically, achieve the goal of spreading the game around the "internet".
  12. I still regularly find answers to issues I face today based on answers posted here years ago. Not sure I can say the same for Discord? Despite the recent drop-off I doubt this forum will close soon - the Pixi subforum remains superbly supported and the rest of the site is still good PR for Photonstorm and valuable for HTML5 game devs finding historic answers. I understand why BabylonJS benefitted longer-term by moving, but by equal analysis Phaser moving was probably less beneficial (given their audience and game-centric goals)? Let's all remember to make this forum what we want it to be - post design and tech questions, releases, post-mortems, searches for talent, offers of services - be original, bold and provoke great responses!
  13. b10b

    Font usage

    You may be interested in a permissive alternative that is extremely close in its implementation to the 1957 Helvetica: https://www.fontsquirrel.com/fonts/tex-gyre-heros
  14. Laggy and unplayable for me. I played via the GD link (Chrome desktop), took a long time to load (stalled at 50% for a while) then framerate was about 3 fps. Audio stutters, total jammer, unable to play. I run an ad blocker (like many people) and I see a bunch of "Failed to load resource" in the console. I re-ran with ad blocker disabled ... urrgh, NOT ONE BUT TWO full length ads that were irrelevant to me (wasted 2 minutes of my life and made you ZERO money). Please never front load a game with an advert, it's disrespectful to players - especially so when asking for feedback. Anyway, no change - same stuttering and jarring issues. More private testing needed.
  15. Nicely made, but I found it frustrating to play - many levels felt impossible, and those that weren't seemed to favour luck over skill? Sorry for the negative review - perhaps some level redesign can add more fun and salvage what is an otherwise well put-together game? Good luck.
  16. Right, the option to "Edit" is not available on posts beyond a certain age (3 months?). I'd conclude that's an admin choice?
  17. Testing edit (works ok for me). Is it just older posts?
  18. b10b

    Pop-Pop Jingle

    Mildly apologetic thread bump. Happy holidays
  19. Do: VAS (aka Value Added Services). Don't: in-game-ads (aka dyscalculia).
  20. Yes, told you it was going to be fun This is getting a bit out of my comfort zone ... our approach was using Nginx as the load balancer (with sticky sessions). PM2 approach works fine with this - with each NodeJS application instance running the service on a sequential port and sharing data between them with either a DB or Redis. The Nginx maps inbound requests to each server via internal-IP, and each instance via the port. So let's say 2 servers x 4 core = 8 instances with 8 ports. New user comes to IP:80, Nginx routes them to one of those 8, and remembers which one (so that Websockets can persist). Nginx configuration determines whether inbounds are round-robined or more elaborately determined - it's doing all the smart stuff automagically. It's certainly been solved before, so it's a matter of implementation rather than invention.
  21. 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
  22. 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.
  23. Cool, we have some HTML5 games available for license, partnerships or customisations: https://b10b.com
  24. 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!