Let's classify stuff.

Objects, as you call them, are obstacles. They have numerous possible actions, meaning that stuff happens when you touch them.
Actions for obstacles might be
- Teleport
- InvokeStash (for treasure chests, corpses and so forth)
- Damage, Kill
- Heal, HealFully
- FireScript (generic stuff that happens as the mapfile dictates it, like a falldoor teleporting the player after the stash was invoked, then damaging him, then text is displayed)

So that's a template in the OOP sense which specific obstacles can derive from. That makes it easy to build something specific:
- Derive from Obstacle template
- Set properties as the specific obstacle demands (collides YES, damaging YES, teleport NO, damage 10 etc)

It's easy to load such properties into the templates from a mapfile.

Mapfile layout:
The mapfile obviously begins with the map layout, as it does right now.
Then comes the list of obstacles, and each cell in that list contains the list of obstacle properties (type, name, collides, damaging, ...). If some property is not set, that property retains its default value as set in the obstacle template.

That looks like this:
g_gameMap.mapObstacles = { {x=12, y=15, type=12, name="tree", collides=true, damaging=true, ...}, {x=12, y=18, ...} }

That sounds tedious if you think of it in terms of editing it with a text editor, but with a level editor that's written in Lua, it's rather easy to handle for people making levels.

The items are pretty much obstacles, but the player can pick them up (obstacles have the property "isItem").

The interesting part is that with that approach, an object can also have weight for pushing, a tint and so forth, and it's easy to extend the format in principle.

The hard part, as you indicated, is FireScript. Everything happening in there can only be stuff that's properly coded. FireScript basically calls functions after all.
So after the list of obstacles, the list of scripts follows. Each cell in that list is such a script.
One cell's layout:
- Item number (as defined in the obstacle list above; really just the array index)
- Function1 (the function name)
- List of arguments for Function1
- Function2
- List of arguments for Function2

The code obviously has to "know" what arguments to expect. The leveleditor has to reflect all of this 1:1.

The result is that everything is in one file, and it's rather easy to read, generate and digest.

I've partly implemented it, it's not completely done yet because minimap stuff is missing.

I've strayed a bit from the concept I described above.

It's basically like this now (this code is in a mapfile, after a map's layout with walls and stuff):

http://pastebin.com/6137fJQ0

So as you can see, there's 2 doors. What they do is in the o.actions = function(self) ... end block.
One of them eats 500 HP, the other one heals 50 HP. Both of them beam to some positions.

The engine has the appropriate mechanics (like item-driven player collision detection, for instance).

It works well; there's some caveats though. For one, you can't beam from one door directly onto another and then directly onto the first door because then, there's a feedback loop and positions break. So doors have to be smarter than that (meaning, not teleport when the player just teleported onto one).
Also, the minimap doesn't display obstacles now. Only walls.

I also put some DEATH into the game.

Alright, I fixed the minimap, added a dead player dude and pushed the changes upstream.

To enhance the scripting, write methods in obstacle.lua and use them inside the actions() block in a mapfile. maps/origin.lua is an example for this.

Jason how about a Easter Egg

how Will Enemie AI Work

How Will It Be Publish.How Long Will The Game Be