Dealing with Screenshot!


These two weeks I’ve been working on refactoring extensively. The code I am working on is responsible for saving the map as an image. It creates a screenshot of the scene and saves to the device’s (Android or iOS) gallery. The first bug I’ve encountered was not showing the recently saved image. Turns out the Show button was missing in the dialog box that’s shown when the save process is over. Then another bug arises when retrieving the image. The device couldn’t read the image while it was working in the Editor on PC.

On iOS, the real reason was unknown but we fixed the bug by telling to iPhone “would you be so kind to open up the photo library” (opening the photo library), instead of “open THAT EXACT file” by giving the exact file path. I guess it was due to an update for iOS that cancels opening the image particularly. Instead of this, we open up photo library so the user can see the latest images from the gallery.

For Android, the file name consisted parenthesis and when I removed the parenthesis from the name, it started to show the image. Before that, the device tried to open the image as a pdf document but failed to do so. The device couldn’t read parenthesis in the name and that mixed up the extensions. The third bug I’ve encountered was a dialog box that’s stuck in the saving process. It was misleading the user that the process is stuck in the middle of the saving process but actually it is done successfully, but there was a problem with updating the UI and hiding the dialog box. I’ve seen that the bug is caused by a forgotten dialog box that code didn’t close. So, please, don’t neglect UI. It needs attention. It needs our care…

These were actually hotfixes that is crucial to meet the expectations of users. But there should be an extensive refactoring of the whole screenshot system. So I started to examine the code and realized it was a monolithic, giant code that governs every single function that’s needed for the screenshot. To be precise it was 800 line of code and it almost does everything. Also, the pro and simple screenshot classes are unrelated classes that do the exact same thing, like saving and opening the file. So I created a class that executes the similar functions of the two modes (aka Factory Pattern). Then I refactored the pro screenshot class and split it into several different classes that handle image size, quality, how many pages it’ll be and show events and props on the map.

After splitting and renaming, I started to test the outcome.

I’ll be updating so stay in tune!


In ProDnD, users can generate their maps and share them on the app’s one of the subreddits, r/ProDnDMaps in Reddit. But the subreddit needs to be opened in-app browser and the maps’ screenshots only can be seen via clicking on the Imgur link. It’s quite a lot job to do, and wouldn’t it be nicer if we had some kind of a store that shows the user-generated maps altogether and you can download them with a single tap?

We thought we could use GameSparks or similar backend services for saving custom user-generated maps and show them in a store-like menu, along with Reddit. Users who want to see the maps in the app, they only open up the menu and scroll through.

Logic is, when a user wants to share the map they’ve created, the code serializes the data (along with the screenshot of the map) and sends to the backend service. And whenever the user opens up the Map Store, they can access the whole archive of the created maps.

The feature is to be implemented so stay in tune!


Saving the game to cloud!


In PlayStation and PlayStation 2 era, we had Memory Cards. Those little cartridges held our sweet childhood memories. For those who had not them, they had to finish them in one session or restart the game every time. But those days have gone, and thankfully, we have cloud saving.

When you develop a Unity game, probably in some case, you need to save players’ data (money, health, unlocked stuff, current level, user-generated content etc.). to the cloud. When the user wants to play it on another device or when the game is reinstalled, either way, the progression that has been made should be present. For this, we can upload the data to the cloud!

For Android, we have Google Play Cloud services and for iOS, we have iCloud.

In Unity, you can have several tools to do this but the concept is the same:

  • Serializing/deserializing of the data
  • Having a binary representation of this data
  • Metadata of this saved game, a representation of this binary package.
  • Uploading it to the cloud service
  • Downloading if necessary

In ProDnD, we have user-generated maps, but they are saved locally in the device and when the app is uninstalled, the data vanishes too (unless you shared it to the ProDnDMaps subreddit in Reddit. In the app, you can share your maps publicly in that subreddit as a QR code. And you can download them from the in-app browser, or use camera to read the QR code.)

However, we also want the users to access to their maps when they change devices or reinstall the app. In Android, besides to the Google Cloud, we can save the app’s data into other folders, outside of the app folder (Also, when the app save the screenshots of the map, the images can be found under the Gallery folder and they never get deleted because it is in outside of the app folder.)

But this only works when reinstalling the app, when it’s about changing the device, it won’t work. So we need to implement Google Play Games Services or iCloud service to provide the solution.

Bug Hunting!


This week’s headline is actually this:

The Bug Hunter Rampages!

In this week, I was given to fix two crucial bugs:

  1. In ProDnD, when the user wants to save the screenshot of the map they’ve created, the game stuck in the saving screen (the UI displays a panel that shows the progress of saving process as percentages)
  2. While zooming in/out in the edit mode, the pen tool draws on the map.

For the screenshot bug, I feared that the bug was related to an I/O issue since the code writes the image to Gallery. Luckily, it was not related to that, but rather it was because of the UI. Somehow progress panel stuck on the screen when the user prefers to save the image as 2 or more pages. (In the app you can save your screenshots as split to 2 or more pieces). The code executes the method that saves the image in a nested for loop. But when the page number goes up 2 or higher, the nested for loop couldn’t function properly. So I fixed this for loop and it started to work as intended.

About the second bug, we use EasyTouch plugin as the primary touch gesture tool in Unity. With that tool, we can detect gestures like swipe, pinch, tap etc. In Edit Mode you can customize the map you’ve generated, but as you can guess there are a lot of gestures to be detected while editing. And the primary concern is that we need to detect them properly and restrict their effect as needed e.g. not painting while zooming in/out.

The thing is, testing on PC is not sufficient. The test cases are almost perfectly executed, the plugin allows the second finger gesture to test on PC and there seems no bug whatsoever. But on Android or iOS, the detection is far from perfect. The user’s two fingers cannot be “exactly” on the device at the same time (I am talking about a moment in milliseconds,  the device usually recognises one of the fingers as the first one, and tries to paint on the map).

And this situation leads to unwanted marks on the map. To eliminate this, I implemented a “time” threshold. When the finger is on the screen for a certain second, and if there is only one finger, then start to draw. Otherwise, don’t draw. It is better than the previous status, but it still leaves some stains, occasionally. I aim to two solutions for this problem; adding a location threshold or adjusting the time threshold. When this feature is refactored properly I’ll update the blog as well.

Stay in tune!

Dependencies and Unused Assets


I really want to talk about the elephant in the room. A crucial element yet the most indie developers’ lack it: proper management of the assets and project files. When projects get big and complex, lots of assets might become obsolete.

The best practice is to keep track of every action taken, by yourself, by the team. You really have to see what asset is used, changed, replaced etc. and decide what’s necessary and what’s redundant. Of course, there would be version changes, no longer supported tools and assets, uncooperatively added files, quickly added hotfix changes, etc. in aged projects and crowded teams. Therefore, it’s almost inevitable to get caught up in this problem even for the indie companies which maintain smaller projects.

If it’s too late for your project, the most common and simple solution as follows: You can export all your scenes in the project as a Unity package. This way, you can see all references, dependencies, assets, and prefabs used in your scenes. Then, you can either select those extra assets and review if they are necessary, or you could create a new project and import this package in there, -so you would have a clean project without these unwanted assets. If you want to continue in the same project, you can also use “Find references in scene” feature by selecting an asset in the project scene. However, as the name suggests this would only show the references in the certain scene (the scene which that asset belongs), so if you have too many scenes this method would take much longer given the fact that you would have to repeat all this for each scene you got.


Stick Biome is DONE!


Hello all! Stick Biome is now officially done! You can see the latest status in the gif below!

Stick Biome _ 2.gif

Now the map has an additional parameter: Diagonal Stick Density. With that, we can adjust the amount of the diagonal sticks, along with the horizontal and vertical sticks.

I started to create the sticks by randomly placing dark dots on the map according to the density amount. Then I elongate the dots, also according to their minimum and maximum stick size.

The most important thing about this map was, I designed it in such a way that the sticks won’t cross each other. Also, they won’t “stick” to each other and create black puddles on the map. Black puddles are the things that make the map look ugly and cluttered, so it’s best to make them stay away. The sticks check their surrounding area before they’re placed. (vertical: left, right and bottom side, horizontal: top, bottom, and right side, diagonal: each dot checks its left and bottom side) This stops them from placing sticks that neighbor one another. But I don’t apply it strictly because it may lead them to be unable to find a place that they fit in when the sticks get crowded. So, whether there’s a puddle or not, the algorithm makes sure that every stick’s border is in the color of the background, so the unnecessary sticks are covered, no black puddles! So with this, I can get a much more neat result with it.

See you in the next map update!