Chott is now avaliable on the App Store

I’m glad to announce that Chott is now available on the App Store!

In case you didn’t know, Chott is a time tracking app aiming specifically for tracking personal creative projects. I made a prototypical version of this for Android before, but this version has more features, like deleting projects and sessions.

For more information about Chott for iOS, you can check out its project page here. Or you can click the black button below to get the app. It’s free!


When making an iOS app that uses Core Data, you would usually make dummy data in the app on a Simulator and see if your data logic is working or not. But what if you wanted to test the app on another Simulator while using the data you’ve already made before? A naïve solution would be to go into the app installed in the other Simulator and recreate the dummy data. This is of course a waste of time.

A better way is to copy the Core Data database files on one Simulator and transfer them into another. That way, you can now test the app on the new Simulator without needing to recreate data.

To be able to do this, a few assumptions are made:

  • You are developing an iOS app with Xcode that utilizes Core Data
  • You already made the data model and are using the entity objects in your code
  • You opened your app in one Simulator and made all sorts of dummy data in it
  • You opened your app in another Simulator and made at least 1 piece of data that’s saved.
    • This is important, because if your Core Data app has no data, it won’t have the folders you need to drag the database files into!

For this demonstration, I have Core Data entities saved into an iPhone 8 Plus Simulator and I want to transfer them to an iPhone SE Simulator. The app being used for demonstration is called “Chott”.


Here’s how to transfer the Core Data storage from one Simulator into another:

  • On your Mac, go to ~/Library/Developer/CoreSimulator/Devices/ with Finder.
  • You will see a heck of a mess of folders with random IDs as names. These folders represent all the different Simulators that Apple installed on your computer. Be sure to sort the files by Date Modified, otherwise it will be a nightmare to look for the right device.


  • Going into those strangely named folders, you will find a file called device.plist. Use Quick Look to check what device this directory represents. In this example, we’re looking for an iPhone 8 Plus.


  • When you’ve found the right device folder, now we must dive deep. There is a folder besides device.plist called data. Now dive into ./data/Containers/Data/Application/. Here, you’ll find more crazy folders of strange IDs. These represent apps installed in the current Simulator, you have to guess which folder is the right one by going deeper: ./[ID]/Library/Application Support/. If you chose the right folder, you should find three files that all start with Chott, which is the app we’re looking for.


  • All three files (.sqlite, .sqlite-shm, and .sqlite-wal) are important, as they contain the app data you made through the Simulator. Copy these files somewhere convenient, and go back up the directory to ~/Library/Developer/CoreSimulator/Devices/. Look through the devices like before and search for iPhone SE, then go to ./data/Containers/Data/Application/[ID]/Library/Application Support/, making sure that the files in there are also called Chott.

  • Copy and paste the files you extracted from the other Simulator into this folder, replacing everything. (When you do this, make sure the app is closed on the iPhone SE Simulator. I don’t want to know what happens!)

And that’s that! Now your data is ready to go on another Simulator. Great for Core Data testing on multiple Simulators.


Usually, when you want an object in code to have a unique ID, a practical solution would be to use something like a GUID (or in Apple’s SDKs: a UUID). These IDs can be converted into strings for serialization purposes, but comparing the IDs as strings is probably not an optimal task.

In iOS 11, Apple allowed Core Data entities to have a new type of attribute: UUID. According to this Stack Overflow answer, the UUID will be stored as a binary when that entity is saved with Core Data, which is more optimal than using strings for storage. This can be used to give your data objects a unique identity when needed.

If you needed to fetch an object (or objects) from Core Data based off a UUID, this can now be done using NSPredicate objects, but you have to cast the UUID as CVarArg in order for the predicate code to work.

Here’s an example of what can be done:

Suppose you had two entities in your iOS 11 app:

  • A Project which has a UUID (called id in code) and relevant data
  • And a Session which holds time information and the Project’s UUID (called projectId in code).

If you were given a Project object and wanted to fetch an array of Session objects matching that project’s ID, the following is a good way of doing that:

func getSessions(forProject proj: Project) -> [Session]? {
    let requestSessions: NSFetchRequest<Session> = Session.fetchRequest()

    // Make a predicate asking only for sessions of a certain "projectId"
    let query = NSPredicate(format: "%K == %@", "projectId",! as CVarArg)
    requestSessions.predicate = query

    // Perform the fetch with the predicate
    do {
        let foundEntities: [Session] = try CoreDataService.getContext().fetch(requestSessions)
        return foundEntities
    } catch {
        let fetchError = error as NSError

    return nil

Notice the initializer for NSPredicate takes a format string representing a query into Core Data. NSPredicate also allows for use of a Swift closure instead of a type-unsafe string for query, but quite unfortunately, Core Data will NOT take predicates that were initialized with a closure; it needs the silly formatted string.

The formatted string is simple enough. The parameter represented by "%K" is the key of the attribute you want to search for, and the "%@" is the value of the search. The key we want is Session’s attribute projectId, and we are searching for the UUID object represented in code as, but this must be casted as CVarArg or the code won’t work.

After setting the predicate and performing the fetch, it should return an array of Session objects associated with the given Project, if they exist in persistent storage of Core Data.

This code would have worked fine if UUIDs were converted to strings, but string comparison is usually slow, and this can add up if there are many instances of an entity you want to search for.

Remaking Chott for iOS

A couple of years ago, I was learning Android development in graduate school, and as a final project, I wanted to make a time tracking app for personal hobbies, which came to fruition as Chott. Now that I’m learning iOS development, I wanted to remake this app for iPhones.

I’m using Core Data as the local storage solution. I’ve use a tiny bit before, but now I’m using a new feature that allows Core Data entries to have UUIDs as a attribute. (UUIDs are like GUIDs in other languages.) Unfortunately, this feature has forced me to target the app at iOS 11 (the latest version at the time of this writing). I wanted to support to iOS 10, but I wanted to use the new UUID attributes, because I felt it would be faster than storing strings IDs.

I developed the UI of this app to look almost identical to the original Android version. I would have liked it to be on iPads, but I had a little dilemma: I wanted the iPhone version to be only in portrait orientation, while somehow allowing any orientation on the iPad. I currently didn’t know how to do this. And also, since Chott currently doesn’t have cloud sync support, I figured that it would be good for now to just target iPhones and not iPads.

I’m ready to submit to the App Store soon. If you want to find out more about Chott for iOS, check out it’s project page here for a list of features and screenshots.

Making an alarm clock app for iOS

After learning iOS development from Devslopes, I figured that I should start making apps myself as a learning experience. I wanted to start off with something relatively simple, like an alarm clock.

I already use an alarm clock app, so I utilized it as a reference to make this new app. I wanted a dimmable clock face that works on different orientations and different screen sizes. The idea was to make an alarm clock app that can also serve as a bedside clock (which is what I do at the moment).

I call this app Minapps Alarm Clock. The “Minapps” is just short for “minimal apps”, because I wanted it to be relatively simple in functionality. If I make more simple apps, I intend to attach the “Minapps” name to them.

I’m a little surprised how long it took to develop this alarm clock (about two weeks), but I fortunately learned some new nuances of iOS development. Here’s a list of skills I gained from making this app:

  • How make multiple text labels scale properly on iPad and iPhone screens.
  • How to schedule functionality with the Timer class.
  • Wrangling with the difficult Date class.
  • Reading the UIDevice class in order to disable auto-lock and to read the device battery life.
  • Using UserNotifications to send local notifications to a user when their alarms ring outside of the app.
  • Using a Settings Bundle to tweak the alarm clock settings.

I’m happy to say that Minapps Alarm Clock is available on the App Store.


If there are any bugs, open a new Github issue here.

Lately, I was learning mobile app development on iOS platforms. Since I always use an iPhone (and sometimes an iPad), I figured that I should be able to write software for these things.

I was actually exposed to iOS development before, in the distant past. Back then, it was very difficult and confusing, but I must admit that my programming skills were not as sharp back then either.

But now I finished learning the basics of iOS development from the DevSlopes team on Udemy. If you like being self-directed in your learning but want some guidance, DevSlopes is great for that.

Last month, I completed their iOS 11 & Swift 4 course. You can see my Certificate of Completion here.

At DevSlopes, you code several projects, learning the different aspects of the iOS platform. The following is a select list of such projects I uploaded onto GitHub. You can see screenshots and more information there:

  • RetroCalc: A simple iOS calculator app
  • Ramp Up: An iOS ARKit demo featuring live-sized skateboard ramps
  • Rainy Shine: A very simple weather app for iOS with 5-day forecast
  • Goal Post: An iOS app demo utilizing Core Data to try to track new goals
  • Bot Vision: An iOS machine learning demo (using CoreML) where the app tries to recognize everyday objects
  • Pixel City: An iOS app demo were users can browse Flickr photos based off map locations
  • Breakpoint: A micro social networking iOS app demo aimed for coders and other geeks, powered by Firebase
  • Confaby: An iOS Slack clone demo app that features realtime chat messaging
  • Scribe: An iOS app demo that dictates a pre-recorded voice message

I’m glad to announce that Gyra is now available on the App Store! I personally tested iOS builds on an iPhone 6 and an iPad Pro 9.7” with no problems.

If you are new here, you can read more about Gyra here and try desktop versions of the game for Windows, macOS, and Linux.

This is officially my first game (or app for that matter) on the App Store, so it certainly feels like an achievement to see one of my works on such a notable platform. Gyra is available for free, and also free of ads and in-app purchases, so please try it out.


Hope you have fun!

Submitting to the App Store is a pretty hefty task. While submitting Gyra, I sort of documented as much of the process as I could. This is not by any means comprehensive, as I omit a lot of details about iTunes Connect. However, I hope that this will still be sort of a helpful guide in submitting Unity games to the App Store.

This guide presumes that you already exported your game to iOS from Unity’s Build Settings. This creates an Xcode project you may have to tinker with later. You must also be subscribed to the Apple Developer Program (which is $99 a year for individuals).

Make A Distribution Certificate

Certificates are used by Apple to sign your app, thus identifying you as the developer. Certificates are tied to a computer and there are multiple kinds (like for development and for distribution). The following procedure is for getting a certificate to submit to the App Store:

  • Login to your Apple Developer account and go to Certificates, Identifiers & Profiles.
  • Press the button on the top right corner.


  • There are many types of certificates. For a distribution certificate, select App Store and Ad Hoc and press Continue.


  • It will tell you to create a Certificate Signing Request. You will eventually send this CSR file to Apple, which in effect is like asking Apple for permission to distribute your app. The certificate itself is the granted permission to distribute. Click continue.
  • Open the Keychain Access app on your Mac (remember that a certificate is tied to a Mac, so you can only distribute from the Mac with an installed distribution certificate).
  • Go to the menu Keychain Access ▶ Certificate Assistant ▶ Request a Certificate From a Certificate Authority…
  • Provide your email in User Email Address, and your name in Common Name. Do not fill out CA Email Address.
  • Select Save to disk and click Continue


  • Save the file CertificateSigningRequest.certSigningRequest in a convenient directory (like the Desktop folder, for example).
  • Back on the Apple Developer site, you should see the field Upload CSR File. Drag and drop your .certSigningRequest file onto the button that says Choose File, then click Continue.
  • Your certificate should be ready. Download it and double click on it. Xcode should open, and the certificate should be installed (it won’t give you any confirmation of that, unfortunately).

Make App ID

An App ID is a unique identifier for each app on the App Store. Typically, this ID is based off your app’s Bundle Identifier (that can be found in your Xcode project’s settings).

  • To make an App ID, go back to the Certificates, Identifiers & Profiles section of the Apple Developer site, and click on App IDs on the left side.
  • Press the button in the top right corner.


  • Enter name for your App ID. This is typically the name of your app.
  • Select Explicit App ID, and provide a Bundle ID (it must be the Bundle Identifier of your app in the Xcode project’s settings). Click Continue.


  • Click Register, and then click Done.

Distribution Provisioning Profile

A Provisioning Profile is kind of like a “package” that ties your certificate (your computer) to your app, and your testing devices (for development or ad hoc profiles). Provisioning profiles can authorize running an app on a test device (development) or for submitting it on the App Store (distribution). The following instructions are for making a Provisioning Profile suitable for submitting to the App Store:

  • Back to the Certificates, Identifiers & Profiles section of the Apple Developer site, and click on Provisioning Profiles on the left side.
  • Press the button.


  • Select App Store and click Continue.


  • Select the App ID you just made from the drop down menu, and click Continue.


  • Select your distribution certificate and click Continue.


  • Now name your Provisioning Profile. Choose something very specific. I personally chose GyraiOSDistributionAppStore. Click Continue.


  • Download the Provisioning Profile and double click it. It should install, but you will not get confirmation for that.


You may have to repeat these same steps for a Developer Provisioning Profile (which allows testing locally in your device). You would select iOS App Developer instead of App Store when choosing the type of profile. You may also have to provide mobile device UDIDs to allow testing (Xcode might take care of this for you, if you plug in your device to your Mac while Xcode is open).

Setting up the Xcode project with the Provisioning Profile

  • Back in Xcode, go to project settings. Make sure that you select the app target
  • Uncheck Automatically manage signing


  • For all Release Signing sections, provide the Distribution Provisioning Profile.
  • For Development Signing section, provide a Developer Provisioning Profile. (Note that if this doesn’t work, change it to the Distribution Profile instead.)


  • Now go to the Product menu and select Archive. It should build a package that is ready for submission to the App Store.
  • If archiving fails, try changing the Signing (Development) section to use the Distribution Provisioning Profile.

When it’s done, it will load a window called the Organizer where you can validate and upload your app. But first, Apple needs to have a record for this app on iTunes Connect before you can upload it to the App Store.

New app on iTunes Connect

  • Login to iTunes Connect (you must be a paying developer), and go to My Apps.
  • Click on the button and select New App.


  • Fill out the form provided. Check iOS. The Bundle ID is the App ID we created. The SKU is a unique ID; try giving it a relevant name. It may possible be taken though, so come up with something very unique.


In my case, it was the app name that was taken. This is the name that shows up on the App Store. It also must be unique like the SKU. I changed mine to add a little more detail. Press Create when you are done.


Submitting Build to iTunes Connect

  • Go back to the Organizer in Xcode.
  • Go to your app archive and validate it first.
  • It will ask for your Distribution Provisioning Profile before continuing.
  • If validation fails, resolve any issues mentioned and try again.
  • Once validation succeeds, click Upload to App Store…


Note that Apple does some processing on your uploaded build before you can choose it on iTunes Connect. You may have to wait for an hour or more.

Prepare App Submission

Apple will send you an email when they have finished processing your uploaded app.

  • Once that happens, go to iTunes Connect ▶ My Apps.
  • On the App Store tab, fill out all of the required information needed for app submission. There is too much of that to cover here, but it should be easy to figure out.
  • You will need at least 2 screenshot: one for a 5.5” iPhone and the other for a 12.9” iPad. You typically get screenshots by running the app on an iOS Simulator and pressing Command + S.
  • App Previews are basically video previews of your app that autoplay in the App Store. Apple has a good reference about making App Previews here. However, I must warn that you need a 5.5” iPhone (any “Plus” sized iPhone) and a large iPad (9.7”+ suffices) in order to have the necessary App Previews needed for the App Store. Fortunately, App Previews themselves are not required when submitting an app.
  • On the Prepare for Submission page, scroll down to the Build section and you should be able to select the build you recently uploaded. If you want to make newer builds later, don’t forget to increment the build number and version number in the Xcode project’s settings.
  • After you have filled out everything, click Submit for Review towards the top of the submission page. Apple will soon review the app for approval.

If Apple emails you saying they they approve of your app, it may still take about a day for it to actually show up on the App Store.

Building Gyra for iOS

Lately, I’ve been learning iOS development in order to increase my skills. I’ve gotten pretty comfortable with Xcode 9 and Swift 4, and I even have a some idea of how submitting to the App Store works (although it’s still pretty complicated).

I soon realized that I might be able to submit something I already made to the App Store. So lately, I’ve been looking over Gyra and trying to make it suitable for submission. My reason for choosing Gyra is because it’s relatively polished, and was already made mobile-friendly. The game was made 2 years ago for Ludum Dare, but because it’s simple, I felt this would be a good project to get onto the App Store.

I only needed to do a few tweaks to Gyra before it would be ready for submission. Firstly, I made the game UI larger, so that it would look good on mobile devices. I did some tests on an iPhone 6 and an iPad Pro 9.7”, and found the original UI too small. Currently, I’m not sure how anyone would factor scaling of in-game UI to different screen sizes (like mobile vs. desktop for example).

I provided app icons and splash screens for Unity’s Player Settings, but long story short, there are some issues with stretching and quality of icons and splashes (using Unity 2017.2 at the moment).

Fixing App Icons

For starters, to make a bunch of images that an iOS app icon requires, I made a single 1024x1024px image. Then I uploaded it a nice web app called MakeAppIcon which helps you generate all of the necessary scaled images needed for an iOS app icon. I downloaded the generated zip of images and put them into the Unity project. In Player Settings, you can override game icon for iOS (and Android if you want), and I placed the different icon sizes into the different image slots.

But an issue occurs concerning the quality of the icon images. If you build your Unity project to iOS (generating an Xcode project), and you build the exported project to your device, you will find the quality of the app icon to be lacking. I suspect that this is a bug with Unity that needs to be addressed.

Here’s how to make sure your icons are top quality for an iOS game made in Unity:

  1. Make your app icon images (as I mentioned above with MakeAppIcon).
  2. Build your Unity game for iOS and open the generated Xcode project.
  3. In the Project Navigator, open the file Images.xcassets.
  4. In this file, locate the AppIcon set and delete it (Right Click -> Remove Selected Items).
  5. Click on the plus icon at the bottom of the screen (+) and select App Icons and Launch Images -> New iOS App Icon. The new set should be called AppIcon. The reason you have to do this is because Xcode will make a more up-to-date icon set than the one Unity provides.
  6. Place in your generated app icons into this new icon set.

When I built the game after this, the app icon looked much better on my iOS devices. I unfortunately wouldn’t trust Unity’s ability to export app icons for iOS.

Fixing Launch Images

Unity’s ability to export a game into iOS is mostly good. But I have found that one of the most obnoxious things to get working after exporting is the launch screen (the first screen(s) the user sees before the game loads).

Long story short, I did not rely off Unity’s Splash Image settings. I would either get a black screen or an ugly stretched splash image when I did, which looked very unprofessional.

I then decided on tweaking the launch image manually in the generated Xcode project. Here’s what I did:

  1. Make a single square splash image that is 2208x2208 pixels. (This may not be suitable for every game project). The original splash image should be affixed with @3x before the file extension. Now clone this image shrunk down to 1104x1104 pixels (affixed with @2x). Finally, clone again and shrink it down to 552x552 pixels.
  2. Drag these three images into Xcode’s Images.xcassets file. (The images should all have the same name, with the affixed @2x and @3x.)
  3. In the generated Xcode Project Navigator, go to LaunchScreen-iPhone.xib. Xcode may ask you to select a device to preview the screen in. Select any device.
  4. Select the image view in Interface Builder, go the the Attribute Inspector and set the image to the new splash image you just added. You should update frames if you see orange line in Interface Builder.
  5. Repeat Step 4 with the file LaunchScreen-iPad.xib
  6. Go to the Xcode project’s General settings. Make sure the app target is selected on the top left corner. Scroll down to the section App Icons and Launch Images
  7. For the field Launch Images Source, choose Don’t use asset catalogs.
  8. For the field Launch Screen File, choose either LaunchScreen-iPhone.xib or LaunchScreen-iPad.xib (didn’t matter in my case).

This more or less resolved my silly splash screen problems. Hopefully these issues will be resolved in a future version of Unity.

» Play Caelium Alpha Here «

Caelium Alpha was something that I always wanted to make, interactive software for making imaginary solar systems. I think this was my more favorite Ludum Dare event yet. I made something decently playable within the 72 hours, but also made a Post-LD build that has more features and bug fixes.

I really appreciate all the people who played the game and gave feedback! The feedback will help me greatly in determining what features to add to the game and what should be fixed. I intend to keep making this after the event’s over, but it will have to progress very slowly.

What Went Well

  • I’m happy with the complex object hierarchy that allows each of the planets to orbit around the star with different orbit speeds and rotations. It can even support tilt (like the planet Uranus), but this was an experimental feature that was not released as of yet.
  • The UI could always improve, but I don’t use Unity’s UI features that much, so having the changeable UI with sliders feels like an accomplishment.
  • Planet selection with the mouse. Doesn’t sound like a big deal, but it’s fundamental in order for this game to work.
  • The particle effects help with depth perception and adds visual cues to the game.
  • Got great feedback from the Ludum Dare community. Thanks again!
  • Object-based data system that allows stars, planets, and moons to have adjustable properties that they all have in common while also having unique features.
  • Decoupling between a planet’s data and the scripts controlling the properties of a planet.
  • (In the Post-LD Version) My implementation of auto-padding between planets allow planets to change size or have additional moons without other planets colliding them.
  • (In the Post-LD Version) Being able to use a musical piece from Stephen Tanksley. Adds nice atmosphere to the game!

What Went Badly

  • Towards the end of the jam, I encountered a weird bug where multiple planets would spawn the more you add planets. This bug was fixed because someone told me that I could fix important bugs after the jam. The bug was caused by a prefab referencing itself, which is apparently a big no-no in Unity; I wrote a blog post explaining this problem in depth.
  • Did not have time for sounds in the LD Version, but they are fortunately available in the Post-LD Version.
  • Many people were not fans of the camera controls (especially zooming). I myself do not like my own camera implementation, but I couldn’t spend the entire jam making the perfect camera controls ;p
  • My code organization was okay, but it could still use a minor refactor if I intend to develop this game further.
  • Could not get moons implemented during the jam, but fortunately they are available in the Post-LD Version.

Features I’ll Consider in the Future

These desired features are not listed in any particular order, and are only up for consideration. They may or may not eventually be implemented:

  • The ability to tilt a planet’s orbit and rotational axis (these are partially implemented, not made available to the user).
  • More music and sound effects
  • More realistic orbital speed dynamics based off orbital distance
  • Better camera movement controls (including better zoom (no more fisheye), “anchoring” on selected objects, and top-down view)
  • Different types of planets (rocky, terrestrial, gas giant, etc.)
  • Rings around planets
  • Ability to remove planets and moons
  • Procedural textures with adjustable color properties (very long term feature)
  • Procedural space skyboxes (very long term feature)
  • Realistic rim shader for planets and moons
  • Flare and light effects for stars
  • Rename planets, stars, and moons
  • Pause planetary movements

Once again, I thank everyone who played the game and gave feedback. If you want to follow further development, you can either follow me on Twitter, follow the game on, or bookmark Caelium Alpha’s project page on this blog.

I am happy to announce that the Post-LD Edition of Caelium Alpha is now avaliable on Last post, I mentioned about a bug where planets would clone multiple times. Fortunately, that bug was fixed, and I also added the ability to add moons, which wasn’t supported in the original Ludum Dare entry.

The Post-LD Edition also features a soundtrack from the composer Stephen Tanksley (great music for modern games) and sound effects from Glitchmachines. Audio really does make a big difference!

If you are interested in reading more about the original Ludum Dare version of Caelium Alpha, you can read about it on its Ludum Dare page.

On the previous weekend was the 38th Ludum Dare game jam, which has now been going on for 15 years. This time around, the theme was “A Small World”. As I thought about how to design a game around a small world, I remembered a project that I always wanted to do.

A little history first, I always wanted to make a “game” involving building your own solar system (or planetary system, which is the general term). It would always be more of a sandbox, akin to Minecraft or SimCity. I’ve called this game idea Caelium (which originates from a word “caelum” for “sky or heavens”). I’ve wanted to make a serious prototype of this game, but for various reasons I couldn’t (life, college, grad school, etc.)

So concerning the game jam theme, I figured that I could probably make Caelium resemble “a small world” by trying to imitate an orrery, which is a model of the solar system. By participating in this game jam, I finally made serious progress with this idea. Since it’s still early, I called the game Caelium Alpha.

Unfortunately, the current version of the game has a strange bug where multiple planets spawn when trying to spawn one planet. This was due to a prefab reference problem in Unity I mentioned in another post. I intend to make an improved version of Caelium Alpha that fixes this problem and also add the ability to spawn moons (which is currently not supported).

If you want to try out the game prototype, you can go to the game’s Ludum Dare page, or the game’s page.

In Unity, I wanted to set up a situation where there is a prefab, and it contains a script, and that script references back to the prefab. The reason for this strange setup was because, once cloned, that GameObject can keep cloning itself as instructed by the script.

When I started cloning this prefab, I discovered that mutiple objects started popping up (instead of one). I tried breakpoints and logging messages, but I couldn’t figure out why many clones were popping up from one invocation.

I eventually went into the object hierarchy and found that the root prefab clone had a very important GameObject reference mysteriously changed. The original prefab would have this reference pointing to itself, but when cloned in the scene, the clone would no longer point to the original prefab, but instead to the clone itself, automagically!

After a ton of searching, I found a discussion on the Unity Forums pertaining to this problem. It was here that I found out that any prefab that references itself and then get cloned, the clone will reference itself, not the original prefab.

I frankly consider this unexpected/undesireable behavior, but on the forum thread, someone from Unity said that it was by design. Perhaps I can understand that the underlying implementation of Unity is complex, and they had to make decisions that can look strange to an outsider. But I still would consider this to be a bug, because it cost me a ton to time to fix this issue. I was working on a game called Caelium Alpha when I encountered this problem, which happened around the last 2 hours. I was not able to fix it before time was up.

So the moral of the story is that you should never have a prefab that references itself in its own scripts. It can cost you your development time!

If you are curious to know a workaround, personally I just resorted to loading the prefab from a Resources folder in the Unity project, and loading the prefab with Resources.Load(). This is actually not my prefered way to solve a problem like this, but I decided to go for it, because there was only 1 prefab I wanted to clone, not a hundred different prefabs.

Since moving to Jekyll and GitHub Pages, I wanted a way to write a new blog post from a mobile device. I admit that I might not write from a mobile device very often, but it’s nice feature to have, and has an app to make this task easier.

I searched long and hard for ways to write posts on an iOS device and post them to this blog. Long story short, I found a way from hardscrabble that involves using an app called Editorial. It’s a pretty advanced text writing app that has tons of features like templates and custom workflows. Instruction provided by hardscrabble show how to set up the app to write to your Jekyll-powered blog (if it’s hosted on GitHub Pages). The custom workflow hardscrabble made can be found here. I did a few tiny tweaks, but it works perfectly.

This post was written in and sent from the Editorial app.

At DePaul University, typical coding projects take about 3 months to complete. However, if you are assigned to make a game engine, it can take 9 months! (That’s 3 quarter terms at DePaul).

LGE is the result of a long-term sequence of game engine development courses where students are tasked with making a game engine. You start with graphics and math, but then build up many other systems like run-time formats, hierarchy trees, and even skinned animation, on the GPU! You take the same engine you made the previous course and keep developing it.

Let’s just say it wasn’t a walk in the park.

But it’s definitely the most advanced code I’ve written yet. It may be useable for a simple animated game (although LGE doesn’t have an audio system).

You can learn more about the LGE game engine at the project’s page, or download the code from GitHub.

In interactive media (ie. video games), procedural generation is gaining momentum, and I think it’s a really cool concept; making computers do the art (or level design).

Another thing I think is cool is outer space, especially planets. The best of both worlds collided back in the early 2010’s with an old iPad app called Planetary. It made very good use of procedural generation techniques to make life-like planets on the screen. Unfortunately that app doesn’t exist anymore (although the source code is available).

That app inspired me to try to make procedurally generated planets. I found an opportunity to do so as a grad school research project. The result is the library Procedutex, which can procedurally generate textures of many kinds, although I mostly used it to demonstrate planetary textures.

You can read more about it at the project’s page, or you can get the source directly from GitHub (code is Windows only).

Through the last couple of years, I’ve been making a few software systems in C++ (mostly game code for grad school). But all of that C++ code was always written for the Windows platform.

I really wanted to know what it would be like to write C++ game code on a Mac (since I use Macs quite a bit). I must admit, it wasn’t easy, since Xcode thinks you only want to write C++ for non-visual command line stuff (and not something visual like a game).

I looked long and hard for a way to make a GUI project in C++ on Xcode. It seems that you have to make a Cocoa Application and use Objective-C as the language. That seems counter-intuitive, but since the main() function is mostly C-style, you can remove the Objective-C code, rename the file, and use a 3rd party GUI library like GLFW to launch a window with OpenGL context.

From there, you can make an OpenGL-powered game engine in C++ that runs on Macs. I did exactly that with an engine I call Sea2D (Sprite Engine Apple 2D). You can go the project’s page to find out more, or you can get the source code directly from Github.

One of the hardest classes in grad school was a class where you make Space Invaders. You would think that would be easy, but it was actually very difficult (although rewarding in the end). From basically nothing (other than a barebones OpenGL graphics API written for C#), students were to recreate the famous game Space Invaders.

You can read more about that at the project’s page, and get the source code from there too (Windows only).

During college, I took an Android Development course, and the result of my final project was a neat app called Chott (an acronym for “Creative Hobby Occurrence Time Tracker”). The premise behind the app was to track the time spend on creative hobbies/work, a concept partially inspired by Devine Lu Linvega’s Horaire.

I actually use iPhone most of the time, so I don’t use Chott. I’ll consider making something similar in iOS later. Regardless, it’s a usable app (although you cannot delete records made in the app). If you have an Android device and Android Studio, you can go straight to GitHub to get the source, or go to Chott’s page for more info on the project.

These are old artworks from an art class I took long ago