作者：Sean “rioki” Farrell

《Da Boom！》是我利用自己的闲暇时间，历经半年开发出来的项目。这是一款经典的炸弹布置游戏，采用了复古的美术风格，但支持玩家在网络上玩游戏。你不但可以上网络上体验该游戏，还可以混合本地多人及联网玩法，例如两个玩家在一头，另外两个玩家在另一头一起玩。

这个项目的核心几乎围绕着开发技术和开发战略。这是我曾经完成的首个业余项目，我曾经想过自己如果不完成这个项目，我就放弃游戏开发。

正确经验

限定范围

刚开始我认为自己必须选择一个小型项目，并严格限制其范围。我一周只能投入约20小时，这意味着我必须尽量移除一些华而不实的东西。

游戏类型的选择是起源于一名好友抱怨网络上缺乏扫雷类型的游戏。这种游戏类型因其有限的范围而正好符合我的要求。

将范围压缩下来后游戏中就只有3种升级道具和一种严格限制的美术风格。

美术方向

art 1(from gamedev)

虽然这里的美术从技术角度来讲是指“程序员”美术，但我仍然达不到创造这种美术的水准。我特别瞄准了一种极为简洁和复古风格的美术风格。这种美术风格意味着我可能够快速在屏幕上呈现出内容，并且试玩这种游戏机制。

中枢跟踪器

我几乎是偶然开始尝试中枢跟踪器。最初我根本就不想使用计划软件。我的结论（至少是针对我的业余项目）就是，你计划的越多，真正执行得就越少。因为当我一看到庞大的工作量并且无法赶在截止日期前完成时，就会严重打击到我的积极性。

但我发现中枢跟踪器有两个奇妙之处。它允许你轻松地重新排列工作。这一点很重要，因为我侧重于计划现在暂时不需要的事情。当你发现一切都像永无止境的样子时，你之后可以简单地将那些额外点缀从计划中删除。

第二点就在于你可以根据已经完成的工作，以及还剩多少工作量来制定截止日期或时间表。虽然你可以为时间表分配日期，但事实上你很可能无法按照时间表及时完成任务。

技术

我对自己所能找到的多数图像库都有点意见。它们不是难以制作出真正简单的东西，就是欠缺重点和成熟性。

在过去几年中，我已经掌握了大量代码，并最大化地满足了自己的需求。唯一的问题在于，它并不是以一种容易使用的方法进行包装。

我花了点时间创建和包装pkzo, spdr和glm。现在我不但拥有了可用于渲染、声音和交流的渲染库，还极大提高了工作效率。我并不打算整合那些会浪费我时间并且不实用的库，因为它们并不能从头开始创建，它们有奇怪的干扰性界面或者庞大的设置开支。

另一方面我也没有从头开始重写一切代码，而是在SDL这种出色的库以及SDL_image, SDL_ttf和SDL_mixer这些伴生库的基础上创建游戏，这确实节省了一半的开发时间。

过度重构

我所无法容忍的一件事就是丑陋而糟糕的代码。这可能是一个性格缺陷，但我曾经因为代码不对而抛弃项目。这一次我决心尽量让代码呈现最佳状态。

这最初听起来很简单，但有时候还是会发生意想不到的情况。例如，类处理菜单逻辑可能会从小而精致的情况转向庞大而杂乱的特殊情况。但即使如此我们还是有可能打散代码并移除最重叠的内容。

重构代码需要遵循严格的准则。问题在于它会让你感觉在这个过程中你根本就没有进步。但它还是值得一试。

art 2(from gamedev)

错误教训

缺乏准则

我们都是人类，通常难以鼓起勇气去做所有乏味而沉闷的事情。该项目有一个良好的开端，那就是我的热情。但在头两个月过去之后，我开始有所懈怠。我刚开始的时候还是挑选最有趣的环节而不是从最有必要的部分入手。如果游戏甚至还不能够试玩，花太多时间去挑选音乐是没有什么意义的。

重写和“点缀”

我很自豪地说，我只重写了整个渲染和交流系统，并且每个都只用了1.5倍的时间。虽然这对我来说是个突破性的历史纪录，但却仍然是我最大的绊脚石之一。

最明显的“点缀”在于我将自己的渲染代码从即时模式OpenGL 2.0转移到了OpenGL 3.2。虽然旧代码是无效的，但这一点完全不重要。任何体面的PC都能够不费吹灰之力地进行渲染。

第二个“点缀”及不必要的投入就是制作异步多线程交流系统。虽然交流代码运行正常，游戏逻辑却会以非常微妙的方式打断，最后我还是采用了同步单线程代码。

art 3(from gamedev)

技术性错误

最缺乏远见的一点就是游戏逻辑，尤其是与展示层交互的过程中出现的问题。虽然这两者关系不大，但在基于事件系统的推动下，在整合交流层时就有可能出现致命的问题。交流系统多线程的属性会间接迫使展示层变成多线程。但与使用OpenGL相同的是，从多线程操纵资源并不是个好主意。

真正的问题在于执行缓解措施的方法（例如调用整理或锁定策略）是一个明显的意外投入。最后我在主循环澡调用了交流系统。

在未来设计中，我必须一开始就考虑到多线程的问题，尤其是在我想从多核系统中获得最多成果的情况下。但在这样一款小游戏中，这种做法无异于浪费精力。

遗失功能

不幸的是，我无法执行自己想做的所有功能。它们是显著的角色动画、得分以及AI。我的关注点在于核心体验，不幸的是我没有足够的时间和精力去执行它们。我可能会在下一回中将其添加进去。

额外条件

最大障碍之一就是我的专业处境。通常情况下我一周工作4天。这让我至少抽出一整天时间来制作这样一个业余项目。但随着项目接近于其发布日期，情况就变得棘手了。我连续3个月每周工作5天。这种时间投入上的不足意味着我无法完成太多事情。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Post Mortem: Da Boom!

By Sean “rioki” Farrell

Da Boom! was developed over the course of the last half year in my spare time. It is a classical bomb laying game with a retro art style, but with the ability that you can play the game over the network. Not only can you play the game over the internet, but you can mix local multiplay and network play, you can for example have stwo player on one end and two on the other.

The focus of this project was mostly centered around developing technologies and development strategies. This is the first hobby project that I ever completed. I went out and said, either I complete this project or I give up on game development.

What Went Right

Limited Scope

From the start I knew that I had to pick a small project and severely limit the scope. I can only invest around 20 hours on a good week and this means that I had to remove as much gold plating as possible.

The actual choice of the game type was triggered by a good friend complaining about that lack of bomb laying games that worked properly over the internet. This game type with its limited scope fit the bill quite nicely.

But even here the scope was reduced to only have 3 power ups and a restricted art style.

Art Direction

Although the art is technically speaking “programmer” art, it is not at the level I can produce. I specifically aimed at a severely reduced and retro looking art style. This art style meant that I could quickly get something on screen and play around with the game mechanics.

Pivotal Tracker

I almost by chance started to try out Pivotal Tracker. Originally I wanted to use no planing software at all. I have come to the conclusion, at least for my hobby projects, that the more you plan the less you actually do. The problem comes from the fact that when I see the mountain of work to do and miss a deadline that this can deal a final blow on my motivation.

But I found two things that were awesome about Pivotal Tracker. It allows you to easily reorder work. This is important since I tend to plan things that are not needed now or even ever. This gold plating can then simply be pulled out of the plan, when you notice that everything will take forever.

The second thing is that deadlines or rather milestones are estimated by the work already done and how much there is to do. Although you can assign a date to a milestone, there is no kidding you about the chance that you will make the milestone on time, when that is not the case.

Technology

I have a bone to pick with most graphics libraries that are available to me. They either make really simple things hard to achieve or lack focus and maturity.

Over the years I have amassed a large body of code that does most of what I needed. The only problem was that it was not packaged in an easy to use fashion.

I invested some time into building and packaging pkzo, spdr and glm. Not only do I now have usable libraries for rendering, sound and networking, I gained a significant productivity boost. I’m not trying to integrate unwieldy libraries that waste my time, because they do not build from the get go, they have weird intrusive interfaces or the setup overhead is huge.

On the other hand I did not rewrite everything from scratch. Being able to build upon awesome libraries like SDL and the companion libraries SDL_image, SDL_ttf and SDL_mixer really cut the development time in half.

Excessive Refactoring

One thing that I can simply not stand is ugly and bad code. This might be a character flaw, but I have given up working on projects because the code felt wrong. This time around I was determined to keep the code in the best shape possible.

It sounds easy at first, but some things just sneak up on you. For example, the class handling the menu logic went from being small and well defined to a huge jumble of special cases. But even here it was possible to break up the code and remove most duplication.

It takes severe discipline to refactor code. The problem is that it feels like you are making no progress at all while doing it. But it was worth the effort.

What Went Wrong

Lack of Discipline

We are all humans and it is often hard to muster the strength to do all the little tedious things. The project was on a great start, what what do you expect, this is my passion. But after the first two months went by I started to not put in the desired time. This was especially true that I also started to pick the interesting thing to do instead of the really necessary ones. It is interesting how much time you can spend choosing music when the game does not even have the means to play it.

Rewrites and Gold Plating

I am proud to say that I only rewrote the entire rendering and networking systems about one and a half times each. Although this is a record low for me it remains one of my biggest stumbling stones.

The first most obvious gold plating was that I migrated my rendering code from immediate mode OpenGL 2.0 to OpenGL 3.2. Although the old code was inefficient, it did fully and totally not matter. The scene is so simple that any decent PC is able to render it without breaking a sweat.

The second gold plating and unnecessary effort was in making the network system asynchronously multi-threaded. Although the networking code worked fine, the game logic broke in very subtle ways and I ended up falling back in synchronous single threaded code.

Technological Blunders

The biggest lack of foresight was the game logic and especially the interaction with the presentation layer. Although the two were weakly bound, through the help of an event based system, it turned out to be fatal when integrating the networking layer. The multi-threaded nature of the networking system indirectly forced the presentation layer to be multi-threaded. But as it goes with OpenGL, manipulating resources from multiple threads is not a good idea.

The real problem was that implementing mitigation strategies, such as call marshalling or locking strategies, were a significant unplanned effort. In the end I ended up calling the networking system in the main even loop.

In future designs I must think about multi-threading from the start, especially if I want to get the most out of multicore systems. Then again, on such a small game, this is a wasted effort.

Missing Features

Unfortunately I was not able to implement all features I wanted. These being notably character animation, scoring and AI. My focus was on the core experience and unfortunately I did not find the time and energy to implement them. I will maybe add them in on another go around.

External Conditions

On of the biggest dampers was my professional situation. Normally I am working 4 day weeks. This gives me at least one entire day to work on such hobby projects. But as the project at my day job approached its release date and things got a bit hectic, I worked 3 months for 5 days a week. This reduction in time meant that I could simply not get so much done. （source：gamedev）