mattstyles

This is a really tricky question for a generic answer as there are so many variables which _could_ dictate whether your project structure works well or not so well. Personally, I'd take any answers with a pinch of salt i.e. there is no single 'best' structure, like, not at all. Have a think about what the problems you are trying to solve are and how the processes and concepts you employ for organisation are going to solve that problem? To the above question, the answer is usually 'I do not know'. This is fine. With the above in mind it is usually better to follow this sort of process: Start the project. Put stuff anywhere, it does not matter at this stage. Get something working. Keep going. Now you have a working product and you can start to identify what organisational problems you have and think about how to solve them. Until this point you are largely guessing. If you have created several similar projects before your guesses are probably good, if not, then they might not be. It is relatively easy to apply some structure and organisation to a project that doesn't really have one, it can be pretty tricky to change organisational structure (can be, depends on many things again, you certainly should not be afraid to change later on if your current system turns out to be not very efficient). There are some rules of thumb that might help you though: Small files and folders are easier to manage than larger ones i.e. small in scope, not necessarily small in lines of code. Decouple things as much as possible, this makes them easier to work with, and makes organisation easier to change. Tight coupling is a nightmare, avoid at all costs. Uber objects (and, similarly, uber-projects) are hard to manage, this is really the above concern worded differently. Divide and conquer. UI and logic (rendering and smarts) are good things to separate. Avoid logic duplication, if you end up writing similar logic in multiple places, consider generalising and abstracting it. Utility functions can form a huge part of your codebase and is _usually_ a sign of good organisation. MVC is fine for games. As are other methodologies. Go with what you think makes most sense for you (and your team) and the project.

Not a stupid question! This is the web and JS so there are, of course, multiple ways of skinning this cat. https://codepen.io/personalurban/pen/dBQQaK here is one way I knocked up. Its a canvas element on the page, with the spinner element also in the DOM. The order of the DOM dictates rendering order, but you could apply z-index via CSS if your DOM structure was different. The CSS is copy-pasted from https://projects.lukehaas.me/css-loaders/ after a brief google search for CSS spinners, there must be several thousand of these such sites. I've used a couple of set timeouts, down the bottom of the JS file, to control the loading spinner. After a set amount of time I've applied a class to fade it out, then, using a different timeout I've removed it from the DOM. You don't need the fade if you don't want it. You could also use element handlers to get an event when the fade has finished, but, they're unreliable cross-browser and it's easier to just know the length of the transition and use a timeout to deal with the next action you want (in this case, remove the element). Hope that helps.

Have a look at Pixi, it just helps manage drawing to the canvas really quickly. Usage inside React is non-trivial, but there is plenty of help out there. You might find Inler's React-Pixi module helpful, it doesn't officially support v5 of Pixi yet but I've been using it (so far) without issue. You have choices here, try searching npm/github for react-pixi and you'll come across a few implementations. If you really like getting your hands dirty there are a few projects like regl that are fun. Probably not quite what you're after though. You could just go the route of having an uncontrolled React component with the canvas renderer inside, again, try searching if you need help working this out. It's been done and written about a number of times for a few different front-end rendering libraries and with a few different canvas rendering libs. There are options other than Pixi too, try searching for canvas rendering libs. It's fun to play with the canvas API but it's quicker to let someone else create a wrapper around it, i.e. Pixi etc.

Hey @bluewales, welcome to the forums! Demo looks great! Sounds like an awful lot of triangles for that small area, but, very nice looking and was a solid 60fps on my machine (which has a terrible GPU). You've done absolutely the right thing, by reducing your use-case to a POC of the bit you want to test. Yes, trying with some different library choices _can_ sometimes be a good plan, but, it can also be time consuming. Three.js is incredibly well supported and used, try looking for demos or experiments that also are close to your requirements. If you find a couple of demos that are similar to what you want to do and work well, then you have to look at how you can optimise to achieve the same performance. Think of it this way: if you have just picked up Three.js, it is a complex library, you can't expect to know exactly how to use it right off the bat. Now you want to test babylon.js, and you don't know that intimately either, so, POC's are tricky when testing performance, have a look also at some reduced use-cases. For any of these renderers there will be frustrum culling and raw number of triangles demos/tests that you can use to get a gauge on whether things are even possible. An example of an optimisation: You may not need the curved corner geometry for anything other than pretty visuals, you can round/curve corners via a shader and have square corners, if you find that the number of triangles is prohibitive with curved corners then cheat. The browser has one advantage over other platforms, debugging is incredibly easy with the browser and JS. Use the tools, find where any bottlenecks are, this will help you identify if there is an underlying issue or just a library/tech choice one. Bare in mind that the browser has the same access to the GPU as any other application (albeit with a slightly older language spec) so any bottleneck may very well be JS, which is _usually_ slower than other languages that you might use (outside of the browser, you have no choice in the browser).

I try to adapt to the size of the screen, rather than pick arbitrary screen dimensions to lock at.

Start googling. There are so many resources for beginners out there for free, you'll have more problems wading through poor content than you will finding what you want when you're starting out. Beyond that, there are also many paid resources. Things like Udemy, Pluralsight, Egghead.io, all offer paid courses, both written and video content. Then there are things like Treehouse that offer dedicated courses. Further still, there are bite-sized learning opportunities like Codecademy, Code Wars, Codingame, etc etc that let you learn in smaller chunks, these are great supplements to more dedicated learning, and range from free to a small fee. To start though, I'd get googling. Use Stack Overflow to help find answers to specific things, and start to identify some thought leaders in the community you like and find their blogs and twitter feeds. I do not know who these people are for Python, but there will be many of excellent gals and guys out there talking about Python and programming. If you like roguelike gaming then there is a nice Python tutorial at https://www.reddit.com/r/roguelikedev/. Python is well used and very well liked amongst Roguelike devs. Creating a full blown game of the complexity of your average roguelike is a fairly daunting place to start, but, maybe if you like that sort of thing then it'll keep your attention and I'm sure you'd learn a lot.

I still don't understand. Correct, this is made possible by browsers and hardware manufacturers. Not Unity. Unity is just one method of creating content for that platform and it is far from the most popular way of creating content. Maybe it'll 'take over' in the future, I doubt it, but maybe it will, but you can't say that right now. Unity is incredibly inefficient and clunky on the web, still. It provides tooling that, for some people, lets them create content faster. Think of it this way, a Fiat 500 is going to be built a lot faster than a Ferrari is, and, it'll get you to the shops and to work and back without any issue at all, but, most of us would 'prefer' to go on a fun drive in the Ferrari.

How so? Nothing in saying that webgl is almost universally supported implies that Unity is the platform for creating web games. There is a saying, never bet against JS.

Why are you worried about webGL on phones? All modern phones (and not-so-modern) support webGL. I don't have concrete stats on _how_ well they support it (i.e. performance) but I haven't heard anything particularly worrying about using webGL via the web on mobile devices.

You're totally right to hate ads, almost everyone hates ads, even the people that create them hate ads. Some alternative monetisation approaches: * Free demo, paid game. App stores make this trivial, harder for web. * Pay for things in game. New Amulet of Awesomeness +2, that'll be £2. * Pay for in-game currency. New Amulet of Awesomeness +2, that'll be 200 Mithrilandian Coins. Oh, by the way, if you don't have the coins, you can buy 150 for £2 (never let someone buy the exact amount they need for something, always slightly more or slightly less than required). * Pay for stuff/currency by watching ads. Watch an ad, receive 10 Mithrilandian Coins. This could also apply to 'extra level tries', 'resurrects' or try agains. * Paid DLC. Want your heroes to explore the Mysterious Caves of Vanthrox, just $5 and that stage is unlocked. * Ask politely. Crowd-sourcing, Patreon, Kickstarter, you could direct to any of these sites and just ask for donations. There are probably loads of more inventive ways to get players to part with their cash. I have no experience of an SDK or other tooling to help, I _thought_ that iOS/Android platforms made this relatively straight forward, so that you didn't need a third-party tool to help. No idea for web and/or cordova-plugins.

Not just webgames, any games! Not just games, any applications! The easier you make it for people to just get going, the less friction they have, and the more likely they are to get to the 'am I having fun?'. Games like Dwarf Fortress take a lot of effort to get going, they lose a lot of players before they get to the 'am I having fun?' question. Affordance theory (presented initially by Gibson) is the theory that objects 'project' their usage, the normal example is a door handle, the shape of the handle implies gripping and turning, you can argue whether this is learned or innate but you can not argue that almost every one on the planet knows how to use a door handle without thinking about it. The holy grail is to get your game/UI/app so intuitive that users just naturally fall into a 'pit of success' and are able to perform the actions they need to to meet their goals, i.e. win the game. I'd argue that advanced users might want more information, but, ideally that information should be in-game. The opposite view to this was popularised by Minecraft where players were encouraged to discover mechanics together, usually outside-of-the-game (at least initially) via the internet (youtube, forums, etc etc). Minecraft is a bit of an outlier for many practises though, but, its an interesting game mechanic to explore, of course, you need to player base in the first instance to be able to explore it.

If you absolutely have to provide detailed game instructions, particularly to beginners, you're doing something wrong...

Good ole polling, never goes out of fashion

Websockets will be the more elegant solution, and lets you 'push' to clients as state changes rather than 'pull'. Most websocket implementations, such as socket.io, will gracefully fall back to long polling for you, for those handful of users stuck on an old browser that doesn't like websockets.

> Anyone has any ideas why the responsive code doesn't work? Because Safari is the new IE6. Seriously, I've had a group of developers waste a load of time on inaccuracies in Safari like this one, with very mixed success. There are so many little problems with developing for Safari. The blue hotspot 'banner' is often invisible to the web, ditto for the task bar at the bottom. Dealing with either is not good, in fact, I'm not convinced you _can_ even deal with the hotspot bar effectively, although, as you've noted, different versions manifest different bugs/inaccuracies so maybe it is more accurate to say that you can't fix things for all your users all in one go; i.e. you have to pick the _least_ annoying problem and some users will just have to live with it, either the least annoying problem or the smallest sub-set of users. Something you could check though, that might help: *Check when resize fires* I think that it can be a little inconsistent (across versions) i.e. sometimes it fires early and you'll be measuring the screen _before_ the resize, sometimes it'll fire late, in your case it sounds like maybe it is firing early and you aren't measuring the screen dimensions you think (and want to be) you are. The only solution for this _early_ firing is to use a small timeout. Of course you don't want to fire it too early and you don't know when the screen will _actually_ rotate so you have to give it a bit more delay than you think, which will be 'flashy' for users, and using timeouts for this stuff is always dangerous because there might be some processing that delays rotation and you get it wrong. You _could_ try to work out the ratio and try to keep track of landscape/portrait to see if you're checking the correct orientation change, but, if you get this wrong (i.e. when the user rotates a lot) then you could get really stuck.