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.

Continue reading

For the last and final day of Devember, I present this:

Billboards announce what is happening

Continue reading

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

Continue reading

For today’s code, a title screen has been added to our little prototype. You may recognize it:

Simple title screen

Continue reading

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.

Continue reading

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.

Continue reading

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):

Ladies and gentlemen, we have a (crude) playable #devember #gamedev prototype! Blog post is incoming. pic.twitter.com/dlaSxS7xtj

— Terence Martin (@OdatNurd) December 27, 2016

Continue reading

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.

This update is going to be so short, I’m not even going to do that “read more” thing. It’s been a long day, tomorrow will be another long day, it’s late, and likely not many are interested in reading a devlog anyway.

Yesterday I left off with the final ball drop sometimes stalling out, stopping any further balls from dropping even though they should. After some digging around and fixing a couple of other unrelated bugs, I discovered that the issue was as simple as the rewritten code for ball reaping stopping 1 column short from the right side of the maze. So any ball that stopped in that column would vanish but never be reaped and so the notification for the next ball to drop was never posted.

Along the way I fixed a (non-issue) with the code not being able to proceed to dropping the final balls if there are no gray bricks to remove (which can only happen during debugging since otherwise there is always at least one bug) and the final ball drop starting a couple of frames early for each ball by not checking that a ball is fully vanished before selecting the next ball.

This testing also uncovered another bug. Due to the step by step nature of the ball drop, the final ball drop will start moving any ball that stops on an arrow by pushing it, when that should not happen. I knew this was going on but had sort of glossed over it until now. However it makes the game unfair because it allows more balls to move than it should.

My ultimate decision is to vanish away all balls that have no possible chance of moving further (anything blocked on something other than a gray brick) before the final ball drop. I have some prototype code for this but I haven’t included it yet because I think it needs a bit more work.

Tomorrow I’ll finish that and add scoring, and we pretty much have a simple playable one-round prototype to continue polishing on for the last week of Devember.

Time constraints reign akimbo for today and the next couple of days for presumably obvious reasons. As such I have finished most of what I intended today but I have simply run out of time to find and squash one last problem with it. Hopefully I can hit that tomorrow, where I can only guarantee that I’m going to get at least an hour of coding in.

The changes today relate to modifying the rest of the existing logic to use the state machine, which went pretty well.
Continue reading