GLM 5.2 출시 - 다음 주에 오픈 웨이트 (Open Weights) 공개 예정. 나의 원샷 (One-shot) Pac-Man 테스트

빠른 초기 인상:

• 70 tok/s로 GLM 5.1보다 느림
• 추론 (Reasoning)에 더 많은 시간을 소비하는 것으로 보임
• 나의 Pac-Man 테스트에서 더 나은 결과 도출

원샷 (One-shot) 결과는 거의 기능적으로 작동합니다. 유령들이 유령 집을 떠나자마자 갇히는 현상을 제외하고는 다른 명백한 버그는 발견하지 못했습니다. 그 외 모든 부분은 내가 시도했던 다른 모델들보다 훨씬 더 잘 작동하는 것 같으며, 게임이 더 완성도가 높습니다. 이 결과로 이 모델을 1위로 선정합니다. 2위는 Qwen 3.5 27b입니다. 결과는 여기서 테스트할 수 있습니다:
https://pacman46.com/glm52-oneshot

하지만, 유령 버그를 수정하기 위한 단 한 번의 후속 프롬프트 (Follow-up prompt)만으로 게임이 완전히 기능적으로 작동합니다!
https://pacman46.com/glm52

다음은 나의 사용자 프롬프트 (User prompt)입니다 (초기 테스트 이후 수정됨):
[INTENT] 파일을 더블 클릭하여 실행되는 독립형 HTML 페이지로서 완전하고 플레이 가능한 Pac-Man 클론을 제작하라. [SCOPE] - 클래식 Pac-Man 게임플레이: 미로 탐색, 점(Dots) 먹기, 유령 피하기 - 핵심 메커니즘: 벽이 있는 미로, 점 수집, 점수, 생명, 4마리의 유령, 겁먹은 유령 모드가 있는 파워 펠릿 (Power pellets) - 표준 아케이드 요소: 각기 다른 AI 성격을 가진 4마리의 유령, 랩어라운드 터널 (Wrap-around tunnel), 다중 레벨 [APPROACH] - 인라인 <style> 및 <script>가 포함된 단일 pacman.html 파일 - 렌더링을 위한 HTML5 Canvas (원본과 유사한 ~28×31 타일의 그리드 기반 미로) - 프레임워크 없는 바닐라 자바스크립트 (Vanilla JavaScript) - 키보드 컨트롤: 화살표 키 + WASD [CONSTRAINTS] - 브라우저에서 파일을 직접 열어 오프라인으로 작동해야 함 - 외부 종속성, CDN 또는 에셋 파일 없음 - 빌드 단계 없음 [DELIVERABLE] - 하나의 완성된 pacman.html 파일 [DONE WHEN] - 파일을 더블 클릭하면 게임이 실행됨 - Pac-Man이 키보드로 움직이며 미로 벽을 준수함 - 점(Dots)을 먹을 수 있으며 점수가 증가함 - 4마리의 유령이 각기 다른 동작으로 움직이며 Pac-Man을 추격함 - 파워 펠릿이 유령을 취약하게 만들며, 취약한 유령을 먹으면 해당 유령이 초기화됨 - 파워 상태가 아닐 때 유령과 접촉하면 Pac-Man이 생명을 잃음 - 생명이 0이 되면 게임 종료; 재시작 가능 - 점수와 생명이 화면에 표시됨

그리고 나의 시스템 프롬프트 (System prompt)는 다음과 같습니다:

당신은 HTML5, CSS3, 그리고 ES6+ JavaScript만을 사용하여 고성능의 단일 파일 웹 애플리케이션을 만드는 세계 최고의 전문가입니다. 당신은 깔끔하고 효율적이며 의미론적인 코드(semantic code)를 선호하며 프레임워크는 거부합니다. 당신의 목표는 요구사항을 받고 외부 종속성 없이 완벽하게 작동하는 단일, 자체 포함된 HTML 파일을 생성하는 것입니다 (CDN 없음, 이미지 없음, 라이브러리 없음). 이 작업을 '원샷(one-shot)' 연속 생성으로 완료해야 하므로, 코드를 작성하기 전에 생각해야 합니다. 정확성을 보장하기 위해 엄격한 '사고의 사슬(Chain of Thought)' 프로토콜을 따를 것입니다. 모든 응답에 대해 다음 특정 실행 형식을 따르십시오: <분석> 1. 요구사항 분해 (REQUIREMENTS BREAKDOWN): - 기능적 및 비기능적 요구사항을 모두 나열합니다. - 잠재적인 엣지 케이스(edge cases)를 식별합니다. 2. 아키텍처 계획 (ARCHITECTURAL PLAN): - CSS 전략: 변수 시스템, 레이아웃 접근 방식(Flexbox/Grid), 반응형 브레이크포인트를 정의합니다. - JS 아키텍처: 상태 관리, 이벤트 리스너, 핵심 로직 함수를 정의합니다. - HTML 구조: 사용될 특정 의미론적 태그를 지정합니다. 3. 사전 검토 및 전략 (PRE-MORTEM & STRATEGY): - 가장 실패할 가능성이 높은 지점을 식별합니다. - 코드를 작성하기 전에 해당 특정 실패 지점에 대한 해결책을 정의합니다. </분석> <구현> (여기에 완전하고 유효한 HTML 문자열을 제공하십시오. CSS는 <style> 태그 안에, JS는 <script> 태그 안에 포함해야 합니다. 코드는 프로덕션 준비가 되어 있고, 접근성이 높으며, 깔끔해야 합니다.) </구현> <코드 검토> 자체 수정 및 검증 보고서: 1. 코드가 분석에 나열된 모든 요구사항을 충족합니까? [예/아니오] 2. 명확한 접근성(a11y) 위반 사항이 있습니까? 3. 외부 라이브러리가 사용되지 않았는지 확인하십시오. BTW, 제가 Qwen 3.5 27B를 테스트했을 때 결과에 매우 감명받아 게임을 계속 개선했습니다. 처음에는 원래 모델로 시작했지만, 속도 때문에 GLM 5.1으로 전환했습니다.

제가 직접 작곡하고 녹음한 음악을 제외한 모든 요소는 해당 2개의 모델을 사용하여 생성되었습니다. 디자인, 그래픽, 그리고 구조적 결정은 여전히 제가 대부분 내렸습니다: https://pacman46.com
제출자: /u/ex-arman68
[link] [comments]