A_DESKTOP_LOVE_STORY design & technical notes

So I just published something new! Here it is. It's called A_DESKTOP_LOVE_STORY.

A_DESKTOP_LOVE_STORY is a short love story told between two files.
Due to system restrictions this is a forbidden love.
As a system administrator, you are the only one that can help them.

A_DESKTOP_LOVE_STORY is a very short cute little piece. You talk to the files, they give you things to pass to eachother, after a while they realize they like eachother, and you help them meet.

This is also one of the most weirdly designed, and technically difficult things I built so far.
I really hope that it runs on everyone's machine. It should if you run it as admin (without restrictions). It's safe.

Conceptually, I thought it would be simple, but omg... delivering a story that is meant to play out using only your desktop is really hard.
It's unique, but hard to pull off.

At the moment it's Windows only. I'm not certain if I can get past OSX's Gatekeeper, and other OS differences that I'm really not familiar enough to work with. I have a few more ideas that I'll try.
If I do manage to get a MAC build to work I'll announce it on Twitter and release a itch.io devlog.
Follow me on both these places for updates, if you're interested.
UPDATE: Mac version is now available. You can read more about that here.

I mentioned that I would write a technical designery thing for the two people who expressed interest in reading it.
Here you go, thank you for your interest :D

So, after releasing this, the biggest lesson learned...

It's really important to test upload and download your thing from the internet to see if low-level stuff (anything that has to do with a filesystem) still works. Downloading it, and then playing it, will trigger security restrictions. These vary from OSX to Windows. Windows is the nicest about it.
OSX's Gatekeeper can be horrible, and i'm not sure how to completely work with that.

To me, this has been a reminder that software, and the distribution of it, is very monopolized by the people that own your operating system.
As a developer you are basically forced to distribute through their stores if you want stuff like this to work (stuff that deals with the system).
This is bad for experimental work because stuff like this, even as a concept, would never be approved in their official storefronts (thinking back to countless rejections in the AppStore).
It really feels like censorship in many ways. I don't know... my background was that software should be free, freely shared, and your computer belongs to you. Freeware has a place, and is important.
When you make stuff like this it feels more like you're loaning your machine from Apple, and they decide what you can and can't download or run.
For the most part you don't notice until you try to... well... make software.
I realize that safety is important, but at points like this it seems less about safety and more about control.

Ok, so, the way this works...

* You download the zip. There's a small folder structure in it. The files live in these folders (their homes).
* You talk to the files, they give you things to pass to eachother.
The things you give them unlock state.
* Both files manage their own state, so there is no need for a save file (that seemed too fickle)
* If you try to drag the files to eachother's folders, before they are ready, they panic (it does take that into account)
* Once they ask to meet, you put them both in the same folder
the win state is saved, and they both are happy
* If you separate them after the win state has been triggered, they cry about being apart. An option is offered to "erase memory of their love", which you have to do to both of them otherwise you are being cruel
* You can replay it after that...

This seems simple. Conceptually, this seemed very simple to me.
It's not easy to build something like this.

The underlying problem I wanted to solve with this was a file reading what files are around it (what files share its folder space), and creating state based on that.
It seems like a simple concept. It ended up being really mind bending tho...

First of all, paths have to all be relative, and checking location has to be completely relative.
Not everyone will unzip this on their desktop, or whatever location you're planing for.
It's more difficult to check location of things relative to a file.
Locations, and file paths, are very different on both OS's.
Best solution is to keep what you're doing really simple. Don't rely too much on a person running this in a specific location.

...Both of these files are located in separate folders, people might try to drag folders out of the directory it's delivered in, they might put the files in another directory and still try to play this... there are a lot of use cases that you have 0 control over. The simpler, more flexible, and vague you keep what you're designing the better.

Don't make a big story relying on desktop specifics.
For example, you know every desktop has a trashcan. You can plan a story around that. Not everyone will keep images on their desktop. Don't rely on images being stored a certain place to trigger a dialogue or say something.
...My conclusion is that this is a very fickle way of building a game. The simpler you keep your idea the better. you can't control how people will run this, where they will run it, or if they'll keep the directory structure that you give them.

It's better to rely on items that your files (characters) generate and ask you to save out, and place around.
That's something you can control... at least, that's how I decided to build this.
One character asks you to give the other character a flower.jpg. You know not everyone will have a flower.jpg on their machine. If they do, then they might not even have it named flower.jpg. How do you tell that the jpg is a flower? This is too much work.
My solution was that a character gives you the flower.jpg that you deliver to the file that needs it.
And yes, you can have a dog.jpg and rename it to flower.jpg and that will still work. I wasn't willing to do that much work.

For stuff that you save out, and the player is asked to deliver, it's a good idea to use file formats that people generally have. Everyone can open a jpg. Commonly supported sound formats are ok too, such as .wav or .mp3. I would strongly recommend shying away from things people need an extension, plugin, or codec for... Anything more obscure is going to be hard to build around in terms of everyone being able to run this... You can't really manage all these conditions. At least these are the problems I ran into.
Especially if you want to package something that will work on both Windows and OSX. Keeping things general, and common, is a good idea.
There are discrepancies between the two OS's that you have to take into account.
For example, the filepath to desktop is different on both OS's, and that can get complicated. I relied on the file to tell me where it is and manage state that way... Up against being too specific about location on desktop... I don't know if that makes sense. It was hard to do because I wanted to incorporate state into this, and it got really weird.

Overall, I don't know if making this was a good idea. I'd be surprised if people play it... but I think it was a good thing to do just to see how it would work in context of a story.
I really hope people can actually play this lol. Fingers crossed that it doesn't suddenly break after an OS update. It shouldn't, but you never know.

Like I mentioned, the biggest problem I ran into was varying permissions people will have on their systems. You don't want to get too fancy with what you're trying to do, especially in terms of manipulating files because a system permission might break your story.
I originally thought it would be funny if the files delete eachother when they are done (run off together and live happily after ever). This feature will not work if the system has strict permissions.
I thought it would be funny if you put something in a directory that doesn't belong there, and then the character would move it to another directory (keeping this place clean!), but that has permission issues too...
It seems unrealistic to ask a person to run something like this as admin (although it's 100% safe), because only bad people ask for that and there are trust issues.
So you can't get too elaborate... You could, but it would require administrative privileges.
You can work around all that by adjusting conditions, like if you can't "delete" then generate another reaction, but this is very elaborate... There are a lot of conditions to keep in mind.
In conclusion, it's best to keep things as simple and contained as you can if telling a story is important to you.

Another interesting observation (or actually, it's more of a theory, I don't know enough about this to be 100% sure but...)...
If you installed this, or asked them to instal this, you would not run into so many permission issues. You would be able to do the "delete a file" "move a file" stuff, BUT this is structured as a handful of files that ask you to do stuff so you would have to install each in order to do that(?)... I don't know much about this, but if I were to look into doing something like this again I would look into an idea that asks you to instal first so I can do more complex stuff to the system... ok, "do stuff to the system" sounds nefarious.
What I really mean; being able to do cute little silly things to someone's system, that in no way mimic virus behavior. At this point running one of my games is a trust exercise. xD ...That's not something I want to be known for. So I'll just not go that far.

One difficulty that you should be aware of, just in terms of usability and a use case, is constantly checking the contents of the folder for updates.
Example: character is in the middle of dialogue about an item missing from the folder. While you have it open, you drag missing item into folder. Character has to update that state while it's open, not just once on open.
I had been doing it just on opening, and then delivers dialogue. Which is simpler, but you have to account for the people that will have them open while they try to do stuff.
Fix for me was they always close themselves after asking you to do stuff.
If they asked you the first time, the second time you open them the dialogue is shorter, and they close faster, so it doesn't give people time to have them open AND drag item into the folder... and then thinking it's broke because the character doesn't acknowledge the update.
I really didn't want to make it constantly check because that's a new layer of complication that I don't want to put in... but if you have the time, you should do that.

Overall, when your'e designing for something like this, being vague and general is your best friend... so it's flexible.
Keep your story general, and try to rely on things you give the user instead of incorporating too much freedom into it (give them a flower.jpg to deliver to the file, instead of asking them to find one online or whatever).

Question I had... how would something like this fit into Cyberpet Graveyard?
Initially I thought I should not spend time on doing this for Cyberpet Graveyard because I didn't think people would bother to re-arrange the folder structure, or drag files around. It seemed like too much work for something people might not even try.
Turned out they did! So it's probably worth implementing something basic like this (files aware of certain files in relation to eachother and generating a reaction based on that). People get imaginative with whatever folder structure you give them, they play along, so it's worth doing.

Concern: You invest a lot of work in getting this to work, and an OS update could break it. It seems impractical for a one-off. You would have to maintain this.
I don't want to maintain any of this. These ideas are obscure, and don't make enough money to be worth that amount of effort. If an OS update breaks any of this I'm pretty sure I'll just take the download down.

So this is a rare thing. Go play it before it's gone! :)

In terms of practicality, Cyberpet Graveyard and Electric File Monitor both work better. They are less likely to break, but still as hard to maintain... I mean, omg. Cyberpet Graveyard is about 41+ exe's. Imagine the work it would take to update that.

I'm going to wait a while and see how this one is received. That will tell me if i want to pursue this tangent further.
It was really hard to do tho...
I was planing to use all this for a larger project, but I'm not completely convinced that this is safe to do. I'd hate to invest a lot of time into it and watch it break spectacularly. As simple as this one is, it really kicked my ass.

* Self-contained one-off games are easier.
* You should only build something like this if doing something different is important to you.