Sexy Smart Slide

This game is intended for mature audience due to its suggestive imagery. In order to keep this page family-friendly, the screenshots were made using innocuous images instead of the original models; with that out of the way, happy Valentine's Day!

What gives? Seriously?

Sliding puzzles are simple to code and don't require much memory: just display a picture, get the width and height of each tile, store "the blank tile" in memory, and swap the blank tile with any other surrounding tile directly on the video buffer. It means you only need to keep track of two tiles at any time: the blank (so you can display it when the puzzle is over), and a temporary one for swapping purpose. Under the hood, you'll also need an array of some sort to store the index number of each tile (so you have to swap the tiles visually on the screen, but also in the array). The puzzle is completed when that array is ordered.

So yeah, slide puzzles can EASILY be done, which explains why so many of them have been written in QuickBASIC in the late '90s: JDR-Sliders (by Johan De Ruiter), JIG (by Jessac Mathias Baird), ORDER! (by Tomer Filiba), Puzzle (by Future $oftware Production), QSlide (by Jim Golston), Slide Puzzle (by Robin Ohm), Sliding Puzzle (by Michael Stein),... but why would you inflict such doom on the unsuspecting populace? "Nobody likes slide puzzles!" I hear you say, "They are boring, frustrating, and I hate them!" Well, I'm glad you asked, because I've got a bunch of good excuses and a note from my parents:

First, Sexy Smart Slide features softcore erotica because I believe that anyone, with the right amount of motivation, can master (and potentially enjoy) slide puzzles (for at least a good three minutes). Second, the theme fits Valentine Day's if you pour enough lube to do the job. Third, someone told me that I HAD to do it because my name is funny somehow (I couldn't help but oblige, as I'd hate to be a dick). Fourth, except for Bulma Produktions' games ("Johnny Abbot's Sex Adventures", "Suds Skins") and a few others (Dieter Caspary's "Free Lilly!" and A.V.'s "Strip Black Jack"), there's not that many adult-oriented games in QuickBASIC (this can easily be explained, but that's a whole other can of worms)... Finally, the note from my parents says they are extremely disappointed in me. Why do they keep sending me these? Please send your best answers to JamesYates@protonmail.com.

By default the game proposes a set of six different scantily dressed female models (because, as we all know, the vast majority of QuickBASIC enthusiasts still eager to play erotic games some twenty years after DOS' demise are lesbians), but after a quick stop by the settings, the straight ladies out there will be able to unlock six male models if they want (hey, I'm not judging). Rest assured that I know my target audience. All three of you.

Screwing with file specifications

I wanted to use all-purpose image formats to speed up the picture creation process. In theory mission accomplished, in practice it was a mistake. Dealing with the various implementations and finicky headers quickly began to bloat the code (it looks okay now, but God what is frustrating).

For instance, Photoshop would always save TGA files upside-down and reverse the color palette (that doesn't break file specifications but the end result was unexpected, especially when you are counting on specific color indices to be used in the 8-bit rendering). It would also count an extra palette entry when saving BMP files (saving a 160-color picture will result in a file with a 161-color palette)... again, that doesn't break file specifications, but it causes problem when you expect a very strict color count. Taking these quirks into account (by subtracting one to the color count) would result in breaking compatibility with other programs that would properly output the same files. The other option (individually counting each color within the pixel buffer) would be too time-consuming for the target system (386-ish computer).

Creating a program to make sure BMPs are properly packed would only bring me one step closer to go "screwwww yoouu!!!1!" and write a converter along with a custom format... yes, a whole custom format, because when it's not the implementation, it's the file format itself that causes trouble: BMPs feature their own set of weird design choices such as padding/junk data, confusing RLE compression scheme, and ambiguous header fields. And frankly, I'd rather do without.

The takeaway here is that you have to balance flexibility and efficiency, and it's a balance I keep struggling with (for instance, it's easier and faster to read binary over text files, but what if I want users to be able to modify those files without relying on a specific tool?) All in all, creating a custom image format might be easier to deal with, but would require converters, which would slow the image creation process down. Pick your poison.

The character map loading routine used to read the data straight from a TGA file, process each character and store them right away in the proper structure in one go. It was rather clean, but to reduce the size of the program, I decided to rely on a dirty trick: turn all colors to black, display the character map on screen and read straight from the video buffer. In a way, it is cleaner since the code relies on already existing routines... but again, a custom format would have helped... and what if I just want to tweak a few pixels and test right-away? I hate this conundrum. On modern setups with tons of memory, you can just shove the whole file in a buffer, stream it to a decoder, and write the result into another buffer (essentially storing twice the picture during loading).

Speaking of limitations, I played plenty of erotic DOS games (for research purpose only, obviously) and many of them displayed poor picture quality, even when they were using the full 256-color palette. One could assume that women in the late '80s looked blurrier and chunkier than today's, often dressing up in old-fashioned JPEG artifacts as a way to emphasize their social status. The other (more likely) possibility is that the hardware available to capture/digitalize photographs and movies wasn't as good as it is today. To state the obvious, the creation process will impact the quality of the end product. Dedicated work stations tend to provide a far superior result than entirely working within the limitations of the target computer. I was told that comic artists would usually draw their pages on bigger formats than print to reduce line jittering, and make things easier for cleaning and coloring. I guess this applies to other fields too.

Final thoughts

Laziness got the best of me as time went on; the menu code has some interesting ideas to speed things up and avoid redundancy, mouse support was added shortly before the final build (which explains why it's a bit messy), sound effects and music were ripped from other games, and I could have added a secondary CUSTOM file to add new music to the game (because you can add your own images to the puzzle list by the way)...

Yeah, I've been pretty lazy on that one. Should run in DOSBox with 3000 cycles, it can work with a mouse and gamepad, and supports SoundBlaster sound effects and midi music as well. That's about it, have fun!