子弹类可以做成虚类实现发射流程控制，各段位置和效果延迟到子类实现就好了，挺常见的多态场景
p.s. 网上很多程序猿段子根本不是程序猿写的，看着都尴尬

嗯

需要我帮忙吗？我想写你来做

你所有功能都写在一个Bullet类里？
正常来说是需要写个基类，不同子弹就写不同的类，然后继承。
例如:
1.子弹基础类BulletBase，实现碰撞逻辑和伤害交互。设置两个基础参数delayStart delayDestroy，开始时暂停运动逻辑，和结束后暂停逻辑销毁。
2.子弹飞行类(BulletLine继承BulletBase)，实现速度和角度驱动移动。会直线移动和转弯的子弹。适合不追踪的飞剑。
3.子弹追踪类(BulletTrack继承BulletLine)，实现子弹追踪移动目标位置(弧线移动，就是锁定目标后不断更改运动角度即可)。适合追踪的飞剑。
4.子弹组BulletGroup类，可以将子弹添加到子弹组 和从子弹组中释放子弹，比如飞剑周围的小飞剑
5.BulletMoveTo(继承BulletBase)，给定目标子弹会按轨迹移动到目标位置，可以设置偏移值。比如实现锤子的效果
5.长枪特殊就单独写个长枪子弹类

同意楼上说的，用多态

我的设想真的只想造小船
但如果一开始不设计成变形金刚，那么每条小船就真的要“造”出来才行
可在设计变形金刚的时候，我就又在问自己：我到底在干啥？我要的不是小船吗？
现在最困惑的就是一个独立开发：
究竟设计好变形金刚后，点点bool调调枚举写写参数就能出一艘船合适
还是复制粘贴东改改西补补的出一艘船合适？

取决于你对相关项目的开发经验
如果开发经验不足，或者对项目项目架构过于陌生，甚至还缺乏一份设计大纲的话，那这种情况是正常的，因为你其实根本就不知道终点在哪里，完全不知道自己在干嘛，只不过是在不断地朝着自己感兴趣的方向行进，而一直在路上到处乱走罢了
也可以看作是眼高手低，你对代码的实际掌控力，暂时还不足以轻松实现你不断拍脑门想出来的东西，同时也因缺乏经验，无法充分理解运用一些软件工程理论到实际中，而最终陷入迷惑
到底哪些地方需要预留设计、哪些地方可能存在过度设计（预留了拓展新但实际上根本用不上或没必要）、哪些地方是自己无法驾驭的，你也都还不清楚，或无法分辨，那代码自然越写越卡
一些个人建议：
A、老老实实先写设计文档（游戏的功能需求文档），然后觉得写的差不多了，就先不要乱改乱加需求，直接按照这份文档去写代码。
用于避免之后因为自己又拍脑门想加需求了，而去浪费时间到自己还无法掌控的代码拓展问题上，最终导致止步不前
B、代码分块，还有尝试从小功能或者小项目写起。等到对小功能、小项目写的得心应手了，再去尝试设计和编写更大一点的代码框架，这样才更容易推进项目，以及有助于理解、消化一些软件工程理论在实践中的应用情境
C、第一次写时，要抱着不怕麻烦的心态去对待。先硬写的思路是可行的，至于那些过于乱起八糟的拓展问题，等到之后迭代的时候再说（能想到并容易实现的就直接做，能想到但觉得不好做的、以及根本就想不清楚怎么做的，就都先无视掉）。
然后在初版demo完成后，再根据实际情况，来对整个代码进行重构，或对设计需求文档进行修改，做减法。
（总之，如果没有经验，就先试着快速地把demo版本给硬写出来，然后再在此基础上进行分析思考，随后果断抛弃掉demo中的一切代码，来对项目进行重构，不要嫌麻烦——敢于去重构代码并在这个过程中学习，这是众多编程大佬几十年传承下来的经验）
真想一步到位，能够在开头就把代码拓展的框架给设计好的直觉和经验，那是需要有多次踩坑经验后才能得到的。另外这也是为什么抄袭现成项目的开发难度会低很多的原因之一（不用过度纠结潜在的拓展问题）。

外行人问问这是什么引擎

这就是一个系统没有考虑全面造成的问题，最实际的解决方式，就是一开始就把功能框死。
游戏最重要的功能，仅可能是和交互有关的，不涉及和玩家交互的东西没有一点都不影响

你的问题是一开始就把功能写死了，抽象程度不足

没bug就算成功

刚开始思考不全面，多写点项目，多重构就好了

楼主写的好啊，看得出是真正在做事的