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’s post before reading this one. Let’s get started!
My Golden Standard
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.
The role play system Gensys and its Star Wars themed ancestors go so far as to use as many as three types of pips on their narrative dice – it’s even possible to get both a “success” and “advantage” 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.
*(officially RNG means Random Number Generator)
About My Bot
This bot constitutes my first major project where I have a discrete engine I will likely re-use later, so I’ve done my best to keep the engine clean at the expense of no time to redo the main bot’s .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’s role to begin after input has been screened, and lasting until it’s returned the structured results. I also included a separate tally function for summing the results.
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.
I finished this week with a presentable bot. I didn’t get all the features I was after, but it will work for my upcoming Star Trek themed game. My main must-have feature is a set of “challenge dice” with the faces 1, 2, 0, 0, C, C. Multiple pip types was an important feature on this engine
Tricks Learned Along the Way
In no particular order, I taught myself a trick or two.
Space-indented comments:
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.
When to Spaghetti Code:
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’t going to ruin your day if it’s 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.
Clean Your Code Regularly:
I don’t 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’m working over SSH in a terminal window, and scrolling through uncollapsible blocks of code all the time isn’t 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.
Git Is a Tool to Practice:
I am using Git locally on this project. Right now, my skill level is git add and git commit. Meaningful comments will come with time as will checking out a previous version will come with time. I’m not working with an online repository, so I don’t need to worry about push or pull, though I am aware of them. In the meantime, I keep a special place for my most recent stable version.
The Development Cycle Loops:
The development cycle doesn’t end with release. Early versions will be flawed. Even now, I’m 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.
Takeaway
I would like to stress that I’m finding it difficult to write about writing code. Tangible progress is often non-linear. There are a lot more options than when you’re working with someone else’s program. In some ways, writing a program is more like writing a story than wrestling a Windows game into working on Linux. Once you’ve figured out the interface to set up your canvass, you are in full command of the ideas you express.
Final Question
What do you think of this “Lessons Learned” format?