Closed yuliurenkali closed 3 weeks ago
看了一下现在的框架结构
1.在memorypack的扩展上选择于pbnet共存。但是我觉得如果做多平台客户端那套rpc C#肯定用不了 必定要大改。那么在同样支持C#的godot和wpf平台下为什么不选择性能最优的memorypack呢。我看了一下现在的共存感觉完全是框架为了妥协一个版本的而去做的一个共存。像hybridclr和et一些 使用必定使用门槛的就是版本新一点。如果为了旧版本去做共存妥协会比较冗余。后面会考虑只保留memorypack吗?如果自己魔改的话 后面同步更新一堆冲突也不好解决。
2.在Unity端 我看memorypack导入时使用了 dll,为什么不考虑直接用包管理器安装,这样也方便更新,也不影响使用。类似et。
3.有考虑将服务端ft 客户端ft 还有打表工具三个脱离分开吗?因为如果你要做跨语言那么客户端ft肯定用不了 ,核心的ft还是保留的。打表工具可以让用户自行选择。不影响更新同时还能做更多扩展。三者都通过git的package去管理,不管更新还是魔改。三者都不会影响很大
个人的一些拙见理解。感觉可以避免很多接入需要魔改而不好更新的问题。
因为git仓库并不收费 如果独立成三个包 通过unity包管理器里的git url安装和更新 完全是一件很方便的事情,更不用说跨平台跨语言。
感谢您提的意见,针对您的问题我的回答如下: 1、git仓库是按照流量收费的,如果超出了流量是会收取一定费用。并且使用这个就必须要开梯子才可以使用,因为ft在国内的git平台也是有同步的。再加上做成包的话,你下次想要合并代码,只能自己建立一个仓库来更新,另外一个仓库来合并。 2、memorypack做成扩展有两个原因、首先,memorypack要求的Unity版本过高,部分还有用2021。其次,memorypack只是c#才可以使用,其他比如cocos是没办法使用的。所以综上所述,我选择将memorypack做成扩展,如果想使用添加扩展就可以了,既不影响使用memorypack,也不影响其他平台和版本限制。 3、目前服务端ft 客户端ft 还有打表工具三个一直是分开的,并没有耦合到一起。可以单独使用。 4、我目前也在寻找其他的一些包管理方式,比如nmp但这个还需要安装node.js才可以,这个是我不想的。后面计划用nuget来做了。
感谢您提的意见,针对您的问题我的回答如下: 1、git仓库是按照流量收费的,如果超出了流量是会收取一定费用。并且使用这个就必须要开梯子才可以使用,因为ft在国内的git平台也是有同步的。再加上做成包的话,你下次想要合并代码,只能自己建立一个仓库来更新,另外一个仓库来合并。 2、memorypack做成扩展有两个原因、首先,memorypack要求的Unity版本过高,部分还有用2021。其次,memorypack只是c#才可以使用,其他比如cocos是没办法使用的。所以综上所述,我选择将memorypack做成扩展,如果想使用添加扩展就可以了,既不影响使用memorypack,也不影响其他平台和版本限制。 3、目前服务端ft 客户端ft 还有打表工具三个一直是分开的,并没有耦合到一起。可以单独使用。 4、我目前也在寻找其他的一些包管理方式,比如nmp但这个还需要安装node.js才可以,这个是我不想的。后面计划用nuget来做了。
关于分开我的理解是这样会不会好点 比如有多个仓库类似Fantasy.Core Fantasy.Config Fantasy.UnityClient 到后面跨平台 Fantasy.CocosClient类似这样的多个仓库。 这样在很多平台都可以单独使用。不会所有东西都在一个仓库里
感谢您提的意见,针对您的问题我的回答如下: 1、git仓库是按照流量收费的,如果超出了流量是会收取一定费用。并且使用这个就必须要开梯子才可以使用,因为ft在国内的git平台也是有同步的。再加上做成包的话,你下次想要合并代码,只能自己建立一个仓库来更新,另外一个仓库来合并。 2、memorypack做成扩展有两个原因、首先,memorypack要求的Unity版本过高,部分还有用2021。其次,memorypack只是c#才可以使用,其他比如cocos是没办法使用的。所以综上所述,我选择将memorypack做成扩展,如果想使用添加扩展就可以了,既不影响使用memorypack,也不影响其他平台和版本限制。 3、目前服务端ft 客户端ft 还有打表工具三个一直是分开的,并没有耦合到一起。可以单独使用。 4、我目前也在寻找其他的一些包管理方式,比如nmp但这个还需要安装node.js才可以,这个是我不想的。后面计划用nuget来做了。
关于分开我的理解是这样会不会好点 比如有多个仓库类似Fantasy.Core Fantasy.Config Fantasy.UnityClient 到后面跨平台 Fantasy.CocosClient类似这样的多个仓库。 这样在很多平台都可以单独使用。不会所有东西都在一个仓库里
好比 万一想接入Luban的情况下,我可以只更新Core的Nuget包。就能使用服务器了而不去管其它东西更纯粹一点。打协议工具 甚至都可以 单独放在一个仓库里 或者一个脚本 完全不用跟打表的工具捆绑
是的,你的建议非常好,我考虑下看看怎么分开下。感谢您的建议。
是的,你的建议非常好,我考虑下看看怎么分开下。感谢您的建议。
要不就Core模块上Nuget包管理,毕竟这是脱离引擎的服务器核心也是跑在控制台解决方案上的。 Fantasy.UnityClient就还是走Git?然后发布版本成UnityPackage 直接在Git上下载这样。类似Cocos引擎也可以用类似的做法了。 甚至做成这样的git 方式 貌似是没有流量费的
然后Tools就可以 分成打表和打协议单独的两个工具 然后放同一个Fantasy.Tools仓库?
像例子就完全可以加一个Fantasy.xxxExample仓库
这些仓库的链接引用 完全可以在主仓库下面挂个链接引用 也挺方便的。
初见大大什么时候有时间折腾一下 ,想自己魔改更新 但怕后续不好同步大佬的更新
我自己刚刚将所有项目拆分成子仓库测了一下 就用普通的git管理都非常方便 顺便我也测试了一下Nuget ,也非常完美 有这两种方式去控制软件包不管维护和更新对开发和使用都超级便利!! 建议初哥赶紧上。
好的,我记录下了。下一个就搞这个。
我自己刚刚将所有项目拆分成子仓库测仓库 就用普通的git管理都非常方便 顺便我也测试了Nuget,也非常完美 有这两种方式去控制仓库不管维护和更新对开发和使用都超级方便!!建议初哥赶紧上。
您可以把您发布的Nuget包给删一下吗?因为我发布这个包,会提示名字已经占用了,只有你删了这个包,我才可以发布。
我自己刚刚将所有项目拆分成子仓库测仓库 就用普通的git管理都非常方便 顺便我也测试了Nuget,也非常完美 有这两种方式去控制仓库不管维护和更新对开发和使用都超级方便!!建议初哥赶紧上。
您可以把您发布的Nuget包给删一下吗?因为我发布这个包,会提示名字已经占用了,只有你删了这个包,我才可以发布。
您好您在尝试一下 我已经删除了所有版本的包,可能会有缓存延迟,您可以先试试
我自己刚刚将所有项目拆分成子仓库测仓库 就用普通的git管理都非常方便 顺便我也测试了Nuget,也非常完美 有这两种方式去控制仓库不管维护和更新对开发和使用都超级方便!!建议初哥赶紧上。
您可以把您发布的Nuget包给删一下吗?因为我发布这个包,会提示名字已经占用了,只有你删了这个包,我才可以发布。
您好可以发送一下您的nuget用户名吗。我将这个包的所有权转移给您
我自己刚刚将所有项目拆分成子仓库测仓库 就用普通的git管理都非常方便 顺便我也测试了Nuget,也非常完美 有这两种方式去控制仓库不管维护和更新对开发和使用都超级方便!!建议初哥赶紧上。
您可以把您发布的Nuget包给删一下吗?因为我发布这个包,会提示名字已经占用了,只有你删了这个包,我才可以发布。
您好可以发送一下您的nuget用户名吗。我将这个包的所有权转移给您
我的用户名是qq362946
我自己刚刚将所有项目拆分成子仓库测仓库 就用普通的git管理都非常方便 顺便我也测试了Nuget,也非常完美 有这两种方式去控制仓库不管维护和更新对开发和使用都超级方便!!建议初哥赶紧上。
您可以把您发布的Nuget包给删一下吗?因为我发布这个包,会提示名字已经占用了,只有你删了这个包,我才可以发布。
您好可以发送一下您的nuget用户名吗。我将这个包的所有权转移给您
我的用户名是qq362946
您邮箱检查一下我的转移申请,得您同意之后我才能转移所有权
看了一下现在的框架结构
1.在memorypack的扩展上选择于pbnet共存。但是我觉得如果做多平台客户端那套rpc C#肯定用不了 必定要大改。那么在同样支持C#的godot和wpf平台下为什么不选择性能最优的memorypack呢。我看了一下现在的共存感觉完全是框架为了妥协一个版本的而去做的一个共存。像hybridclr和et一些 使用必定使用门槛的就是版本新一点。如果为了旧版本去做共存妥协会比较冗余。后面会考虑只保留memorypack吗?如果自己魔改的话 后面同步更新一堆冲突也不好解决。
2.在Unity端 我看memorypack导入时使用了 dll,为什么不考虑直接用包管理器安装,这样也方便更新,也不影响使用。类似et。
3.有考虑将服务端ft 客户端ft 还有打表工具三个脱离分开吗?因为如果你要做跨语言那么客户端ft肯定用不了 ,核心的ft还是保留的。打表工具可以让用户自行选择。不影响更新同时还能做更多扩展。三者都通过git的package去管理,不管更新还是魔改。三者都不会影响很大
个人的一些拙见理解。感觉可以避免很多接入需要魔改而不好更新的问题。