Ship Classification and Ship Icons #78
Replies: 4 comments 5 replies
-
|
Ship Classifications: Ship Icons: Your proposal of an icon for each classification for each faction would work ok, but if ship templates can override, then how do you know what faction or class the ship is at a glance? Isn't that the point of having different icons? Another point to consider: Should there be text associated with each ship icon? Artemis has the ship name written directly above the icon, which has pros and cons. I recommend some sort of toggle for whether or not text is displayed, and that the text should include the ship's name, classification, and faction. If text is displayed, and can be quickly toggled on/off, then I'm much more comfortable with the icon overrides, since a quick toggle and you can check specifics about that ship without having to exclusively rely on checking with science as to what is what. But I'm still more of a fan of the silhouette method for the icon. |
Beta Was this translation helpful? Give feedback.
-
Not all ships are military, like freighters and passenger ships. I'm not opposed to using military-sounding classifications, though. It's just my preference.
It depends on whether we use the classifications for configuring other things, like having factions include an icon for each classification. If the classification is just a name and isn't used elsewhere in the code or configuration, there's nothing wrong with allowing any value.
This is a good idea, and easy to automate. I still think there should be the option to override icons, both for factions and for ships. Sometimes the ship silhouette just doesn't look appealing, and a well-designed icon can be much easier to identify. Maybe it falls back on the silhouette if there are no override icons.
I would prefer the player have proper IFF - Ships turn red if they are hostile, gray for disabled, green for friendly, yellow for... something. I also think there should be an option to choose the color scheme. So the Sensors officer can choose IFF, or they can choose to show the faction color, or they can remove colors altogether.
Unlimited, since plugins can add as many factions as they want. In this blog post I described 7 stereotypical factions that could be included in the main storyline.
This is intended for special ships that are unique for a particular mission. For example, in one mission there's a standard freighter ship called the "Outlaw Star" which the crew interacts with many times through the mission. Instead of using a generic ship symbol, that ship gets a special icon to differentiate it from other ships, for story purposes.
Agreed, both that there should be the option for text and that it can be turned off. Or have the ability to cycle through what the text says, like you suggested: name, classification, faction, and any other values we think might be valuable to see at a glance. All great points. Thanks for the thoughtful analysis. Here's an amendment to my original proposal: Ships can define any classification they like, and classifications on other ships will be provided as suggestions to make it more difficult to have a typo and accidentally create a new classification. Factions can define a single icon which is applied to all of their ships, but ships can still override with their own icon. And if there is no icon provided, the silhouette will be used automatically. |
Beta Was this translation helpful? Give feedback.
-
|
Personally I'd rather factions be associated with colors, and use icons to represent classifications/classes istead. The reverse just doesn't work as well, and if there's, say, a blue glow around all the icons in a particular fleet, it'll be obvious which faction they're from at a glance, while you'll still be able to determine what types of ships the fleet is composed of. But I'd be ok with your amendmenet. |
Beta Was this translation helpful? Give feedback.
-
|
As a demonstration, here are two (poorly crafted) strategic maps, one where faction is indicated with color and another where faction is indicated with icons. Tell me which one you prefer.
One other benefit of using icons to represent faction: you can use colors to represent other things, like IFF. And you could still have that blue glow to represent factions while still having the icons. |
Beta Was this translation helpful? Give feedback.
-
One other problem with this - this brings us back to having to configure different kinds of ship classifications, since you need to define the icon associated with the ship class. I would... prefer to avoid that, especially for something so generic that applies to so many ships. It makes things really messy when you create a ship class in one plugin that a whole bunch of other plugins rely on. |
Beta Was this translation helpful? Give feedback.
-
|
My preferences: For strategic purposes, like on a longer range view, icons and/or colors can be used to show factions. Regions of space under the influence of a particular faction could be color coded for each faction. Regions might also show friendly, neutral, enemy with the possibility of gradients in between such as enemies with a cease fire agreement, neutrals negotiating to be friendly or neutrals considering joining an enemy faction or alignment. Empty Epsilon (for the crew) starts ships as a generic gray/white triangle when they are not scanned - no color to indicate relationship, no shape to indicate ship (type or classification). Once the first scan is complete, the faction relationship and the ship type is visible (color for friend, enemy, neutral; pointy, rotatable icon for ship type). This scheme is used on any screen that shows ship icons (helm, weapons, science, relay). The GM screen has the same pointy/rotatable icons, but a different color is given to each faction. The second scan provides details useful in combat. Instead of only two levels of scan detail, there could be a third level that uses the classification described. The first scan might show the ship classification (eg cruiser) and the friend/enemy/neutral status, the second scan provides the specific ship type (cruiser, interceptor class or cruiser, sniper class) along with the faction and the third scan provides details like shield frequencies, status of subsystems (damaged or healthy engines, etc). I guess I'm trying to say that there can be more than one way to represent a ship depending on the role of a crew person and the level of detail available. Having these varying levels of detail to be represented also gives greater opportunity for multiple crew to assist in the scanning. Perhaps one is primarily focused on combat and the tactical situation, while another supports the overall strategic goals, thus needing a broader picture rather than some of the details. Since this is a starship bridge simulation, knowledge of other ships may be limited due to the vastness of space. Current naval and air force systems have a large body or research behind them to help identify ships. In space, such databases may or may not be available on whatever the sensors are picking up. An initial abstract definition may classify a ship as a cruiser, but the second or third pass via sensors may refine that into a larger or smaller classification: what might seem like a large ship is reclassified once the sensors determine that the large surface area showing on sensors was really just a light sail and it's actually much smaller or a comparatively small ship may get reclassified due to the faction's penchant for using captured black holes as power sources. As @astrolamb-gaming mentioned, the classification of naval vessels relates more to purpose in the real world. I've seen some older naval vessel classifications that use tonnage or size to classify ships. Whatever we come up with may use different aspects, but I suggest we pick one primary characteristic as a way to classify ships. If we want to give a more alien flavor for story telling, perhaps we can have "our" method of classifying ships (say by size) and yet have to be aware of the friendly aliens way of classifying ships (by top speed) and the enemy aliens way of classifying ships (available destructive power). The crew may have to adapt if their sensors are repaired using one of these alien parts making them rethink their classification of ships. |
Beta Was this translation helpful? Give feedback.
-
IconsI love the idea of seeing the direction of ships using icons, but it is really hard to map 3D space to a 2D plane. How do you indicate that a ship is pointed up or down? How do you represent the orientation of the ship when dealing with pitch and roll, and not just yaw? 3D makes everything messier... In Thorium Nova Prime, I addressed this by using direction-less icons which were replaced with 3D models when you zoom close enough. https://thoriumsim.com/blog/update-16-map-updates It think that's a good enough solution, and we could add little lines or arrows to indicate direction as well. Heck, we could even 3D rotate a flat icon to indicate orientation, but from the right angle, the flat icon would disappear. Maybe a checkbox that lets you alternate between a flat view that only shows the yaw component of the ships orientation, and a 3D view that rotates the icon. There's one more problem, though - this requires plugin creators to design icons that have a clear direction to them, and if they don't add a direction to their icon their logo looks silly being rotated around. Perhaps there could be another checkbox when configuring the ship icon that says "This icon indicates direction". When checked, the icon rotates. When not checked, the line/arrow appear. Yeah, I think that's a viable solution. I'd love to hear your thoughts. ClassificationsI would prefer to not have different classifications for different factions. That adds a fair bit of complexity to the programming and configuration without adding a ton of value, as I see it. I could be convinced otherwise, but I think we can just hand-wave and say everyone in the universe classifies their ships by size. Sensor ScansThis should be discussed more in a future discussion, but I figure we can chat about it a bit here too. You bring up Empty Epsilon's scanning. I would love to do something totally different from that, based more on how Thorium Classic works. In Thorium Classic, the sensors officer types text into a box with their scan query. "Nearby pirate ships." "Weapons on the USS Ranger." "Mutara Nebula Radiation." etc. The Flight Director or co-Flight Director types in an answer and sends it back. Obviously this isn't feasible in a fully automated set up. Even doing raw text analysis would be complicated and tricky, where the computer can determine the intent of a scan query (but really awesome if we got it right). So what needs to happen is a combination of Thorium Classic and Empty Epsilon. There are preset scans which the sensors officer can pick from, with different options for scanning open space vs. scanning an object vs. scanning a specific kind of object, like a ship or planet. So we could do something similar to what you described. The crew member selects a ship and scans for "Classification", which tells them how big the ship is. Then they have to scan for "Faction". These kinds of scans probably go pretty quick. Other scans that get more specific take longer to complete, like scanning for the max speed, weapons capabilities, or shield strength. All of these would have to be separate scans, but I imagine they could fire off multiple scans simultaneously. However, each scan drains their available power and having multiple concurrent scans slows down all of them - only so much sensors to go around, I suppose. Once Sensors scans the ships, the properties that are identified are made available to the other stations when they look at the ships on their controls. I would love thoughts on all of these. If you've got lots of thoughts on Sensors, it might make sense to just start another discussion too. |
Beta Was this translation helpful? Give feedback.
-
IconsI think context will determine what's used. Some will get reused from context to context Huge scale map (multiple solar systems):
Large scale map (approximately solar system size):
Smaller than solar system, larger than automated short range sensors Short Range Sensors Rendering in 3D for a viewscreen may suffice, but a tactical view is supposed to simplify the decisions necessary during combat. Some of these view concepts may reveal a basic difference in philosophy for how these bridge simulations should run. The starship Enterprise rarely blows up during the show. Without making everything a cakewalk, it will be a challenge to write automated missions with some sense of perilous adventure without running the risk of catastrophic mission failure. With a flight director, there can be some allowance for poor tactical or strategic decisions because the flight director can protect the crew from themselves or an inherently dangerous universe. If it's largely automated, it's easy for either the crew to destroy themselves or to take unforeseen actions that cause the mission to hang. When you have a group that has scheduled an outing to go on a simulated space adventure, you want them to succeed. That's hard to do if you grant them any significant degree of autonomy (I'm thinking the younger participants). Similarly, if a group of adults schedules a similar kind of outing, they'll get bored if there's minimal challenge (everything has some kind of safety factor protecting the ship and crew). I tend to write missions where there's always a real possibility of getting destroyed or defeated or failing the mission with the idea that the journey itself is as entertaining as the success of the mission. This often means multiple attempts to complete a mission, learning from the deadly mistakes of the previous attempts. If it's written well, there should be enough clues given for the crew or crews to succeed |
Beta Was this translation helpful? Give feedback.
-
|
I think I agree with pretty much everything you describe here. Good tradeoffs, good alternatives and options. Giving options to the crew to let them decide how they want to view things makes the most sense to me. |
Beta Was this translation helpful? Give feedback.
-
This discussion is about two topics that relate to each other: What ship classifications should there be, and how should ship icons be handled?
Ship Classifications
Ships are defined in plugins as classification templates, like a 'Galaxy class" or "Defiant class", to use Star Trek terminology. During a flight, these can be stamped out to create actual ships, like the USS Enterprise or USS Defiant. Most of the properties of the ship should be defined on the ship template itself, but I also want to have broad ranges of classifications to more easily make distinctions between different groups of ships.
These will be built-in to the codebase, and are not configurable by end-users (though we could add more classifications later on if deemed necessary)
Example classifications, based on ship size:
I think this provides a good balance between not overwhelming with choices while giving a good range of options. I also intentionally avoided obvious military classifications, like "Destroyer" or "Battleship".
Any suggestions for other classifications or renaming the classifications I've chosen?
Ship Icons
Ships will have icons that will show on the sensor grid, tactical maps, and other places. How should these icons be defined?
(Quick aside, since I know this will come up - I think Sensors will be tasked with identifying ships on the sensor grid, similar to how it is done in Empty Epsilon - they have to scan the ship to find out what its faction or classification is. Until that happens, it will use a built-in generic icon.)
We could just have each ship template define it's own icon. However, in my experience as a Flight Director, I most often want the ship's icon to correspond to its faction - Starfleet ships get a Starfleet logo, Klingon ships get a Klingon logo, etc.
Ship templates are not bound to one faction. There could be two opposing factions that happen to use the same classification of ships. Does that mean that the factions should decide what icon ships should have?
And should there be separate icons for each classification of ship, to make it easier to tell the classification from the sensor grid just by looking at the icon?
Here's my proposal: All of the above. Factions define icons for each level of classification (another reason to limit how many there are). Ship templates can define their own icon, which overrides the faction icon.
Sound good?
Beta Was this translation helpful? Give feedback.
All reactions