렌즈 #81: 캐릭터 변화의 렌즈

강력한 이야기는 그 속의 캐릭터를 변화시킬 수 있다. 캐릭터가 흥미로운 방법으로 변화하도록, 다음과 같이 자문해 보라.

• 게임의 캐릭터들이 게임 속에서 어떻게 변화할까?
• 그 변화를 플레이어에게 어떻게 이야기할까? 좀 더 명확하게, 혹은 좀 더 강하게 이야기할 수 있을까?
• 충분히 변화하는가?
• 그 변화는 놀랍고 흥미로운가?
• 그 변화는 그럴듯한가?

렌즈 #82: 내적 모순의 렌즈

좋은 게임은 게임 본연의 목적을 해하는 특성을 담아서는 안 된다. 이런 모순적 특징을 제거하기 위해 다음과 같이 자문해 보라.

• 이 게임의 목적은 무엇인가?
• 이 게임의 각 보조 시스템의 목적은 무엇인가?
• 이 목적들과 모순되는 요소가 게임 안에 있는가?
• 존재한다면, 어떻게 바꿀 수 있을까?

렌즈 #83: 이름 없는 특질의 렌즈

자연스럽고 유기적 디자인 때문에 특별하고 훌륭하게 느껴지는 것이 있다. 게임이 이런 특성을 갖도록 다음과 같이 자문해 보라.

• 생명이 가지는 특별한 느낌을 이 디자인이 갖고 있는가? 아니면 내 디자인의 일부가 죽은 것처럼 느껴지는가? 무엇이 내 디자인을 살아 있는 듯 느껴지게 할까?
• 이 게임은 알렉산더의 15가지 특성 중 무엇을 갖고 있는가?
• 이보다 더 많은 특성을 갖고 있는가?
• 이 디자인이 내 자신처럼 느껴지는 곳은 어디인가?

알렉산더의 살아 있는 구조물의 15가지 특성

1. 여러 규모의 수준
2. 강력한 중심
3. 경계
4. 교차 반복
5. 완전한 공간
6. 좋은 형태
7. 부분적 대칭
8. 깊은 연도오가 모호함
9. 대비
10. 변화
11. 거칠기
12. 반향
13. 공백
14. 단순함과 내적 고요
15. 비 단독성

렌즈 #84: 친교의 렌즈

사람은 친구와 플레이하는 것을 좋아한다. 게임에서 사람들이 친구를 만들고 친교를 유지할 수 있도록, 다음과 같이 자문해 보라.

• 플레이어는 어떤 친교 관계를 원하는가?
• 플레이어가 아이스브레이킹하는 방법은 무엇인가?
• 플레이어가 서로 이야기할 기회가 충분히 있는가? 충분히 이야기할 소재가 있는가?
• 친구가 되는 순간은 어떤 때인가?
• 플레이어가 친교를 유지하게 하는 수단은 무엇인가?

렌즈 #85: 표현의 렌즈

플레이어에게 자신을 표현할 기회를 주면, 플레이어는 살아 있고, 자부심에 넘치고, 중요하고, 연결돼 있다고 느끼게 된다. 이 렌즈를 사용하려면 다음과 같이 자문해 보라.

• 어떻게 플레이어가 자신을 표현할 수 있게 해 줄까?
• 무엇을 잊고 있는 것일까?
• 플레이어가 자신의 정체성에 자부심을 느끼는가? 그렇든 아니든 그 이유는 무엇인가?
  이 렌즈는 중요하면서도 늦은 감이 있다. 이 렌즈는 여타 렌즈와 섞어서 활용하기 좋은데, '렌즈 #63: 아름다움의 렌즈', '렌즈 #80: 지위의 렌즈'가 그런 예다.

렌즈 #86: 커뮤니티의 렌즈

게임이 강한 커뮤니티를 형성하게 하기 위해 다음과 같이 자문해 보라.

• 어떤 갈등이 커뮤니티의 핵심인가?
• 아키텍처가 커뮤니티를 어떻게 구체화하는가?
• 게임은 경험의 세 레벨을 지원하는가?
• 커뮤니티 이벤트가 있는가?
• 왜 플레이어는 서로를 필요로 하는가?

렌즈 #87: 그리프 행위의 렌즈

게임에서의 그리프 행위를 최소화하려면, 다음과 같이 자문해 보라.

• 게임의 어떤 시스템이 그리프 하기 쉬운가?
• 어떻게 하면 게임에서 그리프 행위가 지루하게 할 수 있을까?
• 허점을 간과하고 있는 것은 아닐까?

렌즈 #88: 사랑의 렌즈

이 렌즈를 쓰려면 다음과 같이 자문해 보라.

• 나는 이 프로젝트를 사랑하는가? 아니라면 어떻게 바꿀 수 있을까?
• 팀의 모두가 이 프로젝트를 사랑하는가? 아니라면 어떻게 바꿀 수 있을까?

렌즈 #89: 팀의 렌즈

팀이 기름칠 잘 된 기계처럼 돌아가도록, 다음과 같이 자문해 보라.

• 이 프로젝트에 적합한 팀일까? 그 이유는 무엇인가?
• 팀이 객관적으로 의사소통하는가?
• 팀이 명쾌하게 의사소통하는가?
• 팀은 서로 편안하게 의사소통하는가?
• 팀원 사이엔 신뢰와 존중의 분위기가 흐르는가?
• 팀은 결정 후 결과적으로 단결할 수 있는가?

렌즈 #90: 문서의 렌즈

필요한 문서를 작성하고 필요 없는 것은 피하려면, 다음과 같이 자문해 보라.

• 이 게임을 만들면서 기억해야 하는 것은 무엇인가?
• 이 게임을 만들면서 소통해야 하는 것은 무엇인가?

참고 문헌 : Jesse Schell. The Art of Game Design. 에이콘 출판사, 2010.

7.1 교착상태 회피

• 프로세스의 자원 사용에 대한 사전 정보를 활용하여 교착상태가 발생하지 않는 상태에 머물도록 하는 방법
  • 사전 정보 : 현재 할당된 자원, 가용상태의 자원, 프로세스들의 최대 요구량

7.1.1 안전상태와 안전순서열

• 안전상태
  • 교착상태를 회피하면서 각 프로세스에 그들의 최대 요구량까지 빠짐없이 자원을 할당할 수 있는 상태
  • 안전순서열이 존재하는 경우로, 교착상태에 빠지지 않고 모든 프로세스가 종료 가능
• 안전순서열
  • 순서 있는 프로셋의 집합 <p_1,p_2···,p_n>
  • 각 프로세스 p_i는 p_i가 추가로 요구할 수 있는 자원의 양이 다음 주 한가지는 만족한 경우
    • 현재 가용상태의 자원으로 충당 가능
    • 현재 가용상태인 자원에 i>j인 프로세스 p_j에 할당된 자원까지 포함하여 충당 가능
• 불안전상태
  • 안전순서열이 존재하지 않는 경우
  • 자원의 할당과정에 따라 교착상태가 될 수도 있고 아닐 수도 있음
• 교착상태는 불안전상태에서만 발생될 수 있음
  • 교착상태를 회피하려면 항상 안전상태를 유지해야 함
    • 프로세스가 가용상태의 자원을 요구하더라도 할당하지 않을 수 있음
  • 자원이용률은 다소 낮아질 수 있음

7.1.2 각 자원의 단위자원이 하나밖에 없을 경우

• 변형된 자원할당 그래프 이용
  • 단위자원의 개수를 표시할 필요 없음
  • 프로세스가 앞으로 자원을 요구할 것임을 나타내는 선언간선 추가
• 요구간선에 대한 처리
  • 할당 가능한 경우 : 해당 자원이 가용한 상태이고 할당간선으로 바꿔도 사이클이 생기지 않는 경우
  • 할당 불가능한 경우 : 해당 자원이 가용한 상태가 아니거나, 할당간선으로 바꾸면 사이클이 생기는 경우
    • 사이클 -> 안전순서열이 존재하지 않음 -> 불안전상태

7.1.3 각 자원의 단위자원이 여러 개일 경우

• 은행원 알고리즘 이용
  • 자원을 요구받으면 그 자원을 할당해 주고 난 후의 상태를 여러 데이터를 이용하여 계산해서 그것이 안전상태인지 확인한 후 안전상태가 보장 되는 경우에만 자원 할당

7.2 교착상태 탐지 및 복구

• 사후처리 방법
  • 주기적으로 탐지 알고리즘을 수행하여 교착상태가 발생한 경우를 탐지함
  • 탐지한 교착상태를 적절한 조치를 통해 정상상태로 복구함

7.2.1 탐지

• Shoshani와 Coffman 알고리즘
  • 은행원 알고리즘의 안전 알고리즘과 유사함
  • 현재 상태의 모든 자원 요구량을 고려하여 교착상태 여부 확인
• 탐지 시점
  • 즉시 받아들일 수 없는 자원 요구가 있을 때
  • 정해진 시간간격마다
  • CPU 효율이 일정 수준 이하로 떨어질 때

7.2.2 복구

• 복구의 주체
  • 오퍼레이터
  • 운영체제
• 복구방법
  • 교착상태 프로세스 종료
    • 모든 교착상태 프로세스 종료
    • 사이클이 제거될 때까지 프로세스를 하나씩 종료시킴
  • 교착상태 프로세스가 할당받은 자원 해제
    • 사이클이 제거될 때까지 할당된 자원을 단계적으로 선점함
• 복구 후 다시 교착상태 발생 가능
  • 이런 상황이 반복되면 해당 프로세스는 기아상태가 됨
  • 복구를 위한 프로세스 선택 시 복구 횟수를 고려함

참고 문헌 : 김진욱·이인복. 운영체제 워크북. 한국방송통신대학교출판문화원, 2023.

렌즈 #71: 자유로움의 렌즈

자유의 느낌은 다른 유희물과 게임이 구별되는 중요한 점 중 하나다. 플레이어가 가능한 한 자유롭다고 느끼게 하려면, 다음과 같이 자문해 보라.

• 어떤 때 플레이어가 자유롭게 행동할 수 있는가? 그럴 때 플레이어는 자유로움을 느끼는가?
• 언제 제약이 가해지는가? 그럴 때 플레이어가 제약을 느끼는가?
• 지금보다 플레이어가 더 자유롭다고 느끼게 해 줄 수 있는 곳이 있을까?
• 플레이어가 너무 많은 자유에 압도 돼버릴 수 있는 곳이 있을까?

렌즈 #72: 간접 통제의 렌즈

모든 디자이너는 플레이어가 이상적인 플레이 경험을 즐기기 위해 어떤 일을 했으면 하는 바람이 있다. 플레이어들이 스스로의 자유의지로 그런 일을 하도록, 다음과 같이 자문해 보라.

• 이상적으로, 플레이어가 어떤 행동을 했으면 좋겠는가?
• 플레이어가 그런 행동을 하도록 제약을 걸 수 있을까?
• 플레이어가 그런 행동을 하도록 목표를 제시할 수 있을까?
• 플레이어가 그런 행동을 하도록 인터페이스를 디자인할 수 있을까?
• 플레이어가 그런 행동을 하도록 시각 디자인을 활용할 수 있을까?
• 플레이어가 그런 행동을 하도록 게임 안의 캐릭터를 활용할 수 있을까?
• 플레이어가 그런 행동을 하도록 음악이나 사운드를 활용할 수 있을까?
• 플레이어의 자유롭다는 느낌을 침범하지 않으면서 플레이어가 이상적인 행동을 하도록 강제하는 다른 방법이 있을까?

렌즈 #73: 공모의 렌즈

캐릭터는 게임 세계에서의 역할을 다해야 하지만, 가능하다면 게임 디자이너 부하로서의 역할도 해서, 디자이너의 궁극적 목표, 즉 플레이어가 다가오는 경험을 만날 수 있도록 하는데 도움이 돼야 한다. 캐릭터가 이런 책임을 다할 수 있도록, 다음과 같이 자문해 보라.

• 플레이어가 어떤 경험을 하기 원하는가?
• 캐릭터가 게임 세계에서 해야 하는 일을 손상시키지 않으면서도 플레이어의 경험을 위해 캐릭터가 도움이 될 수 있는 방법이 있는가?

렌즈 #74: 세계의 렌즈

게임 세계는 독립적으로 존재한다. 게임은 플레이어의 상상 속에서만 존재하는 이 마술적 공간으로의 입구다. 당신의 세계가 힘과 완결성을 갖도록 다음과 같이 자문해 보라.

• 실제 세계보다 얼마나 좋은가?
• 이 세계로 통하는 관문이 여러 개 있을 수 있는가? 어떻게 다른가? 각각을 어떻게 지원할 수 있을까?
• 이 세계는 하나의 이야기에 집중하는가, 아니면 여기서 많은 이야기가 생겨날 수 있는가?

렌즈 #75: 아바타의 렌즈

아바타는 플레이어가 게임 세계로 들어가는 관문이다. 아바타가 플레이어의 정체성을 최대한 끌어올 수 있도록, 다음과 같이 자문해 보라.

• 아바타가 플레이어를 유인할 만큼 이상형에 가까운가?
• 플레이어가 자신을 캐릭터에 투영할 만큼 아바타에 아이콘화한 요소가 있는가?

렌즈 #76: 캐릭터 역할의 렌즈

캐릭터들이 게임에서 필요한 일들을 모두 하도록, 다음과 같이 자문해 보라.

• 캐릭터가 맡아야 하는 역할에는 어떤 것이 있는가?
• 어떤 캐릭터를 생각했었는가?
• 어떤 캐릭터가 어떤 역할과 잘 맞는가?
• 캐릭터에 여러 역할을 맡길 수 있을까?
• 캐릭터가 역할에 더 잘 맞도록 캐릭터를 바꿔야 할까?
• 새 캐릭터가 필요할까?

렌즈 #77: 캐릭터 특징의 렌즈

캐릭터의 말과 행동에서 그들의 특징이 잘 나타나도록, 다음과 같이 자문해 보라.

• 어떤 특징이 캐릭터를 나타내는가?
• 이런 특징들이 캐릭터의 말, 행동, 외양에서 뚜렷하게 드러나는가?

렌즈 #78: 대인관계 복합도의 렌즈

캐릭터 간의 관계를 이해하는 일은 매우 중요하다. 한 가지 방법은 한 축을 적대적/우호적으로 두고, 다른 한 축을 순종적/지배적으로 둔 그래프를 그려보는 것이다. 분석할 캐릭터를 하나 골라서, 가운데에 둔다. 그 캐릭터와 관계된 여타 캐릭터를 올려보고, 다음과 같이 자문해 보라.

• 그래프에 빈 곳이 있는가? 왜 그런가? 그 빈 곳을 채우면 더 좋아질까?
• 그래프에 '극단적인 캐릭터' 가 있는가? 그렇지 않다면 만들어 넣으면 더 좋아질까?
• 캐릭터의 친구들이 같은 사분면에 있는가, 다른 사분면에 있는가? 그것이 다르면 어떤 일이 생길까?

렌즈 #79: 캐릭터 웹의 렌즈

캐릭터 간의 관계를 더 잘 보기 위해, 모든 캐릭터의 목록을 만들고 다음과 같이 자문해 보라.

• 각 캐릭터는 서로에 대해 구체적으로 어떻게 생각하는가?
• 설명되지 않는 관계가 있는가? 그 부분은 어떻게 활용할 수 있을까?
• 비슷한 관계가 너무 많지 않은가? 좀 더 다르게 할 수는 없을까?

렌즈 #80: 지위의 렌즈

사람이 상호작용할 때는 지위의 수준에 따라 다른 행동을 하게 된다. 캐릭터가 다른 사람을 인자하는 것처럼 하기 위해, 다음과 같이 자문해 보라.

• 게임 캐릭터의 상대적인 지위 수준은 어떤가?
• 어떻게 하면 지위에 맞는 행동을 하게 할 수 있을까?
• 지위의 충돌은 흥미롭다 - 캐릭터들은 지위를 놓고 어떻게 투쟁할까?
• 지위의 변환은 흥미롭다 - 게임에서는 이런 일들이 어디서 일어날까?
• 플레이어가 지위를 표현할 수 있는 기회를 제공하고 있는가?

참고 문헌 : Jesse Schell. The Art of Game Design. 에이콘 출판사, 2010.

6.1 교착 상태의 개요

• 교착상태(deadlock)
  • 여러 개의 프로세스가 서로 상대방의 작업이 끝나기만 기다리고 있기 때문에 결과적으로 어느 쪽도 영원히 진행하지 못하는 상태
• 교착상태와 기아상태의 차이
  • 교착상태 : 관련된 모든 프로세스가 자원획득의 가능성 없이 무한히 대기상태인 것
  • 기아상태 : 관련된 프로세스의 일부가 자원획득의 가능성은 있으나 계속 적으로 대기상태인 것

6.2 교착상태의 특성

6.2.1 교착상태의 필요조건

• 상호배제(mutual exclusion) 조건
  • 프로세스가 자원에 대한 배타적인 통제권을 요구하는 조건
  • 필요로 하는 자원을 다른 프로세스가 점유하고 있으면 반드시 대기해야 함
• 점유대기(hold and wait) 조건
  • 프로세스가 이미 한 자원을 할당받아 점유하고 있는 상황에서 다른 프로세스가 점유하고 있는 또 다른 자원을 요청하여 해제되기를 기다리는 상황
• 비선점(no preemption) 조건
  • 프로세스에 할당된 자원은 그 프로세스가 사용을 마치고 스스로 반환하기 전에는 해제되지 않음
• 환형대기(circular wait) 조건
  • 프로세스의 자원 점유 및 점유된 자원의 요구관계가 환형을 이루며 대기하는 상황

6.2.2 자원할당 그래프

• 자원할당 그래프 G=(V,E)
  • V = ∪ R : 정점의 집합
    • P = {p_1,p_2,···,p_n} : n개의 프로세스
    • R = {r_1,r_2<···,r_m} : m개의 자원
  • E = Q∪S : 방향 있는 간선의 집합
    • Q={(p_i,r+j)|p_i∈P,r_j∈R) : 프로세스 p_i가 자원 r_j를 요구하는 요구간선
    • S={(r_j,p_i)|r_j∈R,p_i∈P) : 자원 r_j가 프로세스 p_i에 할당되어 있는 할당간선
• 자원할당 그래프와 교착상태의 관계
  • 자원할당 그래프에 사이클이 없으면 교착상태가 존재하지 않음
  • 자원할당 그래프에 사이클이 있으면 교착상태가 발생할 수도 있고 아닐 수도 있음

6.2.3 교착상태의 처리기법

• 교착상태 예방(prevention)
  • 교착상태의 네 가지 필요조건이 동시에 만족되는 것을 피함으로써 교착상태가 발생하지 않도록 하는 방법
• 교착상태 회피(avoidance)
  • 프로세스에 필요한 자원의 최대량에 대한 정보를 이용하여 교착상태가 발생하지 않도록 하는 방법
• 교착상태 탐지 및 복구(detection and recovery)
  • 교착상태의 발생 여부를 조사하여 발생한 경우에는 적절한 조치를 취해 정상상태로 복구하는 방법

6.3 교착상태 예방

6.3.1 상호배제 조건 제거

• 공유할 수 있는 자원은 상호배제를 할 필요가 없으므로 교착상태를 유발하지 않음
• 공유할 수 없는 자원은 반드시 상호배제를 따라야만 하므로 사실상 상호배제 조건을 제거하여 교착상태를 방지하는 것은 불가능함

6.3.2 점유대기 조건 제거

• 자원을 점유했을 때 대기하지 않도록 함
  • 프로세스가 앞으로 필요한 모든 자원을 처음에 한꺼번에 요구하여 할당 받음
  • 단점
    • 자원이용률이 낮아질 수 있음
    • 기아상태 발생 가능
• 대기할 때 자원을 점유하고 있지 않도록 함
  • 새로운 자원을 요구할 때는 먼저 할당받았던 자원을 모두 해제함
  • 단점
    • 점유 도중 해제할 수 없는 자원에는 적용 불가
    • 기아상태 발생 가능

6.3.3 비선점 조건 제거

• 자원을 선점 가능하도록함
  • 단점 : 자원의 특성에 따라 불가능한 경우도 있으므로 완벽하게 제거 불가
• 자원을 점유한 프로세스가 다른 자원을 요구할 때 대기가 발생한다면, 할당받았던 자원을 모두 해제하여 다른 프로세스가 비선점 조건으로 대기할 가능성을 줄이는 방법
  • 단점 : 점유 도중 해제할 수 없는 자원에는 적용 불가

6.3.4 환형대기 조건 제거

• 모든 자원에 일련번호 지정
  • 함수 f : 각 자원을 서로 다른 자연수로 지정
• 방법 1 : 프로세스는 자원을 요구할 ㅐ 일련번호 기준으로 항상 오름차순이 되도록 요구함
• 방법 2 : 프로세스가 자원을 요구할 때 그보다 일련번호가 큰 자원은 점유하고 있지 않도록 함
• 점유대기 중인 프로세스는 항상 점유하고 있는 자원의 일변번호보다 대기중인 자원의 일련번호가 크므로 환형대기 발생 불가
• 단점
  • 자원의 일련번호 설정에 어려움이 있음
  • 일련번호가 큰 점유 중인 자원을 해제해야 하는 경우, 해제가 불가능한 자원에는 적용 불가

참고 문헌 : 김진욱·이인복. 운영체제 워크북. 한국방송통신대학교출판문화원, 2023.

5.1 생산자-소비자 문제

5.1.1 생산자-소비자 문제의 정의

• 생산자-소비자 문제
  • 두 협력 프로세스 사이에 버퍼를 둠
  • 생산자 : 데이터를 넣는 프로세스
  • 소비자 : 데이터를 꺼내는 프로세스
  • 조건 1 : 버퍼에 여러 프로세스가 동시에 접근할 수 없음
    • 상호배제 필요
  • 조건 2 : 버퍼의 크기가 유한함
    • 동기화 필요
• 생산자-소비자 문제를 유한 버퍼 문제라고도 함
  • 버퍼가 가득 찬 경우 : 생산자가 기다리게 됨
  • 버퍼가 빈 경우 : 소비자가 기다리게 됨

5.1.2 세마포어를 이용한 해결

• 3개의 세마포어 이용
  • mutex : 상호배제 해결
    • 초깃값 = 1
  • empty : 버퍼가 가득 찬 경우의 동기화
    • 초깃값 = 버퍼의 크기 n
  • full : 버퍼가 빈 경우의 동기화
    • 초깃값 = 0

생산자의 코드

while(true){
데이터를 생산
P(empty);
P(mutex);
버퍼에 데이터를 넣음
V(mutex);
V(full);
}

소비자의 코드

while(true)
{
P(full);
P(mutex);
버퍼에서 데이터를 꺼냄
V(mutex);
V(empty);
데이터를 소비
}

판독기 - 기록기 문제

5.2.1 판독기 - 기록기 문제의 정의

• 판독기 - 기록기 문제
  • 여러 협력 프로세스가 파일 같은 공유자원을 사이에 둠
  • 판독기 : 데이터를 읽는 프로세스
  • 기록기 : 데이터를 쓰는 프로세스
  • 조건 1 : 기록기가 공유자원에 데이터를 쓰는 중에는 다른 기록기나 판독기는 공유자원에 접근할 수 없음
    • 상호배제 필요
  • 조건 2 : 여러 판독기는 동시에 공유자원에서 데이터를 읽을 수 있음
• 제 1 판독기 - 기록기 문제
  • 판독기가 공유자원에 접근 중이라면 기록기보다 판독기에 우선순위를 주는 것
  • 기록기가 기아상태에 빠질 수 있음.
• 제 2 판독기 - 기록기 문제
  • 판독기가 공유자원에 접근 중일 때 대기 중인 기록기가 있다면, 새로운 판독기는 조건2에도 불구하고 대기함
  • 판독기의 병행성이 떨어짐
  • 판독기가 기아상태에 빠질 수 있음

5.2.2 세마포어를 이용한 해결

• 제1판독기-기록기 문제 : 2개의 세마포어와 하나의 일반 변수 이용
  • wrt : 세마포어. 기록기에 대한 상호배제 해결
    • 초깃값 = 0;
  • mutex : 세마포어. rcount에 대한 상호배제 해결
    • 초깃값 = 1;

기록기의 코드

P(wrt);
공유자원에 쓰기
V(wrt);

판독기의 코드

P(mutex);
rcount = rcount + 1;
if(rcount == 1) then P(wrt);
V(mutex);
공유자원에서 읽기
P(mutex);
rcount = rcount - 1;
if(rcount == 0) then V(wrt);
V(mutex);
}

• 제2판독기-기록기 문제 : 5개의 세마포어와 2개의 일반 변수 이용
  • wrt : 세마포어. 기록기에 대한 상호배제 해결
    • 초깃값 = 1
  • rcount : 일반 변수. 공유자원의 데이터를 읽는 중인 판독기의 개수
    • 초깃값 = 0
  • mutex1 : 세마포어. rcount에 대한 상호배제 해결
    • 초깃값 = 1
  • rd : 세마포어. 기록기가 대기 중일 때 새로운 판독기에 대한 상호배제 해결
    • 초깃값 = 1
  • wcount : 일반 변수. 공유자원에 데이터를 쓰거나 쓰기 위해 대기 중인 기록기의 개수
    • 초깃값 = 1
  • mutex2 : 세마포어. wcount에 대한 상호배제 해결
    • 초깃값 = 1
  • mutex3 : 세마포어. 기록기에 우선순위를 주기 위함
    • 초깃값 = 1

기록기의 코드

 P(mutex2);
 wcount = wcount + 1;
 if(wcount == 1) then P(rd);
 V(mutex2);
 P(wrt);
 공유자원에 쓰기
 V(wrt);
 P(mutex2);
 wcount = wcount - 1;
 if(wcount == 0) then v(rd);
 V(mutex2);

판독기의 코드

 P(mutex3);
 P(rd);
 P(mutex1);
 rcount = rcount + 1;
 if(rcount == 1) then P(wrt);
 V(mutex1);
 V(rd);
 V(mutex3);
 공유자원에서 읽기
 P(mutex1);
 rcount = rcount - 1;
 if(rcount == 0) then v(wrt);
 V(mutex1);

5.3 프로세스 간 통신

5.3.1 공유 메모리 방법

• 공유 메모리 방법
  • 협력 프로세스가 공유자원을 이용하는 동일한 변수를 사용함으로써 데이터를 공유하는 방법
    • 고속 통신 가능
    • 통신상 발생할 수 있는 문제는 응용 프로그래머가 책임지고 해결함
      • 통신상 발생할 수 있는 문제 : 상호배제 , 동기화 등
    • 운영체제는 공유 기억장소만 제공

5.3.2 메시지 전달방법

• 메시지 전달방법
  • 협력 프로세스가 메시지를 주고받으면서 데이터를 공유하는 방법
  • 커널이 제공하는 연산 send와 연산 receive 이용
  • 소량의 데이터를 주고받는 데 적합함
  • 통신상 발생할 수 있는 문제는 운영체제가 책임지고 해결함
• 통신 링크
  • 메시지를 주고받는 두 프로세스 사이에 존재함
  • 통신 링크의 성질
    • 하나의 링크는 오직 두 프로세스만 연결할 수도 있고 여럿 연결할 수도 있음
    • 두 프로세스 사이에 오직 하나의 링크만 존재할 수도 있고 여럿 존재 할 수도 있음
    • 링크의 방향성을 단방향일 수도 있고 양방향일 수도 있음
    • 링크의 용량은 여러 형태로 설정할 수 있음
• 직접통신
  • 두 프로세스가 직접 서로를 지정하여 메시지를 주고받는 방법
  • send(B,M) : 프로세스 B로 메시지 M을 보냄
  • receive(A,M) : 프로세스 A로부터 메시지를 M에 받음
    • 대칭형 주소 지정
  • receive(id,M) : 송신자 이름을 id에, 메시지를 M에 받음
    • 비대칭형 주소 지정
  • 두 프로세스 사이에 오직 하나의 통신 링크만 설정됨
  • 하나의 링크는 오직 두 프로세스 사이에만 연관됨
  • 통신 링크는 양방향
• 간접 통신
  • 통신을 원하는 프로세스들 사이에 우편함을 두고 이를 통해 메시지를 주고받는 방법
  • send(X,m1) : 우편함 X로 메시지 m1을 보냄
  • receive(X,m1) : 우편함 X로부터 메시지를 m1에 받음
  • 두 프로세스 사이에 여러 개의 통신 링크가 존재 가능
  • 하나의 링크는 여러 프로세스와 연관 가능
  • 우편함이 수신 프로세스에 소속된 경우
    • 수신자가 하나
    • 통신 링크는 단방향
  • 우편함이 운영체제에 소속된 경우
    • 수신자가 여럿 가능
    • 한순간에 하나의 수신자만 수신하도록 운영체제가 관리함
    • 송신자와 수신자의 역할이 바뀔 수 있으므로 통신 링크는 양방향

참고 문헌 : 김진욱·이인복. 운영체제 워크북. 한국방송통신대학교출판문화원, 2023.

렌즈 #61: 흥미 곡선의 렌즈

어떤 요소가 인간의 마음을 매혹하는지는 사람마다 다른 것 같지만, 가장 즐거운 매혹의 패턴은 모든 사람에게 비슷하다. 플레이어에게 주는 경험에서 플레이어의 흥미가 어떻게 변화하는지 알고 싶다면, 다음과 같이 자문해보라.

• 만약 경험의 흥미 곡선을 그려본다면, 어떤 모양일까?
• 거기에 후크가 있는가?
• 그것은 점점 흥미를 더해가고, 그 흥미는 휴지기로 강세를 주고 있는가?
• 다른 것들보다 더 재미있는 대단원이 있는가?
• 무엇을 바꾸면 좀더 나은 흥미 곡선을 만들 수 있을까?
• 흥미 곡선에 프랙탈 구조가 있는가? 있어야 하는가?
• 흥미 곡선에 대한 원래의 예상이 플레이어의 흥미 수준을 관찰한 것과 잘 맞는가? 플레이 테스터에게 흥미 곡선을 그려보라고 하면 어떤 모양이 될까?
  모든 플레이어는 각기 다르기 때문에, 흥미 곡선의 렌즈와 '렌즈 #16: 플레이어의 렌즈'를 동시에 사용해서 게임을 할 플레이어 유형별 흥미 곡선을 그려보면 큰 도움이 된다.

렌즈 #62: 내재적 흥미의 렌즈

어떤 일들은 그냥 재미있다. 이 렌즈를 사용해서 게임이 지닌 내재적인 재미를 측정하라. 다음과 같이 자문해보자.

• 게임의 어떤 면이 플레이어의 흥미를 바로 잡아둘까?
• 게임에서 플레이어가 보거나 하는 일이 그들이 전에 본 적 없는 것일까?
• 게임은 어떤 기본적 욕구에 어필하는가? 그 요소를 더할 수 있을까?
• 게임은 어떤 고차원적 욕구에 어필하는가? 그 요소를 더할 수 있을까?
• 게임에 극적인 변화와 극적인 변화에 대한 기대가 있는가? 더 극적이게 만들 수 있을까?

렌즈 #63: 아름다움의 렌즈

누구나 아름다운 것을 경험하길 좋아한다. 이 렌즈를 이용해 게임이 영원히 즐겁도록 만들려면 다음과 같이 자문해보라

• 어떤 요소가 게임을 치장하는가? 어떻게 하면 각 요소를 더 아름답게 할 수 있을까?
• 어떤 요소들은 그 자체로는 아름답지 않지만, 적절히 조합하면 아름다워진다. 게임의 요소들이 시정이 가득하고 아름답게 조율하려면 어떻게 해야 할까?
• 아름다움은 게임의 맥락에서 어떤 의미가 있는가?

렌즈 #64: 투영의 렌즈

경험을 즐기고 있는지를 파악하는  핵심적인 바로미터는 그가 경험에 상상력을 발휘해서 투영하고 있느냐이다. 그럴 때는, 경험의 재미가 일종의 선순환 과정을 겪으며 크게 상승한다. 게임이 플레이어의 투영을 잘 유도하고 있는지 판단해보려면 다음과 같이 자문해보라.

• 게임의 어떤 점에 플레이어가 연관돼 있는가? 더할 것은 없는가?
• 게임의 어떤 점이 플레이어의 상상력을 자극할까? 더할 것은 없는가?
• 게임에 플레이어가 가보고 싶어하는 지역이 있는가?
• 플레이어가 돼보고 싶어하는 인물이 될 수 있는가?
• 게임에 플레이어가 만나고 싶어지는(혹은 보고 싶어지는) 다른 캐릭터가 있는가?
• 플레이어가 실생활에서 하고 싶지만 할 수 없는 일을 게임에서 할 수 있는가?
• 플레이어가 일단 시작하면 멈출 수 없는 활동 게임에 있는가?

렌즈 #65: 이야기 기계의 렌즈

좋은 게임은 플레이어가 플레이할 때 이야기를 발생시키는 기계다. 이야기 기계가 가능한한 생산적일 수 있도록 당므과 같이 자문해보라.

• 플레이어가 목표를 달성하는 다른 선택지가 있을 때, 새롭고 색다른 이야기가 생겨난다. 어떻게 하면 선택지를 더 늘릴 수 있을까?
• 색다른 갈등이 색다른 이야기를 만든다. 어떻게 하면 게임에서 다양한 갈등이 일어나게 할까?
• 플레이어가 캐릭터와 환경을 개인화할 수 있을 때, 만들어지는 이야기에 더 신경을 쓰며 비슷한 이야기도 아주 다르게 느껴지곤 한다. 어떻게 하면 플레이어가 이야기를 개인화하도록 할 수 있을까?
• 좋은 이야기는 좋은 흥미 곡선을 갖는다. 이 게임의 규칙은 좋은 흥미 곡선을 가진 이야기를 만들어낼까?
• 이야기는 말할 수 있을 때만 좋은 법이다. 게임의 이야기에 관심이 있을 만한 플레이어는 누구일까?

렌즈 #66: 장애의 렌즈

장애가 없는 목적은 추구할 가치가 없다. 게임의 장애가 플레이어가 극복하고 싶어하는 것인지 이 렌즈를 써서 확인하라.

• 중심 캐릭터와 목적 사이의 관계는 무엇인가? 왜 캐릭터가 목적을 신경 쓰는가?
• 캐릭터와 목적 사이의 장애는 무엇인가?
• 장애물 뒤에 있는 적대자가 있는가? 주인공과 적대자 사이에 어떤 관계가 있는가?
• 장애의 난이도가 점차 증가하는가?
• "장애가 클수록 좋은 이야기다"라는 말이 있다. 장애는 충분히 큰가? 더 커질 수 있는가?
• 위대한 이야기에서 종종 중인공은 장애를 극복하기 위해 변한다. 게임의 주인공은 어떻게 변하는가?

렌즈 #67: 단순성과 초월성의 렌즈

단순성과 초월성을 적절히 조합했는지 알아보려면 다음과 같이 자문해보라.

• 이 세계가 현실 세계보다 어떤 면에서 단순한가? 다른 방식으로 단순화할 수 있을까?
• 어떤 종류의 초월적 힘을 플레이어에게 제공하는가? 게임의 도전을 제거하지 않고도 더 많은 초월서을 제공할 수 있을까?
• 이 게임의 단순성과 초월성의 조합은 플레이어가 품은 특별한 종류의 소망을 충족시키는가? 혹은 그러기 위해 고안됐는가?

렌즈 #68: 영웅의 모험의 렌즈

많은 영웅적 이야기의 구조는 비슷한다. 이 렌즈를 써서 이야기를 개선할 요소를 놓치지 않았는지 확인해보자. 다음과 같이 자문해보라.

• 이 야이기에 영웅적 이야기의 자격을 주는 요소가 있는가?
• 있다면, 영웅의 모험의 구조와 어떻게 대웅하는가?
• 전형적인 요소를 넣으면 이야기를 더 개선할 수 있을까?
• 너무 구조에 딱 들어맞아서 진부하게 느껴지진 않는가?

렌즈 #69: 신기한 물건의 렌즈

이야기에 신기한 물건을 집어넣으면 평범하지 않은 게임 메커니즘에 의미를 부여하는 걸 돕기도 한다. 플레이어의 흥미를 붙잡고 세계가 특별하게 느껴지게 한다. 하지만 너무 신기한게 많아지면 이야기가 접근할 수 없는 퍼즐같이 돼버린다. 이야기가 좋은 의미로 신기할 수 있도록, 다음과 같이 자문해보라.

• 이 이야기에서 제일 신기한 것은 무엇인가?
• 어떻게 하면 이것이 플레이어를 헷갈리게 하거나 멀어지게 하는 걸 방지할까?
• 신기한 것이 여러 개라면, 일부를 제거하거나 합칠 수 있을까?
• 이야기에 신기한 것이 없다고 하더라도, 여전히 흥미로운가?

렌즈 #70: 이야기의 렌즈

다음과 같이 자문해보라.

• 이 게임은 정말 이야기가 필요한가? 왜 그런가?
• 왜 플레이어가 이 이야기에 흥미를 느낄까?
• 이야기가 나머지 4대 요소(미적 요소, 기술, 게임플레이)를 어떻게 받쳐줄까? 더 잘할 방법이 있을까?
• 나머지 4대 요소는 어떻게 이야기를 받쳐줄까? 더 잘할 방법이 있을까?
• 어떻게 하면 이야기가 더 좋아질까?

참고 문헌 : Jesse Schell. The Art of Game Design. 에이콘 출판사, 2010.

4.1 병행 프로세스의 개요

4.1.1 병행성과 병행 프로세스

동시수행

• 한 프로세스나 쓰레드가 실행을 시작한 후 종료상태가 되지 않은 상황에서 다른 프로세스나 쓰레드가 실행되는 상황
  병행성(concurrency)
• 여러 개의 프로세스 또는 쓰레드가 동시 수행되는 시스템의 특성
  병행 프로세스
• 동시 수행되는 여러 개의 프로세스 또는 쓰레드
  CPU 개수에 따른 병행 프로세스의 실행 형태
• 하나의 CPU : 인터리빙 형식
• 여러 개의 CPU(멀티프로세서 시스템) : 메모리 구조에 따른 실행 형태
  • 강결합 시스템 : 하나의 기억장치를 공유하는 여러 CPU를 하나의 운영체제가 제어함
  • 약결합 시스템 : 각 시스템이 개별 운영체제로 독립적으로 운영되고 필요시 네트워크로 통신함

4.1.2 프로세스 간의 관계

독립 프로세스

• 수행 중인 다른 프로세스의 영향을 주지도 않고 받지도 않는 프로세스
• 프로세스의 데이터와 상태를 다른 프로세스와 공유하지 않음
• 프로세스의 실행
  • 결정적 : 실행결과는 입력에 의해서만 결정됨
  • 재생 가능 : 실행결과는 같은 입력에 대해 항상 동일함
• 타 프로세스와 무관하게 중단되거나 재시작될 수 있음
  협력 프로세스
• 수행 중인 다른 프로세스와 영향을 주고받으며 동작하는 프로세스
• 프로세스의 데이터와 상태를 다른 프로세스와 공유함
• 프로세스의 실행
  • 비결정적 : 실행결과는 실행순서에 좌우됨
  • 재생 불가능 : 실행결과는 같은 입력에 대해 항상 동일함을 보장하지 못함

4.2 병행성 문제

4.2.1 상호배제

상호배제(mutual exclusion)

• 2개 이상의 프로세스가 동시에 임계영역을 수행하지 못하도록 하는 것
  • 임계영역(critical section) : 2개 이상의 프로세스가 동시에 사용하면 안되는 공유자원을 액세스하는 프로그램 코드 영역

4.2.2 동기화

프로세스 동기화(synchronization)

• 2개 이상의 프로세스에 대한 처리순서를 결정하는 것
  상호배제 또한 임계영역에 대한 동기화 문제

4.2.3 통신

프로세스 간 통신(InterProcess Communication : IPC)

• 프로세스들이 데이터를 공유하기 위해 반드시 필요한 것
  프로세스 사이의 통신 방법
• 하나의 변수를 사용하는 방법
• 메시지를 서로 주고받는 방법

4.3 세마포어

• 상호배제와 동기화 문제를 해결하기 위한 도구
• 데이크스트라(Dijkstra, 다익스트라)가 제안함

4.3.1 세마포어의 정의

세마포어(semaphore)

• 정수형 공용변수
  • 저장값 : 사용 가능한 자원의 수 또는 잠김이나 풀림의 상태
• 초기화 : 0 이상인 정수로 상황에 맞게 초기화함
• 두 기본연산 P와 V에 의해서만 사용됨
  • 기본연산 : 인터럽트되지 않고 하나의 단위로 처리됨
  • 연산 P : 검사 또는 감소시키려는 시도
  • 연산 V : 증가
    세마포어 s에 대한 연산 P(s)의 동작
• 세마포어 s가 0보다 크면, 세마포어 s를 1만큼 감소시킴
• 세마포어 s가 0보다 크지 않다면, 현재 프로세스는 연산 P를 완료하지 못한 채 대기상태로 전이
  • 이때 세마포어 s의 대기 큐에 현재 프로세스 추가
    세마포어 s에 대한 연산 V(s)의 동작
• 세마포어 s의 대기 큐가 비어 있다면, 세마포어 s를 1만큼 증가시킴
• 세마포어 s의 대기 큐가 비어 있지 않다면, 큐에서 한 프로세스를 빼서 준비상태로 전이
  • 이때 큐는 FIFO(First In First Out)로 동작하는 것으로 가정함

4.3.2 상호배제 해결

세마포어 mutex

• 초깃값 : 1
  진입영역
• 임계영역에 대한 수행을 해도 되는지 체크하는 코드를 임계영역의 시작부분에 둠
• 연산 P(mutex)

해제영역

• 다른 프로세스가 임계영역 수행을 시작할 수 있도록 하는 코드를 임계영역의 끝 부분에 둠
• 연산 V(mutex)

4.3.3 동기화 해결

• 프로세스 A가 특정 코드 S_1을 수행한 후에 프로세스 B가 코드 S_2를 수행 하도록 동기화를 하는 경우
• 세미포어 sync
  • 초깃값 : 0
• 코드 S_2 앞에 연산 P(sync)
• 코드 S_1 뒤에 연산 V(sync)

참고 문헌 : 김진욱·이인복. 운영체제 워크북. 한국방송통신대학교출판문화원, 2023.

렌즈 #51: 피라미드의 렌즈

피라미드는 그 높은 꼭짓점이 우리를 매료시킨다. 퍼즐이 이런 고대 피라미드의 매력을 지니게 하려면, 다음과 같이 자문해 보라.

• 퍼즐의 모든 부분이 마지막 하나의 도전으로 모이게 할 수 있을까?
• 큰 피라미드는 작은 피라미드가 모여 만들어진다. 여러 도전적인 퍼즐 요소들이 위계가 있어서, 마지막 도전으로 단계적으로 이끌 수 있을까?
• 피라미드의 맨 꼭대기에 있는 도전거리가 흥미롭고, 매혹적이며, 분명한가? 사람들이 그것을 이루기 위해 노력하고 싶어 질까?

렌즈 #52: 퍼즐의 렌즈

퍼즐은 플레이어를 멈춰서 생각하게 한다. 플레이어에게 주고 싶은 경험에 퍼즐이 잘 작동하는지 알고 싶다면, 다음과 같이 자문해 보라.

• 게임에서 퍼즐은 어떤 것들인가?
• 퍼즐을 늘려야 할까, 줄여야 할까? 왜 그런가?
• 10가지 퍼즐 원칙 중 어떤 것을 게임의 퍼즐에 각각 적용해야 할까?
• 퍼즐 요소 중 게임과 어울리지 않는 것이 있는가? 게임에 잘 녹아들게 하려면 어떻게 해야 할까? ('렌즈 #43: 우아함의 렌즈'를 사용하면 도움이 될 것이다.)

렌즈 #53: 통제의 렌즈

의미 있는 통제란 몰입하는 상호작용에 필수적이므로, 이 렌즈는 단지 인터페이스를 시험하는 것 이상의 의미가 있다. 이 렌즈를 쓰려면 다음과 같이 자문해 보라.

• 플레이어가 인터페이스를 사용할 때 기대한 대로 되는가? 아니라면 이유는 뭔가?
• 직관적 인터페이스는 통제의 감각을 준다. 인터페이스는 익히기 쉬운가, 어려운가?
• 플레이어가 자신이 게임의 결과에 큰 영향력을 끼친다고 느끼는가? 그렇지 않다면, 어떻게 바꿀 수 있을까?
• 강력하다는 감각 = 통제의 감각이다. 게임의 플레이어는 스스로 강력하다고 느끼는가? 그들이 더 강력하다고 느끼게 할 수 있는가?

렌즈 #54: 물리적 인터페이스의 렌즈

어쨌든 플레이어는 게임에 대한 물리적 인터페이스를 갖게 된다. 현존하는 인터페이스를 베끼는 건 빠지기 쉬운 함정이다. 게임에 적합한 물리적 인터페이스인지 확신하려면 이 렌즈를 사용하라. 다음과 같이 자문해 보자.

• 플레이어가 뭘 집어 들고 만지는가? 이걸 더 재미있게 만들 수 있을까?
• 물리적 인터페이스가 어떻게 게임 세계에 매핑되는가? 더 직접적으로 매핑할 수 있을까?
• 맞춤형 물리 인터페이스를 만들 수 없다면, 입력을 게임 세계에 매핑할 때 어떤 은유를 사용하고 있는가?
• 이 게임의 물리 인터페이스가 장난감의 렌즈에는 어떻게 보이는가?
• 플레이어가 어떻게 세계를 보고, 듣고, 만지는가? 여기에 플레이어의 상상을 좀 더 실감 나게 만드는 물리적 출력 장치가 포함되는가?
  비디오 게임의 세계는 때론 너무 각박해서, 디자이너가 맞춤형 물리 인터페이스를 만드는 일은 딴 세상 얘기처럼 느껴질 것이다. 하지만 시장에는 실험적이고 신기하며 갑자기 튀어나온 특별히 고안된 무리적 인터페이스가 가득하다. 댄스 댄스 레볼루션(Dance Dance Revolution) 장판이나, 기타 히어로(Guitar Here)용 기타, 위모트(Wiimote)의 등장은 낡은 게임 메커니즘과 상호작용할 새로운 방법을 제공함으로써, 오래된 게임플레이에 새로운 생명을 불어넣었다.

렌즈 #55: 가상 인터페이스의 렌즈

가상 인터페이스를 만드는 건 매우 까다로운 일이다. 엉터리로 만들면 플레이어와 게임 세계 사이에 벽을 만든다. 잘 만들면 게임 세계에서 플레이어가 갖는 힘과 통제를 증가시켜 준다. 게임의 가상 인터페이스가 플레이어의 경험을 최대로 향상하는지, 다음과 같이 자문해 보라.

• 게임 세계를 보는 것만으로는 명확하지 않은 어떤 정보를 플레이어가 받게 되는가?
• 언제 플레이어가 이 정보를 필요로 하는가? 항상? 가끔만? 레벨의 끝에서만?
• 플레이어와 게임 세계의 상호작용을 방해하지 않는 범위 안에서, 어떻게 이 정보가 플레이어에게 전달될 수 있겠는가?
• 게임 세계와의 직접적 상호작용보다, (팝업 메뉴 등의) 가상 인터페이스를 사용한 상호작용이 더 쉬운 요소가 존재하는가?
• 어떤 종류의 가상 인터페이스가 이 게임에 가장 잘 어울리는가? 예를 들어 팝업 메뉴와 게임 패드는 안 좋은 조합이다.

렌즈 #56: 투명함의 렌즈

이상적 인터페이스는 플레이어의 상상이 게임 세계에 완전히 몰입할 수 있도록 보이지 않아야만 한다. 완전히 투명함을 위해 다음과 같이 자문해 보라.

• 플레이어는 무엇을 원하는가? 플레이어가 원하는 것을 할 수 있는 인터페이스인가?
• 익숙해지면 플레이어가 생각할 필요도 없이 사용할 정도로 인터페이스가 간단한가?
• 새로운 플레이어에게 인터페이스가 직관적인가? 아니면 더 직관적으로 만들 수 있는가? 플레이어가 조작을 맞춤화할 수 있게 하는 게 도움이 될까, 아니면 방해가 될까?
• 인터페이스가 모든 상황에서 잘 동작할까? 아니면 (구석에선 아주 빨라지는 식으로) 플레이어가 헷갈리는 예외 상황이 있는가?
• 긴장된 상황에서도 플레이어가 인터페이스를 잘 쓸 수 있는가? 아니면 조작을 놓치거나 필수 정보를 지나치게 되는가? 그런 경우 어떻게 개선할 수 있을까?
• 인터페이스에 플레이어에게 혼란을 주는 것이 있는가? 인터페이스의 6개 화살표 중 어디에서 발생하는가?

렌즈 #57: 피드백의 렌즈

플레이어가 게임에서 받는 피드백은 판정, 보상, 가르침, 격려, 도전 등 여러 가지다. 이 렌즈를 사용해 게임의 피드백 순환이 원하는 경험을 만드는지 확인하라. 게임의 모든 순간에 다음 질문을 던져라.

• 지금 플레이어는 무엇을 알아야 할까?
• 지금 플레이어는 무엇을 알고 싶어 할까?
• 플레이어가 지금 무엇을 느끼게 하고 싶은가? 그 느낌을 만들려면 어떻게 피드백을 줘야 할까?
• 플레이어는 지금 무엇을 느끼고 싶어 할까? 플레이어가 원하는 감정을 느낄 만한 상황을 만들 수 있는가?
• 지금 플레이어의 목표는 무엇일까? 어떤 피드백을 주면 플레이어가 목표를 이루는 걸 도울까?
  이 렌즈를 쓰려면 꽤 노력이 필요하다. 게임의 피드백은 지속적이면서도, 상황에 따라 달라져야 하기 때문이다. 게임에서 매 순간 이 렌즈를 쓰려면 정신적 노력이 많이 필요하지만, 게임이 명확하고 도전적이며 보상이 있을 것을 보장해 주는 귀중한 시간이 될 것이다.

렌즈 #58: 촉촉함의 렌즈

인터페이스가 '촉촉하다'라고 하는 건 좀 웃길 수도 있다. 하지만 거의 피드백이 없는 인터페이스를 '건조하다'라고 표현하는 경우는 드물지 않다. 촉촉한 인터페이스는 사용하는 순간이 즐겁다. 촉촉함을 극대화하려면 다음과 같이 자문해 보라.

• 이 게임의 인터페이스가 플레이어의 행동에 대해 지속적인 피드백을 주는가? 아니라면 이유가 뭔가?
• 플레이어의 행동에 의해 2차적 동작이 생기는가? 이 동작은 강력하고 흥미로운가?
• 촉촉한 시스템은 동시에 다양한 방법으로 보상을 준다. 플레이어에게 보상을 줄 때 동시에 얼마나 많은 방식으로 보상을 제공하는가? 더 많은 방법을 찾을 수 있을까?

렌즈 #59: 채널과 특질의 렌즈

게임 정보를 어떻게 채널과 특질에 매핑하느냐가 게임 인터페이스 구성의 핵심이다. 이 렌즈를 써서 신중하고 좋은 매핑을 하라. 다음과 같이 자문해 보자.

• 플레이어에게 어떤 정보가 전해져야 하는가?
• 어떤 데이터가 가장 중요한가?
• 이 데이터를 전달하는 데 어떤 채널을 쓸 수 있을까?
• 각 데이터에 어떤 채널이 가장 좋은가? 그 이유는 무엇인가?
• 각 채널에 어떤 특질이 사용 가능한가?
• 이 특질들을 어떻게 쓰면 좋을까?

렌즈 #60: 모드의 렌즈

모든 복잡도의 인터페이스가 모드를 필요로 한다. 게임의 모드가 플레이어를 헷갈리거나 당황하게끔 하는 대신, 강력하고 통제하는 느낌을 주도록 다음과 같이 자문해 보라.

• 이 게임은 무슨 모드가 필요한가? 왜 그런가?
• 삭제하거나 합칠 수 있는 모드가 있을까?
• 겹치는 모드가 있는가? 있다면, 다른 입력 채널에 넣을 수 있을까?
• 게임이 모드를 바꿀 때 플레이어가 어떻게 알게 되는가? 게임이 모드 변경을 하나 이상의 방법으로 알려줄 수 있을까?

참고 문헌 : Jesse Schell. The Art of Game Design. 에이콘 출판사, 2010.

3.1 프로세스 스케줄링

• 프로세스 스케줄링
  • 주어진 프로세스들이 여러 개인 경우, 어떤 순서대로 프로세스를 처리할지를 운영체제가 결정하는 것

3.1.1 스케줄링 단계

• 상위단계 스케줄링
  • 장기 스케줄링
  • 시스템에 들어와 작업 큐에 있는 작업을 선택하여 프로세스를 생성한 후 프로세스 준비 큐에 전달하는 역할
  • 작업 선택 기준 : 시스템의 자원을 효율적으로 이용할 수 있도록 하는 것
    • 입출력(I/O) 중심 작업과 연산 중심 작업을 균형 있게 선택함
• 하위 단계 스케줄링
  • 단기 스케줄링
  • 준비 큐에 있는 프로세를 선택해 사용 가능한 CPU를 할당하는 역할
  • 디스패치된 프로세스는 실행상태가 되어 프로세스가 처리됨
  • 하위단계 스케줄링의 수행 주체 : 디스패처(dispatcher)
• 중간단계 스케줄링
  • 중기 스케줄링
  • 프로세스를 일시적으로 메모리에서 제거하여 중지시키거나 다시 활성화시켜 시스템에 대한 단기적인 부하를 조절하는 역할

3.1.2 스케줄링의 목표

• 스케줄링의 기본 목표
  • 공정성 : 모든 프로세스가 적정 수준에서 CPU 작업을 할 수 있게 함
  • 균형성 : 시스템의 자원들이 충분히 활용될 수 있게 함
• 운영체제 유형에 따른 스케줄링의 목표
  • 일과처리 운영체제 : 처리량의 극대화, 반환시간의 최소화, CPU 활용의 극대화
    • 처리량(throughput) : 주어진 시간에 처리한 프로세스 수
    • 반환시간(turnaround time) : 프로세스 생성 시점부터 종료 시점까지의 소요시간
  • 시분할 운영체제 : 빠른 응답시간, 과다한 대기시간 방지
    • 응답시간(response time) : 요청한 시점부터 반응이 시작되는 시점까지의 소요시간
    • 대기시간(waiting time) : 프로세스가 종료될 때까지 준비 큐에서 기다린 시간의 합
  • 실시간 운영체제 : 처리기한을 맞춤

3.1.3 스케줄링 정책

• 선점(preemptive) 스케줄링 정책
  • 실행 중인 프로세스에 인터럽트를 걸고 다른 프로세스에 CPU를 할당 할 수 있는 스케줄링 방식
  • 높은 우선순위의 프로세스를 우선 처리해야 하는 경우에 유용함
    • 실시간 시스템, 시분할 시스템
  • 문맥 교환(context switching)에 따른 오버헤드 발생
    • 문맥 : CPU의 모든 레지스터와 기타 운영체제에 따라 요구되는 프로세스의 상태
    • 문맥 교환 : CPU가 현재 실행하고 있는 프로세스의 문맥을 PCB에 저장하고, 다른 프로세스의 PCB로부터 문맥을 복원하는 작업
    • 운영체제는 문맥 교환이 매우 빠르게 실행되도록 만들어져야 함
• 비선점(nonpreemptive) 스케줄링 정책
  • 실행 중인 프로세를 바로 준비상태로 전이시킬 수 없는 스케줄링 방식
  • CPU를 할당받아 실행이 시작된 프로세스는 대기상태나 종료상태로 전이될 때까지 계속 실행상태에 있게 됨
  • 강제적인 문맥 교환이 없어 오버헤드가 발생하지 않음
  • 긴 프로세스가 실행 중이라면 짧은 프로세스가 오래 기다리게 되는 경우 발생

3.1.4 스케줄링의 평가 기준

• 평균대기시간
  • 각 프로세스가 수행이 완료될 때까지 준비 큐에서 기다리는 시간의 합의 평균값
• 평균반환시간
  • 각 프로세스가 생성된 시점부터 수행이 완료된 시점까지의 소요시간의 평균값

3.2 스케줄링 알고리즘

3.2.1 FCFS 스케줄링

• 특징
  • 비선점 방식
  • 준비 큐에 도착한 순서에 따라 디스패치됨
• 장점
  • 가장 간단한 스케줄링 기법
• 단점
  • 짧은 프로세스가 긴 프로세스를 기다리거나, 중요한 프로세스가 나중에 수행될 수 있음
    • 시분할 운영체제나 실시간 운영체제에는 부적합함
  • 프로세스들의 도착순서에 따라 평균반환시간이 크게 변함

3.2.2 SJF 스케줄링

• 특징
  • 비선점 방식
  • 준비 큐에서 기다리는 프로세스 중 실행시간이 가장 짧다고 예상되는 것을 먼저 디스패치함
• 장점
  • 일괄처리 환경에서 구현하기 쉬움
• 단점
  • 실제로는 먼저 처리할 프로세스의 CPU 시간을 예상할 수 없음
  • 짧은 프로세스가 긴 프로세스를 기다리거나, 중요한 프로세스가 나중에 수행될 수 있음
    • 시분할 운영체제나 실시간 운영체제에는 부적합함

3.2.3 SRT 스케줄링

• 특징
  • SJF 알고리즘의 선점 방식
  • 준비 큐에서 기다리는 프로세스 중 남은 실행시간이 가장 짧다고 예상되는 것을 먼저 디스패치함
• 장점
  • SJF 스케줄링보다 평균대기시간이나 평균반환시간에서 효율적임
• 단점
  • 실제로는 프로세스의 CPU 시간을 예상할 수 없음
  • 각 프로세스의 실행시간 추적, 선점을 위한 문맥 교환 등 SJF보다 오버헤드가 큼

3.2.4 RR 스케줄링

• 특징
  • 선점 방식
  • 준비 큐에 도착한 순서대로 디스패치하지만 정해진 시간 할당량에 의해 실행 제한
  • 시간 할당량 안에 종료하지 못한 프로세스는 준비 큐의 마지막에 배치됨
  • 시간 할당량 크기에 따라 성능 변화
• 장점
  • CPU를 독점하지 않고 공평하게 이용됨
  • 시분할 운영체제에 적합함
• 단점
  • 시간 할당량이 너무 크면 FCFS 스케줄링과 동일해짐
  • 시간 할당량이 너무 작으면 너무 많은 문맥 교환 발생으로 오버헤드가 커짐

3.2.5 HRN 스케줄링

• 특징
  • 비선점 방식
  • 준비 큐에서 기다리는 프로세스 중 응답비율이 가장 큰 것을 먼저 디스패치함
    • 응답비율 = (대기시간+예상실행시간)/예상실행시간 = 대기시간/예상실행시간+1
  • 예상실행시간이 짧을수록, 그리고 대기시간이 길수록 응답비율이 커짐
• 장점
  • SJF 스케줄링의 단점(긴 작업과 짧은 작업 사이의 지나친 불평등) 보완
• 단점
  • 실제로는 프로세스의 CPU 시간을 예상할 수 없음

3.2.6 다단계 피드백 큐 스케줄링

• 특징
  • 선점 방식
  • 입출력 중심인 프로세스와 연산 중심인 프로세스의 특성에 따라 서로 다른 시간 할당량 부여
  • 단계 1부터 단계 n까지 각 단계마다 하나씩의 준비 큐 존재
  • 단계가 커질수록 시간 할당량도 커짐
• 스케줄링 방법
  • 신규 프로세스는 단계 1 의 준비 큐에서 FIFO 순서에 따라 디스패치됨
  • 입출력 같은 이벤트가 발생하면 CPU를 양보하고 대기상태로 갔다가 다시 준비상태가 될 때는 현재와 동일한 단계의 준비 큐에 배치됨
  • 시간 할당량을 다 썼지만 프로세스가 종료되지 못했다면 다음 단계의 준비 큐로 이동 배치됨
  • 마지막 단계에서는 RR 스케줄링 방식으로 동작함
  • 단계 k의 준비 큐에 있는 프로세스가 디스패치되려면 단계 1부터 단계 k-1까지 모든 준비 큐가 비어 있어야만 함
• 장점
  • 입출력 위주의 프로세스는 높은 우선권 유지
  • 연산 위주의 프로세스는 낮은 우선권이지만 긴 시간 할당량을 가짐

참고 문헌 : 김진욱·이인복. 운영체제 워크북. 한국방송통신대학교출판문화원, 2023.

렌즈 #41: 벌의 렌즈

결국 플레이어는 게임에 자유 의지로 들어왔기 때문에, 벌은 조심스레 사용돼야 한다. 밸런싱이 잘 되면 게임의 모든 것에 훨씬 의미를 부여할 것이며, 플레이어도 게임에서 성공하는데 현실감 있는 자부심을 갖게 될 것이다. 게임의 벌을 점검하기 위해 다음과 같이 자문해보라.

• 이 게임의 벌은 무엇인가?
• 왜 플레이어를 벌해야 하는가? 벌로 무엇을 이루려는 것인가?
• 플레이어에게 벌이 공평하게 느껴질까? 왜일까? 혹은 왜 아닐까?
• 이런 벌을 보상으로 바꿔서 동일한 혹은 더 나은 효과를 얻을 수 있을까?
• 이 게임의 강력한 벌은 동일하게 강력한 보상과 밸런싱되어 있는가?

렌즈 #42: 단순함/복잡함의 렌즈

단순함과 복잡함 사잉의 균형을 잡는 일은 어렵지만 확실히 필요하다. 이 렌즈를 사용해 게임이 단순한 시스템에서 의미 있는 복잡성이 발생하도록 하라. 다음과 같이 자문해보자.

• 이 게임에서 본질적으로 복잡한 요소는 무엇인가?
• 이 본질적 복잡함을 창발적 복잡함으로 바꿀 수 있을까?
• 창발적 복잡함의 요소가 있는가? 없다면 어째서인가?
• 게임의 요소들이 너무 단순한가?

렌즈 #43: 우아함의 렌즈

대부분의 '고전 게임'은 우아함의 걸작으로 여겨진다. 이 렌즈를 써서 여러분의 게임도 가능한 한 우아하게 만들어라. 다음과 같이 자문해보자.

• 이 게임의 요소는 무엇이 있는가?
• 각 요소의 목적은 무엇인가? 개수를 세서 각 용소에 '우아함 등급'을 매겨라.
• 하나나 두 가지 목적만 있는 요소를 서로 결합할 순 없는가? 아니면 함께 없앨 수는 없는가?
• 다양한 목적이 있는 요소에 더 많은 목적을 줄 수 있을까?

렌즈 #44: 특색의 렌즈

우아함과 특색은 반대된다. 마치 단순함과 복잡성의 축소판 같으며, 균형이 맞아야 한다. 게임이 사랑스럽고 명확한 특징이 있도록, 다음과 같이 자문해보라.

• 이 게임에 플레이어가 흥분해서 떠들 만한 색다른 것이 있는가?
• 게임을 독특하게 만들어주는 재미있는 특질이 있는가?
• 이 게임에 플레이어가 좋아할 만한 결함이 있는가?

렌즈 #45: 상상의 렌즈

모든 게임에는 어느 정도의 상상 요소와 현실적 요소가 있다. 이 렌즈는 묘사와 상상의 균형을 잡도록 도울 것이다. 다음과 같이 자문해보라.

• 플레이어가 이 게임을 플레이하려면 무엇을 이해햐야 하는가?
• 어떤 상상의 요소가 게임에 대한 이해를 도울 수 있을까?
• 이 게임에서 어떤 높은 질의 현실적 묘사를 제공할 수 있을까?
• 어떤 낮은 질의 묘사를 제공하고 있느가? 상상이 대신 빈틈을 메울 수 있을까?
• 상상이 계속 반복해서 쓸 수 있는 묘사를 제공할 수 있을까?
• 내가 제공하는 어떤 묘사가 상상을 자극할까?
• 내가 제공하는 어떤 묘사가 상상을 억누를까?

렌즈 #46: 경제의 렌즈

게임에 경제를 넣으면 놀라운 깊이와 독자적 생명력이 생긴다. 하지만 모든 생물이 그렇듯, 그서을 제어하기란 어렵다. 이 렌즈를 사용해 경제가 균형잡히게 하라.

• 어떻게 플레이어가 돈을 벌까? 다른 방법이 있을까?
• 플레이어가 뭘 살까? 왜 살까?
• 돈 벌기가 너무 쉬운가? 너무 어려운가? 어떻게 바꿀 수 있을까?
• 돈을 벌고 쓰는 데 유의미한 선택이 있는가?
• 이 게임에는 보편적인 통화가 좋을까, 아니면 다른 특별한 통화가 필요할까?

렌즈 #47: 균형의 렌즈

많은 유형의 게임 밸런스가 있으며 모두 중요하다. 하지만 세부사항에 매달리다 큰 그림을 잊어버리기 쉽다. 진창에서 벗어나려면 이 간단한 렌즈를 사용해 다음과 같은 중요한 질문을 자문해보라.

• 이 게임은 좋은 것 같은가? 그 이유는 무엇인가?

렌즈 #48: 접근성의 렌즈

플레이어에게 퍼즐(혹은 그런 류의 게임)을 낼 때는, 플레이어의 첫 동작이 어떤 것일지 명확하게 가시화해야 한다. 다음과 같이 자문해보라.

• 플레이어는 퍼즐이나 게임을 시작하는 방법을 어떻게 알게 될까? 설명해야 할까 아니면 자명할까?
• 만드는 퍼즐이나 게임이 플레이어가 전에 해본 것들처럼 작동하는가? 그렇다면 비슷한 다른 것들로부터 어떻게 시선을 끌어낼 것인가? 같지 않다면, 그 작동 방식을 어떻게 이해 시킬 것인가?
• 퍼즐이나 게임이 사람들이 와서 다뤄보고 싶게 하는가? 그렇지 않다면 그러고 싶도록 바꿀 수 있을까?

렌즈 #49: 가시적 진도의 렌즈

플레이어는 복잡한 문제를 풀면서 진도 상황을 알 수 있어야 한다. 이런 피드백을 제대로 주려면, 다음과 같이 자문해보라.

• 만드는 게임이나 퍼즐에서 진도를 보여주는 방법은 무엇인가?
• 게임에는 충분한 진도가 있는가? 성공적으로 진도가 진행되는 단계에 중간 지점을 더 만들 방법이 있을까?
• 어떤 진도가 가시적이고, 어떤 진도가 숨겨져 있는가? 숨겨져 있는 진도를 가시적이게 할 수는 없을까?

렌즈 #50: 병행의 렌즈

병행은 플레이어의 경험을 병렬로 제공하는 장점이 있다. 이 렌즈를 사용하려면 다음과 같이 자문해보라.

• 플레이어가 특정한 도전을 해결하지 못하면 더 이상 진행하지 못하는 병목이 존재하는가? 그렇다면 그 도전이 발목을 잡더라도 병행해서 진행할 수 있는 도전거리를 넣을 수 있는가?
• 병행 도전거리가 너무 비슷하다면, 병행제는 별 효과가 없다. 병행 도전이 충분히 달라서 플레이어가 풍성하다고 느낄 만한가?
• 병행 도전들은 어떤 식으로 연결돼 있는가? 한쪽의 진행 과정에 따라 다른 쪽의 도전이 쉬워지게 할 방법이 있는가?

참고 문헌 : Jesse Schell. The Art of Game Design. 에이콘 출판사, 2010.