» 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 Itch.io, 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 Itch.io. 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 Itch.io 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 Wordpress.com 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 main.mm, 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

These pieces were made in a visual design class long ago

The first is a photo of Toronto modified with the app Repix. The second is a photo of DC modified with the app Poly

imgbox

Made in an iPad app called Flowpaper

Long ago I made a game jam entry for Ludum Dare called The Other Sky, and while it wasn’t well developed, I still liked the outcome. I made soundspaces for that game by messing around with a tonematrix in AudioTool, then I stretched the sound very long with PaulStretch, resulting in something that sounds like a soundspace.

I made a game a while ago for Ludum Dare called Gyra. It’s my most polished Ludum Dare game yet. You can play it here.

You can see what other Ludum Dare games I made here.

Interesting Article about Solo Game Dev

It discusses the possibility of personal growth in the context of making games (especially as a hobby).

I recently participated in the 33rd Ludum Dare online game jam.

My entry was called Galactic Space Crusher. You play as a giant spaceship who must wipe out fleets of enemies with an arsenal of weapons.

I couldn’t develop it enough the way I wanted, but if I decide to develop this, I’ll try to make it much better.

Hi there.

I am moving from my old Wordpress blog to a Jekyll powered blog because of the increased ability to customize the look of this blog.

I intend of making this place my home on the web for the unforeseeable future.