Mucho hardware, few players

Ok, so here's my fun situation. I have a consistent bridge crew of three, including myself, but we have a plethora of hardware. We have three computers to use for consoles, all of which support multiple monitors, two extra monitors, and three Android tablets. That's just off the top of my head.

The standard layout assumes one screen per person. And the way we play, the Captain (me!) works a console full-time during the game (i have a fast food background, this isn't as strange as it may sound), so we can easily field a three-person bridge crew.

So, what do we need to do to make consoles that work for us? Here's what we do now:

* Designate one or more Android tablets to float, usually running science and/or relay
* We each grab multiple consoles so we can switch between them
* Designate roles for combat, when you can't really switch between consoles

What we *really* want is to be able to have the 5 console/6 player experience with just the three of us, and we have plenty of hardware to make that possible.

So, any suggestions? Are we going to have to hack the source to get consoles that work for us? (We're willing to do that, two of us are programmers, one (me) is quite experienced)


  • I forgot to mention that when we grab multiple consoles, that's basically a per-screen thing. So, like, we all grab engineering and try to crowd-source that to our spare time while one person works helm, one weapons, and one science, and whoever's not busy jumps to engineering.
  • Not sure what you are looking for. You do know about the additional operation/tactical/engineering+ screens?

    Note that the code itself wouldn't have much problems in running multiple stations at the same time. For example helms&weapons side by side. However, SFML has no notion of multiple monitors, which is why I didn't even try to make multi-monitor support, if that it what you are after (2 screens on 1 computer with different stations on each)
  • Yeah, multiple monitor support, that. :)

    We can run multiple clients on each machine for each monitor to get that support. I guess what I'm after is stations designed to be part of a multiple monitor setup. It doesn't have to be built-in to the game, because we can just run as many instances of the client as we need on each machine and let the DE handle the nuts and bolts.

    We're having problems with the additional stations, to be honest. You lose features when you go to other stations, like the tactical station and especially the single player stations. But working two stations on one screen is a pain. So, like, maybe we could hook up a game controller on a computer and have that computer run both helm and weapons. The game controller should always control the helm, no matter which window is focused, and the mouse should handle whichever window is focused. Then we could run a "tactical" setup where we have two monitors on one computer. Is that even possible?

    We're also running a mixed OS environment. My youngest has Windows 10, and my oldest and I are both in Kubuntu 17.10. And then we have Android tablets, two of which are running Android 5.1. We also have a couple of Android phones that could run something, if there were a console designed to run on the smaller screen of a phone, like the damage control console in the single player screens.
  • Been thinking about this some more. I'll go diving in the code in a bit (may be a few days, since I'm working on a python game network library) and see what I can come up with, but here's the basic idea:

    If I hook up two monitors with the same vertical resolution, say, 720p, and in my environment that'll be the laptop display at 16:9 AR, and the external monitor at 4:3. That gives me 1280x720 and 960x720, respectively. So I need a bridge console with a total resolution of 2240x720.

    When you go fullscreen with sfml, can you span all monitors available? I've seen it as a hit or miss situation with SDL1.2, where one time I had a game go fullscreen on both monitors and another time I had the same game only go fullscreen on one monitor, and I never locked down what was different. So it could be a desktop setting, or it could be problems with incompatible resolutions.
  • edited April 2018
    I tried a multi-monitor setup a while ago with multiple instances. It worked, but as you said, focus would be a problem if you use keys/joysticks.

    However I'm not sure if I got your problem. If you also have tablets for this purpose, why would you need additional monitors? If the size is the problem, maybe you can use a controller with the tablet and let it just handle the joystick/key input. For mouse and visuals, just log into the same station with you multi-monitor pc. Disclaimer: I have no idea if joystick and keyboard support even works on the android version.

    Another way would be to get two Raspberry PIs (PI 2 or above) and use it for the additional stations. Preferably pilot,weapons or engineering, as the other two are more hardware-demanding.
  • Well, the specific problem we're having is that we only have three regular/reliable players, and we want to work all five of the main stations at once. We have plenty of hardware in the form of extra monitors, two laptops, one desktop (not counting the one used for the main screen), and one (maybe two) tablets. Unfortunately, the current console design assumes a full-time player behind each one and is therefore quite difficult to work more than one console at at time, and we're seeing places where different functions on different consoles can be relocated to accommodate a three person bridge crew.

    For example, you could run Relay and Science together, and use the scan delay setting to make scanning during combat easier while allowing the person to hack opponents' ships. Likewise, Helm and Weapons can be worked together, but during combat, someone needs to be able to play backup.

    So I'm looking at Star Trek and asking questions like "Why does Worf, Data, and Wesley all have access to sensor controls?" and then asking "Why doesn't Empty Epsilon duplicate functions from other consoles?". The answer to the second question is mostly because of screen space, but here we have plenty of screen space.

    So, we could have an ultra-wide helm console that includes the relay information and can also fire missiles. Engineering could have an ultra-wide console that includes basically the entire weapons console. Similar to the stations daid already mentioned, but without loss of functions and with duplication of functions.

    Also, some of the consoles could be made smaller, and I think some of the single player consoles may be sufficiently small to run on a phone, like damage control, which would free up space in other consoles. So, maybe we could get some phone consoles? :) Like, put combat maneuvers on the phone console and (provided game controller support in the android version) allow a game controller to connect for steering. Then helm could be worked under a science/weapons screen.
  • Multi monitor setups could work, but will require some code changes.
    First off, SFML doesn't understand multiple monitors. So if the game enters full screen, 1 monitor will remain unused. To get around this, you need a "fake fullscreen" mode, where you create 1 large borderless window spanning both monitors.

    Once you have that, everything will be looking "bad", but, don't worry, we can fix the screens. The whole code is using my custom crappy gui system, advantage there is, the screens are just "widgets" that are setup to cover the whole screen. So it's actually possible to create a new screen type that just creates 2 different screen types internally and puts those on different sizes.
    Customizing screens isn't that hard if you look at the code.

    I was thinking about doing this already to combine the GM screen with a main screen (main screen on a projector, GM screen on my laptop monitor) but I haven't got around to do it yet.
    So I'm looking at Star Trek and asking questions like "Why does Worf, Data, and Wesley all have access to sensor controls?" and then asking "Why doesn't Empty Epsilon duplicate functions from other consoles?". The answer to the second question is mostly because of screen space, but here we have plenty of screen space.
    Nope, the answer is, to give everyone a meaningful job. I'm not letting realism or sane ship design get in the way of fun gameplay. And the whole game is build around interaction between the stations.
    Naturally, that falls a bit to pieces when you have less players ;-)

    Final note, the single pilot screen is more of a debug tool then anything else. It was never really intended as a fully functional screen.
  • I had a look at SFML API docs, and this is what I found:

    It appears, but I haven't tested it yet, that you can use that static function to get the full desktop resolution and do as you said, create a window with no title bar or any of that crap, and it should span multiple monitors. It's up to the user to make sure the resolutions work out, though.

    How flexible is the screen renderer? I've used it on several different aspect ratios and not had any problems, so I guess I'm wondering what would happen if I created an Engineering console that spanned an extremely wide desktop, and I'm particularly concerned with widgets getting chopped at the borders of the monitor.

    Anyway, I've been thinking about using my phone as a console, so I'll probably be looking at that soon. It makes sense to me that my phone could provide helm controls and I could work relay on my laptop and I don't really need the short-range sensors at that point. So, I guess I need to find out how to build EE for Android. :)
  • The screen renderer is quite flexible. It basically renders on a "virtual" display which always has a fixed height and a flexible width. And then aligns widgets to different edges/corners or the center. So there is no risk on widgets falling off the screen. But there is some overlap risk if you develop on a widescreen monitor and then run it on a 4/3 screen. (Which is why I develop in window mode in a 4/3 resolution)

    That function only returns the size of the primary monitor. So of little use. The windows APIs to get all monitor sizes and positions aren't difficult. I don't expect the Linux calls to be much harder.

    Note that the Android version is a hit/miss depending on the phone/tablet. And a bitch to build. But I wouldn't mind accepting patches for extra screens, so I can put those in the default build. Which will also give you the android version without much fuzz.
  • I figure I'll work on three extra screens, and see if I need to add buttons to any others to get where I'm going. Um, in case it matters, I've successfully run Empty Epsilon on every Android device I've thrown at it, so I know that I have hardware compatibility, at least.

    Here's what I'm thinking. We can have a 2 station/3 person bridge crew with a few small screens, which is what I'll work on.

    1. Damage control. This is really just a matter of adapting your damage control screen in extras so that all it displays is the ship hull. Putting this on a small screen frees up important screen real estate in Engineering to make it possible to split Weapons between Ops and Engineering. It'll also help eliminate the Tactical console for Really Small Crews. :)

    2. Weapons Engineering. For lack of a better word, this is everything on the weapons screen that isn't in the short-range radar screen. So, loading missiles, raising shields, attenuating the beam weapons, and recalibrating the shields. I think all of that could fit on a small screen quite nicely. This would make it possible for someone to run the regular 5-station Engineering console and use the small screen for weapons, with the option to pass the small screen around if needed.

    3. Helm. For this I'd remove the short-range radar from the main Helm screen and replace it with a small compass capable of showing waypoints and make sure hotkeys are supported in Android. With a tablet running Ops (and Ops getting the ability to lock missile targets), This "Advanced" Tactical console would combine elements of Relay, Science, Weapons, and still provide a fully-functional helm control. During combat, of course, this station would focus heavily on simply steering the ship and firing.

    So, with these small screens, and minor features added to other screens if needed, I think we could play a reasonable game with the following setup:

    The aforementioned Advanced Tactical setup, one person. On a second monitor, we'd run another instance with Science and Relay, but there's enough on this person's plate that we'd expect the Relay to get the most use, and mostly as a navigational tool. But once docked, the Helm switching to Relay to resupply the ship is also quite logical.

    The Engineering + Weapons management, either with the small damage control screen and weapons on Engineering (I believe the Engineering+ console provides this), or with the Weapons Engineering small screen and a full Engineering console. On a second monitor, we'd run another instance that had a dedicated science station, allowing this person to back up the first person with science, and a Relay station, allowing this person to try to hack into enemy ships during combat. These are both logical backup roles for the Engineer to take.

    The Captain probably still has to work a console in combat. As Captain, even if I have a full crew, I usually grab my tablet and take all the main consoles so I can work them as backup when one crew member gets a little overwhelmed, so I'd continue doing that, expecting to do Science during combat. And one thing we've learned, the only way you can really do Science during combat with a smaller crew is to use simple/time-based scanning.

    I've been fooling around with tweaking the extras that are already there, and I'm still working on figuring out how your layouts work. :) They're not as fluid as I'm used to using, but I'm also used to using a full-blown GUI library (Qt most recently). So, I'll see. I guess I should finally make a github account so I can send pull requests for all of this.

    I'm also figuring I'll make another panel for small screens specifically, because there may be other small screens that make sense to have. I think we may have a total of three phones available, too, and I'd like a small screen that gives the captain comms and main screen controls. Or maybe just a short-range display on a small screen? ;)
  • Good to know that the android version works on more devices. I've seen text go messed up, and the radars not working on some devices.
    The Captain probably still has to work a console in combat. As Captain, even if I have a full crew, I usually grab my tablet and take all the main consoles so I can work them as backup when one crew member gets a little overwhelmed
    Bah, that takes all the fun out of blaming your crew member when you fail, and you can no longer shout at them when they are doing the wrong thing.

    And yes, my GUI layout system can be a bit buggy at times. Just follow the examples already there, and remember that ordering counts for rendering as well as layout. It's not as advanced as Qt (We use Qt at the office) but I like making things from scratch :)
  • edited April 2018
    As these stations are pretty specific and somewhat extraordinary, i start to wonder if it might be viable in the long run to create a "custom station": A station that loads custom text files with a simplified syntax that determine which of the screenComponents and values are used and in which way they are arranged.

    Sidenote: maybe you could name the tablet models that you are using, as daid said it is a bit hit/miss with the android version, and in this forum, the most info we have is on which models it don't work correctly. So knowing some models where it works flawlessly could be quiet valuable, especially if someone might get some android device specifically for the game.
  • Maybe daid could take a look at the Cockpit code in Armagetron Advanced? What we did there could be adapted for Empty Epsilon, more than likely. For the HUD, we wrote an xml specification that defines widgets using datasource callbacks to display their information. The only thing you'd really need to add, necessarily, is the ability to click on widgets and send commands based on that. It's very flexible, and includes some basic if/then logic and looping, and all that is written in the xml file. You could also easily extend the xml specification to include embedded lua code. The resulting cockpit renders much like a webpage, but is also specific to limiting all information to the display rather than generate scrollbars like a webpage does. We took a dependency on libxml2 in the process, though, and I wouldn't suggest doing that. Basically, if we had to do it over again, we'd have gone with a tiny embeddable xml parser.

    Anyway, it's clear we have slightly different views of how the team play should/could work. :) Not incompatible views, just different. But different enough that I'd be willing (when we have the stations that work for my crew) to take my small crew against your larger crew in a PvP setting. ;)

    On the android versions, there are some miscellaneous things that go missing from time to time, but they don't affect gameplay that we've noticed. I'll have to do some digging, but I can tell you that we've successfully run Empty Epsilon on Kyocera Hydra Wave phones (two models), and my 10.1 inch tablet is a Tagital tablet that you can now get for $50 or less. We've run it on another tablet quite well, but I don't remember what kind of tablet that is, other than it runs Kit Kat. My phone and Tagital tablet both run Marshmallow.

    Also, as a side note, I was working at local burger place for a little while and noticed their POS systems were running Windows 8 or 8.1. They're fairly large screens (15 inch), solid touchscreens, and you might be able to score them used for a fairly small amount of money. I rage-quitted their before their upgrade cycle came to my store, but I was poised to nab a few when they upgraded. I'm fairly confident EE will run on them, but might need to be statically linked with all non-system libraries.
  • I'm going to be blunt. XML for that is stupid, in general XML is not the right too for a job :-) it has a few uses, but for a lot of locations where it is used it causes more problems then it solves.
    I considered scripting the screens with just pure Lua. It could work, except for how I setup the scripting engine itself, which causes isolation problems between the GUI and the game world (you could create GUI element from mission scripts, causing all hell)

    It's one of the things I fixed in SeriousProton2. Which also contains it's own GUI markup language (resembles QML, and acts more like web markup, with margins at stuff), but porting EE to SP2 would be a hell of a job and would break the missions scripts due to changes in the script bindings. Also, SP2 is far from stable, I change major things every time I work on it.
  • I'll agree that XML isn't optimal, but I'll be blunt: XML is far more useful than it appears at first. But this is a flamewar for a different place.

    I looked at QML, and it's surprisingly (or unsurprisingly) similar to the KV Design Language used by Kivy.


    I'd be interested in lua-scripted consoles that *could* be reached from mission scripts, though. Consider the Star Trek episode "The Enterprise Incident", where they go into Romulan space and steal a cloaking device. A mission like that could be fun, but the mission script would have to be able to create a custom button for the cloaking device, as well as the engineering controls for repairing it, powering it, and cooling it.

    For what it's worth, my kids are here this weekend, and we played EE yesterday for several hours, and didn't once have anything crash. There were a few anomalies, usually caused by ending a scenario and then choosing another one without exiting the server, but nothing that was really a problem. We went with two laptops, each with an added monitor, and the tablet, where the two laptops were both compiled from current sources on github, not the latest release sources.
  • Scripts can create extra buttons on consoles. But that did require a bit of code for the network-replication. Which is where scripted consoles across network would cause a shitload of work :-) But extra basic buttons and messages to consoles is already there.

    It makes sense to have a condense syntax like QML/KV has. My syntax is slightly different:
    [id] {
      tag: value
      [id] {
        tag: value
        tag: value
    It's what I called a "KeyValueTree" in my new code. The data structure looks like this:
    class KeyValueTreeNode
        string id;
        std::map items;
        std::vector child_nodes;
    I use it for a lot more then just GUI definitions now, as the KeyValueTree file loader is also accessible separately. I really start to like this structure, compared to XML and JSON.

    Getting a bit off-track here :-)
Sign In or Register to comment.