This is the distinction that matters most here. The model works on text. Everything else is yours.
Only you can:
- Draw terrain, place units and create locations in ScmDraft 2.
- Rename unit types - which is also how counters get created.
- Compile in EUD Editor 3.
- Launch the game and actually play it to see if it works.
- Decide what to build, and judge whether it is any fun.
What the model can do:
- Building new features. This is the main use: once it has learned your triggers and EPScript, a request described in words - “I want a skill with a cooldown” - comes back as code that actually goes into the map.
- Working out the design with you - how many counters, how the triggers divide, where it collides with what you already have - before any code is written.
- Finding the cause of a bug: give it the symptom and it finds every related trigger and narrows the possibilities.
- Writing many triggers of the same shape, and sweeping a file for what is missing. This saves time, but it is the smaller half.
- Verifying, with a script, that a change came out right.
So compiling and testing in game fall to you every time. A model can tell you the code looks right; it cannot know whether the map runs. That is why this course covers the editor and the compile step in detail.