作者：Inna Treyger

来自Glitch Games工作室的开发者Craham Ransom与Simon Pearce在Twitter上回答了粉丝提出的一系列有关冒险游戏的开发问题，他们在此分享了其中一些最受瞩目的问题及相应答案。

@gtatarkin：制作一款游戏需要多长的时间呢？

Graham：其实，各个项目所需的开发时间各不相同，因此我们无法给出一个确切答案，但我们可以谈下游戏的开发经验。

比如，我们在48小时内首次尝试制作出冒险游戏《The Hauntening》，当时是在The Techority 48 Hour挑战赛中完成的，然而，我能够肯定该作与《Forver Lost》的完整特性大不相同。

forever-lost-episode-1-(from appaddict.net)

《Forever Lost》大概耗费了我们6个月的制作时间，但我们也在其它三款较小型的应用中投入相同时长。在这6个月内，我们确定了美术风格、开发了基本框架，尽管如此，我们希望可以在较短时间内开发出《Forever Lost》的第二章。

假如我被迫回复一个明确答案，我认为至少需要安排6个月的时间，才能保证自己制作出一款完美、长时的游戏，假如你是个只有1到2名成员的小型团队。

@ftsirigotis：如何有效利用存储系统？

Graham：我们采用相对简单的系统，我们既不需要组合物体，也不用放大道具图片，我觉得简单一点或许效果更棒。

我们作品中包含的一系列物体都可以存储在一个文件夹内。我们使用JSON保存单个物品的所有信息，比如名称、描述、物品被选择后呈现的文本，以及包含所有图标的精灵图画帧数。

同时，文件夹中也包含实际库存条的定义，以及便于我们改变外观与效果，并且不需要输入任何代码的HUD按钮。

当玩家收集某个道具时，他便能启动各种事件，这需要各个系统获得信息通知，而后作出相应行动。

其中一个是存储系统，它需要了解道具的ID号码，借此查阅所有必要信息，从而展示道具。

接着，所有当前收集的道具会永久保存在GGData盒中，该系统还会根据道具的使用顺序进行分类，所以，最先使用的道具总排在首位。

我们只在存储系统中陈列某个时刻使用的道具，而玩家只能通过拉动左右滚动条才能看到更多道具。实际上，这样做是为了更新展示出来的道具，摧毁先前的道具，因此，玩家可以无限制地收集道具，但不能出现降级情况。其实，如果你已经在库存中存储了大量道具，你可能想要通过更棒的方法操控它们，我们会在下款游戏中考虑这种做法。

@theDaveB：你们如何绘制图画？

Simon：Glitch Games创建之初，我们都是先手工绘制原创图画，扫描到电脑内，然后利用Photoshop做一些改进。我们头几款应用便采用这种方法，其中包括《The Hauntening》。在我看来，这是一种全新的绘图方式，因为先前我主要采用3D造型软件绘制图画。我们根本不可能在《The Hauntening》制作中使用3D软件，因为那是一场48小时的比赛，3D绘图所需的时间远远多于2D绘图。最初，我们在《Forever Lost》中融合手工绘图与Photoshop的真实纹理处理，但不久之后，我们意识到自己更需要灯光与阴影效果，为此，我们采用3D绘图。我们坚持这种创作风格，因为它既与现实结合，而且还设置了紧密连接的沉浸式关卡。我们利用3D软件塑造了几乎所有的视觉元素，然后添加免费下载的纹理，而后在2D编辑软件中进行相关操作。

@theDaveB：你在其它系统（比如Atari ST、Amiga等）上玩过2D冒险游戏？

Graham：我是伴随LucasArts与Revolution的游戏长大，一直以来，我最喜欢的游戏是《Monkey Island 2》。然而，它们都是PC版本游戏，我还从未在老式主机上真正体验过游戏。

最近，为了进行相关研究，我在iOS平台上体验了大量游戏，我还回顾了Kickstarter工作室开发的《Double Fine Adventure》与《Broken Sword 5》。同时，我也十分喜爱偶像Ron Gilbert开发的《The Cave》。

Simon：我的首次冒险游戏之旅始于“选择你的冒险”书籍，我想，是它们把我带进冒险游戏世界。与Graham一样，我也从未在主机上真正体验过2D版的冒险游戏，但我记得小时候曾在PC上玩过《神秘岛》，当时我还十分着迷这款游戏。

最近，我也在iOS平台体验了大量冒险游戏，而且我发现其中的大量价值。冒险游戏的复兴着实让我感到兴奋，而且我也十分满足自己能在有生之年至少创作出一款游戏。

@davidcondolora：该如何利用Corona SDK出色地处理冒险游戏的寻径方法呢？

Graham：在《Forever Lost》中，我们并未设置任何寻径方法，因为玩家可以透过主人公的双眼观察四周，而不是直接操纵它的行动。这是一种意识设计，玩家既可以进入游戏世界，同时还能减少游戏引擎所需的整体复杂性。

也就是说，我仍然可以有根据地推测冒险游戏中可能奏效的寻径方式。我可以肯定，这并非最佳途径，也不是唯一渠道，但它应该可以发挥作用。

我认为，最简单的解决方案便是创造一个由各个节点与路标形成的网格系统，保证角色可以在上面行走。接着，你可以计算出目前角色所处位置与其想到达的结点之间的最佳渠道。

虽然该系统具备更多功能，且通过各种细节部分形成，但它确实限制了玩家的行动，因为他只能步入一些预先设定好的位置。虽然你可以通过增加更多结点解决此类问题，但由于玩家需要查看更多结点，这不仅会耗费他们更多时间，还会减缓寻径的计算速度。

相反，我会圈出每个结点周围的多边形作为可行区域，这样，寻径代码仍可以计算出A点与B点之间的最佳路径，但角色通常会处于B点（即玩家选择/点击之处），而不是最近结点。

@faxilux：我一直疑惑如何计算出适合可行区域的多边形碰撞。这有什么诀窍吗？

Graham：计算多边形碰撞的第一原则：不要讨论多边形碰撞。

如上所述，严肃地讲，我们的游戏中并不存在多边形碰撞（或者任何形式的碰撞），因此我们可能不是回答这一问题的最佳人选，但基于体验过包含可行动角色游戏的多年经验，我们可以进行一些猜想。

假如，你得到一个类似上述问题所述的系统，那么，你真正需要的是计算出玩家在多边形中选择的点。我们可以简单地假设：你的多边形是凸状体。如果是凸多边形，你仍可以进行这种做法，但由于你已自定义这些可行区域，你只需确保它们均为凸状体，那样可以减少游戏进程的难度。

在检查自己选择的点是否贯穿可行区域后，你只会得到两种结果，其一，你无法发现适合玩家行动的区域，其二是处在可行区域内，借此，你可以利用寻径计算发现适合自己的最佳渠道。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

FAQs: Point and Click Adventure Game Development

by Inna Treyger

Graham Ransom and Simon Pearce are the dynamic duo behind Glitch Games, and the developers of Forever Lost: Episode 1 HD, a new point-and-click adventure game for the iPad/iPhone. Graham asked his Twitter followers for questions on developing adventure games, and shares answers to a handful of the most popular inquires here.

@gtatarkin: How long does it take to make one?

Graham: Naturally it will be different for all projects so we can’t really give a single answer, all we can talk about is our own experiences with our games.

For instance The Hauntening, our first experiment in adventure games, was made in 48 hours as it was for The Techority 48 Hour challenge, however as I’m sure you can guess this isn’t anywhere near as feature complete as Forever Lost.

Forever Lost has taken us around six months but we also worked on three other, much smaller apps at the same time. Those six months also include the time spent deciding on the art style and developing the underlying framework though so we hope to be able to get the second episode out in less time.

If I were forced to make a single answer, I would say you should allot at least 6 months to make a decently polished and lengthy game, assuming you are a small team of 1 or 2 people.

@ftsirigotis: Efficient Inventory System.

Graham: Our system is relatively simple, we don’t have combining of objects or enlargeable item images etc., we decided simple would probably be better.

Our’s works by having a list of all objects that can be collected in a text file. This uses JSON to store all the information about an object like its name, description, text to be displayed when picked up and the frame index into the sprite sheet that contains all the icons.

This file also contains the definition of the actual inventory bar and button used in the HUD that allows us to easily change the look-and-feel without touching any code.

When a player collects an item in the game various events get fired, these allow all the separate systems to get notified and act accordingly.

One of these systems is the inventory itself, it needs to know what the ID of the item was so that it can look up all the required info and display it accordingly.

All the currently collected items are then stored in a GGData box to allow persistence and get sorted based on the timestamp of when they were picked up so that the most recent item is first.

We only display a handful of items at a time in the inventory, requiring the player to scroll left or right to see more. All this does in practice is refresh what icons actually get
displayed and destroys the previous ones, this allows for an essentially unlimited amount of items to be collected but no degradation in performance. Naturally if you did have a large amount of items in the inventory you would probably want to develop a better way of navigating it which is something that we will be investigating for later games.

@theDaveB: How is the art produced?

Simon: When Glitch Games began, all of the artwork was hand drawn and then scanned onto a computer and then edited using Photoshop. We used this method for our first few app releases, including The Hauntening. This method was new to me since most of my previous experiences with game art was using 3D modelling software. It was not really possible to use any 3D software for The Hauntening since it was a 48 hour competition and 3D art is far more time intensive than the 2D art that we produced. We originally started this way with Forever Lost, by merging hand drawn art and real textures in Photoshop, but soon realised that we wanted to work heavily with lighting and shadows and the best way to do this was to use 3D rendered images. We decided that we liked this style because of the induced realism and correlating immersion levels so we stuck with it. We modelled almost every visual element using 3D modelling software and then applied textures downloaded from free texture websites. These were then manipulated in 2D editing software and voila.

@theDaveB: Did you play graphic adventure games on other systems (Atari ST, Amiga etc…)?

Graham: I’ve grown up playing all the LucasArts and Revolution games, my favourite game of all time being Monkey Island 2. However these were all on the PC, I’ve never really played any on the older consoles and really should.

I’ve been playing a lot on iOS recently, for research purposes naturally, and have also backed the Double Fine Adventure and Broken Sword 5 on Kickstarter. I am very excited for those as well as The Cave by my gaming idol, Ron Gilbert.

Simon: My first experience with adventure games was with the old ‘choose your own adventure’ books, which I guess was my gateway into adventure gaming. Much like Graham, I have also never really played many graphic adventure games on consoles (that was reserved mostly for RPG’s and platformers) but I do remember playing Myst on the PC from a young age and being very captivated.

I have also been playing a lot of adventure games on iOS recently, and I have discovered a lot of hidden gems. It is nice to see a resurgence of the genre and I am really happy to have worked on at least one in my lifetime.

@davidcondolora: What is a good way to do pathfinding for an adventure game with Corona SDK?

Graham: In Forever Lost we didn’t require any pathfinding as the player sees through the eyes of the protagonist rather than controls his movement directly. This was a conscious design decision that would both allow the player to be drawn into the world whilst at the same time reducing the overall complexity required for our engine.

That being said though I can still make an educated guess into how the pathfinding for an adventure game might work. This isn’t necessarily the best way and certainly not the only way I’m sure but it should work.

The simplest solution in my mind would be to create a grid-system built up of individual nodes or waypoints where the character can stand. You could then use the A* algorithm to calculate the best path between where the character currently is and which node the player wants to get to.

Although this system would be more than functional and fairly trivial to set up it would be quite limiting as the player would only be able to walk to a few pre-determined locations. You could solve this by putting in lots of nodes but that would be time consuming and would also slow down the pathfinding algorithm as it would have lots more nodes to look at.

I would instead define walkable areas which would simply be a polygon around each node, this way the pathfinding code could still calculate the most optimum path between point A and B but the character would be placed perfectly at point B (where the player tapped/clicked) rather than at the closest node.

@faxilux: What I’ve always wondered is how to do polygon collisions for the walkable area. Is there any trick?

Graham: The first rule of polygon collision is: you do not talk about polygon collision.

In all seriousness and as above, we don’t have any polygon collision (or any collision of any sort) in our game so we may not be the best ones to ask, but based on our own experience in playing games that have walkable characters we can make a guess.

Assuming you’ve got a system that is similar to the one described in the above question then all you really need to do is be able to work out of the point that the player has tapped is actually in that polygon. This is pretty simple assuming one thing: your polygons are convex. You can still do it if you have convex polygons but as you are defining these walkable areas yourself you should just be able to make sure they are all convex to make your life a little bit easier.

After checking whether your point intersects with a walkable area you will only have two outcomes, it is either not in any area in which case you disregard it as the player can’t move there, or it is in a walk-area in which case you then pass that position to your pathfinding algorithm and let it work out the best path for you.(source:coronalabs)