作者：Ray Wenderlich

过去几周我都处于沉寂状态，忙于自己首款iPhone游戏的收尾工作——现在我回来了，因为游戏最终入驻App Store平台。

这款游戏的名称是《Math Ninja》，是首款iPhone教育游戏，旨在将加减乘除运算变得更有趣。

在这个过程中，我学到很多关于游戏开发的经验，我觉得你应该会对此感兴趣。

1. 进行重写不要紧

我首次编写《Math Ninja》时，游戏的代码非常糟糕。应该说是糟糕透了。我是Cocos2D新手，所以犯了很多新手错误，边编写代码边设计游戏，所以游戏的结构非常丑陋，瑕疵无处不在。

所以我在项目中间遭遇瓶颈——我是否应该就此将游戏包装起来，假设终端用户不会发现其所存在的瑕疵？或者我应该重新编写代码，沿途进行完善？现在我知道自己应该怎么做会更好。

关于这一话题的争论很多，我最终决定重新进行——主要出于自我满足和进行学习的目的。重写代码所耗费的时间是首次编写《Math Ninja》时间总量的一半，确实是非常费时间。最终是否值得？

在此显然非常值得，主要表现在如下原因：

* 总体来说，游戏搭载于一个更稳固的根基，方便我添加新功能。

* 在重写代码的过程中，我重组关卡设计的逻辑，将其放入一个简单的配置文件中，这促使游戏设计变得更加简单。

* 在重写过程中，我将更多心思投入于如何存储和保存游戏状态，这简化加载和保存过程。在重写过程中，我对游戏的运作投以更多关注，这令应用变得更具反应性。

* 也许最重要的是，我个人更满意这些结果，且因此感到自豪（而不是觉得愧疚）。

我觉得这里的主要经验是，当你学习新数据库或新软件建构方式时，你通常会在第一次尝试中犯下许多错误。你可以沿途进行代码重构，但对于游戏，你需要持续进行调整，直到发现真正的趣味点。

所以我们很难维持重整步伐，且同时又学习新数据库。所以重写代码让我能够在“建模”阶段加快开发速度，条件是在随后投入更多的开发时间。

我觉得将来在更适合快速开发的语言中创建模型，然后落实所有游戏设计元素效果会更好，接着在游戏设计看起来颇为稳固/有趣时，转投Cocos2D-iPhone。

2. 尽量简化游戏设计

我第一次编写《Math Ninja》时，游戏设计基本上是硬性植入游戏中。改变怪兽的健康值需要改变怪兽类的构造函数数值。调整关卡新生的怪兽需要在函数中编写若干代码。再来就是武器和故事元素等。

调整这些设置并不难，但文件/代码的反复切换让我出于懒惰不再想要改变任何游戏设计元素。

这很糟糕。为方便自由调整游戏设计元素（游戏邦注：例如怪兽统计数值和关卡衍生数目），这些编辑操作需要尽量保持简单。

在重写代码的过程中，我将所有怪兽、关卡和故事的定义抽出，放入一个容易调节的XML文件中。我开始给XML文件创建WPF编辑器，但我随后发现手动编辑XML要比通过任何编辑器简单和快速得多，因此我只能继续处理XML文件。

最重要的是，我做出的所有改变令游戏设计元素变得易于调节。下面是原因所在：

* 由于改变游戏设计元素非常简单，我可以随意做出任何调整，将游戏变得更有趣/更平衡。

* 测试工作变得更简单。我可以轻松创建关卡，衍生我所制作的特定怪兽或组合内容。

* 游戏设计元素和编程元素存在明显的差异。这令我能够针对各项任务树立正确“心态”——这让我觉得非常特别。

3. 但游戏设计依然非常艰难

另一我从中学到的经验是，无论你将游戏设计变得多么简单，要找到优秀的设计依然非常困难，是项非常耗时的工作。

我自己都不记得给游戏各类武器的影响、破坏性和升级路线做出过多少次调整，或是通过不同的武器选择体验不同难度系数的关卡多少次。

起初我因为在游戏设计中投入这些时间而感到愧疚。对我这样的程序员来说，在本该进行编码工作时腾给游戏设计如此多时间就好像是在“玩耍”或“混时间”。

但我随后意识到，从逻辑上讲，顺利完成游戏设计至关重要（游戏邦注：这是决定游戏是否有趣的关键点），所以这完全值得我们投入时间。

我发现我要学习的游戏设计知识还有很多。我觉得有经验的游戏设计师会运用比我更多的数学和电子表格技巧，会计算平均DPS，每时间帧的最大伤害值等，算出武器/升级道具的正确伤害值。

作为新手，我知道的唯一方式就是反复进行尝试，直到呈现优质内容。这个方式非常可行——但需要耗费更多的时间和精力。

4. 是的，你需要测试者！

在接近游戏包装尾声时，我妻子和我对于最终成果非常满意，致使我们开始说出诸如此类的话：“我们不需要测试者，我们的游戏非常杰出，怎么可能会有不妥的地方？”

我们是井底之蛙。

幸运的是，我们开始寻求好友和家人的帮助，这些对象处于不同年龄层及技术水平，让他们对游戏进行试验。他们从中发现漏洞，因此如果直接将游戏发行，我们将陷入尴尬的境地。

不仅如此，他们还向我们提供很多很棒的构思。

所以所获经验是——无论你觉得自己的应用/游戏多么优秀，务必寻找若干测试者。你定不会为此后悔！

5. 最后10%最困难

回到我开始制作这款游戏之前，我记得有位朋友告诉我，在他的游戏项目中，最后10%最困难。

他对此说法完全正确！

我觉得要估算制作《Math Ninja》所需的时间总量很难。我觉得自己很善于估算制作应用所需要的时间，但在游戏领域，这截然不同。

我觉得其中的困难之处在于游戏永远没有真正完工的一天。你总是可以多植入一个功能，多引入一个关卡，多制造一个视觉效果，进而将内容变得更优秀。

所以你要怎么知道自己需要投入多少时间完成游戏的制作？在我看来，这是个开放式问题。坦白讲我对此没有答案，所以我只是持续进行制作，直到自己对此表示满意，虽然我能够添加的潜在功能不胜枚举。

但快要提交作品的这个阶段是最艰难的时候。很多次我都告诉自己作品“差不多完成了”，但最后发现自己1个礼拜后依然投身于此。

更不要说项目出现拖延的情况，越是希望项目“恰好完工”，在项目制作过程中就会越是感到疲惫。但游戏尚未准备就绪，需要进行更多润色，所以有段时间我不得不从心里强迫自己完成剩余工作，然后将其呈现给用户。

所以在制作游戏过程中你需要有坚持到底的毅力——你需要意识到，无论你预计完成的工作量是多少，实际情况总会超出你的预期。

游戏邦注：原文发布于2010年5月5日，文章叙述以当时为背景。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

5 Things I Learned Making My First iPhone Game

I’ve been in hibernation for the last few weeks putting the finishing touches on my first iPhone game – but now I’m back, since the game is finally on the App Store!

For the curious, the game is called Math Ninja and is an educational iPhone game designed to make practicing addition, multiplication, division, and subtraction fun. It’s actually based on the How To Make A Simple iPhone Game with Cocos2D Tutorial Series from this site, and the art was done by my lovely wife!

Anyway, in the process I learned a ton of lessons about making games that I thought you guys might find interesting. So here’s what I learned from the whole experience!

1. It’s OK to Rewrite

The first time I wrote Math Ninja, the code was pretty bad. Spectacularly bad, I might say. I was new to Cocos2D, so made a lot of rookie mistakes, and had designed the app as I was writing it, so the organization was pretty ugly and full of hacks.

So I had a dilemna halfway through the project – should I wrap up the game as-is, figuring the end user would never know the difference anyway? Or should I rewrite it from scratch now that I knew what I was doing better – and add some improvements along the way?

There’s actually a lot of debate on this subject. Joel on Software calls rewriting software from scratch the single worst strategic mistake that any software company could make.

I debated the subject for a while, and finally decided to go with the rewrite – mainly for self-satisfaction and learning sake. The rewrite took me about half as long as it took me to write Math Ninja the first time, so was quite time intensive. So was it worth it?

In this case, definitely. I think it was worth it for the following reasons:

* In general, the game rested on a much firmer foundation, making it much easier to add new features.

* During the rewrite, I refactored the level design logic out into an easy configuration file, which was made the game design much easier (more below).

* During the rewrite, I put more thought into how to store and save game state, which made loading and saving much easier.
During the rewrite, I put more thought into game performance, making the app more responsive.

* And perhaps most importantly, I was personally much happier with the results and can be proud of it (instead of feeling slightly guilty!)

I think my key takeaway from this is when you are learning a new library or way of constructing software, the first time through you’re going to make a ton of mistakes. You can refactor along the way, but with games you are constantly changing things until you figure out what is fun.

So it’s very difficult to maintain the pace of constant refactoring (for cleanliness) with constant refactoring (for fun), while at the same time learning a new library (at least for me). So rewriting let me get additional development speed during the “prototype” phase in tradeoff for additional development time later (to rewrite).

In the future, I think it would be even more useful to make a prototype in a language more suited for rapid development (such as perhaps Flash or Cocos2d Python) to get the game design elements worked out, then switch over to Cocos2D-iPhone when the game design look solid/fun.

2. Make Game Design Easy As Possible

The first time I wrote Math Ninja, the game design was literally hard-coded into my game. To change the health of monsters required changing a number in the constructor of the Monster class. To change the monsters that spawned in a level required writing some code in a function. And so on for weapons, story elements, etc.

It wasn’t hard to tweak these settings, but the amount of switching between files/lines of code necessary to effect a change added up – and subconciously, made me not want to change certain game design elements out of laziness.

This is a bad thing. In order to feel complete freedom to change the game design elements such as monster stats, level spawns, etc., editing those needs to be as easy as possible.

So in the rewrite, I pulled all of the definitions for monsters, levels, story, etc. out into an easily tweakable XML file. I started to build a WPF editor for the XML file, but then I realized that editing the XML by hand was much easier and faster than any editor could be and just stuck with the XML.

Of all the changes I made, making the game design aspects so easy to tweak was probably the most important. Here’s why:

* Since changing game design aspects was so easy, I felt free to make any changes required to make the game more fun/balanced.

* Testing was much easier. I could easily create levels to spawn certain monsters or combinations I was working on.

* There was a clean separation between game design aspects and programming aspects. This helped me mentally get in the right “state of mind” for each task – which feel very different for me!

3. However, Game Design Is Still Hard

The other thing I learned was no matter how easy you make it to tweak your game design, coming up with a good design is still incredibly hard and time consuming work.

I don’t even know how many times I changed the effects, damage, and upgrade paths of the various weapons in the game, or played each level in various difficulties with varioius weapon choices.

At first I felt strangely guilty even spending all this time on game design. To me as a programmer, spending so much time on the game design felt like “playing” or “goofing off” when I really should be coding.

But then I realized that logically, getting the game design right was probably the most important aspect – after all, that is what makes the game fun – so was worth the time.

I realize I still have a lot to learn from game design. I think experienced game designers use a lot more math and spreadsheets than I did, calculating average DPS, max damage possible per time frame, etc. to figure out the right damage for weapons/upgrades/etc.

Being a beginner, the only way I knew how to do it was by iterating, iterating, iterating until something good came out. It worked (at least I hope so) – but just took a lot more time and hair pulling!

4. Yes, You Need Testers!

Toward the end of wrapping up the game, my wife and I were pretty happy with the result, to the point where we started saying stuff like “Meh, we don’t need testers, our game is awesome, what could possibly go wrong?!”

Little did we know.

Luckily we enlisted the help of some friends and family (including my three awesome cousins Drew, Blair, and Ry) with wide age ranges and skill levels, and had them try out the game. And they discovered bugs – lots of them – that would have been embarassing to have shipped with!

Not only that, but they gave us a lot of great ideas too!

So lesson learned – no matter how good you think your app/game is, get some testers. You won’t regret it!

5. The Last 10% Is The Hardest

Back before I started on this game, I remember a friend of mine telling me how with the game he was working on, the last 10% was the hardest.

He was definitely right about that!

I found estimating the amount of time it would take to make Math Ninja extremely difficult. I feel like I’m pretty good at estimating how long it will take me to make applications, but for games it’s a completely different story.

I think the difficulty resides in the fact that a game is never really done. There’s always one more feature you could add, one more level you could include, or one more visual effect you could have to make things that much better.

So how do you know how long you’ll need to get it done? To me, that is an open question. I honestly had no idea, so just worked on it until I was happy for it, even though there are a bucket of features I could have potentially added.

But just getting to that point where it was ready to submit was definitely the hardest part. There were many times I was convinced it was “almost done”, and then found myself still working on it a week later!

Not to mention as the project dragged on, the more and more I wanted to “just be finished” and the more tired I was of working on the project. But yet it wasn’t quite ready and needed more polish, so there were many days of mentally forcing myself to finish up the remaining work to get it out the door.

So to make a game you need stamina to see it through – and you need to realize that no matter how much work you think it will be, it will probably be a lot more.

Promo Codes!

If you’re interested in a promo code, I’ll give them out to the first 5 people to comment on this post. Just leave a comment with a valid email address and I’ll send one to you!

What Have You Learned?

Making my first iPhone game was one of the most fun and rewarding experiences I’ve ever had. I’m extremely happy with how it turned out and had such a great time developing it, and I feel like it taught me a lot of lessons along the way.

I’m really interested to hear others experiences developing games, and any useful lessons you may have learned. Please share below!（Source：raywenderlich）