So the game starts off fine at first but then it gets a little laggy or choppy at thhe end anyone know how to fix this?
It can depend on the computer you’re using. For example, MatrexBall for me is okay, but PolyBrawl starts of laggy. It’s also fine on chromebooks. Maybe you wanna tinker with the browser settings to make it better at using WebGL. You can also delete unnecessary files, assets, & entities in the hierarchy.
Bro youve said this before literally word from word Its like your a bot or clone or something
To be honest it’s going to be hit or miss with PlayCanvas, or just HTML5 games, on different devices. I think that especially if you want to use it with mobile, many older phones (iPhone 5 for example) just won’t support smooth gameplay for even simple games. If you’re developing a 3D game that you want to run on mobile, I think Unity might be better if there’s many things going on. But if it’s a simple game and there are problems, it’s probably just because the device can’t handle it no matter what you use. Best of luck though 
Might also be because as the game progresses you’re loading more things into the game, so you may need to start thinking about how to reuse or destroy game elements if that’s the case.
thats the thing I’m tocode a ai with playccanvas javascript an ai that can automatically make the run more smooth no matter what device your on
Maybe I am.
uhhhh ok buddy
https://developer.playcanvas.com/en/user-manual/optimization/
Actually, doing the following early stage form of optimizations can easily get your game running decently on the oldest Iphone5 browser and faster than any poorly optimized Unity mobile native game.
Early stages: (easy to do)
Limit/remove dynamic lighting collisions with the “Static” flag for non-moving objects, or even remove the Receive flag for ceertain cases, or resort to baking if possible.
Static batching to attempt combine similar materials into one material for certain meshes…or you could do it with external 3d editor by 3d artist.
If not using Playcanvas 3D physics (AmmoJS), uncheck the physics flag in the PUblish Settings . COnsider using another simpler (non)physics engine (collision detection) instead of AmmoJS. AMmoJS doesnt work too well on mobile when it comes to performance. Simplifying meshes into seperate simpler collision ones (if needed) might help . I always roll in my own custom code for collision detection/raycasting against static environment with all the similar methods/optimizations also available in AmmoJS (eg. Boudning volume hierachy, Dynamic bounding volumes) to keep raycasting/collision lighgning fast, just without the overhead of other AmmoJS’s features (and hefty emscripten download). Standard quake-like collision detection code also makes walking up steps easier/possible unlike AmmoJS approach.
If all objects will be visible on the screen 99% of the time, consider turning off Frustum CUlling feature in the Camera as you wont benefit much from it.
Don’t use excessively large textures and excessively detailed models. Keep to the budget.
Early to mid stages
Dynamic batching if needed if you’d handling multiple dynamic objects of numerous quantities (100 or over), Consider batching. Batch repeater (custom) approach is more scalable as it’ll allow you to repeat and clear off stuff, but it does make managing stuff harder as it involves a lot of custom array (matrix pallette) editings rather than working with entities itself.
Mid to later stages
Look into the texture compression options
Later stages (only if needed)
Frustum culling management of different mesh instances by code (meshIsntances[?].cull= true or false with visible= true) or consider rolling your own custom frustum culling management code to turn off/on objects on your own if needed( meshIsntances[?].cull = true, then visible= false to turn off visibility, OR cull=false,then visible=true to turn on visibility). For individual mesh instances that you know will always remain visible 99% of the time, set cull=false, visible = true.
Then, consider LOD and such if your environment is very large like actual PUBG/Fortnite scale maps (ie. openworld maps) or very detailed (eg. like the Casino one). There are numerous articles online on how the developrs manage LOD for such environments as they parachute into the world at varying distanes. Note that likely such extreme solutions are only needed for super-large open levels or significantly detailed ones, and would typically involve tightly coupling the frustum culling routines (custom project-specific code) with LOD as they are very inter-related.
https://playcanvas.com/project/574049/overview/lodbvhbatched-spawnings (Ok, i admit, this is just basic LOD switching and not as polished as Fortnite’s actual HLOD implementation which includes blending and octahedral impostering)
Selective Inlining of codebases. If certain libraries can be optimized, export out custom builds of those libraries with inlined codebases. (yes, it’s ugly. but only done at the last resort to reduce function calls). Typically not needed 99% of the time…unless you have specific very complex algorithms that need to be optimized per frame, in which case those libraries should have had been inlined already.
4 Likes
Very good read, definitely useful!
And come to think of it, yeah I’d imagine many problems faced on PlayCanvas with respect to smoothness probably exists on Unity. I guess when it comes to the iPhone 5 and early Android phones, there comes a point where supporting them is just unfeasible and difficult no matter what optimizations you make.