indienova

indienova同时积累独立游戏资料、文化文章、开发专题和会员开发日志。玩家可以在这里发现主流榜单之外的作品，开发者也能公开记录制作过程。使用时最重要的区分是：GameDB 条目描述作品，编辑或会员文章提供观点，开发日志记录某个时间点的计划和进度，三者都不能自动替代当前商店页或项目公告。

先用 GameDB 建候选，不在资料页直接下结论

发现作品后，先记录游戏名、开发者、发行商、计划平台、语言、类型和页面更新时间，形成候选卡片。然后回到开发者主页、发行公告和实际商店，确认是否已经发售、是否存在可玩的 Demo、目标设备能否运行以及当前价格。旧介绍仍能解释设计背景，但“计划登陆”与“已经可买”是两种状态。

文化文章适合回答“为什么这样设计”

访谈、评论和开发专题能补足作品的创作语境，尤其适合了解机制来源、美术方向和团队取舍。阅读时要分清作者观点、项目方陈述和可验证事实，并留意文章日期。若文章讨论特定引擎、插件或版本控制方案，还需回到工具官方文档核对当前兼容性，不把个人工作流当成普遍最佳实践。

开发日志要能复原一个版本的状态

一篇可跟踪的日志至少写清构建号或日期、本轮目标、已经完成的变化、仍未解决的问题和下一阶段。截图与动图用于说明现象，不能代替版本信息。读者据此能判断项目是否持续推进，也能识别方向调整；但排期、功能设想和众筹目标仍属于计划，不应被转述为确定的发售承诺。

试玩反馈从感受落到复现条件

1. 记录设备、操作系统、游戏构建号和输入方式；
2. 描述发生问题前的具体操作与期望结果；
3. 附上截图、日志或存档，并删去账号和路径中的隐私；
4. 把“节奏不好”等感受拆成等待时间、信息不清或失败成本。

开发者可以把重复反馈合并为任务，并在后续日志说明是否修复。涉及招募、素材或代码合作时，再单独核对身份、许可证、权利归属和交付范围，不因双方都在社区出现就省略书面约定。