游戏引擎学习第28天

仓库: https://gitee.com/mrxiao_com/2d_game

概览

在游戏开发的初期阶段，通常会进行一些基本的结构规划，但不需要过多的预先设计。预先规划往往因为信息不足而导致错误，从而浪费时间。因此，更好的做法是先进行探索，学习如何构建代码，再回过头来做出更明确的架构设计。

目前游戏的进度非常基础，窗口大小可以根据需求进行调整，但还没有涉及任何运动，当前的任务只是简单地在屏幕的上方绘制内容。后续会逐渐加入更多功能。

游戏开发中还包括一些工具，例如一个编辑器，用于编辑和调试。接下来的步骤是清理屏幕，准备开始绘制。清理屏幕时，可以选择用紫色作为背景色，虽然这不是最终的颜色，但有助于调试和区分不同区域。

至于颜色处理，开发者打算进一步探讨浮点数颜色的使用，并让开发者对如何使用这些颜色有更清晰的认识，确保颜色的使用更加合理。

浮点颜色讨论

看起来你在探讨的是如何在计算机编程中处理颜色和浮点数的标准化。你提到的许多内容涉及了如何将颜色表示为红、绿、蓝（RGB）值，并解释了浮点表示（0到1的范围）与实际计算机图像处理中如何使用它们的关系。

主要概念总结：

1. 颜色的表示：

   • 色彩通常使用RGB模型，其中每个通道（红、绿、蓝）有一个值，表示颜色的强度。
   • 这些值通常在[0, 1]范围内表示浮点值，其中0代表没有该颜色，1代表该颜色的最大强度。

2. 标准化和浮点运算：

   • 当你将颜色值标准化到0到1的范围时，进行颜色混合和其他图像处理操作会变得更加简单。因为浮点数计算在处理这些颜色时比整数更高效。
   • 你提到如果你要做颜色混合（例如让颜色变亮或变暗），浮点数在计算中更为有效，而不是将颜色值压缩成24位整数格式。

3. 物理学和视觉系统：

   • RGB模型适用于计算机图形，因为人眼对红、绿、蓝的感知最为敏感。这也解释了为什么RGB模型在计算机图形中如此常见。
   • 实际上，颜色是由不同波长的光组成，红绿蓝只是我们人眼所能感知的最基本的颜色信号。

4. 与百分比的关系：

   • 当你谈到“0到1的范围”时，这是一个常见的标准化过程，用来处理诸如百分比之类的量。例如，0.75代表75%。
   • 通过标准化，你可以将任何实际的量转换为一个简单的0到1范围，从而便于数学运算和后续的应用。

5. 应用实例：

   • 你还提到了如何使用标准化值来处理实际问题，比如你用斑点狗的例子来说明如何根据比例计算数量。

通过标准化到[0, 1]范围，我们可以方便地进行各种数学运算，不论是颜色处理、物理模拟还是其他基于比例的计算。这种方法在图形编程、图像处理和物理仿真中都非常常见。

实际应用浮点颜色

这个过程的核心是处理颜色值的转换与表示。首先，颜色通常使用RGB模式表示，其中每个颜色通道（红色、绿色、蓝色）通常由8位（即一个字节）组成，值的范围从0到255。目的是将浮动的颜色值（通常在0到1之间）转换为整数（0到255）以便于计算机处理。

主要步骤概述：

1. 颜色值的浮点表示：

   • 假设颜色值在0到1之间，例如 r, g, b 都是浮动值。为了转换为整数格式，需要将这些值乘以255。这样，如果 r 是0.9，经过转换后，r 的值就变成了 0.9 * 255 = 229.5。通常，这个值会经过四舍五入，得到一个整数值（在这个例子中为 230）。

2. 四舍五入与截断：

   • 四舍五入通常比直接截断更为准确，因为直接截断会导致一些颜色细节的丢失。通过四舍五入，可以更准确地保留颜色的细节。例如，0.9 转换为 229 或 230 时，四舍五入会确保结果更接近原始值。

3. 位运算与颜色打包：

   • 每个颜色通道（r, g, b）都需要经过位移和位与操作来将它们合并为一个单一的整数（32位整数）。例如，红色通常位于高位（24到16位），绿色在中间（16到8位），蓝色在低位（8到0位）。通过位移操作，可以将每个颜色通道的值合并为一个完整的颜色值。

4. 颜色值的处理：

   • 计算出每个颜色通道的整数值后，需要将它们按位组合成一个32位整数。例如，将红色的值左移16位，绿色左移8位，蓝色直接放在低位。最后使用按位或操作将它们合并成一个完整的颜色值。

5. 颜色显示：

   • 通过上述步骤处理后，颜色值就可以正确地传递给渲染系统，用于屏幕上的显示。可以通过修改RGB值（如使颜色变暗或调亮）来动态调整颜色。

6. 结果：

   • 经过这些处理后，颜色值变得易于处理、理解和显示。例如，通过简单的调整RGB值，可以轻松地实现不同的颜色效果，像是让颜色变亮或者改变颜色的色调（例如将绿色偏黄）。

总的来说，这一过程就是将浮动的颜色值转化为整数，并且确保它们可以被有效地存储和显示，同时保持颜色的精确度。

展示我们可能需要提取的一些结构体

1. 颜色处理的复杂性：

   • 在处理颜色时，传递单独的红色值可能并不常见。通常，颜色值会与绿色和蓝色一起传递。这种现象暗示了在颜色的操作中可能存在一些共性和结构，反映了处理颜色时的相关性。

2. 游戏架构的低层次设计：

   • 讨论了游戏架构的一些低层次设计，提到了一些结构开始显现出来。虽然目前只是初步的设想，但这种低层次的架构设计很可能会成为后续开发的基础。

3. 构建结构体的必要性：

   • 提到可能需要构建一个结构体来封装颜色的概念，以简化传递颜色数据的过程。这种方法将减少频繁传递单独的颜色分量（如红色、绿色、蓝色），从而提高代码的可维护性和清晰度。

4. 颜色操作的抽象：

   • 当进行颜色操作时，应该逐渐形成一种模糊的概念，即对颜色进行的一系列操作。这些操作应该能够与颜色对象直接相关联，避免重复传递和手动管理颜色的各个分量。

5. 逐渐展开的架构思路：

   • 设计的低层次架构正在慢慢显现出来，尽管目前还没有做出太多具体的实现，但可以看出，这些架构设计思路对后续开发将会非常重要。包括矩形操作等，也展示了设计中低层次的架构可能会如何逐步展开。

6. 思想的积累：

   • 通过当前的设计思路，开始有了更多关于如何在低层次架构中处理颜色、矩形等概念的想法。这些思考为未来开发中涉及低层次架构的部分奠定了基础。

总体来看，虽然目前的讨论仍处于设想阶段，但已经可以看到，颜色操作和矩形操作可能会成为设计低层次架构时的核心元素。设计者正在逐步思考如何将这些概念抽象化，并在架构中实现它们，以便提高代码的可扩展性和易维护性。

开始制作基本的瓦片地图

在这段对话中，讨论了如何创建一个简单的瓷砖地图，并通过调试过程验证其功能。以下是详细总结：

1. 设计一个简单的瓷砖地图：

   • 目标是创建一个基础的瓷砖地图，可以在屏幕上绘制。设定了一个尺寸为 16x9 的网格，表示一个简单的地图。通过这种方式，目标是建立一个能够显示基本元素的基础框架。
   • 最初思考的尺寸是 16x9，灵感来自于过去游戏中使用的地图大小，最终决定采用这个尺寸来代表一个简单的地图结构。

2. 数组的使用：

   • 使用一个 16x9 的数组来表示地图上的瓷砖。每个数组元素代表一个瓷砖的位置。这个数组结构将用于存储和处理地图数据。
   • 讨论了数组的语法及其如何在内存中按顺序排列。每行有 16 个元素，每列有 9 个元素。

3. 调试和验证地图的绘制：

   • 为了验证地图的正确性，使用了紫色背景进行屏幕清除操作。紫色作为调试颜色，方便查看是否存在正确显示。
   • 通过手动输入地图数据，可以验证地图是否按预期绘制，并且检查是否存在任何错误或显示问题。

4. 迭代和进一步开发：

   • 计划通过迭代操作对整个地图进行修改或更新，以便调整地图布局和展示效果。迭代操作是逐步改进地图的关键步骤之一，确保每一部分都能正确地显示和运行。

5. 地图的基础结构：

   • 瓷砖地图是非常简单的，只是通过输入一些基本的数字来表示地图中的瓷砖。随着开发进程，可以在这个基础上逐步扩展和添加更多的功能。

6. 使用背景清除进行调试：

   • 通过简单的紫色背景清除操作，确保地图绘制的每一步都能得到正确验证。这是一个调试方法，帮助确认地图是否正常工作。

总结来说，这段内容讨论了如何创建一个非常基础的瓷砖地图，并通过调试和简单验证确保它的正确性。通过数组来表示地图，并使用背景颜色来帮助调试，确保每个元素都能够正确显示。这个过程为未来的地图扩展和功能添加奠定了基础。

循环遍历瓦片地图进行绘制

在这个过程中，首先考虑的是如何绘制一个城市地图（或任何类型的网格地图）并将其呈现在屏幕上。目标是简化实现过程，并且不考虑代码的整洁性、性能优化或潜在的错误，重点仅在于能否快速地在屏幕上显示一个简单的地图。

主要步骤和思考：

1. 地图的行列：

   • 设定地图的尺寸，通常是9行16列（这是一个示例值，实际的行列数量可以调整）。
   • 每个单元格（“瓷砖”）的大小是固定的，比如100x100像素。

2. 绘制基础功能：

   • 使用简单的矩形函数来绘制每个瓷砖，矩形的颜色基于其ID进行设置。
   • 如果ID为0，则绘制灰色（表示一个空地），如果ID为1，则绘制白色（表示另一种类型的瓷砖）。

3. 网格偏移量：

   • 为了在屏幕上呈现地图时能够控制起始位置，可以设置偏移量。通常，地图的左上角会有一些空白边界，使得地图不直接贴近屏幕的边缘。
   • 例如，假设起始位置为 (10, 10)，即地图从屏幕的第十个像素开始绘制。

4. 显示大小与比例：

   • 瓷砖的宽度和高度可以根据需要进行调整。可以调整瓷砖的大小，调整显示比例，如使用50像素宽的瓷砖，或者尝试60像素。
   • 如果瓷砖太大或太小，可能会影响地图的可视效果，因此在设计时需要注意这些调整。

5. 设计考虑：

   • 游戏地图的设计通常受到旧游戏的影响，例如经典的《塞尔达传说》游戏，其地图比例为4:3。随着现代屏幕的变宽，可能需要考虑新的比例，例如16:9。
   • 在不同设备上展示地图时，可能需要调整瓷砖的显示方式，确保它适应不同的屏幕尺寸和纵横比。

6. 逐步开发和调整：

   • 最初的探索代码主要是为了快速实现地图的显示，接下来可以根据需要调整瓷砖的颜色、大小、边距等。
   • 在完成初步设计后，可以逐步加入更多的功能，如门的设计、路径的规划等。

总结：

这段探索性代码的核心目的是通过简单的矩形绘制和颜色填充，快速显示一个城市地图或其他类型的网格地图。在初步实现后，可以根据具体需求进一步调整显示效果、地图大小、瓷砖的设计等方面。

将玩家角色显示到屏幕上

1. 游戏状态与玩家初始化：

   • 游戏状态（game state）通常包含玩家的位置数据，如 player x 和 player y。
   • 初步的设计思路是在屏幕上绘制玩家时，使用 x 和 y 坐标来确定玩家的位置。
   • 玩家角色本身被表现为一个矩形，其位置由玩家的坐标决定。可能会根据情况调整宽度和高度。

2. 玩家精灵的绘制：

   • 画出一个玩家矩形时，要考虑玩家精灵的位置和它与屏幕上其他元素（如墙壁）的互动。
   • 重点在于玩家的中心位置，而非精灵的边缘，特别是处理碰撞时，应该根据玩家矩形的底部或中间位置来判断碰撞。

3. 地图与碰撞检测：

   • 假设游戏中的世界是由瓦片（tile）组成的二维网格，玩家只能在未被墙壁占据的地方移动。
   • 玩家精灵可能会在精确碰撞检测时穿越墙壁，这时需要计算精灵的中心位置和判断它是否超出了墙壁的边界。

4. 图形基础概念：

   • 初学者在开发图形时，可能会觉得挑战较大，因为需要将位置、大小、中心等概念理解清楚，并根据这些数据来绘制和调整图形。
   • 使用基本的图形方法，例如绘制矩形和判断中心点的位置，是解决这些问题的常见方法。

5. 调整精灵位置：

   • 为了使精灵与地图的关系更清晰，可能需要调整精灵的位置，以避免精灵与墙壁发生重叠。
   • 可以通过调整精灵的左上角或中心位置，并考虑到精灵的宽度和高度来实现这一点。

6. 玩家控制与输入：

   • 控制玩家移动的基本思路是通过键盘输入（数字键控制）来改变玩家的位置。
   • 目前处理的是数字输入，模拟运动或更复杂的输入方式（如模拟摇杆或触控）暂时不处理。

7. 程序结构与存储：

   • 游戏状态中的位置数据和控制逻辑是分开的。通过存储玩家的坐标并在每一帧更新这些坐标，可以实现角色的移动和显示。
   • 这种方法对初学者来说是一个入门级别的实现，随着经验的积累，开发者将能够更加灵活地管理复杂的游戏状态。

总结来说，这是一个关于如何在游戏中实现基本玩家绘制和控制逻辑的讨论，包括如何用坐标系统管理玩家的位置，如何处理与游戏环境（如墙壁）之间的碰撞，以及如何通过用户输入（如键盘）控制玩家的动作。这些基本概念和代码结构是游戏开发的基础。

基本角色移动

首先，讨论了玩家的运动控制。通过修改 PlayerX 和 PlayerY 来处理玩家的移动，通过控制器输入来控制玩家上下、左右的移动。此时，玩家的移动由增量（delta）控制，其中：

• PlayerX delta：表示玩家在水平方向上的位置变化。玩家向左移动时，PlayerX delta 为负值，向右移动时为正值。
• PlayerY delta：表示玩家在垂直方向上的位置变化。玩家向上移动时，PlayerY delta 为负值，向下移动时为正值。

对于移动输入的处理：

• 如果玩家向上移动，PlayerY delta 为负值；向下移动时，PlayerY delta 为正值。
• 如果玩家向左移动，PlayerX delta 为负值，向右移动时为正值。

这些增量用于更新玩家的位置，从而让玩家在屏幕上移动。通过这样的增量控制，可以实现玩家的平移。

随后，谈到了实现帧速率和玩家的运动速度。虽然玩家在当前实现中移动得比较慢，但这个速度并不问题，特别是因为帧速率尚未被打印或检查出来。帧速率是影响玩家移动速度的一个重要因素，因此计划在后续通过打印帧速率来进一步调试和调整运动表现。

整体上，控制器输入处理和运动更新逻辑非常基础，目的是先实现玩家在屏幕上的简单移动，不涉及复杂的物理或者动画效果。

调试玩家移动缓慢的问题

上面的内容探讨了玩家精灵在屏幕上的运动，并讨论了帧速率对移动速度的影响。基本的思路是，玩家精灵的移动是基于帧速率进行计算的，也就是说，每一帧更新时，玩家位置会根据按键输入的方向（如上、下、左、右）进行更新。

主要概念与分析：

1. 帧速率和移动速度：

   • 每一帧的更新会移动玩家精灵一定的像素数量。假设每秒30帧，玩家每帧移动1个像素，那么每秒玩家将移动30个像素。
   • 如果帧速率提升到60帧每秒，那么玩家会在游戏中移动得更快（每秒60个像素），这显然不符合预期。

2. 问题所在：

   • 为了解决这个问题，提出了使用“时间增量（dt）”来规范化移动速度。通过乘以dt值，可以根据经过的时间动态调整移动的距离，避免依赖于固定的帧速率。
   • 这意味着即使帧速率不同，移动的速度仍然保持一致。

3. 引入dt（时间增量）：

   • dt表示每帧所经过的时间（以秒为单位），乘以玩家应移动的距离，可以确保无论帧速率如何变化，玩家每秒的移动速度保持不变。
   • 通过将移动量（如1像素每帧）与dt相乘，就能计算出每秒应移动的像素数。这样可以保证在不同帧速率下，玩家的运动速度是平滑和一致的。

4. 调整速度：

   • 如果想要玩家移动得更快，可以通过增加每秒移动的像素数量，比如设置为128像素每秒，这样即使帧速率变化，玩家依然能维持预期的移动速度。
   • 通过调整dt和乘以合适的移动量，能够控制玩家精灵的速度，使其在不同帧率下仍然具有一致的表现。

5. 速度和流畅度的关系：

   • 在具体实现中，可能会遇到帧速率过低或过高的情况，这会导致移动不平滑或不一致。例如，如果帧速率低于预期，移动会显得不流畅，导致游戏体验下降。
   • 通过调试dt和其他参数，可以解决这些问题，使得运动更加平滑。

6. 帧速率的实际影响：

   • 讨论中提到，如果帧速率达到预期，动画和运动应当是平滑的。但是由于某些技术限制，可能会出现显得不稳定或者不一致的情况。调整帧速率和时间计算方式，有助于改善这一现象。
   • 尽管游戏的帧速率设定可能影响流畅度，但通过合理的计算和调试，最终可以实现一个更稳定的运行效果。

7. 调试和问题排查：

   • 代码中的潜在问题可能与帧速率的测量和时间增量的计算有关。如果某些值没有正确传递或计算，可能导致玩家的运动速度看起来不符合预期。这需要通过打印调试信息、检查时间增量的计算和单位转换等方式来排查。

总结：

游戏中的精灵移动速度与帧速率直接相关，因此需要通过适当的时间增量（dt）调整来确保移动速度的稳定性和一致性。通过引入dt和正确的乘法运算，可以避免帧速率变化导致速度不一致的问题。此外，帧速率的提高和时间增量的合理使用，可以使得游戏运动更加流畅。

Sleep() 是否还在导致我们错误计算帧率？

讨论的内容集中在如何解决帧速率（FPS）问题，尤其是由于睡眠机制（sleep）导致的帧率不稳定。首先，提到如果睡眠代码过度“休眠”，可能会导致帧率异常，进而影响游戏的表现。为了解决这个问题，提出了两个选择：一是调整睡眠时间，二是完全去除睡眠代码。这两者都是尝试优化帧率并保证游戏流畅运行的方法。

接着，考虑到睡眠机制本身可能是造成问题的根源，因此建议可以将睡眠处理的粒度降低，或者干脆移除睡眠机制（例如通过设置 SleepIsGranular = false）。尽管在代码中做出这些调整后，帧率问题并没有得到有效改善，依然存在不稳定现象。

进一步的调试发现，问题的根本并不在睡眠代码上，而是在验证睡眠是否真正执行时，发现它并未实际发生。若睡眠代码被正确执行，应该会看到帧率的计算与时间上的延迟。由于没有正确的延时，帧率计算的结果反而是正确的，并且每帧所需的时间固定在33毫秒左右，表明程序至少能按预期的速度处理循环。

然而，虽然帧速率没有直接的问题，游戏仍然出现了帧更新的问题。怀疑这是由于“频率冲突”导致的，可能与窗口合成器（compositor）或系统的其他部分干扰有关。当前的难点是无法确定具体的干扰来源，可能与操作系统或图形处理有关，导致无法以期望的速率更新游戏帧。

最后，指出了一个可能的bug，即在处理时间增量（dt）时，仅在一个输入中设置了 dt frame，这导致更新不一致。这个bug可能是导致帧更新问题的根本原因。需要进一步检查并修正，确保两个输入的 dt 设置一致，从而保证游戏的正常运行。

总结来说，当前面临的问题是帧率不稳定，可能的原因包括睡眠机制的误操作和时间增量的设置错误，需要进一步排查操作系统层面的问题，并修复代码中的bug，以确保帧更新顺利进行。

dtForFrame 只在一个输入中使用?

修复一下之前代码的遗漏

也许我们应该使用垂直同步（vsync）来同步帧率，因为它会丢帧

存在一个问题，可能需要降低刷新率来解决。在使用Windows系统时，可能会遇到框架丢失的情况，导致运动不稳定。系统可能丢弃一些帧，这会导致画面出现卡顿或者不流畅的现象。

目前，虽然意识到这个问题是存在的，但并没有找到一个合适的解决方法。计划是在某些条件下（比如迁移到某个特定的环境）再解决这一问题。此时，可以借助一些特定的技术或方法来应对，然而目前还不确定如何实现这一目标。

有一种可能的解决方案是通过直接调用绘制命令来控制刷新率，但不清楚这种方法的支持程度如何。

最终，计划转向使用OpenGL技术来解决这个问题，因为OpenGL提供了一些自动化的工具，能够帮助实现所需的效果，确保刷新率和帧数的同步。然而，在此之前，无法确定该如何在当前环境下解决这个问题。

关于瓦片地图大小，是否应该使用较小的瓦片，再用两个瓦片做门

讨论了城市地图的瓷砖大小问题。建议使用更小尺寸的瓷砖，并确保两边的瓷砖数量是偶数，这样可以在中间部分设置门。不过，这个方案并未能完全解决问题，因为门的尺寸并不是问题的核心。实际的问题出现在16:9的显示比例上，而不仅仅是瓷砖的数量。如果想要瓷砖保持方形，存在一个方向上是奇数块，另一个方向则是偶数块的情况，这种布局可能不利于设计。因此，单纯调整瓷砖大小并不能完全解决问题。

为什么不使用之前创建的东西，比如 SDL、OpenGL 等（新人的问题）

讨论的核心是为什么不使用现成的引擎或工具，像是OpenGL、SFML、Allegro、Unity等。主要原因是，这个项目的目标是从零开始构建一个游戏，而不是使用别人开发的工具或引擎来“拼凑”一个游戏。虽然Unity等引擎可以简化开发，但它们也限制了对细节的控制，开发者不一定清楚每个工具或库是如何工作的。使用现成工具时，当遇到问题时，可能不知道如何修复或优化，且这些工具的内部细节可能会影响游戏性能。

该项目的宗旨是完全自给自足，亲自构建每一个组件，理解每个环节的工作原理。通过这种方式，开发者能够深入理解游戏开发的各个方面，且能在使用第三方工具时，主动修复问题、提高性能，或根据需要决定是否继续使用它们。最重要的是，开发者有能力在认为某些工具不适合时，自己实现更好的解决方案。

目前，游戏开发工具并不完美，因此，使用现成工具并不是最佳选择。

固定点还是浮点？

讨论的核心是关于固定点与浮动点计算的选择。固定点运算在过去的一些系统中可能有优势，尤其是在处理能力有限的硬件上，因为它不需要像浮点运算那样复杂的处理。然而，在现代硬件上，使用固定点运算通常会带来性能损失。现代处理器特别是浮点硬件，优化了浮点数的处理，因此使用浮点运算会更加高效。

如果坚持使用固定点计算，可能会在某些情况下获得双倍宽度的处理能力，但这通常并不容易实现，且仍然受到32位系统限制。因此，固定点运算并不是一个理想的选择，尤其是在现代硬件上，最终会付出额外的性能代价。

总的来说，使用浮点数是更为合适的做法，因为它能提供更好的性能和更高的灵活性。

60fps下每帧4个像素不会显得有点卡顿吗？

讨论中提到，期望在30 FPS下每帧移动4个像素会导致画面有些不稳定，但实际情况是，修复了之前的bug后，画面看起来非常平滑。虽然偶尔可以看到一些频率的变化，这可能是因为系统不完全同步；此外，当画面四舍五入时，也会出现像素精度的变化，这个问题可以通过改进来解决，从而改善画面效果。

另外，提到了关于"黑客"（hacks）的一些事情，但没有给出具体的看法。提到了一个游戏，说明可以用它来开发游戏，并且对这个游戏很喜欢。

最后，明确表示每帧只移动一个像素的行为应该停止，因为这种方式容易引起画面的“卡顿”或“跳动”现象，解决这一问题已经在前面讨论过。

昨天你讨论了探索性编程。你如何将它与敏捷开发风格进行比较？

在讨论敏捷开发和探索性编程时，主要提出了对“敏捷开发”这个概念的不同理解。敏捷开发的核心思想通常是避免过多的前期设计，强调快速响应变化和提高生产力。然而，问题在于敏捷开发并没有明确解释为什么要避免某些设计方法，而更多的是关注如何做得更快或者如何避免某些步骤。

如果可以正确地设定规划和目标，软件规划会非常有用。但如果规划的步骤不能有效地完成，那么传统的敏捷开发方法就可能无效。进一步地，尽管敏捷开发有其优点，但这些优点与他自己对于开发流程的理解有所不同。他更关注在开发过程中如何理清为什么某些步骤不应该进行，而不仅仅是通过方法论来提高生产力和响应速度。

整体上，尽管他没有完全否定敏捷开发，但他更倾向于通过自定义的方式处理开发中的规划和步骤，而不是盲目地遵循某些流程，尤其是在无法设定明确目标时。

拖延症对你来说是个问题吗？

主要问题是拖延症及其对开发过程的影响。当面临困难的任务时，拖延症通常让人选择去做更容易的事情，这种趋势普遍存在。解决拖延症的关键是坚持每天做一点编程工作，即使每天只能做一两个小时。这可以帮助避免任务停滞，并逐步克服拖延症。

如果每天强迫自己进行少量的编程工作，就算这段时间的编程可能没有实际效果，依然能保持进展。通过这种方式，甚至在感到无效的情况下，逐渐完成任务是可能的。重要的是保持连续性，不让拖延占据主导地位。如果停下了编程，就容易陷入无休止的拖延之中。因此，保持每天编程的习惯，无论任务多么困难，都会有所进展，最终找到推动项目前进的关键。

另外，提到了一个有关编程语言的问题，提问者选择了C语言，但觉得它有些困难，认为C++相对更容易。这个问题的回答认为，这是一个比较个人化的问题，通常在一开始就会有人提出类似的问题，但通常还是应该把焦点集中在当前的任务上，而不是过多地讨论其他语言的选择。

所有的打印输出会导致输入延迟吗？

打印输出本身并不会对帧率产生显著影响，尽管这些打印输出应该去除以提高程序的效率。尽管机器有足够的计算资源处理这些输出，它并不会成为性能瓶颈。实际上，帧率问题的根本原因并非来自打印输出，而是由于没有正确设置dt（帧时间增量）。这个问题已被解决，并且已经确定了问题的根本原因。

此外，还提到了一些关于同步的问题，但这些问题并没有对整体帧率造成影响，已经得到解决。所以，问题的关键在于正确的dt设置，而不是打印输出或其他外部因素。

除了方便使用之外，设置瓦片为正方形有其他原因吗？

选择使用正方形瓦片的主要理由是便于玩家理解和推理。正方形瓦片使得玩家可以很容易地预测在特定时间内，向上或向左移动时，角色会穿过相同数量的瓦片。这种设计简化了玩家的操作体验，使他们能够更直观地理解游戏中的移动规则。

虽然从代码实现的角度来看，可以选择任何形状的瓦片，但正方形瓦片的设计有助于玩家的认知，增强了游戏的可操作性。尽管如此，这也可能只是个人的设计偏好，并不意味着这是唯一的最佳选择，但从设计的角度来看，正方形瓦片是一个合理的选择。

原文地址：https://blog.csdn.net/TM1695648164/article/details/144159208

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！