简介

使用本系列文章所描写的iPhone游戏引擎开发的首款游戏是《Monster Bowling》，它已经在圣诞前发布于App Store。（点击此处阅读文章第一、二、三部分）

Monster Bowling(from altdevblogaday)

你可能会好奇为何成品游戏与早前呈现的游戏截图（游戏邦注：即玩家需要控制着一艘船去探索世界的冒险游戏）不一样。因为之前参与该项目的人员失去了最初的创作激情，并退出了项目开发。但我不希望自己投入努力而创造出的引擎白白浪费（即未能基于该引擎创造游戏），我便与另外一名美术人员合作并最终创造出《Monster Bowling》。我花费了9个月的时间编写引擎和工具，并且在后来6个月中利用空闲时间里编写游戏代码，现在看来我真的为这款游戏投入了非常多的时间。

不足之处

以下我将总结我们在这两个项目中所犯的错误：

首先，船舶游戏项目的失败原因在于游戏规模过大。尽管我们在制作过程中已经删减了一些内容，但是仍然有太多需要费心的内容，并因此抹灭了团队成员的激情。所以我建议那些利用业余时间制作游戏的人，特别是与别人首次合作之时，千万不要轻易尝试制作大型游戏。如果团队中有任何成员失去了创作激情，那么不论你付出了多少努力，都不可能完成游戏创作。

Monster Bowling (from altdevblogaday)

其次，船舶游戏失败的另外一个原因是开发团队缺少清晰的方向，未能明确游戏的发展，时间安排以及检查列表。如果缺少明确的目标，团队成员便很容易迷失方向，并失去激情。

第三点是关于《Monster Bowling》的发行；游戏刚发行时销量并不是很好。因为我们的开发团队中只有1名美术人员和1名程序员，我们将全部的精力都投入游戏开发但而忽略了市场营销，以及宣传游戏的时机。所以游戏在刚刚发行时并未出现任何能够提高销量的评论。

第四，引擎中的技术性问题。在引擎中，游戏执行时间和编辑器会使用相同的文件格式，即二进制格式。但是这导致我们很难合并文件，就像如果2个人都修改了游戏关卡中的物体，我们便很难整合这个过程中产生的变化。幸运的是，我们的团队规模不大，并且我们只需避免同时编辑相同文件就行，这就不会影响项目的整体发展。

可取之处

谈论了错误之处后，我想也应该分享一些我们所做出的正确决定。

首先，在制作《Monster Bowling》期间，我们的团队内部总是进行各种交流。每隔1周或2周的时间我们便会讨论关于游戏的进程。这点对于那些利用休闲时间制作游戏的人来说尤为重要，因为通过讨论游戏，我们能够保持激情，并让团队成员掌握游戏项目的发展过程。

其次，制作编辑器以及Mac版本的游戏决定都很重要。因为这么做让美术人员能够脱离程序员而独立创造并测试游戏关卡。尽管编辑器并非用户友好型工具，美术人员仍建议添加一些自己能够承受的最低功能集（如在3D视口中添加变焦功能以拉近物体）而提高工作效率。明确地说，那些缺失的功能能够帮助程序员真正改善自己的工具。

游戏所使用的关卡编辑器(from altdevblogaday)

第三，在游戏中植入脚本语言非常有帮助。比起使用C++，在Lua中编写游戏玩法代码更加有效。并且，修改脚本文件也比编辑C++代码快得多，因为它的迭代速度更为迅速。除此之外，脚本语言能够明确区分引擎代码和游戏玩法代码。多亏了Lua，我们在从船舶游戏到《Monster Bowling》的转变中并不需要过多修改引擎代码。

使用Lua创建的《Monster Bowling》测试关卡(from altdevblogaday)

第四，我们坚持从头开始编写引擎，包括内存管理，渲染代码，动画等。我一直在使用的一些开放源码库包括：Bullet physics library，Lua以及SOIL（用于解压PNG纹理）。我之所以会坚持使用这些源码库是因为我希望借此学习如何创建一个能够与不同模块相互作用的引擎。并且，我也不擅长物理和脚本语言，所以如果要自己编写物理库和脚本语言将会花费更多时间，并且最终创造出来的代码可能也没有Bullet或Lua那般有效。所以我便选择了具有源代码的开放源码库，从而帮助我更轻松地进行调试。

结论

这次的iPhone游戏引擎项目共花费了我们1年又3个月的时间，并且我们也最终创造了一款完整的游戏。尽管我们只有一名程序员，但是我们合理利用了开源码库，并且我也割舍了最喜欢的图像编程以减少我们的工作负荷。我认为编写了引擎但却不制作游戏实在太荒唐了，所以我便决定使用该引擎创造出《Monster Bowling》。不过从船舶游戏的转变的确浪费了我们之前所付出的一些努力（如游戏世界关卡流动传输）。所以对于那些只是单纯地想创造一款游戏的人来说，他们可以授权使用一些现有的商业引擎，如Unity或UDK，而不是自己花大量的时间编写引擎。但是对于我本人来说，编写引擎能够让我学习到更多知识并感受到更多乐趣。

游戏邦注：原文发表于2011年12月31日，所涉事件及数据以当时为准。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Writing an iPhone Game Engine (Part 7- Postmortem)

Introduction

The first game that made with the iPhone game engine described in this series is released before Christmas on App Store, it is called Monster Bowling.

You may surprise that the final product is different from the screen shots shown before which is an adventure game that controlling a ship to explore the world. This is because someone in that project lost his passion and the production of that game has been stopped. And I do not want to waste my effort on making an engine without producing any game, so I decided to work with another artist which resulted in Monster Bowling. The engine and tools took me 9 months to write and the game code took me another 6 months of spare time to complete, which is quite a long time…

What we did wrong

Here I will summarize what mistake we have taken in these 2 projects.

First, the ship game project failed because the scale of the game is too big. Although some of the content is cut during production, there are still too many things need to take care and the team member gradually lose their passion about the game. So, my advice of making a game in spare time, especially when you work with other people the first time,  is don’t try to make a big game. If anyone in the team lose their passion, the game will never get shipped no matter how hard you work.

Second, the other reason why the ship game failed because there is no a clear direction in the team, how the game project should progress and a clear schedule and check list what should be done. Without a direction, the team member will easily get lost and lost their passion.

Third, this point is about the released game Monster Bowling. When the game was just released, the sales was not good. It is because within this team, there is only 1 artist and 1 programmer, both were putting most of their effort on developing the game and didn’t pay much attention to marketing the game and let the public know about the game. So when the game was just released, there didn’t have any game review to boost the sales up.

Fourth, this point is about technical issue within the engine. Within the engine, both the game runtime and the editors use the same file format which is a binary format. But doing in this way resulted in a problem which cannot merge the files, for example, when the game objects within a game level are modified by 2 people, we are not able to merge the changes. Luckily, as our team is small, we just do not edit the same file at the same time which does not cause a great trouble in the project.

What we did right

After talking about the mistakes, I will talk about some decisions that I think is made correctly.

First, during the production of Monster Bowling, there are constant communication within the team. We talked about the progress of the game every 1 or 2 weeks. This is very important for those who make games in their free time because through talking about the game, we can keep the passion and let other team member know what are going on in the project.

Second, the decision of making editors and Mac version of the game is important. This enable artist to build and test the game level without any programmer interaction. Although the editors are not user friendly, the artist would suggested to add the minimal set of features (e.g. adding zoom extend to objects in the 3D viewport) that he can live with so that he can work in a much faster way. Explicitly saying what features are lacking will help the programmer to improve the tools.

Level editor used to build the game

Third, embedding a scripting language to the game engine is useful. Writing game play code in Lua is much faster than using C++. Also modifying the script file is much faster than compiling C++ code which can have a faster iteration time. Also scripting language can draw a clear separation between engine code and game play code. Thanks to Lua, when migrating from the ship project to Monster Bowling, there does not have much to change in the engine code.

Test level of Monster Bowling which built using Lua

Fourth, as the engine is written from scratch starting from memory management, rendering code, animation. I still use some open source library: Bullet physics library, Lua and SOIL (for decompressing PNG texture). I use them because my goal is to learn how an engine should be architected to interact with different modules. Also I am not strong at physics and scripting, writing my own physics library and scripting language will take a long time and the code would not be as fast as Bullet and Lua. So I choose to use some open source library which have source code so that it is easier to debug.

Conclusion

This iPhone game engine project took a total of 1 year and 3 months of spare time to complete and produced 1 game. As there is only 1 programmer, Some open source library are used and I decided to sacrifice my favorite graphics programming(the engine doesn’t perform lighting and using texture color only) to keep the work load low. I think that it is ridiculous to write an engine without making any game, so I worked on Monster Bowling using this engine, but there are some effort is wasted (i.e. world level streaming) when migrating from the ship project. So if someone just want to focus on making games only, I would suggest they license a commercial engine such as Unity or UDK rather than writing their own engine which will cost a large amount of time. But for me, writing my own engine is to learn and most important is for fun.(source:altdevblogaday)