You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
142 lines
11 KiB
Plaintext
142 lines
11 KiB
Plaintext
<!--210218,210107-->
|
|
<h1>python writes my skills for me</h1>
|
|
march 4, 2021<br>
|
|
#godotengine #json #python <br>
|
|
<br>
|
|
Similar to Magic: The Gathering cards, the functionality of my skills is composed of keywords. For instance, a skill with the 'damage' keyword + 'bleeding' keyword will inflict pure damage + a bleeding status effect. <br>
|
|
<br>
|
|
Since skills derive their effects from existing keywords, each individual skill has very little to no unique code. Repetitive, formulaic tasks are better left to scripts, so I wrote a skillmaker to write skills for me. <br>
|
|
<br>
|
|
<h2>what do blessfrey skills look like? </h2><br>
|
|
<br>
|
|
(Click on the shrunk images for an expanded view.) <br>
|
|
<br>
|
|
They are Godot scenes composed of a single <a href="https://docs.godotengine.org/en/stable/classes/class_node.html">node</a> with an attached script. <br>
|
|
<br>
|
|
<center><img src="/static/img/ent/skillscenetree.png" alt="(image: That's it - the tree's just one node with a script.)"></center> <br>
|
|
<br>
|
|
The .TSCN and .GD files look like this in the engine. <br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skillsceneshot.png">
|
|
<img src="/static/img/ent/skillsceneshot.png" alt="(image: Screenshot from the engine - the node tree, attached script, properties, and groups are all neatly displayed.)" width="500" height="281">
|
|
</a></center> <br>
|
|
<br>
|
|
But Godot files are just simple text, so you can open them in any text editor. Really, you could write the bulk of a Godot game in Notepad, if you wanted to. That's perfect for me! <br>
|
|
<br>
|
|
The same files look like this in xed (similar program to Notepad): <br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skillscene_xed.png">
|
|
<img src="/static/img/ent/skillscene_xed.png" alt="(image: The same files displayed in xed.)" width="500" height="275">
|
|
</a></center> <br>
|
|
<br>
|
|
The .GD file is identical to what gets displayed in Godot Engine, but the .TSCN is a little cryptic. If I learn how the syntax, I can make a script to write it for me. I don't understand all of it, since I only deciphered what I need for making a skill. <br>
|
|
<br>
|
|
<h2>examining the skill scene file </h2><br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skillscene_cipher.png">
|
|
<img src="/static/img/ent/skillscene_cipher.png" alt="(image: The .TSCN file broken into color-coded sections.)" width="500" height="552">
|
|
</a></center> <br>
|
|
(You can also see the text @ <a href="https://pastebin.com/1mzmDFM5">Pastebin</a>.) <br>
|
|
<br>
|
|
Since I designed Blessfrey skills to have a simple, consistent structure, the .TSCN for any two skills will be very similar. <br>
|
|
After experimenting in + out of Godot Engine, I've found that that first line is always the same. <br>
|
|
<br>
|
|
<h3>red + yellow resources </h3><br>
|
|
The red + yellow sections are the scene's resources. This includes any .GD files attached to nodes in the scene tree and any resources (textures, fonts, etc) you load as properties. Those are the properties that look like my icon: <br>
|
|
<br>
|
|
<center><img src="/static/img/ent/skillscene_resproperty.png" alt="(image: This is what resources look like after being loaded into the properties.)"></center> <br>
|
|
<br>
|
|
The script + the resources look so similar because they are both treated as properties of the node. The formula is... <br>
|
|
<br>
|
|
<ul>
|
|
<li><code>[ext_resource path="</code> </li>
|
|
<li>obviously followed by the path of the resource. If resources are kept in a predictable place, it's easier on the script. </li>
|
|
<li><code>" type=" </code> </li>
|
|
<li>whatever the resource type is (examples include Script, Texture, DynamicFontData) </li>
|
|
<li><code>" id=</code> </li>
|
|
<li>a unique number (obviously used for referencing) </li>
|
|
</ul>
|
|
<br>
|
|
<h3>green groups</h3><br>
|
|
Green marks the groups of each node in the scene. You can see the groups are just an array of strings. <br>
|
|
<br>
|
|
Broken into pieces, that looks like <br>
|
|
<br>
|
|
<ul>
|
|
<li><code>[node </code> </li>
|
|
<li><code>name="CuttheGuy"</code> - the name of the node (node.name) goes between the quotation marks </li>
|
|
<li><code>type="Node"</code> - the type of the node, so something like Node, Node2D, or Label </li>
|
|
<li><code>groups=[</code> </li>
|
|
<li><code>"group_name", </code> - each group name is wrapped in quotation marks and separated by commas + line-breaks. </li>
|
|
<li><code>]]</code> - close all brackets </li>
|
|
</ul>
|
|
<br>
|
|
Two interesting things about the group_name property. One, the engine adds a comma at the end of every line, even to last or only group of the node. Two, if your scene node has no groups, this property will be omitted from the node. If CuttheGuy belonged to no groups, it would just look like <code>[node name="CuttheGuy" type="Node"]</code>. <br>
|
|
<br>
|
|
<h3>blue properties</h3><br>
|
|
The properties are inside blue. Since scripts are treated the same as any other resource property, the attached script is referenced in this section. <br>
|
|
<br>
|
|
Resources look like <code>icon = ExtResource( 2 )</code>.
|
|
<br>
|
|
<br>
|
|
<code>Icon</code> is my variable. I declared it in a script that the skill inherits from as <code>export(Texture) var icon = preload('res://res/art/skillIcons/EmptySkillSlot.png') setget , get_icon</code>. The <code>script</code> variable was declared by the engine and isn't in my .GD files. <br>
|
|
<br>
|
|
The <code>2</code> is an id from the yellow section. It must match the resource's number from earlier. <br>
|
|
<br>
|
|
If I store all my skill icons in the skillIcons directory and give them the proper name, they'll be found when they're needed, no manually loading necessary. This is a test skill with a generic skill icon, but it would be named something like <code>CuttheGuy.png</code>. <br>
|
|
<br>
|
|
Other properties are more straight-forward. They are the same <a href="https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_exports.html">exported member variables</a> declared in the node's attached .GD script, followed by an equal sign and the value. <br>
|
|
</ul>
|
|
<br>
|
|
<h3>overall </h3><br>
|
|
They aren't so confusing when read as text files. The Godot team must have planned them to be human-readable. :) <br>
|
|
<br>
|
|
<h2>altar of spellmaking </h2><br>
|
|
So as you modify the groups and properties of a node, the engine is actually just formatting your input into text files. Since I have a functional understanding of how to manually format data, I can write a skill-formatting script to do it for me. <br>
|
|
<br>
|
|
The tool is named "Altar of Spellmaking" as an Oblivion reference and uses JSON + Python3. <a href="https://docs.godotengine.org/en/stable/classes/class_json.html">Godot can interpret JSON files on its own</a>, so maybe someday the game will automatically generate skills from on the JSON file at load time. For now, though, I see a frivolous excuse to use Python, so the interpreter is going to be in Python. Its input shall be a JSON file, and its output shall be matching .TSCN + .GD files. <br>
|
|
<br>
|
|
<h3>writing a skill with JSON </h3><br>
|
|
JSON isn't a Turing complete language, just a notation. It looks like a dictionary and uses attribute-value relationships. It's good at storing nested groups of information and can be easily interpretted by other languages. Since my skills can be described as a collection of attributes + keyword effects, they can wrestled into the JSON format. <br>
|
|
<br>
|
|
<center><img src="/static/img/ent/skill_json.png" alt="(image: The skill as it appears in the JSON file.)"></center>
|
|
(You can also see the text @ <a href="https://pastebin.com/aYvSr3NQ">Pastebin</a>.) <br>
|
|
<br>
|
|
All the repetitive, obvious, or derivative aspects of the skill do not need to appear in the JSON, since Python will be compensating. <br>
|
|
<br>
|
|
I identify the skill by its name in lower-case + underscores just for my sake. The program doesn't care what the skill's id is or if it has an id at all. <br>
|
|
<br>
|
|
Inside, I have some basic attributes like the id and associated class + stat. The tags will become some of the node's groups. The keywords take place in the skill's phases, which are lists of dictionaries. To build the skill phase, Python will interate over each item in the dictionary and use the internal data to supply the keyword's necessary input or conditions. <br>
|
|
<br>
|
|
Conditional effects look like the image below. <br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skill_json_cond.png">
|
|
<img src="/static/img/ent/skill_json_cond.png" alt="(image: A skill entry with a conditional effect.)" width="500" height="255.24">
|
|
</a> <br></center>
|
|
(You can also see the text @ <a href="https://pastebin.com/khSwk8js">Pastebin</a>.) <br>
|
|
<br>
|
|
The <code>cond</code> consists of the <code>code</code> (literal GDscript code) and <code>desc</code> (an English translation of that code). It's not perfect, but it's quicker for me to just write the code and write the skill description than try to have Python translate. This does mean my code has to be perfect, and I have pressure to adhere to the standard language of a skill description. That's a problem, but it is much smaller than the problem of not using JSON at all. <br>
|
|
<br>
|
|
Eventually, I would prefer the desc to be an id from the translation spreadsheet instead of hard-coded text. (I discussed translation in <a href="https://www.blessfrey.me/diary/entries/201029">blessfrey in japanese</a>.) <br>
|
|
<br>
|
|
<h3>writing a Godot scene with Python3 </h3><br>
|
|
Using Python to format JSON values into a Godot scene + script is kind of ridiculous, so I have 168 lines of code and half of them start with <code>f.write</code>. Now that it's written, though, it's easy to maintain. Since the overall structure doesn't change, all I have to do is tweak a line here or there to reflect refactors. I'll include a picture of the main method, so you can get a sense of the flow of the program: <br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skill_python.png">
|
|
<img src="/static/img/ent/skill_python.png" alt="(image: The main method in the Python script.)" width="500" height="272.73">
|
|
</a> <br></center>
|
|
(You can also see the text @ <a href="https://pastebin.com/2kV2LGCn">Pastebin</a>.) <br>
|
|
<br>
|
|
The output is a nested directory of all the skills, so I can just copy + paste the <code>skills</code> folder over the one in the engine. And it works! The first skill image's code looks machine-generated because it was. <br>
|
|
<br>
|
|
<center><a target="_blank" href="/static/img/ent/skill_dir.png">
|
|
<img src="/static/img/ent/skill_dir.png" alt="(image: skills>Common>Brawler>DirtyFighting>CuttheGuy, same directories as the engine.)" width="500" height="128.11">
|
|
</a> <br></center>
|
|
<br>
|
|
<h2>is it better than just making skills in the engine? </h2>
|
|
<br>
|
|
If I only had ten or eleven skills, then probably not. I'm planning on having around 40 skills per class, though, and I'm only one person. Since the skills are very formulaic, I'd rather have Python do all the copying + pasting for me while I worry about what makes my skills unique! <br>
|
|
<br>
|
|
last updated March 6, 2021 <br>
|
|
<br>
|