7. Lighting Up the Scoreboard

I’ve noticed something to be true about this blog and making my game. At least for now, the quick spurts of productivity I have (accompanied by as much as a week going by with no progress) do not lend themselves neatly to good blog posts.

Sometimes I sit down for half an hour over lunch (thanks to Construct’s browser editor I can do this at home and at work) and knock out a hole design. Other times I lose five hours to a string of accomplishments and struggles. It’s difficult to encapsulate these in a way that makes sense.

So instead I’d like to highlight things that illustrate broader points I’m learning about game development.

Up today: learning how to learn about good code management.

When I debuted One-Hole Golf to my friends, I was immensely happy that almost immediately they started comparing scores in Discord. The race to be the first person to score a hole-in-one happened quickly, and was really fun to watch.

So, I decided that with one hole in my new mini-golf game done, it was time to make a scoreboard.

The actual mechanics of it, in my mind, were pretty simple. I was already tracking strokes in my first iteration of mini-golf, and I knew I could easily track strokes per hole by using global variables.

What was unexpected, though, was how quickly this ballooned into more and more lines of visual code.

To wit: the scoring and score display features alone encompass…

• 12 global variables (the project has 15 total)
• 58 conditions
• 150+ actions inside those conditions

Let’s break down the things I had to do:

1) Add strokes to the score tally and advance the hole number

Once a player knocks the ball into a hole, a little message pops up on the screen congratulating them. Once it’s clicked (On tap gesture), we add the strokes to the score for the hole and the overall game, move the message off the screen, advance to the score screen, reset the strokes, and advance the global variable that tracks where they are to the next hole.

And I had to do that twice because Construct wouldn’t let me make an “OR” condition for Touches, and I needed both the unique “Hole in One!” message and the generic “Hole!” to trigger this. Twice over nine holes gives us 18 instances of this one alone.

2) Once players arrived at the score screen, I needed to display their score per hole

Here’s a quick preview of what my score screen looks like:

In each of those boxes, I had a text box ready to be overwritten with the score after the corresponding hole was completed.

But I also didn’t want to display “0” for every uncompleted hole (it looked pretty rough) so I had to find a way to make only the scored holes display on the screen. That’s what’s happening in the code above.

By default, the score text boxes are blank. Once a hole is scored, however (HoleXScore != 0), the game overwrites the blank box with the score.

Even this simple code took quite a bit of trial and error. I tried messing with visible/invisible tags and even moving in scores from off-screen. This ended up being the cleanest method I could find, though.

3) Once players were done look at the score, I had to advance them to the correct hole

This one was even easier, once I had the global variables set up. The “click to continue” text flashes on the score screen; its actual size takes up the whole screen, though, so players can click anywhere to advance.

I set up a simple “if, and, then” check to make sure they were sent to the next hole. If the player taps on the text box, and the HoleNum (global variable that tracks how many holes the player has completed + 1) is equal to X, send them to hole X.

And while this was quite simple in execution, I think it is more emblematic of the larger point I wanted to make:

I felt intense anxiety about whether or not I was coding correctly when I wrote this.

I hadn’t felt this at all up to this point, but I remember watching my line count balloon and wondering if I was doing this all wrong. Would people judge me? Would I be hauled before a coding tribunal?

What I’m having to learn is not just how to code, but also how to code well. Neatness and conciseness matter to me, and I imagine most coders.

For both my own sake and the sake of anyone who might look at this code, I need to organize these as cleanly as possible. The more code, the more things can go wrong. So simplifying the code as much as possible also helps both me and the player.

I have no idea at this point if I’ve done these “the right way” or not, but I’m still learning. And I think that’s the important part. Because while I still feel anxious that I’ve done this all the wrong way and might hamper myself down the road, it’s better to be finished than a perfectionist while I’m learning.

And the good news is that despite whatever worries I have, the score screen works.