4 ms·
In 2010 I didn't know about version control. I released an Android game and sold it. It did really well. I had released many updates, and hardware was changing
by dpcan 7y ago
In 2010 I didn't know about version control. I released an Android game and sold it. It did really well. I had released many updates, and hardware was changing fast.
I wanted to update the game with all new high res graphics for new devices, and support tablets too.
However, I started working on new functionality in the game, something that kind-of affected the core of every other thing that was happening in the game.
I never quite got that perfect, but I kept updating, making backups, etc. Still, no version control.
Then it turned out that the latest update I released about 4 weeks earlier had an issue with a wide range of devices that someone finally brought to my attention. This was a new Samsung device that everyone was getting.
Customers started writing in about the game not working on their new device.
I had a backup of the code before I released the last update (which had a ton of changes and new features), and then a backup AFTER the release but also AFTER I put in a lot of the broken core functionality.
Basically, I was in a situation of having an 8 week set back to redo all the changes I made before the last release from a backup. That would take about 4 weeks, then I'd have to release, and start again on the changes I've been spending 4 weeks on.
The game was doing well, but I definitely wasn't 2 months ahead in income, and this was a side project.
I ultimately couldn't do anything about it and had to just press on with the new changes that did go out, but in a less than stellar way about 4 weeks after that.
In the meantime, I had to make a ton of refunds for people with certain devices, and then block that device from the dev console and put notes in the description not to buy the game if you are using a device like X.
Doing this basically brought my sales to a halt.
I ended up putting out one more update with the small changes I had that weren't perfect, people didn't love the change, I did make it so people with the new devices could download and buy again, but my rank and sales hand tumbled miserably anyway. The game sold a few copies here and there for a few more months, and then within a year I stopped development completely and stopped selling the game.
So..... version control and proper backups are VERY important, especially if you have customers. This game was my ticket to being an independent game developer making a living selling games, and then it crashed because I couldn't work on an older version.
- ggg3 7y agothe problem here is not even your process. its google/apple walled gardens that do not the end user install a freaking older version!
- echelon 7y agoI'm not sure why you were flagged. While the OP is responsible for a lack of version control, the distribution channel is very inflexible and something developers have to fight with. Many other distribution channels provide multiple binaries or versions and let the customer choose which to install. Apple and Google are very simple and primarily aimed at non-engineer consumers, so it makes sense that they wouldn't allow people to select a version. It doesn't mean that this doesn't suck.
- Siwka 7y agoMaybe things have changed now, but as far as I can remember Google Play does let you deploy older APKs. But it's just from the developer side, it's not like users can choose which APK to download.
- jblow 7y agoWhat happens when the older version does not understand the newer data?
- wruza 7y agoVersion control is mandatory, but it is a tricky question if it could help with that situation much. If I understand correctly, you lost all ways to pick updates and reposition them on a foundation that works on both old and new devices. But that depends on how you use your vcs of choice, and that depends on how you organize your work. With rushing big updates you could end up with basically vcs’d equivalent of two releases you had, one old and one broken. As organizing work is hard under some circumstances (e.g. demand grows faster than your ability to both control your code precisely and stay on schedule, given time constraints), and it could be even not possible to avoid that problem completely by vcs means. Moreover, it wasn’t just a bug, right? It seems that it broke new devices by using something that it shouldn’t use at all, and even with logged, well-separated commits it could be non-trivial to rollback and merge. Because otherwise it would be almost trivial to forward-fix the latest release as well. Of course, that is my blind guess from your description, but I think I got “exactly there” too many times even with proper vcs at hand. Sometimes picking between two distant branches/revisions is as hard as it is with bare diff -ru a/ b/, and involves expert-level vcs skills.
- megaremote 7y agoYou were fine, you just needed a way to compare files to look at the changes, right? Which existed in 2010.