你写错字了，宏里那个 METY 和参数 META
C 中有##或#的宏参数好像不会嵌套扩展。可以预先把宏扩展一次，像#7 那样

@weixiangzhe 应用商店应该是限制 targetSdkVersion 吧，minSdkVersion 通常不会限制

最正确的姿势当然是不要让程序挂掉

@nguoidiqua
@wyz123723
我想就算播片+QTE，甚至单纯播片，文字冒险那样的，也是可以算作游戏的，但是确实多数情况下确实没有短视频轻松。可能就是觉得刷完短视频后感到空虚的用户也体会下创造的乐趣（纯个人 yy ）

关于 pico-8，因为我的想法是从一个游戏平台，发展覆盖更多的应用场景（更开放的小程序平台？），所以不太能接受非必要的限制，可能是想多了吧哈哈

@aguesuka
想想好像确实有点像，不过听说微信平台的限制挺多的

@LokiSharp
RPG Maker 在我的远古记忆中是不开源且不支持移动端的，不清楚现在的情况如何，好像已经支持 android 了

@IzayakI
这个想法中没有归属和版权的定义，你 fork 了就是你的分支这样的感觉。素材盗用这个确实没想过，现在的同人二创有着相似的问题。

@RobertLyu
@Pho3nix
如果说是那种远程桌面类似的那种云游戏的话，和我说的这个不是一个意思。我的这个想法是更偏重社区特性


@IzayakI
因为我也只是有个很初步的想法，没有很具体的考量。我想确实会以独立游戏为主吧，就像早期 up 主出于兴趣制作视频一样。


@across
Gal 这也算是一种游戏形式

@byzf
@leimao
确实现在游戏制作成本是比较高的，所以需要降低创作门槛，比如有马里奥制造和魔兽争霸 3 这样的地图编辑器级别的 IDE 。然后就是现在程序员越来越多，说不定有“程序员红利”的可能，不过感觉大家都挺忙的，没时间搞这些

@xatest #8
并不一定基于 web(实际上要实现丰富的功能和良好的用户体验，纯 web 几乎不太可能)，只是从生态考虑 web 技术是最适合快速成型的。
itch.io 之前没接触过，了解了下，确实是一个不错的社区，不过没找到其他语言支持，可能对中文用户不那么友好。我想如果把 github 和这样的社区结合，例如你在玩这个游戏时，还可以查看有哪些开发分支可以选择，还可以为分支添加评论，想加载分支时也不用下载解压复制存档等，一键就可以加载特定分支的代码并运行(感觉这里面技术需要填的坑可能不少）。
大部分 API 说到底只是用于数据存储，提供这样的 API 只是为了增强游戏的吸引力，就像传统视频网站添加弹幕功能一样

@murmur #9
设想中没考虑被 ban 的问题。相关规定我也不懂

@xatest #2
简单说就是跨平台的游戏协作开发及发布社区

@skrsb #3
steam 社区也不能直接访问了，我设想中是以开源作品为主，开源方便多人协作创作分支，还可以支持一些弹幕和多人游戏的 API，像马里奥制造那样的

@Dox #4
云通关的话缺少交互性，不过对于不想费力动手打游戏的用户也是不错的。

@noe132 #5
没有使用过 pico-8，在刚刚粗略的了解过一下后，我发现这个平台在画面音效运行资源等方面有较多限制，我设想的平台不具有这些限制，用户甚至可以开发一套 IDE 作为"游戏"发布。
优秀内容创作的门槛确实比较高，因此提供了可以由其他人 fork 并完善的想法，也可以先发布一个半成品的原型，然后慢慢丰富内容。但是问题果然还是以开源游戏为主，平台和内容创作者就很难获得收益，存续的方式堪忧。

@hjahgdthab750 kotlin native 好像还真可以，不过我不太喜欢每个程序都给自己打包个运行环境副本的做法

java 最近加特性也加的挺快的，最近也在了解 Kotlin 。

fmemopen 但是 windows 上可能没有，可以自己实现一个类似的，加个指针读取并移动指针应该就行了吧

@lxtx2018 #48 如果你这样想的，我觉得你适合学 Go，比 Java 还不花里胡哨。最近版本 java 也加了不少语法糖，还有些库反射用的也比较花。不过个人觉得，编程语言具备这些常用的语法糖是很必要的（除了 C，因为 C 需要支持相当广的场景）。

@lasuar 目前广泛使用的 Jvm,hotspot 并不是解释执行的，分发二进制不是常规操作的原因主要是系统架构及 ABI 不同，就需要针对 windows,linux,x86,x86_64,arm 等等一大堆的平台生成二进制

@linjian 你把 try 的异常 catch 住打印出来，闪退你就用控制台运行，文件被独占模式打开就不能覆盖

notify，wait，和条件判断通常是一起用的，条件判断后选择进入等待或继续运行，这个时候要保证条件判断后，条件不会被其他线程改变，所以通常都会有个锁保障类似的场景。

是不是 udp qos 了？这个可能要问运营商才知道了

bytebuffer 设置小端字节序试试

你把端口都发一遍，那 nat 设备端口不就被你占满了，甚至会影响到其他用户的 udp 通信。nat 设备可能会限制 nat udp 端口数量的吧

如果只是等待线程计算结果，用 Future 就够了，BlockingQueue 都麻烦了

public <T extends BaseEntity> String importDataUnion(Class<T> clazz, MultipartFile file){
ExcelUtil<T> util = new ExcelUtil<>(clazz);
...

@fovecifer 理论最高效应该是回调，但是我想你大概不会喜欢这么写异步程序的