Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

Thank you for playing.
Yes, it is pure canvas-API, but I made a template that I call an engine and it saves a lot of time.
Do you have a specific DOM-based UI library that you would suggest, I honestly don't know of any.
The pathfinding is so busted, I tried to shortcut it to save time, and reduced how often it would be needed in a normal match, but you can't guess your way into optimized pathing, I'll see if I can learn more and fix it up.
Incidentally I do know Typescript, I should migrate to it, but my template is in JS which adds inertia. I will really consider making a typescript version of it.
I do use Visual Studio Code, yes. 

(+1)

The DOM-based UI libraries I think of are the major ones, such as React, Angular, Vue, etc. However, these options comes at certain costs, especially the part where you mix Canvas-based graphics with DOM-based UI. For my game, I thought the trade-offs have been worth it (using a web game framework together with React), though it is by no means a free trade-off. I would recommend that you investigate it thoroughly before attempting it.

For browser-based games, I believe there are 4 main options for UI in a game:

  • Roll your own UI in Canvas - this is what you are currently doing. It doesn't quite scale without a fair amount or lots of effort into the UI library itself, and writing a good UI library is not easy, but you skip the issues with the interaction between DOM-based UI and Canvas-based graphics and the issues with DOM-based UI itself.
  • Use DOM-based UI. The interaction between a DOM-based UI and Canvas-based graphics has a number of challenges and issues, and DOM-based UI does have drawbacks of its own (the DOM APIs are many and often large, meaning that even mainstream browsers like Firefox and Chrome will have bugs or missing functionality even in somewhat basic features - these are some of the browser bugs I encountered: https://bugzilla.mozilla.org/show_bug.cgi?id=75324 , https://bugs.chromium.org/p/chromium/issues/detail?id=836244 - and this is worse for mobile browsers - and since web game using DOM-based UI have much less well-trodden parts than regular web applications, expect more and worse issues). You can then additionally use a DOM-based UI library, like React, Angular, etc., which have their own benefits and drawbacks, including in the interaction with Canvas-based graphics.
  • Use a web game framework that features its own Canvas-based UI library. It depends on the web game framework in question how well-developed it is, and web game frameworks tend to have less momentum than the major game engines.
  • Use a game engine that exports to web and which features its own UI.

Of course, it also depends on how much you want to invest into the project, your goals with the project (is it learning? Is it to show off something to others? Is it a long-term project? Is it commercial? Etc.), and so on. I do know of at least one (commercial) project that combines a Canvas-based web game framework with a DOM-based UI library: "Citadels" (there's Facebook and Android versions), by this Russian company: http://corpwebgames.com/en/ (grinding game I believe - I don't play that kind of game, but someone mentioned it as an example of a major/popular game made in the same web game framework that I use for my current game project, and I looked a little bit into which technologies it used in both the web version and the Android version - I recall it using Cocos2D-X or something on Android).

(+1)

Very detailed, thank you. Incidentally I happen to know react as well, but I didn't realize it was a DOM-based UI library. 

(+1)

You're welcome :- ) . I believe the expression "DOM-based" UI is a self-made description by me, it was the best description I could come up for differentiating it from "Canvas-based" UI. Canvas-based UI is very rare outside of niches such as web games as far as I know, so when referring to web UI, DOM-based UI is (I believe) the norm and what is typically assumed.