b10b

Members
  • Content Count

    519
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by b10b

  1. Such warnings may sound reasonable, and the exact licensing terms of CodeCanyon / Envato may even shed more light on the particular situation described *. However Facebook et al don't owe developers an account or access to their systems to publish content. So it doesn't especially matter if an accused-developer is guilty, innocent or somewhere in between - because at volume these cases are cheaper to auto-suspend than to roll out an elaborate warning-strike-review system or manual audit. From my perspective ... so far I've published none of my own-IP titles on FBIG. Yet I have seen some of those titles published on FBIG without my consent?! I filed a DMCA takedown notice to FB and the games were removed. Far from an ideal scenario, and I could argue a more stringent publishing review process is warranted upfront, but the outcome is satisfactory enough to avoid escalation. * caution, just because something is "paid for" at Envato it doesn't mean to say it is legally licensed! For example, I've had one of my games listed there without my consent, it was removed after I filed a DMCA takedown notice however the dozens of purchasers of the "license" were not notified and they continued to use the items thinking they were valid. Hard to get that cat back in the bag / always best to buy direct.
  2. The scope of "coins" is set within the anonymous-function that is being called by the return of the promise. So it will be "undefined" outside of that function. So either setText() directly within the anon-function, or have the anon-function assign a value to a "coins" property that resides outside of that scope. Or don't use anon-functions, but that's a bigger story and probably off topic. Either way not an issue with FBInstant.player.getDataAsync or even Promises, just an issue with understanding scopes within functions.
  3. b10b

    Code protection

    @jar4563 hi, this comes up a fair bit, it's worth searching the forum. There's some simple measures you can do like code obfuscation, however nothing is going to prevent someone with skills from deciphering any client-side code worth stealing. For genuine protection the valuable logic must be on the server-side. So we're often talking client-server model, MMOs, io games and so on. For a beginner my advice is don't sweat it - some creep might steal your code (and / or your art) - so be sure to beat them to market and offer better player experience as you evolve your game faster than they can rip it off.
  4. I don't know you or your case but from my understanding of mass scale inventory systems this assumption is most probable. Hard to not take it personal, but big data working on experiment #922669581182284 didn't add up as expected. Unless you have a direct line to someone within FB HQ who can bypass the automation then you're now in a curious labyrinth that cannot be exited by your actions alone. Consider filing a quick appeal (again don't take the bot-like response personally) then move your efforts to things you can action - like moving to a new platform.
  5. Yeah, this is a quite remarkable clone!
  6. It's not so tricky ... pricing strategies usually require at least two parties interested in the same item. In the simplest of cases the item is your time and the two parties are 1) You, 2) Employer. For a deal to work the Employer will need to offer more than your "self-value" for your time. You then surrender your time in exchange for their money. Repeat, add skills & capabilities, increase self-value, increase cash buffer, increase price ... eventually, as your time begins to expire, your "self-value" will be so high (to you) that you will retire TLDR; If you think it's worth $495, you're right. But you are the Employer (who must pay the costs) until someone else thinks it's worth more.
  7. Interesting concept, almost a throwback to the viral games from the early 2000s / tapping into memes of the moment.
  8. First try ... Double check Chrome is really using WebGL. Spine mesh deformation can be quite intensive for Canvas and could easily account for these FPS variations (if WebGL isn't working).
  9. I'll have a stab at these as I like to snapshot my view on things periodically ... Yes and yes. Pixi has a very decent power to size ratio and solid compatibility (v4.8 may be wisest in 2019?). For a competent developer capable of spinning their own game structure Pixi is ideal for a lightweight browser game. Coming in at less than 5MB total for your IG is wisest. Red tape aside, it's possible but improbable to make money releasing a single game. Primary monetisation choice with FB IG is in-game ads (which are a low value transaction for a developer and an intrusion to the player). In-game purchases have more value but will require significant retention first. Or consider indirect value generation such as consultancy services, brand building, learning for the next game? FB IG is inherently multiplayer (async). Within the SDK are context (group) leaderboards, notifications, packet sharing (challenges). That being said the vast majority of initial plays will be in solo mode, so a compelling single player experience is necessary for retention. Get creative for the crossover! For more advanced multiplayer use a custom backend. Having some separation / abstraction from the Facebook SDK might be wise in case other markets are a better fit for your game? For Multiplayer specifically? Yes there's a TicTacToe example that covers the basics of a client-server model. My advice is play some of the popular titles, understand what the FB IG audience seem to be attracted to and how other developers are leveraging the SDK to create retention and monetisation - warning, some of it can be ugly. Iterative development is going to be crucial, however you'll likely only be promoted once - so use it wisely, and use each territory to run a split test. Or build several games and apply the learning from one to the next etc. If you haven't built dozens of games already, FB IG probably isn't for you yet? Imo there are better platforms that can help evolve game development skills and player retention mechanics. Instead see FB IG as a specific audience with a specific style of game - developing a game precisely for that might work out very well (FB has a HUGE potential audience after all). Imo Messenger games should be about decorating a conversation, in the same way filters decorate a photo. So quick, contextual, personalised, fun, indisposable. That's not necessarily a standard casual game, so changing some assumptions and expectations may be wise. Just my advice, your mileage might vary!
  10. https://webglstats.com/ Mid 2019 we're at 98%. These stats are being compiled mostly from libraries or websites that feature or require WebGL. There is a risk we're counting travellers at the airport. Perhaps the more important question is whether the project in mind significantly benefits (or suffers) from any dependency? Same applies for Unity. Just because it makes most-sense to the herd doesn't mean it makes most-sense to a specific audience or use case (because unification is homologous which can require compromise). Mobile-web is unique because footprint and initial load are critical while interoperability with other web systems can exploit new and emerging audiences in ways that other apps can't always manage. Yes, I might be over-stating the issue to make my point ... which is ... I recommend studying data specific for a desired audience - make tests and evaluate assumptions.
  11. Technology aside, you may find that the user interface design of your 2,000+ Flash games aren't best suited to today's audience and devices? Specifically games from 10+ years ago were likely designed for desktop, mouse controls, small text, small buttons, cursor controls? Today the basic requirements are touch controls, big buttons, one touch play, and other modern streamlined approaches that might not be compatible with desktop game-design choices? So even if you used an auto-magical porting system to technically achieve what you ask (of which there are many), the result might not be worth using? For that reason I'd encourage you to consider cherry picking the best titles from the list and re-imagining them using modern tech (and modern cross platform user interface design). What percentage of your 2,000 flash games account for 80% of the game plays?
  12. @kurhlaa The deterministic principle is that randomness is not present within the system. So if the same inputs to the system occur in the same order, the system's state is accurately replicable. In the case of bullets they would only exist on (each) client, they are spawned locally based upon synchronised player control streams (one of which is the local player), they terminate locally, and they are (theoretically) ~identical in their lifespan across all clients. This is just a simple explanation - to fully trust the deterministic principle can be naive - but it's a start towards understanding that even a highly complex game's data stream need not be any more complex than a simple game's. As mentioned additional data layers should be added (but need not be as frequent) to challenge and evaluate the naivity.
  13. Good, keep abstracting and reducing it down to the minimum delta and interpolate. Without knowing the exact details I do risk giving bad advice ... but ... you may wish to consider sending nothing about the weapon at all, instead send the player's inputs, or better - only the change in player's inputs (which is often a minuscule data stream). Then have each client be deterministic (bullets need only exist here). With some dead reckoning (and periodic corrective packets and occasional jury) it can be almost permanently "wrong" yet feel "right".
  14. One approach would be to share "commands" rather than object positions. Ultimately within a game there are zillions of things going on, whereas each player only makes a "new" decision every second or so - and not every decision affects every other player. Tune into that "need to know" strategy for significant optimisations. Also, games need not always be fair - if it feels "good" that's often a better result than being accurate. Big topic ...
  15. Might LocalStorage work for your goals instead?
  16. @whatisaghostwriter what is the url you are opening? e.g. https://www.facebook.com/embed/instantgames/APP_ID/player?game_url=https%3A%2F%2Flocalhost%3A8080 Are you able to successfully run the game from localhost without the facebook wrapper? Have you correctly enabled https for localhost?
  17. @Rezoner bullseye, great stuff. I'm a real sucker for anything slice or voxel based. I've had a quick look and my immediate question is ... runtime players? Can your renderer be packaged and consumed in projects directly (and skip the export stage completely)? Would it be performant? Or how about renderer as-a-service for skinning?
  18. As an update for anyone else affected, it was confirmed that Endpoint created Leaderboards not showing on the App Dashboard is intentional (for now) and that the "invisible" Leaderboards can be trusted as reliable. Currently there are no plans for new Leaderboard endpoints so, as a patch, we're thinking of extending our admin functions to include a proxy list (for future visibility and pseudo-delete).
  19. These days I've come around to that point of view - zero upfront time investment from a player should be the default expectation for a mass market game ... ... because modern games should basically play themselves, and the player influences the game to make it play better. Ideally such influence should be highly intuitive and avoid any need for text or instructional ui. That said ... quality text still has utility as a secondary or completionist device. Explaining a game in 8 short bullet points or less is always possible, forces the creator to emphasise the essential core, provides SEO or submission content, and defines a framework for more detailed content to follow (e.g. introducing the game's nouns for future strategy guides or YT narration). Will everyone read it, absolutely not. Additionally text is pretty cool (and cheap) for providing background narrative, dialogue and exposition if the game style suits it (like those early 90s Nintendo manuals) - and I still believe players' time investment is a valuable precursor to playing more specialist titles.
  20. b10b

    Soccer Hero

    With the kick off today of the Women's 2019 World Cup in France I'm bumping this post for relevancy. The game features female players (as well as men) and 70 international teams including the competing nations. GOAAAAALLLLLLLLLLLLLLLLLL! Play for free in your browser (no adverts): http://b10b.com/soccerhero SOCCER HERO is available to license (on a non-exclusive basis) from our website (or PM me): http://b10b.com
  21. @Noel thanks, the Facebook page you linked includes the reference to the "create" endpoint (just before "Step 2"): Our use case is we run weekly "seasonal" Leaderboards and found the "reset" endpoint (date based) to be unsuitable for our goals. In particular we want to archive results for historic seasons (not reset them), and we must correctly assign scores to their initiating season (rather than assign them to whichever season may be current at the time of their conclusion). Because the SDK doesn't offer grouping or filtering of meta we instead create a new Leaderboard each week postfixed by the season number, with the game sending the players' scores to the appropriate Leaderboard (based on date). These sequential Leaderboards can of course be created manually using the Dashboard tool, but the intention of using the endpoint is that we may, theoretically, automate this task and avoid potential for human error. All appears to work well, except for the reported issue ... the endpoint created Leaderboards don't show on the Dashboard, whereas manually created ones do. Might "list" or "delete" endpoints be in the works sometime soon?
  22. I remember going through the top hundred games on Facebook Instant Games platform a few years ago (to assess market share for a client). The results were more diverse than I anticipated, with many being proprietary engines. Our takeaway was it really doesn't matter what engine is selected so long as the choice delivers tangibles for the audience (e.g. in the case of HTML5 portals things like low upfront footprint, device compatibility, speed and ease of development / improvements). As for Steam, I would have a hunch the results are yet more diverse with the lion's share being Unity - however there may be no expedient (or free) way to quantify scientifically (does Steam even care)?
  23. If we create new Leaderboards manually using the Dashboard tool they show on the list of the App Dashboard. Whereas if we create new Leaderboards using the Create Endpoint API they do not show on the list of the App Dashboard. https://developers.facebook.com/docs/graph-api/reference/application/leaderboards_create/ The Leaderboards do appear to function as expected, with setScoreAsync and getLeaderboardAsync working as if the Leaderboard had been manually created. We've not exhaustively tested this ... @Noel does this smell fishy to you? Are we getting a false or unintended result? Or should we go ahead and trust those invisible-Endpoint-created-Leaderboards? Sadly there is no Endpoint to list them or delete them, but trying to create them again verifies their existence through Error 3408. Thanks.
  24. You will benefit from having a range of devices (but a diminishing return per device). A lot can be done virtually these days (especially for HTML5 which is increasingly consistent imo) but the "oddities" usually only show up on the physical device. Having the issue "in hand" can make finding the fix faster - and ultimately developer time should be worth more than the cost of a device. That equation comes down to a good business model, and sensible budgets ... Some tips to reduce costs: Encourage members of the team (or friends and family) to get different personal devices. Supplemental devices can be bought from reliable reconditioned suppliers (there are specialists on Ebay). Study the uptake of devices and spend your money on where the market share is or will be (not was) - which is mostly older devices. A high end latest device might seem essential, but resist the temptation - it'll have lower market share than the same flagship from 1 or 2 years ago (which are a LOT cheaper). Having a high-end and a low-end device for Android and iOS is probably a minimum (but one can be a tablet and one a phone). Remember things move forwards, review your collection annually (which means spending an annual budget), and be prepared to cull older devices rather than support them indefinitely. Recycle appropriately. Make LOTS more money from selling your games than you spend on devices! And consider outsourcing all the testing and QA when you achieve a major hit
  25. @trial asked me on PM how we manage to solve this issue on our games. I've replied here so anyone else experiencing the same issue may benefit. Simple answer is to run the resizeCanvas check almost continuously (on update / RAF tick). Compare a concatenation of window.innerWidth and window.innerHeight to the previous state, if it's the same ignore, if it's different then recompute the resize / css scaling and offsets. We make no use of any Events for this, which may seem less than efficient but we found Events to be inconsistent (and the overhead of continuous comparison to be minimal). This analysis was originally done ~2012 so things may have improved since (and other things may have worsened) - but the code from our framework written mostly at that time can be seen here: https://github.com/hypersurge/awe6/blob/master/lib/awe6/core/drivers/createjs/Kernel.hx#L133