1. mnikn 2023-05-02

    作为一个散修党表示认同,自从接触了其他领域上的技能后发现宽容度高了不少,对于一些水平不如自己的,从之前会想这个人怎么这么菜,变成了这个人只是暂时水平有限而已,没准之后比我厉害。我想可能是因为在学习其他领域上被人吊打的经历使得自己有了一点宽容心哈哈。

    PS:对于写日志的风格我觉得写得开心就好,如果非要提建议的话,我认为写日志前先想好读者能够从中获得什么。以这篇日志看,在我看来这篇日志的目的是分享观点,读完后我个人感觉关注点有点分散。例如一开始是关于联网从入门到放弃的过程,然后借此表达技术对赌的观点。有实例的观点是非常好的,但是实例最好不要太过繁杂,如描述联网那部分有挺多的技术细节,在我看来其实也没必要一一细说,重点是要表达因为不熟悉而导致联网实现中遇坑,为的是后面的观点做示例,联网遇坑的过程我觉得其实两三句说明就好。

    • RockTaoist 2023-05-02

      @mnikn:
      非常棒的建议,包括上次建议我把Gif整合成一张图片。
      1.关于思索读者角度这个事,我感觉自己想得太复杂了。我意图通过日志来锚定自己的轮廓,以及开发过程的轮廓。这是为了未来的队友而考虑的,他们能够从我的这些发散之中看到我的轮廓。比如未来某天一个路人,看到我对某个冷门游戏主题的耕耘,他们可能会产生了解的兴趣,而这些日志就会成为注脚。(当然,可能我的思路不正确,导致适得其反。)
      2.关于阅读关注点分散这个事,之前@π也提到过这个问题,这确实存在而且很严重。以超链+专题的方式实际上对读者会更友善,但专题的内容需要大量时间深耕,这会阻碍开发思路和进程。如果把技术的细则剥离,只留下经历与感受,又会导致“围绕项目”的关联度大幅度下降。
      3.我现在还在想办法设计出一种能够勾勒轮廓但又不分散的写法,但暂时还未找到解决之道。这次我迟了一个月写总结,也是因为意识到自己写的开发日志太散。如果实在不行,就只能分离内容了。
      4.之前也试着压缩过技术细则的分享,但总感觉不安。压缩很有必要,但还在摸索。

  2. ThirtyThree 2023-05-04

    建议:
    “通过文字与语言,很难描述清楚这个占地相关的机制”,往往文章里出现这种表述的时候,就是需要图像或Gif的时候。除非这不是本文分享重点。

    文中涉及只有自己或少数人熟悉的事物、技术时,需要考虑没接触过的读者能否读懂这段在说什么,由此,哪怕多写一两句解说,显得啰嗦,也不为过。

    • RockTaoist 2023-05-04

      @ThirtyThree:
      OK,下次会注意。这个机制是因为设计得有些复杂,外加偷懒没录屏。

  3. Dluck 2023-05-09

    最近我也在学习多人游戏的开发,深感这件事情并不是“找个文档学习两下”就可以加入游戏当中的。多人游戏必须一早就开始规划。其 API,架构设计都会受到很重的影响。
    加上我正在参与一个跨平台 UE5 项目,到时候也打算写一篇入门文章记录一下这个摸索过程。

    • RockTaoist 2023-05-09

      @Dluck:
      真的是被折腾得不轻。

  4. CoryluS 2023-05-20

    散修党+1
    深感你所说的这些劣势。每次想要重拾以前的技能时,就会因为相隔久远的时间成本而停滞不前。当确实需要这些知识时,又会因为后悔未能早拾技能而感到无比沉重的压力。随后,当知晓时间对于学习技能的重要性后,这份压力愈发强烈,甚至于影响自己对新技能的学习。

    看到你的文章后实在感同身受,想发发个人的牢骚,先说句抱歉……早几年未精进美术后,架上绘画功夫丢了,就很难跟上现在的数码插画趋势,自然也没法很快去适应游戏美术的内容;没有在小时候乐理知识最充沛的时候学感兴趣的编曲,现在想要制作些游戏配乐就非常困难了;正因为连重拾过往技能都如此困难,于是给了自己很多无谓的压力,如此,筹备学习代码这事更是望洋兴叹。也许确实如你所说——回头是岸,才是克服这些困难的正确选择吧?

    • RockTaoist 2023-05-21

      @CoryluS:
      欢迎讨论,本来写日志也是想看看能否从碰撞里产生一些新的认知。
      如果身处的环境允许专精,那最好还是专精。在垂直领域深耕,人的精神状态会更好。散修的那种海量的不确定性,太折磨人。

    • CoryluS 2023-05-21

      @RockTaoist:
      确实如此。总之借你建议,再努力努力了!

您需要登录或者注册后才能发表评论

登录/注册