조만간 시스템 사고 워크숍을 조직해야 해서 시작하려면 맥주 게임이 필요해요.

맥주 게임 자체는 소매점, 도매점, 유통점, 공장의 네 가지 캐릭터로 구성됩니다. 물류의 시간 지연 특성을 통해 시스템 관점을 이해하고 시스템 경계를 더 잘 이해할 수 있습니다.

몇 시간 동안 진행되는 워크숍이므로 이 맥주 게임이 다음 기능을 충족하길 바랍니다.

멀티플레이어 게임입니다.

맥주 게임 자체에는 공급망에서 다양한 역할을 수행하는 많은 참가자가 있지만, 누가 더 높은 점수를 획득하는지 확인하기 위해 동시에 여러 공급망이 경쟁할 수 있기를 바랍니다. 따라서 우리는 그들의 시스템 전략을 동시에 배울 수 있습니다.

게임 호스트는 모든 사람의 상태를 볼 수 있어야 합니다.

동시에 경쟁하는 여러 팀이 있기 때문에 호스트로서 저는 현재 각 팀의 진행 상황과 득점 상황을 확인할 수 있어야 합니다.

게임 흐름은 단순하고 속도 조절이 쉬워야 합니다.

처음에도 말했듯이 이번 워크숍은 짧은 워크숍이기 때문에 모두가 빠르게 적응할 수 있어야 하고 각 라운드의 세부 사항을 제어할 수 있어야 합니다.

게다가 각 라운드가 시작될 때 플레이어 UI에 타이머가 나타나 카운트다운을 통해 게임 속도를 높입니다.

캐릭터를 맞춤 설정할 수 있습니다.

클래식 맥주 게임은 4명의 캐릭터로 구성되지만, 캐릭터가 많을수록 게임 시간이 길어집니다. 그래서 3명의 캐릭터가 있는 것이 더 좋도록 게임 속도를 조정하고 싶습니다.

검색해본 결과, 오픈소스 프로젝트나 이미 온라인에 있는 프로젝트 모두 이러한 요구 사항을 완벽하게 충족할 수 없다는 사실을 발견했습니다. 그럼 제가 직접 만드는 게 좋겠어요.

맥주 게임 프로젝트

https://github.com/wirelessr/beer_game

호스트 UI

플레이어 UI

전체 프로젝트는 비즈니스 중심으로 개발되었으며 90% 이상의 적용 범위로 테스트되었으므로 자유롭게 사용하시기 바랍니다.

대비

프로젝트 폴더에 비밀 파일을 만듭니다. Dockerfile에 복사하는 모습을 보실 수 있습니다.

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

본 프로젝트는 MongoDB를 사용하고 있으므로 링크에 계정 비밀번호를 입력해야 합니다. 또한 admin.key 및 player.key는 UI의 키 필드에 해당합니다.

결국 퍼블릭 클라우드에 앱을 업로드하는 중이기 때문에 여전히 기본적인 인증 메커니즘이 필요합니다. 로컬에서만 실행 중이고 인증이 번거롭다면 해당 소스 코드를 제거할 수 있습니다.

설치 및 사용

이 프로젝트에는 Dockerfile이 첨부되어 있어 docker로 직접 실행할 수 있습니다.

docker build -t beer_game .
docker run --rm --name beer -p 8501:8501 beer_game

개발을 위해서는 requiremnts.txt 외에 단위 테스트를 실행하는 요구사항-test.txt도 설치해야 합니다. 그런 다음 Makefile을 통해 모든 단위 테스트를 실행할 수 있습니다.

pip install -r requiremnts.txt
pip install -r requirements-test.txt
make test

게임 흐름

전체 게임은 UI 상단의 옵션에 해당하는 호스트 모드와 참가자 모드로 구분됩니다.

호스트는 게임을 생성하기 위해 먼저 game_id를 할당하고, 모든 참가자는 이 ID로 player_game을 채워야 합니다.

동일한 공급망의 모든 플레이어는 동일한 player_id를 사용해야 하므로 이 ID는 공급망 ID라고도 하며 동일한 player_id를 가진 참가자는 player_role에 따라 역할로 구분됩니다.

참가자가 참여하면 호스트 화면에서 상태를 확인할 수 있습니다.

호스트의 관점에서 전체 반복이 어떤 모습인지 살펴보겠습니다.

조작해야 할 구성품은 모두 이 사진에 있고, 각 턴은 새로고침 버튼을 누르면 시작되고 다음주를 누르면 끝납니다.

이번 라운드에서 모든 공급망에 보낼 주문 수는 Place Order에 의해 실행됩니다.

Place Order 자체는 멱등원이므로 숫자를 변경하고 다시 누르면 마지막 숫자가 사용된다는 점을 언급할 가치가 있습니다. 각 참가자 인터페이스의 Place Order도 멱등성을 갖습니다.

호스트가 주문을 완료하면 상점 플레이어가 주문을 받을 수 있습니다.

마찬가지로, 공급망의 각 역할은 새로 고침으로 시작하여 주문하기로 끝나며, 상점 플레이어가 조치를 취하고 그 뒤를 소매업체 플레이어가 수행하는 식입니다.

마지막으로 호스트로 돌아가서 새로 고침을 다시 눌러 라운드의 모든 상태를 확인하고 다음 주에 라운드를 종료할 수 있습니다.

게임 세부정보

새로 고침 중에 실제로 수행되는 몇 가지 작업이 있습니다.

1. 4주 전에 접수된 주문을 기준으로 다운스트림에서 재고를 다시 채웁니다.
2. 업스트림에서 주문을 받습니다.
3. 판매할 수 있는 재고에 따라 판매 금액을 결정합니다.

Place Order는 멱등성이 있으므로 새로고침 자체도 멱등성을 갖습니다.

미래의 일

기본적으로 현재 내 요구 사항을 모두 충족하지만 개선할 수 있는 부분도 있습니다.

예를 들어 호스트는 모든 참가자의 상태를 볼 수 있지만, 시간이 지남에 따라 인벤토리 및 비용 정보의 변화를 그래프로 표시하면 게임이 끝난 후 검토하는 데 도움이 될 것입니다. .

더 기본적인 문제도 있습니다. 현재 UI에는 테스트 적용 범위가 전혀 없습니다. 주로 현재 게임 흐름이 매우 간단하기 때문입니다. UI를 몇 번만 클릭하면 모든 UI 흐름이 처리되므로 자동 테스트에 크게 의존하지 않습니다. 하지만 UI 수정이 있다면 여전히 좀 지루할 수 있으니 UI 단위 테스트를 해보시는 것이 좋을 것 같습니다.

전반적으로 이러한 요구 사항은 최적화이지만 이러한 요구 사항이 부족하더라도 기능에는 영향을 미치지 않습니다.

추가 아이디어가 있는 경우 끌어오기 요청을 제출할 수도 있습니다. 기여도 환영합니다.