无限星辰官方论坛

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 5611|回复: 28

[公告] 开发技术工作进展报告(隔日更新)

 关闭 [复制链接]
发表于 2016-2-15 20:52:18 | 显示全部楼层 |阅读模式
本帖最后由 FreemanGL 于 2016-5-11 19:31 编辑

原帖地址:https://forums.inovaestudios.com ... ts-engineering/1926

欢迎各位关注Flavien的快速进展报告   2016年2月2日,星期二

在这里我将持续关注并发布无限星辰-战争遗迹的进展。众筹成功以后,所有朋友都想更好的与开发团队沟通并全面了解开发进度,大家的心思我们都十分了解。然而由于时间问题,我们又没法过于详细的描述更新进展(撰写进展报告这事动辄需要好几个小时)。

因此,我们就采取了发布“快速”进展报告的方式。之所以称为“快速”,是因为发布频率会特别高(开始阶段我会争取每天都发布一次,不过在这之后,发布频率就将变成3、4天一次),并且每次撰写更新内容的时间我都会控制在10分钟以内。

免责声明:由于本博客的性质,这里不会有太多深度内容。你们不要理所当然的认为这里写的内容都是我们所完全承诺好或一成不变的(尤其是预计时间的估算,尽管在此我会尽量避免涉及这些内容)。这里我们所更新的并不是官方声明,关心官方声明的朋友请去看我们的官方更新。本博客中我所写到的都是我个人的看法或者经验,并不代表整个开发团队或者团队中其他人的看法。

格式:我一直在考虑本博客最佳的组织形式,最后确定了一部分内容:
  • 我们过去一直在博客里更新重要内容,但由于最近我们更新博客的频率有所下降大家对博客的关注度也降低了,所以我挺担心大家看不到我在博客的更新。另外,这些论坛能够直接跳转到我们的网站,毕竟网站是新成员关注我们的第一站。
  • 本贴禁止评论。之所以如此并不是我本人讨厌评论,而是由于我不想让这些更新内容被一大堆水贴淹没,我觉得这里还是保持整洁最好。如果你想发表评论,请在其他帖子里面自由发挥(如果有什么重要的内容需要讨论,请开个新帖。)
  • 我一般会在(欧洲中部时间)下午的早些时候发帖。所以内容一般是当天发帖之前我所做的工作。
  • 把页面拉到最底下,你就能看到最新的进展报告。

谢谢大家
Flavien Brebion
 楼主| 发表于 2016-2-15 23:28:52 | 显示全部楼层

2016年2月3日,星期三

本帖最后由 FreemanGL 于 2016-2-15 23:33 编辑

今天我看了一份对2015年众筹成功的43款游戏项目的分析,如预料一般,《无限星辰:战争遗迹》成功进入了前20名。这些项目仅在Kickstarter上就一共募集了超过4000万美元,不错的成绩。我很好奇其它诸如IndieGoGo等平台上会是什么样的数字,也许会低一点儿。

在未来的某个时候,我想写一个关于我们在Kickstarter上的众筹的分析。哪些方面进行地很顺利,哪些方面符合预期,哪些又不太好。这也许会花上不少时间,所以我不打算在这次进度报告里进行。

昨天我基本完成了认证方面的工作,所有的功能都可以用了:你可以打开启动器、登录游戏(说到这个,我们还得添加对第三方登录比如Google或者Facebook的支持)、启动客户端,客户端会自动登录到游戏服务器,服务器会读取数据库中的信息并校验你的身份与访问权限,然后返回“Yes”或者“No”。

我说“基本上完成了”,意思是这里仍然还有一堆事需要做,然后才可以称得上是“完成了”。我本地硬盘上没有生产环境的数据库,所以只在测试数据库中进行了单用户测试。我还要进行一些性能测试来确保即使在短时间内接收到大量请求,认证服务器依然可以正常工作。这非常重要,特别是当服务器崩溃后,玩家很可能会同时大量地进行重连。

在处理URL中的错误字符编码上我花了大量的时间。如果忘记了对一些参数进行URL转码,那么就会出现诸如"+"号被空格所替换的情况。听起来很显而易见,如果你是个经验丰富的前端开发者的话,然而我并不是(仍然在学习中),所以总是犯一些基础错误。

在多年前LAMP横行的时候我曾经也做过一些网页开发,还记得我们的老网站吗?对,就是那个被黑了的。老网站完全基于PHP+MySQL,然而现在我们使用的是微软的技术(更具体地说,是ASP.NET MVC),这是一个很不一样的东西。在Kickstarter众筹之前,我对其还是完全的零经验,所以在12月我不得不加班加点地掌握它。不得不说,和我预料的不一样,这段学习经历很有趣,也让我的C#水平得到了提升。

说到C#,我觉得我已经爱上了Async/Await机制。如果你不是程序猿,那么就直接跳过这一段好了。C#里的异步编程非常容易,一旦你掌握了正确的姿势(当然还得有一些小技巧,毕竟没有什么是完美的),那么写起来简直就是种享受,我甚至要说,在程序的执行流里你能看到一种美感。C++引入了一种类似的模式,future和promise,但是我们在引擎中还不能大量使用它们,因为这样的话就得做很多重构。Keith应该会在接下来的数个月里进行相关的工作。

论坛现在貌似经常挂掉,服务器每天都会停止工作,返回HTTP 500 Internal server error的错误。主要问题是数据库在注册新的网站账号前需要访问论坛,这意味着当论坛挂掉的时候就没法注册新账号了,即便是在主站上进行注册。这些问题在数周前我们更新了Discourse版本后开始出现,虽然可能并不相关,但我们仍在进行检查。为带来的不便说声抱歉,目前如果你遇到了这个情况,那么请在论坛恢复后再次尝试。

今天我会继续进行访问权限与启动器可用服务器列表显示的工作,然后玩家就可以选择连接哪一个服务器。对于原型启动器的话,我们可能只会有一个服务器,但至少未来需要的时候我们的相关系统已经准备好了。在登录会话管理上我也还有一些工作需要做,比如记录谁登录了、在哪台服务器上登录了,以及登录了多长时间。
 楼主| 发表于 2016-2-15 23:30:43 | 显示全部楼层

2016年2月5日,星期五

过去的两天不是工作产出最多的日子,至少在代码量上是这样的。

大部分工作已经到了对数据库进行更新和细微改动的时候。我写的访问权限相关的代码将会检查是否一个事务/筹款存在于数据库中(当然不止这些,它还需要获取筹款等级、验证用户身份),但是我们意识到我们想要一个即使事务并不存在也可以授予游戏访问权限的功能,比如如果你是我们的一个开发者的话。。。是的,我们忽视了我们自己访问游戏的权限。这需要对SQL请求进行一些改写。

我还开始进行了一些性能测试来检查当数据库变得复杂起来后的请求状况。为了达到这个目的,我写了一个脚本来产生大量的随机用户与筹款数据。一切都运转良好,直到用户与请求数达到了大约1w2的时候,这时SQL Manager Studio开始因为“内存不足”而拒绝请求。然而内存并没有不足,我在任务管理器里查看了,离用光我电脑的内存还差得远,所以我觉得是软件上有限制阻止了我发起更多的请求。我得找出绕过这个限制的办法,请叫我Google小能手。

我在现实生活中因为公寓漏水而遇到了一堆问题。看着厨房的橱柜(里边并没有保存液体)向下滴水非常忧桑,我怀疑是橱柜后边的墙或者天花板上有道小裂缝,不过不管是什么问题,房东、楼管和水管工都在不断的打电话各种预约骚扰我。我只希望他们赶紧停止,让我一个人好好清静清静。该死,我还有一个游戏要做呢!:p
 楼主| 发表于 2016-2-15 21:00:16 | 显示全部楼层

2016年1月总结

本帖最后由 FreemanGL 于 2016-2-15 21:02 编辑

在过去的一个月里,我们的工作重点是将游戏原型提供给能够参与开发访问的支持者们。

为了完成这个目标,我们一直做公司的基础设施的建设,尤其是网页服务器与数据库系统。这个事急不得,否则就容易玩大发了。@INovaeKeith在这一点儿上比我更有说服力:
“尽管很遗憾,但是不得不说,所有下一步的工作都直接依赖于账号管理、授权、分发和补丁管理。而所有这些代码在本月之前还不存在。这些代码实在是太重要了,必须要谨慎对待。如果我们搞错了什么,那么接下来就是铺天盖地的服务支持请求,抱怨遇到了支付问题、购买了游戏却没法玩之类的问题。或者更糟糕,我们可能会遇到了一个大漏洞导致用户数据泄露以至账号有被盗的风险。现在测试越充足,就越能确保我们的代码是坚固且有效的。”

这基本是我们在1月所做的工作:
  • 服务器认证(玩家以后可以创建自己的服务器,所以服务器认证必须安全)
  • 客户端认证
  • 访问权限验证(谁能访问原型/游戏)
  • 请求token的安全与加密
  • 自动bug与崩溃报告
  • 会话日志(客户端与服务器端)
  • Kickstarter数据库导入
  • Indiegogo数据库轮询与导入(大家可以一直赞助)
  • 奖励申领/匹配数据库(很多人使用了不同的邮箱)
  • 版本控制与补丁管理(全增量式,毕竟没人会愿意每一个小更新都下载一个4G大小的补丁)
  • 数据、错误日志与备份
  • 启动器中可用服务器列表
  • 连接限制/登录队列
  • 启动器,账号管理
  • 性能与可扩展性
  • 也许还有很多我忘掉的东西


粗体高亮的特性是最重要的部分,我简单地说明一下:
  • 客户端认证至关重要,因为我们需要验证客户端的身份确实拥有接入开发访问游戏原型的权限,且这一权限没有因为任何原因而被封掉。
  • 安全/加密同样至关重要,大家都知道黑客一般都喜欢赶早,我们也不愿意在安全性上出现问题。以前踩过一次坑了,以后不会了再踩了。此外,很多早期代码很可能存在一些严重的缺陷,所以我们需要追踪所有的不正确请求,来验证是不是有人在尝试对我们的代码进行逆向工程。
  • KS/IGG数据库导入:这两个数据库使用了不同的文件格式与赞助等级,所以我们必须想方法把两者整合到我们自己的数据库里。IGG现在让我们很头疼,因为它是持续性,也就是说玩家们可以随时赞助,哪怕游戏原型已经放出了。当然,在IndieGoGo上参与众筹的玩家同样会期待能够尽快下载并体验到游戏内容,所以我们得设立一个机制,实时地将相关数据整合到我们的数据库中。
  • 我还该提一下,因为很多人在赞助时使用了不同于注册我们账号时所使用的邮箱,所以我们得找到一个办法来解决这个事。Keith在过去数天内解决了这个问题,添加了将多个邮箱地址关联到同一个账号的功能。
  • 版本控制与补丁管理也很重要,我们要保证每个人在进入游戏前都有相同的、最新的版本。我们预计服务端和客户端都会有频繁地更新,所以版本号可能会一直在变。另外我们想要进行增量式的自动补丁,这样可以避免每天都让玩家下载一个4G大小的补丁包,否则就太憋屈了。在我看来,这就是星际公民最让人沮丧的一点,我觉得很多人根本就没有能如同他们所期望的那样经常玩到它。一个30GB的补丁包可不是小事,尤其是对于那些小水管的人来说。幸运的是我们并不准备让30GB补丁包这样的情况出现在战争遗迹的任何时间点了,但即使是数GB的情况,如果没法增量更新,那也会很快让人厌恶起来。

到目前为止,在整个列表上的许多系统要么已经完成了,要么被更好地改进了。现在仍旧需要花费大努力的就是补丁了。补丁已经能够被启动器自动下载与解压,但是补丁这个过程本身(复制文件、注册等。。。)仍旧需要一些工作。最主要的挑战之一是一些第三方的依赖,比如说CRT与其它一些库,它们自己也有着各种各样的依赖。

当所有的系统都被完成后,我们还要进行一轮测试。这应该会很快,但是目前我还没法断定这事会花多长时间,也许一两天,也可能一周。我们使用Azrure来部署网站环境与虚拟机,而所有的不同的机器都得联合起来一起合作。Azure最好的一点就是扩展就和按一个按钮一样轻松。如果玩家们潮水一般的涌来,我们只需要添加新的游戏服务器,增加服务器的性能或者加大数据库的空间。所以我们目前在基础设施上所花费的功夫都是为了服务器未来的健壮性,我们可以不用在最终发布前才赶着把这些事给做完。不过,不包括网站。目前的网站已经有点儿太老了,不够灵活,在上边发布新闻也不是一件容易的事,因为没有内容控制系统,所以每一次我们想要发布一条信息到首页的时候,都必须要把整个网站都上传到Azrue上。这太不科学了。
 楼主| 发表于 2016-2-15 21:11:47 | 显示全部楼层

2016年2月1日,星期一

在昨日2月1日,我们两位艺术家(Kristian 和 Jan) 开始为Battlescape全职工作了。 这也是把全部基础设施的管理交给Slack和Jixee的绝佳时机。之前我们用Hipchat来实现实时交流和会议,但是最近经常出现无响应(我的Hipchat无故的卡住,有时持续一两分钟),Keith就经常在说手机上的这个应用不怎么好用。在上个周末,我们购买了Slack, 不得不说这软件真不错。我们目前很开心,因为这个软件的界面很清爽,看起来反应也快,目前我们感到很高兴。

Jixee就是我们目前的任务管理系统。 我们对这款软件不是很熟悉,但是我们听说这个软件是由一个对开发者友好的一个公司开发的,所以它会比其他的软件更加针对开发一些。目前来说我的体验还不错,东西看起来都很直截了当,我也很乐意每天来使用这款软件。之前我们用Mantis来作为问题追踪系统,显然没有Jixee 好用。 现在我唯一不喜欢Jixee的地方就是它缺少任务分类。 软件里面有Project项目这个概念,每个项目里面又含有一定数量的boards,就和分类栏差不多。就算是这样,可以下分小类里面赋予任务也还是不错的。我也挺喜欢在查看任务类型的时候弹出任务创造器的名字。

我在慢慢习惯Jixee的时候,看了一眼他们网络API的界面,想试着了解这些如何连接到我们的构建中。 我们希望游戏者可以在游戏启动器里面汇报游戏bug,然后这些信息会自动发送至我们的服务器中。然后这些报告就会被转至Jixee里形成一个自动的列表,等待查看和解决。我写了一个程序发到了Jixee网络API上,但是没起什么作用。

我决定使用Fiddler(一个可以让你自行组合人工发送HTTP信息的软件)生成一个HTTP请求,附件了一个含有任务信息的JSON object Jixee的服务器回应了HTTP 200正常的回复,没有任何的报错,但是我没看到项目里面出现这个任务,可能API是实时的,所以我肯定是哪里做错了。

我试了两个小时之后(试过了不同的项目名,任务,请求等等)我都快要放弃了,想找他们的帮助的时候收到了一个启示。 当我在Fiddler里面编辑我的HTTP信息的时候,我作出了一个大胆的假设,JSON文件是正常的(我还很确定句法是正确的),结果被Jixee的服务器自动反序列成一个JSON文件。 事实上并没有。 我漏掉了一个简单的目录标题来指出接下来的数据是JSON格式。 在我整好了之后所有的东西都正常工作了,游戏启动器自动发送bug报告也正常工作了。

这些让我想起了我的台式机,我主要工作用的电脑仍在运行Win7系统。本来我计划升级到Win10的但是我还没决定什么时候升级。可能会在微软夏日免费升级结束前升级系统。唯一让我感到不安的是Keith已经开始用Win10系统了,意味着我也需要紧跟步伐,在Win7平台测试和开发就不再那么频繁了。不过我觉得没啥大问题,因为我们还没发现Win7和Win10有什么兼容方面的问题。

明天我会继续游戏部分的验证工作,希望能尽快正常使用了。
 楼主| 发表于 2016-2-23 21:27:36 | 显示全部楼层

2016年2月5日,星期五

过去的两天不是工作产出最多的日子,至少在代码量上是这样的。

大部分工作已经到了对数据库进行更新和细微改动的时候。我写的访问权限相关的代码将会检查是否一个事务/筹款存在于数据库中(当然不止这些,它还需要获取筹款等级、验证用户身份),但是我们意识到我们想要一个即使事务并不存在也可以授予游戏访问权限的功能,比如如果你是我们的一个开发者的话。。。是的,我们忽视了我们自己访问游戏的权限。这需要对SQL请求进行一些改写。

我还开始进行了一些性能测试来检查当数据库变得复杂起来后的请求状况。为了达到这个目的,我写了一个脚本来产生大量的随机用户与筹款数据。一切都运转良好,直到用户与请求数达到了大约1w2的时候,这时SQL Manager Studio开始因为“内存不足”而拒绝请求。然而内存并没有不足,我在任务管理器里查看了,离用光我电脑的内存还差得远,所以我觉得是软件上有限制阻止了我发起更多的请求。我得找出绕过这个限制的办法,请叫我Google小能手。

我在现实生活中因为公寓漏水而遇到了一堆问题。看着厨房的橱柜(里边并没有保存液体)向下滴水非常忧桑,我怀疑是橱柜后边的墙或者天花板上有道小裂缝,不过不管是什么问题,房东、楼管和水管工都在不断的打电话各种预约骚扰我。我只希望他们赶紧停止,让我一个人好好清静清静。该死,我还有一个游戏要做呢!
 楼主| 发表于 2016-2-28 22:54:35 | 显示全部楼层

2016年2月6日,星期六

管道工昨天过来并且发现了漏水的源头:我楼上邻居的洗衣机。我很高兴事情这么快就有了答案,并且我们也不用把墙凿开来检查管道是否破损。下一步要做的就是把我的公寓的墙面翻新并重新粉刷,而且由于我在自己公寓的起居室(面积并不是很大)里工作,下一步的工作可能会遇到一些问题。但是无论如何我们都会解决这一切。

目前为止,我还还没弄明白为什么SQL服务器管理工具拒绝执行用于压力测试的查询。我还在研究这个会引起“内存不足”的12K限制,每次发生“内存不足”的错误时,明明还剩下很多内存。我猜可能程序会尝试异步来执行查询,所以每个查询会建立起一个独立的线程并且消耗掉大量的内存。为了测试我的猜想,我写了一个C#脚本,这个脚本会连接到数据库并从一个文件提交查询。经过测试,这个脚本完全可以正常工作。看来SQL服务器管理工具还是有些问题。

我采用不同数量的用户和权限对Web API代码(处理连接请求、登录、访问权限等功能)进行了测试。因为我们之前只用一个用户对代码做过测试,所以我对测试的结果感到非常紧张。一开始,我向数据库中添加了5000个用户,之后是50000个,再之后是500000个。随着用户数量的上升,查询的执行速度也越来越慢,但执行的时间并不是按照量级来增长的,而是按照一定的百分比进行增长。从这点来看,用户数量的增长引起的性能损失并不是想象的那么严重。测试的结果显示,拥有500000用户的数据库只比一个拥有1个用户的数据库慢50%。考虑到SQL Server在全球的大公司和大型数据库中的应用非常广泛,我感觉我一开始的担心有点多余了,但是良好的实际测试结果更能让人放心。上面的测试是在一台测试电脑上完成的(我的个人桌面电脑),在实际的应用当中,我们会把数据库部署在Azure云上,这样我们就不用担心数据库规模的问题了。

在我弄脚本的同时,我写了一个把bug/task数据库从Mantis迁移到Jixee的小工具。整个迁移过程只用了一个多小时,目前新的数据库中有160条之前没有处理完的bugs/tasks,占之前数据库中总条目的50%。不过目前还不能让新的数据格式和旧的数据格式完全匹配,所以我们还得抽时间检查并调整这些数据,但是这些并不是目前要紧的工作。

我已经开始查看SSPI库和TSL/SSL协议,这些协议可以让我们加密客户端和服务器之间的通信。我们不希望会发生中间人攻击,此类攻击一般会模拟出一个用户来与服务端通信,之后可能会向我们的系统提交虚假的登录信息、用户状态以及游戏信息。在我研究加密的时候,我开始对RSA算法感兴趣,这种算法用来产生加密所需要的公钥和私钥。RSA算法有些很让人着迷的思路和方法在里面。如果你想知道服务器和客户端之间是如何建立起完全安全可靠加密的会话,甚至在建立会话的过程当中也不怕第三方进行监听,我可以告诉你答案:这就是数学的魅力。:)
 楼主| 发表于 2016-2-28 22:57:43 | 显示全部楼层

2016年2月7日,星期日

昨天没发生什么大事,一切平淡无奇。我们对代码做了一些小的修正,这可以让程序更好的运行。举个例子,我们把部分设置移到了注册表中,而不是直接写在代码里。现在也可以强制使用非安全连接(当然,在正时发的程序当中这个功能是默认被禁用的,但是在测试过程当中,这个功能很好用)。我给服务端添加了一个接口来与不同类型的用户验证器交互,还做了一个“私有”的验证器,这个东西是为将来那些打算假设自己的私人服务器的用户准备的。这个“私有”验证器与“公共”验证器的区别是“公共”验证器会在我们的网站上注册其自身并检查架设服务器的权限,而“私有”验证器不会。
  • 下面是目前预计要在下一周之前完成的工作:
  • 使用SSPI和TSL加密服务器和客户端之间的验证通信。
  • 在启动器(launcher)中显示在线的服务器
  • 处理同时在线的玩家数量限制
  • 启动器(launcher)的部分视觉设计和测试

SSPI是目前最不确定的一部分,我不太确定是否能在一天之内让它好用,可能需要好几天才能搞定这个东西。其余的东西和SSPI相比简单的多,所以一切应该会顺利完成。

之后我可能会继续完成客户端和服务器方面的工作,Keith会完成安装包方面的工作。
 楼主| 发表于 2016-2-28 22:58:08 | 显示全部楼层

2016年2月9日,星期二

SSPI/Schannel接口现在可以正常工作,并且我们已经将它集成到了游戏引擎当中。让这个东西工作的过程简直如噩梦一般。网上能找到的所有的例子都非常的复杂,而且都与socket代码混在了一起,但是我并不需要socket相关的代码。所以我必须得自己弄明白如何在服务器端处理证书。整个过程是一个很好的学习过程,我了解到了不少和证书相关的内容,还有和CA以及证书签发过程当中的一些事情。但是这个过程也消耗了很多的时间,而我们现在很缺时间。目前仍让我感觉比较困惑的东西是证书链,不过我不打算花更多时间在这个问题上了,如果将来需要的话我可能会重新捡起来研究。

下一步是采用我们自己的socket接口代码来加密客户端和服务器之间的通信。SSPI目前更多是实验性的(从代码量上讲,SSPI不算庞大,我可能会在引擎中加入1500行相关的代码)。我感觉一切不会很难实现,但是谁也说不好实际情况会是什么样……希望明早之前加密部分可以完成,这样我就可以继续完成剩下的工作了。
 楼主| 发表于 2016-2-28 22:58:37 | 显示全部楼层

2016年2月10日,星期三

SSPI/TLS加密目前已经可以在我们的socket代码上运行,剩下的就是做一些代码的清理工作和一些测试工作。

也可能不是。每次我完成引擎的一部分的时候,我都会做一些压力测试来确保不会发生内存泄露,这样才能保证我们不会遇到莫名其妙的性能问题。好消息是目前还没发现内存泄露。坏消息是目前的性能表现没有达到预期。

具体来说,每次TLS握手大概要消耗掉10ms。到目前为止,10ms看起来可能不算慢,但是你要知道实际当中,在很短的时间内会有很多的用户尝试建立连接。比如服务器重启的时候,会有很多用户尝试重新连接服务器。根本的原因似乎来自Schannel API的调用,这些调用并非异步的,会让线程停止响应,但是我猜测背后实际上可能是只做了一个延时。在这些调用发生时,CPU使用率看起来并没有上升,所以很明显程序并没有进行任何消耗大量CPU时间的工作。我想知道这些调用要花掉多少时间来处理一个完整的证书链。这些API后面的代码会向证书验证服务器发送一些web请求吗?我需要明确知道这后面发生了什么。不过我在Google上简单搜了一下,并没有找到什么有价值的信息。

无论是那种情况,在目前的原型阶段这还不是个问题,因为我们最多也就有几百个用户,而且连接请求都是分散开的。我要先把这些工作放一放,然后将精力集中在剩下的工作上。在周末之前我会对任务列表(就是我在2016年1月总结里发的那个)做一个回顾,之后我就应该把更多的精力和时间放在和游戏相关的更新上了。
 楼主| 发表于 2016-2-28 23:07:11 | 显示全部楼层

2016年2月12日,星期五

我在服务器基础设施系统方面有了一些很好的进展。今天和明天我打算做一些改进和完成许多系统中的定稿,以及更多的测试。大多数系统功能已经完成了。让我们看看我在一周半前发布的名单…我会用图标显示状态:一个绿色的对号表示任务完成或基本完成;锤子时,它仍在进行中而出现了一些显着的进步;一个红色的标记任务还未启动或仍远未完成:
  • 服务器身份验证(玩家将能够在未来主持自己的专用服务器,它必须是安全的)
  • 客户端身份验证
  • 访问权限验证(谁访问了游戏)
  • 请求和令牌的安全/加密
  • 自动错误和崩溃报告
  • 游戏记录(包括客户端和服务器)
  • Kickstarter的数据库导入
  • Indiegogo数据库轮询和进口(因为人们可以保持承诺)
  • 奖励系统/匹配数据库(很多人使用了不同的电子邮件,以保证)
  • 版本更新和修补(完整或增量,没有人想下载一个4 GB的补丁,所以更新会是很小的)
  • 统计,错误日志和备份
  • 登录器中显示可用的服务器列表
  • 连接限制/日志队列
  • 登录器,帐户管理
  • 调整游戏性能

接下来让我们看看正在工作中的任务:
  • 自动错误或崩溃报告:登录器有一个功能可以报告一个问题或一个错误,它是自动提交给我们的服务器。这一作品,但我们需要保证它的安全性,以确保人们不滥用这个功能。自动崩溃报告尚未完成。
  • IGG数据库检查和输入:Keith做了一些工作,但是据我所知当一个用户报告问题时我们还不能及时的接受信息,如果这样他不能尽快解决问题玩上游戏。
  • 奖励系统:Keith在里面进行了一些工作,但我不能确定它的确切状态,所以我将其标记为正在进行中,但它可能已经完成。
  • 版本更新和修补:这是原型最需要的工作,是目前较落后的。我们至少还需要一周的时间去工作。统计,错误日志等。我们已经记录了各种重要事件(谁登录,并从什么时候和从什IP地址)到存储数据库,我们可以做更多,但现在这个东西相对来说并不重要。
  • 日志队列:不是首要任务,我会在以后完成。
  • 启动器,账户管理:登陆器是现在是美工已死系列,它功能强大的但看起来并不美观。我们不知道有多少时间可以让我们去改善它的外观。我想开发支持者不会真的在乎。账户管理是最基础的:它只是列举出你迄今所做的一切,以及一些帐户的详细资料(你的名字,你的赞助水平等。)现在他是只读的。
  • 性能:将永远在制作中 :p

昨天我一直在调试登录器上显示的可用服务器列表。我花了更多的时间在愚蠢的WPF问题(DataGrid控件不允许双击,发现网上解决技巧不是与地铁主题我们目前使用的,怒了)而不是网络编码。不管怎么说,服务器列表现在是可用的。它为每个服务器显示其名称、描述、播放器计数+容量和所有者名称。有一点是缺乏的,但我们不能直接在服务器的时刻(由于使用我们自己的自定义网络协议),所以有没有容易的解决方案,以显示服务器的延迟。我们可能会在以后完成它。

服务器具有最大的容量限制,如果达到该服务器的最大容量的话,登录器将拒绝连接到该服务器。这已经完成了,但是我想在一些点添加一个队列,你只需等待一些时间后你将连接到服务器。我设置的默认能力为50人,但是这只是作为一个开始。一旦我们验证了服务器不落后/崩溃,如果需要我们会慢慢增加这个限制。考虑到我们有300-400开发支持者,只有一小部分将同时在一个给定的时间,所以50人是可以承受的,我们甚至不需要增加它。我想我们会明白的。
 楼主| 发表于 2016-2-28 23:09:17 | 显示全部楼层

2016年2月14日,星期日

在我们的基础的引擎之上,我正在制作第一个版本,并且我着手去实现一些被忽略但是很重要的“细节”。

例如,登陆和认证。当服务器关闭时,所有用户的连接也将断开。我们会以对话框的形式提醒用户,而不是直接停止响应。

用户日志中加入了更多的信息,这些信息在将来对于我们非常有用。我们收集了硬件信息,例如中央处理器的类型,内存使用量,操作系统以及显卡的类型。我也打算加入游戏运行时帧率的统计,比如在游戏中最小/平均/最大的帧率分别是多少。这有利于我们去监测一些错误发生的原因,比如资源的浪费(在当前封测版本中,一些资源因为分配不合理会导致游戏过程中帧率的下降)和验证用户的电脑运行是否正常。当然,如果用户不希望我们跟踪这些数据,我还会为用户添加一个“不跟踪”选项供您使用。

我在登录器中加入了一个通过私人服务器登陆的选项。我们还无法启动这些私人服务器(我们不希望用户的数据很快传播)但是这些功能都已经准备好了。对于开发者来说,当我们想链接到私人服务器而不是公众服务器时,它会发挥它的作用的。
 楼主| 发表于 2016-2-28 23:11:03 | 显示全部楼层

2016年2月16日,星期二

本帖最后由 FreemanGL 于 2016-2-28 23:13 编辑

网络基础建设已经圆满完成了。有许多很重要的细节。比如记录用户运行游戏时更多的数据(分辨率、视频质量、断开连接的情况及原因、模型构建、实体场景的构建等等),报告最低配置(并且在登陆界面进行检查),这些是通过用户的账户首次登陆完成的,(在此之前默认是“未知”)。最重要的一点,是建立更好的错误报告和日志记录。

Keith已经完成了安装和补丁的相关工作,但正如他在上周更新时说的那样,我们并不确定是否能在二月月底及时完成。所以我们打算以ZIP压缩包的方式发行,这需要支持开发者自行安装。这种解决方式是有风险的。如果游戏比较稳定,那就没必要这样做了。然而如果有经常崩溃,诸如此类的重大问题,我们只能让用户在短短几小时的时间里再次下载重新安装。那么问题来了:对于用户来说,最令人沮丧的事情是什么?就是不能及时通过高频率的(一周或两周一次)安装补丁或重新安装从而解决一些问题(如果有重大错误,我们需要尽快的解决)直到我们完成了自动修补系统?问题仍然存在……

在本周的某个时候,或者下周早些时候,我们将首先部署安装和测试新的游戏本体。这意味着数据库模式的变化,KS/IGG数据导入(代码已经这样写了),能够用实际数据的游戏启动器测试,不只是测试/模拟数据。在后台的服务器中变化很大,但客户端将保持不变。理想的情况下,除了一段时间的停机时间,你甚至不会注意到任何变化。
 楼主| 发表于 2016-2-28 23:20:37 | 显示全部楼层

2016年2月17日,星期三

真是开心死了,Vulkan发布了!哦耶!虽然有所推迟,但是总算是发布了。

我没有在这上边花多少功夫,大概只用了一两个小时的时间去浏览API文档、示例,对这个新API有了个简单的了解。对于这个API我有一些想法(这些想法很可能是错的,毕竟只是我的第一映像)。

从概念上来看,它和DX12很类似,完全缺乏让人能感到惊喜的特点。说真的,我很想知道现在为什么需要有另一个不同的API,它们太相似了。唯一的不同就是Vulkan不是巨硬出品,除此之外就没有什么了。如果你直接拿来一堆DX12的API,把它们都给重命名一下,那么你就会得到一个看上去很相似的“新”API。。。这让人感觉似乎DX12和Vulkan是一对小伙伴。。。我并不是说他们是双胞胎,因为毕竟还是有一些不同的地方,但是呢。。。你懂的。。。

我现在所能发现的一些优点和缺点:
  • 这个API看上去从设计上就考虑到了未来的发展,大量的参数现在没有使用留待未来。这既有好处也有坏处,好处就是理论上这使得未来的发展变得更为容易,坏处就是这让Vulkan看上去比DX12还要复杂。
  • Vulkan的API极度的冗长。我这么说是因为Vulkan选择了向函数传递结构体作为参数,而且有时候会结构体嵌套结构体。也就是说,Vulkan中每一个调用都要写上好多好多行,比DX12多上许多。有时候这到了一个极度荒缪的程度,我还看到了仅仅一个函数调用就需要写上多达60多行的前置代码,仅仅是为了向该函数传递参数。比如说看看这个例子(https://github.com/KhronosGroup/ ... 3/demos/cube.c#L972),2800多行代码,仅仅是为了。。。创建一个立方体,什么鬼。。。
  • 第一眼看上去,通过事件或者光栅进行同步似乎更为容易一些,关于互斥锁的部分我不确定我是不是完全看懂了,资源创建/分配第一眼看上去也似乎比DX12要方便了不少。
  • Vulkan引入了一个叫做渲染通道(Render Pass)的概念,这在DX12中应该并不存在,除非是我记错了。不清楚这东西会起到多大的作用,但是感觉会很有趣。
  • 至于扩展,真是一坨shit。Vulkan发布的时候就已经有了一打扩展,但是你知道OpenGL因为它糟糕的扩展一直很头疼吧?如果有了数百种经常是供应商特定的扩展和许多种完成同一件事的方法,那这就是一团乱麻。不要重复犯相同的错误。必须要一个用于创建交换链(Swap Chain,在创建渲染层时最基础的东西之一)的扩展这个事实已经让我很恼怒了。我知道,之所以这么做是因为OS相关,但是不要告诉我没有办法把它做成核心的一部分,我才不会相信呢。

所以最后,我们会换到Vulkan或者DX12上吗?Vulkan是跨平台的,这是一个巨大的优势,而且它可以在Win7上使用是另一个很大的优势(DX12只支持Win10)。所以就算上边提到的瑕疵非常的现实,我还是认为好处比坏处更多,但这并不意味着我们会在短时间内增加引擎对于Vulkan的支持,首先我们现在没有足够的资源来做这件事,这是一个重大的技术挑战,整个渲染器都得重写,这将会花上数个人月的工作。这对于引擎的其它部分也会产生重大的影响,比如说场景图。所以呢,第一步就是等着Vulkan的API更为成熟,积累更多的经验(要先做一些实验),然后等我们信心充足、资源允许后,我们就会转到Vulkan,至少在明年以前这些工作都不会进行。
 楼主| 发表于 2016-2-28 23:25:43 | 显示全部楼层

2016年2月19日,星期五

数天之前,我们做了一些编辑器的改进与修复工作。有些事情非常烦人,比如打开模型查看器查看哪怕是一个简单的物体也会花上数分钟之久,在做了一些检查后我们发现这是线框材质所导致的。。。
  • 我们有不止一种(实际上是两种)线框材质,他们不是按需编译的(比如当你按下线框图按钮时),而是在当你第一次打开模型的时候。。。
  • 这些线框材质为所有的渲染模式都进行了编译(SM3、4、4.1、5),尽管一次只用到了一种。
  • 这些材质以最高的渲染优化级别进行编译,然而用户此时可能并不在意性能。

我修复了以上两点,让初始化时间从数分钟直降到了10秒。不过仅仅就打开一个立方体而言,10秒仍旧是一段很长的时间,我觉得我们必须得为一些特殊的材质实现一个缓存或者预编译机制。

在其它的方面,我已经开始着手研究贴花材质。在我深入细节之前,我必须讲清楚我们说的不是在贴花材质板里边的比如说损伤特效,而是说的贴花几何,比如在《星际公民》中所用来对模型添加所有细节的那种。网上有很多关于这项技术的信息,如果你对此有兴趣的话就去Google一下吧。

这是我们想要了很久的一个主要的艺术管线的变化。比起以前的“位图贴图、皮肤纹理,为每一个3D模型分离材质增强”的管线来说,它有着很多的优势:
  • 更高的质量:贴花几何会重用材质块,所以细节上会比使用唯一材质时更加的高。想象一下驾驶舱中的一个螺钉,使用唯一材质的话,你就不可能获得这个螺钉的细节的任何合适的分辨率,但是使用贴花几何的话,你只需要添加一个栅格方块,它将另一个拥有更高分辨率的细节映射到了这里。
  • 更低的显存占用:这其实是采用这项技术的最大的驱动力,现在的原型使用了接近3.5GB的显存,而且并没有渲染多少不同的舰船。我们真的很需要降低显存占用,而贴花技术帮上了大忙。
  • 更快:这项技术的一个副作用是你不再需要创建一个高面数模型,位图映射然后计算差值来生成一个法线贴图。这节省了大量的建模时间,但是细节仍旧需要法线贴图。

它也有不少的劣势:
  • 更多的面数:贴花几何是几何形状,尽管非常的简化,但是仍增加了模型总的面数。
  • 如何进行分离材质的细节渲染,比如铁锈、划痕等?当这些细节是独立的时,你就能用贴花来做,很简单。但是如果那些细节是外形/形状相关的(比如金属边的铁锈/侵蚀),这就成了个问题。我们认为这就是为什么《星际公民》里的船只看上去都很闪亮干净的原因。我们的设计师当前正在研究这个方向上技术的限制。
  • 细节层次与深度冲突。我不认为深度冲突会是个大问题(《星际公民》有一些这个问题,但我们使用了Z缓冲的诸多诀窍来应对行星引擎的天然特性,这让这些问题不再存在了)。然而细节层次方面,你没法简化贴花几何,因为它已经非常的简化了(如果一个螺钉是一个四边形,你就没法再简化它了。。。)另一个问题是,如果一个资源的细节层次更低,而你在更高的细节层次使用贴花,这二者就不会再匹配了。我们计划使用自动细节层次,但是因为这个原因我开始觉得那可能不可行。设计师可能得手动地创建每一个细节层次和它们对应的贴花。

在引擎方面,我已经开始实现缺失的特性来支持这些几何贴花与材质。将诸如Z偏移/Z尺度的细节暴露给用户(来避免深度冲突),渲染器的顺序(来确保一个材质在它的基础材质之后才被渲染),编写遮罩(一些贴花可能只想要在法线方向上写,另一些则要扩散的,还有一些则两者都有),alpha混合或遮罩等。。。

在延迟渲染器方面alpha混合成了一个主要的问题,而且与我们目前的G缓冲并不兼容。我准备将它给换掉来进行贴花混合。我可能要把今天一整天时间都花在上边了。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

QQ|小黑屋|手机版|Archiver|无限星辰 ( 京ICP备12007702号-2 )滇公网安备 53011202000341号

GMT+8, 2019-1-16 15:43 , Processed in 0.031795 second(s), 15 queries , MemCache On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表