TypeSDK接入实现（5）
&&&&通常，游戏开发商并不会只在一个渠道上线他们的游戏，接入越多的渠道，代表着可能获取越多的用户，但同时也代表着越多的接入SDK工作量、工期和费用。一款游戏要有足够的用户，甚至需要接入30家以上的各种渠道，以保障自己的市场覆盖率。
单个SDK接入流程在一位有经验的全职客户端程序、一位全职服务端程序员、一位全职QA处理的情况下，需要3天时间才能完成。因此当一款产品面对30个甚至更多不同需求的渠道SDK时，人员成本和时间成本就会急剧增加。所以我们需要一个通用接口，来处理各种渠道的需求，这就是统一渠道SDK接入框架。 本部分主要提供平台SDK服务器与CP方游戏服务器交互的接口规范
1.2&& 支付基本流程
1.2.1 渠道支付流程
游戏客户端在每次用户点击购买时向服务端请求生成内部订单。并需要采用特定机制（例如一定时间内禁止连续点击购买）防止用户频繁操作对服务器造成过高负载。
游戏服务端生成的所有内部订单需要存储待查。并在得到渠道返回的外部订单后异步处理发货操作并以特定机制通知客户端更新数据显示。
渠道支付接口负责完成货币交易操作，生成并存储外部订单，供对账查询使用。
&&&&&&&SDK服务端转发请求时额外存储一份订单日志数据，存储内部订单号，外部订单号及订单状态，供对账及查找BUG时作为参考。
1.2.2 一般渠道支付流程图
1.3 协议说明
1.3.1 通信协议
&&&&&& SDK服务器采用HTTP协议作为通信协议，游戏服务器通过构造HTTP请求（POST方式）向SDK服务器发起接口请求。
1.3.2 数据协议
1.数据格式
&&&&&& 请求消息和响应消息的内容都使用JSON表示数据。
2.字符编码
&&&&&& 请求与相应内容均采用UTF-8字符编码
3.签名规则
&&&&&& 请求和响应中的签名均使用md5哈希进行，算法如下：
&&&&&& MD5(签名内容 + ”|” + apiKey)
&&&&&& 说明：
&&&&&& ·MD5使用RFC1321标准，编码后需转换成全小写。
&&&&&& ·描述签名的表达式中，”+”表示做字符串连接，实际产生的待签名字符串中并不存在。
&&&&&& ·签名内容指各接口请求数据中若干字段的拼接。基本格式为各字段值以 ”|” 符号分隔后直接连接。注意，由于”|”符号用作分隔字段，签名内容中需避免出现该符号，换行符(回车或换行)等特殊符号也需要预先剔除。如果对应字段为空，仍然需要保留“|”符号占位。
&&&&&& ·计算MD5签名时，应以UTF8编码取字符串的字节值。
&&&&&& ·appid及apiKey由打包工具分配，打包工具使用方法请参考使用文档。
4.签名示例
&&&&&& 假设请求数据为：
&&&&&& “data:{
&&&&&&&&&&&&& “id” : 123,
&&&&&&&&&&&&& “name” : “test”
&&&&&&&&&&&&& “value” : “something”
&&&&&&&&&&&&& “other” : “blarblar”
&&&&&& 要求的签名内容为:
id + name + value
则拼接后得出要签名的内容串为
123|test|something
假定apiKey=aabbcc，则需要进行MD5哈希的字符串为：
123|test|something|aabbcc&
1.4 接口说明
1.4.1 用户会话验证
1.请求地址：
&&&&&& 说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具说明，可以从客户端提交的参数中获取当前渠道代码。
&&&&&& 例：&
2.调用方式：HTTP POST
3.接口描述：
&&&&&& 验证用户登录结果。
A)&& 游戏客户端通过SDK客户端的登录动作获取用户登录信息。
B)&& 游戏客户端将获取的用户登录信息传送至游戏服务端。
C)&& 游戏服务端通过本请求将用户登录信息传送到SDK服务端，验证该登录信息是否有效。
D)&& SDK服务端返回验证结果及其他信息，供游戏服务器使用。
4.请求方：游戏服务端
5.响应方：SDK服务端
6.请求内容（JSON格式）：
用户唯一标识
对应渠道的用户ID。并非必传，未作说明的情况下传空字符串。
用户登录会话标识
本次登录标识。并非必传，未作说明的情况下传空字符串。
附加信息。并非必传，根据渠道不同，该字段含义不同，未作说明的情况下传空字符串。
MD5(签名内容&+& ”|”& +& apiKey)
签名内容：
Id + ”|” + token + ”|” + data&
7.返回内容（JSON格式）：
本次请求结果标志
用户唯一标识
对应渠道的用户ID
用户在渠道的昵称
对应渠道的用户昵称
用户登录会话标识
本次登录标识
如果请求出错，描述错误信息。
渠道返回信息
渠道返回的原始结果信息。&
响应码说明：
&&&&&& 0：渠道正常返回，结果成功
&&&&&& 1：渠道正常返回，结果失败
&&&&&& 2：渠道服务端请求错误
&&&&&& -1：提交的请求参数错误
&&&&&& -2：提交的请求转换成渠道参数错误
&&&&&& -3：提交的请求参数签名错误
&&&&&& -99：未知错误
id,nick,token说明：
&&&&&& 根据不同渠道定义的返回字段不同，此三个字段不一定有值。渠道未返回对应字段时，该字段值为空字符串。
1.4.2 充值结果回调
1.请求地址：
&&&&&& 该地址为充值结果通知地址，由游戏服务端在下文的SaveOrder接口中通过notifyurl字段提交至SDK服务端。
2.调用方式：HTTP POST
3.接口描述：
&&&&&& 通知用户充值结果。
A)&& 用户在游戏中向SDK客户端提交充值请求。
B)&& SDK客户端将充值请求转发渠道方
C)&& 渠道方异步执行充值。
D)&& 渠道方将充值结果发送给SDK服务端
E)&& SDK服务端通过该接口将充值结果发送给游戏服务端。
F)&&& 游戏服务端处理充值逻辑。
G)&& 游戏服务端向SDK服务端返回处理结果。
H)&& SDK服务端向渠道方返回处理结果。
4.请求方：SDK服务端
5.响应方：游戏服务端
6.请求内容（JSON格式）：
渠道返回的充值结果。
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
订单附加信息
游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数，则该字段为空字符串。
MD5(签名内容&+& ”|”& +& apiKey)
签名内容：
code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info
该笔订单价值折算为人民币的金额（以分为单位）供服务端校验使用，不参与签名。
7.返回内容（JSON格式）：
本次请求结果标志
如果请求出错，描述错误信息。
响应码说明：
&&&&&& 0：正常返回，结果成功
&&&&&& 1：正常返回，结果失败
-99：未知错误
8.推荐处理方式
游戏服务端收到该请求后可保存该次请求参数，随即返回code=0，表明成功收到消息。之后异步处理充值或发放道具逻辑。
1.4.3 充值信息提交
1.请求地址：
&&&&&&说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具文档，可以从客户端提交的参数中获取当前渠道代码。
&&&&&& 例：&
2.调用方式：HTTP POST
3.接口描述：
&&&&&&充值信息存档待查。
A)&& 用户在游戏中向游戏服务端提交充值请求。
B)&&& 游戏服务端生成内部充值订单号及相关充值信息
C)&& 游戏服务端将内部充值订单号及相关充值信息返回游戏客户端，供其提交给渠道方。
D)&& 游戏服务端异步将内部充值订单号，该笔订单回调url及相关充值信息发送给SDK服务端。
E)&&& SDK服务端将充值信息存档待查并返回处理结果。
4.请求方：游戏服务端
5.响应方：SDK服务端
6.请求内容（JSON格式）：
游戏客户端在提交订单时传送的内部订单号。
由CP生成订单时自定义的附加信息,不能为空及空字符串。
MD5(签名内容&+& ”|”& +& apiKey)
签名内容：
cporder + ”|” + data
订单回调url
该笔订单回调通知游戏服务端的url，不参与签名。
订单查询url
该笔订单向游戏服务端查询详情的url，不参与签名。
7.返回内容（JSON格式）：
本次请求结果标志
如果请求出错，描述错误信息。
响应码说明：
0：正常返回，存档成功
1：正常返回，存档失败
-1：系统错误
-2：参数错误
-3：签名校验错误
-99：未知错误
注意：SaveOrder接口在服务端生成内部订单号时请求。只有获取到该请求成功返回，才能允许客户端作后续充值动作。
1.4.4 充值信息确认
1.请求地址：
&&&&&&说明：URL中的{appid}代表游戏代码，由打包工具生成，{channelid}代表渠道代码，渠道代码列表可以参考打包工具文档，可以从客户端提交的参数中获取当前渠道代码。
&&&&&& 例：&
2.调用方式：HTTP POST
3.接口描述：
&&&&&&充值信息查询。
A)&& SDK服务端向游戏服务端转发充值结果回调。
B)&&& 游戏服务端向SDK发送充值信息查询请求，目的是确认该充值结果有效性。
C)&& SDK服务端根据提交的内部充值订单号查询充值信息并返回游戏服务端。
D)&& 游戏服务端根据查询结果进行逻辑处理。
说明：部分渠道提供信息查询接口，本接口将优先使用渠道的信息查询接口处理请求。如果该渠道没有提供信息查询接口，则查询&3.3.3&充值信息提交 接口中保存的充值信息，如果创建充值信息时没有调用该接口，或者没有查询到目标订单对应的充值信息，则会返回未查询到相应充值信息。
4.请求方：游戏服务端
5.响应方：SDK服务端
6.请求内容（JSON格式）：
游戏客户端在提交订单时传送的内部订单号。
MD5(签名内容&+& ”|”& +& apiKey)
签名内容：
7.返回内容（JSON格式）：
本次请求结果标志
如果请求出错，描述错误信息。
订单详细信息
根据渠道不同，返回相应订单信息。
响应码说明：
&&&&&& 0：正常返回，获取订单信息成功
&&&&&& 1：正常返回，没有获取到订单信息
&&&&&& 2：正常返回，获取订单信息错误
-1：系统错误
-2：参数错误
-3：签名校验错误
-99：未知错误
1.4.5 游戏订单查询
1.请求地址：
&&&&&& 该地址为订单查询地址，在SaveOrder接口中通过verifyurl字段提交至SDK服务端。
2.调用方式：HTTP POST
3.接口描述：
&&&&&& SDK服务端向游戏服务端查询收到的订单信息。
A)&& 用户在游戏中向SDK客户端提交充值请求。
B)&& SDK客户端将充值请求转发渠道方
C)&& 渠道方异步执行充值。
D)&& 渠道方将充值结果发送给SDK服务端
E)&& SDK服务端通过该接口向游戏服务端查询该充值请求是否合法。
F)&&& 游戏服务端处理查询逻辑。
G)&& 游戏服务端向SDK服务端返回查询结果。
H)&& SDK服务端比对订单信息并依此确定下一步处理流程。
4.请求方：SDK服务端
5.响应方：游戏服务端
6.请求内容（JSON格式）：
预留字段，区分本次查询操作类型。目前统一传0
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
订单附加信息
游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数，则该字段为空字符串。
MD5(签名内容&+& ”|”& +& apiKey)
签名内容：
code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info
7.返回内容（JSON格式）：
本次请求结果标志
如果请求出错，描述错误信息。
用户唯一标识
对应渠道的用户ID。
渠道订单号
渠道返回的订单号。
游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数，则该字段为空字符串。
该笔订单价值折算为人民币的金额（以分为单位）。
createtime
订单创建时间
该笔订单创建时间。
该笔订单的道具id，如果没有传空字符串。
(该字段标识订单中的商品ID，需要与客户端下订单时对应的字段匹配，验证对比不符时不发货)
Itemquantity
该笔订单道具数量，没有传0。
（该字段标识客户端提交的订单中的道具数量，渠道不接受该字段时，客户端提交的订单没有该字段，此时直接传0或1均可）
订单状态码。
备用字段，传送其他可供比对的信息。
响应码说明：
&&&&&& 0：正常返回，结果成功
&&&&&& 1：正常返回，结果失败
-99：未知错误
8.推荐处理方式
游戏服务端收到该请求后优先以CP订单号为条件查询，查询不到或请求中没有CP订单号时以渠道订单号为条件查询，找到匹配的订单信息并同步返回SDK服务端。
l& 支付相关接口内部订单号字段长度不能超过10位，格式使用英文字母和数字的组合，需要能够区分区服。不可重复。
l& 渠道返回的用户id用于用户唯一标识。单区服内不可重复。
l& 支付接口返回的amount是当次支付产生的实际金额。
该项目已开源，大家有兴趣可以自己研究或使用接入
项目地址：
项目地址：
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：4270次
排名：千里之外
原创：24篇
(4)(3)(1)(11)(5)用业余时间开发独立游戏应保持怎样的节奏？ - 知乎1264被浏览19113分享邀请回答/s/1kTT1OuN。4. Play Games（0.9.27a）和Admob（2.3.1）的Unity插件是有冲突的，放在一起无法直接编译通过，需要做以下步骤：1） 不要复制google-play-services_lib文件夹2） 复制android-sdk/extras/google/m2repository/com/google/android/gms/play-services-ads/8.4.0 到 /Plugins/Android.3） 删除Plugins/Android/GoogleMobileAdsPlugin/AndroidManifest.xml中的activity android:name="com.google.android.gms.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"4） 如果你也使用的Unity的IAP，还需要删除Plugins/Android/GoogleMobileAdsPlugin/lib/in-app-billing-service-aidl.jar以上我弄完就可以编译通过了，但是广告内容暂时没测，不知道会不会有什么问题。以上资料都来自于Google Play Games Unity Plugin的官方GITHUB中的ISSUE。具体的原因可以上去找找：5. 为了减少Drawcall，我把大部分散的图片都Pack到了一张Atlas中，Atlas的尺寸和Sprite的部署都需要注意。Atlas尺寸过大虽然可以有效减少Drawcall但是太吃内存，因为载入了根本不需要渲染的Texture。尽量把会同时出现的Sprites Pack到一起才有意义。否则Drawcall的数量减少会不明显（为了Pack成Square POT的Atlas我还专门写了个小工具，非常简单大家有兴趣可以自己试试，懒得写就Email我我给你发过去，实在写的太简陋不好意思拿出来）6. 没必要盲目优化。这个游戏的Drawcall数量在UI界面大概在15左右，关卡内在30-40左右。大部分的机器运行基本不太可能有什么问题，其实之前没PACK过也Drawcall也没破百，其实这部分工作我认为真的是纯积累经验了，效果并不大，因为玩家几乎是感受不到差异的，除非是设备非常惨的用户。三、关于美术
毕业之前一直都执着于做纯艺 ，对游戏的美术概念非常模糊。当时最常见的就是页游网游上各种炫酷仙侠修真之类的原画。于是本能的把游戏的美术和艺术生硬的切割开了。
随着在游戏行业见识增长，接触到一些风格独特的独立游戏，
发现并非我想的那样只有仙侠才会受欢迎。 接触到《纪念碑谷》时心里仿佛遭受了一记重拳，在我看来它是把艺术与游戏结合的一种里程碑式的尝试（见识浅薄，如果有其他欢迎介绍推荐）。艺术是可以横向发展， 相对游戏美术来说只是呈现的方式不一样罢了。游戏绘制同样可以是自我情绪的宣泄，同样能表达自我，一点都不冲突。这样的思路可能在画风上给予更多的视角，无意中产生了一种新的画面效果或绘画方式，这就是属于自己的干货。
做游戏时不会一拿到文件就开始画素材，快速画好大量的草图，将界面中的场景、文字、图片布局等等配合程序的原型，结合游戏玩法在心里有了一个全面清晰的概念和感觉之后，再去细致的绘制每一张图每一个素材， 在开发游戏项目中这样做的好处非常多，为了游戏好玩往往在中途无法避免设计频繁修改，当游戏跑起来确定好了整体感觉，心里更清楚的知道了该在哪里可以添砖加瓦，最后再精雕细磨，加细节、加特效、 丰富画面。四、最后寄语
团队合作的模式有很多种，需要花时间找到最适合自己成员的合作方式。要么做好团队建设，相互之间建立起信任、默契、尊重、鼓励，众人划桨开大船，有分歧没结论就直接做出来看，别你看不上我的点子我看不上你的设计，我嫌你理解能力差你嫌我工作效率低，负面情绪爆表相互充满怨气，这么下去项目不是草草了事就是要坑。还有一种就是团队中有“大神”，能力资历都足以让其他人信服，他交代什么其他人就做什么，这样高效的方式也能出不错的东西。
《种子净化之旅》之前设置0.99美元，朋友说太贵了居然要六块钱，坚决不买！（不是亲生的朋友……）名称和关键词设置也有问题，原本设想游戏就叫《种子》，结果apps tore搜不出来，后来研究了一下貌似名字如果是使用频率太高的单个单词就没法搜出来，现在游戏改名为《种子净化之旅》可以成功搜索到了！如果对我们后续的进展或者我们的游戏有兴趣请继续关注我们。15644 条评论分享收藏感谢收起/cn/app/spherevscube/id 有兴趣可以看看吧。不过你们要是发现bug或者觉得不好玩或是教程看不明白的，我也懒得改了。。。------------------------------------------------------------------------------------------------------------------------这也是我纠结的问题。。。。下面我想介绍一下我一个失败的巨费时间的独立项目经验，希望给大家点启示，内容比较长废话比较多，具体针对题主的问题回答在最后。--------------------------------------------------------割-----------------------------------------------------------之前工作时还算宽松，有时候八九点就到家了，周末也有时间。但是拖延症实在是要命，加上还要纠结公司的项目，所以大部分时间都在动脑，没有动手。。。当时最多就是每天上下班的车上、午休的时候、周末在家的时候，去搜集优秀的游戏、构思游戏玩法，什么想法都记录下来，想着以后有时间做。结果是记了一大堆乱七八糟现在自己都看不懂的东西。后来辞职了，终于有时间了，胸中壮志豪情，脑中浮想联翩，反正有时间了，也不急着找工作，这个也想做那个也想做。后来想想，还是先从简单的开始吧，就决定做一个跑酷类的小游戏，主角有多个形象，有几个小道具都是计费点，就类似过马路或者地铁跑酷那种模式吧。从那时起，我才知道，我太年轻了。。。因为所有内容都是我一个人负责的，策划、美术、程序、音乐都是我自己弄的，本来程序我水平就不咋地，其他方面更是菜比。所以首先从设计玩法的时候，我就要考虑这种玩法对于美术实现容易不容易，结果这就纠结好久，大概用了一周时间定下来了，本来要计划写的策划文档也支离破碎的。然后就是美术资源，开始我设计的主角是一个猫女（不要问我为啥，就是Sexy，我喜欢- - ），结果在我跟3DMAX、blender纠结了一周时间，PS画了两天贴图，闭上眼全是网格和大色块的时候，做出一个巨丑无比的猫女，好吧，放弃了。只好把主角换成一个由球和方块构成的机器人，又用了三天做出来了，还花了两天画贴图，结果还算满意，可后来还是扔了，因为没有办法以此为基础做多个人物（主要不是没办法，是没时间）。后来主角就变成了一个球，然后多个形象就靠换贴图。。。。我都佩服我自己的机智- -。 这时候美术又已经用掉了二十多天时间，这就一个月了。好吧，资源准备好了，开始写程序吧，这总会好点了吧。具体过程不表。反正是每天起早贪黑，除了吃饭睡觉就在电脑面前，大概用了七八天吧，玩法流程是出来了。当然，这只是第一步。。。。因为我发现，我TM除了地形、主角和敌人，就没别的了，空的都有禅宗的味道了。好吧，又跑去做了点装饰用的植物、房子、汽车啥玩意的，还画了背景天空、云彩啥的，又把这些加到游戏里实现一些简单运动，又用了一周。这个时候，游戏内的部分算是差不多了。但这只是二里长征第一步啊。。。虽然玩法实现了，骨架有了，但我知道差的还很多，UI、主界面、分数、商店系统、特效、IAP、新手引导等等，好吧，让我哭会。。。。后来，我决定先把流程弄出来，至少有个游戏的样子，然后就把从进游戏、到开始玩、死亡统计、会主界面这一个完整循环弄出来了，当然还是没有UI的。这又用了好几天。接下来做UI图，设计样式，画出来，放游戏里，实现逻辑和特效，又是一周多。然后再加上一些装饰画面的粒子效果。又是一两天。新手教程为了省时间，直接画了两张图。这会儿游戏完整度差不多了，但还有重要的东西没做，计费系统、广告系统、推广系统这些乱七八糟的SDK啊。。。。好吧，纠结的过程也不提了，那时候我已经疲了，只想着赶快上线得了，其他都无所谓了。所以排行的SDK直接砍了，GameCenter砍了，Share砍了，只留个本地最高分。。。广告为了快直接用Unity Ads，几行代码搞定。苹果的IAP是个蛋疼玩意，我TM自己搜了半天写了OC嵌U3D里，结果测的时候死活支付不成功，以为自己写的有问题，又找了半天插件，弄上去还不行，后来我才反应过来，我的iPad是越狱的，测IAP是不行的。。。。好吧，重刷系统，重新测，OK了。这时候，差不多功能都实现了，就开始测试改BUG了，然后我才发现一个问题，游戏还TM还没声音呢！啊啊啊。。。好吧，又找了各种奇葩音效，背景音乐为了不涉及版权，我自己愣是拿软件做了一段你敢信么。。。最后，就是提交store了，这个纠结的过程大家都懂的，我也不提了，ASO啥的我也懒得弄了。在一番千辛万苦后，终于提交了，然后就是“漫长”的等待审核，这是唯一比较爽的地方，只用了一周居然就通过了。看着自己辛苦了快仨月的破玩意上线，眼泪哗哗的，然后就是每天查下载量，看评价。结果呢如何呢？第一天十几个下载的，第二天几个，第三天0，第四天0 ，然后就是一路0，总收入0。。。。 嗯，可以的 - - 。后来我还发现自己的pad下载下来玩，游戏里的付费还是不成功，不过反正也没人玩，也懒得改了。。。因为这段经历，我之前的计划都放弃了，决定缓一阵以后再说，这个游戏也没跟周围的人推广过，因为我觉得始终是个半成品，自己又不想再去碰了。。。--------------------------------------------------------割-----------------------------------------------------------现在说一些个人从这个项目总结的经验：1、首先要明白，独立游戏不简单，细节太多，没有项目管理、制作经验的人，是很难把控的。2、一定要统筹好大局，分清主次，定好计划，认清能力，想好后路。不要眼高手低。什么都想实现，做的过程中又发现实现不了再去换方案换设计。3、先大后小。先粗再细。开始的时候不要在细节抠太久。比如开始上来我就从不擅长的美术资源开始，模型做完居然还画贴图，然后才发现不能用，时间都浪费了。其实以前在公司我们也是先随便找个资源代替，以实现玩法为先，只是我们美术效率比较高，一般我程序还没写好，美术资源都给我了，让我产生了模型不是很费时间的错觉。。。4、如果有条件，还是分工合作比较好，一个人太痛苦，很容易疲劳。把对的事交给对的人才是好的。。。当然，因为我比较偏执，就是想一个人全部包了才有成就感，而且不喜欢妥协别人或让别人妥协我，所以都是自己来，只是我忘了自己几斤几两。。。不过有些东西还是能省时间的，比如美术找外包，音乐可以找一些国外的免费资源库，花点小钱买点插件啥的。5、不要做同一件事太久。我都是每个模块分开来的。先做美术资源，再写程序，再做UI，其实我现在觉得应该在目标明确的前提下，平铺开一起做。因为我在做一件事的时候容易钻进去，就变成钻牛角尖，其实有些地方是可有可无的，可是我却总在那一个点上耗太久，却对结果没什么大的影响。6、千万不要造轮子，尤其是对于程序员，你是做游戏，不是做引擎， 啥都优先去找现成的吧。。。7、其实大部分问题都还是经验不足造成的，我做之前哪知道有这么复杂啊，想着就弄点模型，玩法那么简单，还是单机，用的了多久。做起来才发现忽视了多少细节，也造成了UI、新手指导、系统的完整性等许多方面的问题。这也体现出了好游戏与烂游戏的差别，至少人家完整度高啊。。。8、关于业余时间开发这个问题，因为我以后还是希望有机会做独立游戏的，所以也想过以后继续工作了怎么办。目前觉得，每天下班都那么晚了，在单位写了一天程序脑子都浆糊了。我觉得这时候就别做太核心的内容了，可以多看看网上的资源找灵感，或者听着歌画画图做做模型啥的。上下班的路上可以去构思游戏玩法，思考项目结构。周末是用来重点开发的时间。然后开发过程中一定要多回顾，多思考，多听取他人的意见，换换思路脑筋。但也要坚持一个基本原则，不要人家说啥就改啥。。。9、身体是革命的本钱，千万别熬夜。尤其你还要工作。我知道做项目到半夜都很亢奋，但是也要强制自己休息好，那样才有清晰的思维。还有，没有把握不要辞职，我之所以这么赶，就是因为没工资啊，这可耗不起啊。。。。你有工作的保障下，至少还可以精雕细琢，如果像我一样心态不稳，就绝对做不出好东西。10、其实我也帮不了题主啥，你一个项目做一年实在是太累了。。。换我早放弃了。我目前是不敢做那么大的项目。在这个基础上缝缝补补，我觉得也是困难重重，所以要么放一放，换个项目或者干脆歇段时间。要么直接重写，这样让你能在有整个大局观的情况下再去做这个项目，应该会快很多。。。。（只是不负责任的建议- - ）居然突然胡扯这么多废话，主要也是有感而发，希望能帮到大家吧。。。。22243 条评论分享收藏感谢收起查看更多回答1 个回答被折叠（）}