diary

3 years ago · 5017427f2c
parent ecde736bf2
commit 5017427f2c
1 changed files with 106 additions and 4 deletions
--- a/src/diary/entries/220301
+++ b/src/diary/entries/220301
@ -1,13 +1,115 @@
 <!--220201,220401-->
-<h1>february 2022:  </h1>
+<h1>february 2022: paving the road to the first finalized skills </h1>
 february 1, 2022<br>
 #diary <br>
 <br>
 <h3>tuesday, february 1 </h3>
 <ul>
-<li>For every skill I add, I need one or two new keywords. According to the Pareto principle, 20% of keywords should cover 80% of my skills. I want a good variety of keywords and for the total amount to be small and easy to learn, but it should snowball soon even if 20% is a difficult figure to believe. </li>
+<li>updated ID code - Each skill (and most other objects) have a 6-digit hex ID, so they can all be identified by a unique color. Each digit means something, and I'm currently solidifying them after making sure the color system works and I have had a lot of time to decide the basic categories for things. If I go back on any decisions after this point, I'll have gaps instead of rewrites. Any IDs that get assigned now will forever stand for those objects. </li>
-<li>I don't want to add all the keywords now, but I am going ahead and adding some skill variety for the demo. </li>
+<li>updated translation keys - Every piece of text corresponds to a key. Blessfrey is English only (with some random bad 日本語 translations for fun), but it's nice to keep my text separate. The only exception is dialog, but I'll figure that out later. Before, I used long keys like skill_desc_cut_the_guy, but now I'm finalizing short codes to replace them. The first 2 characters of name keys for objects is the type (sk for skill), and the rest is unique to the object. Descriptions add de to the front but are otherwise the same. Now Cut the Guy's keys are skcugu and deskcugu. I love codes like this because unintended words form sometimes and popular naming patterns are revealed, but they're also simply more convenient to type out. </li>
 <li>updated skillmaker.py (I use a script to generate skills instead of writing all the GDscript stuff by hand) to support new skill keywords: cure (remove a status effect), bleeding (attrition DPS), heal (opposite of damage), life drain (direct DPS), mark (nerf, comparable to the Guild Wars 1 hex), summon (spawn an ally), and projectile (entity that carries a keyword to apply on the target upon collision). </li>
 <li>added 11 skills to the script's json input file. </li>
 <li>The Attack keyword now rolls for damage, either remaining unchanged for bad rolls or increasing by the critical attack multiplier for good rolls. </li>
 <li>Replaced duration timeout with remove for all status effects to accomodate new removal conditions. </li>
 <li>moved level and xp code to the Actor object instead of being exclusive to Characters.
 <li>began adding Life Drain, Health Absorption (negate incoming damage), and Cure into the game </li>
 <li>Usually, if I encounter a bug, I'll fix it right away. I think AGILE recommends doing that? (or at least, whenever it isn't recommending you do whatever works best for you.) Right now, I'm focused on adding completed skills into the game. I made a bug.txt for anything I encounter that falls more under polish and doesn't directly impact the needs of the specific skill I'm working on. I put some random ideas in there, too. When my skills are good to go, I'll have plenty of little things to fix afterwards. </li>
 </ul>
 <br>
-Last updated February 1, 2022 <br>
+<h3>wednesday, february 2 </h3>
 <ul>
 <li>Documenting each keyword in the game design document as I go... </li>
 <li>skillmaker.py supports energy loss, energy gain (modify current skill currency by an integer), eye strain (status effect: high chance to miss outgoing attacks) </li>
 <li>added 4 skills to the json </li>
 <li>Health Absorption is now called Negate. </li>
 <li>Began adding energy loss/gain, slow (decrease movement speed), and level skills (passively affects all entities in the area; gives each level a different challenge). Removed stances for now. Generalized keywords like that are more like a tag to add to a skill than an expected structure that can be generated by Python. </li>
 <li>Adding lots of new skills and entities to the spreadsheets I keep in my game design folder. It helps prevent shared IDs and keys. </li>
 <li>The Explosives attribute of the Chemist job is replaced by Materials Engineering. </li>
 </ul>
 <br>
 <h3>saturday, february 5 </h3>
 <ul>
 <li>Continuing to finalize color code system, track proposed skills and entities, and add JSON skills  </li>
 <li>Add skillmaker.py support for knockdown (cannot move or attack), oil (applies keywords to equipment) and begin implementing them in-game </li>
 <li>I need to implement windows before the demo's release because sometimes the Skill Library gets covered by other unmovable UI elements, and it's kind of unplayable. Before, some UI plates were always there but hidden, and they were static floating textures. Now all UI elements will be standardized as the content of "windows" which are instanced and freed as needed, can be moved around, can be brought to the front or hidden behind other windows, and can remember their customized location. They won't be 100% before the demo's release, but they will no longer permanently cover up the Skill Library. Also, they'll probably all have a matching, basic window bar instead of something more subtle or cute. </li>
 <li>While I'm at it, I'm rebuilding the entire smartphone (will ultimately hold most UI stuff and maybe some texting or minigames or shopping or whatever) from containers. I didn't really know how to use containers before, but I should have been using them for providing structure and organization to content inside UI elements. </li>
 </ul>
 <br>
 <h3>monday, february 7 </h3>
 <ul>
 <li>Continuing to finalize color code system, track proposed skills and entities, and add JSON skills  </li>
 <li>Adding Interrupt (cancel activating skill), Energy Degeneration (drain skill currency) in-game </li>
 </ul>
 <br>
 <h3>tuesday, february 8 </h3>
 <ul>
 <li>Continuing to finalize color code system, track proposed skills and entities, and add JSON skills  </li>
 <li>Adding Interrupt (cancel activating skill), Energy Degeneration (drain skill currency) in-game </li>
 </ul>
 <br>
 <h3>wednesday, february 9 </h3>
 <ul>
 <li>Continuing to finalize color code system, track proposed skills and entities, and add JSON skills  </li>
 <li>Adding level skills in-game, tweaking level layout </li>
 </ul>
 <br>
 <h3>saturday, february 12 </h3>
 <ul>
 <li>I played Guild Wars today for probably the first time since they added the anniversary elite skills and weapons. I periodically log in to open presents and wander around the Plains of Jarin, maybe even decide I'll finally make a good Paragon. This time, I actually played through the main story on my Assassin. Sins never clicked with me, despite them being the closest profession to the Blessfrey job I've been playing as for months (Brawler). They're not quite the same, but they both emphasize critical hits, high mobility, and dodging/deflecting instead of high armor. Sins are all about shadowstepping all over the field, though. Brawlers have more improvised weaponry and environment-based skills. Still, I actually finally liked sins today for something other than raptor farming. I made the first build that feels good based on skills that stood out to me, ironing out any weaknesses revealed during battle, just like old times. </li>
 <li>Hopefully this means I'm in an okay place designing the Brawler skills. It's not like I don't play in other styles, but I have a strong preference for life steal/drain, managing huge mobs of minions, preventing damage (love love love playing prot in FA so so much), and any magic class in general in any game. I bounce ideas off other people, but no one else is really working on this game besides me. With 10k hours on my Guild Wars necromancer and hundreds at best on melee professions, I wondered how bad it would show through my melee job designs. </li>
 <li>Finished creating JSON entries for all proposed skills, though they don't necessarily have the fields completed. Also added a line to the skillmaker to warn me if any skill shares an ID...not that that should ever happen, of course. </li>
 <li>Made a skill name idea TXT. Too many ideas to use right now keep popping in my head as I name all the demo skills. </li>
 </ul>
 <br>
 <h3>february 13-16 </h3>
 <ul>
 <li>Proofreading JSON file, making sure every field is accurate to the listings in the spreadsheets. </li>
 <li>Documenting keywords in the GDD </li>
 </ul>
 <br>
 <h3>thursday, february 17 </h3>
 <ul>
 <li>Continuing to finalize color code system, track proposed skills and entities, and add JSON skills. </li>
 <li>I think I'm ready to start finalizing the list of skills that will appear in the first demo. I renamed the old skill and entity stockkeeping spreadsheets to archives, and only objects that will appear in the live game will be copied over to the official spreadsheets. </li>
 <li>Not everything will be represented, but I want a little taste of the Brawler, Disciple, and Chemist jobs. I have a few NPCs who will have a few skills equipped, the player will be able to learn a small collection of skills, and there will be a few level skills, hidden skills required to make the game run (some background world stuff is the result of skills being used by the engine...probably no one will realize it's happening but it's an idea I really wanted to realize through making this game but lol whatever), etc. These few defined skills will be implemented for the demo, and all other skills will wait for future releases. </li>
 <li>Brawler can be easy to play but hopefully more original than a straight melee class like Soldier will be, so it's been the player character default for a while. I'm also including a "healer" per level. One is Chloe, a Disciple, who provides direct healing and cures for status effects. The other is Night, a Chemist, who provides damage protection, buffs, and conditional healing. There will also be Chemist enemy slimes with life drain who can buff their Brawler melee allies. The Tamer job is also present, since Tamer cats will be in the courtyard. They're not really the most representative of their job, but Mean Cats and Bad Cats were my first NPCs in Godot, so they kind of end up in everything I make. </li>
 <li>Characters have two jobs (through multiclassing) and will automatically know the default skills of both jobs, plus the common default skills. That looks like a few arrays of skill resources. I have over 100 skills right now to test, so I made skillmaker.py also spit out a TXT file with all the skills pre-formatted for copy-and-pasting directly into the player's skill pool. </li>
 <li>Removing the Elementalist (lol), Heavy, and Light jobs from the game. The Disciple job is probably what all the magic class players will choose, though the inspiration and abilities are completely different from the Guild Wars Elementalist. It'll probably be more of a Transmutation Wizard from Dungeons & Dragons or something. Heavy and Light were combined into Soldier, which will accomodate both heavy tanky and quick, precise melee styles. </li>
 </ul>
 <br>
 <h3>friday, february 18 </h3>
 <ul>
 <li>Proofreading JSON file, adding all the healing keywords </li>
 </ul>
 <br>
 <h3>sunday, february 20 </h3>
 <ul>
 <li>More JSON </li>
 <li>Added skills to all the NPCs' skillbars </li>
 </ul>
 <br>
 <h3>thursday, february 24 </h3>
 <ul>
 <li>Documenting keywords in the GDD </li>
 </ul>
 <br>
 <h3>sunday, february 27 </h3>
 <ul>
 <li>I left Empty Skill out of the official skills list. Oops. Can't have empty skill slots without that hidden skill. </li>
 <li>Now all the skills should be more or less final. I begin manually adding each skill individually, add all the missing features and iron out all the bugs that the skill requires, test and make sure it works well, then make sure the python skillmaker can reproduce it perfectly. I'm going to have to do this with most skills at first, but it should snowball after a while. Currently, I've only ensured the skillmaker can reproduce skills with damage, attack/heal, summon, projectile, burning, and bleeding keywords. </li>
 <li>Once all the keywords are supported by skillmaker, 80% of the skills will be able to be generated at the push of a button. There will be some special skills that don't use keywords (like the hidden dev skill Banish that is used to delete unneeded entities during the game) and probably some special skills that will need me to add a custom line or two. I want Blessfrey skills to have a strong, consistent keyword-based language, just like Guild Wars and Magic: The Gathering. </li>
 <li>Keywords cluster into specific jobs, so I guess I'll add skills alphabetically. That way I can run into a broader assortment of keywords more quickly. </li>
 <li>I start with Adrenaline Rush, a Critical Eye Brawler skill that increases the skill user's critical rate and attack rate. I begin adding support to the game for modifying those values and implementing those keywords. </li>
 </ul>
 <br>
 <h3>monday, february 28 </h3>
 <ul>
 <li>Implementing critical attack rate and attack rate modifiers. </li>
 <li>Fixing some bugs related to highlighting and targeting </li>
 <li>I've been writing quests again. I wish I wrote more often. I used to write a scene for Blessfrey every day. Good or bad, surely if I have a ton of content, I can use the best 10% and have an interesting world. Oh well. </li>
 <li>When I write random NPC side quests, I use very generalized faceless people like it's King's Field or something. Maybe the other world can be like that, but Lucrest is supposed to be a relatively small town full of familiar faces. I made a list of all the random positions in town (cashier for clothing store, regular at cafe, gondolier, etc) and am going to start filling them out. It's a lot of characters, and they don't <i>need</i> to be these deep and richly human side characters, but they will to some extent paint the picture of Lucrest and the greater world around it and how the story is changing everything. </li>
 <li>Some characters, I already have a strong inspiration for. (I have tens of OCs from all kinds of novels I've written in private...Surely some of them can be adapted to live in Lucrest.) For the rest, I use the random button in Sims 3's Create-A-Sim as a starting point. I definitely struggle to create anyone other than cute young girls, so it's a helpful nudge to include some grown-ups, elderly people, and children, too. And guys. It's so hard to design guys... It's ridiculous because grungy, gritty old guys are my favorite characters in other works. </li>
 </ul>
 <br>
 Last updated March 4, 2022 <br>
 <br>