EE After-action report 1

I am the advisor for a university sci-fi club, and we ran an EE night at the club meeting a few weeks ago to familiarize folks with it, and then had it available all day in its own room as an activity at our local free sci fi convention. Following are some notes and feedback from the two events; I've got another event coming up soon as well. They are in no particular order.

Version was 2016-09-02, almost entirely Windows. We did have one person who (with some effort) managed to get a working and compatible Linux version, and a semi-successful attempt to get it running on Mac OS X that was aborted due to lack of time.

I want to point out that despite considerable frustration, when things were working people had a lot of fun.

* Instructions for cloning from the repo are out of date; and the one person who managed to get it to compile themselves had some issues. Among other things, it's apparently not immediately obvious how to get a version that properly matches a particular version of the pre-compiled download version. (Also, the error messages for incompatible versions were not as clear and obvious as they could be.)

* Both the server and client seem to demand more system resources than it seems like they ought, and are significantly unstable on weaker systems. Slow is OK, stuttery is even OK, but it shouldn't just lock up or crash on a slower system. We had several laptops that could play perfectly fine for a few minutes with no signs of problems, but would just crash before 15 minutes were out. (Leading to various jokes about officers having apparently been yanked out of a bar when the alert was called, as they would go unresponsive randomly as they kept having to restart the client and get back in.)

* The server, even if running on a decent system, seems to be intolerant of network issues and crashing clients, and locks up. (Unresponsive, only way to get out is to kill it from Task Manager.) I had an arrangement with a small form factor (SFF) desktop as the server & display, a good laptop, and a decent laptop to run clients, all with dedicated NVIDIA graphics and hardwired through an Ethernet switch; this was stable indefinitely (several hours on at least one occasion). However, when we threw a WiFi network or lower-power clients (which would themselves crash every so often) into the mix, the server would just lock up every so often. My best guess is that the error handling / rejection for malformed, bad, or out of sync packets is insufficient (or lacking).

* As far as I could tell, the GM screen can only be brought up on the system that is running the server. I can sort of see why that might be done that way, but it's operationally inconvenient. Consider a separate password for GM functions?

* Middle mouse button functionality on the main screen controls (switch between directional 3D and various radar views) was erratic. In particular, it seemed to mostly be able to switch to the tactical radar, but not to the longer range one.

* A "look in the direction of the targeted ship" mode readily available for the main screen would be very handy.

* The tutorial needs serious help. It's far too slow and tedious. My most significant short-term suggestion is to break it into separate segments based on stations / functionality; so new folks can check out the one for the station they are trying, and so that when the client crashes you don't have to start over from the beginning. We had several people who tried for almost an hour and were never able to get all the way through due to crashing, despite multiple tries.

Secondly, significantly up the power of the beams, or reduce the shields / hull of the target, in the weapons segment. Many people thought it was broken, because nothing seemed to be happening for quite some time, as the feeble beam plinked at the target to no apparent effect; and you don't seem to be able to move on until it's been killed.

* The default ships are hard to use for people who don't know what they are doing. The first session I was the only one with any serious experience with EE; we tried various default things, and it never really jelled. In particular, broadside torps are hard to use for inexperienced helm and weapons, and the limited arcs of fire, weak weapons, and slow turn rate means that the "action" is not very action-filled.

Over the next couple of nights I created a "beginner's cruiser" to use at the bigger con event, and it went over *far* better. Significantly inspired by Classic Trek but with influences from various other genres, it has the following layout:

Spinal Mass Driver: 0 deg, centerline forward (HVLI only; dead ahead, unguided)
Torpedo tubes, multi-purpose: canted 15 deg. port and starboard of centerline forward (Homing, EMP, Nuke; 15 and 345)
Mine dropper: 180 deg, aft (Mine only)
Port + forward medium range (2000) beam, 120 degree arc (270 to 30)
Starboard + forward medium range (2000) beam, 120 degree arc (330 to 90)
Forward long range (3000) beam, 60 degree arc (330 to 30)
Aft short range (1000) beam, 180 degree arc (90 to 270)

This gives at least *some* close in beam fire in all angles, so that fights against fighters aren't quite so annoying; but with plenty of interesting tactical variation; in particular, what players started calling the "cone of death" where (by deliberate intent on my part), the PF, SF, and F beams overlap. There's some vague balance logic, in that the narrower the cone, the longer the range. I considered adjusting beam power as well, but left it at the default, which seemed to work well enough.

* Many people asked about how to shoot down incoming missiles; the tutorial should probably mention that there is no point-defense in the game (yet).

* Major point of frustration: Enemy AI ships get *way* too close to stations, frequently ending up clipping inside them partly or even entirely, which makes it very difficult to hit them as you just end up hitting the station. Is there a setting in the files somewhere that can adjust their stand-off distances in the short term? Player beam weapons should probably not fire when there is a friendly object occluding the locked target; or at least this should be a difficulty option in scenario setup. Eventually, some AI tweaks are needed here.

* The homing process for homing missiles was a bit opaque; folks gradually learned to work around it, but it never felt really solid. I think missiles should perhaps be faster; opponents should be possibly out-maneuvering missiles, but not simply outrunning them. (There is also a psychological presumption of sorts, due to historical performance of real-world missiles and games based on them, that homing missiles should do better if you get on someone's tail; the EE ones seem to do particularly poorly in a stern chase by contrast.)

* The arbitrary limitations on which console combinations can be used together were regularly annoying. We rarely had a full crew, and the fact that some console sets simply don't have certain options is not immediately obvious.

Short term, simply having a tab that has all the possible consoles listed to pick from would be very helpful. For instance, when I was testing solo on my laptop, I would run the server in one window with Solo Pilot; but have to start a second client process and window to be able to pick Weapons, Relay, and Science to test all the functionality.

* IIRC, despite sort of combining Relay and Science, Operations+ doesn't have all the functionality to conduct full drone operations. As it's usually the first stations to be combined if we are short handed, this was irritating.

* In the rare cases when we had extra folks, everyone thought that the stand-alone power management screen was far less useful than the power management screen from the Engineer station.

Comments

  • EE should work just fine on Linux and MacOS using Wine. (tried it only on linux)
  • edited October 2016
    @Miuramir, What version(s) of Windows were you running? In previous versions I've ran it fine with Pentium 4s with WinXP. (It's been awhile since I'm running newer Compute Stick style computers with Win8, Win10; and old Intel Atom Acer Revo running Debian Linux.)
    I'm beginning to think there could be problems with EE & Win10, my un-educated guess it's with SFML/OpenGL.

    * By default, when you build from source, it puts the current day as the version number. You can modify the CMakeLists.txt file to override this.
    Particularity these Lines:

    string(TIMESTAMP CPACK_PACKAGE_VERSION_MAJOR "%Y")
    string(TIMESTAMP CPACK_PACKAGE_VERSION_MINOR "%m")
    string(TIMESTAMP CPACK_PACKAGE_VERSION_PATCH "%d")


    If you make the version "0" it will try to connect to any version of the game.

    * I've never tried the middle mouse button for changing views. I only have used the left & right mouse button. Didn't even know it worked with the middle-button. Just tested the middle mouse button and it does seem to be erratic.

    * I'm not a big fan of the default ship either for conventions and other events. I usually change it. Typically I just use the old "Player Cruiser" as it seems to be the easiest for new people to pickup.

    * The 3/4 player ships have less functionality than 5/6 player ships. Daid did that intentionally.

    * The enemy AI currently loves to get in your face & scrape some paint. I agree that they should keep a little distance.

    Hopefully the developer Daid will chime in with some responses.
    (I'm not a developer; just a player willing to help.)
  • For easy play, I use the player Phobos. It's a bit weaker, has front tubes, and thus allows for quicker players with less complexity.
    The scenarios could use some tweaks to default to this ship more. (We do love the Atlantis in our sessions)

    The crashes are super annoying. I'm working on a better crash reporter, which can also auto-upload the crash reports so that I no longer have to beg for them.
    I also want to update OpenAL, as this seems to be part of the crashing problem.

    But right now, I am kinda busy with this:
    https://ultimaker.com/en/made-by-the-new-ultimaker
  • daid said:

    I also want to update OpenAL, as this seems to be part of the crashing problem.

    I just checked SFML's Git Repo. Looks like they are still shipping the same version that comes with 2.3.x with the source in Master.
    daid said:

    But right now, I am kinda busy with this:
    https://ultimaker.com/en/made-by-the-new-ultimaker

    Interesting... Hopefully there will be more videos after the release.
    I would like to see our local Makerspace get Ultimakers and replace the Makerbots and their problem extruders.

  • daid said:


    The crashes are super annoying. I'm working on a better crash reporter, which can also auto-upload the crash reports so that I no longer have to beg for them.

    I will be running EE next weekend (Fri. 10/21 & Sat. 10/22) at a regional convention; if it goes like the last time, I'll have plenty of opportunity to collect crash reports. Let me know what is most useful; if you want me to run a debug or extra-logging client I can certainly do that.

    Note that most of these systems will not be connected to the Internet, just wired to a switch "LAN party style", at the time; so any automated error reporting will need some sort of local caching. Also note that I'll try and check in here Thur. evening 10/20, but after that may not be online much until after the con.

    Both events were "bring your own laptop" for most players, as will be the one next weekend. I have a few core systems, but not enough for a full bridge. Anecdotally, the factors that seemed to result in more likelihood of crashes, and more frequently:
    * Windows 10
    * Touchscreen enabled (convertible laptop or tablet)
    * Integrated (Intel) graphics only
    * Wi-Fi networking, as opposed to a hardwired Ethernet connection

    The Microsoft Surface someone brought, embodying all of the above, was a lost cause despite a fair amount of trying.

    All of my own personal systems have Windows 7, and most of them are very stable. I experimented with a factory-refurbished Ultra Small Form Factor PC that a local shop had several of (HP 8000 Elite, Win 7, 3 GHz Core 2 Duo, 4 GB RAM, Intel graphics only and no ability to install a card), and it was completely unable to handle EE and I returned it. My good "gamer" laptop can run the server and multiple clients with no issues. My somewhat older, but OK laptop and my Small Form Factor desktop with dedicated (but weak) NVIDIA card are stable running a single client, but have issues with the server; but they may have been being brought down by other people's unstable clients confusing it. My little, barely more than a netbook laptop crashes every so often just running the client; if we need "synthetic" crashes under controlled conditions that's the best choice for it. Everyone was having more problems when we tried connecting via a Wi-Fi router, rather than hardwired.
  • kwadroke said:


    * The 3/4 player ships have less functionality than 5/6 player ships. Daid did that intentionally.

    Thanks for your comments. Regarding the above, it's a bit of a weird decision in my opinion. The way I look at it, you have the same (virtual) ship, you have the same tasks / challenges / scenario, but on that particular occasion you happen to have fewer actual player humans trying to complete it; the computer should if anything be giving them more help, not locking away vital abilities to make their life even harder.

    With some experience, it seems that the 4/3 slots are enough less useful so that it's better for most players to be running multiple tabs of the 6/5 stations. IIRC, what we evolved into was:

    1 player (2 clients): Single Pilot; Engineering + Weapons + Science + Relay
    2 player: Tactical; Engineering + Weapons + Science + Relay
    3 player: Tactical; Engineering + Weapons; Science + Relay (or sometimes Engineering; Weapons + Science + Relay)
    4 player: Helm; Weapons; Engineering; Science + Relay
  • Some more feedback I've remembered:

    * The "Minesweeper" hacking game is a neat idea, but too hard / time consuming; I think we only had one person ever get it to work semi-usefully, and really it would have been more useful if they had spent that time doing other things. Perhaps the number of cells, or the number of "mines", or the number of errors (mine hits) allowed, could be a configurable difficulty parameter somewhere? (Either based on the ship in question, or the level of the scenario, or a startup parameter for the server like scan range.) Also, it would be helpful if you had the ability to mark / flag suspected mine locations.

    * Displaying current effective repair rate on the Engineering screen in some fashion would be good. It's not immediately clear if multiple damage control meeple in a room accumulate, and if so, whether there is some sort of diminishing return.

    * Also, how does hull repair work? Is it all the time, is it only if other things are not being repaired, is it only when you have damage control meeples in an un-designated room or hallway?

    * The "Preparing to Jump" countdown should appear on all screens, and/or have an audible alert.

    * There should be some easily differentiated special effects between an enemy attack hitting shield, and an enemy attack hitting hull / internal components. (Prominent "Pew" or "Zwing" sound effect vs prominent crunching / metal tearing sound effect?) This will both help build immersion, and be a heads-up warning when things are going badly.

    * Ideally, the shield calibration should give some warning or prompt about how long it will take, especially if shields are currently up. Having a "If you push this button by mistake or inexperience, everyone looses" button is very bad ergonomics, both in-setting ("Why doesn't this button have a guard?") and as a game. (25 seconds of no shields by default, if that happens in combat, more or less an automatic loss.)
  • Miuramir said:

    * Displaying current effective repair rate on the Engineering screen in some fashion would be good. It's not immediately clear if multiple damage control meeple in a room accumulate, and if so, whether there is some sort of diminishing return.

    IIRC, damage controle crew accumulate without diminishing return.
    Miuramir said:

    * Also, how does hull repair work? Is it all the time, is it only if other things are not being repaired, is it only when you have damage control meeples in an un-designated room or hallway?

    Hull is repaired automatically when docked to a station.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!