作者：Chad Ata

当你刚进入游戏开发领域时，你总是很难决定该使用怎样的工具，语言和框架。你将面对各种各样的选择以及大量需要考虑的观点。而我和我的团队发现参考其它游戏公司的开发环境是非常有帮助的。

蹒跚而行

尽管拥有在其它领域10年以上的编程和设计经验，但是当开始开发游戏时我还是觉得自己就像个新手。我们的第一个项目《外星宠物》开始于2009年，并且在那时候只面向Android平台。Java是唯一适合初出茅庐的人所使用的语言，所以我们果断选择了它。为了创造一款2D游戏，我们并未使用OpenGL去开发游戏（这是错误的）。而因为Furdi广受欢迎，所以整个项目也因此受到广大关注。我们最终发现自己需要面对像性能和可移植性等问题。而如果我们能够从其他开发者身上吸取经验教训便有可能避免许多不必要的问题。

找到一个更好的方法

在完成《Furdiburb》并几乎快将游戏移植到iOS（使用playn）后，我们决定转向创造第二款游戏（《炼金时代》）。为了进一步扩展交叉平台开发并为未来的主机开发做准备，我们决定舍弃Java。

所以我们便开始进行各种探索。我花了将近1个月的时间去比较不同框架，工具和引擎，最终我和我的团队决定使用一种全新的开发方式，这也是我们到今天仍在使用的方式。我并不清楚为什么我们会有这样的选择。框架总是不断发生着变化，我们在一年前做出一个决定的原因可能在今天早已无效。而在之后的内容中我将简单地描述我们使用的方法以及为什么会使用这种方法。

编程

这是我们用于编写游戏程序的内容。这是我们做事的方法。结合各自不同的工具和框架是非常有效的。

框架

我们所选择的所有框架要么是开源的，要么是带有公开的代码。这对我们有很大的帮助，因为如此我们便可以根据需求做出适当的调整与紧急的修改。

Cocos2d-x—-我们的所有跨平台开发都是依赖于开放源Cocos2d-x框架。对于《炼金时代》，我们使用的是第二版。我们也将在之后的游戏中使用最新的第三版，即包含大量关于API和性能的完善。从整体看来Cocos2d-x 2D拥有突出的性能以及出色的文件编制功能。

Spine—-我们在动画制作中使用了Spine，所以我们添加了他们基于C语言的Cocos2d-x插件。

Box2D—-虽然我们还未使用Box2D发行过游戏，但是我们在下一款游戏《A Quiver of Crows》的开发中使用了这一工具。

SQLite—-Cocos2d-x提供给我们一个数据储存解决方法，但我们更倾向于使用SQLite，因为它能够帮助我们更好地阅读/编写。

语言

C++—-Cocos2d-x支持多种语言，但我们还是选择了C++，因为我们认为这是当下最友好的跨平台语言。

C—-有时候你可能会想整合一个开放源API。而有些开放源便是基于C语言进行编写。

Java—-我们仍然需要使用Java，但只是为了在Android平台上整合IAP，广告和针对于OS的功能。语言间的交流是通过JNI完成的。

Objective-C—-与Java一样，我们使用Objective-C去创造针对于iOS的功能。

脚本语言—-包含shell脚本语言和其它脚本语言。所有开发者都需要经常编写脚本，但我们却很少谈及它。这是相对简单的内容，但也是费时的内容，就像如果你和我一样因为很少使用而很难记住语法的话。我们是为了编译代码，自动化音频转化，自动化关卡创造和整合纹理而编写脚本。

开发环境

Xcode—-每个人都跟我们说Xcode很糟糕！所以我便决定尝试看看，但是我却必须承认，这已经成为现在的我最喜欢的开发环境。我们会使用Xcode进行跨平台开发以及面向苹果的编程工作。

Eclipse—-我们会在所有与Java和Android相关的开发中使用Eclipse，包括资源配置与调试。现在的Android主推Android Studio而不是Eclipse，但我们既没有时间也没有动力再去转向它了。

Visual Studio—-这同样也是个优秀的IDE。我们主要是在与微软相关的编程，调试和资源配置中使用它。

版本控制

即使你是只有一个人的团队，你也应该使用版本控制！每个人都会犯错，任何硬盘驱动器都有可能瘫痪。我们是一支拥有三个人的团队，所以从第一天开始我们便非常重视版本控制。虽然对此的解决方法并不多，但我还是想和你们分享我们使用的一些方法：

SVN—-我很喜欢SVN。它能做我需要它做的所有事（包括合并，同步，历史等等），唯一的缺陷便是它不具有较高的学习曲线。

Git—-在众多开放源框架中我们还是依赖于Git。我们会使用Git去保持实时更新，有时候还会在需要进行快速修改时用它去创造分支内容。

计算机

显然你需要使用计算机才能创造电子游戏！最初所有开发工作都是基于Linux，但是当我们开始面向iOS开发游戏时，Linux已经很难再同时应对两台或三台计算机（甚至是系统多重启动的机器）。所以我们便购买了几台iMacs并使用它们去开发游戏。幸运的是OSX中的命令行与Linux的一样，如此我们便不需要再去改变大量脚本。

图像艺术

Adobe Creative Suite—-这没有什么意外，我们的美术师使用最多的便是Illustrator和Photoshop。

Spine—-我真的极力推荐这个骨架动画工具！比起传统的逐帧动画，骨架动画能够帮助你节省更多磁盘空间。并且因为拥有像动画混合，角色蒙皮和可变形的网格等强大功能，它还能帮你节省下不少时间。

Texture Packer—-你可能会为了拥有更好的性能而想将图像打包到更大的纹理中。为此我们便选择了Texture Packer，我们还使用了他们的命令行功能去自动化打包过程。

bmGlyph—-如果你计划使用位图字体（而不是运行Truetype字体），你便需要位图字体生成器。我们选择的是OSX可兼容的bmGlyph，这对我们非常有效。

关卡编辑

以下是我们用于设计关卡和图像布局的工具。

没有编辑器！—-有时候我们不会使用任何编辑器！我们只是编写了代码。虽然这听起来很疯狂也很无理，但如果你的团队真的很小，那么放弃编写一个编辑器将能够帮助你们节省不少时间。

定制编辑器—-有时候我们会编写一个较笨拙的游戏内部编辑器去创造图像布局或设置关卡。对于笨拙，我指的是未优化，因为只有我们自己会使用这一编辑器。

R.U.B.E—-对于我们的下一款游戏，我们先是创造了一个游戏内部编辑器，然后偶然发现了R.U.B.E（游戏邦注：即Really Useful Box2D Editor，真的很有用的Box2D编辑器）。这一工具帮助我们节省了不少时间，但如果我们决定发布一个关卡编辑器的话，我们还是要创造自己的编辑器。

音乐和音频

ffmpeg—-我是ffmpeg的忠实粉丝。它真的很棒！我们是在脚本中使用它将音频转化成面向特定目标平台的适当格式。

Cakewalk Sonar—-这是一个非常强大的音乐制作程序，在一开始便带有一个复杂的学习曲线。

Garritan Personal Orchestra—-如果你想要的是orchestral VSTs（乐器），Garritan便拥有非常高的音质。我们便是使用它与Sonar结合在一起。

Audacity—-这是一个很棒的音频编辑器与录音工具。

而以下是我们虽然不再使用，但仍想推荐你们的工具：

Anvil Studio—-如果你曾培训过乐器并且能够浏览/操控音符和时间等，且想要创造MIDI的话，这对你来说便是一个很不错的程序。

Linux Multimedia Studio—-LMMS是一个非常简单的程序。你将能够使用它去创造高科技舞曲/电子乐。并且该程序也不需要你知道如何看乐谱。

结论

如今创造游戏的方法多种多样。而以上是我们选择的用于创造跨平台2D游戏的方法，并且到目前为止我们都用的很顺畅。我们最近的游戏已经面向Android（Google Play，Kindle和Nook），iOS和Windows Phone发行了。我们也将使用同样的工具和框架将我们的下一款游戏进一步带向PC，Mac和Linux等平台。

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

What We Use to Make Our 2D Games
[04.02.15]
- Chad Ata

When you’re first starting out in game development, it can be very difficult to decide on which tools, languages, and frameworks to use. There are a ton of choices out there and a whole slew of opinions to wade through. My team and I always found it particularly helpful when other gaming companies revealed the development environment setup they found useful.

Stumbling About

Despite having 10+ years programming and designing experience in other fields, I felt like a newb when I started developing games. Our first project, Furdiburb (a virtual pet adventure game), was started in 2009, exclusively at the time, for Android. Java was the only available language for the fledgling platform, and so we went with it. Being a 2D game we (incorrectly) chose to develop without OpenGL against a non-hardware accelerated canvas. As Furdi grew in popularity so did the project. We eventually found ourselves dealing with performance and portability concerns. We could have saved ourselves a lot of pain had we been able to learn from other developers which frameworks to use or avoid.

Finding A Better Way

After completing Furdiburb and very slowly porting the game to iOS (using playn), we decided to move on to Game #2 (Eras of Alchemy). We wanted to move away from Java in the hopes of wider-spread cross-platform development while leaving the door open for console development in the future.

And so the search began. I spent nearly a month comparing frameworks, tools, and engines, and in the end, my team and I settled on a new way of development that we are quite happy with now. I won’t get into why we chose these. The frameworks are constantly changing, and the reason for making a decision a year ago may no longer be valid at this moment. Instead, the rest of the article will simply describe what we use and why we use it.

Programming

These are the things we use for programming our games. This is just the way we do things. Many different combinations of tools and frameworks are perfectly valid if not better.

Frameworks

All of the frameworks we’ve chosen are either open source or have publicly available code. This has been a great help so far as we’ve been able to make custom tweaks and emergency fixes when necessary.

Cocos2d-x – All of our cross-platform development is done against the open source Cocos2d-x framework. For Eras of Alchemy, we used version 2. For our next game, we are using the latest version 3, which includes a major overhaul of the API and performance improvements. Overall, Cocos2d-x 2D performance is great and the documentation is decent.

Spine – We use Spine for our animations, and so we include their C-based Cocos2d-x plugin.

Box2D – We’ve yet to publish a game with Box2D physics, but we are happily using it in the development of our next game, A Quiver of Crows.

SQLite – Cocos2d-x offers a data storage solution, but we prefer to use SQLite for better read/write access and performance.

Languages

C++ – Cocos2d-x supports multiple languages, but we chose to use C++ since we feel it is the most cross-platform friendly language available at the moment.

C – Occasionally you may want to integrate an open source API. Some of them are written in C.

Java – We still have to use Java, but only on Android for integrating IAP, ads, and OS-specific functionality. Communication between the languages is done via JNI.

Objective-C – Same as with Java, we use Objective-C for iOS-specific functionality.

Scripting – This includes shell scripting and other scripting languages. All devs have to write scripts from time to time, but we rarely talk about it. It’s relatively easy, but it’s often time consuming if you’re like me and don’t remember the syntax due to lack of use. We write scripts for compiling code, automating audio conversion, level building automation, and texture packing.

Development Environment

Xcode – Everybody told us that Xcode is terrible! So I tried it, and I have to say, it’s currently my favorite development environment. I won’t say why because I don’t want to start an IDE war! We use Xcode for cross-platform development as well as for Apple specific programming.

Eclipse – A sluggish monster of an IDE, but quite a good one in my opinion. We use Eclipse for all Java and Android related development including deployment and debugging. Android is pushing Android Studio instead of Eclipse now, but we haven’t had the time, nor the incentive, to switch over yet.

Visual Studio – Also a great IDE. We use it for Microsoft related programming, debugging, and deployment.

Version Control

Even if you’re a one-person team, you should use version control! Everyone makes mistakes, and any hard-drive may mysteriously die. We’re a team of three, and so from day one, version control was necessary. There are quite a few solutions out there, but these are the ones we use:

SVN – I like SVN. It does everything I need it to do (merging, syncing, history, etc.) but without a high learning curve.

Git – Many of the open source frameworks we rely on use Git. We use Git to stay up-to-date with them and occasionally make our own branches when a quick fix is necessary.

Computers!

Apparently you need computers to make video games! Initially all development was done on Linux machines (I <3 Kubuntu), but it eventually became very inefficient to deal with two or three computers (or even multi-boot machines) once we started developing for iOS. So we caved (I <3 Linux) and got some iMacs, which have actually been enjoyable to work on. Luckily, the command line is essentially the same on OSX as it is on Linux, so many of our scripts carried over unchanged.

Graphics Art

Adobe Creative Suite – No major surprises here. Our artist mostly uses Illustrator and Photoshop.

Spine – Can’t recommend this skeletal animation tool enough. Skeletal animation saves you on disk space as compared with traditional frame-by-frame animation. It also saves you development time with powerful features such as animation mixing, character skinning, and deformable meshes.

Texture Packer – You’ll probably want to pack your images into larger textures for better performance. We chose Texture Packer for this, and we use their command line functionality to automate the packing process.

bmGlyph – If you plan on using bitmap fonts (rather than runtime Truetype Fonts) then you’ll need a bitmap font generator. We chose the OSX compatible bmGlyph, which has served us well.

Level Editing

The tools we use to design our levels or layout graphics.

No Editor! – When we can get away with it we don’t use an editor. We just code it up! It sounds crazy and inefficient, but if your team is really small, sometimes you can save time by not coding up an editor for a one time task.

Custom Editors – Sometimes we code up a clunky in-game editor to layout graphics or set up a level. And by clunky, I mean unpolished, since we’re the only ones who ever use it.

R.U.B.E. – For our next game, we almost developed an in-game editor until we stumbled across R.U.B.E, which stands for Really Useful Box2D Editor. This super useful tool has saved us a ton of time, but if we ever decide to release a level editor, we’ll have to develop our own.

Music and Audio

ffmpeg – I’m a huge fan of ffmpeg. It’s awesome! We mostly use it along with a script to convert our audio to appropriate formats for each target platform.

Cakewalk Sonar – This is a powerful program for making music with a difficult learning curve in the beginning.

Garritan Personal Orchestra – If you want orchestral VSTs (instruments), Garritan has high quality sounds. We use this in conjunction with Sonar.

Audacity – A good audio editor and recording tool.

The following we no longer use, but would still recommended:

Anvil Studio – This is a good program if you’ve trained classically with an instrument and are comfortable with reading/manipulating notes, times, measures, and want to create MIDIs.

Linux Multimedia Studio – LMMS is a nice simple program. Out of the box, you can make great techno/electronic sounding music. This doesn’t require you to know how to read music notes.

Conclusion

There are tons of ways to make games these days. This is the way we’ve chosen to make our cross-platform 2D games, and so far, we’re quite happy with it. Our most recent game shipped on Android (Google Play, Kindle, and Nook), iOS, and Windows Phone. Using the same set of tools and frameworks, we plan on expanding to PC, Mac, and Linux with the release of our next game. (source:gamecareerguide)