游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

分享业余爱好者自创游戏的经验

发布时间:2013-10-25 17:43:07 Tags:,,

作者:Nate Miller

前言

在过去三个月中,我都在致力于开发一款名为《Lunar Lander 3D》的小游戏。我着手这个项目的主要原因是希望掌握创造游戏所需了解的知识。除此之外,我还希望借此转移自己在课业上的压力。虽然这款游戏很小很简单,其开发过程却让我收获了大量有用的知识。我将在本文列出自己在开发游戏过程中学到的一些重要知识。

在进入正题之前,我想先说明一下,我并不是什么专业人士。我只是一个常坐在电脑前的呆子,本文内容面向想自己试着创造一款游戏的业余程序员和爱好者。所以本文的重点是让你如何完成一款游戏,而非制作一款技术华丽的半成品游戏。

programmer(from drimmit.com)

programmer(from drimmit.com)

你的理念并不罕见

如果你想完成一款游戏,你就必须认识到这一点。无论你有多看重自己以及自己的想法,你都要勇于抛弃其中的多数想法。当我开始制作自己的游戏时,满脑子都是自己想用的理念。我想在游戏世界中加入移动的平台的障碍,复杂的摄像系统以及一系列其他元素。但我知道如果我想完成游戏,就得更改自己的多数理念。要记住当你是孤军奋战时,你就无法搞定一个专业团队需要用一年以上时间才能完成的项目。虽然一年以上的时间对专业团队来说并非很长的时间,但却业余爱好者来说却是个大难题。要根据自己的想法合理安排开发时间,例如将其控制在6个月以内。

不要从头做起

如果你并没有什么编码基础,那就无法一开始就编写出一款游戏。这听起来难以让人接受,但如果你确实没有一系列持续使用的代码,你可能就无法持续长时间地编程。如果你没有那么长久的编程经验,那么就不能幻想开发一款游戏。我开始制作自己的游戏时,已经有了一个很大的代码库。我针对一般窗口创造、输入管理、粒子效果、运算以及各类用途的代码。有了这些现成的代码,我就能够快速展开工作,制作与游戏相关的内容。除此之外,我还不需要去测试这些代码,因为我之前编写的时候就已经测试过了。你在开始创造自己的游戏之前,不需要逐个编写每一节代码。只要花点时间先做一点基础工作即可。如果你觉得自己还是得创建一个代码库,那就先编写小型用来测试一下。我处理粒子效果、输入管理和控制执行代码时就是这么做的。这可能不像制作游戏一样令人兴奋,但对你却有长期的帮助。

借鉴想法

我要再次强调这个环节的重要性。当你开始编写一款游戏时,不要害怕使用他人的理念,库或工具。可以尽量借鉴,因为这可以让你的工作更轻松。我在制作自己的游戏时,借鉴了Conor Stoke的轴线对齐边界框树,Paul Nettle的碰撞检测文件,id Software的Q3Radiant关卡编辑器。为什么我要用其他人的想法和工具来解决自己本可以完成的问题呢?原因就在于,这样更简单——我使用这些不同的资源是因为节省时间。使用现成的方法进行碰撞检测,这样我就不需要将时间浪费在测试自己的碰撞系统上了。我根据自己的需求调整了id Software的地图编辑器,就不需要再制作自己的编辑器了。除此之外,id地图编辑器非常适合我,这又为我节省了不少功夫。不要执拗于自己的游戏一定要有定制工具和解决方案。如果你够精明,就会知道何时要采用新理念,何时可以使用现成的东西。

避免使用3D地形引擎

如果是为了创造游戏而制作引擎,那就很可能被卡在半途。无论你多努力地尝试,总会发现自己无所进展。根据我制作游戏的经验,你自己编写游戏时并不需要用到引擎。要记住,你是一个人而不是一家公司在编写游戏。你不需要一个反复重用的引擎。编写引擎的一个理由就是代码重用,但没有引擎你也照样可以做到这一点。只要设计合理,你就能够将自己其他项目的元素重用到游戏上。例如,我编写的游戏所用的新代码都不是特定的游戏代码,我可以将其重用于其他项目。编写引擎以获得引擎本身的知识及其背后的设计过程当然可以,像如果你是要制作一款游戏那就要避免这种情况了。

不要在图像上画蛇添足

你制作自己的游戏时,不要添加一些并不会让游戏更棒的图像特点。不要使用GeForce20那种很棒的扩展功能,以及其他的逐象素、凹凸贴图、纹理动画、逐象素深度阴影等元素,因为你根本就不需要。如果你将自己的游戏定义为靠图像来撑场面的那种,那你可能并不了解游戏。你制作的只是一个技术演示样本。我在自己的游戏中使用的最复杂的图像功能就是多重纹理,但如果要游戏正常运行也并不需要这种功能。我知道自己并非id Software成员,也并不需要很高端的硬件来支持我这款简单的游戏。如果你保持简单性,不但可以扩大游戏受众,还能够将自己的精力集中于更重要的环节,例如游戏玩法。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Building A Game On Your Own

by Nate Miller

Introduction

Over the course of the past three months I have been working on a little game called Lunar Lander 3D. My main reason for embarking on this project was to gain some knowledge about what it takes to create a game. Other than that, I just wanted something to distract me from school. Although my game is simple and small in scope, the process of creating it has given me a great deal of useful knowledge. In this article, I am going to go over some of the important things that I learned while creating my game.

Before I get into the meat of the article, I want to point out that I am by no means a professional. I am just another goon with a keyboard. This article is meant for hobbyist programmers who would like to create a game on their own time. The main emphasis throughout this article will be on finishing the game you are working on, not making a flashy technology-bloated half-game. And when I say finish, I don’t mean working on a game for a long period of time only to ditch it because a shiny piece of metal caught your attention.

Your ideas are not sacred

If you ever want to finish a game, you need to realize this. No matter how much you think of yourself and the ideas that you have come up with, you will need to toss most of them out. When I started working on my game I had a mountain of ideas that I wanted to use. I wanted to have moving platforms and hazards in my worlds, a complex camera system and a number of other things. But I knew that if I ever wanted to finish my game, I would have to ditch most of the ideas I had. It is important to remember that when you are working alone, you can’t come up with a project that would take a professional team a year or more to make. While a year or so may be OK for a professional team, it is a bad idea for a hobbyist programmer. Try to tailor your ideas so that you can work on your game for a period of, for example, six months or less and you will be much better off.

Don’t start from scratch

If you don’t have a base of code to work off of, you shouldn’t be writing a game in the first place. It is that simple. This may sound harsh, but let’s take a closer look at the situation. If you don’t have a set of code that you use consistently, you probably haven’t been programming for all that long. If you haven’t been programming that long, jumping into a game is the last thing you want to do. When I started working on my game I had a large base of code to work off of. I had code for general window creation, input management, particles, math and various pieces of utility code. With all of this code ready to be used, I was able to immediately begin working on things that were related to my game. Additionally, I didn’t have to test this code since I had tested it when I originally wrote it. You don’t have to write every piece of code you will ever need before you start your game. Just take some time to lay a groundwork that you can build off of. If you feel that you need to build up a code base, write small applications to test things out before you start your game. I did this with my particle, input management and command execution code. It may not be as exciting as a game, but it will definitely help you in the long run.

Borrow ideas

I can’t even begin to stress how important this section is, so let me say it again. This section is important. When you are writing a game, don’t be afraid to use other people’s ideas, libraries or utilities. Borrow as much as you can, it will do nothing but make your life easier. In my game, I remembered Conor Stokes’ soft hands and used his article on axis aligned bounding box trees, I used Paul Nettle’s collision detection document and I used id Software’s Q3Radiant level editor. Why did I use other people’s ideas and tools to solve problems that I could have solved on my own? The answer to this question is simple: I used all of these different resources because it saved me time. By using an established method for collision detection, I didn’t have to waste my time coming up with and testing my own collision method. By adapting id’s map editor to my own devious purposes, I avoided having to come up with my own. And, as an added bonus, id’s map editor lit levels for me, which is yet another thing I didn’t have to deal with. Don’t get caught up in the belief that you need to have custom tools and solutions for your game. If you are smart, you will know when to come up with new ideas and when to use well-established ones.

Avoid the tar pits

What in the world are the tar pits? The tar pits are the so-called 3D and terrain engines that everyone loves to work on. If you are working on an engine in order to create a game, you will be like a mammoth stuck in the tar. No matter how much you try, you aren’t going to be going anywhere. The experience of working on a game has made it clear to me that an engine is not needed when writing a game on your own. Remember, you are a single person writing a game, not a company writing a family of games. You don’t need an engine to reuse over and over. While a good reason to write an engine is code re-use, this can easily be obtained without an engine. With a reasonable design you will be able to reuse parts from your game in other projects. For example, of all the new code I wrote for my game that is not game specific, I can reuse 100% of it in other projects. This is pretty good considering I never had this in mind as a goal. Writing an engine to gain knowledge from the engine itself and the design process behind it is fine, but you should avoid it if you are trying to create a game.

Don’t get cute with graphics

When you are working on your game, don’t bother adding graphic features that don’t make your game better. You know that cool extension on the GeForce20 that you want to use? Don’t use it. You know how you want per-pixel lit, bump mapped, texture animated, per-pixel depth shaded magic snails in your game? You don’t need them. If you define your game by the extensions and eye candy in it, you probably don’t have much of a game. What you have is a technology demo. The most complex graphics feature that I use in my game is multitexture, but you don’t even need it to run the game. I know that I’m not id Software, so I have no business requiring insane hardware to play my simple game. If you keep things simple, you will not only broaden your audience, but you will also be able to focus on more important things in your game, like gameplay.

Conclusion

Well, I hope some of what I have said makes sense. It makes sense to me, but who knows what other people will think of it. If you have any questions or comments, feel free to e-mail me at nathanm@uci.edu and I will try to get back to you as soon as I can.

If you are interested in my game, you can visit the Lunar Lander 3D page and download it.(source:flipcode


上一篇:

下一篇: