나도 비슷하게 .#screenshots derivation을 추가해뒀고, 초반 설정 비용은 크지만 그다음엔 유지보수가 거의 들지 않음
프로그램으로 스크린샷을 생성하는 김에 앱의 light/dark theme 두 버전을 같이 만들고, prefers-color-scheme: dark에 맞춰 바꿔 끼우면 됨
이런 요소는 GitHub README에서도 잘 동작함: https://github.com/CyberShadow/CyDo#readme
이 방식에 강하게 공감함
모바일 앱에서는 Nix로 일회성 Android 에뮬레이터를 띄워 최신 스크린샷을 생성하게 했고, 사전 설정도 필요 없고 실행 후 데이터도 남지 않음
내 경우 설정 자체도 그렇게 힘들진 않았고, 아이디어를 떠올리는 쪽이 더 어려웠으며 Nix 코드는 좋아하는 LLM으로 한 번에 만들었음
수동으로 스크린샷을 갱신하는 일이 세상에서 제일 고된 건 아니지만, upload-apk + take-screenshot + transfer-back-to-PC + edit 흐름이 늘 미묘하게 귀찮아서 결국 거의 안 하게 됨
모바일에서는 코드 예제 가로 스크롤이 꼭 필요함
문맥으로 대충 추측은 가능했지만 그래도 불편했음
이건 모바일 프로젝트에서 정말 유용함
앱 스토어는 스크린샷이 필수인데, 화면 크기 수와 현지화 수만큼 이미지를 만들어야 해서 금방 번거로워짐
예전엔 이걸 위해 직접 스크립트를 썼고, 지금은 https://fastlane.tools/ 같은 Fastlane 도구가 큰 도움이 됨
내 로직 퍼즐 게임 Nonoverse에도 Fastlane을 쓰고 있고, 앱스토어 페이지에서 예시 스크린샷을 볼 수 있음: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
App Preview 영상 녹화도 여러 장면까지 포함해 자동화해뒀고, 궁금한 사람이 있으면 글로 따로 정리할 만한 주제라고 봄
흥미가 확 당기는데, 이게 유료 서비스인지 아니면 로컬에서 도는 OS 앱인지 잘 감이 안 옴
꽤 멋짐
내가 vibe coding으로 만드는 작은 캐주얼 게임들은 늘 앱이 CLI로 헤드리스 실행되고, 오프스크린 텍스처 렌더링과 스크린샷 명령, 성능 계측까지 가능한 상태에서 시작함
이걸 넣는 데 시간도 거의 안 들고, 에이전트가 UI를 자동화하고 중요한 지점을 살펴볼 수 있는 통로도 생김
덕분에 에이전트가 스크린샷을 갱신하게 만드는 것도 아주 쉬워짐
빌드 과정에 완전히 녹아든 형태만큼 깔끔하진 않지만, 이제 그 부분도 추가해볼 생각임
나도 똑같이 함 offscreen screenshot path와 world pos/camera view vector를 넣는 CLI 인자도 있고, 텍스트 기반 입력 형식으로 스크립트 벤치마크를 돌림
이 형식은 이름 붙은 세그먼트 여러 줄과 세그먼트별 n 게임 틱 길이, 그리고 각 세그먼트의 컨트롤 입력으로 구성됨
게임 코드를 작업하면서 비주얼과 성능을 A/B 테스트할 때 이걸 아주 많이 씀
이런 캐주얼 게임들 링크를 좀 공유해줄 수 있을지 궁금함
나도 vibe coding이 게임 개발을 얼마나 쉽게 만드는지 관심이 큼
Adobe Flash 시절엔 인디 게임 생태계가 정말 활기찼고, 그 뒤로는 그 정도의 개발 용이성을 건드린 게 거의 없었음
vibe coding은 그 수준을 처음으로 넘어서는 도구처럼 보임
이걸 넣는 데 시간도 거의 안 든다는 말은 경우에 따라 다름
어떤 엔진을 쓰는지 궁금함
정말 멋짐
Markdown 문서 안에 스크린샷 선언을 인라인으로 넣을 수 있다는 점이 특히 마음에 듦
내 데스크톱 앱에서는 여러 언어와 light/dark 모드의 스크린샷을 생성하고, 노이즈를 제거하고, Windows/macOS 창 프레임까지 입히는 솔루션을 만들어뒀음
여기에 정리해뒀음: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
지금은 별도 스크립트라 유지보수가 꽤 귀찮은데, markdown/mdx 일부로 편입하는 쪽을 살펴봐야겠음
좋은 영감을 받았음
이런 게 정말 자주 필요했음 아무도 눈치채지 못할 X 최고의 작업물 같은 밈으로 써도 될 정도임
Hacker News 의견들
프로그램으로 스크린샷을 생성하는 김에 앱의 light/dark theme 두 버전을 같이 만들고,
prefers-color-scheme: dark에 맞춰 바꿔 끼우면 됨이런 요소는 GitHub README에서도 잘 동작함: https://github.com/CyberShadow/CyDo#readme
모바일 앱에서는 Nix로 일회성 Android 에뮬레이터를 띄워 최신 스크린샷을 생성하게 했고, 사전 설정도 필요 없고 실행 후 데이터도 남지 않음
내 경우 설정 자체도 그렇게 힘들진 않았고, 아이디어를 떠올리는 쪽이 더 어려웠으며 Nix 코드는 좋아하는 LLM으로 한 번에 만들었음
수동으로 스크린샷을 갱신하는 일이 세상에서 제일 고된 건 아니지만,
upload-apk + take-screenshot + transfer-back-to-PC + edit흐름이 늘 미묘하게 귀찮아서 결국 거의 안 하게 됨문맥으로 대충 추측은 가능했지만 그래도 불편했음
앱 스토어는 스크린샷이 필수인데, 화면 크기 수와 현지화 수만큼 이미지를 만들어야 해서 금방 번거로워짐
예전엔 이걸 위해 직접 스크립트를 썼고, 지금은 https://fastlane.tools/ 같은 Fastlane 도구가 큰 도움이 됨
내 로직 퍼즐 게임 Nonoverse에도 Fastlane을 쓰고 있고, 앱스토어 페이지에서 예시 스크린샷을 볼 수 있음: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
App Preview 영상 녹화도 여러 장면까지 포함해 자동화해뒀고, 궁금한 사람이 있으면 글로 따로 정리할 만한 주제라고 봄
내가 vibe coding으로 만드는 작은 캐주얼 게임들은 늘 앱이 CLI로 헤드리스 실행되고, 오프스크린 텍스처 렌더링과 스크린샷 명령, 성능 계측까지 가능한 상태에서 시작함
이걸 넣는 데 시간도 거의 안 들고, 에이전트가 UI를 자동화하고 중요한 지점을 살펴볼 수 있는 통로도 생김
덕분에 에이전트가 스크린샷을 갱신하게 만드는 것도 아주 쉬워짐
빌드 과정에 완전히 녹아든 형태만큼 깔끔하진 않지만, 이제 그 부분도 추가해볼 생각임
offscreen screenshot path와 world pos/camera view vector를 넣는 CLI 인자도 있고, 텍스트 기반 입력 형식으로 스크립트 벤치마크를 돌림
이 형식은 이름 붙은 세그먼트 여러 줄과 세그먼트별
n게임 틱 길이, 그리고 각 세그먼트의 컨트롤 입력으로 구성됨게임 코드를 작업하면서 비주얼과 성능을 A/B 테스트할 때 이걸 아주 많이 씀
나도 vibe coding이 게임 개발을 얼마나 쉽게 만드는지 관심이 큼
Adobe Flash 시절엔 인디 게임 생태계가 정말 활기찼고, 그 뒤로는 그 정도의 개발 용이성을 건드린 게 거의 없었음
vibe coding은 그 수준을 처음으로 넘어서는 도구처럼 보임
이걸 넣는 데 시간도 거의 안 든다는 말은 경우에 따라 다름어떤 엔진을 쓰는지 궁금함
Markdown 문서 안에 스크린샷 선언을 인라인으로 넣을 수 있다는 점이 특히 마음에 듦
내 데스크톱 앱에서는 여러 언어와 light/dark 모드의 스크린샷을 생성하고, 노이즈를 제거하고, Windows/macOS 창 프레임까지 입히는 솔루션을 만들어뒀음
여기에 정리해뒀음: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
지금은 별도 스크립트라 유지보수가 꽤 귀찮은데, markdown/mdx 일부로 편입하는 쪽을 살펴봐야겠음
좋은 영감을 받았음
아무도 눈치채지 못할 X 최고의 작업물 같은 밈으로 써도 될 정도임
내가 만든 https://github.com/zombocom/rundoc에도 비슷한 기능이 있음
주된 목적은 튜토리얼 생성이라서, 실행한 명령의 출력도 다시 문서 안에 넣어줌
도구의 라이브 프리뷰를 직사각형 안에 넣는 식임
도구가 가볍다면 시각적으로도 최적일 수 있고, 브라우저의 접근성 설정이나 사용자 애드온 같은 렌더링 설정도 그대로 반영할 수 있음
iommi 문서에서는 실제로 그렇게 하고 있음: https://kodare.net/2025/01/14/iframes-not-screenshots.html
문서용
docs/도 같은 저장소에 두고, 문서를 업데이트하면서 새 스크린샷이 필요해지면 새 테스트를 추가하는 식이면 잘 맞을 듯함나도 몇 년 전에 정확히 이걸 만들기 시작했다가, 결국 https://picshift.io/처럼 더 범용적인 쪽으로 추상화했음
그래도 여전히 스크린샷 유스케이스는 정말 마음에 들고, 이 프로젝트의 원래 이름도
ScreenSync였음