Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


b10b last won the day on April 15

b10b had the most liked content!


About b10b

Contact Methods

  • Twitter

Recent Profile Visitors

8351 profile views
  1. Heads up the Codecanyon (Envato) license at ~$30 USD is usually their "regular" license. There are chances you'll need the "extended" license which will often be ~$100 USD, and customizations on top probably another few hundred or more? Either way a pretty cheap entry point, and you'll get what you pay for. Please be mindful that Envato do not check that what is sold on their stores is owned by the seller, so there is no guarantee that the games you'd "license" are actually legit. MarketJS do things differently and if I understand correctly are providing basic bespoke services (atop cloned
  2. Welcome to HTML5 game development. Here's the elephant in the room ... generic interstitial in-game-ads are worthless. $1 eCPM roughly means "if 1,000 players play my game I might get to share $1 with my publisher 60 days later". Does that sound viable even before we reduce it by factoring in odds of non-payment, cost of collection, ruining the player experience etc? Or, does any story of a positive experience suddenly make it a compelling proposition? My general advice to newcomers is "make games for fun", and develop your own audience while doing so. First make a small game collect
  3. Compute the bytes loaded / bytes total - and show that as a function of time elapsed. Similar to how a large OS update shows its progress. It will be wrong for 99.99% of the time, but tend towards accuracy as it approaches completion! That said - don't fix what isn't broken - lumpy loaders are cooler. If a loader is too smooth some users will assume it's fake and become disgruntled. Plus anticipation of a lump completing is oddly entertaining. Loader psychology is weird and fascinating. Some loader progress designs aren't linear, some include minimum progress updates, etc. Ever not
  4. Sounds cool, let me play! I sometimes play an FPS where botting is prevalent and it sure is f$!strating, but for a "learning purposes" project perhaps being botproof isn't the highest priority? Maybe the design choice is whether to consider each bullet a distinct server authoritative entity, or whether to consider each "blast" (spawning multiple bullets) to be the server authoritative entity. Some degree of trust from the client is likely acceptable, so long as it mostly correlates with others?
  5. In celebration of 2021's "2020 Olympic Summer Games" we developed a collection of simple HTML5 summer sport themed games. Each game is designed to load fast and run on desktop and mobile browsers (keyboard, mouse, touch controllable) usually with single button control. Inspired by 80's favourites such as California Games, International Track & Field, NES Tennis these were all great fun to make: ATHLETICS HERO (aka TRACK & FIELD HERO) https://b10b.com/athleticshero/ Choose your hero and compete in the 100m, Javelin and Triple Jump Track & Field events. Time
  6. You mentioned ticking at 50fps on the server. I'd question whether that frequency is necessary even within a physics sim. It may be that a much lower rate is acceptable, say 15fps - if combined with client side interpolation. For example, round trip time alone may limit actual frequency to closer to 10fps on some clients, visuals are going to need a minimum of 30fps - so interpolation is likely essential anyways? As I don't know the specifics of your game loop it's hard to say, or indeed how much load each thread genuinely needs. Just a gut reaction says that the simulated world shoul
  7. @LoudSilence hey, these are interesting (and specialist) questions - you may do best finding someone who is already hosting similar and asking them directly? For what it's worth these are some things I learned when building similar for a client: Yes, Nginx as a proxy for NodeJS is a win-win Using PM2 to manage multiple NodeJS apps is also a win - and check out the multiple instances mode if going multi-core Weigh up multi-core vs multi-server - within a virtual environment I'd always favor the latter (8 lite servers rather than a single 8-core server gives more redundanc
  8. Pixi aside, I think this task splits into a few questions: Can we use JS to measure "steps" Can we run JS run when the screen is locked / device is in pocket / player is walking Should we do this with pure JS? "1" is certainly "yes", and there is existing code to do this by measuring the rhythm of motionevents over time (http://sebastien.menigot.free.fr/pedometer_explanations.html). "2" is a limited "yes" for a period of time after the screen is locked, by using service worker hacks or audio events. "3" is almost definately "no" - because there are better approaches, an
  9. I like this creative and indirect strategy. Unlike in-game-ads it adds value to the play experience rather than interfering with it - while also creating additional discovery channels. It plays to one of the web's strengths - i.e. it's a good thing to explore outside the walled-garden rather than bounce around within it. Perhaps an extension is to provide standardised tools within games that allow players (or AI) to create such supporting content more easily (or automatically)? Commerically I can imagine multi-level commission systems built on the back of such tools that yield returns
  10. Welcome @codingbutter! As you may know, whether using setTimeout or requestAnimationFrame the delivered framerate will be limited based upon what is attempted to be done between each redraw (because single thread). Hitting the CPU bottleneck was more commonplace a few years ago for HTML5 games, these days less so but it's still relevant to the design question. So a follow-up question might be whether work(ers) can be done off the main thread - and would that help anyway? Another question is whether inputs can (or should) be resolved on update, or whether they should be resolved (potent
  11. Good luck. I think you'd benefit from a clearer message - for who, what, why it's great - and why you are crucial to the plan. I watched your pre-release KS video but found it to be slow and then (unintentionally?) funny. "From 5 prototypes in three months we acquired 100k players" ... we get that a day by comparison (and I still question the sustainability). The stats of importance on instant games are retention and avpu - did your prototypes demonstrate traction on these? If we study the Knock Knock raise in a bit more detail, it's a valid proposition (as proven by $4M-$6M) headed by an
  12. I've also used the method described by @ZackMercury and it worked well enough to sequence events to audio reliably. One extra thing to consider (if setting animation based on audio elapsed time) is that visuals will be tend to appear one frame behind the audio. Because the frame is constructed and delivered after that time, whereas the audio will have continued. This is more obvious within low framerate environments (we were doing it at 20fps, rather than 60fps for example). A simple time offset is usually sufficient. A related issue is to consider "un-lagging" the inputs also (that is to
  13. 300k at 60fps seems viable on desktop with ParticleContainer. Why do all the circles need their own interaction events? You may do better to use a "system" ... color map, distance calculation, tree search etc to determine which circles are "over". And those "circles" would be pretty small to fit them all on screen at once, are they all needed, and is it essential that every interaction occurs every update? Many ways to optimise, just change some of the upfront assumptions.
  14. @Jason908 LOL, I haven't done any DOM Javascript for a long time ... here's one approach for javascript.js: // get a reference to the box and cache the initial style for resetting const box = document.getElementById( 'box' ); const initStyle = box.style.cssText; // what to do when clicked, using the text within the button as identifier function onClick( event ) { switch( event.target.innerHTML ) { case 'Grow': box.style.width = box.style.height = '300px'; break; case 'Blue': box.style.backgroundColor = 'blue'; break; case 'Fade': box.style.opacity = 0.5; break;
  15. Yes you may have a chance. But I'd wager the chance of doubling your investment is less than merely breaking even. Otherwise everyone would do it and inflation would soar to keep up with the irrationality of the outcome (!?). But pragmatically - the chances of scalable-success are increased by understanding precisely who, why, how. It helps to avoid dismissing these as "random" etc, else success will also appear to be random (and therefore near impossible to scale). A good publishing partner will have considerable expertise and experience in this field. Worth rembering that anyone wi
  • Create New...