It looks like you're new here. If you want to get involved, click one of these buttons!
This all starts to seem like an awful lot of work and complexity for something which doesn't really add all that much to the game.
I'd be curious about what sorts of things EE offers in the way of GM tools and features, or if anyone has ideas for GM features they'd like to see.
How feasible would it be to have a second render target, for those running a decent gaming pc for the main viewscreeen?
Haven't posted in here in a while.
But the procjam article is one of the methods I played with. It's quite a good way. But still, it is difficult to get all the details right with any of these methods. Concept is simple, but the devil is in the details. Like subdividing isn't hard, but undoing subdivision that is a lot harder. And partial subdivision leaves all kinds of edge cases.
My engine also has a limit of 64k of vertices per 3D mesh. So I need to split it into multiple meshes, which complicates things even more.
(The above has been in a draft post forever)
Random idea that has been drifting in my mind for a while. How about a very slow text based bridge simulator. Played over the span of days/weeks. For example directly integrated with discord/telegram. Similar to old school MUDs (if anyone knows those)
You basically sit in a sort of chatroom, and you can give commands through typing. And the game would play out in real time. For example it could take multiple hours to fly towards a destination target. So the helms officer sets up the flight computer to fire the engines until arrival, science uses it's scanners to find the target, and engineering manages that you have enough fuel to get there.
Science: !scan stations
Ship: 1 station found at bearing 300, distance 500km
Ship: Systems at 100% power. Fuel reserves at 80%.
Ship: Flight speed 10km/minute at 0.42% fuel per minute.
Helms: !turn 300
Ship: Rotated to heading 300.
Helms: !thrust 100% for 50 minutes
Ship: Firing engines.
It would require people to work together on longer intervals with shorter "intense" discussion moments. You could chat as much as you want, but proper ship control is only achieved together.
You might find your ship destroyed the next morning, as you stopped in the middle of the night somewhere in hostile space. So proper real life time planning would be required. Or you might be stranded somewhere because engineering boosted the engines using up more fuel then expected by helms.
Feedback from the ship could be separated into different chat channels, so you do not have all the information without chatting with your fellow officers. Or multiple officers could control the same part of the ship in different shifts, requiring time schedules. Or you could have a mole on your ship that tries to achieve some alternative goal without the rest of the crew noticing, if you have enough players (for example, try to get the ship stranded without fuel)
I've flirted with the idea of a MUD-like thing as well! MUD interfaces have come a long way too, especially with unicode and modern clients. Chat based systems could also be interesting as an irc/matrix/discord thing.
One thing I like about the slow pace is that you can play with people from around the world. Jumping into different roles would be easier too. The main navigator lives +10 hours and is fast asleep!
I got a recent issue reported for SNIS which is interesting from a game design perspective, maybe others would enjoy thinking about some of these things: https://github.com/smcameron/space-nerds-in-space/issues/243
I will quote the issue as reported here:
Missiles are too powerful, while torpedos are really hard to use.
Most fights are either short-lived or never-ending.
The goal would be to be able to have long interesting battles. Two common scenarios would be one big ship against several small ones (this is what we have in most missions right now), and one big ship against another one (bonus points if this interesting in PvP context).
Being experienced at the game and team play should be required to win, ideally.
The more interesting parts (to me) are: "Most fights are either short-lived or never-ending ... The goal would be to be able to have long interesting battles."
One of the specific fixes for the too-effective-missiles (The player can fire heat-seeking missiles which are super deadly) I have tried so far for SNIS have been to give the NPC ships a special behavior when a missile has locked on to try to evade the missile by moving in a direction perpendicular to the missile's motion (not all that effective as the missiles are faster) and to emit chaff to try to distract the missile. This works ok, though the missiles are still probably too strong, but at least they sometimes now fail to be effective and it might take 2 or 3 missiles where previously 1 would have sufficed. I probably still need to work on the missiles a bit.
The torpedoes in the game work like this: You aim what amounts to a 1st person gun turret with a mouse, and fire the torpedo with the mouse in the direction the guns are pointed. Once the torpedo is fired, it moves in a straight line at a constant speed in the direction fired. If it comes close enough to an enemy, it will inflict damage. Because the speed is not very fast, you have to lead the enemy. There is a cooldown, and you have a limited number of torpedoes. These all make the torpedoes a bit hard to use. Especially since you also have laser bolts, which are much like torpedoes except they move faster, do less damage, and can be fired much faster. But the misses don't cost much compared to missing with a torpedo, so players tend to lean on the laser. Maybe that's fine. But there does seem to be room for improvement in how the Torpedoes work to make them more fun, and different from the lasers.
Currently, damage to the player ship is distributed more or less randomly to the different systems on the ship. This means that at any given point in a battle, all of the ships systems will be more or less equally damaged. It might be more interesting to distribute the damage less evenly. One idea I had was to timeslice the distribution of damage, so that (say) for each 30 or 60 or whatever second interval, a new "victim" system would be chosen, and any hits arriving within that time window would be delivered to the same system. This way you would get the sense that the enemy is targeting a specific system, and battles might have different "feeling" from one another depending on which systems were targeted during the battle. Hard to know without trying it whether it's a good idea.
One thing I noticed a couple of years ago was a long-standing bug with the damage distribution system. The intent was that for each hit of a laser or torpedo on the player ship, damage would be distributed among the systems randomly, and each system would take some fraction of damage. However due to a bug involving unsigned integer math, systems could actually gain health when hit! The result of this bug is that you tended to live when you should have died, and it seemed that you would scrape by by the skin of your teeth. You can see this bug in action in this old video: https://www.youtube.com/watch?v=nTBiM5zJi8A&t=521s
Around the 6:00 minute mark, if you watch the warp power on the Nav screen, you can see it goes way down, then back up due to changes to the damage to the warp drive components. At the time, I thought this was just the repair robot doing its thing (if I noticed it at all). But the point is, this bug made it seem like I was just barely surviving, and fixing this bug kind of wrecks that behavior (not that that behavior made any kind of sense). However there's a common trick which I am strongly considering implementing, which is to make the last few of the player's "hit points" a lot tougher for the enemy to remove, to encourage this kind of "just barely surviving" outcome.
Anyway, any ideas you may have for making the battles more interesting would be interesting to read.
Warning: This is a spure of the moment trainwreck of thought.
HP 0 = blow up/dead is a very old game mechanic trope that is easy to understand. A nice explosion at the end helps close that combat loop. But another spin is to set up mission objectives that do not explicitly require destruction of ships, even in combat-centric sessions. Defend a starbase for x amount of time, escort a payload from a to b, etc. Ships no longer have to be destroyed, just disabled or forced to retreat. Fewer satisfying booms though. This leads to...
...treating ships as a collection of systems and sub systems instead of a monolithic ship (even more than they are now). This idea stems for a space engineers like survival game I wrote a doc on. The player character doesn't have hit points, but instead can have inflictions - traits that might be permanent or on timers, might be visible to the player or hidden without the right diagnostic tool, and may go away after the timer runs out or kills the player. I liked the interplay that it could give to a medic profession, something more intricate that just pointing a magic heal ray.
Fighting a ship wouldn't be a generic slugfest seeing who can get the other to 0 hp first. It would be trying to disable the other ship by targeting and taking out their ship's systems. These systems would be both mounted on the surface of the ship (weapons, sensors) and interior locations. Where a ship is hit would influence what is damaged (inflicted) or even destroyed. Treat the ship as voxels (not as a blocky rendering but to model how the ship is being damaged). Simulate heat so a player has to figure out where the in-universe equivalent to a warp core is by looking at an IR view. Different types of weapons and missiles will inflict damage on the ship in different ways.
Combat for the bridge crew would hopefully be more fun and tactical. Pilot will need to be mindful to keep very damaged sides hidden. If a player's system goes out they could conduct their own basic repairs.
There is some interesting discussion here, on the discussion board for Oolite (an open source single player space game inspired by the original Elite game) about NPC pirates, and in game economies, cargo contracts vs. trading commodities directly, etc. http://aegidian.org/bb/viewtopic.php?f=2&t=20569
There are other threads on that board possibly of interest as well...
The 370+ page screenshots thread: http://aegidian.org/bb/viewtopic.php?f=2&t=4494&start=5565
Some talk of shaders, and towards the end you see they have implemented a physically based rendering system (though the shader code appears to be licensed under a GPL-incompatible license, a CC-NC variant, iirc. unfortunately for me... although even if the shaders are a major part of a PBR pipeline... getting/making PBR assets is no small thing either.)