The Life and Times of an 80’s Game Programmer – Putting it all together | 80년대 게임 프로그래머의 삶과 시간 – 모두 합쳐서

GraphicSheets
Nick Marentes Graphic Sheets

How does game development back in the early 80’s compare to game development today?

현재의 게임 개발과 비교해 볼 때, 1980년대 초반에 게임을 개발한다는 것은 어떤 것이었는가?

 

한국어 번역본이 아래에 이어집니다. (Korean below.)

By Nickolas Marentes (originally published on Play it Again on December 28, 2013)

How does game development back in the early 80’s compare to game development today?

For starters, the computers of that era were far less powerful  and didn’t have anywhere near the graphics and audio capabilities of today’s power houses. My TRS-80 was monochrome and offered a graphic resolution of only 128 x 48 pixels and sound was generated by toggling the cassette output port on and off.

Back then, a computer generally ran at around 2 megahertz and a fast one did 4 megahertz.  We played with RAM sizes of 4K to 64K and unless you were lucky enough to afford a floppy disk drive, you saved all your work on cassette tapes.

Compared to today, programmers worked with quite primitive equipment but we just got on with the job and developed to the best of our abilities with whatever we could afford.

There were no boundaries to creativity.

I developed most of my TRS-80 Model 1 games in Z-80 assembly language. This code compiles to raw machine language and almost all commercial arcade style games of the era were created in this language since it allowed the maximum processing speed from the technology of the day.

Programming in assembly language was not for the faint hearted, not so much because it was a hard language to learn but because each instruction did so little in comparison to other higher level languages. To print a word on the screen required a mini program in itself whereas languages such as BASIC could achieve this by simply executing the command PRINT”HELLO WORLD”.

Assembly language requires a thorough understanding of the operation of the computer and how the hardware operated and I enjoyed this feeling of total control of the system. Being tied so closely to the hardware also made for some spectacular system crashes when errors were made. Assembly language was a very “precise” language with little margin for error. A programmer had to have a clear understanding in his mind of what the computer was doing at all times.

I wrote all my code, routine by routine, with pencil and paper. I didn’t have a printer so my hand written notes served as the hardcopy of my code to peruse at any time. It also meant I could create code anywhere… even during classes in high school!

The teacher may have been talking chemistry but mind was piecing together the code to my next blockbuster game!

This also filled in the time during cassette tape loads. Loading data from cassette tape would take about 3 minutes to load the assembly language development program (Editor/Assembler) into the computer. It would then take another 5 minutes to load my source code that I had created so far. During this time I was creating new code on paper or debugging an error with my current code. When the tape finished loading, I transcribed my new lines to the Editor/Assembler.

I then saved my new work back to cassette tape (another 5 minutes) then compiled my code to machine language (3 more minutes) into an executable file.

After resetting the computer, I would load the compiled code into the computer for testing. If it worked, I would move on to create the next piece of code. If it failed, then the whole cassette loading process would repeat until I finally had it debugged and working correctly.

I would always use high quality cassette tapes for my development work and I would frequently clean the cassette tape heads with alcohol to maintain reliability.

For graphics design, there was no Photoshop or fancy graphics editors back then. I designed all of the graphics on graphic worksheets with a pencil and eraser. I would create pages of graphic objects and level layouts.

Then I would create a simple program in BASIC to recreate these graphics into the memory of the computer and save these to a cassette file. I documented all of the dimensions  and memory locations of all the graphics so that I could access them from within my code.

When a game was finished, I created my own packaging and recorded each distribution cassette on my computer. My artwork was all hand drawn and quite amateurish but it was all I could afford.

The artwork, instruction sheet and cassette tape was then put into click seal “zippy” plastic bags for sale.

In summary, I think the basic process of game design and product manufacturing hasn’t changed too much. It’s just that it is more “refined” and better funded.  I was only a kid at school with no money so I did everything myself on a shoestring budget. I am proud of what I achieved and can honestly say that not many could do what I did.

They were the early “Halcyon Days” of the game industry when we felt we were creating something new and special. These experiences will remain with us forever.


원문 출처: “80년대 게임 프로그래머의 삶과 시간 – 모두 합쳐서” (The Life and Times of an 80’s Game Programmer  – Putting it all together), 닉M(NickM ), 2013년 12월 28일, playitagainproject.org

편집자 개요: 이 글은 취미 개발자 학생이었던 닉 매런츠(Nick Marentes)가 티알에스80(TRS80)의 제약 속에서 게임을 설계하는 일이 어땠는지, 그 개발 과정, 그가 참고한 책들, 손으로 쓴 코드와 직접 그린 그림을 공유하면서 전해주고 있다.

 

현재의 게임 개발과 비교해 볼 때, 1980년대 초반에 게임을 개발한다는 것은 어떤 것이었는가?

초보자에게 당시 컴퓨터는 성능이 영 시원찮았고, 현재와 같은 그래픽이나 사운드의 성능을 찾아볼 수가 없었다. 나의 티알에스-80(TRS-80)은 흑백에 해상도가 단지 128 x 48 픽셀이었고, 사운드는 카세트 출력 포트를 껐다켰다 하면서 생성시킬 수 있었다.

당시 컴퓨터는 보통 2메가헤르츠로 돌아갔고 빠르면 4메가헤르츠였다. 운좋게 플로피 디스크 드라이브를 살 형편이 못 되어, 우리는 4K에서 64K까지의 램 크기를 비교하며 놀았고, 모든 작업물을 카세트 테잎에 저장했다.

오늘날과 비교할 때 프로그래머는 상당히 원시적인 장비로 작업했는데, 일거리를 얻고 할 수 있는 한 최선을 다해 개발했던 시절이다.

창조성에는 경계가 없는 법.

나는 대부분의 나의 티알에스-80 모델1용 게임을 제트-80(Z-80) 어셈블리어로 개발했다. 이 코드는 날 기계어로 컴파일되는데, 그럼으로써 처리 속도를 최대치로 낼 수 있게 해주었기 때문에 당시 거의 모든 상업적 아케이드 스타일의 게임이 이 언어로 만들어진 것이다.

어셈블리어 프로그래밍은 심약한 사람에게는 적합하지 않은데, 배우기 어려워서라기보다는 다른 고등 언어와 비교할 때 각 명령어가 하는 일이 별로 없기 때문이다. 화면에 단어를 출력하게 하려면 그 자체로 작은 프로그램을 짜야 하는데, 베이식 같은 것은 단지 간단한 명령어 – “안녕, 이 세상이여” 출력하라 -만 넣으면 실행되는 것이다.

어셈블리어는 컴퓨터의 작동과 하드웨어 작동 방식에 대한 철두철미한 이해가 필요한데 나는 이 시스템에 대한 모든 것을 제어할 수 있다는 느낌이 참 좋았다. 하드웨어에 근접해 있다면 에러가 생겼을 때의 볼 만한 시스템 충돌 역시 만들어낼 수 있었다. 어셈블리어는 오차 범위가 거의 없는 아주 “정밀한” 언어다. 프로그래머는 그 언제든지 컴퓨터가 지금 무엇을 하고 있는지에 대해 잘 알고 있어야 한다.

나는 모든 코드를, 루틴별로, 종이와 연필로 작성했다. 인쇄기가 없었고 손으로 작성한 공책이 언제든 정독해 볼 수 있는 내 코드의 출력 자료였다. 이는 곧 어디서나 나는 코드를 작성할 수 있다는 것을 뜻했다.  고등학교 수업시간에도!

 

선생님은 화학에 대해 말씀하고 계실 때 내 머릿속에서는 코드가 엮여져 나의 이번 대박 게임이 만들어지고 있었다.

이는 또한 카세트 테잎에서 불러들이는 동안의 시간을 벌도록 했다. 어셈블리어 개발 프로그램(편집기/어셈블러)를 카세트 테잎에서 컴퓨터로 불러들이는 데 3분 정도 걸렸다. 그리고 내가 지금까지 작성한 소스코드는 5분정도 걸렸다. 이 시간동안 나는 종이에 새로운 코드를 써보거나 이미 작성한 것의 에러를 고치기도 했다. 다 올려졌으면, 나는 나의 새로운 코드 줄들을 편집기/어셈블러에 옮겼다.

그런 다음 새 작업물을 다시 카세트 테잎에 저장을 (다시 5분에 걸쳐) 하고, 내 코드를 기계어로 컴파일을 (3분 더 걸려) 해서 실행 파일을 만든다.

컴퓨터를 다시 세팅한 후에 컴파일된 코드를 컴퓨터로 불러들여 시험을 해본다. 잘 돌아가면 새로운 코드 작업으로 넘어가고, 안 돌아가면 될 때까지 카세트 테잎에서 불러들이는 과정을 반복하면서 고치는 것이다.

나의 개발 작업을 위해 나는 언제나 고품질의 카세트 테잎을 썼고 테잎 헤드를 알코올로 청소해주며 기기의 신뢰도를 유지했다.

그래픽 디자인의 경우, 포토숍 같은 세련된 편집기가 당시에는 없었다. 종이와 지우개를 가지고 그림 연습장에 모든 그래픽 작업을 했다. 그래픽 오브제와 단계 배경그림을 위한 페이지를 만들어댔다.

 

그리고 베이식으로 단순한 프로그램을 짜서 이 그림들을 컴퓨터의 메모리에 다시 만들어 넣고 이를 카세트 파일에 저장했다. 모든 그래픽의 각 차원과 메모리 위치를 일일이 기록해 둬서 코드 내에서 필요할 때 써먹을 수 있었다.

게임 개발이 끝나면, 패키지를 만들고 컴퓨터에서 각 배포 카세트에 기록해 넣었다. 내가 그린 삽화는 모두 손으로 그린 것인데, 아마추어적이었지만 내가 다 할 수 있는 것들이었다.

 

삽화, 설명서, 카세트 테잎을 똑딱이 밀봉 비닐봉투에 넣으면 이제 팔 수 있었다.

게임 설계와 제품 생산의 기본 과정은 많이 변하지 않았다고 본다. 더 “정교해지고” 더 나은 자금 하에 이루어지는 것이다. 나는 돈 없는 학생이었고 몇 푼 안 되는 돈으로 나 혼자 북치고 장구치고 한 것이다. 나는 내가 만들어낸 것들이 뿌듯하고, 사실 많은 사람들이 나처럼 할 수 있었던 것이 아닐 것이다.

우리는 뭔가 새롭고 특별한 것을 창조한다는 느낌이 있었고, 그 때가 게임산업 초기의 “태평성대”(Halcyon Days)였다. 이런 경험은 영영 우리 말고 더 없을 것이다.

 


댓글

 

케빈 필립스(Kevin Phillips, January 31, 2014)

1980년대, 32k가 다고 “게임엔진”같은 것은 꿈도 못 꿀 때, 게임 개발은 손으로 코드를 작성하는 일이었다. 그것은 단지 게임만이 아니라, 그래픽 기능, 사운드 기능, 자판과 조이스틱에 반응하도록 하는 코드, 게임 논리 자체까지 그 모든 것을 포함한다. 게임이 저장해야 하는 그래픽, 음악, 점수, 게임 수준 데이터 등등의 모든 정보를 지금보자면 너무나 보잘 것 없는 메모리 안에 때려넣어야 하는 것이었다.

이것은 모든 코드가 작동하는 데 최적화되어야 하는 일인데, 내 생각으로는 현재의 개발자는 굳이 고려하지 않아도 되는 일이 되었다. 대량의 램이 있으니 우쭐하게 되고, 씨피유/쥐피유(CPU/GPU) 속도가 엄청 빨라지니까 80년대에는 흔히 도전거리였던 것들을 이제 더 신경쓸 필요가 없고, 모든 복잡한 코드가 이미 장착된 “게임 엔진”이 넘쳐나니까 단지 그림 좀 넣고 논리 좀 짜면 되게 되었다.

바로 그렇기 때문에 기계 코드가 당시에는 아주 결정적이었던 것이다. 베이식은 대부분의 작업에 꽤 쓸만한 프로그래밍 언어였지만 그 속도가 너무 느려서 화면을 재빠르게 바꿔주지 못했고, 조이스틱이나 자판에 반응도 느렸고, 우리편과 외계인의 위치를 잡아주거나 사운드 효과를 제 때 내는 데도 느렸다. 내가 훨씬 수준높은 게임을 개발하려고 했을 때, 도깨비를 그린다거나 소리를 넣는다거나 하는 결정적인 기능들을 기계 코드로 작성했다. 그러면 그것들이 베이식으로 작성된 게임 안에서 호출되는 것이다. 그렇게 해서 양 쪽의 장점을 최대로 살린 것인데, 베이식으로 게임과 그 논리 개발을 더 쉽게 하면서도 기계 코드를 통해 실로 집약적인 작업들을 엄청 빠른 속도로 처리한 것이다.

나중에 나는 전적으로 기계 코드만으로 게임을 코딩했고, 그렇게 하면서 단지 언어를 이해하는 것만이 중요한 것이 아니라, 각각의 씨피유(CPU) 명령이 실행되는 데 걸리는 시간도 그만큼 중요하다는 것을 발견했다.

내가 개발하려고 했던 수평 이동자 게임(sideways scroller)가 생각나는데, 그것은 시차 이동 별들(parallax scrolling stars)과 수많은 도깨비들이 표시되어야 하는 것이었다. 당시에 가장 어려운 일은 모든 것이 화면 메모리를 직접 잡아먹는다는 것이었고, 그것은 곧 도깨비나 다른 요소들을 화면에 잽싸게 나타나게 했다가 다시 잽싸게 지워서 새롭게 다시 나타나게 할 수 있는 술술 잘 짠 코드가 결정적이라는 것이다.  처리해야 할 것들이 많았을 때 기계 코드가 빠른만큼, 티브이 화면이 빨리빨리 안 바뀌기 일쑤였고(초당 25번), 80년대 게임에 깜빡거리는 화면이 많은 이유가 바로 그것 때문이다.

나도 게임코드 참고서가 있었는데 그 책에는 연산코드(기계 코드 명령)와 함께 각각의 티-상태(t-states)도 있었다. 티-상태는 명령이 프로세서 안에서 실행될 때 걸리는 마이크로초(100만분의 1초)의 숫자다.

내가 지금껏 게임을 작성할 때 화면에 그리려고 한 것이 빠르고 단지 몇 마이크로초밖에 안 걸리는 방식으로 했다는 것을 알게 되었지만 … 그 시간 동안에 여러 개의 이미지와 도깨비를 나타나게 하려고 했을 때, 깜빡거림의 문제가 있는 것이다.

어떻게 하면 이동하는 화면에서 그래픽을 부드럽게 불러들이게 할까 고민하면서, 나는 메모리에 우선 그래픽을 만들어 놓고 실제 화면 자체에 모든 것을 다시 뿌려주는 방식을 생각했다. 이것이 현재 많은 게임 엔진에서 구현하는 방식이 되었는데 – 백버퍼(back buffer), 먼저 게임의 그래픽 이미지를 만들어놓은 화면의 복사본이 있고, 그것을 바꿔가면서 표시해주는 것이다. 이렇게 하면, 그려주고 지워주는 것이 화면 밖에서 먼저 이루어지면서 깜빡거림을 완전히 없앨 수 있게 된다.

그렇게 해봤더니 잘 됐는데, 하나의 메모리 주소에서 화면 메모리로 정보를 복사하는 것은 여전히 느려서 화면상의 작은 움직임을 만들어내는 데도 안 좋았다. 참고서를 확인해 봤을 때, (씨피유가 데이터를 저장하는 메모리의 영역을 이르는) 스택(stack)에서 데이터를 밀어넣고(저장) 띄우는(검색) 단순 명령의 티-상태는 나의 복사 코드보다 5배 빠른 것이었고… “메모리에서 바이트를 가져오고” 그리고 “화면 메모리에 바이트를 쓰는데” 2나 3이 아니라 단지 하나의 명령으로 다 되는 것이었다.

이 스택과 연동하는 연산코드는 꽤 괜찮은 선택사항 같았다. 한번은 내가 게임 화면을 메모리로 넣었을 때, 나는 이 “스택” 메모리 위치를 화면 메모리로 변경하도록 코드를 썼다. 그리고 이 “스택”으로 화면을 넣었던 메모리로부터 데이터를 밀어넣기만 하니까 화면 메모리가 엄청 빠르게 채워졌다.

비올레(Viole)! 놀랍게도 부드럽게 이동하는 그래픽, 더 이상의 깜빡임 없이!

이런 소소한 이야기가 80년대 게임 프로그래밍이 나에게 어떤 것이었는지를 잘 알려준다. 단지 게임을 개발한다는 것만이 아니라, 메모리가 사용되는 방식을 최적화하는 데 수많은 밤을 지새면서 빠른 코드를 개발해 내는 하나의 도전이었던 것이다… 1980년대 프로그래머들이 괴짜(geek)나 광(nerd)으로 불린 이유도 이런 류의 것들 때문이다. 코드 최적화의 전율을 즐기려면 “괴짜처럼” 해야 하는 것이다… 재밌는 시절이었다!

말했듯이, 지금은 기술이 다 손봐준다. 긴 길을 걸어온 것인데, 모든 일이 그렇듯이 이런 일도 어딘가에서 시작해야 하는 것이다. :)

 

케빈 필립스 (Kevin Phillips, February 14, 2014)

관심있는 사람들을 위해, 수평 이동자 게임(side-scroller) 개발을 위한 공책을 찾아 스캔했다. 이 모두는 사랑과 정성을 담아 손으로 깔끔하게 써내려간 알고리즘이자 개념이자 제트80 코드이다.

https://drive.google.com/file/d/0B-yNJZpBnrutTVlrNXpmSWRiYTg/edit?usp=sharing

 

번역: DongwonJ

Share

1 thought on “The Life and Times of an 80’s Game Programmer – Putting it all together | 80년대 게임 프로그래머의 삶과 시간 – 모두 합쳐서”

Leave a Reply

Your email address will not be published. Required fields are marked *