Plan for James W. Hofmann

start of qcs scripting, map editor

Most of the stuff I've been writing for QCS has been straightforward; I've done it all in some form previously. The actions and scripting, however, are new to me...and they get complicated pretty quickly.

The plan I have right now is like this:
1. Game loop cycles through all game objects(things) in the map, incrementing a turn-taking timer. This makes relative speeds easy to model in a turn-based fashion, and game time can be measured "realistically" as well. When the map scale changes relative speeds can be scaled as well.
2. Every object, on it's turn, takes an action. Actions can be actual effects, or triggers for other actions(so scripts are a kind of action). So the player thing always calls the player-turn-taking action. I don't really want to do scripting right away, because that just shoves the hard work of core gameplay into script-land immediately. I'd rather that it start out mostly fixed and then have everything be translated into default scripts later.
3. (where it gets uncertain) Right now, I *think* what I can do to make gameplay work is pass to the actions two pieces of information: a command with some data, and the calling object. The tricky thing is that the actions have to be flexible enough to work in multiple situations. If the action is not changing gameplay variables but instead just displaying text or showing a picture, I don't need anything but the command and data. And if it's going to affect the caller, I can easily include that information. What got me confused was if I want the action to affect some other target.

I'm pretty sure that what could be done to make everything work is to make the use of the calling object the key to advanced scripts: A script could get the map data, analyze it as needed, then say, "object x is the caller now" and then run an action with that data.

The next step is responsiveness: do actions ever need to return anything? Or, by being *actions* is that a moot point, since nothing will be done with the data? In a script there has to be a way to gain information, of course; but that doesn't have to be done through calls to actions. If there's a case where an action might produce results that are very hard to acquire through other means, it might be worth including. But that's something I'll have to think about a while longer.

Getting out of action-world for a bit, I got a little walkthrough demo with collisions working. No living objects other than the player, and it cheats by never using the action system at all and just checks the properties of everything directly, but it all works great. After I did the walkthrough demo I started on the map editor. No drawing yet, but you have a mouse-driven cursor and you can scroll around with the right button either by holding it down within the frame or on the borders. Or you can use the arrow keys. One thing I've found out from previous experience is that a graphics tablet is incredibly useful for editing anything on grids, so I try to make it easy to "paint" with those. Though one thing I haven't figured out yet is how painting works on the keyboard - the mouse moves the cursor around, but the arrows don't move the cursor, they move the view. I suppose I could have keyboard movement "reset" the cursor to the center of the view...

This is all in about 500 lines of Python right now. I'm guessing that a "complete" version that can edit and run games may be somewhere between 2000-4000. It depends on how much space the editor interface takes up, really...