Posted May 18, 2021
This is a list of issues, based on notes i made during EA 0.5 gameplay so far.
1st line of each paragraph is a short issue description. Following lines of a paragraph, if any, provide extra info and/or my suggestion for the issue. So, to quickly check "what it's about" - it's sufficient to only read 1st line of each paragraph.
In no particular order,
- issue: player data tab, "favorite weapon" - beam laser remains "favorite" one, even when other weapons are being used for massively longer time.
-- suspected cause: "favorite" weapon is defined by number of hits, and beam laser hits per second - is massively higher than any other weapon's, creating this problem.
- issue: map delay - in many locations, opening the map for the 1st time after entering the location - causes several seconds delay. This issue happens repeatedly, whenever player exits and re-enters same (or, other) location and then opens the map.
-- observation: during this delay, CPU usage does not go up (even when way below 50%), and GPU usage even spikes down to nearly nothing. In the same time, opening the map once again without leaving current location - produces no delay whatsoever.
-- suggestion: this can and should be optimized.
- issue: to travel to other locations, most of the time, player needs to open the map and place a map marker. This becomes one tedious part of gameplay after a while. Especially with previous issue also present.
-- suggestion: allow the player to create permanent, replaceable map markers for often-visited locations. Those would not disappear after player enters marked location, but could be removed by the player at any time. Assign to each such marker a different color (possibly picked from specific color range), or have those permanent map markers having numbers on them (1 to 9 per each system).
- issue: incorrect readings of either cockpit speedometer, or distance (in HUD) to an in-location target, which happens when flying at high speed. Readings are sufficiently off to be "felt" wrong.
-- details. Assuming it's km/h for cockpit speedometer. At high speeds its readings are ~12% lower than they should be, possibly more at times, per following. Verification method used: striker, inertia dampeners off, energized boost towards distant marker. Results: distance of 1 km (6.7 to 5.7 km left to the marker) is covered in 23 frames of a 30-FPS video (1st frames to have both distance readings are the beginning and end of this 1 km run). In 6.7km 1st frame, speedometer said 4153 km/h. In 2nd frame (5.7 km to the marker), it said 4110 km/h. Average speed during this 1 km from speedometer = 4131.5 km/h = 1.143679 km/s. To cover this 1 km at this speed, the ship would need 0.87437s. But instead, the ship covered it in 23/30 = 0.7667s, meaning the ship was moving ~12% faster than speedometer indicated, if HUD-displayed distance to the marker was correct - OR, if speedometer is correct, meaning that distance to marker was displayed ~12% less than it actually is. This can't be any error from roundings and such - too big a difference.
-- low-speed test: scout, moving towards a marker, forward thrusters, no boost, cockpit speedometer 383 km/h at all times - took 70 frames (30 FPS video) to move from 1000m to 751 meters mark. 70/30 = 2.3333s; then, 383 / 3.6 * 2.3333s = 248.24 meters. And it's 1000 - 751 = 249 meters by distance marker change. This is extremely good match. Means, the issue only exists at either high speeds, and/or for energized boost specifically.
- issue: cockpit speedometer showing km/h, but "speed speed" stat in Ship screen shows it in m/s.
-- suggestion: use same units of measurement for both. Can be confusing to players, otherwise.
- issue: manual supralight flying is too slow to be of any practical meaning.
-- suggestion: much increase supralight non-autopilot flying speed, overall, at least for long distances (50+ Ls). Manual piloting would then have some useful feature to it.
- issue: impossible to switch view (1st/3rd person) in supralight with enabled autopilot. Ccorresponding button does nothing, but works fine with autopilot off.
- issue: NPC skirmishes are grossly broken at times - weak NPCs beat times stronger ones, lots of strong ones can't beat a single weak one, etc.
-- example: i observed a lone outlow drone easily taking out elite G&B fighter, in a couple-minutes-long 1-on-1 fight between the two; while few kilometers away, simultaneously - lone regular G&B fighter endured, endlessly, vs multiple outlow attackers at once, one of them being a heavy outlow fighter. They scratched its shield a few times a tiny bit, which it easily regenerated to full - something his elite fighter failed to do against a single basic drone.
- issue: distress calls regularly generate too weak attackers, like 2...3 drones, and without reinforcement wave of outlows, too.
-- explanation: it's boring because it's way, way too easy.
- issue: in distress calls and "repel attackers" jobs, it is very bad to have outlaws to keep pounding freighters while under attack of a combat vessel (player's), provided that player keeps enough range from outlaws (not difficult).
-- explanation: it makes it massively easier to plunder those freighters - should player quickly be under enemy fighters' fire, he'd have much harder time blowing up the freighters, plus, as it is now - attackers keep damaging freighters, which actively helps pirating players to bring freighters down, too. Pirate's life should be harder than "law abiding pilot"'s life - not easier. Usually.
-- suggestion: per above, it'd be best to script all hostiles in those encounters to switch their target to be the player, permanently, all at once, no matter distance to the player - as soon as player deals any damage to any of the attackers. And same thing - as soon as player deals any significant damage to a freighter, too: then, also, make all the _attackers_ to start attacking the player, and player only. The latter case - is because outlow pirates would not be willing to share their plunder with a stranger, i.e. the player. Pirates' thikning: "we can finish freighters off later - after we kill this intruder". So, in both cases, it'd be "coordinated, surprise attack" against the player - as soon as player attacks either an outlaw or a freighter. In addition, if player deals any significant damage to any of the freighters - then have all the freighters to focus all their attacks on the player, too (freighters' logic being: "the old attackers stopped hitting us - but this new guy now does!").
-- observation: there are posts in discord from other players, who plunder / betray G&B in those encounters actively, and note exceptional ease and profitability of it.
- issue: "lost cargo" missions with multiple small containers with small yellow lights - are often too difficult or too bothersome to complete.
-- suggestion: add proximity sound "pings" to each container in "lost cargo" missions of this type.
-- observation: many players find this mission type excessively hard to complete, and some repeatedly fail it.
- issue: whenever a stack of items is placed to the bottom of ship inventory and then more of same items are picked up - game automatically moves the stack to the highest available slot.
-- explanation: inconvinient, because this makes it impossible to use bottom slots (ones not visible without scrolling in default inventory view) for "gotta keep with me" item stacks - they keep "jumping up", resulting in more inventory scrolls when "current loot" keeps filling bottom inventory slots.
- issue: all shops have very few items for sale, in compare to best looter-shooter games.
-- observation: traditionally, a "shop" features a few items for "each slot" (e.g. Diablo 2 shops), averaging ~5 or so per slot, with some variability. In ES2, this would mean ~5x8 = 40 equippable items, on average, in a shop inventory, give or take couple dozens. Instead, we see 1...12 or so. This makes any "serios shopping" to require excessive amount of shop visits for any specific gear, much deteriorating whole mechanic of earning credits to then spend them to buy better gear in shops.
- issue: whenever docking to any location when doing so completes a job - job-finishing dialog interrupts and cancels any small talk from the shop's owner.
-- suggestion: disable shop owners' small talk when going in with a job complete, or delay it for after job-related talk is done happening.
- issue: jobs which in addition to usual rewards also grant an item - usually have that item useless to the player, and thus not worth the effort.
-- suggestion: jobs should always grant an item with a random prefix. This would make it much more useful to keep looking for good jobs even after maxing reputation with a faction.
- issue: percentage of jobs offering items is too low. Often, multiple consequetive visits to job boards result in not a single item-granting job offered.
-- suggestion: make it so that ~half of all jobs grant an item, but in the same time, make it so all jobs which grant an item - would give no monetary reward. So player would have a choice: to go for items (which can be sold later on, if the item is not needed anymore) - or for jobs with monetary reward (which often will be higher value than worth of an item).
- issue: ship cruise speed (inside a location) is not affected by modifiers to ship's speed. Strange.
- issue: armor modules can't be marked in expanded inventory for batch processing.
1st line of each paragraph is a short issue description. Following lines of a paragraph, if any, provide extra info and/or my suggestion for the issue. So, to quickly check "what it's about" - it's sufficient to only read 1st line of each paragraph.
In no particular order,
- issue: player data tab, "favorite weapon" - beam laser remains "favorite" one, even when other weapons are being used for massively longer time.
-- suspected cause: "favorite" weapon is defined by number of hits, and beam laser hits per second - is massively higher than any other weapon's, creating this problem.
- issue: map delay - in many locations, opening the map for the 1st time after entering the location - causes several seconds delay. This issue happens repeatedly, whenever player exits and re-enters same (or, other) location and then opens the map.
-- observation: during this delay, CPU usage does not go up (even when way below 50%), and GPU usage even spikes down to nearly nothing. In the same time, opening the map once again without leaving current location - produces no delay whatsoever.
-- suggestion: this can and should be optimized.
- issue: to travel to other locations, most of the time, player needs to open the map and place a map marker. This becomes one tedious part of gameplay after a while. Especially with previous issue also present.
-- suggestion: allow the player to create permanent, replaceable map markers for often-visited locations. Those would not disappear after player enters marked location, but could be removed by the player at any time. Assign to each such marker a different color (possibly picked from specific color range), or have those permanent map markers having numbers on them (1 to 9 per each system).
- issue: incorrect readings of either cockpit speedometer, or distance (in HUD) to an in-location target, which happens when flying at high speed. Readings are sufficiently off to be "felt" wrong.
-- details. Assuming it's km/h for cockpit speedometer. At high speeds its readings are ~12% lower than they should be, possibly more at times, per following. Verification method used: striker, inertia dampeners off, energized boost towards distant marker. Results: distance of 1 km (6.7 to 5.7 km left to the marker) is covered in 23 frames of a 30-FPS video (1st frames to have both distance readings are the beginning and end of this 1 km run). In 6.7km 1st frame, speedometer said 4153 km/h. In 2nd frame (5.7 km to the marker), it said 4110 km/h. Average speed during this 1 km from speedometer = 4131.5 km/h = 1.143679 km/s. To cover this 1 km at this speed, the ship would need 0.87437s. But instead, the ship covered it in 23/30 = 0.7667s, meaning the ship was moving ~12% faster than speedometer indicated, if HUD-displayed distance to the marker was correct - OR, if speedometer is correct, meaning that distance to marker was displayed ~12% less than it actually is. This can't be any error from roundings and such - too big a difference.
-- low-speed test: scout, moving towards a marker, forward thrusters, no boost, cockpit speedometer 383 km/h at all times - took 70 frames (30 FPS video) to move from 1000m to 751 meters mark. 70/30 = 2.3333s; then, 383 / 3.6 * 2.3333s = 248.24 meters. And it's 1000 - 751 = 249 meters by distance marker change. This is extremely good match. Means, the issue only exists at either high speeds, and/or for energized boost specifically.
- issue: cockpit speedometer showing km/h, but "speed speed" stat in Ship screen shows it in m/s.
-- suggestion: use same units of measurement for both. Can be confusing to players, otherwise.
- issue: manual supralight flying is too slow to be of any practical meaning.
-- suggestion: much increase supralight non-autopilot flying speed, overall, at least for long distances (50+ Ls). Manual piloting would then have some useful feature to it.
- issue: impossible to switch view (1st/3rd person) in supralight with enabled autopilot. Ccorresponding button does nothing, but works fine with autopilot off.
- issue: NPC skirmishes are grossly broken at times - weak NPCs beat times stronger ones, lots of strong ones can't beat a single weak one, etc.
-- example: i observed a lone outlow drone easily taking out elite G&B fighter, in a couple-minutes-long 1-on-1 fight between the two; while few kilometers away, simultaneously - lone regular G&B fighter endured, endlessly, vs multiple outlow attackers at once, one of them being a heavy outlow fighter. They scratched its shield a few times a tiny bit, which it easily regenerated to full - something his elite fighter failed to do against a single basic drone.
- issue: distress calls regularly generate too weak attackers, like 2...3 drones, and without reinforcement wave of outlows, too.
-- explanation: it's boring because it's way, way too easy.
- issue: in distress calls and "repel attackers" jobs, it is very bad to have outlaws to keep pounding freighters while under attack of a combat vessel (player's), provided that player keeps enough range from outlaws (not difficult).
-- explanation: it makes it massively easier to plunder those freighters - should player quickly be under enemy fighters' fire, he'd have much harder time blowing up the freighters, plus, as it is now - attackers keep damaging freighters, which actively helps pirating players to bring freighters down, too. Pirate's life should be harder than "law abiding pilot"'s life - not easier. Usually.
-- suggestion: per above, it'd be best to script all hostiles in those encounters to switch their target to be the player, permanently, all at once, no matter distance to the player - as soon as player deals any damage to any of the attackers. And same thing - as soon as player deals any significant damage to a freighter, too: then, also, make all the _attackers_ to start attacking the player, and player only. The latter case - is because outlow pirates would not be willing to share their plunder with a stranger, i.e. the player. Pirates' thikning: "we can finish freighters off later - after we kill this intruder". So, in both cases, it'd be "coordinated, surprise attack" against the player - as soon as player attacks either an outlaw or a freighter. In addition, if player deals any significant damage to any of the freighters - then have all the freighters to focus all their attacks on the player, too (freighters' logic being: "the old attackers stopped hitting us - but this new guy now does!").
-- observation: there are posts in discord from other players, who plunder / betray G&B in those encounters actively, and note exceptional ease and profitability of it.
- issue: "lost cargo" missions with multiple small containers with small yellow lights - are often too difficult or too bothersome to complete.
-- suggestion: add proximity sound "pings" to each container in "lost cargo" missions of this type.
-- observation: many players find this mission type excessively hard to complete, and some repeatedly fail it.
- issue: whenever a stack of items is placed to the bottom of ship inventory and then more of same items are picked up - game automatically moves the stack to the highest available slot.
-- explanation: inconvinient, because this makes it impossible to use bottom slots (ones not visible without scrolling in default inventory view) for "gotta keep with me" item stacks - they keep "jumping up", resulting in more inventory scrolls when "current loot" keeps filling bottom inventory slots.
- issue: all shops have very few items for sale, in compare to best looter-shooter games.
-- observation: traditionally, a "shop" features a few items for "each slot" (e.g. Diablo 2 shops), averaging ~5 or so per slot, with some variability. In ES2, this would mean ~5x8 = 40 equippable items, on average, in a shop inventory, give or take couple dozens. Instead, we see 1...12 or so. This makes any "serios shopping" to require excessive amount of shop visits for any specific gear, much deteriorating whole mechanic of earning credits to then spend them to buy better gear in shops.
- issue: whenever docking to any location when doing so completes a job - job-finishing dialog interrupts and cancels any small talk from the shop's owner.
-- suggestion: disable shop owners' small talk when going in with a job complete, or delay it for after job-related talk is done happening.
- issue: jobs which in addition to usual rewards also grant an item - usually have that item useless to the player, and thus not worth the effort.
-- suggestion: jobs should always grant an item with a random prefix. This would make it much more useful to keep looking for good jobs even after maxing reputation with a faction.
- issue: percentage of jobs offering items is too low. Often, multiple consequetive visits to job boards result in not a single item-granting job offered.
-- suggestion: make it so that ~half of all jobs grant an item, but in the same time, make it so all jobs which grant an item - would give no monetary reward. So player would have a choice: to go for items (which can be sold later on, if the item is not needed anymore) - or for jobs with monetary reward (which often will be higher value than worth of an item).
- issue: ship cruise speed (inside a location) is not affected by modifiers to ship's speed. Strange.
- issue: armor modules can't be marked in expanded inventory for batch processing.
Post edited May 18, 2021 by Fins_FinsT
