Hey everyone, XOR seems to have taken off and gone down quite well. I’m really chuffed with myself!
As with any release, especially one that can’t be thoroughly unit-tested, there are bug fixes and improvements to do. I decided to put this on the back burner for a little bit. I reckon it’s part of the current culture of software engineering to have to support and improve your codebase. So I need to be able to mix it up a bit.
I was going to post some of my work-based code snippets, which is mostly VBA from the outside, working with Excel and Access. Nothing big. At all. But there’s a few little opportunities to get stuck into SQL, HTML, and RegEx.
BUT. Instead I have totally got the bug for SAM games again, and started work on the next one!
I’m doing a (hopefully quicker) project to convert Splitting Images/Split Personalities to the SAM. If you’ve never seen it before, it’s an arcade-puzzler of the ‘sliding picture pieces’ variety. You get to do it against a timer, er why am I describing it? Have a play on a Java emulator version of it here or download a proper version from World of Spectrum. Go on! Have a play. I’ll wait right here.
It’s fun. Right?!
Well, so far I haven’t made enough progress for it to be a real game, as such. Just done a bit of copying graphics from the Speccy version, and got the cursor moving around a bit. But have a quick look if you like: Download v0.1 here!
Here’s the thing. Without coming across too middle-manager-jargony, I’m hoping to get (ahem) synergy from doing another game so soon. I have some tips - and hopefully this won’t come across too know-it-all. Bear with me.
Chatting to Andrew Gillen - who is also one of the only remaining SAM developers - he mentioned how much easier it is doing a conversion, because the end result is right in front of you to copy. Making a spec etc is invaluable, no matter how simple you think your project is. I tried to follow Joel Spolsky’s 12 steps to better code, and it *really* helped. I guess sometimes you need someone to stop you being a martyr with the compile-run-debug loop.
There’s more. Now I know the sort of bugs I find the hardest to track down so I’m designing my dev strategy to avoid making these bugs. You might have guessed what these are, and how I’m doing this: All the features of popular languages that are a *little* higher-level than assembler are good ideas. Object-oriented programming is all good. And being able to move up-and-down the ladder of abstraction is good too:
- Encapsulation: make sure you keep your local variables visible to as small a set of routines as you can. Try to keep your public routines separate from your private ones is good too.
- Trying to emulate things like C’s structs, VBA’s select case, etc are awesome. General concepts like this can be used over and over, and you begin to stop using your JPs and JRs as lone pawns, and start to use them together as a phalanx of chess pieces.
- In XOR’s front end (and already with Split) I’ve been writing a little script interpreter. Effectively with this, you’re jumping away from the ‘loop every frame’ of machine code, and into the land of autonomous Objects. There’s a lot more to this than I’ve found yet (it’s hard to get your head round), but I’ll write more later.
Without being too big-headed, I can’t see the main coding side eating into more than a fortnight. The real juicy bit will be what I do with the graphics and sound. With only one real moving square at a time, and no scrolling, there’s no reason why MODE 4 can’t be used, and who knows? Maybe I’ll get more cunning.