Capture the Flag in EE

Greetings all

I'm starting a separate conversation thread to discuss doing CtF in EE. We had started this conversation in another thread, but I think the topic deserves its own unique thread. My hope is that we can collaborate to develop this capability.

Here's a recap from the other thread:

I had originally asked Daid to "Please consider adding a "Flag" object that can be picked up, carried, and dropped by ships. This would be so we could have "capture the flag" scenarios. Please also consider how this would be prevalent on a scan or visual identity of a ship. "

Daid responded: "As for a "flag" object. You could make that with mission scripts. The Artifact object can be used for this, with the allowPickup function. And a custom button to the ship to drop it again. It's a bit tricky to setup, as you need a way to find the player that picked up the artifact (a callback would have been useful here) but you could find the ship that closest to the artifact when it is picked up. As that's the one that did the pickup. "

Xansta added: "This is the second time I've heard interest expressed in a "capture the flag" scenario. I'm writing one based off of the interest. I'll put it in an EE pull request after I've worked out the bugs. "

I replied:
"Wow. That's cool Xansta. Thanks for being willing to take a crack at it!

My principle interest for asking Daid about it is because my main audience for the teambuilding/leadership labs I've run in the past with Artemis has been the Scouts. We play CtF (in person) in a forest setting, and they really enjoy the challenge and get into it. So I thought they would be enthusiastic about CtF in a bridge sim environment.

There are some mechanics I'm not sure about though. For instance, when we play in person, there are boundary areas and territories. You can't be tagged in your territory, but can be in the "enemy" territory. You have to get the flag and run it back to your own territory without being tagged. In other FPS games that have a CtF variant, being "tagged" usually means being "killed"; your avatar drops the flag and you respawn at a home location. Translated to EE, does this mean a ship has to be destroyed in order to get them to drop a flag? That could make it more difficult than it should be to get a player ship to drop a flag. I was toying with the idea that perhaps it should only take a single missile hit to tag a flag carrier, and that would force the flag drop. Ships could still destroy one another if they wanted to, forcing a time penalty in the respawn. One might think a single missile hit would be too easy, but at our recent EE event, I had a ship with a verifiable mad man at the helm who could dodge just about every missile shot at their ship, and it was great fun to watch. 8-)

Please take into consideration that when we run our events, I usually have 6 ships/crews running simultaneously. (Yes, we fill all positions! It's a big event for us. Each ship/crew gets their own room, and it can be quite the ruckus!) So, a CtF event for us would need to accommodate several ships. I also had the idea that instead of running "large" ships (like the Atlantis with a full bridge crew), we would instead turn every console into a fighter and let each player act individually. This would be a great big fur ball and a huge amount of fun! If we have 6-8 people per bridge crew, but then turn them into a squad of 6-8 individually managed fighters instead, we could divide the whole lot into two teams and make them coordinate over separate TeamSpeak channels (we run our own local TS server at these events).

Running a bunch of fighter class ships will also present the teams an interesting challenging if the ships only have a small number (1/2?) of available missiles before they have to go resupply from a base (presumably deep behind their own lines). This will cause them to be judicious in firing solutions and to coordinate their defenses! 8-)

Regarding victory conditions, I had been thinking about two victory paths: either successful flag capture, or total number of "victory points" if time runs out without either team successfully capturing the flag. Victory points could be: 1 for scoring a successful missile hit; 5 for destroying an opposing ship; and perhaps give a "yardage" (ha) award for carrying a flag so far, even if it doesn't win the game (i.e., you carried the flag for 40U, you get 40 VPs, or something like that; I haven't worked out the math to see what would be fair/balanced).

And regarding flag drops, when we play in person we typically play by the rules that if a team manages to move an opposing team's flag down field but is forced to drop it, the flag stays where it is -- the owning team is not allowed to move it backwards or reposition it. In essence, this allows for the tactic to move the flag down field by a number of successive sacrifice plays as opposed to retrieving it without being caught.

There should also be some sort of penalty timer if you are carrying the flag and are hit/forced to drop it. You shouldn't be allowed to immediately pick it back up again. Some time should have to elapse first. (30 seconds? 60?)

Well, those are my initial thoughts. Sorry for the long post. Was excited that you were interested in perhaps trying to implement."

Daid replied: "If you don't want the ships to get destroyed (which can get complex with rejoining the game) Then you could drop the flag on hull damage (so shields are your defense against flag drops)

And when hull damage is too low, you teleport the ship back to base, and repair the hull, or to a respawn area where they have to wait.

Alternatively, to prevent the "rejoin a ship" issue, you can use the "transferPlayersToShip" function to transfer the crew to a new ship just before it gets destroyed.

The new "zones" feature sounds perfect for the enemy/friendly areas."


  • Continuing the conversation...

    Thanks for the recommendations Daid! I think the idea to teleport ship and repair just before it's destroyed is a great idea. It would definitely help reduce the complexities of crews having to rejoin, etc. And given the 'update' function is called so frequently, it shouldn't be a problem to conduct the logic test to teleport/repair before a ship gets destroyed.

    Also, I had skipped right over the "zones" feature as listed in the script reference. You're right, that feature would be perfect for CtF functionality. Thanks for pointing it out!
  • Hi Kilted, Where in the world are you based btw?
  • East Coast US!
  • Ideas I've been putting in the capture the flag scenario so far:

    Each player ship spawned (default to Human Navy) spawns an identical player ship of faction Kraylor. This means there'a only ever two teams, but you can crew a bunch of player ships. You're fortunate to have a large number of players eager to play - I can rarely crew two ships. Script gracefully handles up to 12 player ships (6 on each side). This lets you set up your capture the flag game with whatever ships you want: all fighters, Atlantis, a mix, a carrier with smaller ships, etc.

    There's a five minute set up phase where you "hide" your flag in your own territory: fly around and click the drop flag button on the weapons console. The flag (artifact) does not appear until the end of the set up period, to hamper opposing team Relay officers that may send probes into your territory during the setup period to find your flag. I intend to add three "decoy" flags at higher difficulty levels.

    Entering your opponent's territory during the setup period causes your ship to be destroyed. That may be harsh, but it's easy to implement.

    Once the hunt starts, 25 minutes remain before the game is over. 30 minutes is about the attention span of the group I play with before they get antsy and want a break. This means my longer mission scripts rarely get played to completion (Defender Hunter or the longer versions of Patrol Duty).

    You can get tagged in your opponent's territory if you come within half a unit (500) of an opponent ship whereupon you are teleported back to your starting point with warp and/or jump engines damaged. If you were carrying the flag, it's dropped where you were tagged. The length of the delay of being tagged is governed by the efficiency of your engineers in fixing your high speed engines.

    To pick up the flag, it has to be scanned first. I may make scanning configurable by difficulty level: easy = no scan, normal or higher scan required. Scanning lets you differentiate between decoys and the real flag. Observant/competent science officers will be able to use the edge of the scan circle to help locate distant "flags"

    I intend to have space divided by a line of nebula to obscure opposing players' territory from each other unless they send probes or cross the boundary. It also marks the boundary. The "drop flag" button is also only usable while within the boundaries of the game (100 units normal, 50 units small, 200 units large). I'm still debating how to mark the outside edges visually - either nebulae or asteroids are likely.

    I intend to randomize the territory on each side - bases in your territory will be of your faction. Bases on or near the border will be neutral. There will be a central neutral base in visual range of all players' starting positions with a call sign that counts down the starting period and the overall game period. I've got code I can modify to generate bases and other terrain features. It's not in yet because I'm trying to get the base mechanics working.

    Victory is declared as soon as you cross back into your own territory with the enemy flag. If time runs out, all teams will be identified as defeated, but I intend to provide statistics like surviving player ships, number of times the flag was picked up, whether the opposing team's flag was scanned, number of times ships were tagged and sent back, etc. I could add logic to declare some kind of victory there, but initially, it'll just be shown on the main screen at the end giving information on how the game progressed and leaving the participants a reason to play again to try to actually gain a full victory.

    I also intend to add enemy ships marauding through your territory. They will be identical on each side and have mirror flight paths and orders. The weapons officers need *something* to do while the ship searches for the flag, encroaching opponents and/or dodges pursuing opponents.

    It is hard to implement respawned ships, so right now, if you get destroyed, you're out for the duration.

    As you can see, some of your questions have been addressed by my vision of what can be done relatively easily and what's been put in the script so far. I haven't worked on this script in over a week due to real life interference. I've done some initial testing of basic conditions, but nothing extensive. If you'd like to test and/or add to the script, let me know and I'll send it to you. I know I've got a couple of bugs because some of the conditions are not working quite right yet.
  • edited November 2018
    @Xansta - YOU ROCK! Thanks much for spending time on this. Totally understand real-life interference. We manage as we're able to. Yes, I'd be glad to take a look at the script and take it for a spin.

    Ref your points above:

    Balanced spawning. Excellent idea. You're probably using a default ship configuration at the moment, but it might be good for us to spend a little time to consider what ship configuration we'd prefer. I will think on this. What did you think of the idea to have a script varient that has each player in their own fighter class of ship? Or, to decrease the number of ships but increase the level of team cooperation, have two person ships (like a two seat fighter (F-14 or Apache)). One person plays the tactical combined position of helm + weapons, and the teammate plays the science/engineering/comms (sorta like a WSO).

    5 min setup phase. Also excellent idea. We of course do the same for live play (but usually end up taking longer than 5 min, ha). Please consider putting the countdown timer on the mainscreen of all ships.

    Decoy flags. Brilliant! Love it. That will certainly add some spice to the game!

    Destroying ships who cheat during setup -- spot on. Also consider a team "Victory Point" penalty (ref my previous thoughts on alternative winning path).

    Game duration time. Sure, that seems reasonable. Can we make the duration time a variable easily identified/changed in the init?

    Tagging an opponent via proximity. Hmmmmm... Am pondering. Hadn't thought of just close proximity being sufficient to tag/cause a flag drop, but it does make sense. 0.5U is fairly close, and it would certainly emphasize flying skill and energy management. And of course there's a handy function for calculating the distance between two objects, however having looked through the script reference list, there doesn't seem to be a function ready made for checking if a ship has been hit by beams or missiles and by whom... So, on further reflection, I think you've made the right choice. This does raise the question however, of what good are any weapons in this setup? If an opponent is in your territory, and you fly close enough to score a "tag", then they respawn at the appropriate respawn point in the rear of their territory. No weapons were needed in the engagement, however, that doesn't mean we couldn't have used missiles to slow someone down, or give them some damage to prevent them from escaping. Ok, I agree with the proximity approach, and weapons are 'secondary effects'.

    Dropping flag where tagged. Excellent. Thank you. This is an important element to game play.

    Time delay on respawn being a function of engineering skill. Devious. Let's try it. ;]

    Scanning flag prior to pick up. Great idea. Also the variations on difficulty level. I didn't see in your post however, how will a ship actually pick it up? Also proximity? That would be easiest, yes?

    Boundaries. Yes, this will be a little bit of a problem. In live play, we use "caution" tape to clearly mark left/right/middle boundaries, and it's not allowed to go around the boundaries. "Going around" would be quite enticing for players to try in EE. Perhaps we use the "Zone" feature/functions, and if the players go outside of either zone, then warnings are sent to their main screen/helm console, and they get a time limit to get back into a legal zone or --kaplooie!--.

    Territory. Yes, I like the idea of having randomized territory option, but would like for the possibility of having some predesigned maps as well. I'd be glad to design some maps. Area choices of 100 normal/50 small/200 large initially seem too small to me. But let's try it first and see how it plays.

    Victory conditions. Roger. Collect and show stats now, and incorporate into an alternate victory path after base script is stable. Good idea.

    Marauding ships. LOL. Why yes, I think we should. ;]

    Some additional thoughts:

    -- Defensive placements. Incorporate just a little castle defense game play by allowing each team a specific number of defensive assets to place where they wish (in their territory) during the setup phase.

    -- Supply drops. Should we consider Team 'A' supply drops randomly placed in Team 'B' territory? Non-renewing, of course.

    Testing/playing opportunities. I would love to be able to use this CtF script during our major event in February. We'll have 6 full ship crews. To prep, we're running a full test/dress rehersal in January. We could continue to develop/test until the Jan full-up test and then run it at scale, then still have some time to fix issues prior to the major event in Feb. Thoughts?

    Again, thanks very much for taking an interest and stepping out. Am very excited to try it out!

    BTW, have you seen the other threads I've started here ref adding more dynamic elements to the environment? Here are the thread links:
  • (p.s. - Sorry, but I blew past the part early in your post about using any type of ships. Most excellent. (Note to self, slow down to read more carefully... ha))
  • Pick what ship(s) you want with the crew complement you want :-)

    If you have not set your flag by the end of the setup period, wherever your ship happens to be is where the flag will go. A smart Relay officer will leave a probe around the countdown station and will keep the crew appraised. I may do it on the main screen, too - that's easily added, but low priority.

    The game duration variable (gameTimeLimit) is easily located in the init function and thus can be manually configured.

    Proximity for pickup, yes. The artifact can be configured to be picked up or not, but I did not want a friendly to be able to pick up a flag after it's been placed, so it's a proximity check for an opponent near the flag.

    The primary boundary is between territories. That's easily checked: X < 0 or X > 0. The territory size only matters during the preliminary phase - disable the flag laying button when outside the boundary. After that, the ships can fly wherever they want. Experiments and a couple of play test games will determine whether larger areas are warranted. They are easily added. I went whole hog on huge play areas on some of my scripts and found that it was hard to keep the attention of the players, hence the sizes I chose.

    The territory generation is likely to be a clone of what is done in Defender Hunter with some modifications to account for the initial start area to make it relatively clear of clutter. If you want to design your own terrain or your own terrain generating algorithm, please do so. Replace the calls to the existing functions with yours. If you want it incorporated in the final release, we can add variation permutations to cover it.

    Defensive emplacements are a possibility. I'll look into that after the basic structure is in place and working. Should be relatively easy. Supply drops are a different matter. I'm inclined to disable supply drops initially. If they are enabled, they'd initially follow the existing supply drop paradigm. Each team would have a fixed amount of reputation and they can earn more by destroying enemies. They may be able to get more by either scanning flag or picking up flag or spending time in enemy territory. This variant seems a low priority until after the basics are working.

    I did read through the orbiting bodies post. I've done some of that myself. Planets are not as interesting because they don't have much in the way of game play interaction (though they look great).

    For some reason, when I tried to make asteroids a different size than the default size, it did not work. Of course, I run various versions of the software and I have not tried it with the latest version. I'll plug in your exploding planet code and see if the variations in asteroid size work as flying chunks.
  • Hey Xansta!

    Thanks for letting me take a look at the work in progress. Truly appreciate your taking a crack at this. Totally understand of course it's a very early work in progress.

    Some observations.

    Demarcation line (per your last post). Yes, it makes perfect sense to use X=0 as the left/right demarcation line. Very easy logic test, you're right. This actually caused me to reconsider the need for upper/lower boundaries at all. However, after some further thought that that I won't bore you with here, I think it's still worthwhile to apply upper/lower boundary constraints (according to your previous small/normal/large suggestions).

    I love the fact that when you spawn a TSN vessel, a team balancing Kraylor is automatically spawned as well. Well done.

    Starting location. How would you feel about starting the players a little further back into their own territory, say about 25U? That'll set them distinctly on separate sides, but still keep the demarcation line inside initial sensor range. Also, please consider aligning ships on same side with the same X value, just spaced out at perhaps 1U intervals along Y.

    Flag drop. The scenario description says that the science officer will be able to mark the drop location, but I wasn't able to do so, so I assume that's still to come. Otherwise, the flag artifacts did drop at ship locations just as prescribed. Did you create the model for the artifact? That's pretty cool! Definitely a "space flag", ha. Please consider at some point in the future adding a notification to science station or main viewscreen (or both) that the flag has been placed and game has commenced.

    Please also consider adding a notification to either helm and/or main screen when the ship crosses over to opposing territory.

    I definitely like the requirement that the flag artifact has to be scanned before being able to pick it up. Makes it much more deliberate. I noted that the science station does get a notification that identifies the opposing flag has been identified. Nice!

    I played around a little bit and put a nebula on top of a dropped flag to see how close you'd have to be to see the artifact. 5U and it shows up. I was just working out in my mind how difficult it is going to be to find a flag hidden in a nebula, because you KNOW that's where they'll put them… ;]

    Tagging. I noted that nothing happens as of yet when opposing ships are in close proximity. Obviously tagging and transporting ships is still to come. Roger.

    Pickup. Scanned flag artifact is automatically picked up within 0.5U. Excellent!

    Please consider adding a notification to the science console and/or main screen when a ship is carrying the flag.

    Also, I was playing through some potential scenarios (in my mind). We need to make sure to drop the flag artifact if the carrying ship is destroyed and not just tagged. Speaking of which, should legitimately destroyed ships be allowed back in, or have to sit out? From one perspective, I like the idea of the attrition, but if I have a crew that's out for the rest of the game, sometimes that makes for restless players… Perhaps we leave it at the GM's prerogative. We can also use Daid's suggestion from earlier, and auto transport the crew back to the respawn point when they get to a certain level of hull damage. The more I think of the various options, the more I like Daid's approach.

    Yet another consideration to ponder. Should there be any indication to a side when their flag has been taken and which ship has it? During live gameplay, we've never played by a rule that you had to announce when you had an opponent's flag or wave it around when running back to your own territory (ha). However, most of the time we do play with a sufficiently obvious flag, so this tends to be self-evident. When we first began this discussion, I was pretty much of the mind that it was necessary to at least be able to identify a ship that was carrying a flag, but now I'm not so sure. Perhaps the question's academic, however. What mechanisms are there to change the scan signature of a ship to indicate if it is carrying the flag? Looking at the script reference list, it appears possible to change the "radarTrace"; can this be done during the game play? If so, perhaps we change the carrying ship's radar trace to something very obvious?

    Ok, I think that's it for now. Overall, looks like a great start! Thank you again for your time and effort! 8-)
  • edited November 2018
    Ok, after rethinking what you said about territory size only mattering during the startup phase, I understand better what you meant. So only establish the size boundaries to set the initial environment (terrain) and not allow them to put the flag x=+/- 10000000000 (ha; you know they'd try...), but then during play don't worry about upper/lower/rear boundaries since the flag is set and the owning team can't move it again. Ok, now I got it. I actually like that solution. May I recommend using a series of mines set to mark the initial perimeter, but then after the startup phase, remove the mines from the map. Easily done with a single array of mines. As a matter of fact, I'd like to be more helpful than just offering constructive ideas [grin]. Would you like if I were to write the functions to place and then remove the perimeter based on chosen difficulty level?
  • I didn't update the description: it's the weapons officer that gets to smash the "drop flag" button. The weapons officer should also get a message saying it's dropped.

    I reused an existing artifact model available in EE for the flag.

    Relay for sure will be notified when setup has completed and the hunt has begun. That's not in yet. Relay will also get notified when the flag is picked up, though science, helm and weapons will see the flag disappear from their screen which should be indication enough. I can easily add that to the main screen, too.

    Tagging is not yet fully functional (obviously). Definitely need to cover the case when the flag carrying ship is destroyed - that's not in yet.

    For now, I'm going with the simplest option: your ship gets destroyed, you're out of the game. This is another reason I chose a 30 minute time limit so that the eliminated players don't have to wait too long for the next game. I'll consider adding code to re-spawn a ship if it gets destroyed after I get the basics working.

    If tracking an opponent that has your flag is important to a team, they can have Relay leave a probe near the flag to observe who picks it up. Alternatively, the flag carrying ship's call sign can have ":flag" appended to the end if we think it needs to be obvious. If I add that, it'll likely be for the easier difficulty level setting. Harder difficulty will not make it obvious who's got the flag. Middle difficulty may just get an announcement via Relay that the opponents have picked up the flag without an explicit indication as to which ship has it.
  • Aha! The ol' instructions vs. actual gameplay switcharoo. I see what you did there. ;]

    Yes, once I got a clue, saw the button on the weapons display and flag drop works great. Awesome.

    Destroying/respawning. I chatted with a couple of folks who will be involved in our next major event, and the consensus is we like the idea of a crew being eliminated if their ship is destroyed. Definitely will cause crews to be a little more cautious and not so cavalier. (Hey! Ships are expensive, and it's not like we get to respawn in real life... sheesh! -grin-) But I do like your idea that if possible, to build respawning into the difficulty levels.

    Flag tracking. Sure, that does seem reasonable. Going in position/capability is a team has to have good situational awareness and have the presence of mind to leave a probe to watch the flag if they won't leave a ship to guard. Maybe build into difficulty levels if there are cycles and it seems necessary.

    Ref my previous post, I think we were posting close to same time. Did you see my comment/offer ref initial perimeter during setup phase?
  • Perimeter: you should try to set your flag beyond the perimeter as a test now that you've found the set flag button. You should also try flying your ship beyond the perimeter during the setup phase without setting the flag and see what happens when the initial setup timer runs out. These are scenarios I've coded for but not tested (you *did* offer to test)
  • hahahaha; aye-aye Cap'n; I be yur tester... ;]

    please see code drop I left for you
  • edited November 2018
    BTW, you do know that Klingon code is considered worthy of production only when it can violently escape the clutches of the testers... ;]
  • edited November 2018
    Test Report Cap'n Xansta!

    Test Case (TC) Group 'A' is for startup phase actions
    TC Group 'B' is for live game phase actions

    TC-A1: crossing the center line into opposing territory during startup phase (before timer expires) destroys ship immediately
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A2: crossing the upper, lower, or rear starting area boundary line during startup phase (before timer expires) removes the "Drop Flag" button from Weapons console
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A3: crossing back into valid starting area during startup phase (before timer expires) restores the "Drop Flag" button to Weapons console
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A4: pressing the "Drop Flag" button during startup phase (before timer expires) causes the flag artifact to drop in the designated spot (ship's current position), even if ship moves after button is pressed
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A4a: pressing the "Drop Flag" button during startup phase (before timer expires) causes a dialog box to appear on the Weapons console stating that the flag artifact will be dropped in the designated spot (ship's current position) at the end of the startup phase
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A5: NOT pressing the "Drop Flag" button during startup phase (before timer expires) causes flag artifact to drop at the ship's current position when the timer has expired, so long as the ship is within valid starting area.
    - TSN: confirmed
    - Kraylor: confirmed

    TC-A6: If the player ship is outside the valid starting area and does NOT press the "Drop Flag" button before the timer has expired (note that the button will not be present while the ship is outside the valid starting area), the flag will drop in the ship's last position in the valid starting area.
    - TSN: confirmed
    - Kraylor: confirmed

    Sorry that took a little bit to get back to you. Had real world engineering tasks to get done, but now can do fun stuff for a little bit. ;]
  • Ref pre-designed environments for CtF. I'm working on one now. Can we agree that each separate start-up environment will be established in it's own function? And that given the center dividing line "motif" might change from design to design, let us leave the responsibility for establishing the dividing line "motif" to each design in each function. Ok?
  • As long as the code that checks for crossing the line does not need to be changed, that's fine. I'll say that the terrain generation from me will likely be more than a single function, but I'll be sure it's commented well so that it can be replaced/bypassed. I intend to line the dividing line with nebulae to hamper "peeking," but I'll confine that motif to the replaceable function(s). Some things I'll want to remain across all motifs like the central neutral station (currently called Zebra) that sits on the dividing line. Actually, that may be the only thing. I was thinking of having a nearby friendly station on each side near the starting points, but that can be part of the changeable motif.

    Thanks for the testing. Those are cases I won't have to worry about
  • edited November 2018

    Sorry, let me clarify. The code to check for ships crossing the center line will NOT have to change; I'm only talking about the "terrain" generation (I get hung up thinking about the space environment as "terrain", but it is 2D in EE, so it's reasonable to say, but stilllll.... ha). And ref "single function", I should have been more clear to say a single starting function for a chosen terrain; it could have any number of sub-functions as necessary. For instance, this first terrain I'm building has a single function to build the terrain [buildSwirlyNebulaEnvironment()], and one function to cause the environment to move [moveSwirlyNebulaEnvironment()] that of course gets called from the update function. I'm about 1/3rd done and hope to finish soon and will show you right afterwards.

    Regarding friendly stations, I'm not sure how that should be handled. I saw in your scenario script that there's a rather elaborate system set up for communicating and bartering with stations. I assumed you brought that forward from another scenario and plan to use/incorporate and it seems intriguing, but I haven't had the time to study sufficiently. Does this mean that the number of friendly stations is fixed? Since we might have any (reasonable) number of terrain maps, it seems the chosen terrain generation function should set the station positions, yes? We could establish a max number of friendly stations that works with your prior script setup, then let the terrain author use up to that max and place where they want to. We could keep the friendly stations in a single array for simple housekeeping (one array per team of course). Thoughts?

    Ref center line terrain motif, I was suggesting to leave that to the terrain function because there might be variations wherein you want to use nebula, maybe asteroids, maybe mines, or maybe nothing. We've played a CtF variant in live play where it's a "Pickets Charge" kind of all or nothing startup (meaning nothing is hidden and nothing to hide behind). Causes great mayhem and is fun to watch. ;]

    Did you have a chance to check out the setup phase perimeter function?
  • Agree, center line motif will live in the individualized motif. Outside of what's currently generated in init should be in the specific motif and thus customizable/replaceable.

    Yes, my terrain generating function will bring on code from previous scripts and there is cargo buying and trading going on with the stations. I've tried to put each station in its own function with psx, psy and stationFaction set outside the function. This allows me to randomize their position and ownership. Station size is determined at random. Right now I've got three groups of them since they came from a cooperative script rather than a competitive script like this one: 1) friendly/neutral, 2) generic (less info, less goods) - could be friendly, neutral or enemy and 3) enemy (no goods - intimidating sounding names). Once I get these added, you are welcome to spawn stations from any of the lists.

    I intend to randomly generate the stations with the algorithm centered generally on the starting position. Stations near the line will be neutral, stations firmly in Human Navy space will be Human Navy and stations firmly in Kraylor space will be Kraylor.

    I like having some flavor to the universe, so I'm likely to randomly select about 30 stations from the list. Depending on where they get randomly distributed determines how many "friendly" stations there are. I may create a version where the the number of stations on each side is equal, but placement is random. I may also add a variant where the number of stations is equal and placement is mirrored. I haven't gotten that far and it's a moot point if you'll be writing additions to be incorporated for variety's sake.

    Yes, each side will have a list of stations. We should keep those lists the same name across motifs. I suggest humanStationList and kraylorStationList and neutralStationList.

    I have not gotten back to the code yet (yours or mine)
  • Roger, I'll need to study the station list elements to understand better and see how it all works together.

    I've updated the perimeter test script and finished my first "terrain" map and have sent you links for the files. The terrain has lots of orbital parts to make for a constantly changing environment. ;] I've done a load test with the map and it runs 12+ hours without a problem and generates about 500Kbs network traffic.

    I'm starting work on the next terrain map, and it's going to involve worm holes and fewer orbital mechanics. ;]

    So I've discovered a speedbump of sorts. I had assumed earlier on that if you use the function "setScanned(true)" on a space object, then that object stays visible on the Relay console map. I was thinking that doing so would enable us to use the Relay console map as a broad perspective overview of the playing area so that teams could quickly discuss/decide generally where to put the flag and not force them to explore their territory in their (very) short setup phase time limit. I was a little stumped to find that I was proceeding from a bad assumption. Turns out that even when using the "setScanned(true)" function on all the mines, they don't automatically show up on the Relay console map unless your ship is still within long range radar distance of them. Hmmmm.... So I started another discussion thread asking the community if anyone has developed a "Captain's" or "Campaign" map function (or perhaps a fork of the main game even that hasn't been brought back into the trunk). I do have a manual work-around in mind, but would of course prefer an in-game solution.
  • Limiting knowledge is an integral part of EE, I think. If you want the knowledge, you have to go there or have a friendly station there or have a probe there. This paradigm differs from Artemis where you can "see" everything on the captains map and science map. This works in Artemis because you only ever see a fixed amount of data. In EE, the universe is limited only by the amount of memory you have and the amount of time you have to run around the unexplored bits of the map, thus a better simulation of space reality IMO.

    Having an overview might be nice in the context of capture the flag where you want to be strategic in your placement of the flag and the assumption is that you're playing in familiar territory. However, I kind of like making you explore a bit before you decide where to "hide" your flag, especially if the the terrain changes each time you play.

    Five minutes of setup time is short for an inexperienced crew/team, an eternity for a moderately experienced crew/team with a very specific strategic goal in mind for the flag and short for an experienced crew/team that wants to know the home territory to get the absolute best strategic placement for the time given.

    This kind of intense exploration and related coordination of shared info among ship officers and possibly multiple ships on a team for the intent of placing the flag hones the team spirit at the start of the game IMO. It can also point out weaknesses in a team that will have to be overcome on the fly during the hunt.

    I recommend spending your energy on different terrain motifs (which you're already doing) rather than trying for a code split to get a broader overview.

    I'm sending you another version to test, KK. I got tagging working this weekend, I think, but I did not extensively test - just the bare bones test scenarios.
  • Thanks for the thoughtful response Xansta. I agree. I will incorporate a good overview of the setup phase area dimensions in the game pre-brief and will emphasize the need for efficient communication/decision making. The rest will be up to the crews. ;]

    I will begin on next round of testing this evening and then continue with terrain motifs after this round of testing is done. I have an idea brewing... think 'inter-dimensional shifting' .... ;]
  • I think the current incarnation is at least marginally playable. If anyone is interested in trying it out (for entertainment or for test purposes), go here:
  • Thanksgiving prep has the family a little preoccupied, but will get to testing it soon!

    (BTW, I noted you incorporated the first terrain motif directly back into the scenario script file. You don't think keeping the terrain motifs in a separate file is a good approach?)
  • Separate files could be good. I've had issues in the past when I tried that, but it could have been just be my lack of familiarity with LUA
  • Ok, after a week, I'm finally getting to testing your latest. Thanks for your patience. Working it now... Hopefully results posted later this evening.
  • edited November 2018
    Greetings Xansta!

    Ok, I was able to get a little done this evening. Felt good to get back in.

    Here's what I was able to confirm using the 2018.09.06 release. (These test cases pick up from my previous list; I didn't have the time to do any regression testing tonight, sorry.)

    TC-B1: during game phase, when in opposing territory, if a ship does not first scan the opponent's flag artifact, then the ship cannot pick up the flag
    - TSN: confirmed
    - Kraylor:

    TC-B2: during game phase, when in opposing territory, after scanning the opponent's flag artifact, then the science console properly indicates that the opponent's flag artifact has been scanned
    - (observation): it took a little effort to the get the 3 level deep scan accomplished on the flag artifact; consider lowering the scan complexity
    - TSN: confirmed
    - Kraylor:

    TC-B3: during game phase, when in opposing territory, when a ship does scan the opponent's flag artifact, then the ship is able to pick up the flag
    - (observation): there does not appear to be any indication on any console screen or in the ship's log that the flag has been successfully taken
    - TSN: confirmed
    - Kraylor:

    TC-B4: during game phase, when in opposing territory, after successfully scanning and picking up an opponent's flag artifact, the game shows the correct team to be immediately victorious when the carrying ship crosses back into its own territory
    - TSN: confirmed
    - Kraylor:

    I have confirmed today that I have to go on a trip starting Monday and I'll be out of town for 7-10 days. I will still be in contact while traveling, and will do what I can while away, but my time will unfortunately be more constrained. I have some other thoughts and what-not that I hope to share soon.

    Thanks again for your work on this! Very much appreciated.
  • If a human picks up the Kraylor flag, it disappears. There's no other human notification. On easy difficulty, the Kraylor relay officers are told which enemy ship picks up the flag. On normal difficulty, the Kraylor relay officer is told that the Kraylor flag has been picked up, but not which ship picked it up. On hard difficulty, there is no Kraylor notification.

    I just added notification to the ship log for the ship picking up the flag.

    I just changed the flag scan difficulty to match game difficulty.

    No worries on testing scheduling. Right now, you're likely to be the primary user.
  • Aha! I wasn't watching Kraylor screens when TSN picks up flag. Roger. I'll be sure to have both ship's consoles open while doing more tests. (Note to self, should have picked up a couple of extra monitors on Black Friday... ha) And thanks for the memory jogger on the notifications changing depending on difficulty level; now I remember having that conversation... ha.

    Ok, I will write a more complete explanation later, hopefully this evening, but how much work do you think it would take to increase the number of player ships to a max of 20?

  • O.o where are you getting all these people O_O
Sign In or Register to comment.