It could take years to figure out all the ins and outs that go into a game engine. Even as a programmer who's tried to make my own engines, I've found it a lot more satisfying to start from an existing basis. And that doesn't make it easy, just easier. :(
I was looking at free engines I could suggest to a non-programmer friend of mine, and I liked Construct 2 a lot (https://www.scirra.com/).
Construct 2 is a tool with free and paid versions, and I tried the free version. One thing I like is that even though it has a rich editor for arranging level designs and animations, it also lets you write plugins that use arbitrary JavaScript code. This means it's probably really easy to put in a JavaScript evaluator. That said, once you're trying to invoke Construct 2's special-purpose functionality from JavaScript code, I have no idea if it's as easy to use as the editor.
Another reason I like Construct 2 is that it saves the game in a pretty readable XML format, so if it really doesn't work out, it's probably not hard to write a tool to parse what you've made and translate it to another system. Knock on wood...
These two features give me the confidence that if things get messy, someone can don a programmer hat and write a chunk of dedicated code to get things back on course.
It turns out I didn't actually get very far in the project, though. After I built a few moving platforms and teleporters, I found some of the platforming physics to be quirky in ways that it seemed like I'd want to dig into the engine to fix. While it seems like I could put in a custom implementation of platforming physics with JavaScript code, I was no longer excited enough to keep up my momentum in the project. But those quirks had to do with the details of what happens when the player gets crushed under a moving platform, and I was also trying to do frame-perfect fine-tuning of the jump physics, so if only I were in a somewhat less picky mood, I could have gotten further in the project.
It's a popular system that's been around for a while, I got the bundle just in case I want to see what it's capable of someday.
---
"4. How does one control scrolling in different directions? Do you create the screen in memory and then instruct the system to scroll in the direction of the newly created portion?"
The exact details depend on the game engine, but action games are typically written in an object-oriented style with some "stepper" logic that runs at a regular interval. In each run of the stepper, you process user inputs and determine what graphics will be rendered to the screen. Each step of the stepper may be divided into multiple phases, like a user input interpretation phase, a physics phase, a collision resolution phase, and a graphics rendering phase.
Scrolling is a common need, and there are some traditional optimizations and gameplay conventions that apply to scrolling (such as not updating objects that are too far offscreen), so game engines often offer built-in support for it. A typical interface is that you have a scrollable stage object that you put things in, and you can make a camera object and put it in the stage too. Then you make a camera.setCoordinates(x, y) call to update what part of the stage is showing. You'll tend to make this call at some point in one of the stepper phases, any time after you've calculated the player's new physics position but before the graphics have been drawn.
It's possible I'm misunderstanding what y'all mean by "maze game". Does something in text mode like https://github.com/ryanb/ruby-warrior qualify? It's probably at the bottom of a steep hill with Dwarf Fortress at the top..
If text mode is an option, I'll plug my Basic-like http://akkartik.name/post/mu language. My students have made tic-tac-toe and a card game with it. Maybe we should try a maze game next. Here's a text-mode chessboard program, for example: http://akkartik.github.io/mu/html/chessboard.mu.html. With tests for screen and keyboard access (search for 'scenario'). I'm sure it looks like Greek, but take my word for it that 11- and 12-year olds found it pretty easy to work with. Happy to show more over a Hangout or something.
Ack, right after I typed all this out I remembered the Windows constraint. That disqualifies Mu, at least immediately. I knew there was a reason I chose to keep mum when I saw jsgrahamus's post last night.
I know someone who's making a game with Clickteam Fusion and considers it almost a form of betrayal to go with GameMaker. :-p So when I brought up GameMaker, I was thinking of mentioning Clickteam Fusion as well, but the usual cost is $99. I don't really know enough about it to know that it's worth that price tag. Now that it's on sale, I guess I'll be picking it up just in case I want to use it sometime, just like the other one.
