隱藏 ✕
※ 本文為 windows2k.bbs. 轉寄自 ptt.cc 更新時間: 2012-09-16 20:08:34
看板 GameDesign
作者 onelife (旺來)
 Fw: [新聞] StarCraft 的開發歷史

時間 Wed Sep 12 21:32:27 2012

※ [本文轉錄自 StarCraft 看板 #1GJVm97_ ]

看板 StarCraft
作者 zabiak (zabiak)
 Re: [新聞] StarCraft 的開發歷史

時間 Mon Sep 10 22:41:10 2012







Tough times on the road to Starcraft


by Patrick Wyatt

I've been writing about the early development of Warcraft, but a recent blog
post I read prompted me to start scribbling furiously, and the result is this
three-part, twenty-plus page article about the development of StarCraft, along
with my thoughts about writing more reliable game code. I'll be posting the
latter parts over the next several days.

This post: Why StarCraft crashed frequently during development
Part 2: How we could have fixed the most common causes
Part 3: Explaining the implementation details of the fix



The beginnings of StarCraft

During the development of StarCraft, a two and a half year slog with over a
year of crunch time prior to launch, the game was as buggy as a termite nest.
While its predecessors (Warcraft I and II) were far more reliable games than
their industry peers, StarCraft crashed frequently enough that play-testing
was difficult right up until release, and the game continued to require ongoing
patching efforts post-launch.

Why? There were sooooo many reasons.




Orcs in space

StarCraft was originally envisioned as a game with modest goals that could fit
into a one-year development cycle so that it could be released for Christmas,

The project leadership was comprised of the same folks who had started
Shattered Nations (video), a turn-based strategy game along the lines of X-COM
that Blizzard announced in May 1995 but canceled some months later.

The team members were regrouped to build something that could reach market
quickly so Blizzard wouldn’t have a long gap between game launches.

Q4 1994 - Warcraft
Q4 1995 - Warcraft II
Q4 1996 - planned ship date for StarCraft
Q2 1998 - actual ship date for StarCraft

The decision to rush the game’s development seems ludicrous in retrospect, but
Allen Adham, the company’s president, was under pressure to grow revenue.
While Blizzard’s early games had been far more successful than expected, that
just raised expectations for future growth.

Given a short timeframe and limited staff, the StarCraft team’s goal was to
implement a modest game - something that could best be described as "Orcs in
space". A picture from around the time of the E3 game show in Q2 1996 shows the
path the game team originally chose:

But a higher priority project overshadowed StarCraft and stole its developers
one by one. Diablo, a role-playing game being developed by Condor Studios in
Redwood City California, was in need of additional help. Condor, a company
formed by Dave Brevik along with Max Schaefer and his brother Erich Schaefer,
was given a budget of only $1.2 million - ridiculously small even in those

The Condor team had no hope of making the game they aspired to build, but
they did such ground-breaking work in developing something fun that it made
sense for Blizzard to acquire Condor, rename it Blizzard North, and start
pouring in the money and staff the game really deserved.

Initially Collin Murray, a programmer on StarCraft, and I flew to Redwood City
to help, while other developers at Blizzard "HQ" in Irvine California worked on
network "providers" for battle.net, modem and LAN games as well as the
user-interface screens (known as "glue screens" at Blizzard) that performed
character creation, game joining, and other meta-game functions.

As Diablo grew in scope eventually everyone at Blizzard HQ - artists,
programmers, designers, sound engineers, testers - worked on the game until
StarCraft had no one left working on the project. Even the project lead was
co-opted to finish the game installer that I had half-written but was too busy
to complete.

After the launch of Diablo at the end of 1996, StarCraft development was
restarted, and everyone got a chance to see where the game was headed, and it
wasn’t pretty. The game was dated, and not even remotely impressive,
particularly compared to projects like Dominion Storm, which looked great in
demos at E3 six months before.

The massive success of Diablo reset expectations about what Blizzard should
strive for: StarCraft became the game that defined Blizzard’s strategy of
not releasing games until they were ready. But a lot of pain had to occur along
the way to prove out this strategy.



專案負責人是由"破碎的國度(影片)"團隊成員組成, 破碎的國度是暴雪在1995年5月發表


1994年第4季 - 魔獸爭霸
1995年第4季 - 魔獸爭霸2
1996年第4季 - 預計的星海爭霸出貨日期
1998年第2季 - 實際的星海爭霸出貨日期

現在回想起來,加快遊戲的開發腳步似乎荒唐可笑,但是公司總裁Allen adham承受著增

在緊湊的時間表以及有限的人力下,星海爭霸團隊的目標是實作出一個簡單的遊戲 - 一

黑破壞神,一個由位於加州Redwood市Condor Studio所開發的角色扮演遊戲,正處於需要
額外幫助的狀態。Condor,一家由Dave Brevik、Max Shaefer以及Erich Schaefer兄弟創
立的公司,僅編列120萬美元的預算 - 即使在那時候,也可以說是少得可憐。

東西,促使暴雪收購它,更名為Blizzard North,並開始投入開發此遊戲實際上需要的資

最初,我跟Collin Murray(星海爭霸的程式設計師)飛到Redwood市去幫忙,後來,包括


暗黑破壞神的開發規模越來越大,最後暴雪總部的每一個人 - 美術人員、程式設計師、


Dominion Storm等專案進行比較,其於六個月前的E3進行展示,看起來相當棒。


Something to prove

With everyone looking critically at StarCraft, it was clear that the project
needed to be vastly more ambitious than our previous ground-breaking efforts
in defining the future of the real-time strategy (RTS) genre with the first two
Warcraft games.

At the time of the StarCraft reboot, according to Johnny Wilson, then Editor
in Chief of Computer Gaming World, the largest-distribution gaming magazine
of that time, there were over eighty (80!!) RTS games in development. With so
many competitors on our heels, including Westwood Studios, the company that
originated the modern RTS play-style, we needed to make something that kicked

And we were no longer an underdog; with the successes of Warcraft and Diablo
continuing to fill the news we sure wouldn’t be getting any slack from
players or the gaming press. In the gaming world you’re only ever as good as
your last game. We needed to go far beyond what we’d done previously, and that
required taking risks.



在星海爭霸專案重啟的當下,根據Computer Gaming World(當時發行量最大的遊戲雜誌)
總編Johnny Wilson所言,當時有超過80款即時戰略遊戲正在進行開發,有這麼多的競爭
者,包括Westwood Studios(首創即時戰略遊戲類型的公司),我們需要作出些什麼對對手


New faces

Warcraft II had only six core programmers and two support programmers; that
was too few for the larger scope of StarCraft, so the dev team grew to include
a cadre of new and untested game programmers who needed to learn how to write
game code without much mentoring.

Our programming leadership was weak: we hadn't yet learned how essential it is
to provide guidance to less experienced developers early in the project so they
learn much-needed lessons before the game launches, so it was very much a
sink-or-swim proposition for new Padawans. A big part of the problem was just
how thin we were on the ground - every programmer was coding like mad to meet
goals, with no time for reviews, code-audits, or training.

And not only were there inexperienced junior members on the team, the leader of
the StarCraft programming effort had never architected a shipping game engine.
Bob Fitch had been programming games for several years with great results but
his previous efforts were game ports, where he worked within an existing
engine, and feature programming for Warcraft I and II, which didn't require
large-scale engine design. And while he had experience as the tech lead for
Shattered Nations, that project was canceled, therefore no validation of its
architectural decisions was possible.

The team was incredibly invested in the project, and put in unheard of efforts
to complete the project while sacrificing personal health and family life. I've
never been on a project where every member worked so fiercely. But several key
coding decisions in the project, which I’ll detail presently, would haunt the
programming team for the remainder of the project.



帕達瓦接受溺水或學會游泳的課題一樣。很大一部分的問題出在時程緊迫 - 導致每一個

計的經驗。Bob Fitch有多年遊戲程式設計經驗,並伴隨著成功的結果,但是他之前的經




Some things have changed

After spending months working to launch Diablo, and further months of cleanup
effort and patching afterwards, I returned to help with the reboot of
StarCraft. I wasn't looking forward to diving into another bug-fest, but that's
exactly what happened.

I thought it would be easy to jump back into the project because I knew the
Warcraft code so well - I'd literally worked on every component. I was instead
terrified to discover that many components of the engine had been thrown away
and partially rewritten.

The game's unit classes were in the process of being rewritten from scratch,
and the unit dispatcher had been thrown out. The dispatcher is the mechanism I
created to ensure that each game unit gets time to plan what it wants to do.
Each unit periodically asks: "what should I do now that I finished my current
behavior?", "should I re-evaluate the path to get where I'm going?", "is there
a better unit to attack instead of the one that I'm targeting now?", "did the
user give me a new command?", "I'm dead, how do I clean up after myself?, and
so forth.

There are good reasons code needs to be rewritten, but excising old code comes
with risks as well. Joel Spolsky said it most eloquently in Things You Should
Never Do, Part I:

It's important to remember that when you start from scratch there is absolutely
no reason to believe that you are going to do a better job than you did the
first time. First of all, you probably don't even have the same programming
team that worked on version one, so you don't actually have "more experience".
You're just going to make most of the old mistakes again, and introduce some
new problems that weren't in the original version.

The Warcraft engine had taken months of programming effort to get right, and
while it needed rework for new gameplay features, a fresh programming team
was now going to spend a great deal of time relearning lessons about how and
why the engine was architected the way it was in the first place.



我以為回到專案工作是容易的,因為我對於魔獸爭霸的程式碼的理解相當透徹 - 事實上

麼把自己清除呢?" 等等

有合理的理由說明程式碼需要被改寫,但是除去舊的程式碼同樣具有風險。Joel Spolsky

的舊錯誤重新再犯一次,並且再多增加一些舊版本所沒有的新問題。" (註)

註:摘錄自"約爾趣談軟體(Joel On Software)    Joel Spolsky 著    梅普華 譯

    悅之文化 出版


Game engine architecture

I wrote the original Warcraft engine for Microsoft DOS in C using the Watcom
Compiler. With the switch to releasing on Microsoft Windows, Bob chose to use
the Visual Studio compiler and re-architected the game engine in C++. Both were
reasonable choices but for the fact that - at that point - few developers on
the team had experience with the language and more especially with its many

Though C++ has strengths it is easy to misuse. As Bjarne Stroustrup, the
language’s creator, so famously said: "C makes it easy to shoot yourself in
the foot; C++ makes it harder, but when you do it blows your whole leg off."

History tells us that programmers feel compelled to try every feature of their
new language during the first project, and so it was with class inheritance in
StarCraft. Experienced programmers will shudder when seeing the inheritance
chain that was designed for the game’s units:

CUnit < CDoodad < CFlingy < CThingy

CThingy objects were sprites that could appear anywhere on the game map, but
didn't move or have behaviors, while CFlingys were used for creating particles;
when an explosion occurred several of them would spin off in random directions.
CDoodad - after 14 years I think this is the class name - was an uninstantiated
class that nevertheless had important behaviors required for proper functioning
of derived classes. And CUnit was layered on top of that. The behavior of units
was scattered all throughout these various modules, and it required an
understanding of each class to be able to accomplish anything.

And beyond the horror of the class hierarchy, the CUnit class itself was an
unholy mess defined across multiple header files:

class CUnit ... {
    #include "header_1.h"
    #include "header_2.h"
    #include "header_3.h"
    #include "header_4.h"
Each of those headers was several hundred lines, leading to an overall class
definition that could at best be called amusing.

It wasn't until many years later that the mantra "favor composition over
inheritance" gained credence among programmer-kind, but those who worked on
StarCraft learned the hard way much earlier.


軟視窗作業系統的轉變,Bob選擇使用Visual Studio編憶器,並使用C++重新架構遊戲引擎

C++有其長處,但也容易被誤用。就像C++之父Bjarne Stroustrup的名言:


CUnit < CDoodad < CFlingy < CThingy

爆炸發生時,許多CFlingy以隨機方向分散開來。CDoodad - 在過了14年之後,我想這是
一個類別名稱 - 是一個未具現化類別。CUnit則是最高層級的類別。單位的行為被分散在


class CUnit ... {
    #include "header_1.h"
    #include "header_2.h"
    #include "header_3.h"
    #include "header_4.h"


We're only two months from launch

With its troubled early history, after the reboot the development team was
pressured to finish up, and so schedules were bandied about that showed the
game could be launched in two months.

Given the number of game units and behaviors that needed to be added, the
changes necessary to switch from top-down to isometric artwork, a completely
new map editor, and the addition of Internet play over battle.net, it was
inconceivable that the game actually could ship in that time, even assuming
that the art team, designers, sound engineers, game-balancers and testers
could finish their end of the bargain. But the programming team continually
worked towards shipping in only two months for the next fourteen months!

The entire team worked long hours, with Bob working stretches of 40 hours, 42
hours, even 48 hours programming. As I recall no one else attempted these sorts
of masochistic endeavors, though everyone was putting in massive, ridiculous

My experiences developing Warcraft, with frequent all-nighters coding, and
later Diablo, where I coded fourteen-plus hour days seven days a week for
weeks at a time, suffered me to learn that there wasn’t any point in
all-nighters. Any code submissions [ha! what an appropriate word] written
after a certain point in the evening would only be regretted and rewritten in
the clear light of following days.

Working these long hours made people groggy, and that's bad when trying to
accomplish knowledge-based tasks requiring an excess of creativity, so there
should have been no surprises about the number of mistakes, misfeatures and
outright bugs.

Incidentally, these sorts of crazy hours weren't mandated - it was just the
kind of stuff we did because we wanted to make great games. In retrospect it
was foolish - we could have done better work with more reasonable efforts.

One of my proudest accomplishments was to ship four Guild Wars campaigns in a
two-year window without leading the development team down that dark path.









The most common cause of StarCraft game crashes

While I implemented some important features in StarCraft, including fog-of-war,
line-of-sight, flying unit pathing-repulsion, voice-chat, AI reinforcement
points, and others, my primary job gravitated to fixing bugs.

Wait: voice-chat! In 1998?!? Yeah: I had it all working in December 1997. I
used a 3rd-party voice-to-phoneme compressor, and wrote the code to send the
phonemes across the network, decompress them, and then play them back on the
other seven players' computers.

But every single sound-card in our offices required a driver upgrade to make
it work, if the sound card was even capable of full-duplex sound (simultaneous
recording and playback of sounds), so I regretfully made the recommendation to
scrap the idea. The tech-support burden would have been so high that we would
have spent more money on game support than we would have made selling the game.

So anyway I fixed lots of bugs. Some of my own, sure, but mostly the elusive
bugs written by other tired programmers. One of the best compliments I've
received came just a few months ago, when Brian Fitzgerald, one of two best
programmers I've had occasion to work with, mentioned a code-review of
StarCraft; they were blown away by how many changes and fixes I had made over
the entire code-base. At least I got some credit for the effort, if only well
after the fact!

Given all the issues working against the team, you might think it was hard to
identify a single large source of bugs, but based on my experiences the
biggest problems in StarCraft related to the use of doubly-linked linked

Linked lists were used extensively in the engine to track units with shared
behavior. With twice the number of units of its predecessor - StarCraft had
a maximum of 1600, up from 800 in Warcraft 2 - it became essential to optimize
the search for units of specific types by keeping them linked together in

Recalling from distant memory, there were lists for each player's units and
buildings, lists for each player's "power-generating" buildings, a list for
each Carrier's fighter drones, and many many others.

All of these lists were doubly-linked to make it possible to add and remove
elements from the list in constant time - O(1) - without the necessity to
traverse the list looking for the element to remove - O(N).

Unfortunately, each list was "hand-maintained" - there were no shared
functions to link and unlink elements from these lists; programmers just
manually inlined the link and unlink behavior anywhere it was required. And
hand-rolled code is far more error-prone than simply using a routine that's
already been debugged.

Some of the link fields were shared among several lists, so it was necessary
to know exactly which list an object was linked into in order to safely
unlink. And some link fields were even stored in C unions with other data
types to keep memory utilization to a minimum.

So the game would blow up all the time. All the time.






不堪的程式設計師所撰寫的。幾個月前,Brian Fitzgerald(他是我合作過的程式設計師中







不幸的是,每個串列都是"手工維護"的 - 沒有共用的函式去鏈結及取消鏈結這些串列,程



But why did you do it that way?

Tragically, there was no need for these linked-list problems to exist. Mike
O'Brien, who, along with Jeff Strain, cofounded ArenaNet with me, wrote a
library called Storm.DLL, which shipped with Diablo. Among its many features,
storm contained an excellent implementation of doubly-linked lists using
templates in C++.

During the initial development of StarCraft, that library was used. But early
in the development the team ripped out the code and hand-rolled the linked-lists
, specifically to make writing save-game files easier.

Let me talk about save games for a second to make this all clearer.


一切都是悲劇阿!其實這些鏈結串列問題根本就不該存在。我跟Mike O’Brien及Jeff



Save games

Many games that I played before developing Warcraft had crappy save-game
functionality. Gamers who played any game created by Origin will remember how
looooooong it took to write save-game files. I mean sure, they were written
by slow microprocessors onto hard-drives that - by today's standards - are
as different as tricycles and race cars. But there was no reason for them to
suck, and I was determined that Warcraft wouldn't have those problems.

So Warcraft did some tricks to enable it to write large memory blocks to disk
in one chunk instead of meandering through memory writing a bit here and
there. The entire unit array (600 units times a few hundred bytes per unit)
could be written to disk in one chunk. And all non-pointer-based global
variables could similarly be written in one chunk, as could each of the
game-terrain and fog-of-war maps.

But oddly enough, this ability to write the units to disk in one chunk wasn't
essential to the speed of writing save game files, though it did drastically
simplify the code. But it worked primarily because Warcraft units didn't
contain "pointer" data.

StarCraft units, which as mentioned previously contained scads of pointers in
the fields for linked lists, was an entirely different beast. It was necessary
to fixup all the link pointers (taking special care of unioned pointer fields)
so that all 1600 units could be written at once. And then unfixup the link
pointers to keep playing. Yuck.






Change back!

So after fixing many, many linked list bugs, I argued vehemently that we should
switch back to using Storm's linked lists, even if that made the save-game code
more complicated. When I say "argued vehemently", I should mention that was
more or less the only way we knew how to argue at Blizzard - with our youthful
brashness and arrogant hubris, there was no argument that wasn't vehement
unless it was what was for lunch that day, which no one much wanted to decide.

I didn't win that argument. Since we were only "two months" from shipping,
making changes to the engine for the better was regularly passed over for
band-aiding existing but sub-optimal solutions, which led to many months of
suffering, so much that it affected my approach to coding (for the better) ever
since, which is what I'll discuss in part two of this article.




More Band-Aids: path-finding in StarCraft

I wanted to mention one more example of patching over bugs instead of fixing
the underlying problem: when StarCraft switched from top-down artwork to
isometric artwork, the background tile-graphics rendering engine, which dated
back to code I had written in 1993/4, was left unchanged.

Rendering isometric-looking tiles using a square tile engine isn't hard, though
there are difficulties in getting things like map-editors to work properly
because laying down one map tile on another requires many "edge fixups" since
the map editor is trying to place diagonally-shaped images drawn in square

While rendering isn't so bad, isometric path-finding on square tiles was very
difficult. Instead of large (32x32 pixel) diagonal tiles that were either
passable or impassable, the map had to be broken into tiny 8x8 pixel tiles -
multiplying the amount of path-searching by a factor of 16 as well as creating
difficulties for larger units that couldn't squeeze down a narrow path.

Had Brian Fitzgerald not been a stellar programmer, the path-finding problem
would have prevented the game from launching indefinitely. As it was pathing
was one of the problems that was only finalized at the end of the project. I
plan to write more about path-finding in StarCraft because there are lots
interesting technical and design bits.

更多的OK蹦: 星海爭霸的路徑搜尋



通過大的(32x32像素)對角線砌塊,地圖是以小的8x8像素組成 - 使得路徑搜尋以16倍的

要不是Brian Fitzgerald是一位一流的程式設計師,本來路徑搜尋的問題將使得這款遊戲

End of part 1
So you've heard me whine a bit about how difficult it was to make StarCraft,
largely through poor choices made at every level of the company about the
game's direction, technology and design.

We were fortunate to be a foolhardy but valiant crew, and our perspicacity
carried the day. In the end we buckled down and stopped adding features long
enough to ship the game, and players never saw the horror show underneath.
Perhaps that's another benefit of compiled languages over scripted ones like
JavaScript - end users never see the train wreck!

In part two of this article I'm going to get even more technical and talk
about why most programmers get linked lists wrong, then propose an alternative
solution that was used successfully for Diablo, battle.net and Guild Wars.

And even if you don't use linked-lists, the same solutions carry over to more
complex data structures like hash tables, B-trees and priority queues.
Moreover, I believe the underlying ideas generalize well to all programming.
But let's not get ahead of ourselves; that's another article.

Thanks for reading this far, and sorry I haven't yet discovered how to write

filed under: game design, programming tagged with: starcraft



本語言的地方 - 終端使用者絕不會看見火車失事!




※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From:
※ 編輯: zabiak          來自:       (09/10 22:42)
dl4303:推1F 09/10 22:42
std94003:推推2F 09/10 22:47
doom3:END推3F 09/10 22:50
KYPKYPKYP:學過程式推  好猛阿~4F 09/10 22:51
justastupid:好神 英文也太好了5F 09/10 22:53
Vett:看到linked list的死當   真是妙到一個不行6F 09/10 22:54
huggie:讚讚讚!!7F 09/10 22:55
suwilliam:人家是這樣堅持品質(燒錢)反觀國內......難怪被韓國超車8F 09/10 22:56
OSDim:樓上那是員工自主賣命阿,哪有燒錢9F 09/10 22:59
bbyan:所以在世界末日之前玩不到蟲心了嗎 QQ11F 09/10 23:01
moongloaming:不解釋了~12F 09/10 23:03
derswarm:推 翻得真好13F 09/10 23:05
dakkon:蟲心也才剛beta,就算不用六個月.四個月也總是要的14F 09/10 23:06
cji4284503:這麼認真翻譯只能推了QQ 大感謝!!!15F 09/10 23:07
ck321:好強喔 真想看他們寫的程式 TAT16F 09/10 23:07
Sechslee:不推不行17F 09/10 23:09
crazymagic00:英文推推推推推推推推推推!!!18F 09/10 23:09
PTTco:CS的只能推了19F 09/10 23:10
imunknown:20F 09/10 23:10
VenceYen:同為RD只能淚推...21F 09/10 23:12
MaySnow2010:寫得很好,翻譯也很棒!!值得鼓勵,大推!!22F 09/10 23:13
VenceYen:不過現在開發應該會更容易23F 09/10 23:13
Sechslee:"只有在合理的工時下,才可以完成品質更好的作品。"24F 09/10 23:18
hahahaha5438:星海爭霸之始--->  穩定度"剩"過其他同業的前作25F 09/10 23:19
zseineo:推26F 09/10 23:19
nilson847552:"只有在合理的工時下,才可以完成品質更好的作品。"27F 09/10 23:20
oscarss07:這麼長的翻譯只能推了28F 09/10 23:20
Puser:29F 09/10 23:20
jhunfong:推翻譯!!!!30F 09/10 23:23
wtao: 原來Diablo 太成功 讓SC1完整了才敢上架@_@31F 09/10 23:27
wtao:  果真成也Diablo  敗也Diablo
Lioli:大推翻譯官33F 09/10 23:29
paul81611:推高品質翻譯!34F 09/10 23:35
CaTkinGG:推!看到錯誤的設計方向讓之後的臭蟲只能貼OK繃心有戚戚焉35F 09/10 23:41
always123x:專業推36F 09/10 23:43
FAlin:翻譯專業推!!37F 09/10 23:45
Infernity:超扯!!38F 09/11 00:01
aCCQ:推~39F 09/11 00:05
bobjohns:我覺得SC1做的比SC2好 光 音效跟圖 就贏了40F 09/11 00:19
only1032:感謝翻譯41F 09/11 00:22
wtao:    BZ 以往的音樂都很用心 幾乎都很有特色獨創42F 09/11 00:29
yuiweq1999:大推翻譯~翻得好好看噢QQ43F 09/11 00:39
Emerson158:"想要從頭開始時,請不要抱著這次會做得比第一次好的想44F 09/11 01:30
Emerson158:法。"  ...有深刻體會過
jackalin2002:讓我一直想起八掛那篇 講德國人精神跟台灣人精神...47F 09/11 01:42
rssai:SC1真是難以跨越的巨牆~~SC2目前也難以超越48F 09/11 04:23
photopanda:裡面提到的兩家遊戲公司/工作室都被EA吃掉了,回不來了49F 09/11 04:52
LZong:原來SC1的程式設計上是這麼可怕的東西...51F 09/11 07:43
PanXPan:推!52F 09/11 10:02
oceanocean:太不簡單啦~推推53F 09/11 13:44
little76d:推翻譯54F 09/11 14:00
carlk:推翻譯太強大了= =55F 09/11 14:37
OpenSolaris:同是RD幫推,雖然有些還不是看得懂。56F 09/11 15:57
onelife:好文推~ 原po願不願意也轉錄到GameDesign版?57F 09/11 19:55
zabiak:忘了說  大家可以隨意轉錄  進行交流  但這篇文章應該會被58F 09/11 21:05
zabiak:瘋狂吐槽  因為我沒有任何開發遊戲的經驗  對於電腦繪圖理
zabiak:論也是一竅不通  XD
losesong:很詳實的心路歷程 推!61F 09/12 11:40
Falldog:推62F 09/12 16:00
onelife:感謝同意轉錄~63F 09/12 21:32

※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: onelife (, 時間: 09/12/2012 21:32:27
tsl3333:推64F 09/12 22:55
changyin:推65F 09/12 23:15
skyhawkptt:推!!專業翻譯精彩好文66F 09/13 02:03
k387259:推哦 原來心路歷程這麼...~~可以讓我轉貼嗎67F 09/13 03:03
Bencrie:原來 Origin 有遊戲存檔很久的特色 XD68F 09/13 09:24
Bencrie:難怪 Ultima VIII - Pagan 剛出的時候被罵翻了
Bencrie:Avatar 常常被機關整死,搞得玩家走一小段路就得存檔
Bencrie:偏偏存檔以當時的硬體來說又存超慢,讓人超不爽 XD
chenglap:「僅編排 120 元的預算」這句真是令人心痛.72F 09/13 11:30
chenglap:「僅編列 120 萬元預算」
tobygameac:他的blog好棒!74F 09/13 11:32
chenglap:「甚至犧牲個人的家庭和健康」在我們這邊是基本要求...75F 09/13 11:34
chenglap:就算如此, 我們這邊大規模的企劃預算還不及別人 1/3.
Ebergies:樓上拍拍 XD77F 09/13 11:55
alsh:SC的路徑搜尋居然到上市前才作完 這功能超強的...78F 09/13 12:07
alsh:SC的尋路效果比之後的AOE AOC還好很多
dragoni:大推啊!!!!80F 09/13 12:38
lf21201:看完推 翻譯推81F 09/13 13:31
bachi95:好文推!82F 09/13 14:31
silveriii:push83F 09/13 16:11
a83a83cjcj:推 T^T84F 09/14 15:45
lc85301:太厲害了…85F 09/15 22:13

※ 同主題文章:
※ 看板: FW 文章推薦值: 0 目前人氣: 0 累積人氣: 636 
r)回覆 e)編輯 d)刪除 M)不收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇