Okay, as I was reading this, I was thinking "My GOSH, this sounds a LOT like the QBASIC game engine for the ASCII Adventerator by Space and me! The project is shelved though, for a while, due to an overload of work....

> How about a game engine which would encompass grid-based puzzle/adventure games such as Enchanted Forest and Exterminator?

Done. Well, it's sort of on a grid, as good as ASCII can be. You move up, down, left, right etc. And hey, it actually looks like something!

>A game written to use this engine would consist of a rectangular grid, and each square would have a separate variable associated with it (like a state variable in the AGL engine).

Well, yes. Each location has an x,y co-ordinate, and I can put anything on there, be it as simple as a wall or as complex as an enemy with advanced AI that will constantly be on the move, one square every second (but I'm still working out the AI script). I can change variables (1000 of them, with more in store if needed) and other such things.

>These variables could represent something really simple such as the particular graphic drawn for that square, or perhaps something more complicated. In addition, the game engine would keep track of a list of "objects" which can move throughout the grid from turn to turn.

Ahh, the objects file. Have it. And the term 'object' is used lightly. Everything that isn't part of the map is an object, even you! Or course, I'm limited to one ASCII caracter, because that's how big a square is.

> For example, if one were to implement Enchanted Forest in an engine like this, state variables could keep track of whether a particular square was (unexplored, explored, tree, petrified tree), and the object list would consist of the player, the leviathan, and the pixie. For Exterminator, the state variable could represent (empty square, wreckage pile), and the object list would consist of the player and all of the robots.

You know, now that you mention it, that really wouldn't be hard to do. All I'd need is a few objects and then assign a random object to each square. When you move into a square, the script for that square auto-runs. I'll have to think about designing an EF-like game. I'll store that as an idea along with actually completeing the RPG and Tetris.

> At any given time, one object would be designated as the "control object", usually representing the player.

Yep, you are defined as object 0. If your poisoned, for example, I can change your color to green!

> One file for each game would initialize the grid/object list (much like the 'start' file in AGL), and be either a fixed pattern (for example, a puzzle game grid), or a random generation as in EF. Another file would specify which graphic images are used for each square after every turn (this would depend on square state values, object positions, and possibly other global variables). There would be a separate file consisting of small graphic images, of course.

Yep, Start file for the map. Now, it doesn't say with grpahic goes where -- that's the Map file's job -- but the start file would be used if I wanted to make a random object on each square, much like EF. Of course, I'd use ASCII character 6 for a tree and stuff like that, but it could be done...

> The main file, however, would handle the game logic itself (determining which options are available to the player, handling the results of a player's action, updating state values/object locations, etc.) and would consist of most of the programming. This could be done in a similar way to AGLL programming, I suppose.

This I don't have. Each object either takes care of itself, like walking enemies (via a one-second file) or will only activate once the player moves onto the square (like most stuff). If the code for the object in the square includes removing the object, it'll do that after the script for the object has run its course. Basically, the logic for each square would be programmed individually.

> I'm not sure if all of the preceding would be the best way to implement the idea, so I'll go into a few examples of games/puzzles that could be created fairly easily with such an engine:
>
> (1) Mazes. This would probably be the easiest creation. Only one object (the player's position) would be necessary, and four state values (starting point, ending point, wall, open space). The game logic would be very simple (give the player the option to move in any direction where the adjacent square is not a wall or off the edge of the grid).

Yeah, this would be VERY simple for me. It would only need the map file, a start file, a win file, a timer maybe, and a lose file. If I really wanted a good maze, I might make it so that the walls are invisable until you come close to them. That would require a lot more programming though, although the code would be fairly simple.

> (2) A 'mine-sweeper'-type game. Again, only one object would be necessary. State values could represent unknown squares, open squares, squares marked as mines, and number-bearing squares signifying the number of adjacent mines. A bit more complicated to implement, but still fairly simple.

Could do it. I'd have a hard time trying to figure out exactly how to go about the numbering/mine-laying bit though so that it all would be correct. I mean, it'd be bad if there was a '2' and there were 4 mines around it!

> (3) Exterminator-type games, in which multiple objects occupy the grid. As an example, one could make a puzzle game in which your character must do things such as push blocks, flip switches, and use other tools to find the way to the exit. Anything that moves (such as the pushable blocks) would be represented as an object). The possibilities here are endless.

That's more or less like the RPG I'm making. You have to gather some objects make money, eventually buy weapons and defeat bosses, often in a specific order. You have an inventory and equipment screen -- I have yet to really make use of those but I will once I resume the project. And indeed, the possibilites are endless. After all, the map-maker program uses the same engine as the actual game!

> So, what does everyone think?

Gremlinn, I think that we think way too much alike...

-Ka"The only major problem so far is that the engine doesn't want to become a stand-alone .EXE!"z!