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.


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)


  • 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 @Xansta picked up on this topic and graciously offered to help code up the scenario script; see the whole thread here:
      • 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.


Sign In or Register to comment.