如何制作一款横向卷轴游戏？
我想创建一个游戏，用户可以转到屏幕的最右侧部分，如果他们继续前进，他们将滑入一个新视图。
所以基本上，如果他们在第 1 号屏幕上有 3 个怪物在追他们，并且他们一路向右并继续前进，他们将进入第 2 号屏幕，那里将有 5 个新怪物和一个新地形。
游戏开始时，我应该立即初始化每个屏幕的所有 NPC 怪物和地形特征，还是应该在每个屏幕进入时初始化它们？存储每个屏幕内容的最佳格式/方式是什么？
I want to create a game where the user can go to the right-most part of the screen, and if they go any further, they will slide into a new view.
So basically, if they have 3 monsters chasing them on screen # 1, and they go all the way to the right and keep going, they will enter screen #2 where there will be 5 new monsters and a new terrain.
When the game starts, should I initialize all the NPC monsters and terrain features for every screen right away, or should i initialize each screen as they enter it? And what is the best format/way for storing what goes into each screen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
？可以，当然没有什么可以阻止你这样做：
但这取决于你的关卡有多大以及游戏期间加载时间和延迟之间的权衡（例如，当加载下一个屏幕时）。
我建议如下：
第一：线程
创建两个并发运行的线程，一个负责实际的游戏玩法，另一个唯一的职责是加载新地形。
gameplay线程是主线程，当玩家进入下一个屏幕时，将触发loader线程加载新的地形数据。第二：减少一个地形与另一个地形之间的滞后
避免在进入下一个地形时加载它。相反，您应该做的是（对于横向卷轴），加载当前位置左侧一处的地形，并加载当前位置右侧一处的地形。这样您不需要立即将整个关卡保存在内存中，同时在进入相邻地形时永远不会遇到延迟。这与第一点配合得很好。
这也非常符合你的要求，让一个地形中的 NPC 怪物能够“跟随”你到下一个地形（如果你没有杀死它们）；需要注意的是，如果玩家连续穿过两个屏幕而 NPC 怪物没有穿过其中一个，他们就无法进一步跟随你；这就是我玩过的许多横向卷轴游戏似乎都可以工作的原因。
另请注意，这意味着当您开始一个关卡时，您必须一次加载 2 个或 3 个地形（取决于您是从关卡的边缘还是中间开始），但随后，您将只拥有一次加载一个地形，因为每次玩家前进到下一个地形时，您所要做的就是将当前地形与相邻地形交换
序列化
鉴于您选择的平台是 Java，我认为持久保存关卡数据的最有效的加载时方法是序列化。使存储有关级别和对象信息的类实现
Serialized接口。如果您选择此选项，那么当您第一次创建关卡时，您要么必须创建特殊方法来硬编码每个关卡的初始化，然后在加载游戏之前将它们序列化；或者你必须构建一个关卡编辑器。
XML
与反序列化对象相比，此选项大大增加了加载时间，但它更健壮，并且很容易进行更改。如果您的关卡不是很复杂，这可能是最好的选择。
事实上，没有什么可以阻止您将两者结合起来。
You can, there certainly isn't anything stopping you from doing that:
However it depends on how big your levels are and the tradeoff between load time and lags during the game (for example when the next screen is loaded).
I would suggest the following:
First: Threads
Create two threads that run concurrently, one that is repsonsible for the actual gameplay, and another whose only responsibility is to load new terrain. The
gameplaythread is the main one, and will trigger theloaderthread to load new terrain data when the player goes to the next screen.Second: Reducing lags between one terrain and another
Avoid loading the next terrain upon entering it. What you should do instead is (for a sidescroller), load the terrain that's one to the left, and load the terrain that's one to the right of the current position. That way you don't need to keep the entire level in memory at once, and at the same time will never run into a lag upon entering the adjacent terrain. This works rather well with the first point.
This also fits in nicely with your requirement of having the NPC monsters in one terrain being able to "follow" you to the next terrain (if you haven't killed them); with the caveat being that if the player gets through two screens in a row without the NPC monsters getting through one, they are not able to folow you further; which is how many of the sidescrollers I have played appear to work anyway.
Also note that this means that that when you start a level, you will have to load either 2 or 3 terrains at once (depending on whether you start at the edge or the middle of the level), but subsequently, you will only ever have to load one terrain at a time, because all you have to do is swap out the current one with the adjacent one each time the player advances to the next terrain
Serialize
Given that your chosen platform is Java, I would say the most load-time efficient way of persisting the level data is serialization. Make the classes which store information about the levels and the object in in implement the
Serializableinterface.If you do choose this option, when you create the levels for the first time, you would either have to create special methods to hardcode the intialisation of each level and then Serialize them before loading up the game; or you would have to build a level editor.
XML
This option increases your load times considerably as compared to deserialising objects, but it is more robust, and and is easy as hell to make changes. This is probably the best option if your levels aren't very complicated.
In fact, there is nothing stopping you from doing a combination of both.