Pondering bridge simulation game creation.

So, why this post. First off, just to dump my mind a bit. As it's getting full in here.

As you all will most likely know. I started EmptyEpsilon as a better, open, hackable/moddable clone of Artemis. And it does a pretty decent job on that area. It plays well, it's quite stable, it's pretty easy to pick up, runs well with or without a game-master. And it does not suffer any out-of-sync problems (after the collision bug was squashed...)
It also has it's share of negatives, the sound effects suck. The amount of mission scripts is limited. Few parts are a bit harder to grasp then others.
But all of that, isn't a huge problem. The game works, people enjoy it.


Now the last year or so, I've been pondering about making a new bridge-simulator game. I've made a whole bunch of silly proof of concept/tech demos to try things. Just to name a few things.
* There is the way too complex highly modular C++/lua prototype that contains a lot of code for something that only simulates an unstable reactor core, but does contain it's own scripting language next to lua...
* Then there is the slightly less, but still complex, modular python code with a web frontend, using true orbital physics. Which actually has a lot of the simulation problems that the unstable reactor core had. (Making the same mistake twice?)
* And not to forget to mention, the electrical network simulator, where components can be placed on a grid and electrical connections can be made, but I never got the UI up to a point where it was a joy to work with this code. This also quickly became complicated without adding anything really.
* I have an ascii-turn-based-single-player-roguelike-spaceship-simulator, doesn't work very well on a conceptual level.



I've been noticing a few things in what I'm building. First off, i'm trying various technologies to build on top. Secondly, I noticed I never touched combat. EE and Artemis are quite combat heavy, and that has it's plus side, as it's clear what goals are, and combat is generally tense action. But i think they can be more to bridge simulation then combat.
Finally, none of my prototypes had a fixed amount of players, except for the single-player-turned-based thing. EE is clearly optimized for 6 players (5 stations plus a captain)

I think with the right engine/mission/scripts/data, you could have a lot of interesting scenarios without ever touching combat. Just to name random ones:
* Tracing/tracking warp signatures to follow a ship
* Handling a ship with broken system (detecting, fixing and recovering from a coolant leak in the right truster engines)
* General maneuvering/flying in full 3D, while orbital mechanics are hard, Newtonian physics are quite easy to grasp.
* Trading goods
* Docking, with full docking communication/negotiation (please shut down your fusion reactor before getting within 5km of our station, to prevent radiation blasting our station)
* Landing on planets/moons, managing fuel, speed, angle of attack.
* Maneuvering deep space


Next, I noticed that I'm having trouble on settling on technology, everything has it's advantages and problems.
* C++ with SFML and OpenGL gives a lot of flexibility and speed. But is also slower to develop in. The 2nd version of Serious proton addresses quite a few of the problems in the first version. But isn't mature yet, but I do have a lot of experience in C++.
* Python with PyQT5 and QML, we use this at the office a lot. Quite fast to develop in, but harder to properly package and deploy. QML gives a nice markup language for UI development.
* HTML5. I'm not a huge fan of javascript. But the zero-deployment effort of web development does has it's advantages. Performance is a clear disadvantage here. Realtime data is also a bit harder unless websockets are used, which are a bit of a complex piece of tech on it's own. 3D rendering has options, but support isn't great across the board. (NodeJS is not an option for me)

Comments

  • As much as HTML5/JS sucks, it does solve one huge problem - cross platform deployment sync. That alone is what caused me to abandon Artemis. This nonsense of "oh wait a year after I push out an update for whoever I commissioned to do the Android version, if they can even be bothered" is just unbelievable. I looked at Horizons but $60 entry fee pushed me away from that without even trying (but hey his stuff just WORKS in any device). SNIS, only for extreme geeks on an OS that nobody uses. So I landed at your project, and here I am. The mishmash of languages (low level coding and higher level scripting) is confusing, but like you said, it's mature, it works, it's free, it works on my devices.
    And for all the negatives listed above, the authors are ALL better than me, have all made something entertaining, and clearly have their own fanbase. That's a win no matter what. So each and every one of you creators, thank you. Keep doing what you're doing.
  • Well, EEs Android version is build from the same source as the desktop one, and the release process builds and releases both. Pretty much the only way to keep compatibility like this. And as EE is free, expectations are different, but offering a paid android version and not keeping it up to date with the rest is shitty at best.
    SNIS's only for linux is pretty much what hold me back on even trying it. Linux is used by 2-3% of the end users of the company I work for, which is most likely already biased towards the higher end due to 3D printing being nerdy. So you are right on the nobody uses it as a desktop OS.

    I'm actually quite happy with the C++ and Lua mix. Lua allows for a safe environment to quickly build mission scripts, without knowing all the details of the C++ code. The only thing I would do different there is the http API, which now hooks into the lua scripting, which makes it difficult to use. A JSON REST API makes much more sense here, and works better with all kinds of other tools including javascript frameworks.



    Another point for pondering. Users. World wide, there are most likely up to a few 1000 people that have interest in these kind of games, have the people, and the space to play this with 6 people. With 5 or 6 different games currently in the mix, and most of those are quite the same, as artemis was the first and people copied a lot from that. I tried to filter out a few of the things I didn't see working in EE. But in the core it's the same. Most these games currently follow the same lines.
    So quite a lot of games "fighting" over a small group of people. Which is why I don't think any of the paid options will survive except for Artemis (for the simple sake of being first and most well known)
    The free options are surviving for the simple fact that they are being driven by people that want to create something for themselves, and at the same time just give that away to the world.
    So any new game, needs to offer something new and unique, or it won't attract players. My current idea if I make something new, is to have much more complex systems. So it's less a pickup and play, but more a pickup, fail and learn.

    If you make something different, that's no guarantee for success. Roguesystem http://imagespaceinc.com/rogsys/ has some good ideas, but for an alpha game, it has a large focus on graphics. Meaning there is little content right now. It also runs on only 1 of the machines I have, which is my girlfriends laptop. Due to the heavy graphics requirement. Part of the backing funding was cut from a publisher due to the limited success in sales.
    (Note that it is single player, not a crew based simulator. But it does simulate a pretty extensive spaceship, with lots and lots of buttons)



    And something completely else. On the development side. It's very very hard to develop a game without playtesting. With EE I had the luck of quite a bit of playtesting at the office. Every session there provided valuable feedback. What controls worked, what features are unused, how are the interactions between the crewmates, which stations are busy at what times. With the GM screen, I could keep a close eye on everything. And even spot bugs without the players noticing them.
    But when other people are playing, I'm limited by the feedback those people give here. Which is limited, and generally done by the people that are more experienced. So lacks a whole lot of details.
    EE can do some recording of a session with the gamestate logger. But that does not capture the full state of the game, and lacks information on what the players where actually doing.
    It also does not auto-upload those logs. So I only have logs for my own sessions, which I already saw with my own eyes.
    The original idea of these logs was to do postmortems, sitting down with the crew and walking trough what they did on critical moments. But we never actually did.
    As a coop game, game balance isn't a huge problem. The players should be more powerful and smarter then the AI ships. As the players should feel smart and good at the game.
    This is where I think MMO like bridge sims will fail. You don't have the player base and information to properly balance things out, unless you make it one giant COOP game.

    Anyhow, back to postmortems. If I make something new, I would like to collect data, shitloads of it. Status of every system, every button pressed, maybe even audio of the people playing it? Capturing players audio is always tricky. As people generally do not like to be recorded. But it's also essential interaction in a crew based simulator. (Not to forget data size, an uncompressed audio stream of an hour is about 300MB of data)

    Another thing in this area is, if I make a more complex simulator, people will need to know why they failed/blewup/ran out of power/flew into a sun. So the game might need to be able to identify critical chains of events that lead to failure. (Shield system sabotage caused structural damaged while flying into an asteroid, which in it's turn caused a warp-core fracture, that was not properly contained in time and thus cased an warp-implosion, destroying a large part of the ship and venting all oxygen into space, as air-tight-bulkheads where not closed, killing everyone on the ship)
  • You seem to think about 20 steps ahead, I'm lucky to get 2 or 3 :) Thanks for the insight into the analytics of making these things work.
  • Well, I did play chess. But thinking before doing is a big part of software engineering. However, you can also over-think things, and quite often you just need to start building prototypes to see what works and not. EE was build on top of other work, including the space-invaders clone running on our arcade cabinet at the office, and various prototypes. And it had the advantage of looking closely at Artemis.
    Our original plan was actually to build something like http://www.lhsbikeshed.com/, before we encountered Artemis and changed plans, mainly due to the large hardware/room requirements. Our office is in constant space shortage. Only reason I can keep storing our EE setup there, is that most people think it's part of our inventory as it's there for so long already.


    Subsystems. Any game has subsystems, or components, or gameplay elements, as you could also call them. And subsystems should have relations to other subsystems. Also, subsystems generally should have equal complexity, else things start to feel out of place.
    Examples work better here. A game like... Doom (the first one), has a bunch of subsystems/gameplay elements, it has health, armor, weapons (with ammo), projectile enemies, close combat enemies. All those are simple on their own, and are closely related and work well together.
    On the other end of the spectrum, we have Eve online. Which also has health/armor, and weapons, and ammo. But health/armor is hull, armor and shields. Weapons have a whole bunch of statistics, and relative distance and movement are suddenly also important, as well as shield or armor strength. All subsystems there are way more complex, even tough there are about the same amount of subsystems and about the same relations. It does make for a whole different game.


    Back to bridge spaceship simulation. If we look at EE/Artemis, we have a whole bunch of clear subsystems:
    * Energy (+reactor)
    * Beam weapons
    * Missile weapons
    * Moving around (impulse/maneuvering)
    * Jump/warp drive
    * Long range scanning
    * Communications
    * Shields/Hull
    * System damage + repair crews
    * Probes
    And that's also why engineering is the most complex, and most important job on the ship. Almost all these subsystems are connected to engineering in one way or another. That means engineering can influence almost everything, except scanning, communications and probes. While most other things only have relations to a few things, where relay is the crew member with the least amount of direct connections, and generally has a very indirect influence.
    Note that while engineering has the most direct influence on how the ship operates, it also has no real information on what is happening except for the main screen. So it can influence everything, but has no direct information on what to do. So talking here is vital.
    Now, there are more subsystems in EE, but no all are as visible.


    Now, on any new game, you need to consider what main subsystems to implement. One of those that "popped up" in my prototypes is "life support". Life support is important on any spaceship, as, well, it keeps you alive. However, after some careful thinking, it generally does not make for a very good game subsystem. Without going into the details of food/heat and oxygen. Life support is generally a system when you put in power, and the result it that you stay alive.
    If you have played "FTL" I'll use that as an example, and if you haven't played it, stopped reading, and buy it on steam. I have 126 hours in it, and finished it on easy with every ship/layout.
    Anyhow, it has a life support subsystem. The "O2" component on your ship. This refills any room of your ship with air that the crew needs to live. If the system is disabled (damaged or no power) then the air is slowly venting.
    And while venting a room of air, has a bunch of uses, namely putting out fire and killing boarding crews. The O2 subsystem that refills it has actually one major use.
    And that is that it is actually a battery. It's not life support at all, it's a battery. It charges up, and when it's full, you can take out the power and use it somewhere else until the charge is too low. And as the extended content added a emergency battery as well, the game now suddenly has two backup batteries.
    With the side note that one of these batteries is essential for your ship, and any damage do it should be repaired as soon as possible.

    So back to new simulator games. Life support is essential for a spaceship, but does not make very good game mechanics. As it's just something that needs "upkeep", it does not tie into any other systems very well. And just becomes something that can break, needs fixing, or else you die. Unlike most other things, which if they break, you need to avoid certain situations, or else you die. For example, your generator can be destroyed, but you still have time before you run out of energy. So you should get out of the way for repairs, or you die. Or if your shields are down, you need to avoid being hit, or you die.
    Life support down, you die. No "if", just no life support results in death.


    I want to think up a whole list of subsystems that spaceship simulation games can have. But I'll leave that for another day.


    Note, I spend about two hours a day in trains. Which is where I find the time to do these posts. Some of the things in here actually come out of text files I've written for myself earlier. But I figured why keep those things private, I can also share those thoughts. And, I lost a few of those files... which is always a shame. (I had a whole file on "life support", with all kinds of details on what the human body can handle and what happens if you go beyond those limits, but I lost the file)
  • Huh. I recently added "life support" to Space Nerds In Space -- it's pretty much as you describe, a battery that kills you if it runs out of juice (O2) but which, when working, uses a small amount of power and charges up on O2. For my game, it's just another system added into Engineering that can break and require repair, and applies to the whole ship (no separate regions, bulkheads, etc.) I put quite a long timer on it, and it gives you plenty of warning though. So it really doesn't add much to the game either way, as it mostly just sits there quietly working, and when it doesn't work, you still have a long time before you actually need to repair it (unless you have been purposely depriving it of power). I really put it in for the ambience -- people expect a space ship to have a life support system (and it should also work most of the time) -- not that anyone plays my game, ha. :)
  • Tiny bit more on the life support. Scraping together some old files I had. So here are my notes on life support.

    There are in general a few things that life support needs to handle:
    * Cabin pressure
    * O2 levels
    * CO2 levels
    Pressure
    Less then 0.356 bar, you die due to all kinds of horrible effects on your body.
    Less then 0.5 bar, effects of low pressure are the same as high altitude sickness.
    More then 3 bar gives you tunnel vision.
    More then 4 bar kills you.
    O2
    Less then 17% O2, death due to lack of O2
    Less then 18.5% O2, breathing will be harder
    More then 50% O2, while not deadly, this makes breathing harder. Also, it makes everything flammable as fuck. So explosion risk!
    CO2
    More then 5% CO2, player starts to get sleepy.
    More then 7% CO2, player will fall asleep, and sleeping players cannot do anything to survive.


    For long term survival, there is also food and water. For example, an average human produces 0.2L water vapor per hour. Which you will need to extract from the air. And humans need to eat and drink. But you can go a few days without water and weeks without food. (Although the fun quickly drops if you go without those)
    And there is the thing of going mad without light, day&night cycles and inter-human contact. But that's also quite long-term.


    Back to the short term life support:

    Standard air mixture is 20.95% O2, and the rest is almost all N2, which doesn't do anything for us in terms of survival, except for keeping up the pressure without making everything flammable as fuck. (There is about 1% of other stuff in air, so that's not really contributing for anything simulation wise)

    Humans consume about 0.6m^3 of O2 per day. Which is turned mostly into CO2 and some H2O. Starting of in a 1m cube with 100% O2, you can live for a few hours before the CO2 levels kill you. If you start off with normal 20% O2, O2 levels will drop below living conditions before CO2 becomes a problem. But only slightly, start with 25% O2 mixture, and CO2 becomes your problem.

    CO2 scrubbers are important thing for life support, and lack of those will kill you quite quick.
    As for O2 itself, even if you don't recover the O2 from the CO2/H2O. You most likely have a shitload of O2 in the form of one of your fuel components. So "generating" that is actually quite easy.
  • Subsystems! There are so many of them. Let's write down a quick list of all I can think off right now, and steal from my previous notes. Some of these come from other games. Some of these are just ideas. Some of these might not even work in a game. I could write almost every single one of them out in as much detail as the life-support.

    Games to peek at (in random order):
    FTL, SNIS, Artemis, EE, RogueSystem, Elite


    Power generation
    Fuel cell (H2 + O2 -> H2O+power, exists already today)
    Reactor (nuclear, fusion, "future tech")
    Battery: Can store energy.
    Solar panel: Generates energy when aimed at a sun.

    Movement
    Engines/Trusters
    Engine: uses H2 and O2 to accelerate the ship.
    Reaction control system (RCS)/Stabilizers
    Docking computer
    Navigation computer
    Warp drive, variation A: move at high speed
    Warp drive, variation B: move trough "sub space", different reality where distances are shorter
    Jump drive (instantly move to new location, "spore drive ;-) ")
    "afterburner"
    atmospheric flight

    Life support
    CO2 scrubber
    Space heater
    Pressure regulator

    Communication
    Radio transmitter receivers. Unidirection, directional, long range, short range. Can also be seen as a "sensor"
    Communication channels (Open subchannel 5)
    Radar, Unidirection, directional, long range, short range. Can also be seen as a sensor.
    Sensors to sense gravity, light (intensity/frequency), life signs, magnetism, radio waves, electrical waves, ...

    Combat
    Shields
    Weapons
    * Beam weapons (instant hit, also called "hit trace weapons")
    * Missile weapons
    * Homing system
    * Combat drones
    Countermeasures
    Repair system/drones
    Hacking

    Various
    Heat exchanger/radiator
    Electrolizer (H2O+power -> H2 + O2)
    Computer: runs software to control various aspects of the ship.
    Database: Stores data for the computer to access.
    Light: uses electricity to light up the ship.
    Material sensor: Sense a certain material amount, come in gas and liquid forms.
    Doors (bulkheads, airtight. Normal, only prevents people from crossing)
    Cargo hold, carry cargo, spare parts, legal trade good, illegal trade goods.
    Cloaking device. Artemis has this, confusing as hell, felt like a bug when ships popped up out of nothing without a warning/animation.
    Boarding crew
    Tractor beam
    Landing gear
  • Don't forget lidar! More resolution than radar but somewhat limited range and line of sight. Use it a lot in heavy gear in space.
  • edited November 12
    Actually there already is one situation in EE that can directly lead to death without be exposed to enemies or hazards: If your Engineering officer decides that it would be a good idea to overpower your reactor a while. With max power and wthout cooling, that needs just about half a minute (even less if the reactor is already damaged)
    So it actually is a bit weird that of all stations the self destruct button is in engineering, as the engineer already has a pretty effective way to blow up the ship, one that does not even require the permission of other officers.

    I would really recommend to check out SNIS. Compilation is pretty straightforward, at least on debian-based systems.
    I'd say it is a pretty good source for inspiration.
    It is definitely not the most accessible bridge sim out there (I guess that award goes to EE, at least from those gave I tested so far) and I never played a real mission with it, but it has a very distinct and cool feeling, and some fresh ideas. Also full 3d space without beeing arcady.

    Small addition about FTL:
    FTL is not only available to Steam, but also DRM free through humble store (which also includes a steam key, so even for those who are into steam that can be a good decision)

    Regarding technology: You said the sfml/c combination's advantage is speed. Maybe thats just the implementation in EE, but I had several performance issues when running on older hardware. Even with shader disabled, the fps drops to values between 5 to 7 on some machines, even on engineering. On the title screen however, everything is fine So I guess there is quite some overhead there. So for a new bridge sim, maybe that kind of overhead can be reduced.

    Some other note: It would be cool if you could consider to make unicode the standard encoding for that new sim.
    I know, you are not a big fan of translations, but with unicode it will at least be easier to do unofficial "fan translations".
  • Uhm, yes, engineering blowing up the ship with the reactor is a bit of an issue. I did think about removing that. (It takes 17 seconds if you do it right, from the start of a game. Which makes it for one of the shortest game sessions we ever did, note that the self-destruct has a much bigger explosion, and thus does a lot more damage to ships surrounding you. We actually won a game with this once)

    I'm planning to checking out SNIS. One of my main reasons is the fact that it is 3D. EE is 2D for a simple reason, it makes it easier to navigate and communicate about positions and headings. So I'm wondering how SNIS solves this with 3D.
    If I make something else, I feel the huge urge to make it truly 3D. But navigation is a lot more complex in 3D, so I'm still pondering how to handle that UI wise.
    Kerbal space program does it (or doesn't, as navigation is a big thing there). As well as Homeworld. But then there are also games that just "ignore" the fact that they are 3D, for example, the X-Wing and Tie Fighter games are fully 3D, but the "map" view is 2D. Note that this is what most games do, give some degree of 3D freedom, but mostly work on a 2D plain.

    The FPS drop of EE is all down to 3D acceleration or not on the hardware we use. The UI rendering isn't the most efficient implementation, but fast enough if software rendering isn't used. Note that it's one of the reasons I'm thinking about Qt for whatever I build next. That only redraws the elements that change, instead of constantly redrawing everything as I do now. The speed I actually referrer too, is the fact that you can run a 500 AI ship simulation on a fast computer.
    (Possibly, it's the text rendering that is slow. I'm not sure if re-creating the sf::Text objects every draw is actually the right way for speed)
  • edited November 12
    > I'm wondering how SNIS solves this with 3D.

    I can write about that a bit.

    There are waypoints on the science screen, where the player can either type in x,y,z coordinates, or drop a waypoint at the current location of the ship. These waypoints also show up on the Nav screen, and the ship's computer knows about them too. The science station can select most objects in the game including waypoints, and will give a bearing and mark (azimuth and elevation relative to a fixed canonical orientation, really) and distance, and closing rate (the latter might be negative) on the "details" screen. When science selects something, on the navigation screen, there's a 3D arrow that points in the direction of whatever science has selected (there's also another arrow pointing whichever way the gun turret is pointed). So to navigate towards something, science can scan it and select it, and then navigation can follow the arrow that's pointing to it. You can also use the computer and type in "set a course for blah", (In theory, you can also use the speech recognition, but it is incapable of recognizing the procedurally generated planet names or ship names, but it knows "nearest ship" and "nearest planet", etc.) There are also a couple different attitude indicators on the Nav screen, one of which is mostly cosmetic, that shows a little rendering of the ship, and shows yaw, pitch, and roll rates (copied from Apollo era attitude indicator https://www.hq.nasa.gov/alsj/alsj-FDAI.html), and then the recently added main attitude indicator with 3 large rings with degree markings. One ring (slightly different color than the other two) shows the heading (0 to 360 degrees) and the other two rings show the "mark," or elevation (-90 to +90 degrees). So it is possible for the science officer to call out "Bearing 320 Mark 70", and the navigation officer can, by looking at the rings, manage to bring the ship onto that course, more or less (it is more easily accomplished by the science officer selecting something, then Navigation following the green arrow that will appear on the nav screen, but it is also possible strictly by using the numbers on the rings.)

    The interaction between nav and weapons is interesting, because the weapons is a 3D turret (more Millenium Falcon style than Star Trek style, admittedly, but hey, the MF is super cool.) But if Nav is thrashing around, this makes aiming the guns very hard (they do not try to compensate for ship motion), so Nav has to be aware of what Weapons is trying to shoot, and since the guns are only on the top of the ship, not the bottom, Nav has to maneuver so weapons is actually capable of pointing in the right direction. This interaction works pretty well I think in that it forces some cooperation quite naturally. I have vaguely thought about having some deflector shield turret mechanism so someone can "angle the deflector shields" as in the MF, but haven't done any work in that direction.


    The science short range scanner screen is a little strange. It shows a 2D view in which the distances are proportional to the 3D distances. This can get some pretty strange looking things happening in the 2D view. When you select a ship on the 2D screen, it kind of "pops out" (and other ships near it also pop out) in a 3D representation of the spatial relationships. It is a bit strange. We kind of wanted something that didn't look too straightforward, and required some poking around and gave a feeling of exploring the space. Not sure how successful that part is. There is also a bug in that if you have something selected, and then it warps a great distance away, well, there's some strange behavior as the view sort of follows this warp travel in a lerpy way, and then if you deselect, the view rapidly lerps back to the locale around your ship. Eh, it's pretty harmless as bugs go.

    The 3d "demon screen" (game master) was interesting. I don't think it works great, but it works kind of ok, though it is kind of strange the way that it works. iirc, clicking right mouse button on something in this view flies the gamemaster (distinct from the ship) towards the object (with maybe some incidental spinning that is not really intentional, just some quaternion slerping side effect, but which can be a little disorienting). If you click on no particular object but to the right, left, above or below the center of the screen, the view is rotated in that direction, so you can steer around by clicking. The mouse wheel moves you straight ahead or backwards. There is a "exagerate scale" button so that all the objects (except planets) are rendered much larger than they really are so you can see them from a great distance, if you move up close to something, you can turn it off and see things are normal scale. So, did struggle with how the UI for that screen could work in 3D, and came up with something, but it's not particularly great.

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!