02-09-1999 22:06									#1
	ICQ Meeting on macro/scenario stuff vs. code structure; JimC, Blade Runner, you in? Full PM-box? Change here!

Hi All:

The need for this meeting has become apparent from the recent threads, Coding organization for Clash, and Documentation for the code so far..., and the Macro language description thread.

IMO we need to discuss the macro language we're going to use, and how we are going to support it in the main game code.

I think the best thing to do, is to get us together for an ICQ chat over the weekend and hash this out. I would also like to have myself, Blade Runner, F_Smith, mca, and JimC (for general knowledge about java capabilities and speed of execution issues) there if we all can make it. Any other serious java Gurus that happen to check in here would be welcome too .

(If some of you don't have ICQ, you can get it at www.icq.com for free)

I would like everybody listed to post the times they are available over the weekend, and we will try to put it together. This is a holiday weekend in the states, so this may not work... but we'll see .

I am available most of the weekend from 9-22:00 EST (GMT +5)

We just need to talk the issues thru and take note of strengths and weaknesses of each approach talked about in the threads above. (and any other possibilities people want to bring up) For the cases where we don't know the real value / limitations of a particular approach, we'll have to design some simple tests to evaluate those issues soon.

We need to put this decision behind us quickly, or we're going to risk wasting a Lot of coding time.


Specifically, some ideas presented have been (see the threads for more info):

A C-like macro language

Using XML as the macro language

The notion of using reflection to make generic getters and setters in the code that would interface easily with a macro language.

Using a java bean architecture for the code.


I hope everyone can make it...

-Mark

[This message has been edited by Mark_Everson (edited September 02, 1999).]

	02-09-1999 22:52									#2
	Browse Apolyton AD-FREE

I am available from 04 to 16 (Apolyton time) on Saturday and Sunday.

Martin
[This message has been edited by mca (edited September 02, 1999).]

	03-09-1999 23:06									#3
	Support Apolyton, buy Civilization: The Boardgame

My ICQ no. is 15227822. I'll try and be there.

Maybe I'll just stay in bed all day.... and all week.... 'cos I finished work today :-)

Two weeks of blissful nothingness until my University term starts. My brain deserves a well earned break from damned SCADA programming.

Jim

	04-09-1999 00:55									#4
	Increase the size of your Attachments

Hi All,

I try to get ICQ, but my stupid sound card driver always kick out the ICQ program in the starting period. I cannot get in to the ICQ chat. (The sound card built-in.) I got back my cable modem connection today, so I can hanging around longer time than before.
Anyway. I'm in Europe, so the time different is huge. I send my opinion now, and Mark, please send the chat description to the forum, so we can follow the discussion.
Thanx

We need to produce a macro language, which easy to use, but enough powerfull to build scenarios, and control completely the game system. Maybe we can write parts of the game system with this macro language. Very easy to implement a text file reader to load values in the game system. (a little bit like the SMAC or CIVs). Maybe 1-5% of the gamers can write something with the scenario language, but almost everybody can change something in text files. (like not 5 but 8 civs, etc.)

Macro language:
1. No OOP, or any other sophisticated gadget. The average gamer can maybe produce a short rutin with Visual Basic or Access, but they dont understand C++, Java or Delphi.
2. For little programs and rutins the best to use a structured language. Easy to follow the flow of the code, and easy to understand what do the macro rutin and why.
3. We need to follow the popular languages. IMHO the most popular structured languages are: Pascal or C. I work professionaly with Delphi, so I prefer Pascal, but the C has also strong points.
4. Events (or triggers) must easy to follow for the users. My idea was to use the trigger name for the source code, and for the "main" function or procedure (method in Java).
(Read my short language description: follow the URL of "Macro language description" in Mark's beginnig post.)
Rem. If we agree to use my C-- baby, I try to produce a working tokenizer and parser ASAP. This will take a couple of weeks (2-6). All the language specialities go to this part. The another part of the interpreter (the executor) takes a few days plus. But the speed of the code is depend on the executor, so we need probably a few another weeks to produce a speedy executor. (permamnet feedback and code optimizing)

I. Program structure and macro language:
1. We need to produce the graphics and AI part of the game in Java. We need to write a speedy macro interpreter and the macro interface programs and message boxes, menus, etc. in Java too.
2. We (and this is a bigger part of the project members) can write the control and rule parts of the game in our macro language.
3. The ultimate game "constants" can go to text file(s).

I see a few advantage and one disadvantage. (Probably there is more.):

Adv:
1.Flexibile game development.
2.Half professional programers can help us easily, but they cannot touch the Java parts of the program.
3.We can detect and kill the bugs of the macro interpreter in early stages. (and not the users will send us nasty comments about the scenario maker part.)
4. The users can examine our working scenario model (The Game!). They can modify the program or write scenario(s) follow our code.

Disadv:
The game system will be slower than a 100% Java application.
(Rem: We (I) try to develop a quick interpreter. I hope the interpreter part will be enogh speedy to open the choice of use Java or C-- [my fantasy name for the macro language] for coding.)


II. Program structure and the Java bean:
I'm a Delphi programmer. I write always Delphi components for my longer applications, so I support the using of the Java beans for Clash too. (The use of the Java beans almost automaticall solve the getter setter problems too.)

Blade

PS. I think I cannot join to the ICQ chat without workong ICQ program. If somebody know a different way to join or has an older version of the ICQ program (that maybe work for me) send me a message (or the ICQ program).
Thanx



[This message has been edited by Blade Runner (edited September 03, 1999).]

	04-09-1999 02:42									#5
	Support Apolyton

Please use my hotmail address to send messages: gkosztolanyi@hotmail.com

Thankx

Blade

	04-09-1999 03:34									#6
	Lose 30 kilos (of popups)

Hmmmm... I had assumed everyone could do ICQ. But I think we need Blade Runner in this discussion.

How about we do the discussion here?

It would be a bit less fluid than ICQ, but we can clearly get everyone involved. Also it would leave a record that others could easily see and comment upon. And Finally BR has already given us a good overview of his position to start out the discussion.

If anyone objects, please speak up, or I'll assume we'll do it here.

I propose we start In this thread at 13:00 Saturday EST (GMT +5) Is this ok with everyone?

If that time is a show-stopper for anyone, please speak up!

I hope to see everyone there.

	04-09-1999 04:02									#7
	Support Apolyton, buy Civilization: The Boardgame

Good for me. Thankx for the possibility to join.

Blade

	04-09-1999 07:39									#8
	Support Apolyton, buy Alpha Centauri

I'm not a Java programmer at all... but I'll try to be here anyhow. [At least so you'll have somebody to point at and laugh ]

One preliminary comment, tho:

The purpose of using a 'macro' language is: [pick one or more]
a) to make the logic accessable to the player
or
b) to allow changes "in between" releases while we're debugging
or
c) to let programmers OUTSIDE the project do add-ons later.

If (a) is among your answers, then I suggest that C or Pascal is not the right choice for a base. If you need to be a programmer to write the macro, what's the point in making it a macro? Just put it in code and do not pay the speed penalty....
We're going to have open code anyhow.. so just put all the "macro" stuff in a separate module and let the programmers roll their own.

	04-09-1999 13:32									#9
	Lose 30 kilos (of popups)

Personally I think they're all valuable but rate a > c > b. However Most of 'a' could be handled in an editor IMO.

On the 'open code' argument against a macro language being needed, I still don't think we've determined whether Clash should be completely open once development nears completion or not. However, this is not the thread to continue That discussion. If you want to talk about it go to Open Source vs Quasi-Open (what we're doing now). We only got a few votes in that thread a ways back, tho it seems to be pro-open so far in the thread. However, private messages from some who didn't contribute go the other way...

	04-09-1999 18:31									#10
	Support Apolyton, buy GURPS/ Alpha Centauri

I'll be around, too.

Martin

	04-09-1999 22:20									#11
	Put an end to popups!

Post Me2

Here are some specifics on the off-line editing program capabilities that I think we need. First and foremost, is a rational way to access all the variables that the scenario designer might want to change. I think this would be best gone using an interconnected tree that allows the user control down to any level in any object.

We could use Java's reflection capability to do this fairly easily. So at the top of the tree hierarchy would be the game object (I'm using F _ Smith's proposed structure with my names on it). I will just show a single extended branch of this very big tree.

Game
|
civs; map; turnHandler; gui; io; etc.
|
Babylonians; Romans; Indians; etc.
|
AI characteristics; map (parts known of/controlled by); task forces; diplomacy; etc.
|
military aggressiveness (53); technology preference (farming 38, metallurgy 75, etc.)

Add a few logic and loop capabilities to a system like this that allows you to access anything, and you have a pretty powerful scenario design tool.

Since nobody else seems to have made it yet I'm going to step away for about 15 min. Will return...

[This message has been edited by Mark_Everson (edited September 04, 1999).]

	04-09-1999 22:37									#12
	Remove this text

(Sorry for being late, I miscalculated the time zones)

mca1:
re: me2

Such a tree-based editor will be quite useful for game and ai parameters, but I'm not quite sure how logic and loop capabilities could be incorporated.

The main use for control structures is in a "triggered event" system, I suppose?

Martin
[This message has been edited by mca (edited September 04, 1999).]

	04-09-1999 22:48									#13
	Support Apolyton buy from Amazon

Post Bl1
Re: Me2

Hi,

I'm here.

This data can go to the text files. I think we need something more powerfull tool. It is possible to write loops and control stuff in the game system, but I think that will be more difficult to implement than a macro language with interpreter.
I.E.:

How can we produce a scenario editor modul to implement the next rutin without language?

If ((CivNumber > 5) and (CivNam = Badguys))
{
X = 1;
while MapSquare[X,15] <> CitySquare do
{
Destroy(MapSquare[X,15]);
X++;
}
};

(This is a user defined weapon, which destroy everything in the map row until find a city.)

Blade
[This message has been edited by Blade Runner (edited September 04, 1999).]

	04-09-1999 22:50									#14
	Support Apolyton buy from Amazon

Warning: If you post the same minute as someone else it seems to not take your post! I just mention it so everyone is aware of that. It is easy enough if it doesn't show up in the thread after the post to use the browser's 'back' button to go back and re-post...

Post me3:
re-mca 1

Triggering is is one important use of logic and loops. Another would be simple tweaking of the AI for the general game. For instance, if someone thinks our AI is too timid under a certain set of circumstances, they could cause the AIs military aggressiveness for a civ presented with those circumstances to be increased. I'm sure there are also other uses we could come up with.

re-BR1:
Yes that's true. As I said, we probably need a macro language to save stuff from the off-line editor program anyway. I just think we can cover 99+% of what people want to do with an editor.

[This message has been edited by Mark_Everson (edited September 04, 1999).]

	04-09-1999 23:04									#15
	Support Apolyton or Terrorists Win

Bl2
Re: Me3

Sure. 90% - 10% rule:
The users 90% use the 10% of the program, 10% use the 90% of the program, but nobody know which is the unnecesary 10% of the system. The program needs a powerful scenario editor, text files with game constants and a full featured macro language for us and for the power users.

Blade

	04-09-1999 23:08									#16
	Support Apolyton buy from Amazon

me4
re-bl2

Have you thought about the coding practices we need to use so that the macro language can 'talk' to the code. Reflection seems to be the way to go, with each parameter having its own getter and setter methods. I just don't know much about reflection at the moment.

	04-09-1999 23:16									#17
	Got spare money?

Bl3
Re: Me4

If we use (I hope this will be majority opinion) Java beans, the users cannot punch the Java code from the Macro language side. The components have special interface part. The developpers can enable or disable and filter every input. I need the interface description to send the input. The java programmer has all the possibilities to catch any input calling which dangerous.

Blade

	04-09-1999 23:18									#18
	Full PM-box? Change here!

Ups..
component = Java bean

Blade

	04-09-1999 23:25									#19
	Full PM-box? Change here!

me5
re: bl3

Do you know what's involved in changing 'normal' java code over to a bean format? I hope its not too complicated since some of our programmers are new to java...

	04-09-1999 23:31									#20
	Support Apolyton buy from Amazon

[mca2]
re bl3

Could this "filtering" be accomplished with a SecurityManager?

Martin

	04-09-1999 23:32									#21
	Support Apolyton, buy Alpha Centauri

Blade4
Re: Me1..4
(A little longer)

IMHO we can start to develop the game with Java beens:
Adv:
Every component looks lile a black box nobady can and nobady need to touch the inner parts. Zou can send information for the component to call the set or get functions or the common methodes. The component developper needs to check if the input datas are in the valid range, or the method calling are valid. The main program practically just calls the components in order. IMHO this part of the game can be a macro language - macro interpreter combination. For the average users we need to implement a map and basic modification editor. Probably better to hide the basic text file information too. We can write a short program to set the game variables with valid values. So the gamer cannot smash the system with invalid values.

Blade
[This message has been edited by Blade Runner (edited September 04, 1999).]

	04-09-1999 23:36									#22
	Support Apolyton, pre-order Civilization IV

I personally don't think that the choice of language / exact syntax is the most important issue.

The major things we need to discuss before choosing a language are:

- what program control structures are we going to allow? (for/while loops, if/else statements etc.)

- what data structures are we going to allow access to?

- what 'routines / methods' are we going to provide?

Jim

	04-09-1999 23:40									#23
	Support Apolyton buy from Amazon

ooops I forgot - what logical operators are we going to allow?

e.g. the Starcraft editor seems to force you to AND all of your conditions together - there is no provision for OR, NOT etc...

if you want to use OR, you have to write a whole new trigger, and the editor provides you with 'opposite' conditions where possible to replace NOT

Jim

	04-09-1999 23:40									#24
	Support Apolyton

[mca3]

Well, I'll just try to describe the system I envision from the discussions here, and my own point of view.

We'll have basically a bunch of text (and gfx) files, front-ended by some editor, so the scenario builders can modify the static game data (the map, terrain types, unit types, ai parameters, civilizations, tech tree). This will cover most players' needs as Mark says.

Then, for advanced scenario builders, there will be scripting capabilities to define triggering and custom effects for weapons and technologies. I.e. stuff that dynamically effect the game state, but doesn't modify any of the underlying game models or the AI.

I'm not quite sure what to do for hardcore Clash hackers, who want to tinker with the AI and game models beyond just setting the parameters, except to expose the Java code and allow modified models to be pluggable.

Martin

	04-09-1999 23:42									#25
	Support Apolyton, buy Call to Power 2

Bl5
Re: Mca2

No. The rule is very easy nobady never touch a variable inside a component. There is setter and getter methods. The component developper must check inside the setter method if the variable is valid. If valid OK if not the component can send error message or do nothing or enything else, which is fit for the system.

Re: Me5

The component developping is just a logic step forward to the OOP. With the normal OOP evevrybody can tappering your public variables, so you never sure which is the value, Wth the component developping you can control ALL of your variables. The methods and other stuff can go without changes. In my practice to change from OOP to component is less work than what the ones can spare time in the debug stages.

Blade

	04-09-1999 23:47									#26
	Full PM-box? Change here!

Pluggable AI(for advanced Java users): simple....

Java's class files are v. convenient (if we aren't going to compile to native code, that is)

Simply issue the specs (data + methods) for the AIRoutine class or whatever it's going to be called, and then the keen AI hacker can simply write his own class, compile it and plug it in.

Et voila.

Jim

	04-09-1999 23:52									#27
	Support Apolyton, buy Civilization 2

Or better: They can to join to produce the killer app CoC II. (Clash of Civilizations II)

Blade
[This message has been edited by Blade Runner (edited September 04, 1999).]

	04-09-1999 23:54									#28
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

[mca4]
re: bl5

Aha, my thoughts were circling around using reflection to invoke the methods on the components, and to prevent the macros to access something in the game they shouldn't.

Martin

	04-09-1999 23:55									#29
	Get a bigger avatar today!

me6

So we seem to be in fair agreement (let me know if I have misconstrued this). I will just restate to make sure it is so. As said mostly in mca3 we have 3 levels:

1. Standard scenario handling - off-line edit program with access to pretty much all 'standard' data (and possibly simple logic for triggers). Is my sketch above in me2 reasonable, or does it need modifications?

2. Advanced Scenario Capability - Macro Language that can dynamically change program data, exact nature TBD.

3. Serious Hacking of Clash - Use Java (either we: 1) make method and data descriptions available and let them take it from there, overriding what they will, or 2) make code generally avail., or 3) require Serious Hackers to join the team). Which choice(s) of 1-3 are best?


[This message has been edited by Mark_Everson (edited September 04, 1999).]

	05-09-1999 00:00									#30
	Full PM-box? Change here!

Bl6
Re: JimC

I hope we neednt produce native code. I saw today the new Athlon (K-7) proc. datasheet. The next year every java program will run like a full optimized C++ 2 years ago.

Blade