Kilted-Klingon's Leadership Lab Events

edited January 21 in EmptyEpsilon
Greetings all -

I thought to start a separate thread to document our leadership lab / teambuilding events.

Some quick background. I organize these events for a Scout Troop on the US East Coast. Our goal is to use the starship bridge sim software as the mechanism through which to teach leadership skills and overall good teamwork in a fun and engaging way. This will be our third year running the event.

In addition to running the bridge sims and everyone having a great time, one key element of our events is that each bridge crew has an assigned "Mentor/Evaluator". This person typically has some military/leadership experience, and their role is to mentor the team by providing feedback after each event. The M/E leads the group in an After Action Review to discuss how the scenario went, how effectively the crew met their objectives, what could they have done better, etc. We think the M/E role and AAR activities are essential to the overall experience. It's gaming with a purpose.

Because we also run the events as competitions, the M/E's are also responsible for scoring the teams. We have evaluation sheets that are mostly the same, but have some tailoring to the specific scenario being run. We give prizes to the best performing teams.

So you have an idea how our physical area is set up, here's a simplified floorplan drawing of the activity center that hosts our events. It's not exact, but close enough for this purpose.

image

https://drive.google.com/file/d/1qnBCkCAvZYDQUopbNKh5Bx2PUcBmblpL/view?usp=sharing

As you can see from the floorplan, we have the physical space to set up 6 complete bridges (and more on other floors if we have the participants/computers). We put a ship in the large open area to make it easy for parents/visitors to see a bridge crew in action, and we encourage everyone to sit in and play a bit. Having one ship in the large gathering room makes this easy. Keeping the GameMaster's command center in a separate room keeps the traffic down and that area under control. Of course, isolating the bridge crews from each other keeps them from overhearing each other and forces them to use the ship comms, whether they are playing cooperative or competitive scenarios.

Each ship is outfitted with 6 Dell laptops (of various flavors) and most rooms have a large screen monitor to serve as the forward view screen. I use a mid-tower Dell or a beefed up laptop as our simulation server.

This is our typical "flow" for each scenario:
  • Ship Captains and their M/Es gather for an in-briefing
  • GameMaster explains the scenario objectives and answers any questions related to the instructions
  • Ship Captains and M/Es gather with their crews in their ship rooms, and the Captains explain the scenario objectives and provide their orders
  • GameMaster orchestrates the scenario; Captains run their ships to accomplish the objectives; M/E's observe and take notes on crew performance
  • Scenarios can last between 45-90 mins, depending
  • At the conclusion of the scenario, the M/E leads their crew through an AAR discussion; we provide 15-20 mins for this discussion
  • Short break, and get ready for the next scenario
  • At the end of the event (and sometimes in the middle), we have an all-group discussion to walk through various points/issues/topics that are relevant to their scenarios and performance.

Also, in order to run the events, I usually have a tech crew of 3 or 4 who are dedicated to going between the rooms to fix the inevitable problems that pop up and they keep everything running smoothly. We use hand-held radios to communicate. (All M/Es also have radios to ask for assistance as needed when issues pop up. Mr. Murphy is a constant attendee at our events… ha)

Comments

  • Inaugural Event, Feb 2017:
    • Software: Artemis
    • Bridge Crews: 6
    • Scenarios:
      • Earn Your Wings: basically learn to fly the ship and work the stations
      • The Advancing Horde: all bridge crews work together as a single fleet defending their respective stations against an enemy fleet; bonus points are given to those crews who coordinate their actions with other ships and not just "go it alone". Respawning is allowed, but at a significant point penalty.
      • Limited Resources: all bridge crews work together as a single fleet to defend a single star base against an enemy fleet; the challenge is to coordinate between ships who is going to dock in what rotation in order to re-arm and re-fuel; there is no designated wing commander and all Captains are peer equals, so they must effectively collaborate. Respawning is allowed, but at a significant point penalty.
      • Sealed Orders: instead of openly briefing the ship Captains and allowing them to ask questions, each Captain is given a sealed envelope with their orders and told to report to their ships to read. No direct questions are allowed. They will find that their fleet has been divided into two teams and the two teams must duke it out. Respawning is not allowed.
      • Red Dawn: civilization has completely broken down and it's every ship crew for themselves. Mass melee. Respawning is not allowed.
      • New Alliance: The fleet comes back together when a new alien fleet arrives and threatens to wipe them all out. (Essentially bringing us back to "The Advancing Horde".) Respawning is allowed, but at a significant point penalty.
    • Tech Notes:
      • Comms: Because ship to ship comms is fairly limited in Artemis, we gave each ship's comms officer their own hand-held radio which allowed for open/free voice comms between the ships. For the "Sealed Orders" scenario when they were split into two teams, we assigned each team their own frequency and they were forbidden to switch frequency to "eavesdrop". Tech Crew was on their own separate frequency.
      • LAN: We ran everything on the building's WiFi and the game performed adequately well. There were a few glitches, but overall I kept the enemy ships to reasonable numbers and overall it performed acceptably well.
    • Summary Notes: The event was a big hit. We had about ~60ish in attendance, including all participants, M/Es, and Tech Crew. The general consensus was that we should do it again next year, and I started making plans on how to improve it and make it "bigger".
  • edited January 21
    Main Event 002, Feb 2018:
    • New/Additional Objectives:
      • Increase the number of ships to 8
      • Introduce using TeamSpeak as the ship-ship communication method instead of hand-held radios (keeps it more "in character" by using a computer console tool, plus allows for free-form text in addition to voice comms)
      • Introduce a mechanism to feed video from each ship room out to a viewing station in the large gathering room
    • Software: Artemis
    • Bridge Crews: 8
    • Scenarios: (I used the same scenarios that we used during the Inaugural Event; please refer to those descriptions.)
    • Tech Notes:
      • Ships: We did set up 2 more ships in rooms on the 3rd floor of the building . Artemis does support a maximum of 8 player ships in a single scenario. We did end up shutting down the two extra ships part-way through the event because of problems encountered with the network. See below.
      • Comms: We setup a TeamSpeak server through an online host and installed TeamSpeak on all the comm officer's consoles. We gave each of them an additional monitor attached to their laptop so they could run both their comms console and the TeamSpeak simultaneously on the two screens. TS was also setup on the GameMaster rig. The M/E's and Tech Crew still used hand-held radios so we could communicate ref performance problems. For the most part, TS ran acceptably well and did what we needed.
      • Video: We added USB cameras to the computers that were running the main view screen and oriented the cameras to capture as much of the room as possible. We used a free video teleconferencing software package to send the camera video to a single computer in the large gathering room that was hosting the "call" between all the rooms. We made it so that each ship was broadcasting, but not receiving (took a little bit, but we got that to work). The end effect was that you could see each ship crew on the "conference call" on the single monitor in the gathering room.
      • LAN: We ran everything on the building's WiFi and experienced significant issues. Read below.
    • Summary Notes: The event was a near disaster essentially because we ended up overloading the WiFi network and everything suffered. Although we showed that it was possible to increase the number of ships, use TeamSpeak, and to pipe the video to the gathering room, it was all too much for the building WiFi to handle. We ended up shutting down all video feeds, turned off ships #7 and 8 completely, and discontinued using TS as well. We went back to using the hand-held radios between ships. Once we did these things, then we were able to get through a couple of scenarios. In the end, I realized I came out of the Inaugural Event over confident on what the WiFi could handle and planned to introduce too many new items without testing them in the target environment first. Big mistake (insert face-palm here). On the positive side, everyone seemed to take it in stride and said that we should still do another, but I promised to find a solution to the network issues.
  • Test Event A, Oct 2018:
    • Preface: I was very busy most of 2018 and the earliest I could get to a test event was October, but I was thinking a lot about it all during the year. During the May/June timeframe was when I first became aware of Empty Epsilon, and after playing around with it for a bit and testing it at home, decided to use it instead of Artemis for our events, but I would be sure to test it at the host facility first.
    • New/Additional Objectives:
      • Use Empty Epsilon instead of Artemis
      • Use our own local TeamSpeak server so that all comms traffic stays within the LAN boundary and does not need to bounce to an off-site host
      • Introduce a new mechanism to feed video from each ship room -- we decided to try using SteamLinks at receiving stations in the large gathering room
      • Regarding the network, the overall intent of the test was to see if changing the architecture to keep all network traffic within the local network boundary would solve the performance problems. Essentially, we were trying to avoid the cost of switches and cabling if we could and wanted to try this configuration.
    • Software: Empty Epsilon
    • Bridge Crews: 6 (note: we physically set up all 6 bridges in their respective rooms, but I only had a small test crew with me (~10 people), so whereas all ships were "on", only two could have crews at consoles)
    • Scenarios: we mostly used the included "Basic" scenario and dynamically added enemy ships and space elements at will
    • Test Observations:
      • Ships: Although we have enough computers to support 8 ships, we kept to 6 for this test event just to keep it simpler.
      • Comms: We setup a local TeamSpeak server on another Dell box and it worked very well. We can use the free server license given that we are using it strictly for non-commercial purposes and don't need more than their allotted 32 participants for free use. The M/E's and Tech Crew will still use hand-held radios so we can communicate ref performance problems.
      • Video: We decided to try using SteamLinks as a mechanism to pipe the desktop from each ship room to an individual machine in the large gathering room. The SteamLink boxes are set up with monitors in the large gathering room, then pointed back to the appropriate machines in each ship room; we stream the desktop with the USB camera video from the ship room to the SteamLink box so that visitors can easily see and hear the action going on in the ship rooms. We used the SteamLinks because 1) they were super cheap on SteamSale (I ended up getting 10 of them), and 2) they keep the video signal completely within the LAN boundary and don't bounce to any external server thus keeping latency to an absolute minimum. Running the SteamLinks on the WiFi was problematic and we had a lot of difficulty maintaining a consistent link from SL box to their respective computers. Note that when the network link was good, then the desktop feed was also good.
      • LAN: As stated in the objectives above, our intent was to try this configuration in an attempt to still run the events on the WiFi and thus avoid the cost of purchasing switches and cabling.
    • Summary Notes:
      • Although I tested EE at home on a wireless LAN and it seemed to run fine, it would not remain stable in the WiFi environment in the activity center. It would start, but crash soon thereafter. Somewhat frustrated, we set up a jerry-rigged wired network between two ships and the simulation ran solid. Accordingly, we came to the conclusion that the only viable way to move forward with our events was to go with a hardwired network and we decided to get the required gear and conduct another test to verify.
      • Fortunately, during this same event we found out from the facility technical director that the rooms were actually already wired with LAN cabling, but they were physically disconnected in the server room for security purposes. After a short conversation, they agreed to help us and would reconnect the cables on their exterior facing network so we could use the existing infrastructure. We'd still have to acquire cabling and switches to support all the ships, but that would be easy compared to connecting the rooms.
      • It was at this same test event that I had the idea to do Capture the Flag (CtF) via EE, and began a conversation on this topic on bridgesim.net. @Xansta picked up on this topic and graciously offered to help code up the scenario script; see the whole thread here: http://bridgesim.net/discussion/406/capture-the-flag-in-ee
      • It was also during this test event that I decided to try to improve the look/feel of the ship rooms. Understand that they're used as general purpose class/activity rooms for a church, so they have a variety of stuff already in the rooms and really don't feel like a starship bridge. I set about thinking how to improve them and to try it out for the next test.

  • edited January 21
    Test Event B, Jan 2019:
    • Preface: After the previous Test Event in October, we acquired the necessary switches and cabling to support 6 ships and the viewing stations in the gathering room. We also conducted a mini-test with the facility tech director to ensure that the room network drops were properly connected and EE clients were able to see an EE server across their network, and it worked just fine. Additionally, I also designed a solution to improve the "set dressing" for the rooms and acquired enough materials to do one room as a test. It was also during this time that @Xansta and I were working on the CtF scenario. Oh, and Christmas and New Years were tucked in there, as well as an unexpected family emergency that required a trip for 2 weeks. Yikes! Yes, it was a hectic time.
    • New/Additional Objectives:
      • Use a wired network throughout the entire simulation setup
      • Ensure Empty Epsilon was stable and test limits
      • Retry the SteamLinks to see if they would be more stable on the wired LAN.
      • Test the new room "set dressing".
      • Discuss/walk through the CtF scenario with the test crew (there wouldn't be enough people to actually run the scenario, so we'd just talk through the mechanics and look for problem areas)
    • Software: Empty Epsilon
    • Bridge Crews: 6 (note: we physically set up all 6 bridges in their respective rooms, but I only had a small test crew with me (~10 people), so whereas all ships were "on", only two could have crews at consoles)
    • Scenarios: we mostly used the included "Basic" scenario and dynamically added enemy ships and space elements at will
    • Test Observations:
      • LAN: We were able to assemble all the ships with the switches and cabling (there was a bit of a drama with getting cabling at the last minute because of a lost shipment from Amazon… just suffice it to say that the Troop's families are awesome and came through in a pinch!). The wired network worked very well. 1 GB throughout.
      • Comms: We didn't bother testing TeamSpeak during this Test Event because we felt confident about its performance during the previous test.
      • Video: The SteamLinks did perform much more consistently with having all the ships on a wired network. Very oddly however, the SteamLinks themselves maintained a more stable link when on the WiFi as opposed to the wired network. Yes, very strange, but they were stable. Go figure.
      • EE: Rock solid with 6 ships, 6 consoles each. We turned on all machines, and even though really could only man 2 of them, I put at least 75+ enemy combatants in the scenario and it ran smoothly with no glitches. I also ran a couple of my dynamic environment scenarios that have lots of moving planets/nebula/asteroids, and it handled it all very well with no surprises. Success!
      • Set Dressing: it worked well and everyone really liked it, but it did take us a few hours to do this first time. See more details below.
      • CtF Walkthrough: we spent a couple of hours walking through the mechanics of the game with the test crew and came up with a few minor changes, but overall the idea is well accepted and we're looking forward to running it for real during the Feb Main Event 003.
    • Summary Notes:
      • Overall we considered this a very successful test and it has given us the confidence to press ahead to our Feb event. EE performed great on the wired network, and with more complex scenario characteristics than I ever tried with Artemis.
      • We had wanted to also be able to include external players from across the internet to participate in this test, but we weren't able to get the facility firewall configured prior to the event, so we'll have to do this later.
      • Here's quick rundown on the test set dressing we did for one room. The first picture is the classroom "before", and the second is the bridge "after". Without boring you with the details, we used king sized bed sheets with PVC tubing suspended from the ceiling for the screen panels, and they were joined together with wood lathing and binder clips. There are some blue bounce lights behind the screens, and appropriately "spacey" desk lamps by the consoles. What you can't hear is the sub-woofer sound system and an additional ambient ship "thrumming" sound being played. All together, it made for a very nice atmosphere and all the testers/visitors liked it! We're trying to decide whether to make the investment to do the other 4 rooms or not.



      • https://drive.google.com/file/d/1tyalDlpmg4iUl6X7XYBRAeMcgcP5yNwl/view?usp=sharing



        https://drive.google.com/file/d/11rVnFiNmNhJsNIBXSXeQBwC7PrGTwAGY/view?usp=sharing

  • Main Event 003, 23 Feb 2019:

    Software: Empty Epsilon, Custom Mod of base release version 2019-01-19

      • This mod was created by "amir-arad" (user name on EE server on Discord); amir-arad created this mod per a general request I made in the Discord discussion channel about wanting to be able to see planets in the Relay Console map.  Amir-arad was gracious and did the mod and provided a compiled executable that we could use until daid produces another full release version with the modification included.
      • The mod ended up being VERY helpful -- thank you amir-arad!
    • Bridge Crews:  6
      • Although we physically set up for 6 ship crews, only enough people showed up to man 5 of them fully, so 1 ship did go empty.  First time that has happened for us, but there were several other competing events going on this day, and several Scouts had to make choices about where to be.  A little bit of a bummer, but I understand. 
    • Scenarios:
      • Earn Your Wings: basically learn to fly the ship and work the stations; however the space environment is a rather dynamic multi-planetary orbital system… lots of opportunities to crash into planets; we added custom collision detection logic to immediately destroy ships that collided with planets (that ended up being used more often than you'd think it would)
      • Limited Resources: all bridge crews work together as a single fleet to defend a single star base against an enemy fleet; the challenge is to coordinate between ships who is going to dock in what rotation in order to re-arm and re-fuel; there is no designated wing commander and all Captains are peer equals, so they must effectively collaborate. Respawning is allowed, but at a significant point penalty.  Again this scenario also had plenty of orbital mechanics and opportunities for ships to fly into planets and asteroids.
      • The Rescue:  all ship crews must cooperate together to evacuate the crew off a space station and transport the personnel to other space stations.  The ship crews must do this before a near-by star goes super nova and destroys the first space station.  The scenario is timed, and once the GM activates the timer, there is no stopping it!
        • @Xansta wrote the foundational code for this scenario in just a couple of days!  Many, many thanks to  @Xansta for stepping up to do this!
      • Capture the Flag:  yes, capture the flag in space!  This was the first collaboration between Xansta and myself, and Xansta put a good deal of work into creating the core functionality.  I added dynamic environment elements.  You can read the separate discussion thread here:  http://bridgesim.net/discussion/406/capture-the-flag-in-ee#latest
        • Huge kudos and thanks to Xansta for all the hard work!!
    • Set Up Notables:
      • We applied the lessons learned from the previous two test events and used the fully wired network.
      • We also set up the "model ship" with the hanging curtains and lights in just the one room like we did for Test Event B.
      • We added sub-woofer enabled sound systems to all ships and this really makes a difference. 
      • Quite serendipitously, the facility that we use had decided to install all new large wall screen TVs in each of the rooms that we use for our ships, so we were able to use the large wall screens as the forward monitors for each of the ships.  Score!!
      • In the lobby area, we came up with a better way to arrange the monitors that display the piped video from each one of the ship rooms, and we used an overhead projector onto a large drop down screen to display the Game Master's map from the control room so that visitors in the lobby area could see. 
      • In the ship rooms, we decided to try out a new way of setting up the room cameras.  We got some extra USB extension cables at the last minute, and placed the cameras along the ceiling in the rear of the room facing forward and down onto the crews.  It made for a much better camera angle and showed up better on the monitors in the lobby area. 
    • Execution Notables:
      • Streaming the game:  To stream the game to the lobby overhead projector, I ran a Zoom meeting from the main EE server and projected my desktop through the meeting and had another computer in the lobby area also on the "call" and just connected to the overhead projector.  During the game play, I narrated the basic events; Xansta was also in the Zoom meeting and streamed the meeting over Twitch.  Cool!  I wanted to go direct to Twitch, and have a collection of software tools to help do this, but just haven't had the time to practice using the tools enough to be comfortable with it yet. 
      • Comms:  We were going to use TeamSpeak for the ship-to-ship voice comms, but our TS server box was not cooperating and we had to revert to using hand-held radios.  This worked for today, but we really need to make sure the TS server is working before coming out to the event.  It had worked so well for us last year that I hadn't tested it during one of our test events, consequently we paid the price for our assumption… ugh.  
      • LAN:  the gigabit LAN worked flawlessly.
      • Firewall port-forwarding:  We had worked out to assign a specific IP address to the EE server so we could allow external crews to participate in the event, but for whatever reason, the assigned IP address would not work, so we didn't have any external crews participate.  We'll fix this before the next event.
      • EE Software:  Running the mod version as noted above, it worked great and solid for the duration of the single run of approx 40 minutes that we were able to do (ha, surprise!  Read below.)
    • Summary Notes: 
      • So, saving the big reveal for the end.  Everything was working pretty well (except for the dumb TeamSpeak sever).  The EE software was solid, no crashes with 5 fully crewed ships, and over 50 AI enemy ships spawned during the scenario.   Player ships were repeatedly respawned without issue during the scenario as well.  The network was solid, no issues.  Simultaneous Zoom streaming as well as Steam Links streaming from each of the rooms, no problems. 
      • We got through our first full scenario and were doing crew debriefs and gearing up for the next scenario -- and that's when the power in the building went out.  Yes, we had a power outage.  We checked the breakers (understand it’s a 3 story building and not small), and everything was good.  We called the local power company, and come to find out that there was a problem at a local junction outside the building.  They sent crews to investigate and we found creative ways to stall our eager ship crews who didn't have ships.  A little while later, word came back from the power company that they'd have to replace some equipment, and it would take sometime between 2-6 hours to get the job done.  UGH!!!  All this work and preparation only to be done in by a power outage completely outside our control.  Crazy.
      • So we did the only sensible thing, and we packed everything up early and everyone agreed we would reschedule to another date as soon as practical. 

     

  • edited February 27
    Bummer! Good that the participants agreed with a reshedule. Looking forward to the report of this new event.
    I know the handheld radios are meant to be a back-up solution by now, but have they jacks for an external mic? I guess only holding the mic in the hand would fit more to the setting than holding the whole radio. (Having stationary radios would be even cooler, but even though there are pretty cheap ones, I guess that might be too expensive if you have to get 6+ of them)

  • Yea, we were all just rather flabbergasted, but truthfully, not deterred one bit. The whole team is excited at how well the first scenario performed, and they know about the other scenarios, and are excited to reschedule and do it again. 8-)
  • Hello,

    I am with a Planetarium crew that works on this game. I am wondering what you did to the original game, or what current game modes you used for the games you play. Is there a place where we could download a version to see?

    Regards,
    Tony
  • edited March 22
    Find the Capture the Flag scenario here:
    https://github.com/daid/EmptyEpsilon/pull/634
  • @Tony12321: My apologies for the delay in response sir. Major house remodeling going on here and it has the bulk of my attention, sorry!

    Were you referring to the base game or the scenario scripts, or perhaps both? For Main Event 003, we were using a custom mod of the daid's version 2019.01.19. It's only a slight mod however as described above. Daid has accepted the mod changes into the repository trunk and I assume they will be included in the next release.

    For scripts, Xansta and I have been collaborating on the scripts for these events. He's been an invaluable partner! The link for the CtF script is above. I'm not quite ready to share the other scripts just yet - Xansta and I have a new approach that we'd like to employ to organize our scripts to support both individual and multiple ship crews in a cleaner approach. I'd like us to get these scripts rebuilt with the new approach before releasing them into the wild.

    I'm curious, how do you run EE in a planetarium? What does your set-up look like? Single or multiple ship crews? Have a blog or pics to share?
  • edited April 8

    Main Event 004, 5 Apr 2019:

    • Special Event Location:
      • This event was done at work and not for the Scouts.  We have a high-end simulations lab where I work, and we received special permission to host an after-hours team-building social event in the lab.  See pic links below. 
    • Software: Empty Epsilon, Custom Mod of base release version 2019-01-19
      • (see description in previous event write-up)
    • Bridge Crews:  4
      • Although we physically set up for 4 ship crews and I initially had a full roster, 6 people eneded up not being able to come and so we only ran 3 concurrent ships.  Somewhat disappointing, but outside my control. 
    • Scenarios:
      • Earn Your Wings: (same as in previous report, just tailored down for 3 crews)
      • Limited Resources: (same as in previous report, just tailored down for 3 crews)
      • The Last Stand:
        • A new scenario I created to emulate (albeit on a smaller scale) the scenario at the end of 'Ender's Game'.  Three (real human) crewed 'bug' ships (Ktlitans) with a slew (~75) drone ships at their command against a single human dreadnaught.  The dreadnaught must kill the sole remaining bug queen on a bug space station.  The bug ships must stop the human dreadnaught.  The bug space station spawns a new bug fighter every 30 seconds, so the human crews can not dawdle.  The three crewed bug ships are significantly less powerful than the human dreadnaught, but can resupply weapons at the single station with the queen.  The human dreadnaught can not resupply and must manage resources carefully.  There are no respawns in this game. 
    • Set Up Notables:
      • We used a combination of on-premise machines as well as laptops that I brought in, and we had to get them all set up on the same wired network.  The sim lab already has an extensive multi-layered network, so it was just a matter of getting the right ports configured for the right network.  This took just about a day for the 24 machines involved. 
      • The sim lab we used has a specialized "data wall" system that is comprised of 15 vertical monitor "stacks".  Each stack is comprised of three, 50" monitors on top of each other contained in a single framing unit.  Each stack is connected to a motorized track mounted to the ceiling, and can spin 360 degrees, and can be moved the width of the room.  All told, there are 45, 50" monitors in this reconfigurable data wall.  The stacks can be rearranged in many different configurations. 
      • The sim lab uses a highly specialized video muxer that allows one to take the video output from any on-premise computer and place it anywhere on the collective data wall.  And it is not limited to a single instance of said video; you could map the output from a single on-premise machine and replicate it 1,000 times on the wall (it would be a tad small though, ha).  The point being is that it is highly tailorable.
      • We had 3 ships in the main lab space using the monitor stacks, then a fourth ship in an adjacent room.  The fourth ship had a single, measley 80" wall mounted monitor to use for their view screen.  The fourth ship was used in the third scenario (Last Stand), as the human dreadnaught, so that the doors could be closed and the two teams would not be able to overhear each other. 
    • Execution Notables:
      • Aside from some oversights on my part with the third scenario, the software performed exactly as expected and there were no issues with EE.  It ran rock solid in the first two scenarios.  
      • At one point, our largest data wall segment, for ship #3 (Excalibur), the entire data wall just simply shut off.  Obviously, Mr. Murphy was saying hello.  Fortunately, a simple recylcing of the power for that wall fixed the problem and it didn't happen again. 
      • The sim lab also has a reasonable sound system, and we played a ship "thrumming" sound in the background that gave the entire room a great "feel".  Deep base, engine, power sounds. 
    • Summary Notes: 
      • I was asked to keep this event time to a max of 3 hours, and we went to 3.5 hours.  The software performed well, and the sim lab data wall was simply awesome.  Excalibur's screen was literally 24 ft wide by 7 ft tall, and we had multiple consoles mapped to the forward viewscreens (see pics below).
      • Everyone had a great time and it was a great experience.  I truly hope to be able to do it again in the sim lab. 
    drive.google.com/open?id=1afCmkPjv-9mbZ4IaeH_vcO9lvrSX8fKQ

    drive.google.com/open?id=1cNb3P75cPr1KgQGUFfdr2hvcbtFMfICn

    drive.google.com/open?id=1Caee3dTuTDnxNVObIDYS7C8WHRLVAk3k

    drive.google.com/open?id=1XYNkreDFOW_l9Ma1cpebu6ODmwlMpXB2
  • OMG, that screen setup, makes me drool a bit...
  • lol, yea, it's definitely a privilege to be given the opportunity to use it.

    However, real thanks go to you daid for having built the EE platform and allowed us all to participate. Without your work, none of this would have been possible.

    Thank you, thank you, thank you. 8-)
  • Wow. That's a nice setup.
  • edited April 9
    tks kwadroke! Wish I could have frequent access to it, but it's a special arrangement kinda deal. Hopefully we'll get to use it again.
  • edited August 27

    Main Event 005, 26 June 2019:

    • Event Location/Venue:
      • Multi-location event.  This event was done at work and not for the Scouts.  We have many satellite office sites for the company I work for, and the main location for this even was held at our Orlando offices.  I also had a friend put a crew together at his home in northern Virginia, and Xansta assembled an internet based crew.  All told we had approx 21 participants across 4 ships in multiple locations, but the bulk were in Orlando.
    • Software: Empty Epsilon, ver 2019.05.21
      • (daid had incorporated the previous changes introduced into the custom version I was using, so I switched back to the main released version)
    • Bridge Crews:  4
      • (see 'Location' explanation above) 
    • Scenarios:
      • The Last Stand:
        • See previous description.  1 human crew with the Leviathan against the other 3 bug crews.  (Bugs won...)
      • Borderline Fever:
        • One of Xansta's scenario scripts.  He ran from an AWS server.
      • The Last Stand
        • different human crew, and bugs still won; (it was an awesome grame and great fun was had by all) 
    • Set Up Notables:
      • This was a kind of ad-hoc, last-minute collaboration and we cobbled together enough machines to put together 2 ships in the office space, then invited a friend to get a crew together at his place in northern Virgina (NoVA to the uninitiated, ha), and then Xansta put together a crew from a few internet players in Discord.
      • Because we couldn't run a server on the company's DMZ and have external participants reach it, Xansta ran a headless server from AWS so all parties could access it. 
      • No other special set up notables, except that the Orlando office space was a bit crowded... ha
    • Execution Notables:
      • Generally, all things ran well, including the 'Last Stand' scenario code where we have a slew of bug drones fighting a powerful human dreadnaught class ship.  It was quite entertaining.
      • For communication between the ships, we set up a Skype session for the ship Captains to efficiently coordinate between each other during the "Borderline Fever" scenario.  During the "Last Stand" scenarios, the bug crews used the Skype session and the lone human crew simply dropped off the skype session and rejoined after it was done. 
    • Summary Notes: 
      • Even though it was rather cobbled together at the last minute, we made it work and had a good time at it.  The company definitely wants to do some more...  
  • edited August 27

    Main Event 006, 24 Aug 2019:

    • Event Location/Venue:
      • Held at our standard location for our Scout Troop events - a church activity center in northern Virginia (see top of thread for facility diagram)
    • Software: Empty Epsilon, ver 2019.05.21
    • Bridge Crews:  6
      • although we had thoughts towards incorporating internet participants, we stuck to only the local ship crews for this event to minimize complexity; we hope to incorporate internet crews at the next event.
      • We had over 40 Scouts show up, but only had console seats for 36 (6 per ship); we had thoughts of adding some additional consoles per ship (i.e., split engineering or add a duplicate science, but decided against doing so at the last minute as the day was begining at a fast pace...)
    • Scenarios:
      • Earn Your Wings:  (see previous description)
      • Rescue Us!:  (see previous description)
      • Capture the Flag:  (ran 1.5 times....)
        • Xansta and I have been collaborating on this script idea for about a year now?  We began the discussion here in the 'bridgesim.net' blog, but then moved the discussion to the Discord USN server, and then eventually we set up a shared developers notebook space where we can be more efficient about communicating over long term.
        • The big thing to note about this version is that it incorporates drone fleets into the mix!  Each playership is allocated a certain number of drones they can use as they see fit -- for defense, recce, or offense.  It definitely expanded on the range of strategies they could employ.  (The crews used them to great effect!)
    • Set Up Notables:
      • This event was the culmination of wanting to change and improve things off of our very first Inaugural Event back in Feb 2017.
      • We ran with the wired network with a few newer machines added to the mix.
      • We swapped out the SteamLinks and thought that we could just stream the video from the rooms to other machines with Steam on them in the front/lobby room, but this ended up not working so we basically dropped the video feed per room.  I really have to figure out a better solution...
    • Execution Notables:
      • Taking a lesson learned from the the special event back in April, I put together more detailed mission briefs for each scenario, and this seemed to go over very well as it gave the crews sufficient information on the objectives and constraints for each mission.
      • We ended up swapping the 'command center' room from where we had it previously and it worked much better (larger room).
      • The 'Capture the Flag' scenario (ver 0.16.7) did crash once and we had to restart it. I have a pretty good idea what caused the crash in our script, and Xansta and I will work to fix before the next event.  When running the script the second time, we were careful to avoid the condition that we thought was causing the crash, and it ran to completion. 
    • Summary Notes: 
      • Even with the one scenario crash, the event was a resounding success and everyone had a great time.  We had 9 M/E's on hand for the 6 crews, so some got to rotate out.
      • We had a large wall screen in the command room, and this was the center of attention for attending adults as we watched the scenarios unfold and we did a running analysis of the overall strategy being employed.
      • We all agreed that it was worth the wait to get to this point, and the Scouts are eager to do again.  We have more events planned both for Scouts and for work in the coming months.  One in particular is being planned for Mar 2020 at a major Scout event, and there is the possibility we could even increase up to 10 crewed ships!!  We'll see.... 8-)
      • The next event on the calendar is a multi-site event for work... one multi-ship site against another multi-ship site... this will be fun! 
  • The 'Capture the Flag' scenario (ver 0.16.7) did crash once and we had to restart it. I have a pretty good idea what caused the crash in our script, and Xansta and I will work to fix before the next event.
    I try to make it so that scripts can never crash the server. So I'm interested in this as well.
  • Also, I'm not sure if you are allowed or not, but I would love to see photos from these events. It's really inspirational to see my software being enjoyed by so many.
  • Pictures would be nice indeed
  • There will definitely be pictures! I took some, but I'm also gathering from parents. Give me a couple of days to pull the group together and I'll post.

    Ref CtF v 0.16.7, yes, we'll be happy to share. Pls let Xansta and I confer first, and then we'll be glad to share with you. Pls give us a couple of days. Got a lot on the plate.
  • No rush.

    Also, seeing you play trough the internet as well, and the server location is a bit of an issue there. Would it help if there is an option to connect the server to some remote "relay" server that only serves to break trough NAT/firewalls?

    I investigated if NAT hole punching would be an option for EE2, but that is so fragile that I don't even have access to networks in which this works. So I'm thinking about a small simple relay server. Both the client and server connect to the relay, and the relay only passes on the data. Not ideal for ping times, but makes it a lot easier to setup internet games without port forwarding/DMZs. As outgoing connections are generally not an issue.
  • Hey @daid, hope all is well.

    Yea, we were going to try to include internet participants in this last event, but then chose not to. The event was entirely LAN participants with the server on the LAN.

    Ref crashing issue. At first I thought it was most probably logic/table/object management errors in our CtF script, but I made a simple test script that only spawns CPU ships and has no other logic included, and the crash still occurs.

    To make it easier to convey the issue, I put together a video demonstrating the crashes under various conditions from the test script. I've posted the video here:

    https://drive.google.com/open?id=1GMdAoqLozLoL9QIDf5ZINXQZiacUdl0E

    The test script used in the video is here:

    https://drive.google.com/open?id=1hWAO82xTuVbXT1RYBhHMNShrnYNfRXGp

    As stated in the video, the awesome solution would be to have the CPU-v-CPU fights remain stable under reasonable loads; if not that, then understanding the conditions that cause the issue so we can avoid them.

    My guess is that you'll probably want to move this discussion to GitHub as an issue? I'm glad to follow, but have to confess that I haven't made an issue in GH before, and certainly don't mind learning/doing, just being transparent that it's still relatively new to me.

    Many, many thanks for having taken an interest in checking this out. Completely respect your time and cycle constraints. I will say though that having this issue made more stable will have a HUGE impact on our leadership labs.... 8-)
  • (Just a quick follow-on; I just watched the video myself and note that there's occasional jerkiness in how the CPU ships are moving around. That's purely an artifact of the desktop recording software. There was no such behavior being displayed on the screen during the test runs.)
  • Quite likely that is this bug then:
    https://github.com/daid/EmptyEpsilon/commit/b81530519777129f39d1d2015699c201d3e54276

    Happens when a ship is firing a laser and is destroyed in the same game tick. More likely to happen the more ships you have.
  • aha! So, looking at the issue in GitHub... it says it's 'fixed' as of Jul 4? (auspicious date to do a fix! ha) So, if that's true, that would be really awesome that the problem is already fixed. When were you thinking of putting out another release that will include this particular fix?
  • I'm guessing release 10290910 contains the fix. Has the crash occurred with the new version?
  • The fix is rock solid! Have thrown literally thousands of drones in my test script, and it didn't crash once. So, it's 'game on!' for full drone deployment in CtF... just imagine the glorious chaos! ;]
Sign In or Register to comment.