Ran First EE Event -- Great Time

Greetings Daid/Nallath

First posting here. Wanted to say thanks very much for your having put so much effort into EE. I've been using Artemis to sponsor team building/leadership lab exercises for the last two years, and just this last week ran my first two EE events. Those who had played Artemis before definitely liked the upgrade in EE, and those new to starship bridge sim play got their first experience with EE.

I have to say, right off the bat, that the Game Master capabilities are simply awesome. Easy control over all elements in all scripts. Exactly as it should be. And it doubles as a level builder/editor. Wow! Thank you so very much for having put the effort into this!

I created a race scenario through a nebula maze wherein ships on opposite sides had to be the first to reach the only station somewhere in the maze. Of course, there were a plethora of enemies to deal with. The point of the exercise was to use different tactics at different points; sometimes you have to sneak, sometimes run, sometimes fight, and it was important to know when to do different tactics. About 75 active AI entities in the script. All had a great time! 8-)

I hope you don't mind, but I'd like to offer some feedback as someone pretty new to EE (only 3 weeks), and also to recommend a few suggestions.

Things we liked:
1. Overall
a. Auto-location of servers on LAN. Excellent.
b. Simple toggle between full screen or windowed mode. Effortless and just works. Also excellent.
c. Introduction of orbital bodies and wormholes. Uh, yes, please.
d. Very much appreciated the built-in tutorials. Helped get new players up to speed quickly.
2. Science
a. Love the addition of the data base feature; I actually had a player researching species during game time to give the crew intel on how to deal with their encounters.
b. Love that nebula are a variety of colors.
c. It was a huge and pleasant surprise to see that nebula occlude the area behind them. Huge kudos for implementing this. Now ships can hide and employ advanced tactics. Most excellent.
d. Active, multi-layer scanning is a bonus and requires at least some work to actually accomplish aside from simply pushing a button. Well done.
3. Weapons
a. At first we were disappointed that a ship is not able to lock onto an incoming missile to shoot it with ship's beams, but after some discussion, we decided that the defensive tactical shift to forcing the helmsman to actively avoid the missiles was an overall positive change. The defeat of missiles in Artemis was sometimes too easy for the cost/effort of using missiles, and having to dodge them is a lot more fun (and suspenseful!). 8-)
b. Rail gun - (HVLI) - bravo. Great addition. Gotta love a high velocity, rapid fire rail gun.
c. Definitely applaud the more realistic missile firing solution geometry calculations. Well done!
4. Relay
a. Wow. You guys clearly put a lot of thought into this. Kudos.
b. Love the probes and being able to link to Science.
c. HUGE thanks for implementing open texting to other human players. We typically run TeamSpeak in parallel and give this to the "Comms" officer, but having built-in texting is definitely a step up from before.
d. Overall large map capability is great.
e. Being able to set way-points is also great given the large playing area.
5. Engineering
a. Intuitive and well laid out. Love being able to simply select a repair crew and tell them where to go to fix a system. Very simple.
b. We did a "Self Destruct" just for fun, and really liked the way you implemented a multi-crew agreement approach! Well done.
6. Game Master
a. Simply awesome. Thank you. Thank you. Thank you.

Observations from running our first scenarios:
1. The game seems to be sensitive to increased wireless network load, or if the wireless network encounters interference.
a. Occasionally, and only when running on WiFi, the server would seize/crash.
b. We ran a variety of scenarios, and clearly it was finicky when we were on the wireless connections. Everything ran beautifully when wired.
c. To compare, we ran Artemis under the same wireless network conditions, and it was much more resilient under the same conditions and seldom crashed. I can give you more details if you're interested. We were running InterMapper as a network health observation tool during the latest event (although we didn't record data, we were actively using it to examine network health during game play).
2. We think there might be a bug regarding main screen controls. If multiple people have the controls available, and if they might be trying to change the view perspective near the same time, it seemed to crash the game. We resorted to letting only one person having main screen controls, and that seemed to take care of the problem.
3. There seems to be a rather large number of freighter type ships available, and the taxonomy of the main player ships seems… well, somewhat befuddled. Perhaps I know someone who might be able to help suggest a better baseline ship taxonomy….

Some initial recommendations/requests from a N00b
1. Please provide a clear indication on each player console screen what ship they are assigned to. When running multiple ships/crews and sometimes having to troubleshoot issues, being able to confirm the assigned ship from the player's screen is helpful.
2. From the GM screen, please consider making it more clear that you are in "create/placement" mode and perhaps what item it was that you chose to create/place.
3. We noted that when a ship's call-sign is reassigned, then it forces all the crew members to go back to re-select their stations. Was this intentional? Please make it possible to change a call-sign without kicking the players from that ship.
4. I really like the addition of being able to have some bodies orbit others. Please consider allowing stations to orbit other bodies (suns, planets, black holes).
5. It's awesome that the GM can control so many aspects of the ships functionality. However, there doesn't seem to be any way to affect the probe count. Please add this.
6. As GM, I would like to be able to zoom out more to see a larger scale map/scenario.
7. As GM, I would like to be able to control the contents of supply drops in the same way that I control ship attributes. I know I can set the supply drop contents via script, but would like the option of modifying contents during game play.
8. 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.

I think that's it for now. Thank you again for all the love and effort you've put into EE. We had a great first experience and are looking forward to more. We're already planning out next event in early December.


(aka the Kilted-Klingon)


  • BTW, apologies for the structure in my first post. It all looked great in the editor, then when I posted, it pushed the indented outline all the way flush-left. Ugh. Sorry.
  • Don't worry, it's still very readable and structured.

    On observations
    We never ran on wifi for the above reason. The network code tries to correct for flaky networks, but it's hard to test/debug.
    Note, that if the game crashes, it generates a crash log. That helps in debugging the source of the crash.

    There is a bug with the mainscreen controls, never managed to track it down, but crash logs point in that direction.

    As for the base ships. I've created EE more as an "engine" then a full game. You're free to adapt and add contents. Pull requests are always welcome.

    On recommendations
    First off. I've partially moved on from EE. I no longer spend a lot of active time developing it. I used to have regular play sessions, which really boosted my willingness to work on it. But my life has changed (got a kid) and now I haven't played it in about a year.
    So don't expect anything major from my side. Other people are working on patches and sending in pull requests. So the game is slowly improving.

    Orbiting stations didn't work really well when I tried it with the network code (which docked ships). So that's why I didn't add that option.

    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.
  • Thank you daid for this game. I too had a first session albeit not as intense as James'. There were four of us and we did have a great time. It's interesting to hear about the wifi issues as we too encountered similar issues and once I got the server on ethernet and one other client all was fine.

    I have now gotten DMX lighting to work with the game, which is really cool. I look forward to the next opportunity to play with a group.

    I have never played Artemis, but from what I read I really get the sense that EE is better, even with its grassroots creation and maintenance. daid really made a good good here.
  • Thanks for the response Daid.

    I told my compatriots about your response ref "we never ran on wifi for the above reason" and we had a good laugh. We spent a few hours going through test scenarios to come to that conclusion when a simple question via email might have sufficed. ha

    Totally understand ref having to spend time on higher priorities. We have 5 teens at home. Totally understand. ;]

    Thanks for the recommendation for the "flag" object. Sounds like there's a lot of versatility in the scripting abilities. So, is there a handy reference apart from the source code for all class/attribute/methods that can be manipulated via script? If not, np, I will endeavor to get set up to request a pull. Been awhile for me writing C++, but would be glad to do so again.

    Do you have any sort of notification list for when updates are posted and a new version is available? Or just monitor this discussion board?


  • There is an autogenerated file 'script_reference.html' in the program folder (or in the build directory, if compiled by yourself), which lists all available scripting functions.
  • 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.
  • 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.


  • edited November 2018
    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.

    Also: 6 ships fully crewed, that's a LOT of clients! I'm kinda proud that my code holds up against that many. I've never ran above 14 clients (which was causing issues back then due to network code bugs, which have been long squashed)
  • 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.

    Ref 6 ships/crews, I need to clarify. That was in our previous events running Artemis over WiFi. And we did have 36+ clients successfully connected and all participating. We've done this a few times over the course of the last 2 years.

    I ran two events last week using EE. The first event was just a single ship "let's try this out" with friends, the second event was a full-scale test to see if we could run 6 ships over WiFi, but that's when we had the EE stability problems on WiFi and determined that we needed to go wired only. However, we were only able to wire up 6 consoles for one ship during the full-scale test (the ship/crews are in separate rooms and we simply didn't have enough cabling on hand). We are organizing another full-scale wired test for EE in January to determine if we can get 6 fully loaded ship crews operating. My fervent desire is that it will be stable as I want to make the switch to using EE for our leadership lab events. Our next full-on leadership lab event is in Feb. My apologies for any confusion I caused.
  • Everyone wanting to discuss CtF in EE, please see the separate/focused thread I've created to discuss.
Sign In or Register to comment.