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

I very much like this idea. I was a huge huge fan of Stuart Smith's ACS. I finished about 6 full games with it and made probably a dozen or more half unfinished games, Graphics and all. I have yet to see a game creation tool that captured the simplcity of ACS. I mean, i was in 4th grade when i started using it, and in 7th or so when i finnally stopped using it. It was literally "child's play."

Even then, I noticed there were too many limitations. For those unfamilar, ACS limited you to 16 maps, 127 objects per map, 128 sprites(16x16x2bit tiles) per project. These hard limits that were set in place are a non factor in making a modern version, they can be done away with.

Most of the improvements to ACS that i can see involve making the battle system and stat building system better. I will suggest from the view of improving ACS.

You need to balance how skills increase. In any ACS game you could get most of your combat skills (melee, missle, dodge, parry) maxed out relatively easily. This made any combat in the game trival unless you were fighting a similarly maxed out enemy.

Maybe add more atributes to armor and weapons while still preseving the simplicity of the system. Power, Speed, Recovery time, stat modifiers, special damage/defense (fire, slashing, blunt, etc)

A more robust spell system is needed too. Need area effect spells, line of site, and possibly status effects, the standard stuff. Effects that could be used as escape or crowd control spells was something that was lacking in ACS.

Things that can add strategy to the battles where a low level player can overcome higher level enemies are always a plus.

As far as interface. There definently needs to be a quicker way to change weapons, use spells, and use items.


I guess to sum things up:
-make very large games possible by reducing hard limits and balancing combat to allow steady progression through many different sizes of games.
-make equipment, items, spells, and the movement system complicated enough to allow designers to make combat strategic
-impove and streamline UI for both designer and player
-scripting to many aspects of the game would be a huge bonus for advanced users
-above all, while trying to add features and improve, try to maintain the simplicity of the orignal ACS.