Big systems are interesting; they’re complex, have many interlocking and interdependent parts and exhibit really fascinating emergent behaviour. Take a hospital, for example. You go in the door marked “EMERGENCY” and talk to the person behind the desk, while wondering just how bad the top of your head is. She asks for a few pieces of personal information, taps on her computer for a while and then looks confused. It appears that if you don’t ever go to hospital, then they don’t know who you are, and it takes a lot of clicking and typing to piece you together. From my date of birth and name she could find the street I lived on, but nothing else. After some more mystery typing she figured out my phone number, and presumably after finding me registered at the local doctors’ she figured out who I was. Think I’ll be writing my NHS number into my phone for future reference, it might help.
Hospitals are full of really helpful people, who want to efficiently and accurately stick your head back together. They’re hampered though by being constantly interrupted by other tasks, and having too many people to look after. There’s a very strong “Do you really need to be here? Could you not be somewhere else?” vibe in the place. Posters full of stern looking people in green scrubs stood next to pleasant and understanding looking people in white shirts and lab coats with “Go to your GP” written underneath.
Big systems are too large for any one person to figure out. During the three hours it took my head to be glued up and a tetanus jab to be stuck in my arm, I was able to observe and figure out individual parts, but how those parts knew what was going on was a layer of mystery above. At one point I was sat by myself in a room for about half an hour, wondering if I’d been forgotten about.
Smaller systems are much easier to understand. That’s why I’m having fun with the Pico 8 system I bought the other week. It’s so limited I can’t change the colour palette and have a hard limit on the amount of code that can be stored in a “cartridge”. It’s really good for cutting through the over-engineering crap that having a computer science degree installs in your brain. Hacking code is bad, engineering an elaborate and thoroughly robust system is good. Sure, there might only ever be one player, but what if in the future there were more?
No. Stop. Just make the damn game work.
I started by making a small Tron Lightcycles game by following a YouTube tutorial, happily following along and creating something playable in less than an hour. The system is limited, but I think this might lead to some fun simple ideas. I’ve loads of those floating around in my head, getting them out might be good. Clear some room for other games.
After that, I found a longer YouTube tutorial showing how to create a Breakout/Arkanoid type game. This was good because I learnt how to do some fairly complicated things – the collision detection between ball and bricks was always a bit confusing to me, but now it actually makes sense. Doing the Tron game first also gave me some code to re-use for the title and game over screens. I also figured out how to do object oriented programming in Lua. It’s not as bad as Python, which is nice.
The Breakout game is now at a point where it needs some juice to look more exciting. The basic game mechanics are there, there are no game breaking bugs or missing features, and creating new levels is fairly easy. So I decided to figure out how to create nice explosion effects.
Yes, that should do nicely. Lots of that going off on the screen when blocks get hit. It’s also only 146 code units long. Pico 8 is pretty smart, on the surface it’s a toy that can be programmed, and low quality 8-bit style games that are pretty short in duration can be created. Under that however is a deeper system with some optimisations and pretend direct memory access for fun effects and tricks.
