원하는 기능을 쓰게 하기 — 맵 제작 강좌

What decides the outcome is how specific the request is. “Make me a skill” nearly always produces something unusable. You have to decide which parts of your map it should use, and say so.

A good request contains four things.

What the mechanic does, in one sentence.
Which counters, units and locations it may use - by exact name.
When it fires - the condition.
Which existing code it should look like - the thing to copy the shape of.

쿨다운이 있는 스킬을 만들고 싶어.
- 발동: 플레이어가 "Skill Pad" 로케이션에 들어가면
- 효과: "Skill Area" 로케이션을 그 플레이어의 영웅 위로 옮기고, 그 안의 P8 유닛에 50 데미지
- 쿨다운: 데스 카운터 "SkillCD"로 240 사이클
- 형태는 epscript.txt의 updateAfkTimer 함수와 같은 방식으로 만들어줘
먼저 코드를 보여주고, 내가 확인하면 파일에 넣어.

Every name is chosen by you, an existing function is named as the model, and it is told not to touch the file yet.

That last line matters. Asking to see it first lets you catch a wrong direction before it reaches the file.

Break a big mechanic up. Rather than one skill in one go, do the cooldown counter, then the trigger condition, then the effect - each one checkable.

Extending a system you already have makes the request shorter, if anything - there is no new structure to describe, only an existing pattern to continue.

보스 시스템을 보면 1회차부터 13회차까지 트리거가 있어.
회차마다 체력이 10%씩 올라가는 패턴이야.
먼저 그 패턴을 정확히 설명해줘. 아직 아무것도 만들지 마.
맞으면, 같은 패턴으로 14회차부터 20회차까지 만들어줘.

Have it state the pattern in words first, and only build once you have confirmed it. Far safer than it misreading the pattern and producing seven wrong triggers at once.

Verify a large extension by count. “Runs 14 through 20” means exactly seven new sets of triggers (times however many triggers each run needs). A missing one or a duplicated one rarely jumps out on a read-through.