Capture the Flag in EE

2»

Comments

  • Short story is that my next major event in Feb will have ~40 active players in a Fri-Sat "lock-in". During the lock-in, we'll run 6 full ship crews (6-8 players each) for various scenarios, but for Capture the Flag specifically, we're going to break the large crews apart into 2 person "fighters"; 1 person will operate the helm/weapons, the other person will operate science/engineering/relay; we'll thus turn our 40 players into (max of) 20 fighters (10 per side). Our experience with live CtF is that numbers of players definitely improve the experience, and we want to translate that into the EE arena. There's more to it, and will write a better explanation a little later this evening. Real job is pestering me at the moment... ;]
  • ...lets just hope we can concert some to remote players too ;)
  • As a matter of fact, I've been considering just that.... ;]

    I have a test/prep event scheduled for 11-12 Jan; we have to stress test the entire setup prior to the event, and I was thinking of including remote access for the test event in prep for the full event. First things first though! ;]
  • hahaha, 20 fighter ships with 2 crew each.

    But give me some time, and yes, I'm reaching for the bigger numbers...
  • @Xansta -

    Thanks for your very considerable patience while I dealt with family matters and took some time for Christmas.

    I really appreciate all you've done to setup this CtF script. I've spent a few hours with it, and the basic functionality is pretty solid. Well done! I'm very excited to bring this script to our main event coming up in February. We're going to have a limited test event this coming weekend, and although we won't be able to fully run all ships, we will have some additional folks gets hands on and see if they find any other issues.

    Here are my latest observations/comments/requests. Please note the parentheticals that indicate whether it's only a comment/observation, or a change request.
    • Because this scenario script will likely continue to evolve, please add a version number to the name of the script so it can be easily identified in the EE scenario menu; from my count, we're currently up to version 0.4.
    • Regarding ship names (just observations for now; no changes needed):
      • For our group and the way we're organizing our event, we need to have an efficient mechanism for command and control of a wing/fleet, and to do so, the ship names need to be named for efficient organization, i.e.:
        • Crews can easily select the correct ship according to fleet/wing
        • Squadron commanders can identify and communicate with their ships
        • wing commanders can easily identify and communicate with their fleet
      • However, because the EE GameMaster console/screen gives excellent control over many in-game variables, I can change the names at game-time and the code doesn't need to be changed now to support our Feb event;
        • Question: does changing the ship names in the GameMaster interface/console negatively affect the scenario script at all?
      • Just FYI, in case you want to consider for possible changes, this is the naming schema we intend to use for our events, assuming there will only ever be two sides in a CtF match (but there could also be some non-aligned marauders):
        • Human squadrons will be: Alpha (1-2), Bravo (1-2), Charlie (1-2)
        • Kralor squadrons will be: Red (1-2), Blue (1-2), Green (1-2)
    • Regarding the "random" environment (just observations for now; no changes needed):
      • Because we're hosting a competition between teams, the randomness of the environment can create an unfair advantage for one side over the other, and I need to avoid that as much as possible for our groups
      • However, this may not be an issue for other groups and isn't really so much of an issue that must be changed as it is an "awareness" item as others may not care about the fairness/balance between the two sides
      • I am planning to build at least one more environment prior to our event in Feb, and you've already built in the ability to choose between environment functions, so it's not an issue that needs to be explicitly changed at this time, but one that we might want to think more carefully about going forward
    • Regarding the starting position of the player ships (just observations for now; no changes needed):
      • The starting positions in the init() function do align the ships in a symmetrical fashion around the center station, and I had several thoughts about this placement and whether or not it would be better to put the ships farther into their own areas, but then I saw in the scenario script where you put the starting position array very near to the top of the init() function and did my own experimenting of where the ships could go.
      • So, really, it's a non-issue because you've made it very easy for a GameMaster to assign their own starting positions depending on how they'd like the scenario to begin.
      • Thanks for making this so easy! 8-)
    • Who has the flag? (please consider making this change)
      • It's not clear from the instructions who will have the flag when the game starts (I determined just through observation that it is the first 2 ships in the player ships queue)
      • I can manage in the short term just by explaining to our crews, but in the longer term, we might want to provide a clear indicator on some screen ref which ship has the flag at game startup, just to avoid confusion.
    • Regarding setup time: (please consider making this change)
      • Although we can track the setup time via mechanical means, it would be nice to have an indicator on a console or main screen how much time is left in the setup time. Basically a countdown timer.
    • ** Regarding capturing the flag: (important; please consider making this change)
      • We really do need some sort of indicator that a ship is carrying an opponent's flag
      • Yes, there is a log entry and that's good, but there really needs to be a more obvious indicator
    • Regarding respawning location: (just observations for now; no changes needed)
      • I was going to make some observations regarding the respawning location, but then I figured out that you're using the start location as the respawning location, and because it's so easy to change, it's a non-issue to change it to suit a particular scenario/environment layout. Thanks again! 8-)
    • ** Regarding overall remaining play time: (important; please consider making this change)
      • Although we can track the game time via mechanical means, it would be nice to have an indicator on a console or main screen how much time is left in the game time. Basically a countdown timer.
    (continued....)
  • edited January 7
    • Regarding the total number of player ships: (just observations for now; no changes needed)
      • I appreciate your previous input about it would be too much for just two people to run all the stations for a ship
      • We're going to experiment this weekend with both 3 and 2 person ships and see what our test crew thinks
      • This matters because if we reduce the number of people flying a single ship, then that means we can increase the total number of ships in the game
      • However, I know you've expressed concerned about the script complexity and possible negative effect on the update() function, so we're going to work with what you've set up and keep to a maximum of 12 player ships for our Feb event.
      • We will probably come back to this issue; I'm going to take a closer look at the update() function to see how we might simplify/remove some elements
    • ** Regarding the "Drop Flag" button on the Weapon's console (please consider making this change)
      • Related to the previous comment group regarding a reduced crew to operate a ship, I was planning to use the "Single Pilot" screen in order to combine helm and weapons, however, the "Drop Flag" button doesn't appear on this combined purpose screen.
      • It's easy enough to work around this issue just by having the ship carrying the flag remain in the intended location for the flag drop until the setup time expires, however, it would be nice if the "Drop Flag" button could be added to the "Single Pilot" screen.
    • Regarding environment setup functions: (just observations for now; no changes needed)
      • I know I'm going to be creating more environment setup functions that are intentionally designed.
      • In order to reduce the complexity of the scenario script, I would like to put the environment setup functions back out to a separate file (like what is currently done with "utils.lua").
      • Assuming I can find the time, would you mind if I reworked the script structure to use a separate file for the environment setup functions?
    • Regarding the whole bartering system at the space stations: (just observations for now; no changes needed)
      • I'm wondering if this is really needed in the CtF scenario, and if not, would we be better served by removing and simplifying the script?
    Again, thank you so very much for all your work!!
  • Changing the call sign of the player ships does not adversely affect the script
  • For squadron purposes, I can name the ships. However, I'd need to know a standard grouping. Without guidance, I'd assume this:
    Ships/ Names Team Human Kraylor ------ ----- ------- 01 Alpha Red 02 Alpha Red Bravo Blue 03 Alpha Red Bravo Blue Charlie Green 04 Alpha1 Red1 Alpha2 Red2 Bravo1 Blue1 Bravo2 Blue2 05 Alpha1 Red1 Alpha2 Red2 Bravo1 Blue1 Bravo2 Blue2 Charlie Green 06 Alpha1 Red1 Alpha2 Red2 Bravo1 Blue1 Bravo2 Blue2 Charlie1 Green1 Charlie2 Green2
  • Symmetric random is on my list of improvements, but I have not gotten there yet. As you mentioned, you can plug in the terrain you desire.
  • As you noticed, I put the starting positions in an array at the top of init for easy modification. Ship rotation (which way the ship faces when spawned) is still random. Keep in mind, this is also where the ship goes when tagged while in enemy territory.
  • Added text to the description stating that the ships closest to the referee station will set the team's flag. This means that if you change the player ship starting locations, you should keep the first ones in the array closest to the mid-point where the referee station is located.
  • The referee station constantly renames itself to include the time remaining in the current phase (set up or hunt). If you're not seeing this on relay, helm, weapons, science, this is a problem. If your teams need/want to track this, they should have relay leave a probe near the referee station before they take off to explore. I'll consider adding a message to the main screen.
  • "Drop flag" appears on the weapons screen and on the tactical screen. I didn't include it on single pilot screen due to the inherent cooperative nature of EE. I know that some screens cannot have buttons added to them. I don't know if the single pilot screen is one of those excluded screens. I'll investigate
  • To extract the environment to a separate script is fine. I assume structural changes would be relatively minor. I've had issues with separate scripts in the past (as I mentioned), so I avoid that. If you've got different environment scripts, you may end up always modifying the main one to point to the desired one or renaming the external ones to suit your needs. I took the script line approach because it seems like the same amount of work to change the line in the script to require an external script as it does to change the line in the script that refers to a different environment function within the script.
  • Bartering came with a copy/paste. I also had the idea that the bartering could lead to ship improvements (like is done in other scripts), so a team could spend their time chasing the flag or improving their ship. Improvements include faster ship speeds, better beam weapons, faster turning time - all which could benefit a team. It's outside the typical capture the flag paradigm, true, but adds something you might not find in other capture the flag scenarios.

    The improvements are not in the script yet.
  • Thanks for the speedy reply. I'm neck deep in a work project, so will need to respond tonight.

    One quick comment, I didn't realize the timer was incorporated in to the central station name, ha! Just didn't pay that close of attention to it. Very clever!
  • Hey Xansta -

    Thanks again for the speedy reply.

    Ref ship names above in yellow, yup! That's just what I was thinking. For simplicity sake, the numbers can always be attached. It won't bother us at all to call "Alpha-1" even when there's only one "Alpha" in mix. However, you can do either way as you think best.

    Thanks again for making the ship starting/spawning position array easy-cheesy!

    Thanks for clarification ref the ship closest to the referee station is the one that gets the flag. I thought it was just the first one in the array. Very good to know.

    Ref the "Drop Flag" button on weapons and tactical consoles. The only reason I thought to use the single pilot console was because it also incorporates the forward view screen as well. While doing our 12 ship CtF setup, I probably won't have enough extra monitors to give each ship a dedicated view screen, hence the interest in using the single pilot console. We can definitely use the tactical console in a pinch, or use the single pilot console and just use the work-around of waiting until setup time expires for flag drop. If you're able to work the "Drop Flag" button onto the single pilot console, then that's icing on the cake. If not, we can definitely use what's already there.

    Ref putting the environment setups in a separate script file. Thanks. We'll see if I have the time. I did do a small amount of testing back in October to see if having the environment in a separate script file behaved properly, and it seemed to do so. You have probably done much more extensive testing than I have. My principal concern is that if I end up creating 5-10 environments (which I do intend to do), I'm thinking it will make the main script file unwieldy and overly complex. It's already pretty darn long.

    Ref bartering. I like where you're going with that. Essentially a kind of crafting for EE. Ok, let's keep it in and see where it goes! ;]

    Again, a gazillion thanks for your labors. Before our Feb event, I need to tune the "Just Passing By" environment with stations, and create another that's in my head... it will involve wormholes. ;]

  • Clarification: the ships that drop the flag are the first pair spawned. It also happens to currently be the first pair in the array of starting positions. I modified the instructions to state that. If you fiddle with the starting positions and the first pair spawned is no longer the closest to the center, then the instructions will be misleading.

    The long script can be made less unwieldy by good sectional comment blocks. Notepad++ color codes the comment blocks in green making scrolling to the necessary section relatively easy.

    I'll send you the updated version here shortly, KK
  • Most awesome. Thanks Xansta! I'm building machines tonight (acquired more for our event), and will load this up tomorrow.
  • Hey Xansta -

    You ever have one of those times when you think you've discovered a flaw in a system, then only to realize it's really not a flaw at all, and the system design is robust enough to accommodate? I just had a thought like that ref the CtF design. Here's the down and dirty.

    Team A plants their flag, and a ship stays immediately adjacent to guard it. If a Team B ship approaches within 1U to try to grab the flag, they will automatically be tagged and teleported because of coming within the 1U distance of the Team A ship. I thought this was going to be a flaw, then I thought that this is no different from how we do live play. Teams will often leave a guard or guards at the flag. The trick is to get Team A to leave the flag long enough to allow Team B to grab it. In live play, we do that with numbers of players and feints. In EE CtF, it could be done with stand-off missles and HVLI.

    So what I thought was going to be a problem really isn't, but it will probably make for some exciting game play at some point!

    Again, well done on the design. It's gonna be cool... ;]
  • (For anyone else following this thread, I've created another thread to summarize our Leadership Lab events, link below):

    http://bridgesim.net/discussion/427/kilted-klingons-leadership-lab-events#latest
  • Just wait until your players figure out they can lay a minefield around their flag. *then* try to figure out how you'll handle it (maybe choose ships with no mines)
  • Hahaha, yea, I already thought about that. It's a valid tactic! We'll see if anyone decides to try that and how the others deal with it! It'll be entertaining for sure. ;]
  • Make mines rare and expensive if the proof very powerful?
    But, I think they would be a much help as hell, as damaging yourself or teammates will most likely be easy in some chaos.
  • Yes, it's easy for a GM to lay a mine field, another thing entirely for a ship to do it. ;]

    I hadn't thought about making mines expensive. Will have to give that some thought! Will certainly make them use them more judiciously.
  • edited January 24
    As - at least on full crewed ships - there is a way of clearing a minefield that is easier and cheaper* (maybe even safer) than laying one out, that won't be a game breaker.
    And I agree, it would be interesting to see if the other team will find a way to deal with it (like figuring out they have "anti-mine-devices" in relay that get restocked for free* on stations).
    Like daid said, you can make them more expensive if they proof too powerfuI, but I doubt they will.
    this

    *As that restock takes time, and time is literally money in EE, that is not entirely true, and in practice mines might ultimately be cheaper than probes. But I guess that have to be figured out in the game. And least with jump engines that should not matter much, as you can clear every mine within 0.6u with a single probe. So you could deploy about 3 of them around the flag, then jump in.
Sign In or Register to comment.