Integrating and interacting with IronPython is very smooth. For me the greatest aspect is how the script's running in IronPython's scope allows it acess to the engine structures which can inturn be modified and used via reflection. I remember the last time I tried to have scripting support for a game, I used a language called Pawn (formerly known as Small, used by Eternal Lands), it was not bad but getting it off the ground was not the most pleasant of activities. Plus, the app <-> script interaction was nowhere near as robust and elegant as the .NET technologies has allowed.

I shall be storing the worlds as script files. In my last RPG project (RIP 2004), the maps were stored as binary files, Id simply write out the data in the important structures, i.e. NPCs, items,world map. This was not so good as each time I changed a structure - say for example, giving NPCs another stat or adding light data to the map the game would loose support for old maps. One solution would be to sit and plan everthing perfectly ahead of time but that is boring, plus no one is so perfect. However by storing the world as scripts, telling the game what to add,how to draw, etc. newer implementations of the game engine will still be able to use old modules with no need for conversion since the scripts would be extened and not subtracted from.

Suppose a new attribute was added to NPCs and I wished to load an old map (while still supporting new ones). C# is very strict about its parameter count so it would cause an error to use the old way of adding an NPC since the newer engine will be expecting say two parameters. For example:

Quote:
world.Members.Add_NPC(health) # would not work in new version of map
world.Members[world.player.focus].will = 4 # would not work in old version - Game engine is backwards compatible but not forwards.

Quote:
world.Members.Add_NPC(health,will)
world.Members[world.player.focus].will = 4 # good

But we can get around this. I do not wish to clutter the game code with overloading 500 versions of Add_NPC() but luckily python is incredibly flexible in how it handle arguments and it is useful to tap into that. To do so,an interface module is made that wraps around the utility class which exposes the important game objects. The map can import this module and work so that old style map files still execute. All that would need updating would by the interface.py script.

##########interface to utility class##########def AddNPC(o, hp = 10, will = 2):      o.Members.Add_NPC(hp, will)##############import interfaceinterface.AddNPC(world,hp)interface.AddNPC(world, hp,will)

Now to design a good map script format..