Triggers (split from A couple of suggestions)

[Kimball]

I don't mean to get too off track here (it seems like we're going in the direction of religion implementation), but I was sifting through the features cut from part 1 and something caught my eye. We should seriously reconsider the implementation of triggers in Atlas. They're the backbone of scenario design and open up a world of possibilities for designers.

[Pedro Falcão]

I don't mean to get too off track here (it seems like we're going in the direction of religion implementation), but I was sifting through the features cut from part 1 and something caught my eye. We should seriously reconsider the implementation of triggers in Atlas. They're the backbone of scenario design and open up a world of possibilities for designers.

I agree with you, Kimball. I frankly would rather see the game released late but with good scenarios/campaigns than a early multiplayer-only game.

Edited December 9, 2012 by Pedro Falcão

[Mythos_Ruler]

I agree with you, Kimball. I frankly would rather see the game released late but with good scenarios/campaigns than a early multiplayer-only game.

How "Late"? A year? Two years? Three years?

[Pedro Falcão]

How "Late"? A year? Two years? Three years?

I seriously don't think it matters, since we'll be able to play it anyways the whole time. The only difference is that the game receives the title of "complete". This is what i think.

[feneur]

I seriously don't think it matters, since we'll be able to play it anyways the whole time. The only difference is that the game receives the title of "complete". This is what i think.

Well, the only difference in triggers or not is that triggers wouldn't be included in the first "complete" version of the game, so it's not really a big difference in either direction.

The main reason why I think we should wait with including triggers is a technical one though. FeXoR has been talking about how nice it would be to do all kinds of things with triggers (search through his posts for a more indepth explanation of what he wants), and while I don't know all the technical details to be able to fully evaluate that idea I'm sure it would both be very valuable and require a lot of code to be rewritten/edited. And while some changes might be important enough to warrant a code rewrite even at this stage of development (the sound code rewrite for example was important as the old code didn't work at all on Macs), I don't think now is a good time to do something that could potentially require rewriting most of the game code.

Of course we could implement some quick and basic triggers in much shorter time, but then we'd probably have to redo that when we do a more indepth trigger implementation later, so to me it's better to wait and have it properly implemented when it's first implemented. I might be wrong, but I believe that will mean that we will have a better trigger system sooner than if we'd have a more basic system now and then implement something more indepth later.

I guess one of the less important reasons, but still a big influence, is that if we implement triggers we'll want to implement story-based scenarios/campaigns as well, and I think that would add several years overall to the development (in addition to the time it would take to implement the gameplay features, which could mean something like 5-7 years or something in total before we get a full version).

And all in all I think having a full version out/working towards a full version is both a big accomplishment (partly nice as a personal accomplishment - to have been part of a finished game rather than a perpetual WIP, and partly nice as a testament to the strength of the community and open source development), and an important step forward (there's less incentive to work on performance if we know we're going to add a lot of new features, having a more clearly defined goal makes it easier to see progress - which in turn can help encourage progress as people are motivated when they see progress, and having a full version out is likely to give the game more credibility - which in turn might have positive effects such as Linux distributions adding 0 A.D. in their main repository, other distribution channels opening up which would mean more publicity for the game, and hopefully attracting skilled contributors who can help improving the game, so I think that might be argument enough to not include something as major as triggers in the first version.

A long post, but the main point is: The first "full version" is just the beginning of what 0 A.D. can become

(A minor additional argument to leave triggers/story-based scenarios/campaigns to the future is that they can work well with other features which are very much up for consideration to be included then. Like morale for units, supply/attrition, etc etc.)

[Kimball]

I guess one of the less important reasons, but still a big influence, is that if we implement triggers we'll want to implement story-based scenarios/campaigns as well, and I think that would add several years overall to the development (in addition to the time it would take to implement the gameplay features, which could mean something like 5-7 years or something in total before we get a full version).

Although I agree that this is a less important reason, I think you'd be surprised at how quickly we'd be able to find incredibly talented scenario designers with a powerful enough map editor. Even basic functionality would attract all sorts of talent, and I don't think a campaign-less historical RTS is really reaching 0 A.D.'s full potential. This isn't Counter Strike - people are here for the experience. And if the game is released with an inadequate trigger system, Open Source may come save the day with a dedicated fan to help take the system to new heights. Eventually, part 2 may require an overhaul rewrite, but it's important to have that first iteration to attract the kinds of fans that will make this game great.

AOM/AOK survived long past their expiration dates because of their design communities, and that's largely due to the fact that they put a lot of work into making sure the map editor was ground breaking, fully featured, and fun to use. Although we're not a AAA-title producing company, I don't think we should limit our aspirations.

As Pedro said, people will be playing the game the whole time this is being worked on, so it's not like the community loses anything from the game taking longer to complete.

[Mythos_Ruler]

A "complete" 1.0 release is whatever we deem it is. To me, triggers aren't necessary for a complete release. The 1.0 release does not need to be the most awesomest RTS ever. We would need to start thinking outside the box in order to include things like a full set of triggers, cut scenes, voice acting, narrative campaigns, and the like before we all reach retirement age. Outside of the box means hiring on some team members at full-time for the next 2 years. One or more artists/designers, one or more programmers, and maybe a management person. It can be done, we'd just have to raise the money. I have no doubt we could raise the funds. Crowd-sourcing is all the rage these days. It's just finding the right people is the problem. I could be one of the artists/designers, but we'd still need one or more programmers for it to work.

[zoot]

Kimball, could you write a paragraph or two about what you understand by triggers? I can't really follow these estimates saying it will add years of development, but maybe you're all talking about something different than I am.

[Kimball]

For those that don't know exactly what we're talking about, a trigger is essentially a script event that controls actions in a scenario.

They're based on "Conditions" and "Effects" (i.e. if/then) that are defined in the scenario editor (Atlas, in our case). When a condition or set of conditions is met, an effect is fired. A condition can be anything, such as:

• Distance to Point
  
• Unit is Alive
  
• Player at Popcap
  
• Unit Selected
  
• Unit in LOS
  
• Always (fires immediately - triggers can fire other triggers)
  

If the condition(s) are met, the effect results. Effects are generally more complex, and there are many more of them, such as:

• Army Move/Deploy/Teleport/Kill/Flash/Train/Garrison/Formation/Mine/Farm etc. etc.
  
• Advance Campaign (advances to next scenario in a campaign track)
  
• Cinematic Mode (black bars, GUI shuts off)
  
• Camera track (for cinematics)
  
• Counter add unit/stop/pause/subtract etc.
  
• Flash UI category/tech/train etc.
  
• Set Animation/Music/Lighting
  
• Send Chat
  
• Reveal Map
  
• You Win/Lose
  

As you can see, this opens up a wide variety of possibilities for scenario designers - it is the building blocks of interactive campaigns (and it's the same tool that Ensemble Studios used to create their "official" campaigns). Furthermore, triggers are not limited to one condition and one effect (at least, this is how they functioned in the AoE/AoM franchise). The implications are limitless.

The advantage is that a player doesn't need to know a scripting language to script events in a scenario/campaign to write them, since everything is interface-based.

It doesn't take a lot of thought to realize that it's a vast undertaking, but it also doesn't take a lot to see how much value triggers can provide for us and our community. The AoK community lasted over a decade because players were obsessed with creating new worlds and stories for others to experience. I'm not saying that ours will die without it, but having at least a rudimentary form of map event scripting (even if we don't have interface-based triggers) will inspire our community beyond any one person's imagination. It will also enable us to develop a compelling campaign to associate with the current game (don't worry about staffing - that's by far the easiest part when it comes to scenario design).

So yes, it would be really difficult. Yes, it might add several months to the development track (I'm not a programmer, so I can't be sure of the real estimates here). But the benefits outweigh the costs in this case. That's why I think we should reconsider striking triggers from part 1.

If we decide triggers are too much, we should at least consider some sort of script language for map events so the more tech savvy among us can make their maps come to life. The interface itself can come later if that's a hang up.

TL;DR: triggers are interface-based map event scripting

[zoot]

Yeah, I don't see a years work in that at all. The main thing I would need to get started is some way of storing the trigger definitions in the scenario file and some way to load them into the simulation. I'll see if anything along those lines already exists...

[fabio]

Triggers are already implemented in the tutorial AI: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/ai/tutorial-ai/introductory_tutorial.js

[zoot]

Triggers are already implemented in the tutorial AI: http://trac.wildfire...ory_tutorial.js

Looks more like a script than triggers stored in the map itself.

[Mythos_Ruler]

Yeah, I don't see a years work in that at all. The main thing I would need to get started is some way of storing the trigger definitions in the scenario file and some way to load them into the simulation. I'll see if anything along those lines already exists...

The years of work come in creating the content expected after triggers are implemented.

[zoot]

The years of work come in creating the content expected after triggers are implemented.

"Expected"? By whom?

[Kimball]

If the issue is the campaigns that would theoretically result and not the triggers themselves, why was this feature cut in the first place? That seems incredibly irrational.

If there's a different reason though, I'll get off my soap box.

[zoot]

The main thing I would need to get started is some way of storing the trigger definitions in the scenario file and some way to load them into the simulation. I'll see if anything along those lines already exists...

I could probably extend the scenario XML to contain a "Triggers" element with some JSON in it. Any objections?

[quantumstate]

I think it would be better to allow a more flexible trigger system with pieces of actual javascript allowed. For the more fancy scenarios this would make things easier.

A agree that a trigger system would be quite easy to implement. The concern I have is that building such a system will lock us into backwards compatibility troubles. If we release a trigger system with part 1 but then decide that actually it isn't the best design will we be able to change it once a whole set of maps depend on it? My initial reaction is to go for implementing the system though.

I agree that the argument about it delaying the release because we will somehow be forced to implement a trigger based campaign is weak. We can just release a game with the possibility for campaigns without actually having any. Campaigns are very easy to add since they don't affect multiplayer compatibility at all so players can install them at will.

[Kimball]

The concern I have is that building such a system will lock us into backwards compatibility troubles. If we release a trigger system with part 1 but then decide that actually it isn't the best design will we be able to change it once a whole set of maps depend on it? My initial reaction is to go for implementing the system though.

You bring up a good point about maps becoming obsolete if we change the system. Remember that I know nothing about programming when I ask: how difficult would it be to develop a conversion tool that would hypothetically change old trigger script into the new version? I realize it depends on the changes, but if something like that is possible, this problem could be avoided relatively easily.

[Mythos_Ruler]

Well, if people are asking only for triggers, then that shouldn't be a problem. We just don't have the manpower to create actual narrative campaigns and folks just need to accept that. I suspect though we'll still get post after post asking why we haven't included a campaign.

[Pedro Falcão]

Well, with a good trigger system, anyone can make campaigns. If we look through this forum, there are already many ready to contribute with campaigns, scenarios, the team will only have to decide if/which of them will be included within the game.

[Lion.Kanzen]

Well, if people are asking only for triggers, then that shouldn't be a problem. We just don't have the manpower to create actual narrative campaigns and folks just need to accept that. I suspect though we'll still get post after post asking why we haven't included a campaign.

what is most possible? a total war type campaing(strategy map per turns) or narrative?

[Pedro Falcão]

what is most possible? a total war type campaing(strategy map per turns) or narrative?

Steps to make a Total War campaign (roughly):

- Set the start date/turn and the end date/turn.

- Build the overall map

- Program the game to make it affect the map according to the outcome of the battles (probably the most time consuming)

- Script a handful of special events (e.g. discovery of the iron: players can now make units that use iron weapons/armor)

- Build the scenarios of the battles

Steps to make a Narrative campaign (roughly):

- Choose the story carefully and what moments will be depicted (maybe make a storyboard?)

- Create the dialogues and missions

- Create the scenarios

- Introduce the missions/dialogues/cinematics to the scenarios and adapt them to the comfort/fun of the player (probably the most time consuming)

Note that most likely, both will use triggers. At least to make campaigns like RoN's ones, you'd need triggers.

[FeXoR]

I'm not sure if we all have the same understanding of triggers.

For me the following thing should be possible in javascript e.g. added to a random map:

A trigger should consist of an even, likely a string like "aUnitDealsDamage", a condition (not required IMO but this is how it's mostly done) like (unitTypeOf(damagedUnit) == "units/athen_infantry_spearman"), and the code that is executed when this trigger event happens and the condition is true.

To enable trigger events nearly every game relevant function in the game (for the example the function handling damage dealing) engine has to be extended by adding the event calls.

To enable helpful conditions some variables (like "damagedUnit") has to be stored before the trigger event calls all the functions added to this type of event on the javascript side. That variables has to be accessible by the javascript side for the later called code.

The code evaluated after the trigger event took place and the condition was true has to do things with the engine again (like setMaxHitpointsOfUnit(damagedUnit, 2*getMaxHitpointsOfUnit(damagedUnit)) or something like that).

I know this example is stupid. The result would be: If a athen infantry spearman is attack his maximum life is set to twice the maximum life it had before the attack (not the actual hitpoints, so it still might die by the attack). That would simulate that units get tougher by having combat experience. But as it is this is done by ranks (which is OK but badly interferes with the unit type for triggers (if just taken from the actual template name) as the unit type string differs dependent of it's rank like "athen_infantry_spearman_b" or "athen_infantry_spearman_c").

I don't see why this should be a small amount of work.

I strongly suggest to start ASAP because this feature is so powerful and many things otherwise done ugly (like with mods) and about the same time-consuming to implement can then all be done in the map it's wanted for without interfering with the other maps. For random maps it would be just part of the random map code (that would then be evaluated during game time though, quite a lot of work as well). I don't know how fixed maps are loaded/to edit with an text editor but I doubt it would be easy for them as well..

BTW: When adding triggers it would be a good point to think about the used srcipting language. I'd personally prefer Python.

P.S.: My girlfriend said it as: "Powerful triggers for computer games equals life extending potions for the joy gained by playing them!". I can only say: THX!

Edited December 11, 2012 by FeXoR

[zoot]

I'm not sure if we all have the same understanding of triggers.

For me the following thing should be possible in javascript e.g. added to a random map:

A trigger should consist of an even, likely a string like "aUnitDealsDamage", a condition (not required IMO but this is how it's mostly done) like (unitTypeOf(damagedUnit) == "units/athen_infantry_spearman"), and the code that is executed when this trigger event happens and the condition is true.

To enable trigger events nearly every game relevant function in the game (for the example the function handling damage dealing) engine has to be extended by adding the event calls.

To enable helpful conditions some variables (like "damagedUnit") has to be stored before the trigger event calls all the functions added to this type of event on the javascript side. That variables has to be accessible by the javascript side for the later called code.

The code evaluated after the trigger event took place and the condition was true has to do things with the engine again (like setMaxHitpointsOfUnit(damagedUnit, 2*getMaxHitpointsOfUnit(damagedUnit)) or something like that).

Why not do this with normal simulation scripting?

BTW: When adding triggers it would be a good point to think about the used srcipting language. I'd personally prefer Python.

Adding a dependency on yet another scripting library when we already have SpiderMonkey == madness and/or SPARTA!

[Pedro Falcão]

When we talk about triggers, what (basically) comes to my mind is the possibility to make a certain scenario follow a script, through if/then/else cases. You'll call me dumb if it's not what you mean, but what i understood from your post is this. If true, then i must agree that it's not a small task, but as i envision it, it's not that big either.

BTW, thanks for the good will, zoot.