At the end of this first day of Devember some code and syntax files have been written, and I’m reminded (not for the first time) that I should really stop working on coding a bit sooner because I always forget to leave time for the development log part.
In any case, as this is the first day of Devember this log should probably start off by explaining the project goals a little more.
As I did in 2015 and 2016, I will be participating in Devember again this year. Although in previous years I’ve used this time to work on game development projects, I’ve spent the last year not only skipping out on making regular blog posts but also concentrating on Sublime Text and it’s amazing community. As a result, this time around I’ve decided to move away from game development and instead work on something Sublime Text related instead.
If you’re new to the Devember party, it’s an idea put forth by code.org to help drive home the idea that everyone should know a little about computer science and software development because computers are so prevalent in our every day lives. As a guy who got into programming back in the stone age (the mid 1980’s) and found it full of excitement and wonder, I whole heartedly endorse the idea that everyone should at least dip their toe into the programming pool.
Following the rules of devember, my Devember contract:
I, Terence Martin, will participate to the next Devember. My Devember will be Package Development in Sublime Text. I promise I will program for my Devember for at least an hour, every day of the next December. I will also write a daily public devlog and will make the produced code publicly available on the internet. No matter what, I will keep my promise.
This year’s project will be a package for Sublime that adds simple hypertext help support, which will be designed to be used as a dependency package for other packages. This is actually something that I’ve worked on in the past with the name hyperhelp, which will be the basis for this project.
hyperhelp is actually something that grew out of my desire to improve the in-editor experience of my OverrideAudit package. It originally started as a simple proof of concept idea that snowballed and grew as time and ideas occurred. At this point the code is a little jumbled and hard to follow due to initial design choices.
Over Devember I will re-implementhyperhelp from the bottom up (although probably using some bits of the original code) in order to incorporate some new design elements into its code base. In the event that this takes less than the time available this Devember I will also work on a companion package to ease help creation in Sublime.
I also plan to create a development log that hopefully talks more about the internals of Sublime and creating packages for it with an eye towards it being a helpful series for those interested in getting into Sublime Package Development.
This year instead of hosting my projects at GitLab, I will be using GitHub instead. This year’s project repository is thus: https://github.com/OdatNurd/devember-2017. Once Devember has concluded, the code from this repository will be merged into the official hyperhelp repository and become the new base of the project.Daily updates will be made here in the Devember 2017 category of the blog.
This section of the blog is devoted to Devember 2016 and the project that I worked on for that period of time, A-Maze-Balls, which is a simplistic clone of an old Soleau Software game called Bolo Ball. Unlike last year I didn’t have multiple goals, just the one: work on this game a little each day. This worked fairly similar to how it worked last year, albeit with some tooling changes.
For the last and final day of Devember, I present this:
Billboards announce what is happening
Here we are at the second to last day of Devember 2016, so time to pour on a little development speed, I guess. This means I need to put down my 3Doodler and actually write some code. We actually got a lot done today, including this little visual tweak:
Balls showing where they score
For today’s code, a title screen has been added to our little prototype. You may recognize it:
Simple title screen
I’m not talking about the kind where the robots rise up and take us down (my AI is not that sophisticated by far) but rather the black hole variety. I can’t believe that the Romulans power their starships with these things. This is a minor nerd alert; I just spent 10 minutes traipsing through Memory Alpha making sure I didn’t make that up.
In any case, today’s changes entirely encompass the black hole Teleport entities, and their (prior) flaws, such as clobbering balls when they’re blocked, and becoming semi-inactive when they became unblocked. This was only supposed to be a minor task (and in the end, it was) but I kept waffling about how I wanted to fix it and went down a few blind alleys before coming up with my ultimate design.
For today’s hour of code (and a little more) I primarily reworked the code that generates mazes to try and generate more interesting play fields. In particular I was aiming at how it was possible for a maze to be generated with a path directly from the top to the bottom with nothing intervening to impede the ball progress. Once this was done I ironed out two of the remaining three (known, obvious) bugs.
Here we are at Day 26 of this year’s Devember (Boxing Day, if you’re in a part of the world that celebrates that) and after “boxing” a couple more bugs, we have a playable prototype of our little game; scoring is now in. This completes the tasks for having a human and computer player, alternating turns (where possible), scoring points to see who wins. This is still crude in that there is no game over screen just yet, and there should be three rounds and not one (to mention just a couple), but nevertheless, progress!
Here’s a twitter post where I showcase all of the new functionality (which up until today hasn’t been shown completely due to various small bugs that I had to leave dangling at the end of the day):
Again like yesterday, it’s been a long busy day so we’ll keep this update short and sweet.
I accomplished what I set out to do with a blocked ball removal scheme. What this means is that when both players are out of moves, we will now switch to a mode where we try to find and remove all balls that are blocked from further movement (i.e. not sitting directly on a gray brick that will vanish, or on a ball that is). Once that is done, we then swap to the state where the gray bricks remove as they did before.
This is done similarly to how the gray brick code works, except that in this case the Maze has no event for when all dropped balls are finished and instead the caller determines that for themselves when the method it invokes to remove a ball finally says that there are none left and all are vanished away.
There IS an event that triggers when a blocked ball is removed, so that in the pending scoring update we can score a blocked ball, since in the general case scoring would otherwise only happen when the ball reaches the goal line or stops for the second time (during the final ball drop).
I have noticed a couple of weird bugs that are still floating around, but nothing too earth shattering. I’ll take a brief look tomorrow to see what’s going on, and then proceed directly into the scoring mechanisms. I think based on what’s already present that we should be good to go for all of the possible scoring scenarios.