Scenario making and system design

[Blade Runner]

Mark,

1. We need to produce a flexible system for the scenario makers and for
ourselves to produce add-ons on later stages. I think the best if the
users can modify the system in 2 levels:

The first (easy) level can be similar like the CIV2 .txt files. A
primitive parser can collect data's every start, then put inner
variables.

The second (sophisticated) level can use the same java code like the
game. Practically we can provide a few code module with description to
the users to modify.
Advantage: The users needn't to learn a new macro language.
The users code speed will be the same like the other part of the game.
If we want to change something on the later stages, then we needn't
write newly the interface part and the macro.
Disadvantage: We can't pre compile the complete code.

2. When you finished the system design you need to produce (or find
somebody to produce) a system plan. This plan must contain not only the
modules, but define the interfaces between the modules (let say: how is
look the record structure which contain the AI decision about a
diplomacy event, etc.) and the coding rules. Nobody aloud to change this
rules and interface descriptions without your permission. So you need to
keep the development on the track.

[Dominique]

While I wouldn't dare to touch any java code (fearing I could destroy everything), I'd welcome some easy to handle parameter file (like CtP's .txt files) - BUT...

- for a scenario designer, cross-references are deadly. These, especially when distributed among different files, should be avoided wherever possible.

- all flags, parameters etc. must be thoroughly documented. I think it wouldn't be a problem to build a heavily documented text file which can edited using any text editor, but which will be compiled afterwards to a compact, non-commented form. This compilation could check for any fatal errors, as well. So the user would have all the knowledge he needs, but the program wouldn't have to mess around with gigantic file sizes, but the necessary data only.

- avoid at all costs users needing to replace / patch existing data... so there shouldn't be any "mods" in the proper sence, but add-ons only between which you can choose at program startup.

- the same is true for gfx: I always loved those easy-to-edit (and in part even documented) images in CIV2. We should do it exactly this way.

- avoid restrictions wherever possible; e.g. in CIV2 the possible number of different unit types was severely restricted. I see no need to do that - everyone should be able to build scenarios with as many units / terrain types as he likes.

So much from the graphics slave ...


------------------
If somebody asks you "Art thou a god?", you tell him "YES!"

[manurein]

About the .txt files : those built with CTP are a mess since when u build a scenario u alter the whole game. Then u have to make backups and sweep files each time u change mod or try to play MP... This should be avoided at all costs!

[Mark_Everson]

It seems to me you should have a directory structure beneath the game home for different scenarios and mods. You'd just pick which one you want to use on startup. If a file wasn't in the "mod" directory the program would use the default.

I don't know why they don't do this right now, its so simple, even I could do it . Well, Maybe...

[manurein]

Sure u could do it! And it's in deed the right way.

[F_Smith]

1) I'd prefer not to use a formal 'design/code/test/model office' structure in developing this game. I prefer a prototyping approach, and I've found that it not only cleaner but much, much faster way to turn out superior quality code.

I'll get more into this later if anyone wants, but to sum up -- each 'subsystem' should be given to one team (in our case, likely a team of 1!) of programmers. They are given a general outline of minimum requirements. They spend a little time working up the best architecture (*the* most important step!). Then they make a simple working model that implements just one or two of the requirements. Then, repeat.

This allows the programmers to heavily test their code, and it allows them to build the subsystem to suit coding possibilities, instead of the other way around. The typical 'corporate' approach, one you see in all the big game companies, is to design a game then force the coders to to their bidding.

Big, big, BIG mistake -- which is why none of them ever come out on time . . .

2) I would much prefer to build a 'scenario designer' like AoE's, or StarCraft's, and store seperate 'map', 'situation', etc, files. Anyone mind that approach?

[Dominique]

F_Smith (still don't know what the "F" means ):

I didn't dare to ask for a special editor / design program. Certainly this is the way to go IF you want to busy yourself

Nevertheless, the actual data should be plain .txt files - you simply never know.

And, yes, OF COURSE there should be an appropriate directory structure to separate the "mods" (still prefer to look at them as alternative add-ons).

My proposal is to do the plain .txt format first - lateron, there will be time enough for a decent editor. Just concentrate on the main thing for know, I think.


------------------
If somebody asks you "Art thou a god?", you tell him "YES!"

[Blade Runner]

Dominique,

I think you are absolutelly right with the .txt files. In my mind to modify the .txt files is enough to produce any scenario which was possibile with CIV II and even more.
I think my "primitive parser" explanation was a mistake. It is realted with the program code and not the modify level of the txt files.
IMHO to contain a few java source files can be life saver for people (with programing experience) who would like to produce add-on's with the Clash (let say a space Clash or something special). So you needn't tweaking with java code if you stick to the normal interface.

Blade Runner

[Mark_Everson]

'F':

I am certainly temprementally much better suited (and have in fact used so far) the prototyping approach you describe. Lets see what the other coders say.

Can you say a little bit about the scenario design types you allude to in AoE or SC? I've never played either game.

'D':

(perhaps we'll have the whole alphabet soon!) We'll have to discuss when to implement the .txt approach, but it seems to me it fits in very well with the prototyping approach outlined above. For instance when the java programmer finishes a substantial part of a model others could look into the sort of parameters that give good playability. I don't know if this'll work, but front-loading the testing could give significant benefits IMO.

[Mark_Everson]

These are good points, and I agree with them. I hadn't thought about the idea of using java itself, and think its quite good. We could even make limited "example" modules available.

Yes, we will have to do 2 soon. But we need to finalize the design of the various game modules first.

-Mark

[manurein]

About sytem design and organization :

what I give u here are generic methods used in industry for complex projects of any nature (and I think whatever choices we make, Clash WILL be a complex project).

The general idea is to have a hierarchical architecture for the project. This means dividing the project in several modules, and then if still too complex divide these modules in sub-modules... Until each module is manageable at a one-designer level.

Of course, the seperation between the modules and sub-modules has to be done very carefully, with cohesion and logic in mind.
Generally speaking, he division is "functional" (you group related functions in a module).
Well, I guess this is already what we tend to do with the different models...

Then, when this architecture clearly exists, the next step is to provide interfaces between the different modules. This is probably the most important step : as soon as the interfaces are clearly defined and specified, each module is considered as a "black-box". A black-box is an entity which u know the function and the interface, not how it is built. This way, each programmer/designer is entirely responsible of its own module, and as long as he doesn't change the specs of its interface, its module will fit in the architecture.

Thus we would end up with a system where the only configuration management we have to do is on the level of the interface, and where the programmers/designers are quite autonomous on their own module.

OK, more on the interfaces : in a word, (well, a few words, say...) the interface is the entry point(s) of the module. It has to be defined in terms of input and output parameters, with all the possible values and their meaning, and very importantly, all the exception (error) conditions and the way they are handled and propagated.

Well, the methods used in the industry (which are named SA-DT, SA-RT...) are very formal, this is not exactly what we need, but the genral idea could be a good departure point.
(Anyway, having a real, high-level architecture is IMO mandatory, we will go nowhere without it).

At any level of design, there also is a very classical but efficient method (although very general), called the V-cycle. Its drawn like this :

genral design/spec integration tests

detailed design unit test

coding

you descend the left branch : general design/specs/architecture --> detailed design (for each module) -->
coding (of each module)

Then u go up the right branch :
unit test (test of each module independantly) --> integration and integration test (test of the modules running with each other).

If u follow every step closely, u should come up with a quality thing.

One last point : in general, on big software projects, and for concerns of maintainability and evolveability, the people use naming conventions. In the particular case of Jva, I guess such a method already exists for naming classes. I have to check a little more, but it could be quite enough for now.

[F Smith]

AoE and SC have 'scenario editors', in which you can edit the map, tile by tile . Just click on the squares. You can also add any sprite or resource in the game, from gold mines to artifacts, from lions to neutral buildings.

Then the whole thing gets saved as a highly encoded file, but it can be easily modified, GUI-style, by anyone.

[This message has been edited by F Smith (edited May 19, 1999).]

[This message has been edited by F Smith (edited May 19, 1999).]

[Glak]

You didn't mention the triggers. The Starcraft editor had a system called triggers. It was sort of a simple point and click programming type of thing. I'm not a programmer so I don't know what it would be called. Basically if I want something to happen I break it up into causes and causes and effects.

Say I had an installation mission (indoors) and I wanted the player to have to find a key to open a door. First I would click on the button that says location layer. Now my terrain pallette disappears. I drag to make boxes called locations. They have some properties but mainly they are just places. So I would make a location around the key (named KEY) and a location around the door (named door).

Now I go to the triggers menu. I click make new trigger and determine who the trigger runs for (every ~2 seconds each players triggers are evaluated). Then I determine the conditions. For my first trigger I want two conditions: the player brings a guy to the location and that this is the first time, because you can't grab the key twice.

Since I am in the condition menu I hit new and it brings up a list of all the possible conditions. I choose BRINGS. Now I am in a section where I edit this BRINGS condition. I see a sentance where is says: "player" brings "how many" "units" to "location". The words in quotes look like links. So I hit "player" and select "active player" from the radio box. For "how many" I select "1 or more". For "units" I pick "any units" and for "location" I pick "KEY". Now the condition reads: active player brings 1 or more any unit to KEY. This condition is clear to everyone, not just programmers.

For the next condition I select "switch set". I replace words and rename the switch so that I get "key switch clear" as the condition. Switches start clear by default.

Next I move to actions. I select "set switch" and make it so that the action is "set key switch to set" The as another action I have it display text and play a wav (which then becomes part of the map file, most maps don't use sound because of size considerations, though it would be nice if you could specify a game sound to play).

Now for the door I make the conditions "key switch set" and "active player brings one or more any unit to DOOR". The action would be "toggle door state" or "disable (open) door" depending how I wanted the door to behave.

[Blade Runner]

The users have different knowledge about programing, but they all would like to change the system. (The biggest complain about the CTP the missing map and scenario editor.) We can provide maybe 3 levels for editing.
1. Map and scenario editor. A program which has an easy to use interface, but lack the very sophisticated possibilities.
2. Text files to modify (with description).
3. Java source files (with description), practically limitless.

Blade Runner