Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 530 All Categories
- 4 News
- 3 News and more
- 50 Rec Room
- 14 General
- 5 Off-Topic
- 6 Custom & Commercial Simulators
- 6 TV Shows, Movies, & Books
- 18 Forum & Website
- 321 Games
- 37 Artemis SBS
- 210 EmptyEpsilon
- 8 Quintet
- 11 Sigma Tau
- 8 Space Nerds in Space
- 9 Starship Horizons
- 33 Other Games
- 14 Software
- 8 Mods & Models
- 4 Helper Applications
- 1 WINE & Emulation
- 10 Hardware
- 6 Computers, Tablets, Screens, & Networking
- 4 Custom Controllers
- 18 Enhancing Your Games
- 11 Bridge Construction
- 2 Uniforms & Costumes
- 1 Props
- 3 Graphics & User Interfaces
- 33 Events
- 29 Conventions & Events
- 2 Meetups
- 2 Event Planning
- 5 Crews & Groups
- 5 Looking for Crew
- Groups Looking for Groups
- 1 Mission Reports
- 1 Mission Log
Comments
Only updating one "cell" per frame, so it's a bit slow in updating. While it can delete multiple cells in a single frame.
There is also no collision, so I mistakenly flew into the planet.
Yeah, this, or something akin to it, seems likely to be the cause of many oddities I have observed (e.g. ships "porpoising", oscillating orientations, weird figure 8 movements...). At any given moment, what the ship is doing might make sense, but perhaps over some short time span it oscillates between attempting to do two different things.
I also observed some behavior in which an NPC attempting to reach a waypoint that was nearby but that they were not facing while they were traveling relatively fast would cause them to sort of "orbit" the waypoint without ever reaching it. I relaxed the distance at which they were considered to arrive at the waypoint, and this helps. This probably accounts for some of the "figure 8" maneuvers I would sometimes see them doing.
I did still see some "porpoising" behavior sometimes, the cause of which is still unknown. I suspect some of the collision avoidance steering behavior code.
Debugging these guys amounts to watching them on the Demon screen until you see one do something weird, then selected it to get it's ID, then aitrace the ID and watch the console and try to figure out what it thinks it's doing.
To go on another tangent again, space terrain. I think there are two ways to approach space terrain, long-term strategic (when and where to fight to get an advantage) and the tactical (on no we about to die, look a nebula to hide in!). Gameplay is more varied and rewards captains who pre-plan their fights.
For my imaginary Expanse-tech-level game the Jupiter system (or a gas giant hybrid of jupiter and saturn) offers a lot of possibilities. I mentioned earlier that the moon positions can be interesting. A Homman (sp?) transfer orbit from Callisto to Io would take about 30 hours based on my rough napkin math. The rings (or even better with Saturn-like rings) will make some orbit changes more treacherous in a 2d map. Jupiter's magnetic field is wicked strong. Callisto is the closest moon anyone can live on the surface for any significant amount of time. The radiation around Io would kill most people in a week. On the other hand we know that antimatter is more plentiful in planetary radiation belts by several orders of magnitude.
I need to put a bit of a hysteresis on the level of detail switches. And the voxels where sampled at the corner, not in the center, giving some odd results.
In trying to fix that, I ran into a few more problems, and it starts to get pretty complicated. The starbases follow a fixed circular orbit, defined by an altitude and a quaternion encoding an axis of rotation and an angular velocity. So in theory, NPC ships could estimate how long it would take to reach a starbase from their current position, and knowing that, calculate where in the orbit the starbase would be after that much time had elapsed. And of course this new position might be a different amount of time away. You might be able to iterate this calculation several times, incorporating an error term and converge on a solution to sufficient accuracy. I'm not entirely sure, but let's suppose you could.
In SNIS however, NPC ships that have warp capability have some small probability of "just warping" to where they're currently trying to go if it's sufficiently far away. This system would need to be modified to account for the moving starbases. It's no good to predict where a starbase will be in a couple of minutes, when you would arrive by means of conventional thrusters, if you then along the way randomly and instantly warp to that location. Now you're early, and the starbase isn't here yet.
Additionally in SNIS, the NPC ships don't really "dock" with the starbases (uh, mainly because to dock involves ramming a "docking port" that is mounted on the spinning station, and that's hard to automate.) Instead they just hover near the station, presumably conducting their business with the station via transporters and radio. Well, if the station is orbiting (moving), then this hovering needs to move with the station as well.
However, in SNIS, an NPC ship's orientation is partially defined by its movement. It always points in the direction it is moving. And it always shoots a spout of fire in the opposite direction, the amount of which is scaled according to how fast the ship is moving. These would have to be changed for this "hovering near a starbase" behavior to accommodate a moving starbase.
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.
You can invoke Lua scripts from this screen which can either be full blown mission scripts, or simply utility or test scripts. The utility scripts I currently have are:
- CLEAR_ALL.LUA -- deletes all objects except human controlled ships
- DAMAGE.LUA -- inflict damage on the player (this script needs some work).
- DESTROY_SHIP.LUA -- destroys the specified ship
- DISABLE_ANTENNA.LUA -- turns on / off antenna aiming code (nobody uses this).
- ENABLE_ANTENNA.LUA
- PAY_PLAYER.LUA -- deposits some Z-bucks into the player ship's wallet.
- PLAYER_SPEED_BOOST.LUA -- sets player ship max speed to ludicrous
- PLAYER_SPEED_DEFAULT.LUA -- sets player ship max speed to normal
- REDALERT.LUA -- turns on red alert
- REGENERATE.LUA -- clears and regenerates (repopulates) the solar system.
- RESETBRIDGE.LUA -- resets a player ship to good health and fuel
- RESTORE_SKYBOX.LUA -- restores default skybox (not sure this still works).
- SAY.LUA -- Triggers text-to-speech on players bridge (allows GM to impersonate computer)
- SETFACTION.LUA -- changes the faction of a given object (NPC or player ship or starbase)
- SET_PLANET_DESCRIPTION.LUA -- sets the description of a planet viewable when it is scanned by science.
- SET_PLANET_ECONOMY.LUA
- SET_PLANET_GOVT.LUA
- SET_PLANET_SECURITY.LUA
- SET_PLANET_TECH.LUA
- SET_SB_FACTION_MASK.LUA -- allows starbases to reject docking for certain factions.
Additionally, the GM can kind of poke around visually within the solar system, select objects, move them around, and add new objects of various types, or delete objects. He can take direct control of NPC ships and drive them around and fire the weapons (admittedly, this does not work particularly well, and is something I should probably work on.) NPC ships may be directed to attack other NPC ships or player ships (the interface for doing this is pretty terrible though, and needs some work.)Various settings/options for the client and server may be selected via this screen via either menus or a bunch of variables you can set via "the console". Writing a generic "variable tweaking" system turned out to be a great idea.
A lot of what I've added to this screen amounts to whatever it is I need to work on or debug some feature of the game, and often it's a very minimalist implementation, just enough to barely work. I think there's room for a lot of improvement, esp. for things that are GM centric rather than "guy-debugging-the-code"-centric.
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.
If you do do full orbital mechanics, you run into a few issues, like engine strenght, and time "warp" requirements. As well as having a very complex to understand movement system (unless you played enough ksp)
Thats why I added orbiting for planets in EE only as an estetic thing. It looks nice from a distance. EE has it's basic, move things around and create new objects. As well as modifying properties of various object, most important ships.
Special features include the ability to export all items on the current map (or only the selected items) as mission script code. Really useful to setup positions for scripts.
Another important one is the ability to have mission scripts add custom buttons to the GM screen.
It does not offer much in the form of debug features. I'm quite adept at debugging with limited information. (Something with debugging systems where attaching a debugger is impossible, and adding a simple print can screw up everything as well)
EE's release builds to have a crash logging facility buildin. This proved to be extremely valuable tracking down crash causing bugs.
Two hardest to figure out bugs in EE where that AI ships would suddenly stop and do nothing any more (rare) and collision data not properly cleared. Both where quite tough, because they happened rarely.
The targeting bug was the toughest. Because the code looked sound, it was just missing a "const". This required first a whole bunch of extra log statements to find it, and then single stepping trough the all the code in a single if condition to find out it took the wrong path, and even that was hard to spot, as it was doing less code then I would have expected.
Details: It was implicitly casting objects to bools to compare them, instead of using the compare operator, this was an important patch to track these issues down:
https://github.com/daid/SeriousProton/commit/dc232f90c755fe001310409d4a7556e0f1d2f3b8
The collision bug, I don't remember exactly the fix. But I found the problem by just reading the code, and walking trough the possible paths in my mind. Resulting in a code path that destroyed the object, but kept the collision data alive in the box2d physics engine.
http://daid.eu/dump/record_193304_19112019.gif
Exploring a single level of simplex noise "caves". Looks pretty cool right? It has performance issues which are not visible on the gif, and a lot of other issues. But it looks quite cool already.
It would be quite awesome for clouds/nebula. But some of the shader features required for this to work are not available in my targeted specs. (OpenGL ES2.0) as I want the whole thing to work on Android as well. Without the limits that EE1 has.
These are pretty awesome however: https://www.shadertoy.com/user/Duke
https://github.com/daid/SeriousProton2/blob/master/src/window.cpp#L37
My engine directly allows gif recording by pressing F3. So it's very quick and easy for me to capture gifs and dump then on my shared folder (which is then directly accessible). No extra tooling needed, no screen recoding software, no encoding software, no waiting. Just F3, play a bit, F3, copy file, copy URL. Done.
TLDR: Because I'm lazy.
Note that one major issue for Android (20% of the devices), RaspiberryPi (2 and 3) and WebGL (depending on your desktop) is the lack of gl_FragDepth:
https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/gl_FragDepth.xhtml
Meaning raymarched rendered things won't have depth information, and thus are always rendered in front or back of all other things.
There are a few ways around this, but they get complex fast and require multiple render passes, which is also not that great for performance, and complex to get right.
However it's lacking in details, and though it links to a github, there appear to be only binaries there, no source: https://github.com/wolfniey/Procedural-Real-Scale-Planet-Generation-in-Real-Time
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.
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:
<blockquote>
Missiles are too powerful, while torpedos are really hard to use.
Most fights are either short-lived or never-ending.
Ideas:
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.
</blockquote>
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.)