ICQ Meeting on macro/scenario stuff vs. code structure; JimC, Blade Runner, you in?

[Mark_Everson]

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.

[Blade Runner]

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

[Blade Runner]

Ups..
component = Java bean

Blade

[Mark_Everson]

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...

[mca]

[mca2]
re bl3

Could this "filtering" be accomplished with a SecurityManager?

Martin

[Blade Runner]

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).]

[JimC]

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

[JimC]

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

[mca]

[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

[Blade Runner]

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

[JimC]

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

[Blade Runner]

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).]

[mca]

[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

[Mark_Everson]

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).]

[Blade Runner]

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