Thanks for the suggestions. Some really good ones.

Could you explain what you mean exactly by "Game size (canvas size etc.)standardisation"?

Also, when you say that the size of wade feels big... do you mean the full (unminified) source code of the engine, or the actual wade.js file (minified) that you get when you click the Download button?

The source code feels big. But I have not tried to release or publish it. Before I set out trying to code games I worked backwards. I get the feeling that because the source code is so big, there is probably a ton of stuff when I come to release the program that could be packaged with the program that will not be used. My first game will be your connect 3 or make 3 your wizard.

Another suggestion would be to do what panda2 have done, with code examples. They gave code examples for literally everything. While 2DKit have made sure you can monetize easily. Theirs is slick, but it does not marry well with code, or it gives me that impression. It feels like a Unity lite type of thing. And I lost days of my life just trying to set unity up, it just was the biggest mistake I could have made. At the moment it is panda2 if your a coder and wade if you want a mix of the two. A big change would be to give a coders view. Read-only view, then when you have done the building blocks you can download the source code and code with notepad++ or visual studio code, atom etc. But do not go too far if you go as far as unity you need a degree just to learn the package.

the game size is important cause at the moment I do not trust the preview mode to be a good reflection on what is happening on browser phones. As your marrying coding with a visual development environment, you can feel lost to the eventual outcome. The worst thing anyone can do is to take something in the wrong direction, based on a guess or an assumption of what is happening especially with boundaries of display.

By game size and canvas size. I really need an understanding of how it will look on a phone, tablet etc. So some default size that are for different devices. If you look what panda2 have done, you get a real sense of confidence that what you write and test run will be the same on a phone. It could be an idea to display a coordinate system when you preview. My second game needs to be pacman and the maze for me needs to be coded, also the monster AI in my head needs to be coded. That does not naturally mesh with your environment yet, but I am going through your tutorials to workout how I would do it. I might have to use panda. thats next week.

only on audios, so I will see what scripting is like next week. Just noticed you do that as well.

Thanks, that's helpful.

Just to address a couple of your points... there is a plan to let you use a "normal" file system when you use the downloadable version of the editor, as opposed to the virtual file system that you have now. So you won't need to download your code files, they will be saved on your hard drive like normal files that you can edit with WebStorm, Notepad++ or whatever, while still having the ability to use the Wade editor for editing scenes etc.

This is planned for version 4.2, so not that far off but realistically a month or two away.

Size-wise, I see what you mean. Generally though,Wade has been built with the idea that the one JS file you need to include (the minified wade.js) should only contain the core functionality that most games always need. The rest can be included separately (the physics engine, specific behaviors and so on). The core part is currently around 340KB, but only about 80KB when g-zipped (this is the actual download size).

In the past we used to do this to a greater extent, so for example the isometric part of the engine was separate from the rest. While this allowed us to shave off a few KB from the total size, in retrospect it wasn't worth all the additional complications. So now we have a slightly bigger core, but it does more of the things that you might need in many common cases.

I agree with your comments regarding standard display sizes. We do have a very solid scaling system, but it's not immediately obvious to users what they should do with Min Screen Size, Max Screen Size and all that. Could be made more intuitive.