个人备案能公司网站,哪些网站可以免费看剧,微信公众号开发需要什么技术,重庆搜索排名提升这一节没讲什么主要是关于接下来要干的任务
开发过程概览
我们正在进行最后的总结#xff0c;并计划接下来的步骤。目前的目标是创建一个包含所有必要组件的游戏引擎原型版本#xff0c;目的是让这些部分能够协同工作并展现预期效果。通过这一过程#xff0c;可以实验和探…这一节没讲什么主要是关于接下来要干的任务
开发过程概览
我们正在进行最后的总结并计划接下来的步骤。目前的目标是创建一个包含所有必要组件的游戏引擎原型版本目的是让这些部分能够协同工作并展现预期效果。通过这一过程可以实验和探索各部分如何运作从而明确需求并为后续实现更强健的系统打下基础。
我们需要一个完整的框架版本其中所有预期功能都得以体现这样便可以开始编写实际游戏。如果需要后续添加功能或优化部分代码也能够在明确需求后进行调整。
通过这一灵活的开发方式可以快速验证核心概念和设计是否合理。例如在渲染部分需要先了解渲染如何在实际中被使用再优化实现。否则很可能创建一个无法满足需求或效率低下的系统。同样地碰撞检测、路径规划等核心系统也需要通过实验探索明确需求后再进行系统化优化。
这一过程的核心思想是确保每个模块的初版具备基础功能并在整体框架中完成测试和验证。只有在了解实际需求后才开始优化和扩展避免浪费时间在不必要或不实用的设计上。
目前我们正在继续完善原型框架确保各模块之间的协调运行。今天的任务包括检查和整理之前完成的部分同时探索下一步的改进方向和关键任务。
碰撞规则哈希表的回顾
我们今天的任务是讨论和回顾碰撞规则列表的实现。之前提到当某个物体与另一个物体发生碰撞时我们希望能够让物体继续通过而不受阻碍同时记录下这次碰撞事件。然而碰撞系统并不需要处理所有的细节只需要知道碰撞发生的事实。
为了实现这一点我们创建了一个哈希表用来添加碰撞规则。具体来说当两个物体相互接触时如果碰撞的反应是“不再关心”那么就将这个规则添加到哈希表中这样就不会再收到关于这个碰撞的通知。这种方法是否是最佳的我们还不确定但目前我们决定尝试这种方式。
这一过程的核心是简化碰撞检测系统只在碰撞开始时记录事件而不需要每次都重新处理整个碰撞细节。这种做法让系统能够更高效地运行尤其是在不需要频繁更新的情况下。
从哈希表中移除碰撞规则的问题
在哈希表的应用中我们遇到了处理碰撞规则的挑战。具体来说当我们处理碰撞时需要考虑到多个碰撞规则的管理。例如在一个游戏中像剑这样的物体可能会与不同的实体发生碰撞。每当剑与怪物发生碰撞时就需要添加一个新的碰撞规则。这导致了一个问题随着游戏的进行规则会不断增加可能会达到成千上万条规则。
因此问题就在于如何有效地删除这些规则。我们意识到哈希表本身并不提供直接的机制来清除特定实体的碰撞规则。哈希表的查找操作是基于两个索引和一个实体的但如果碰撞规则存储在哈希表中并且需要清除这些规则就会遇到一个难题如何在不遍历整个哈希表的情况下找到并移除这些规则。
这个问题的根本在于哈希表无法有效地处理那些需要删除的碰撞规则因为我们没有合适的数据结构来支持删除操作。虽然可以通过查找某个实体并逐步删除规则但这种方法在实际应用中效率低下因此我们需要改进现有的数据结构确保能够高效地删除碰撞规则而不需要每次都搜索整个哈希表。
总结来说为了更好地管理碰撞规则需要设计一种新的数据结构允许在不遍历整个哈希表的情况下快速删除与特定实体相关的碰撞规则。
一个简单的解决方案用于快速在哈希表中找到实体的碰撞规则但目前还没有实现
问题背景
在哈希表中如果键是由多个元素例如a和b组成那么删除涉及这些元素的条目会变得更加复杂。我们无法单独通过a或b来直接定位并删除相关条目。
解决方案
为了简化删除操作可以采用以下策略 存储索引对的两种顺序
假设有两个实体A和B它们分别对应索引i和j。我们不仅存储索引对(i, j)还存储索引对(j, i)。这样无论我们查询的是(i, j)还是(j, i)都能从哈希表中找到相关的条目从而简化删除操作。
优势
删除简便通过存储两个顺序的索引对可以直接删除A和B相关的所有条目而不需要考虑它们在哈希表中的顺序。提高查找效率不管A和B在哈希表中的存储顺序是(i, j)还是(j, i)都能确保我们能够找到并删除相关条目。
挑战与权衡
内存开销每个条目需要存储两个索引对这会导致额外的内存消耗。对于大量数据这可能成为问题。性能和存储的平衡为了减少内存消耗可以减少指针存储但这可能会影响删除操作的效率。因此需要在内存使用和性能之间找到合适的平衡。
优化方法
双向存储索引为每对元素存储两个顺序(i, j)和(j, i)确保可以在删除时快速找到所有相关条目。空闲列表更新在删除时记住空闲列表的顶部位置并在删除操作完成后遍历空闲列表将删除的索引对反向删除确保所有相关条目都被移除。
示例
假设我们有哈希表存储两个实体A和B它们分别对应的索引为i和j 存储索引对 哈希表中存储(i, j) 和 (j, i)。这样无论A和B是按照(i, j)顺序还是(j, i)顺序插入都能确保哈希表能找到这两个实体。 删除操作 假设我们要删除A和B。首先记住空闲列表的顶部位置例如k。然后遍历哈希表找到(i, j)和(j, i)并删除它们。 更新空闲列表 删除(i, j)和(j, i)后将它们插入空闲列表。遍历空闲列表并反向删除这些索引对确保从哈希表中删除所有相关条目。
总结
通过存储索引对的两种顺序哈希表能高效执行删除操作。即使条目顺序不同只要存储了这两个顺序就能确保删除时不会遗漏任何相关条目。尽管这种方法会增加内存消耗但可以在性能和内存之间找到平衡简化删除操作。
AddRadiusTo函数中的一个Bug
在开发过程中遇到了一个bug这个问题最初没有引起注意但幸好有人报告了这个问题。我们当时并没有意识到它直到它被指出因为它是一个看起来很不起眼但可能会带来很大影响的错误。
问题出在了我们代码中的一个矩形扩展的逻辑。原本的意图是增加矩形的宽度和高度但在实现时由于打字错误错误地进行了减法运算而不是加法。虽然在当前使用的场景中这个错误不会导致问题因为我们传递的是相同的宽度和高度值但如果在未来的某些情况下我们传递了不同的值这个错误就会导致程序不能正常工作。
幸运的是检查代码的人发现了这一点并指出了错误这避免了在后续开发过程中遇到更严重的影响。虽然这个问题看起来只是一个小小的打字错误但它确实提醒了我们在编程时即使是看似简单的细节也要格外注意。
此外当我们在代码中出现错误时尤其是在调试过程中能有人提醒我们是非常有帮助的。虽然调试是一个个人的过程自己调试时能从错误中学习但他人的指正能帮助我们更快地发现问题节省调试时间。这种帮助非常宝贵特别是在复杂的问题中。
总之在编程中错误是不可避免的即便是最细微的打字错误也可能引发问题。通过及时的沟通与帮助可以大大提高工作效率避免错过一些潜在的错误。 关于接下来开发内容的头脑风暴
首先我们需要处理当前存在的排序问题。现在物体的绘制顺序没有经过排序导致某些对象比如角色被错误地绘制在树木后面这显然是没有意义的。虽然这个问题暂时没有对开发进程造成太大影响但它确实需要在渲染时得到修正。
此外我们还需要解决关于怪物行为的问题特别是当怪物死亡时应该触发的行为。这是我们目前需要考虑的一项任务。除了怪物行为外我们也必须开始规划如何处理更复杂的系统例如路径发现碰撞检测等。
在碰撞检测方面我们目前使用的是碰撞规则但这些规则是否足够有效呢比如在处理压力板等交互物时是否需要特定的规则来确保只有在第一次踩上去时触发相应的行为这类问题让我们思考是否应该依赖现有的碰撞规则还是考虑实现更复杂的几何碰撞检测系统。
此外我们还需要考虑是否需要为这些规则添加时间窗口来确保它们能正确地应用和移除。我们可能还需要考虑在不同的碰撞检测场景中采取不同的方式尤其是在处理物体进入或退出某些区域时。
同时我们也在思考如何在更复杂的场景中使用这些系统例如让角色穿越复杂的环境避免障碍物或其他干扰。这个问题涉及到的路径发现系统可能需要更多的工作和调试但它可能是我们接下来要解决的一个难题。
最后我们还需要考虑动画的实现。虽然我们一直将动画放在待办事项的末尾但它是项目中不可忽视的一部分我们应该为其分配时间并开始着手处理。
综上所述我们的任务列表包括修复排序问题、规划怪物行为、改进碰撞检测、实现更复杂的路径发现系统以及开始进行动画的实现。
待办事项动画/渲染
我们决定开始处理动画因为动画会直接影响渲染的过程。动画涉及到多个方面首先是粒子系统的实现另外还包括骨骼动画。这些图形效果将为渲染提供动力因此我们需要先实现动画部分。
在动画的实现过程中我们需要考虑如何对角色的不同部分进行旋转。当前的位图绘制代码无法支持这一功能因此我们需要更新绘制代码来适应旋转操作。动画的实现将产生一系列需求这些需求直接影响渲染工作。
在渲染阶段我们将面临一些要求比如缩放和旋转操作。渲染代码必须能够处理这些需求因此我们计划在渲染前进行最后的动画设置将动画的实现推迟到接近渲染开始时。这样我们就可以确保动画和渲染的协调进行避免过早开始动画造成不必要的处理。
待办事项游戏逻辑
在实际的编码过程中游戏的开发将进入一个重要阶段。在这个阶段可能需要推迟开发实体系统因为与游戏同时出现的将是能源系统。因此在这之前关于实体系统我们可能只需要关注可扩展性和如何处理它的增长。
在这个过程中暂时会将一些不太复杂或不执行任何实际操作的实体比如“小猪”实体暂时搁置。重点放在能源系统的实现上因为它将与游戏的其他部分同步发展。
能源系统将在游戏构建过程中逐步出现并演化成为构建游戏的一部分。在游戏开发的过程中随着时间的推移这些系统将不断进化以满足游戏的需求。
待办事项基础世界生成
在世界生成中首先要关注的是创建一个基础的世界框架。当前生成世界的能力是非常有限的仅仅能够创建一堆连接的房间。接下来的目标是建立一个基础的世界生成系统能够生成具有地面覆盖的树木、岩石等元素而不是将树木排成一条奇怪的线。
这个生成系统的核心目标是让世界看起来更符合实际尽管我们不会使用复杂的算法而是以基本的方式放置一些树木、岩石和草地确保这些元素有合理的布局。这将帮助我们更好地理解世界的构建方式虽然是粗略的但至少能确保系统能正常运作。
对于世界生成的代码支持重点将放在如何实现生成算法以及如何确保不同元素如树木和岩石不会重叠确保背景元素和其他结构能够合理地放置。这些基本的步骤对于确保世界生成系统的有效性和支持其他系统的功能非常重要。
待办事项AI系统
在世界生成和系统设计中我们需要处理不同类型的查询和管理相关事物的方式。首先系统需要支持对物体的发现和代理管理。这包括为那些在世界中有某种代理的物体提供一个概念帮助理解它们在任何时刻的行为和目标。这些物体可能有一些目标需要完成或者有其他标准的任务。
为此我们可能需要设计一个机制用于管理这些目标和行为例如通过链表或其他数据结构来存储这些信息。同时我们还需要考虑在没有特别计划的情况下如何确保这些行为可以正常进行避免出现不符合预期的情况。需要明确的是在处理这些行为时要避免任何异常情况确保系统运作顺畅。
这些设计的核心在于理解物体如何在系统中进行交互和变化确保我们能够有效地管理每个物体的状态和行为。
待办事项碰撞检测
在系统设计中碰撞检测是一个关键的问题。需要考虑如何有效地处理碰撞事件确保系统能够在检测到碰撞时进行恰当的反应。与此同时考虑到健壮性系统设计必须避免陷入一些复杂的情况或异常确保在各种条件下都能够稳定运行。
为了实现这一目标可能需要对碰撞检测的具体实现进行规划包括如何定义碰撞的条件和处理逻辑。在这一过程中虽然具体的方法可能尚不明确但已经认识到这是一个需要关注的重要部分。最终确保所有要做的事情能够按计划进行并在列表中明确列出所有关键任务是设计过程中的重要步骤。
待办事项每帧实现多个模拟区域
在多路模拟的设计中每个区域的更新非常重要。通过每单位时间的更新能够跟踪实体的状态并决定它们是否需要进一步的更新。这个过程包括为每个单独的步骤设置合适的更新机制确保实体在每个区域内按预期进行模拟。
当玩家靠近时可能会将多个玩家合并到一个区域中进行模拟。这样可以更加高效地进行处理尤其是当玩家位于世界的不同地方并逐渐靠近时。合并区域的操作相对简单能够快速地识别并管理不同区域内的玩家。
此外需要定期检查和测量这些合并区域的效果确保模拟过程的准确性和效率。在游戏开发过程中可能会遗漏一些细节需要通过不断思考和检查来补充完整确保系统的设计是完善和高效的。
待办事项元游戏/存档系统
在游戏设计中关于是否允许保存游戏的决策非常重要。虽然我们可能不希望玩家在游戏中随时保存进度但我们可能希望玩家能在某些时候暂时中断游戏并能够在以后继续游戏。这要求我们考虑如何平衡游戏的流畅性和玩家的需求。
另一个重要因素是崩溃恢复。即使我们在开发过程中消除了所有已知的bug系统仍然可能因外部因素如图形驱动程序问题而崩溃。因此设计一个能够在游戏崩溃后恢复进度的机制是非常重要的这样玩家即使在突发情况下也能继续游戏而不会丢失大量进度。
为了应对这些问题定期保存游戏进度是一种很好的解决方案。特别是在长时间的游戏过程中例如扩展到几十小时的游戏时间时玩家可以避免因为崩溃或错误导致的进度丢失。通过周期性保存我们能让玩家从最近的保存点恢复而不是从头开始。
然而保存游戏时可能会遇到一些挑战尤其是当游戏世界非常庞大时。保存大规模的游戏世界可能会导致保存文件过大影响存储和加载速度。因此增量保存成为一种有用的技术允许我们只保存更改过的数据而不是每次保存整个世界。这样可以有效减少数据的存储需求提升性能。
另外还需考虑持久数据如解锁内容、玩家成就等与游戏进度保存的分离。这样可以确保保存文件的大小得到控制同时避免每次上传大量数据特别是在云存储中。通过将持久数据与游戏进度分开存储我们可以优化游戏的保存和加载过程。
待办事项AI - 基础怪物行为示例
游戏设计中涉及了初步的行为模型此模型旨在展现如何通过简单的行为示例来推动游戏角色的行为。在游戏中可能会通过这些示例来设定角色的动作或互动方式帮助模拟真实的医疗场景或处理医疗任务。
待办事项Z轴实现
在游戏开发中需要考虑如何实现角色在不同高度上的移动例如上下楼梯。通过使用向量3来处理角色的上升和下降可以解决渲染和动画的问题。像《以撒的结合》这类游戏虽然处理了类似的上下运动但它们并没有真正展示角色上下楼梯的过程而是通过跳跃动画或直接切换级别来简化这一问题。对于渲染我们可以选择一些简单的解决方案例如一触即发的屏幕切换但也可能考虑更复杂的渲染方式比如更精致的动画地图或者模仿一些做得特别好的游戏。
因此虽然处理“z轴”方向的运动不难但需要明确的实现方法和细节以便将其整合进游戏的整体结构中。这是游戏开发中一个值得探索的方面。
审查待办事项列表 - 什么内容是困难的什么内容是简单的
在开发过程中涉及到许多复杂的方面包括建筑、探索和生产等内容。这些领域可能带来不同的挑战有些可能是常见的问题而有些则比较独特和困难。尽管我们有一些明确的方向和想法仍然需要不断地回顾和检查是否遗漏了什么关键的任务或问题。特别是像建筑和探索这类复杂的系统它们可能会在开发中引发更大的难题。因此虽然我们已经知道一些困难的工作需要完成但有些部分的解决方案仍不确定需要进一步深入思考。
待办事项音频系统
在音频方面开发团队不需要进行过于复杂的工作。尽管音效、环境音和音乐对游戏体验非常重要但考虑到预算有限不必打造一个复杂的音效编辑系统。所需的音效可以通过购买现成的素材来完成例如流水声或其他背景环境音。当游戏需要这些音效时就简单地将它们引入。虽然将来可能会对音效做一些调整或改进但目前的目标是实现音效的基础支持确保音效和音乐能够适应游戏的需要而不会投入过多的资源。
在整个开发过程中需要确认是否遗漏了任何重要的部分并确保所有的要素都已涵盖。除了奖牌游戏等额外的元素其他重要内容基本上都已经梳理完毕。
待办事项元游戏 - 存档槽
在游戏设计中存在着如何处理多个保存槽save slots的问题。尤其是当多人共享同一台设备时比如家里的客厅电脑两个玩家可能会希望各自保存自己的游戏进度而不需要互相干扰。这个问题涉及到如何在游戏中有效地分开不同玩家的保存文件确保每个人都可以解锁自己的内容而不会覆盖或混淆其他人的进度。
为了解决这个问题可能需要设计一种机制使得每个玩家都能选择自己的保存槽并且在游戏中保持这种分离。一个简单的方式是在游戏开始时让玩家通过类似空间选择的方式来选择他们想玩的“世界”而不是通过传统的菜单选择保存槽。玩家可以通过类似走楼梯或选择通道的方式来选择自己想要的游戏进度。
然而这种设计会引入一定的代码复杂性因为游戏需要确保每个玩家的进度保持独立并且无误地加载正确的存档。因此必须在开发过程中确保这一点能正确实现避免出现保存文件混乱或数据覆盖的问题。在进一步开发之前团队需要对这个机制进行充分的思考和规划。
游戏内UI是否有必要
在设计游戏的最终阶段时目标是避免过于复杂的“结局”设计。希望游戏在结局部分能够避免冗余的、让玩家感到不必要的复杂元素。理想情况下希望能够省略掉一些“最后的结局”设定保持游戏的简洁性。
有一种想法是可以通过“漂浮的元素”来处理这可能是一种简单的动态设计类似于悬浮物体的机制但这并不是强制性的要求。设计者希望能够尽量避免复杂的结局设定保持游戏体验的流畅与简洁而是看看是否能在没有这种复杂性的情况下完成设计。
总之最终希望能够通过去除复杂的结局机制创造一个更简洁、自然的游戏体验。
待办事项调试代码
在开发过程中调试工作非常重要并且需要将日志记录logging纳入计划中以便于问题跟踪和修复。调试代码和生成图解像是用开关、滑块等元素是工作的一部分。这些步骤有助于确保调试工作顺利进行。
尽管有这些工具游戏界面GUI在设计上可能只是做一些简单的调整。虽然会做一些基础的图形用户界面GUI元素但总体上并不会过度依赖图形界面因为某些开发者并不喜欢复杂的GUI。虽然偶尔需要手工制作一些元素比如在经典游戏《过山车大亨》-好像是叫《模拟乐园》等中看到的那种窗口风格但仍然倾向于保持界面的简洁性不让它看起来像是一个复杂的应用程序。
尽管如此仍然有可能做一些简化版的图形界面适应游戏的需求尤其是为了调试和提供提示功能。
待办事项基础世界生成 - 地图显示
关于地图的设计虽然地图是一个很有趣的元素但如何实现地图显示是一个技术上的问题。这个问题需要进一步的思考以确定最佳的实现方式。考虑到这个问题的复杂性有可能需要更多的规划和技术上的准备。在思考这个问题时已经开始了一些初步的想法并计划将其记录下来作为未来开发的一部分。
玩家是否可以携带多个物品
关于携带多个物品的问题决定是尽量避免这种机制。在游戏中计划保持物品数量较少避免过于复杂的物品管理系统。尽管地图是一个有趣的元素但它并不是当前设计中的重点。整体来说游戏的设计思路已经基本完成主要内容已经确定并且接下来会对已经列出的内容进行排序和进一步规划。
对待办事项列表进行排序
计划中首先要清理和完成一些已经开始但尚未完成的任务如碰撞检测代码和调试工作。接下来会按优先顺序完成这些任务确保在做其他更复杂的工作之前基础功能已经顺利运行。
在下周准备开始新的内容但不会进行过于复杂的开发而是清理已完成的任务这样可以避免在休假一周后留下未完成的工作。之后可以逐步开展更多的工作比如处理碰撞检测的完善、调试代码的优化、和动画系统的对接等。
这个计划的目标是在完成所有任务后拥有一个可玩的引擎虽然某些部分可能还不完全成熟但会为后续的工业化增强和真实化提供良好的基础。最终目标是逐步将所有功能整合到一个稳定、强大的游戏引擎中逐步改进、完善最后达到工业级的质量标准。
这样列出待办事项是否过于超前或不符合压缩导向编程的理念
计划不是严格的时间表而是一个灵活的参考列表包含了未来一段时间需要完成的任务。当不确定下一步该做什么时可以回到这个列表选择需要完成的任务。这个列表的目的是确保在开发过程中不会忘记任何重要的任务。虽然有很多内容可能随着工作进展而发生变化但它为当前的工作提供了指导并能帮助理清思路。我们不必强制按照列表的顺序执行而是可以根据需要随时调整任务的优先级。
例如处理某些任务时如果我们发现需要做其他修改可以随时加入新的内容或改变现有内容。最终目标是确保所有必要的任务得到完成但没有必要对列表上的每一项任务都严格执行。
在GetHashFromStorageIndex函数中通过位操作将哈希值映射到哈希索引。为什么不直接通过hash index hash value MOD array count计算哈希索引
在讨论哈希表索引的计算时避免使用取模mod操作的原因是因为取模操作涉及整数除法而整数除法在计算中是较为昂贵的操作。与此相比按位运算bitwise operations通常更为高效因为它们执行速度更快。整数除法的成本主要是由于它需要对数值进行更复杂的运算通常需要更多的处理器周期因此在性能敏感的程序中尽量避免使用它。
此外虽然取模操作可以简化哈希表索引的计算但在实际应用中特别是在需要优化性能的情况下非2的幂次大小的哈希表可能会导致更高的开销。因此这种权衡决策的最终选择取决于特定的使用场景和目标平台的性能。现代计算机的内存访问速度和处理器的高速运算能力已大大改善取模操作的成本可能不如过去那么高但仍需要根据具体情况进行测试。
总体来说这类优化策略的决定是根据目标平台的性能特点来做出的。在一些情况下取模可能不是性能瓶颈而在其他情况下使用按位运算等优化手段可能会显著提高程序的运行效率。因此测试和了解目标平台的特点对于做出最佳决策非常重要。 目前伴随角色移动的熟悉角色familiar会有延迟因为它的移动速度比玩家慢。在某些情况下玩家和熟悉角色可能会分开。是否考虑过为其速度实现比例积分微分控制器
目前对于玩家的familiar问题我们并没有专门尝试实现复杂的控制器。我们只是想要一些简单的机制以便能够看到整个系统架构应该是什么样的。具体的实现尤其是familiar系统的细节会留到后面整个游戏开发过程中的进一步处理特别是在对家庭成员系统的实现和如何让它们发挥作用时。
关于比例积分微分控制器PID控制器尽管它们在很多情况下都非常有趣但也存在一些缺点。对于游戏来说积分部分通常并不那么有趣反而比例和微分部分更具吸引力。比例和微分控制器能带来一种更具弹性、略显不可预测的行为这种行为通常更适合用来做游戏中的互动和反馈。与此相对积分项可能并不适用于游戏中的许多场景尤其是在控制行为上需要可预测性的情况下PID控制器也许并不是最好的选择。
对于那些需要高度可预测行为的情况PID控制器可能不是最佳选择。在这种情况下可能更倾向于使用某种形式的盲插值blind interpolation来处理这些场景中的行为。因此目前很难确定具体会使用哪种方法但这一问题会在未来的开发中逐步明晰。
是否必须进行Z排序对于这样的游戏是否可以只基于Y轴排序通过调整速度来模拟爬楼梯例如当角色上楼梯时改变速度
对于这个游戏来说z轴排序不能仅仅依赖于y轴的排序。虽然对y轴进行排序是常见的做法一旦完成了y轴的排序我们就可以轻松地通过排序比较来获得z轴的排序。通常当我们进行排序时排序比较会是复合的不仅仅是对一个轴进行排序这样一来z轴的排序也能顺利得到实现。
不过问题并不在于排序本身而是在于角色上下楼梯时的表现。我们需要考虑的是角色在楼梯上上下移动时应该如何呈现如何实现这种表现。这是一个展示的问题而不是代码实现的问题。
至于代码的部分我们相信能够实现所需的功能但关键在于如何设计和表现角色在楼梯上的动作。当角色向上爬楼梯时应该如何显示这一动作如何流畅地过渡到下一个阶段像是从楼梯的某一部分切换到另一部分这些都是需要仔细考虑的地方。
听说正在讨论动画看到你提到骨骼系统。是计划从现成的软件导入还是为美术人员制作一个动画程序
目前程序正在开发一个供艺术家使用的动画工具。这个工具可能会主要依赖程序化动画但也有考虑过使用预制工具来导入骨骼动画。某些工具提供了低成本的解决方案并且有免费的版本可以用于制作简单的骨骼动画。这种工具看起来是一个潜在的、合理的选择可以用来导入动画数据进而加载到游戏中。
然而尽管这类工具可能会非常合适但是否使用这种预制动画尚不确定。可能整个游戏中的动画信息都会通过程序化方式生成而不需要通过创作的动画文件。如果决定使用的话可能会考虑这种工具作为一种低成本的动画制作工具特别是它能输出数据文件适合用于游戏中。
总的来说动画的实现方式还不完全确定可能会更多依赖程序化的生成而非预制的动画。
待办事项列表中提到超级鱼Superfish
在游戏设计中已经有一个文本文件里面包含了所有想要在游戏中实现的设计元素。这些内容目前只是表面上的设计。最近有关于一个“肤浅的敌人”概念的讨论想法是设计一种模拟敌人其行为类似于模仿其他物体或存在。这种敌人就像“伪装者”可以模仿不同的物体比如箱子或者出租车等类似于《地下城与龙》中的一些概念。
这种敌人可以在玩家接近时变身成怪物形成一种潜在的威胁。简单来说这个“肤浅的敌人”就是通过模仿的方式来欺骗玩家玩家习惯性的行为可能导致他们遇到意想不到的危险。这一设计可以提供不一样的游戏体验增加游戏的不可预测性。
待办事项列表中缺少资产加载管理。
资产加载管理的功能在列表中被遗漏了这是一个很好的提醒。伤害的设计也被提到了这是一个值得注意的例子。在讨论如何实施这些功能时考虑到资产流管理可能需要在当前的框架中加入这一部分以便更好地管理和优化资源加载。
哪款2D游戏在Z轴移动方面做得很好个人很喜欢《波斯王子》里爬台阶的表现。
在谈论图蒂游戏时波斯王子的例子被提了出来特别是角色在游戏中爬上台阶时的动作。这个动作设计得非常好因为它让玩家直观地感受到角色的上升过程。波斯王子的设计方式也符合逻辑因为游戏是从横向视角展示的而角色的上升动作在屏幕上是垂直的这让玩家更容易理解游戏中的物理运动。与此相比其他等距或顶视角的游戏可能会让玩家对角色的上下移动产生困惑因为这些游戏的视角变化较大。
对使用他人代码作为学习工具有什么看法
使用现有代码作为学习工具是完全可以接受的甚至是推荐的做法。很多人并不清楚如何编程但通过使用现成的库或引擎能够让他们快速实现想法和功能。然而在此过程中重要的是能理解这些代码背后的原理。如果只是依赖于现成的工具而不理解其工作机制就容易犯一些常见的编程错误这些错误可能会使游戏体验大打折扣。
尤其是当你自己做游戏时有时候你会遇到明显的编程错误这些错误如果修正游戏的质量就会有显著提升。因此理解如何编写基础代码是非常重要的即便使用现成的引擎和库。这样不仅能避免常见的错误还能让你在面对问题时更容易修复和调整。这是展示如何从头编写代码的原因之一目的是让更多的人了解编程的基础并且能在使用现有工具时理解它们的工作原理避免因为不理解代码而导致的问题。
Spriter的文件格式是完全开放且有文档记录的。
考虑到使用创作的动画如果决定采用这种方式它可能是一件好事。但更倾向于使用过程性动画因为过程性动画更侧重于代码的实现这也正是系列内容的重点。因此最终可能会选择让动画更具过程性而不是依赖已创作的动画。
游戏中是否会有任务如果有如何规划和定义这些任务
在构建游戏时如何定义某些要素并不是一个架构问题。这个阶段更多的是关于构建和运行游戏而不是在架构设计中考虑过多的细节。因此当前的架构探索过程不需要考虑这些因素它们并不会对整体架构产生重大影响。
上次在碰撞代码中是否遗漏了检查Entity HitEntity的部分
在处理碰撞检查时发现可能遗漏了一个关键步骤。之前提到要在某个地方进行实体检查但实际上没有把它实现。这个问题导致可能不必要地进行自我检查浪费了时间。因此确认只有当实体 A 和实体 B 不同的时候才进行碰撞检查这样可以避免浪费资源。感谢指出这个问题并且确认现在的逻辑应该是正确的。 是否会为怪物路径规划算法申请专利
对于专利制度的看法认为它非常荒谬尤其是当有人试图用算法申请专利时显得尤为不合理。即使有人创造了新的算法认为应该让所有人都可以使用而不是限制在某些人的专利权下。对专利制度的批评认为它已经造成了很多不必要的限制和困扰。
关于Z轴移动是否可以通过改变精灵大小实现例如当角色上升时增大精灵的大小到达目标时再缩小同时对墙面纹理做一些视差处理。
讨论了关于Z轴运动和精灵大小变化的可行性。提出了一个想法即随着精灵向上移动时可以增大精灵的大小直到达到某一高度后再缩小。然而这样做似乎没有太大意义因为Z轴的运动并不会让精灵更接近摄像机。实际上精灵向上的运动对玩家的视角影响较小这意味着缩放精灵的大小可能不符合游戏的视觉逻辑。
如果游戏是从顶部俯视的视角如《塞尔达传说》那种风格也许会看起来更合适。因为玩家依然从侧面看到角色的变化精灵大小的变化可能显得不太自然。整体来看这种改变可能不符合我们想要的效果尽管很难断定最终的呈现效果。
觉得《宝可梦》第三代/第一代在Z轴处理上表现不错。
讨论了《口袋妖怪》第三代在Z轴方面的表现认为它在这一方面做得很好。然而随着游戏的推进这一设计在第三代被削弱。提到“珍”的意思可能是指“第一代”。在此过程中提出了如果能分享一个视频链接或相关资源将帮助更好地理解这个话题。虽然并不完全关注某些细节但有些人对这些细节非常熟悉。
怪物遭遇战会是随机的像《最终幻想》、《勇者斗恶龙》还是更静态的像《塞尔达传说》
讨论了怪物遇敌的方式提出两种可能一种是随机遇敌类似《最终幻想》或《龙战士》那种方式另一种则是更静态的类似《塞尔达》的风格。在前者中怪物会出现在地图上你可以直接与它们进行战斗而不是通过某种代表性的怪物触发战斗。最终选择了前者即让怪物在地图上出现玩家与之互动而不是进入单独的战斗场景。
剑的攻击是否需要加入时间和距离的限制
讨论了是否在剑的功能上添加时间限制和距离限制。虽然添加这些限制是可能的但实施起来相对简单特别是在不涉及碰撞管理的情况下。如果决定添加这些功能可以作为一个例子对象进行实验目的是看看它们在游戏系统中的作用。对于时间限制它可以通过检查剩余时间在更新调用中轻松实现因此没有必要做过多的测试未来也很容易加入这种功能。不过目前来看这些限制对系统的影响不大。
《网络创世纪》Ultima Online似乎也处理了Z轴问题但不确定效果如何。
讨论了《Minish Cap》及其在处理额外内容时的表现。虽然没有直接玩过这个游戏但观察到有些人玩过甚至在一个游戏公司办公室中也有见过。提到了关于Z轴处理的问题虽然游戏中有使用Z轴的内容但不确定它的表现如何。此外谈到游戏公司办公室的布局员工需要上楼取东西。总体而言尽管没有亲自体验但依旧对一些细节保持了关注并愿意进一步了解。
参与过的最大游戏项目是什么
提到过一些参与过的较大游戏产品其中虽然没有直接编写游戏代码但有许多较大的游戏中使用了个人开发的角色动画系统。在工作中研究了这些系统的特性并将角色接口授权给了其他游戏。讨论中提到的“目击者”游戏是一款在其中直接编写代码的非授权游戏这款游戏现如今变得非常庞大。尽管它不强迫玩家解决所有问题但如果选择解决其中的所有难题它将是一个巨大的挑战。
关于动画的评论有没有遗漏
讨论中提到动画本身并不再被视为手工制作因为已经有工具介入其中动画的制作过程变得更加程序化。尽管加载动画本身是一个导入问题涉及解析文件格式但这一过程并不被视为创新或有趣的部分。动画的导入问题已经通过工具解决并展示了如何处理文件格式。在处理大型资产时可能会涉及到压缩文件以便运输而解析新文件格式也未必是一个有趣的任务除非真的有需要导入特定类型的动画。
在自己代码中写平台层时是否发现受某些现有解决方案的影响太大从而思路变得狭隘如何突破这种困境
在讨论中提到了一种现象即通过某种方法或解决方案的影响可能会形成对解决问题的偏见。这样的偏见可能导致在解决新问题时倾向于使用已经知道的解决方案而不是从根本上重新思考问题的本质。作者认为这种偏见并非恶意而是一种自然的倾向因为已知的解决方案让人觉得更容易解决问题。
接着讨论如何突破这种偏见。作者提到在面对问题时重要的是要反思并识别自己解决方案中的潜在问题而不是仅仅满足于已有的解决方法。通过重新审视问题提出新的目标并努力朝着这些目标去解决问题可以帮助避免陷入思维定势。每个解决方案都可能会有不同的权衡因此能够从多个角度去看待和解决问题是非常有价值的。
最终作者的建议是挑选不同的目标并朝着这些目标努力通过不断迭代来优化解决方案。这种方法比单纯追求不同的解决方案更有意义因为目标的改变会直接影响解决方案的效果。
理想的游戏时长应该是多少
在讨论游戏时长的问题时观点指出游戏的长度不应当是评判其好坏的标准。游戏的重点应当放在体验本身而非单纯的时长。不同类型的游戏适合不同的时长关键是游戏设计是否能够充分利用所需时间来提供丰富的内容与体验而不仅仅是为了填充时长。
一些游戏如《以撒的结合》因其可以不断地进化和提供多次游玩体验而具有高可玩性玩家能够在长时间内享受不断变化的内容。然而如果是互动故事类游戏20小时的时长可能显得过长因为故事的推进可能不需要如此多的时间。比如类似《行尸走肉》这类游戏其核心体验可能更适合较短的时长。
与此同时游戏不应单纯追求长度而应根据设计目标来确定合适的时长。某些游戏的玩法可能需要更长时间如《最终幻想》但并不意味着长度本身带来了更好的游戏体验过度拉长的游戏时间可能导致重复性战斗消耗玩家的时间却并未增加乐趣。
因此在游戏设计中更应考虑的是是否有足够有趣和有价值的内容支撑游戏时长以及是否能够为玩家提供合适的游戏体验。游戏的时长应根据内容的丰富性与深度来调整而不是盲目追求一个固定的数字。
