Topic: Standardized Mission Architecture

[Karnak]

Standardized Mission Architecture for SFC2 API Programming

Author:  el-Karnak, koshnaranek2002@yahoo.com

1.0 Abstract
The purpose of this ongoing document is formalizing a consistent set of mission design for scripts used by SFC2:EAW and SFC2:OP.   By establishing homogeneous standards the goal of achieving more user-friendly and robustly coded scripts will resul in contrast to the missions currently experience in D2 dyna play.

Many of the items detailed in this document are already being done by the active mission scripters of the SFC series of games developed by Taldren, inc.  The guidelines are meant to be suggestions based on my personal experience in dyna campaigns both as a player and as a mission script developer.  Many thanks go out to the RMs and Admins that took the time to patiently give feedback to many and verbose inquiries.

This document consists of two sections:

First, detailed in section 2.0, a specific classes of missions that achieve clearly defined purposes without negatively impacting the quality of dyna play through too many connection drops, mission crashes and anomalous AI generation in-mission.

Second, detailed in section 3.0, establish a standardized mission template that will be common in all missions produced so that the user experiences a similar standard of code quality and robustness.

In addition, it is the responsibility of the script writer to unit test their code as much as possible before releasing even a beta version to any server admin. for dyna use.  The hope is that the following guidelines regarding mission scripting standards will help the scripter in developing robust mission scripts.  In the future, the author hopes that new items can be added to this document

2.0 Mission Class Descriptions
2.1 Patrol Class missions
Patrol-class missions are designed to fulfill the role of the most common usage missions for the dyna campaign and will have the following features:

·   They can appear in any terrain type hexes.
·   They can neither be too easy nor too hard.  New players should be able to succeed in these missions after a few days of play in a minimum CA-class ship.  
·   Common priority setting would be 3.
·   Mission times for the average player should not exceed 3 to 8 minute range.
·   Robustness is the key word for these missions since they will be, by far, the most heavily used missions in any dyna campaign.
·   To reduction the likelihood of connection drops, the maximum number of ships for these missions is 6.
·   The features used in these missions should be standardized as much as possible between the various active mission script writers so as to achieve a common level of integrity in mission play for the user.
·   The script writer should heavily test them before being released to any server admin. for dyna play.
·   Active consultation with RMs and Admins. during mission script development regarding game balance and specific test cases is highly recommended.

Example Patrol-class mission from EEK:

·   Deep Space Patrol (1v1)
·   Enemy Sweep Patrol (2v2)
·   Joint Ops. Patrol (2v2)
·   Skirmish Patrol (3v3)
·   Combined Arms Patrol (3v3)

2.2 Action Class missions
Action-class missions are designed to fulfill the more challenging role of missions in a dyna campaign and will have the following features:

·   These missions will be localized to a specified type of terrain (ie. A range of hexes pinned on a planet or base, for example) so as to never appear in anywhere close to the frequency of the Patrol-class missions.
·   Since these missions are localized to certain areas of the dyna map, it is possible for these missions to have higher priority than Patrol-class missions (common usage priority would be 2).
·   These missions can range from medium to extreme difficulty.  Even veteran players will find these missions both challenging and fun.
·   Mission times for the average player should not exceed 8 to 15 minute time range.
·    Robustness is vital in these missions. Even more so, because the player will take longer to finish these missions than would be the case for Patrol-class missions.
·   Any number of ships can be used; however, the scripter should try to bear in mind what total of AI will cause severe lag problems for the average user.
·   They should be heavily tested by the script writer before being released to any server admin. for dyna play. Even more so than Patrol-class mission, because the player will take longer to finish these mission.
·   Active consultation with RMs and Admins. during mission script development regarding game balance and specific test cases is highly recommended.

Example Action-class EEK missions:

·   Squadron Action
·   Fleet Action

2.3 Stationary Class Missions
These type of missions focus on a specific target such as bases and planets and will have the following features:

·   Only accessible in base or planet hexes.
·   The high importance of the hexes that these missions appear in, dictate a high priority requirement (common usage priority would be 1).
·   Since many, if not all, base and planet hexes have Victory Condition (VC) or high Economic/Strategic value, the difficulty of these mission should be high; bordering on the need for players to Co-op in order to succeed in a 10 minute time frame.  A veteran player should be able to succeed in-mission within 30 minutes.
·   Robustness is vital in these missions. Even more so, because the player will take longer to finish these missions than would be the case for Patrol-class missions.
·   Any number of ships can be used; however, the scripter should try to bear in mind what total of AI will cause severe lag problems for the average user.
·   They should be heavily tested by the script writer before being released to any server admin. for dyna play. Even more so than Patrol-class mission, because the player will take longer to finish these mission.
·   The mission goal is quite straight-forward so little consultation with RMs and Admins. during mission script development regarding game balance and specific test cases is anticipated.

Example NW (NuclearWessels) Stationary-class Missions

·   NW Planetary Assault
·   NW Planetary Defence
·   NW Base Assault
·   NW Base Defence

2.4 Special Class Missions
These missions are the domains of the scripter?s most imaginative inspirations. There are really no specific guidelines to follow except for the following minimum standard requirements to ensure mission robustness and proper campaign mission flow.

·   Special mission are meant to not show up as often as any other class of mission so the common usage priority would be 4.
·   Robustness is, of course, vital in these missions. Even more so, because the player may take longer to finish these missions than would be the case for Patrol-class missions.
·   Any number of ships can be used; however, the scripter should try to bear in mind what total of AI will cause severe lag problems for the average user.
·   They should be heavily tested by the script writer before being released to any server admin. for dyna play. Even more so than Patrol-class mission, because the player will take longer to finish these mission.
·   Little to no consultation with RMs and Admins is anticipated.  The scripter is free to do as he/she wishes with only common sense as their guide. In many cases, the Admins. will request a specific special mission designed only for their campaign.

Example EEK Special-class Mission

·   Pirate Base Assault

2.6 Certifying a New Mission for Production Dynas
Already, many missions are already being tested out and validated on test server generously put up by many server administrators.  The section merely formalizes the process where no new mission should be certified for a production dyna release (ie. serious 4 to 6 week campaign) until it is has been properly validated in a minimum 2-week mini-campaign.

2.7  Freeware
It is suggested by many server admins. that scripters share their knowledge with each other for the overall benefit of the SFC community.

3.0 Standard Mission Features
The goal of this section is not to dictate a specific set of features for all the scripters but mainly to set a specific set of guidelines that have be confirmed to robustly work in EEK missions.  In addition, the majority of the playerbase has asked many of these features be implemented for quite some time based on my SG3 Admin experience.  Of course, each scripter is free to do as he/she wishes, but it is hoped these guidelines will serve some benefit nevertheless.
3.1 Ship-based Features

1.   The player?s ship will automatically go to Red Alert status at the mission?s 1 second mark.

2.   Regulation of spare use to reduce to usage of a ?second? or even ?third? set of ship internals in mission play. In any mission, the maximum spares available on a player's primary ship will be based on the following schedule based on ship class:

a.   Freighters:               8
b.   Frigates/Destroyers:         10
c.   Light Cruisers:         12
d.   Heavy Cruisers/New Heavy Cruisers:   14
e.   Heavy Battle Cruiser:         16
f.   Carrier/Dreadnoughts:         18
g.   Battleship:            20
h.   Any other class:         14

Any surplus spares that exceed the above limits on a player?s ship will not be available in-mission, but instead returned at mission?s end; if the player?s ship survived the mission.

3.   All enemy AIs will be given the maximum T-bomb load available as specified for the ship in the shiplist.txt file.  All enemy AIs   will also receive a Spares compliment equal to 25% more than scheduled amount, as detailed in sub-section 2 above, for the given Enemy AI?s ship class.

4.   Officer ranks that are programmatically set for Enemy AI ships will use the following schedule:
a.   Captain      Veteran
b.   Weapons Officer   Veteran
c.   Engineer      Legendary
d.   Helm      Legendary
e.   Security      Legendary
f.   Science      Legendary
g.   Comm      Legendary

3.2 Mission-based Features

1.   When using the player?s BPV value to generate Enemy AI opposition and the mission is played in the Early Era time frame, the BPV value used is reduced by 25%.

2.   Increased PP rewards for PvP matches: forced disengagements yield 2 times the normal victory PP payout, player kills/captures yield 3 times the normal victory PP payout, out-numbered PvP wins (ie. 2 humans on one or worse odds) wins for the under-dog yield 4 times the normal victory PP payout. In addition, if the player is forced to disengage from a match where there are the same number of humans and ships per side then the player will always incur a Devastating Defeat. Any match involving a human DN player nullifies all these PP adjustments.

3.                Whenever possible remove extraneous AI ships from the mission when Player vs. Player combat is involved.


A MS-Word soft copy of this document can be found at this URL:
Standardized Mission Architecture for SFC2 API Programming

Feel free to download a copy, make changes, and email them to me so we can discuss. <img src="http://208.57.228.4/ubbthreads/images/graemlins/laugh.gif" alt="" />  

[CptCastrin]

You need to add a section on licensing and fair use. I'd suggest reviewing the GPL wording ( http://www.gnu.org/licenses/gpl.txt ) and incorporate something similar to that into your document so that no matter what, admins and players are not held to the whims of scripters and have the option to further their campaigns if a scripter should become unavailable (or unwilling) to fix problems in their scripts.

So long as the original script writer is properly credited and informed of changes I see no reason why this should not be included.

You might want to get togeather with the other primary scripters and get input on how to best protect your works while protecting the rights of others to use your work. I am not so simple as to think that this can be done over night but you have a good base and from there I think you and others can get a truely useful standard worked out quickly.  

[CptCastrin]

Quote:
Standardized Mission Architecture for SFC2 API Programming

Author:  el-Karnak, koshnaranek2002@yahoo.com

...

3.0 Standard Mission Features
The goal of this section is not to dictate a specific set of features for all the scripters but mainly to set a specific set of guidelines that have be confirmed to robustly work in EEK missions.  In addition, the majority of the playerbase has asked many of these features be implemented for quite some time based on my SG3 Admin experience.  Of course, each scripter is free to do as he/she wishes, but it is hoped these guidelines will serve some benefit nevertheless.
3.1 Ship-based Features

...

2.   Regulation of spare use to reduce to usage of a ?second? or even ?third? set of ship internals in mission play. In any mission, the maximum spares available on a player's primary ship will be based on the following schedule based on ship class:

a.   Freighters:               8
b.   Frigates/Destroyers:         10
c.   Light Cruisers:         12
d.   Heavy Cruisers/New Heavy Cruisers:   14
e.   Heavy Battle Cruiser:         16
f.   Carrier/Dreadnoughts:         18
g.   Battleship:            20
h.   Any other class:         14

Any surplus spares that exceed the above limits on a player?s ship will not be available in-mission, but instead returned at mission?s end; if the player?s ship survived the mission.

I'd remove this as a player limit and instead use it as a guideline for AI ships. Removing spares from ships when people have "paid" for them unfairly penalizes them for stocking up and will result in your missions not being used because of the arbitrary limit you propose.

   

[Karnak]

Quote:


I'd remove this as a player limit and instead use it as a guideline for AI ships. Removing spares from ships when people have "paid" for them unfairly penalizes them for stocking up and will result in your missions not being used because of the arbitrary limit you propose.

   

The spares have not disappeared. They will be available for the next mission.  It simply establishes a maximum limit of spares that a player can use in one mission.  For example, a ISC player using a I-CCY with 30 spares would only be able to burn up 16 spares a mission instead of the whole 30 in one mission.  Most players that gave me feedback dislike the notion of ships having an "extra set" of internals.  It will also speed up the PvP matches. For many players,  they rarily use over 10 spares in any one mission so the change won't even be noticed.  I think Fluf used similar consumable limits for LB4.

As for the licencing, send me an email detailing a new setion 2.7 regarding such matters and I'll put in the MS-Word document for other scripters to ponder.

 

[CptCastrin]

I understand that they have not dissapeared permanetly but only for that mission however that is small comfort when your ship is an expanding ball of flame and those 10 additional spares that your engineering team couldn't find could have come in handy.

The point is this is a game and as a game if you are given certain bonuses then there should not be an effort to remove those except in the need of game ballance. I don't see that need in the case of spare parts. Better to increase the AI's options (and capacity) and make the missions more ballanced vs the capabilities of the player.

As to the "licensing" point I only really offered it as a suggestion and I don't know if you (meaning the scripting community) can even get that to work much less agree to follow it. It was a suggestion based on the occurance of projects being left to seed when the primary person disappeared. I don't feel it's my place to dictate to any of you how this should be implimented and as many of you are software writers I'm sure many are aware of GPL and other methods that could provide guidance.  

[Karnak]

Quote:
I understand that they have not dissapeared permanetly but only for that mission however that is small comfort when your ship is an expanding ball of flame and those 10 additional spares that your engineering team couldn't find could have come in handy.

The point is this is a game and as a game if you are given certain bonuses then there should not be an effort to remove those except in the need of game ballance. I don't see that need in the case of spare parts. Better to increase the AI's options (and capacity) and make the missions more ballanced vs the capabilities of the player.

Well, I feel the AI is about as souped-up as it's ever going to be. There's maybe a 1% chance that an AI lives to use its tenth spare much less its twentieth.  That's why I went on the player side.  It is already implemented by Taldren in SFC3 on a much more stricter basis. You can't buy a tenth spare in SFC3 much less a twentieth.  For this reason, I don't feel I am intruding on the game's env. too much.  Most SFC3 players that transfer to OP won't notice a difference or be surprised their Heavy Cruiser has 14 spares to play with instead of 8.  You could say I am trying to take the good parts of SFC3 and put them back in SFC2. Much like Drall's rule set is trying to enforce D3's almost airtight disallowance of multiple missions in one hex so that the hex flipper can't run missions underneath other players in the same hex. The RMs I consulted said they don't use that many spares so they don't care for the most part.  PvP time will also decrease reducing the chance of a 3 hour PvP match being all for naught cuz the server connection was lost. On the whole, I don't see anything negative about this change.  But, it's really the players that decide this issue so I will see what the reaction are after the Test Server.  If the players don't like it then I will be encouraged to take them out. If the players do like then you willl be encouraged to use EEK in your server along the same lines as AI stripping.

Quote:


As to the "licensing" point I only really offered it as a suggestion and I don't know if you (meaning the scripting community) can even get that to work much less agree to follow it. It was a suggestion based on the occurance of projects being left to seed when the primary person disappeared. I don't feel it's my place to dictate to any of you how this should be implimented and as many of you are software writers I'm sure many are aware of GPL and other methods that could provide guidance.    

I think there's only so much you can ask from people that work for free. Basically, everything in D2 is on an "AS-IS" basis. Like buying an used car you have to do a lot of research on the work before you use.  Also, since it's volunteer work RL will alway have RL priority and people will be less tolerant of certain issues than if they were doing a paid job.  I could write up some recommendations for the scripters so they don't do something hasty and encouraged them to share ideas, but really I think it's the Admin.'s responsiblity to make a call on missions. If you are wrong about a mission pack the players will very unhappy.  But, if you go with stock missions and another dyna runs bug-free customized missions then you also will most probably lose players.  My personal, no guarantees it's correct, suggestion is to go with the established bug-free missions, run a tight ship with player behavior (Pelican's Admining of DomWars is a perfect example of this) and be skeptical about new-fangled ideas until they have been thoroughly tested.  

EDIT:  "Section 2.7 Licensing and Freeware/Shareware Issues" added to this thread's top post and the soft copy of the "Standardized Mission Architecture for SFC2 API Programming" document.

[Demandred]

Can you release mission scripts under the GPL? Unless the scripter has rewritten the whole basic framework of a mission, a fair chunk of the code belongs to Taldren and they might not be terribly happy about it.

[FireSoul]

I'm pretty sure that he's gonna have to follow the same license agreement that came with the Taldren missions.

[Karnak]

Quote:
I'm pretty sure that he's gonna have to follow the same license agreement that came with the Taldren missions.  

"He's gonna have to"  means every script writer  I'm sure you meant to say. :|

Well, until we get a definitive answer on licences regarding the usage of scripts, that implement features of Taldren's EAW and OP API, authored by non-Taldren software developers, I am not going to post any material on it.  

Edit:  "Section 2.7" - strike any references to GPL license.

[CptCastrin]

I never said "use the GPL" I said use it for reference and make a rule that would cover the sharing of source code to missions while protecting the original author's right to not have their work copied and claimed as someone elses work.

If Taldren has a "rule" governing this fine but I wouldn't know. Also the GPL is not a great, all powerful, agreement and may run counter to Taldren's stand on sharing resources.

Btw, I had assumed that the above "architecure" guide was in regardes to the mission setup and ideas behind how the script is written, not the actual API tool set that was used to make it. But then there in maybe the problem. As the API is Taldren's and all scripts are derivative works there maybe no way to protect said work done by the scripters. Saddly this leaves most in the possition of a) only releasing the missions and if they deside to move on or not fix "bugs" the users are SOL or b) release both the mission and it's source and hope for the best (i.e. no one takes their work and "tweeks" it then claims it's their work).

Perhaps a central location for missions and source code would be best for all so that if claims are made that are in regards to final "ownership" to a source code.

Then again the point is probably moot as Karnak has left the community. Sad too as this points out the very reason an agreement between the scripters in the community should be made. Now the new EEK mission for OP will probably be lost and that is a loss to all.  

   

[CptCastrin]

I have reopened this thread for two reasons:

1. Karnak's absense from the scripting community was short lived thus he might want to comment further on his baby.
2. to allow others to also add comments as desired considering Karnak is still here.

My appology for not doing this long ago but sometimes you forget things that should not be forgoten.

Peace.