Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am adding some features to my Discord dice bot. Be sure to catch last week\u2019s post before reading this one. Let\u2019s get started!<\/p>\n\n\n\n
Dice come in many forms. Outside of specialty die collecting, the hobby of role play games will tend to land you with the widest variety to determine success\/failure of fictional characters as their real-world players throw them into the hands of the equally fictional Random Number God (RNG*). Most people are familiar with cubic dice with faces valued one to six, but both the shape (read: number of sides) and the faces can be changed.<\/p>\n\n\n\n
The role play system Gensys<\/em> and its Star Wars<\/em> themed ancestors go so far as to use as many as three types of pips on their narrative dice \u2013 it\u2019s even possible to get both a \u201csuccess\u201d and \u201cadvantage\u201d from the same face! There exists a dice roller by SkyJedi on GitHub for this system, but I would like a bot I can look at and understand. It serves as my gold standard, but I can settle for bronze.<\/p>\n\n\n\n *(officially RNG means Random Number Generator)<\/p>\n\n\n\n This bot constitutes my first major project where I have a discrete engine I will likely re-use later, so I\u2019ve done my best to keep the engine clean at the expense of no time to redo the main bot\u2019s .py file. The biggest question I had to ask myself over and over again was this: Engine or implementation? Is this feature specific to this function, or does it belong in the engine? I defined my engine\u2019s role to begin after input has been screened, and lasting until it\u2019s returned the structured results. I also included a separate tally function for summing the results.<\/p>\n\n\n\n Part way through testing, one of my friends tried subtracting one term from another. I had to re-write a good chunk of the otherwise mostly working engine, but I came out with a product that can pass common mathematical operators without choking.<\/p>\n\n\n\n I finished this week with a presentable bot. I didn\u2019t get all the features I was after, but it will work for my upcoming Star Trek<\/em> themed game. My main must-have feature is a set of \u201cchallenge dice\u201d with the faces 1, 2, 0, 0, C, C. Multiple pip types was an important feature on this engine<\/p>\n\n\n\n In no particular order, I taught myself a trick or two.<\/p>\n\n\n\n Space-indented comments: When to Spaghetti Code: Clean Your Code Regularly: Git Is a Tool to Practice: The Development Cycle Loops: I would like to stress that I\u2019m finding it difficult to write about writing code. Tangible progress is often non-linear. There are a lot more options than when you\u2019re working with someone else\u2019s program. In some ways, writing a program is more like writing a story than wrestling a Windows game into working on Linux. Once you\u2019ve figured out the interface to set up your canvass, you are in full command of the ideas you express.<\/p>\n\n\n\n What do you think of this \u201cLessons Learned\u201d format?<\/p>\n","protected":false},"excerpt":{"rendered":" Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am adding some features to my Discord dice bot. Be sure to catch last week\u2019s post before reading this one. Let\u2019s get started! My Golden Standard Dice come in many forms. Outside of specialty die collecting, the hobby of role play games will … <\/p>\nAbout My Bot<\/h2>\n\n\n\n
Tricks Learned Along the Way<\/h2>\n\n\n\n
Debugging is all about wall of text. At one point, I had a function with a triple for-loop to split input strings into tokens another function could evaluate one at a time. Six hours I bickered with it until success. That victory is in part thanks to my idea to indent debug messages based on how many nested loops each one was in. On my way to a break, inspiration hit and within five minutes, I had replaced the whole thing with only three lines of code.<\/p>\n\n\n\n
Programming is an art form. Just as sketch work is drawn\/painted over, so too are new features written quickly and sloppily, made to work, added to, tweaked, extended, and eventually depreciated as early code is replaced by a more elegant solution. Messy code is hard to develop, but a little more isn\u2019t going to ruin your day if it\u2019s that little bit more to round off a major version before a deadline. As you code, you will pick up better ways to do things, and you will want to go over your old code as you are able.<\/p>\n\n\n\n
I don\u2019t know why I need to remind myself this, but I have a hard time deleting massive code blocks once a functional replacement has been coded. It feels good being able to revert quickly, but I\u2019m working over SSH in a terminal window, and scrolling through uncollapsible blocks of code all the time isn\u2019t fun. My advice is to comment out the old code being removed and make sure your program still works before removing it all together and verifying that it still works. The same goes for massive chunks of debug code built up over a long debugging session. If a whole file needs a major quality bump, I found it helpful to make a big block of comment I can move functions above as I perfect them.<\/p>\n\n\n\n
I am using Git locally on this project. Right now, my skill level is git add<\/strong> and git commit<\/strong>. Meaningful comments will come with time as will checking out a previous version will come with time. I\u2019m not working with an online repository, so I don\u2019t need to worry about push<\/strong> or pull<\/strong>, though I am aware of them. In the meantime, I keep a special place for my most recent stable version.<\/p>\n\n\n\n
The development cycle doesn\u2019t end with release. Early versions will be flawed. Even now, I\u2019m considering using those picture icons to the dice output. Always a new feature. Support code can take even longer to wrestle into existence if the clean implementation re-writes half the engine.<\/p>\n\n\n\nTakeaway<\/h2>\n\n\n\n
Final Question<\/h2>\n\n\n\n