Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
2 
Report this post
I'll test your ship designs and consider your recommendations. Some of the proposed balance changes sound quite radical, though.
Sounds that you have already used the configuration modding to test the balance changes, could you share the files?
- I've upped all projectile speed to nerf shields, so some ships that were effectively invincible (e.g. "WLKR Greyhound", except vs SuperGauss and sustained missile) can now be DPS'd down by lots of small ships.
- Plasma and small beams are now super viable (probably too much).
- I think gauss turrets should get a huge range buff to compensate for low fire-rate, but that's another discussion.
- I really like increased armour, especially when placed inside the internals of a ship. Survivability is better, and armour is now clearly much better than shields.
- I really like armour on some non-armour modules too (core, weapons etc), as it makes sense from a lore perspective, and nerfs beam snipers dramatically.
- Buffing armoured thrusters are probably my favourite change.
- Note: Didn't modify cost at all.
More feedback on the base game:
----- Battle Setup -----
- Allow me to see armour overlays when constructing a ship.
- New overlays for penetration resistance and structuralHp would be lovely & appreciated, as designing around them is important when different modules have different stats.
----- Balance -----
- Large Plasma is also underpowered. Needs to do far more damage.
- It's good that you allowed Chemical Thrusters to still fire once out of resources as that also made them broken. Do they automatically switch to energy?
Actually the chemical thrusters have internal input-only propellant storage and the thruster gets disabled completely once propellant runs out. This internal storage is kept topped-up from any propellant tank modules.
The idea is that separate propellant tank modules are only needed for extra endurance, which is useful for small fighters and probably avoids some new player confusion.
- Large Beams maybe should target missiles?
Large beams (and large plasma) are meant as primary weapons on larger ships.
The large beam has long burst time and relatively slow tracking speed, making it intentionally bad for missile defence as switching between targets will waste the burst.
- Thrusters having an infinite blocking distance limits designs. See "Cosmoteer" game for an excellent example of mitigating this.
Actually the blocking distance is 100 units, but yes practically meant to be infinite.
I've played Cosmoteer a bit, and what I really want to have different with BFE is that building boring "armored box" designs without any weak points should not be possible, or at least come with some heavy compromises.
The core idea being that optimal ship designs should not be such trivial boxes as balancing compromises makes it challenging and interesting. I've elaborated on this design choice somewhat more on other forum topics.
- Missiles in general could use a production building, or some kind of fixed size missile storage (e.g. 20 missiles, reloads 1 per second).
This is a design and balancing dilemma.
I want the missiles to be fairly powerful, meaning that with proper use they are effective against most ships and devastating against ones that lack means of defence against them.
It is very satisfying to see a swarm of missiles take out multiple light fighters, or a carefully aimed flanking attack drill to a core of a large enemy.
However, the missiles can easily become OP if you can have lots of them. Currently the balance relies on limited count, high cost, and limited launching speed.
- Kinetic missiles seems specifically slightly underpowered, although it is the only one that can penetrate shields.
I think kinetic is actually by far the most effective of the missile warheads, as each missile can deliver a precision-guided super-gauss shot.
The velocity of the missile also gets added to the projectile, so these are even stronger than from a cannon.
A single kinetic missile can usually kill a light fighter, and module-targeted flanking attack with 10-20 missiles can drill through multiple modules to destroy a core from a large ship.
- The AI will not aim SuperGauss at specific modules, so if the AI (or user) selects a module to aim at, the SuperGauss will rarely ever fire. This may be desirable for human pilots, but AI pilots should just fire the moment it hits 100% reload and the angle is near enough to probably hit any part of the enemy ship.
- The AI will not aim SuperGauss when flanking.
The super gauss firing logic does support targeting specific modules, but yes the ship movement logic doesn't have anything to turn the ship such that the fixed weapons could fire.
The ship motion control and logic for where to move is actually quite complicated because it needs to work (at least somewhat) for any kind of ship design, and for ships that are badly damaged too.
I fear that trying to add such weapon targeting logic to the mix could cause too much issues, and would need compromises like do you expose a flank to fire a broadside, and how to balance that for any kind of ship design?.
Maybe the whole movement logic should be rewritten with better design, but its not something I'm really interested in doing.
The specific issue with flanking is probably that the ship never reaches its destination position as the target keeps moving and turning, and thus the logic to face the target doesn't kick in.
The flanking logic is really only effective if the target is much slower than the ship that tries to do a flanking attack.
- Would be good to specify that the campaign uses Hull to store stuff in te Hull description.
It doesn't actually. All fleets have practically unlimited resource and "loose modules" storage. The mass of all carried resources and modules are added to the fleet's total mass which is then used to calculate the fleet's max acceleration.
btw. I'm now renaming the "campaign" mode to "career mode" as that is actually a much more what I have had in mind. There won't be a scripted story to play through, just a sandbox "universe" to grow a fleet etc.
- Energy storage on weapons can be pulled out by other modules. Recommend you only allow energy to go INTO weapons, never out.
(Although this does nerf the "missile launchers as implicit battery" strat).
Have you seen this with some specific weapon modules or how did you find such issue?
I already have logic in place that only allows energy (electicity) to move into the weapon module's internal storage. I can debug to verify the logic, but would be easier to have a starting point.
- Warn me if a ship has thrusters not in any movement groups.
The "design evaluation" tab of ship editor has a warning for this, and you can even click on it to select those thrusters.
- Add feature: Tell ships to move to a location without rotating. E.g. "Sliding". ("Particle Fleet" game).
There is already a "heading lock" feature, setting of which is by default bound to extra button on the mouse and clearing to the backspace key.
- Add an on-screen "missing resource" icon over weapons that are "reloaded" but don't have enough energy or radiator.
Where? As part of the resources overlay?
- Add $"{currentHp:00.00} / {functionalHp:00.00} ({structuralHp:00.00})" to the modules viewer.
I don't get this, can you elaborate what and where this would be?
What is "modules viewer"?
Current HP only really makes sense for in-battle (and in career mode when fleet is not fully repaired yet)
The "module browser" in ship editor already shows functional and structural HP stats in the tooltip.
- Add the ability to tick the game 1 tick at a time.
The game doesn't use a fixed tick length, but I guess this could be a debug function to do single update loop with some predefined time step.
What would be the main use for this?
- Beams consume 1 ticks worth of resources every tick, which would be fine except that they also have a burst time and reload time. Decompiled code to confirm: Compare `BeamWeapon.fire` to `Weapon.fire`.
Good catch!
The beam firing logic is pretty old code, but the intention has been that the beam will first wait for resources to do a full burst and then always emit the beam for the full burst duration.
The implemetation seems indeed wrong, and I'll probably fix it such that electricity is consumed and heat generated at the start of the burst. However, a bit tricky thing is to ensure that if a firing command is given during a burst and resources allow, the beam will continue to fire without a break between bursts.
- The "Velocity Limiter" should limit acceleration and max acceleration rather than limiting to 10s. I.e. I use it to ensure my ships fly towards a target *together*.
Making ships fly in formation is actually a pretty difficult problem I once tried to solve using a multi-axis motion control library to synchronize the accelerations and deaccelerations for N ships.
It didn't quite work but maybe I should revisit that again sometime.
There are general issues like achievable acceleration of a ship depending heavily on the relative direction, and also mixing with the rotation control which uses same thrusters.
The collision avoidance also gets mixed in, sometimes overriding the control and causing ships to not reach their expected performance.
The collision avoidance is set to look up to 10s forward in time for collisions, so limiting the velocity to such that a ship can stop in 10s derives from that. Same collision avoidance is also used to avoid going out of the level bounds by defining those as static barriers.
The enemy "fleet-level" combat AI uses a simple method of limiting the max velocity of ships to that of the slowest ship until they reach enemy weapon range. This keeps the fleet somewhat together, but often makes them super slow, pretty much waiting to get flanked.
- In competently balanced ships (see my Workshop entries), Large Shields are extremely OP.
- Funnily enough: I'd also say that shield size is far too small, especially for Kinetic. Why? Kinetic shields ability to deflect projectiles is an amazing mechanic, but this rarely works due to their small effect radius. They have to be right at the edge of armour to have that effect.
Some quick thoughts about this:
Your workshop ships are indeed almost unbreakable by utilizing overlapping large shields and lots of generators to keep them up. The compromise seems to be that they are: Slow, internally weak (mostly generators), and expensive.
I think the energy requirements of large shields will need to be further increased to make having full coverage impractical. Maybe best way will be to significantly increase the energy drain of defeating beams and plasma projectiles.
The shields being small so they have to be placed at the edge where they are vulnerable is intentional. This ties to the weak points and compromises thinking for ship design and generally not being able to have perfect or even "good" defence all around your ship.
I remember Cosmoteer having ships with 5+ layers of armor in front of shields, engines, and all other vital parts, which is just frustrating as only way to win is through brute firepower to overwhelm the power delivery.
At least personally I would like the ship design meta to be such where ships can get partially disabled and even torn apart by well placed salvos, but well designed ships can still keep fighting because of e.g. some internal armor modules and redundancies that keep the core(s), some weapons and actuators operational.
Having all modules be more or less bullet-sponges also goes against that ideal.
The kinetic shields are currently intended for use together with some armor, and also to guard against ramming attacks.
I have had an idea to allow customizing the shield arc from 360 degrees down to maybe 90 degrees, which would give more range in one direction but leave others vulnerable. The shield penetration math and logic for beams would get even more complicated, though.
- Allow me to see armour overlays when constructing a ship.
The same overlays from battles are also available in the fleet & ship editor, but there is no UI to toggle them on and off. You can use the shortcuts Ctrl + F1 etc. to toggle them on and off.
- Large Plasma is also underpowered. Needs to do far more damage.
The issue here is mainly that plasma weapons don't penetrate like kinetic projectiles do, so increasing the energy of large plasma shot basically just causes it to delete a single module on contact, which is boring and ineffective.
I've done somewhat hacky special handling to work around this, where a single projectile can't one-shot a module but also causes some area damage by triggering a small explosion.
The same explosion simulation is used as with high-explosive kinetic projectiles and missiles, but it also has tendency to just delete a single module and cause little damage to others.
- Trying to mod shields seems to break them.
- Mirroring during building breaks manual resource groups and "calculated movement groups".
- Seems like the generate fleet button is broken.
- Cannot read ship or module info due to white text on white game graphics. Need black background.
Can you elaborate on how to reproduce these bugs?
Regarding the UI issues, is your environment somwhat special like using Windows 11, using high scaling ratio or something?
The game also keeps a log file under "Battlefleet Engineer\User Content\debugLog.txt" which might have some useful info if e.g. exceptions occurred.
I've clearly made a few bad assumptions :) , but my mistakes may be worth considering as "UX feedback".
Note: Don't feel obligated to reply to everything. I want to be respectful of your time.
My PC: Ultra-wide-screen 5120x1440 on Windows 10, so I normally have the game view Windowed 2500x1300.
- "Actually the chemical thrusters have internal input-only propellant storage.."
TIL. Fair point, perhaps worth renaming "Propellant tank" to "Auxiliary propellant tank" or similar.
- "Large beams (and large plasma) are meant as primary weapons on larger ships."
I understand this, but I'm just reiterating that find it a little odd that my ship with 3 large lasers will not even attempt to defend itself against missiles, especially when otherwise out of danger (far outside max range of enemy ships) and when the missiles are coming head-on.
- "what I really want to have different with BFE"
Totally fair design goal and justification. I personally think that the opposite is true, but I respect the idea.
- "I want the missiles to be fairly powerful etc."
Yeah great points. It'll perhaps get more clear once "Career Mode" establishes the process involved in re-arming missiles (if it hasn't already).
- "I think kinetic is actually by far the most effective of the missile warheads"
Interesting POV. I'll run some more "Vanilla mod" testing.
- "The super gauss firing logic does support targeting specific modules"
Yes exactly: The fact that the AI will target the core specifically ends up disabling most sGauss.
- "The ship motion control and logic for where to move is actually quite complicated"
I understand. It's an extraordinarily complex problem.
- "I fear that trying to add such weapon targeting logic to the mix could cause too much issues"
Fair points. Right now I believe sGauss only fires for AI ships if they just "so happen" to rotate enough to line up the sGauss with the targeted part.
FWIW: Cosmoteer has an evaluator that scores each cardinal (i think) direction of the ship on "how much damage can this side do?" and points that side towards the enemy. A similar scoring could be done for defense + sGauss. This would also solve the flanking problem (as ships would prefer to show their front armour to whoever they are attacking, even if flanking).
- "[Regarding Hull storage] It doesn't actually."
Oh, TIL. It was an assumption I made after seeing the "Campaign tug 2" ships. Are they just there for additional thrust then?
- "Have you seen [weapons stealing energy from other weapons] with some specific weapon modules or how did you find such issue?"
Yes. 100% repro with the sprinter plasma. Weapons on the top half of the ship (the ships left) get priority (most likely due to mirroring creation order). The bottom plasma will attempt to recharge but it'll have its readiness drop over time as the other weapon steals all the energy. Tested with vanilla settings.
- "The "design evaluation" tab of ship editor has a warning for this"
Oh, I didn't notice. It's probably because I rarely have that window open these days.
One window I do always have open is "Action Groups". Putting that error in that window would be a huge help.
Speaking of windows: Can you make the game remember that I've opened "Priority resource groups" and "Module options" please? And where I've moved them to? They spawn on top of each other?
My workflow is: "Make ship change > Save > Playtest against itself > Repeat loads".
Speaking of that fleet + ship design workflow, my wishlist:
1. Increment a version number whenever I save.
2. Store those incremental ships into a temp folder and make them available as UI.
3. Option to test my current ship iteration vs a previous version (default to the last version).
I worry that some changes will make my ship worse, so being able to test versions against each other would be fantastic QoL.
- "There is already a "heading lock" feature, setting of which is by default bound to extra button on the mouse and clearing to the backspace key."
TIL! I don't have that key. Trying it with the L key. Oh nice! Your rebindable controls menu is fantastic btw.
- "Where [to show reloaded but not got energy or radiator]? As part of the resources overlay?"
Yeah. Maybe an "electricity" icon if it's low on energy? Etc.
Bug: You need to toggle ON "damage" to view per-part "Module resources". Feels like that should be under the "Module resources" toggle?
- "I don't get this, can you elaborate what and where this would be?"
Sorry yeah. When you mouse over a module in-battle you get a bunch of text in the top left about each module. Adding:
1. All hp values (current, structural, functional, absolutes and percentages)
2. Any armour values if applicable (absolutes and percentages)
3. The name of the selected piece.
4. Fuel overlays on propellant thrusters.
etc.
This is also the text I described in the following bug:
""Cannot read ship or module info due to white text on white game graphics. Need black background.""
Adding a black background to the label would help a lot. Ditto for showing ship info and update time. See pic: https://drive.google.com/file/d/1w8gN14JJa4SjUxF6QLxSNmx5UGibvPry/view?usp=sharing
Related: One cool feature I found out about recently is right-clicking on any ship to view stats. Suggestions:
1. Having the visual auto-update may be better UX than "hovering to find out".
2. They should warn if: Low on electricity, Radiators maxed, no more weapons, or if a part has been destroyed within 10s. E.g. Factorio "Part is taking damage".
3. Have the right-click functionality be part of the tooltip. E.g. "WLKR Titan\n<i>Right click to view detailed statistics.</i>
4. Enemy ships should have a different colour to distinquish them.
5. Bug: Says "Destroyed" if it fled.
I really like the green + grey bars under each ship in the viewer though.
- "What would be the main use for [1 tick]."
Debugging weapon damage and reload efficiency. E.g. How many ticks after reload completed do I need to wait for radiators to work?
- Regaring beam bug.
Maybe if the fire command is issued DURING a burst, it'll ALWAYS attempt to re-fire (even if the target gets destroyed in the meantime)? That's by far the most common case.
- "Making ships fly in formation is actually a pretty difficult problem"
Yes it is. Fair point. Limiting the entire fleets velocity is a nice option to expose to the player, FWIW.
- "The collision avoidance also gets mixed in, sometimes overriding the control"
It would actually be nice to see an in-game line render showing collision avoidance override direction and power to help explain why my ship is flying so erratically.
- "Same collision avoidance is also used to avoid going out of the level bounds by defining those as static barriers."
Oh fair. In the short term I'd love some fudge value (moddable?) to fix this.
E.g. Assume deceleration has been overestimated by 30%.
- "The compromise seems to be that they are: Slow, internally weak (mostly generators), and expensive."
Yeah, they're absolutely designed for frontal combat. Regarding expensive: They're actually far cheaper once you factor in that they can destroy 2-5x their value, especially with shields mitigating (presumably expensive) repair.
- "I think the energy requirements of large shields will need to be further increased...significantly increase the energy drain of defeating beams and plasma projectiles."
I approve of the goal, but my suggestion is to make them weaker for the same power drain (and clamp power drain), otherwise they wont be feasible at all.
I.e. The problem is: I don't want my ship to not be able to fire back if under heavy fire. I can fix this manually via resource groups, but it seems odd that power drain cant really be properly reasoned about.
- "The shields being small so they have to be placed at the edge where they are vulnerable is intentional."
Fair goal, but I'll reiterate that the nice thing about kinetic shields is that they make gauss miss. If all my shield does is make gauss hit another part of my ship, it's mostly redundant. In my opinion it would be cooler to lean into this feature (and force enemies to counter kinetic shields with plasma).
Especially as you currently need both kinetic and energy shields to reliably defend a single location.
- "which is just frustrating as only way to win is through brute firepower to overwhelm the power delivery."
I agree, but Cosmoteer shields have a great weakness (shields are breakable). Arguably BFE has the more OP shields in vanilla.
- "At least personally I would like the ship design meta..."
Yeah 100%. That is a pillar of this genre and BFE shines in that regard.
- "Having all modules be more or less bullet-sponges also goes against that ideal."
That's fair. To me it makes sense that some pieces have their own armour, but I agree with you that it has to be balanced against that goal. I may have been over-zealous with applying HP and armour.
- "ramming attacks."
That's a great point that I haven't tested at all. Brb!
- "Allow customizing the shield arc from 360 degrees down to maybe 90 degrees."
+1
- "The same overlays from battles are also available in the fleet & ship editor"
TIL! Ty. Discoverability is the issue here.
- "The issue here is mainly that plasma weapons don't penetrate like kinetic projectiles do"
Interesting issues yeah.
- ""Trying to mod shields seems to break them.""
Repro: Copy and paste the shield module into your own mod, without any changes. Observe that large shields in-game are reduced to a small size.
- ""Mirroring during building breaks manual resource groups and "calculated movement groups""
Sorry, to clarify: WLKR Greyhound has 3 lasers, and each are given their own resource group. If I press the "Mirror" button, those resource groups get clobbered.
Same issue when manually assigning movement groups.
- ""Seems like the generate fleet button is broken.""
Oh my God. I've just seen the problem. I tried to click "Add Ships" without first clicking "Generate Fleet". Maybe the "Generated ships" table and "Add Ships" button should be disabled (or invisible) until you click "Generate Fleet".
Also note: It should be 2 buttons: "Add Ships to Player" vs "Add Ships to Enemy".
Related: Seeing the value of my ship when I mouse-over it (tooltip) would be nice, to know what to compare against. Cheers!
The biggest thing will be addition of a settings dialog for the "Test battle" where level size, deployment distance to enemy fleet, and the enemy fleet to use can be set.
Some of the bugs you mentioned I couldn't reproduce and might be misunderstandings instead. I've altered how movement groups are assigned when mirroring, but the resource and weapon groups were already assigned based on the mirror source.
- "Have you seen [weapons stealing energy from other weapons] with some specific weapon modules or how did you find such issue?"
Yes. 100% repro with the sprinter plasma. Weapons on the top half of the ship (the ships left) get priority (most likely due to mirroring creation order). The bottom plasma will attempt to recharge but it'll have its readiness drop over time as the other weapon steals all the energy.
This I think is not a bug but how the resource system works and some continuous electricity consumption happening in turret modules, not just when firing the weapon.
Basically the resource system doesn't distribute resources evenly, but simply gives as much as each storage / consumer desires and then moves to next one. This is simpler and also has the benefit that e.g. one weapon can fire sooner than 2 being charged evenly.
Each weapon module also has its own internal storage for resources from which it e.g. consumes electricity and dumps generated heat into. These also have limited directions so electricity can only go in and heat out.
At least the turret module also has kind of upkeep electricity consumption which is taken from the module's storage on each update tick. So if the module doesn't get any electricity from outside, the existing storage will slowly drain due to internal consumption, not "stealing" to other modules. Similarly also heat gets removed from the internal storage by the module itself at some rate even if it is not taken out by the resource system.
btw. Creating lots of resource groups probably has negative impact on performance as the resource system needs to make a kind of "evaluation pass" for each group separately.
Large ships are also slower to update compared to many smaller ones because game update tick happens in parallel (.NET Task-based multithreading) for ships, but update of each ship is done in a single thread and all ship updates must finish before moving on in the main game update loop.
I'm thinking that I should probably set up a wiki for the game and start writing articles about the many simulation and gameplay mechanics in the game, but it would take some significant effort to get decent coverage.
I once recorded this ~6 hours long technical explanation, and probably most of the core functionalities still apply.
https://www.youtube.com/watch?v=qf77wYf6Hak&t=14669s
Using the overlay is fine and can be definitely useful for "power players", which is why I've included the option in the settings menu, but I still regard it as kind of throwaway functionality just to help myself develop the game. Thus the UX of the debug overlay has never been a priority and its functions are not explained anywhere.
>"but the resource and weapon groups were already assigned based on the mirror source."
So the exact problem is:
1. You have a mirrored ship with, for example, a largePlasma on the left side (mirrored to the right side).
2. You create TWO resource groups: One for "LargePlasmaLeft", the other for "LargePlasmaRight", and you have all of the the generators and radiators on the left assigned to the "LargePlasmaLeft" (and vice versa). Thus, they can both fire continuously using their own pools of generators and radiators. You save this.
3. Some days later, you're editing the ship again and forget about the resource groups, and press "Mirror". Suddenly "LargePlasmaLeft" now has all of the mirrored modules selected as well (i.e. The modules on the right). The "LargePlasmaRight" now has ZERO modules selected. I.e. The values have been "clobbered" by the mirroring process.
It's quite a niche, esoteric bug, but it does affect "power users". I'm not even sure the best way to fix it, other than maybe to warn about resource groups being clobbered.
>"This I think is not a bug but how the resource system works and some continuous electricity consumption happening in turret modules, not just when firing the weapon."
Ah! Yes you're right, this would explain exactly what I'm seeing. The debug functionality showing "continuous" vs "per shot" power draw would be helpful.
>"btw. Creating lots of resource groups probably has negative impact on performance as the resource system needs to make a kind of "evaluation pass" for each group separately."
This also makes sense. Ty.
>"Large ships are also slower to update compared to many smaller ones because game update tick happens in parallel (.NET Task-based multithreading) for ships, but update of each ship is done in a single thread and all ship updates must finish before moving on in the main game update loop."
If you add a rule forcing all resource groups to be distinct (i.e. never contain the same module), you could in theory parallelize the module updates, but that isn't trivial and it would be easy to break.
>"I'm thinking that I should probably set up a wiki for the game and start writing articles about the many simulation and gameplay mechanics in the game"
Please don't feel obligated to do it just to make my questions easier to answer.
>"but I still regard [the debug overlay] as kind of throwaway functionality just to help myself develop the game."
Totally fair view, just giving my 2c that it would be a great feature of the game if kept. E.g. It helped me learn exactly what each of the circles (of the "resource overlays") means.
I'll probably have time to jump on the build later. That twitter screenshot is looking great!