itch.io

Great! I will post there, as well... But for the moment, I will post this here, as I believe feedback from everyone here will also be helpful to you.

First things, first... Put the whole issue of Web/Win(32/64) aside. Separate the game engine from _both_ the game presentation (including UI, graphics, and platform), and game data. Focus _only_ on one part at a time. Then, you will have a game engine that can run on Web/Win/Mac/Linux/Whatever, and you only have to develop the parts of the UI that are different for each platform, without needing to constantly refactor the engine.

The same holds true of the visual (graphics), audio, and the game data. You want each part to be able to operate both on it's own, and when combined in different configurations. Maybe you can do multiple--There is quite a large number of "old school"/retro/vintage users out there and on Itch (look at all the retro 8-bit remakes on here!): You could offer a "retro 8-bit" UI and graphics, as well as a modern HI-Res version, without a lot of extra code (or re-coding). It also makes it relatively easy to provide simple models for different platforms such as Web/Win/Mac/Linux/Android/iOS/whatever.

Another advantage is... you mentioned a tutorial. I would put that aside for now -- make the different components separate modules (Engine/Data/UI/Platform), and a tutorial will likely become extremely easy to add, as it would fall under Game Data, and be more of a matter of the tutorial simply combining the other parts of the game in a guided manner. From the Engine's perspective, it does not matter if it receives a command from the user or a tutorial script. It simply does what it was commanded to do, such as take Object A and Object B, and mix/combine them to create Object C.

You can also worry about balancing mostly when working on the Game Data, and not need to worry about the Engine or UI while trying to find a good balance. Same goes for the graphics. You could set the graphics initially to be simple colored dots on the screen during development, and worry about fancy, hi-res graphics and art without needing to change the engine code. And so on.

All these things are the very heart of any kind of computer development and programming, and more so when you add in object orientation: Encapsulation, Implementation, Interface, Modularity, Re-usability, etc.

One thing I always keep in mind, even when writing a short, one-shot program to handle a specific task, is that the computer is nothing more than a numerical processing machine. It does not care where the numbers come from, or if the numbers represent "pure text", or high quality graphics, or something else. It simply follows the same pattern: Input Data, Process the Data, Output the Results, and Repeat it all again.

One thing to note, in particular, is that nowhere did I state "analyze the data". That is because the computer cannot do that on it's own. It cannot look at the data and conclude that it is script to execute or an image to display! Yes, you can give it instructions on how to do that, but it cannot do it until _you_ tell it _how_ to--even if that is simply giving it a code library you or someone else already wrote to do so.

Keep that in mind and you will start to think in the way I do: At the lowest level, you simply have a series of instructions telling it how to input/process/output. At the next level, you do the _same thing_! The only difference is that instead of low-level CPU primitives, you are combining code libraries in a sequence that accomplishes the desired (sub-)task. And the same thing for the next higher level; The process does not change -- only the building blocks do, becoming more complex at each new higher level, until the level and complexity are sufficient enough to complete(/solve) the task at hand.