• Content Count

  • Joined

  • Last visited

  • Days Won


b10b last won the day on July 24

b10b had the most liked content!


About b10b

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

7213 profile views
  1. JS client connects to the server, usually sending some parameters, the server issues a response based on those parameters (and sometimes an ongoing state). That response is not normally code to be executed by the client, but more normally a data response (like any other typical function). That data modifies client state, influencing view, user input, and subsequent method calls (either local or remote). It's not a magical protection solution on its own because the data returned from a remote function still lands at the client and can be manipulated there. Server-authoritative is achieved if the primary state is maintained on the server and the client becomes a secondary state - perhaps just reflecting the view and listening to inputs. I'm at risk of trivialising what can often be a fascinating system-design challenge ... most web apps will use remote methods, whereas it's less common in web games.
  2. Understandable, Haxe (a language and transcompiler) is multi-purpose so may appear overkill for a simple browser project (which Haxe also does extremely well). But - back to original question about protecting source - consider that Haxe compiles and bundles JS into a single file by default, no bundler needed, and then with a simple compiler command can uglify it (using Closure lib or the Uglify node lib). Plus all "source" is protected to a degree because the original is never published, so the competitive advantage of fast evolution is kept offline. Furthermore, if you really want to show off, because of the inherent transcompiling / isomorphic nature, chunks of the game logic can be remoted and become server authoritative, thereby *genuinely protecting* the secret-sauce. Before I get flamed for my fanboy post, I will add much of this can be done with modern JS ... just with more dependencies and update pita imo.
  3. lol some might say welcome to npm, others might say look at yarn. Anyways ... this is a recurring theme of the often crazy world of Javascript development ... a seemingly endless rabbit warren of fixes to fix other fixes ... I prefer to use Haxe instead.
  4. I understand a reluctance towards dependencies, but Node probably isn't the enemy on that front. Consider the amount of tooling it brings for a single install, and most of that tooling is powered by or leverages Javascript (so less need for "batch" scripts etc). It's probably one of the strongest and versatile dependencies to embrace (as a Javascript developer). Closure is also cool, and can play nicely with Node - there are Node packages to manage its install and interface with it - some packages require it as a dependency to do what they set out to do.
  5. I guess you're not using a "bundler" already? Worth looking into that first, e.g. Webpack? Then adding a plugin to obfuscate or "uglify" is easy enough. I don't use this stuff much anymore so I'll just drop some links: https://webpack.js.org/ https://webpack.js.org/plugins/uglifyjs-webpack-plugin/
  6. You asked this last year? Again my recommendation would be to search the forums for "obfuscation", there are some good replies from multiple people with links to tools and techniques. If you really need to protect your IP you'll need to think differently to slapping on some obfuscation at the end. Or ... if someone steals your game maybe consider it a compliment? I'm complimented daily, especially on Facebook.
  7. A hacky approach could be to use a bitmap font, with each character pre-rotated -90 degrees. Construct the text as normal (using BitmapText) then rotate that +90 degrees. ?
  8. Thanks for reply. Curious ... find() works well for me - I add the audio files to the loader queue (as with any other asset file, no special treatment). Then use PIXI.sound.find() to retrieve them (which plays them from the preloaded asset as expected). I'm loading the libraries as self contained js in the html (rather than using imports) so perhaps this reveals an issue in the loader middleware / initialisation for your scenario?
  9. There's risk of overcomplicating things. Just use "find" instead of "from" in your original code. https://pixijs.io/pixi-sound/docs/PIXI.sound.html#find
  10. Perhaps the "end" of Flash will be similar to the "end" of Silverlight or Shockwave? For example, we can still install the last plugins / players if desired, they may not work especially well, or provide much modern-day utility, but for the committed die-hard it's never the "end". And there's always offline / exe / app wrapping for content providers to continue to share their content independent of browsers. Perhaps, if consumer demand warrants it, then a simpler, "HTML5 way", of playing SWF content in modern browsers may emerge (although likely won't solve many inherent usability problems). Perhaps, it'll really be the End, and nobody will mention Flash again, they will never seek to run a SWF or view a massive part of internet legacy. Blip, gone, erased. But however it plays out in 2020 and beyond the time to place commercial bets on such things was 10 years ago ... anyone with content that is predominantly SWF today has been napping.
  11. @apocalexxnow quick (untested) suggestion ... try "find": const sound2 = pixiSound.default.Sound.find('explosionSound');
  12. I'd agree with this analysis. Perhaps the thing to do, before dismissing entirely, is discuss further with your potential partner about their long term plans for your property. If their answer is default, then your decision can be default. Yes, it's good to be realistic. HTML5 is a great platform to get new players to play a game (onboarding is mostly free, easy, instant, ubiquitous). But it's not a great platform to monetise directly - e.g. in-game ads are unlikely to break-even on months-of-work until years later? So a long-dev game needs to know ahead of time where their audience is and why, and how, that audience will pay for their game. If the game scope is sufficiently impressive, it may be worth splitting it into two ... a cut-down version for casual release on as many platforms as possible - intended to get eyeballs on the game rather than monetize directly - and then a premium release via a store that includes the full content for those that enjoyed the teaser.
  13. What does the non-exclusive deal look like in comparison? Probably similar, but with "40/60" or less? Does two partners at 25/75 equate to one partner at 50/50? What does 100% look like, where is the break-even point, what are the risks? Etc. Games or not, a solid exclusive licensing deal typically includes a minimum royalty per period, a basic advance, and / or a comprehensive go-to-market plan (that the IP owner should approve). Anything less is to leave the IP owner's royalties entirely to chance ... with no recourse if "life time exclusivity" has been assigned. In a nutshell, unless you fully trust your publisher, it's very unlikely to be worth assigning exclusivity just for a claimed increase in share - instead ask about the "special treatment" for this and future titles - focus on relationship building. Or casually throw this one to chance and focus on building the next game
  14. Sounds like a fun brawling sim ... I've PM'd to find out more.
  15. I'd suggest doing it offline, run the audio files through a specialist tool that extracts the syllable data into a cue sheet - for example: https://github.com/DanielSWolf/rhubarb-lip-sync Then process that sheet as your audio plays, synchronising the audio / visual as necessary. Main benefits: 1) a higher level of audio analysis (using other people's expertise) including phonetics, 2) not bogging down the browser at runtime with what is a constant analysis. Or, if you're looking to do things dynamically, then a rudimentary peak analysis might suffice for syllables (e.g. quantise the amplitude to 100ms and assume a syllable if the value changes by +75%)?