在 6 月 18 日的时候有一场 FGO 的游戏开发商 DELiGHTWORKS 面向游戏行业从业者举办的演讲会，谈数据库结构、海外展开架构还有游戏技术与制作有趣的游戏的关系。负责讲解技术和游戏有趣性的是 DELiGHTWORKS 开发技术指导田村祐树，在演讲中他提到复杂的技术和先进的技术并不会和游戏是否有趣直接相关，但是为了实现有趣的游戏企划是需要一定技术力的，而且是要敢于冒一些风险的。而在基础的数据库、CDN 等硬件设施方面最早 FGO 是采用了微软的 Azure 平台，但后来包括数据库和 CDN 全部迁移到了品质更好的 AWS 平台，FGO 在日本以外地区的游戏展开也以 AWS 平台为基础
田村祐树的演讲主题是「如何做出一款有趣的游戏」，田村祐树表示现在游戏制作的预算、周期、规模扩大，但游戏行业面临着前所未有的危机，实际上也有花了 2 年的时间开发的游戏企划由于种种事情停摆，发售后的游戏 bug 太多获得了用户的低评价，而造成这种问题的原因在于以下两点：
1、欠缺玩家的视角
没有提供玩家希望的游戏，只是做开发者自己想做的游戏，还有就是根本不存在的想象中的玩家
2、试错不足
游戏制品说明书中没有写出来有趣的作品样子
面对这两个问题，从技术角度该如何切入？复杂的技术与先进的技术并不会和游戏游戏有趣直接相关，但是面对一个有趣的游戏企划数如果没有相应的技术作支撑，好的点子也要舍弃掉，所以是需要一定的技术力才能创造有趣的游戏，没有一定技术力的话游戏做不出来，而如果因为畏惧失败而不敢冒风险那么游戏也有可能会死掉。因此需要的是技术随机应变的能力，在过去的主机游戏开发领域有游戏做完了就结束了这样的观点，但现在游戏几乎都是强调升级的概念，经过 1、2 年后游戏变成什么样子谁也不知道，所谓好的游戏设计就是玩家想玩游戏的时候不去干扰玩家，需要更加灵活的游戏结构，以变化为前提进行游戏设计。
游戏的迭代是否会让游戏有趣这谁也不清楚，但是并不能说游戏更新机能增加就是坏事，开发游戏无论如何都无法避免的就是「变更」，游戏开发是无法实现所有事情从一开始就决定好
而在游戏迭代变更中需要遵行的是以下五个准则
1、责任单一制
每个人对各自负责的部分而负责，不要搞双重责任
2、Open Closed 原则
对于游戏机能进行扩张可以，听取各种各样的意见和点子让游戏更强，但是对于修正则是紧关大门，所谓紧关大门就是绝对要避免部分修正对游戏整体造成影响。
3、里氏替换原则
里氏替换原则：派生型必须可以替换基础型
4、依存关系逆转原则
上位模块不能依赖下位模块，上位模块与下位模块应该依存于抽象的概念
5、接口分离原则
尽可能的将不重复的复数机构分离开来
田村说明做游戏的目标不是说「制作完成就结束」，而是要「能够向玩家传达游戏的有趣」，虽有有一些需求看似不可能，但可以一步步的迭代开发，游戏的开发过程中本身包含着很多不确定因素，如何预测这些不确定因素才是重点，唯有一定的技术和随机应变的能力才可以创造出有趣的游戏
另外在海外业务展开方面，来自 DELiGHTWORKS 的甲英明（这名字放中文里真不是什么好名），以 FGO 为例介绍了 FGO 在海外展开时所使用的一些基础的数据设备和网络设备以及案例。每个人对游戏的需求不同，玩家在游戏中会追求达成感、解放感、爽快感、连带感（社交感）等等，而游戏开发方面为了不让玩家对游戏厌烦需要持续提供全新的游戏内容，升级游戏数据调整游戏平衡，需要提供给玩家稳定畅快的游戏环境，下载安装简易读条时间较短。而为了这个目标开发商在运营基础设施方面需要遵从 RASIS 原则
所谓 RASIS 原则就是
信赖性：服务器、数据库机能安定
可用性：可用性较高，发生故障导致游戏停止时间较短
保守性：故障维修简单，在维持性能和机能的基础上较少的作业负荷
保全性、完全性：故障和异常早检出早修复，数据完整出现故障不会破坏数据
机密性：可以抵挡第三方外部攻击以机密泄漏
而 FGO 的游戏现在使用的是亚马逊的云平台 AWS，最早的时候 FGO 数据库使用的是微软 Azure 平台 MySQL 数据（初期小霸王服务器微软的锅？），但后来迁移到 AWS 平台提供服务，因为当时 AWS 提供的数据库性能更好，存储增大为 224 G， 数据处理性能还有所提升，FGO 后来也从 MySQL 变成了极光数据库，因为可以减少 30% 的成本而且可用性提升，还会自己增加存储。FGO 刚开始提供服务的时候每分钟请求量 10 万以上，现在是 30 万以上。而在 CDN 方面，FGO 最早使用的是 Akamai CDN 后来也换成了 AWS 的 CDN 服务，一部分是因为 Akamai CDN 性能的问题。目前 FGO 在海外的服务展开是以 AWS 平台做为基础，
原文链接： 好的游戏设计就是不干扰玩家，FGO 开发公司 DELiGHTWORKS 谈如何做一款有趣的游戏, 转载请注明出处