Wow it’s finally out.
3 Likes
Had trouble compiling on Linux because of case-sensitivity - different filenames vs. includes for TitleScreenState / TitlescreenState and SplashScreenState / SplashscreenState.
1 Like
Loved playing it once compiled though - many an idle minute of my youth was spent Minesweeping on school computers in Windows 3.1! 
Aussie / Cockney localisations are a bloody ripper too! 
2 Likes
Bloody Ripper! Bugger me, I wish I had slotted that into my translation somewhere.
4 Likes
Found the easter egg!
3 Likes
Maybe one day I’ll make a visual novel set in Australia,
just to see how many colloquialisms I can cram in:
“Blimey, did you get that guy’s rego?”
“The ambo’s arrived, and they’ve brought the packer whacker.”
“That bloody journo is hanging around again.”
“He’s guilty of murder, arson, and jumping the rattler.”
“That bloke’s a few roos loose in the top paddock.”
“The bloody bogans are causing biffo at the pub.”
“Hey pom, watch out for the drop bears and bunyips!”
2 Likes
Might be a while before I fix it though, since the jam has started and I would like to take a break from Minesweeper for a while.
Technically it is a bugfix though, so I’ll try to do it soon.
There’s no point having a good localisation system if you can’t make some joke translations :P
You certainly have.
I’ll wait to see how many other people find it before revealing it.
Or maybe I’ll just let it be a word of mouth thing.
I just realised I shouldn’t have combined the bugfixes and adding the German translation, I should have made the bugfixes take the version to v1.0.2 and then made the German addition take the version to v1.1.0.
That’s going to be hard to fix retroactively though, since git annoyingly doesn’t like people juggling commits around.
Cool to see a game support multiple languages within the same .arduboy file! 
2 Likes
As long as you’re not concerned about breaking forks (by rewriting history), you can modify a local copy and then push it with the –force switch. Use git rebase --interactive to modify and rearrange commits to your hearts content. After the push, you can delete and recreate tags and releases.
I know it’s possible, I’ve had to us --force/-f before when I’ve accidentally commited to master instead of the intended branch,
but I’d have to read up on all the commands and there’s a lot of steps involved, so it would take some time.
1 Like
Anybody else found the easter egg?
1 Like
As far as I’m aware, nobody else has yet.
I’d offer some kind of prize for finding it,
but I don’t have any prizes to give out.
1 Like
i really like the use of the checksum. If all the devs did that sort of overhead on memory, we’d figure out the eeprom debacle sooner.
1 Like
Yes its a good idea but its really only looking after this game - not any helping it coexist with others. It will simply overwrite other game’s data if it feels its own data has been compromised.
3 Likes
True, but at least it will ask first, which is more than some games do.
(Unless it’s been manually disabled.)
1 Like
Oh that’s a nice feature. I didn’t realise you had made it optional. I guess you could expand this to choose a different EEPROM range (slot?).
Chose a different EEPROM range from the settings header at compile time or choose a different EEPROM range at runtime?
The former is easy enough, I can make a note (i.e. an issue) to add that in.
The latter would be much more difficult.
Speaking of ‘slots’, I could theoretically add multiple save slots, but it would make it harder to be backwards compatible in future and I’m not sure how desirable that would be anyway.
I was thinking the latter as it would allow an end user to choose a ‘slot’ for this game. This could be a template for other games to adopt. I would assume a slot needs to be large enough to be useful but still somehat granular - maybe 32 or 64 bytes?
1 Like
The way I see it working is on startup, you look for a marker at the start of each 64byte block. If you find your one, you are in business and know where to save the data in future. Otherwise, you prompt the user to pick a slot number and then you assume its yours - regardless of what data might be there.
This of course gets more difficult when your game requires multiple slots!
I’m not sure. The problem with a ‘block’ system is that the Arduboy only has 1024 bytes, so it might be a bit of a waste. At the very least I think block size would have to be flexible to get the most out of the space available.
I’ve had several ideas about EEPROM systems in the past, but never got round to trialling anything.
Either way, I think it would be overkill to invent a system just for Minesweeper to use. If I was going to devise a block system, I’d have to design it with all games in mind and with the intent of multiple games using it.
1 Like