Original Post
The RPG-maker program I have in mind is based in spirit on the groundwork laid by Stuart Smith's "Adventure Construction Set" and Chris Hopkins' clone-of-sorts "Adventure Creation Kit." It is written with Python/Pygame, will be public domain open-source, and should have a project set up to develop a community and continue improvement when I get it to a releasable state. The main thing I want to preserve from these two programs is the great accessability they have both for the player and the creator; the core gameplay is kept to the basics of dialog, puzzles and combat with only one PC controlled at a time. Premade graphics and object definitions make quickly setting up a scene a simple matter, while the customization abilities are good enough to keep each game unique. Games made with them are roughly described as "light-RPG" and they both really hit a sweet spot for me when I was younger. (But ACK was newer and more powerful and so preferred, albeit buggier) What I would like to do is to find a starting point where I can do what the earlier programs did, but a little bit better, with room to non-destructively expand creator power later. GCS and moddable-game design is a field that isn't often touched here, but is worthy of a lot of consideration - I believe it straddles a line somewhere between software architecture and game design. This post is in part meant to help me work through my own design and make clear the parts that aren't clear yet. So while I would love to see commentary, I do this for myself ;) Both programs lay down some pretty solid ground rules: the game is, in a general sense, turn based(although in ACS there was a real-world time limit, linked to your per-turn movement allotment). The maps are strictly tile-based 2d maps, with only "chunky" movement within the grid allowed. The combat system is fixed and has little nuance to it, but remains fairly flexible because of strategic differences in weapon abilities as well as simple numeric changes - for example, in ACK you can define "cone," "beam," and "bullet" types of ranged weapons. In both programs the game is primarily made within an IDE that uses simple list and menu choices and built-in tile and map editors. Much of the gameplay is produced through the elegant use of "have item," "on use" or "on drop" commands built into objects - with these you can unlock doors, mine for gold, read scrolls, etc.. ACK also has a classic Ultima-type dialogue engine, and very basic scripting abilities. The specs written into the code as of now are something like this: -Chunky tiles and turn based system, as in predecessors; one upgrade is the use of time units as in some Rogue-likes; each turn an actor takes one action, but their next turn only comes around after so many time units have passed dependent on stats and the last action. -All game objects("Things") are given a Python dict(hash table) of properties that are relevant to gameplay. Many properties are assumed by the engine to exist in the current code. Part of the plan is to allow gameplay scripts(which are an undefined thing atm) to exist as a property. So an example Thing might contain: "name"::"Man" "isalive"::"True" "desc"::"Some average joe." "tile"::"man" "strength"::5 "dexterity"::5 "talkto"::("dialogue", "joe") "death"::("drop", "gold", 1) Something I just came up with while working out this example is that I can pretty easily parse the tuple objects - the ones in parenthesis - as more complicated actions, without necessarily making it the de-facto scripting language. Instead, I can get by with built-in actions like "dialogue" and "drop" at first, in effect duplicating everything the earlier programs were doing. Then, later on, I can introduce "script" as an action to maximize flexibility. Another thing is that while there is a human distinction between attributes like "dexterity" and actions like "talkto," this isn't going to necessarily be seen by the program. Some actions could return values and trigger other actions. Pretty complicated stuff. -Map tiles("Blocks") are also given properties. Until just now, I was going to include additional property dicts for per-turn and on-entry events(to change the values of the affected Thing) but that could instead be handled as an action or script in the main property dict under "perturn" and "onentry". See, writing these things helps! -Combat will start fixed. Later it may turn into a script...but the issue there is with graphical effects. It'll require the addition of actions for all sorts of effects to duplicate that functionality. -The interface will also start fixed to match the combat system. This too can probably be changed later. -Things like inventory and the general turn-based-movement procedure will probably stay fixed. Some items I need to think about more: -a simple yet flexible combat system to start from -vehicles and how to make them work -portals to different maps -multi-tiled things(like large enemies....or vehicles maybe) -various user-interface choices