Mod Repackaging

[RBL-4NiK8r]

* 4nE your probably one of the best peeps to talk to about my current focus with your MP gaming background & Mod experience-goals.

* Here's my basic premise.

* The original campaign was built on "Asymetric Warfare Principles" (AWP) which was a big part of its captivating gameplay.

Well one of the problems with the SP game was that everything was scripted with triggers to where you take X number of units to Point A and take out target Y and when you cross over Trigger Z your force gets attacked, and this will happen every time you trip the trigger. Now if your a smart player you build defenses around the trigger and not trip it till your ready and let them do your work. There is a mission on Camp3 that blasts your LZ with Artty and after 5+ mins or so a never ending supply of VTOL's hit your LZ. The thing is its a real bitch to do much with the Artty hitting your LZ and for the most part taking out any AA defense you might build. Now the funny thing is that all you need to do is run 3 Bunker Buster VTOL's at one of the Sensor Towers and the Artty stops. Oddly after that is taken out no truck will go out and rebuild it, in a MP game you would have many of Sensor Towers to give your Artty support and always rebuild sh*t that was taken out. Oh and for the most part I think the maps used by Pumpkin really made you think in a lot of its missions, but then again they also had a lot of dead space in them at times.

* This is fairly straight-foward to build in SP scriptomatically.

* We're following a similar path in building the new SP CAM - "WZ 2200".

* My contention is that "The Asymetric Warfare" GPMs of CAM never translated to MP (I don't count "Truck Rushes" - standard or flying)..... because, in the absence of scripting it's not easily achievable.

Well here to not many people think out side the box when it comes to trucks, I think it was Maynard that made the Bootcamp map and I trashed that in about 4 hours, and no one could figure out how I could do something like that and the same with a few others. You give flying trucks into the mix and now your looking at placing hardpoints where nobody really thought about putting them, and I for one hated the flying trucks as you might recall. Also I always looked as my trucks as being the Queen in Chess and as anyone can tell you when I used VTOL's in MP games it was to take out Factorys and Trucks at the same time, there is nothing worse then having the best turtle base in the world only to lose factorys and trucks in one attack, then it only is a matter of time before I trash the rest of it.

* I also believe that Pumpkin's "ECM" schema was gonna be implemented to take WZ MP down that road of AWP evolution.

I disagree here Pumpkin never really tested there T3 tech yes it worked to some degree in the SP game but Multiplayer most of it either was over powered or to weak to use, so people used the things that worked good and left the rest alone. Keep in mind here that alot of this also depends on the map and the oil on it, I was never big on oil in your base maps, and felt its was ment to be hunted and guarded thru out your game play, but most players get bored way to fast on maps that you only have a hadful of oil and the enemy from hell to attack, I think Tromans one map was like that Citadel and I bitched up a storm on that because though it was a hard map to take out when your dealing with T3 you need oil and that map had like 4 or so and not enough to really put up a fight, any ways thats when Citadel Elite was made and it had more oil and better game play with out getting bored.

* Now I know your "VTOL FUN" (& work on v.1.12 with Strata) were attempts down a parallel path by way of a rebalancing (rock-paper-scissors).

Well I think Pumpkin forgot about the RPS in some of its balancing and once again spent most of its time on the SP game, they didnt take into accout what would happen if player X makes 90 of the same unit and try to blast a hole in your defense with 3 other players comming in right behind them with all there tanks. There idea was to use 10 or so of each type of weapon to make a group that can deal with all kinds of things, but the down fall of this was that many of the non-anti-armor weapons lacked the defense on there turret. Take something like the Bunker Buster this was something you either wanted out in front of your tanks or in the rear, so you either have to give it short range and good turret defense because its going to be taking fire from both tanks and hardpoints OR you let the thing be weak in turret armor and give it more range. Then again the BB was the only weapon used for that warhead another thing I could never understand about Pumpkin was that they had the means to give the game balance but never went thru with it. OH and before you say it might have been in the works, I highly doubt it, these are thing that should have been done before release or with the first or second patch.

* Here let me use this chess analogy to make this brief.

* I would like to able to do the equivalent of the "Queens Gambit" in Wz against an equally strong player who's not made an egregious mistake (elliminating the whole "Fools Mate" bull chit win) and still have a fair chance winning endgame.... (the "Queens Gambit" creates an "Asymetric Warfare" condition, in other words.)

* Does that make sense ?

Let me ask you this if you have played Chess over the past number of years, how many times have you really won a game in Fools Mate, I think its called that for a reason and sorry to say this but nothing can be done to help the person who makes the foolish moves in the first place. I have been playing Chess for over 38 years now, and I can only recall winning a game in Fools Mate because I was teaching my brother how to play and he was very foolish. Also keep in mind that in Chess everyone starts off on more a less an equal setting this cant be said about most RTS games, because in the end its going to be the person that knows more about the tech, the map, and oil on the map, the weapons in use or being made. How many times in a MP game do they check to see what unit the other side is making, many of games I won was because I knew how to counter the other sides unit. Back in the early days of MP Pulse Lasers were the sh*t everyone made them and they would trash any damn base defense BUT they sucked against HC track or Rail track so it always was a matter of waiting for them to attack and when they lost all there tanks guess what you did next ? Sure they might have put a hole in your defense and wiped out a few things, but HC vs Pulse the HC will win every time hands down, and mix in a few Rails and now you can go on the offense.

* Do you think it a worthy goal ?

I do agree with your statement below, but the only real way to do that would be to add a unit limit type, so where you can only build say 10-20 of one given unit. Even Supreme Commander what I think is one of the best RTS games out there today has yet to do something like this, but they do have means to limiting the powerful weapons to just a few. Anyways I may get into that later.

* Basically it is to make MP winning tacs less narrowly predictable & afford more opportunities to win by means other than sheer overwhelming #s of select units....

* Your thoughts on this would be very helpful to me in working on  WZ 2200..

- Thanks, Rman

           

Hope this helped some 4nE

[Rman Virgil]

------->

* As always, 4nE, very helpful.

* Never thought about caping # of unit-types directly. My approach has been to make units more "precious" thru enhanced "Rank & Experience" mechanics.

* "Trucks" as the "Queen".... yup, as any lowly pawn can effectively become one.

* Maynard's "Bootcamp" - How well I remember how you took me & my assessment to task over that one...(at the time I thought to myself - "Who is this UPSTART !!!) All I can say was that I failed to take a brilliant mind into account, heh.

* Troman's Maps were "Fortress", "Desert" & "Hunters"...

* "Citadel" & "Citadel Elite" were the result of one of the funest collaborations I've had in WZ - with the singularly talented Laws 245.

* "Supreme Commander" is indeed one of the best out there (did you notice how much of what we formulated for 2120 & TWZ, years before, showed-up in SC ?).... I also think "TA: Spring" is quite outstanding....

* I agree - Pumpkin never finished their balancing, esp. in T3.... which probably had a lot to do with T1 only MP popularity.

* I give a lot of kudos & respect to the WZ MP community because not only have they exposed all of WZs weaknesses....BUT they ALSO took a host of creative measures to compensate for them as best as possible under the circumstances. IMHO, anybody that works on WZs future that doesnot take into account ALL of the MP experience over the years is a fool...

* On "Fools Mate"... all I meant was suckering peeps that were not entriely versed in WZs ins & outs... Rather imagine playing someone as good as yourself 4nE, how would that play-out in your mind ???

* I do believe Pumpkin put a lot more into the SP CAM experience than they got to do in MP.... Unlike yourself I think they intended on actively working on WZ for another year than they got to as the groudwork / groundswell for 2120's release 2-2 1/2 years after 2100's release.

* I'm goona have to give your unit-type # capping some deep thought.

* Thank you for that comprehensive & caring response.

- Regards, RV

[Chojun]

I think one of the biggest mistakes that was made after the source release was to raise the unit limit through the roof, to 300 (or whatever it is now).  Raising the unit cap to fix multiplayer GPM issues is like throwing gas on the fire.  Counterintuitively, the fix to the problem I believe was nailed right on the head by 4nie.  It isn't to add MORE units, it is to REDUCE the amount of units available.

Throwing everything you got at the enemy, including the kitchen sink, is a naive tactic that really only serves to bring on wars of attrition rather than "AWP" as you call it, RJ.

Attrition and massive tank columns shouldn't even fit with the Warzone storyline.  So, when you are faced with an opponent, you're both on equal ground, and you have a limited number of units, what do you do?  Make them bigger, stronger, faster, more experienced and develop strategies of wit and cunning that will put you ahead.

The trouble with warzone is that it (because of balance issues) has never really been a game of rock, paper, and scissors.  It's more like a game of a rock with sharp edges that can cut paper, paper with hard chunks in it that breaks scissors, and drill-like scissors that can bore through rock.  And I completely agree with 4nie, T3 tech is completely broken.

As for a unit cap, I think 50 units tops, with proportional limits to how many small / med / heavy / superheavy bodies that you can build.

Also I think commanders should play heavily into this as well (they are far too underused).

[Rman Virgil]

........
The trouble with warzone is that it (because of balance issues) has never really been a game of rock, paper, and scissors.  It's more like a game of a rock with sharp edges that can cut paper, paper with hard chunks in it that breaks scissors, and drill-like scissors that can bore through rock.

,,,,,,,

* Oh, man, THAT is grade A, choice word crafting.... kwe dudel.

* Your so good at what your doing now.... I forget your multiple gifts include wordsmithing.

* Oh yea..... right-on with the assessment.

* I also think that connection to the whole WZ game world is an inconsistency that never gets mentioned - it's a friggin world of scarcity, bottom-line, no matter how you slice it..... it's Sci Fi.... not a magical fantasy dog-gone-it.

- RV

[kage]

unilaterally changing the code to restrict the number of units, so that you force everyone to play with fewer units for their own good is a bad idea, and i hope you weren't actually suggesting that as an improvement.

good engine programming would be making things continually more efficient so that you give the player the choice of being able to play with more units on screen or with high graphics options at the same framerate as earlier engine revisions.

to improve gameplay by limiting the number of units, you always have to rely on the players (since it's not your place as a developer to care), and the correct solution would be to implement settable max unit limits, as well as corresponding displays and filters when searching for a multiplayer game.  as we add ever more customizability to a multiplayer game, the current interface becomes a hinderance: it is based on static screens, that can only contain a very limited amount of settings. the simplest solution would be to add more "pages" for settings, and that may do a great job at a minimal effort in the near future, but eventually, we may just need to rip out the menu code and write something scrollable, especially one that would use 1:1 pixel ratios at all times, allowing more settings to fit dynamically on screen before scrolling when using higher resolutions, as opposed to the current stretching methodology (in other words, what the ingame gui does is better than what the menu gui does).  if we want to polish warzone, this kind of work, and code simplification are the two things that'll bring it straight up to modern expectations, as well as removal of some limitations (like allowing in-game resolution switching... if at least to start, can only happen when in the main menu, and it can just exec() another instance with new res options).

i had an idea which may set warzone apart, at least from every commercial rts game i've played, which i choose to dub "micro-scripts":

essentially, you provide extremely simple and limited syntax (this is done intentionally), and provide just a small variable set, to configure basic game rules regarding power use, unit limits.  players would be able to see the micro-script of a server (if any), before they choose to join (and after they choose to join) -- the code should be as such that even users with no programming experience can use and read it with little instruction.  also of primary importance: this would completely remove developer burden when it comes to adding new game types, game rule combinations, etc: just give the player a save/load interface and a basic line editor (so that players aren't required to mess with console commands each time they want to start a new game with a completely new micro-script.

code could look like this:

Code: Select all

when units greater than 60
  increase unit_power 85%
  increase unit_time 15%
  increase buildings of research 1 maximum 5
end_when

when total units less than 10 multiply players
  increase power_generation 10% maximum 160%
  decrease factories of cyborg 2
  decrease factories 1
end_when

set units 200
set units_per_small 3
set units_per_medium 7
set units_per_large 15
set buildings 60

(note, those lines at the end could be used to implement something like what chojun suggested -- one medium unit in this case is considered to use 7 units towards the maximum of 200 (so you'd never actually have 200 units per player, in this case)

formal script language requirements would be:

• code must be completely translatable to and from the user's local language -- if the code is correct, there's no way it couldn't translate into other languages (token order could be defined per-language, but always the same number of tokens to complete a given statement). note that spaces don't necessarily always split tokens -- "less than" would be a single token, for example.
• is a syntax only for setting complex game rules. the script is interpereted and stored into values and a few condition checks, but none of it will be "run" as a script during gameplay.  because of this, statement order doesn't matter within a code block, and all actions are implicitly atomic.
• gives all players equal oppurtunity: while you can read the summed values of all players for many variables with the special total prefix, you can not set limits on a global basis -- this is because setting the per-player unit maximum to 40, and the global maximum to something like 100 in an 8 player game pretty much gives the game to whoever builds the fastest (last time i checked, this game isn't starcraft).
• code that is not within a conditional block is filtered out and modifies the game settings -- so "set player_units 400", and the two lines below it will just tweak "slider" values (the kind that you drag with a mouse) in the settings screen, get grayed out on the host's machine, and wont actually be seen by other players (so as to reduce code clutter), because they can just look at the values in the general (readonly to them) game settings display.
• strictly one statement per line. indentation is ignored, but when other players see it, it's always indented. absolutely no punctuation allowed to be used syntactically (if at least several other written languages have difficulty dealing with % as a representation for "percentage", and there is not a replacement symbol, then percentage should be written instead of symbolized).
• there is no such thing as a code comment.  it wastes screen real-estate.  besides that, if you need comments, your script is too long, and of course, other players really couldn't care less how clever you think you are.
• no creation of user-defined variables... this is just for setting game rules.
• rules set in a conditional only apply while that conditional is true, after which they are reset to defaults (or two an overriding conditional).  in the above example, this means that after the total number of units in an 8 player game owned by all players combined exceeds 80, then power generation rate is reset to normal, and the players can all suddenly build two more normal factories than before.
• there are really only two variable modification methods: increase and decrease. set is just informal shorthand for tweaking variable settings before the game starts (after trying to explain the semantics of using set statements in conditional blocks, the realization that i'd need to explain it was proof enough that it's too complex for this scripting language).
• limits can never be changed in a conditional such that it is possible for a player to suddenly violate some limit (like having 5 factories, and suddenly having a game rule lower the factory limit to 3) simple logic checking would say that when you use "less than", you can never use "increase" with a limit, and likewise, if you use "greater than", you are not allowed to use "decrease" with a limit.  if this rule is violated, the violating tokens are highlighted, and the user is notified (and unable to use the script until fixed). otoh, if someone can suggest a way to bypass this paradox (aside from making buildings and units vanish into thin air, and without allowing the excess buildings/units to stay fully operational), then this restriction can be removed.
• all increase/decrease rules are cumulative with those from other concurrently true conditionals. whenever integers are involved, increase rounds up, decrease rounds down.
• nested variables: while everything could be grouped into logical heirarchies, only those sets of values with true mathematical relationships are allowed to use the of syntax, and only one mathematical relationship between two values may exist per nested variable.  for now, this relationship will be that the value of a child can never exceed the value of the parent, and that the 'current' value of the parent is the sum of all 'current' child values.  for example, the factories variable contains tank, cyborg, and vtol. changing factories limits the total number of any kind of factory that can exist per player, and changing factories of vtol changes the number of possible vtol factories that can be built per player, and while you can set factories to 8 and factories of vtol to 7 (you can build up to 7 vtol factories and only one slot left over for a single cyborg or normal factory), you cannot set factories of vtol to 9.  research of speed wont exist, however, because there's no mathematical relationship between the parent and child variables, especially not any meaningful relationship between that and research of power (besides which, at least in english, the logical association as worded there is nonsensical).
• variable naming conventions: variable names should imply the most likely meaning. when in doubt, if it sounds like a limit, it probably does. so factories changes the total number of buildable factories, while factory_power changes the relative cost of units built at all factories, and factory_power of cyborg changes the relative cost of specifically cyborg factories (cumulative with the value of factor_power).  'of' can be considered an abbreviation for 'of type'. also, variable names should stay as concise as possible in spite of useful relationships, or at least shorthand should be provided in common situations. for example, buildings of labs sets the maximum number of research labs, but since setting lab limits is not uncommon, simply labs is the equivalent shorthand, but is still logically tied into 'buildings'.
• upgradable buildings can also have limits and other values applied to various upgrade stages. by convention, an unupgraded building is referred to as 'basic', the first upgrade is 'first', etc. thus "set factories of vtol of first 2" will only allow no more than 2 vtol factories can be upgraded. unlike other variables, like unit production costs per upgrade level, setting building limits as a special logic exception to normal rules: setting the building limit for one upgrade level implies a maximum limit for higher upgrade tiers as well, so in the previous statement, it implies that there can also be no more than 2 level 3 vtol factories (ones that have been upgraded twice). of course, you can also use "set factories of vtol of second 0" to indicate that, while there can be up to 2 level 2 vtol factories, there can't be any level 3 ones.

oddly enough, i think such a language specification should also go with minimum display requirements:

• tooltips should be provided for every token, and especially every variable when it is hovered over with the mouse
• (only if a micro-script is used), there should be a window (typically hidden) that displays all non-limit (changes in production power, research times, etc) changes as a combo bar displaying deviations from the true defaults in terms of percent (0 marks true default, extending to the left and right as positive and negative changes).  by "combo bar", i mean that it will indicate the match-specific default (what was set before the game started), as well as the current applicable value, based on conditional changes.  this would be as compact as possible, showing only, for example, research speed changes for labs in general, and not the specific values for upgraded labs, if any (well, anything goes, as long as it's concise and intelligible)
• the micro-script can be viewed during game play (of course, read only, even for the host player), and the applicable conditionals are highlighted.
• the user is notified with an auto-fading, mouse-transparent display (mousing actions go "through" this temporary display and perform normal actions) of the changes as soon as they occur.  this applies to going into and out of a conditional, and the display is probably best placed in a corner of the screen

i'm a bit tired, so if any of this looks inconsistent, it probably is. i refined the language spec about 4 times while writing it.  anyways, feel free to bash or improve this idea. if it gets enough good reception, i can personally put in the time to code it -- i'd probably demo it in python first, but if everything works out, i'd code it in c for the actual game implementation (and yes, i realize that this most likely violates a lot of assumptions about the warzone code, like the ability to set arbitrary variables and limits at runtime... i'd be willing to go through and sort out those issues as well, with some guidance).

[Rman Virgil]

---------->

* @ Kage: you hit the jackpot with this formulation.

* Nothing more powerful than freedom of choice.

* Just the basic premise of giving the players themselves the options of game rules (inc.  unit / struct restrictions & so on), server-side auto game type matching, and the Gui enhancements to go with it all.... that's the most robust, the most generative path I can see, now that you've layed it all out, as plain as the sun rising over the eastern horizon.

* Yep, I feel ya on all that.

* Hey.... if for some reason you can't get to it (chit happens outta left field to us all now & then, waylaying even the best laid plans of both mice & men)..... well under those conditions, could we "steal" it from ya.... hehe... with all due  conceptual acknowledgment. 'Course the pref would be your being as  active in the mix as you propose.

- Cheers, RV

[kage]

* Hey.... if for some reason you can't get to it (chit happens outta left field to us all now & then, waylaying even the best laid plans of both mice & men)..... well under those conditions, could we "steal" it from ya.... hehe... with all due  conceptual acknowledgment. 'Course the pref would be your being as  active in the mix as you propose.

i think that many games need something along these lines, that i'll make the whole of the previous post public domain (yes, even commercial game producers are welcome to abuse it), and i make just make a bsd-licensed generic library and then hook it into warzone.  but once again, i'd like more feedback, positive or negative, and more reception before i consider thinking about starting on this (i've got limited time between college, life, and other gaming projects.

i'm pretty sure i'm not the first person to try to design a language by ditching features as the primary means of decreasing the learning curve and increasing readability.  probably not the first person to think about using tiny runtime editable (in menu, not while a game is running) scripts to specify variations on game rules. however, i doubt many people have set out to create a formal language spec/requirements. either way, if there are any other implementations of something similar to this, i'd certainly like to know, so that i could get ideas about what does and doesn't work well, and possibly just use another implementation directly if already coded.

[Rman Virgil]

........but once again, i'd like more feedback, positive or negative, and more reception before i consider thinking about starting on this (i've got limited time between college, life, and other gaming projects.

* Understood. I'll give it more attention over the weekend & see if I can offer more useful feedback. (Similar demands on my free time as well these days).

* Btw - In your mind, do you have a "phrase" that would sum-up what your invisioning conceptually  ? A brief lexicon or formal nomenclature ?

- Regards, RV

[Rman Virgil]

--------->

* @ Kage: Do any of the below track with your thoughts ?


http://www.patentstorm.us/patents/6961873-claims.html

http://www.modwiki.net/wiki/Tutorial_list

http://software.olegdulin.com/2006/12/1 ... -language/


- Cheers, RV

[kage]

lol. i've seen programs written in pseudocode, but never in legalese. hmmmm, maybe i can write a combination code generator and automatic patent claim printing program. oh well, it would've worked in the 90s, at least.

yeah, those links reminded me of many things, and gave me a better idea of how to describe "micro-scripts" (insert better name here): non-finite, user agnostic, stacking rules-based per-game value modification configuration language, with full support for bidirectional language translation mappings (all keywords and program-provided variables, or in short, the whole thing, can be loaded from any supported language, and exported to any supported language -- someone can write a microscript purely in chinese characters, and when you select their server from the lobby list, you'll see the microscript in pure, intelligible, english, or czech, or whatever you want)

because of the "user agnostic" part, i was considering removing the total keyword, but possible use of total is still user-agnostic (you can not say: "if player one gets five units, increase all build costs for player four"), and i can definitely see legitimate use -- the point is, all players have equal oppurtunity (even if it's to trigger global changes that negatively affect everyone), and the scripts should be easy enough to read that users can see what they're getting into ahead of time.  however, i plan to add a "may discriminate based on user performance (ability to get things done quickly)" tag to the display requirements, so that players can easily differentiate between "only you can (indirectly) trigger your own stat tweaks" games and ones that may try to add pseudo rpg elements or truely alternative game "rules" (such as reducing power production by 100% -- turning it off -- as soon as 5 minutes have passed).

[Rman Virgil]

lol. i've seen programs written in pseudocode, but never in legalese. hmmmm, maybe i can write a combination code generator and automatic patent claim printing program. oh well, it would've worked in the 90s, at least.
........

* HEHE.... I thought you'd get a kick of that one.

* When I first read it I said - "WTF is this chit !!!!"

* But after I stopped cracking up I came to the conclusion it had some value as a conceptual construct (if somewhat tedious).

- Cheers, RV

[Rman Virgil]

---------->

* One thing this reminded me of was something we tried to do with a XOOP Module @ wztoys.org a couple years back.

* WZ MPers have been creating their start of game rules / prefs for years.

* I likened the modules functionality to an online "Dating Service" where player profiles (aka, rule prefs, etc) could be matched & then those players could find each other for MPing.

* Your modus could achieve a more elegant, robust & user friendly result.... it seems to me upon reflection.

-Regards, RV 

[Kamaze]

Some things...

I'll may start coding such a thing after 2.1, after the MP gots stable.
Maybe with some things like "Notify me 30/60mins before the match starts i signed on" via mail or jabber.

[EvilGuru]

I have promised myself that when the netcode is stable I will work on the lobby. My ideas are as follows:

• Forum-linked logins. These will be for tournament games whereby you can use your forum login so that WZ knows who you are &c. It would also allow for 'locked' games (so only players foo and bar can join a game).
• This would also store things like win loose count etc (for games you play online while logged in) and would also allow for tournaments.

Still a long way off mind you.

Regards, Freddie.

[Rman Virgil]

I have promised myself that when the netcode is stable I will work on the lobby. My ideas are as follows:

• Forum-linked logins. These will be for tournament games whereby you can use your forum login so that WZ knows who you are &c. It would also allow for 'locked' games (so only players foo and bar can join a game).
• This would also store things like win loose count etc (for games you play online while logged in) and would also allow for tournaments.

Still a long way off mind you.

Regards, Freddie.

* That's kwel. However, it doesn't preempt:

I'll may start coding such a thing after 2.1, after the MP gots stable.
Maybe with some things like "Notify me 30/60mins before the match starts i signed on" via mail or jabber.

* For a couple reasons.

* Most MPers are not into Tourney play. At least not right-off.

* What Kamaze is proposing is a service that could be of use RIGHT NOW, actually.

* Plus after awhile of playing Non-Tourney, gaining experience and confidence, it would be a natural flow to Tournement Play.

* Anyhow, that's MHO on the dynamic and progression.

-l8r, RV