Programming can be a ton of fun. There is nothing like taking a piece of silicon and telling it what to do with some simple coding. And what could be more fun than building your own game using hobby hardware. It is not a trivial task, and here are some tips to help you get there.
Write it down. The only people who don't architect their programs are novices. The only exception to this are experts who are doing routine work beneath their expertise.
- Linear planning. New developers tend to only think about what they expect to happen next and they ended up writing code which reflects the exact sequence they expect the player to interact with their game. Players are random and almost never do what you expect them to do. Solution: Plan fully and define all of the possible actions they can do and handle them.
- Code that can get jammed. Continuing from above, if you write code that has while loops or waits for very specific things to happen, then your own can get jammed and stall. There should only be one ‘while loop’ in your code. While this isn’t always completely practical, especially with low level hardware routines, at a higher application level, this applies. Solution: Write code that continuity runs (fall through) checking for the primary path (expected inputs) and other unexpected inputs.
- Use the watchdog timer. In all critical systems, programmers utilize what is referred to as watchdog or COP timer. This is a timer that runs in the background and will reset the controller of things really go wrong. It is usually set up in the beginning of your program and a special command must be sent to the watchdog timer to keep it from resetting your microcontroller. If you fail to ’kick the dog’, it assumes something bad has happened and it will reset the chip and try again to run. In a properly designed system, this should only happen in the case of a hardware hiccup, which can be caused by bad power or other external event. If you get these during normal operation, you've done something wrong. There is a small corner case where sometimes it's easier to let the watchdog do its thing because writing error handling for a particular routine is not prudent (extremely rare event/something else has gone horribly wrong), in which case you can monitor when it happens then decide if it's a case with handling more eloquently. Solution: Learn how the watchdog timer works for your device and use it.
- Time is very important in programming. Any modern microcontroller can process a 10,000 lines of code in a blink of an eye. This sounds great, but causes many problems in the real world. For instance, when a player presses a button, the processor may see 10 button presses. This is because the metal contacts in the switch are dirty and make and break the connection as they rub over each other until the connection is made solid. The processor can see all of this. Solution: To address this particular case, programmers write a debounce routine. The signal is bouncing, so we want to de-bounce it. In general, you read and input, wait a small amount of time, and read it again. Repeat to cover a ‘human’ amount of time, maybe 100ms. The example below is a bit more elaborate (from our open-source github 6 wire game) where we look at an input DEBOUNCE_COUNT times and then decide which state it is in ‘more’, then return that value.
- Welcome to the machine. A partial solution to these problems is the state machine. To begin, plan! Get out the paper or a Google Presentation or Powerpoint and draw what is called a state transition diagram (this is kind of flowchart, but specific for states). Draw a circle and name it. Let's start with ‘Start’. Now draw arrows to other states and define how you get from state to state.
Here is what this looks like in psuedocode (using C style):
Good programming skills come with time. Good software comes from good programming and beating the heck out of it (by others testing) and multiple people working on the code and testing it. That is the beauty of open-source and commercial software. Lots of people are writing, maintaining, using, and testing it.
This is a problem for the lone developer in a small environment (read new programmers in an escape room programming props). Unfortunately, the answer is usually build it, try it out on your customers, and debug more, retry. As your skills improve, it should all get better with time.
Side note: I’m not a proponent of using hobby hardware like components from Adafruit and Sparkfun in a production environment (read where you make money). I know many readers will disagree, but that is the very reason we built the FX350 and FX450, to do the hard-hardware part so programmers could focus on the software part. Check out the next blog about Hardware Tips for Escape Room Owners. (coming soon)