Category Archives: Development

Steam Early Access: Four Weeks In

So it’s been four weeks since we launched Drifter on Steam Early Access and I figured it might be worthwhile posting about our experience launching there. The short version is it’s definitely been a very positive experience so far and assuming that we can continue to grow interest in the game while we work on it this will be the best year yet for Celsius Game Studios.

Continue reading

Briefly Looking Back Before Charging Forward

I had originally meant to post this on my birthday a few days ago but a blizzard over the weekend with record cold temperatures followed by rolling blackouts necessitated by a sharp increase in demand on our electrical system and then ultimately a province-wide blackout for a few days kinda put a damper on any computer-related activities such as blogging.

That said, instead of New Years Eve, my birthday occasionally becomes a focal point of my life where I reflect on how things are going and look to the future. I think most importantly my impending 30th birthday, four years ago, became the catalyst that drove me down the path to creating Celsius Game Studios and attempting to follow my dream of creating my own video game company. While the road has been bumpy at times the journey overall has been great so far and despite occasional slowdowns and setbacks it feels like 2014 is poised to be an amazing year.

Continue reading

A Simple Data Serialization System for C++

It’s been a while since I last blogged, as I’ve been quite busy working on Drifter; both the game and the physical rewards for Kickstarter. Many of which, I might add, have already been produced and sent off to my backers. Also a close family member was diagnosed with cancer over the summer and that threw me for a bit of a loop so things have been a bit out of sorts, however while they’re not out of the woods yet things are looking very promising. So in an attempt to return to some level of normalcy I’m going to try and get back to my “hectic” one-blog-a-month-or-so schedule.

Continue reading

Pluggable AI Using Polymorphism

I was talking briefly on Twitter the other day about how I was using polymorphism in C++ to handle different types of AI in Drifter and someone suggested I should make a blog post about it. As I’ve been wanting to post something new for a while, I figured why not!

I apologize in advance if this is not the Right Way to do this, but it works, and that’s the main thing. Also I reference C++ but any object-oriented language that supports sub-classing should be able to implement something similar.
Continue reading

Converting Game Sound Assets via OS X to Save Space and Memory

Another audio-related mini-post!

I had mentioned on Twitter earlier how I had written a script to convert all the WAV assets in Red Nova from unnecessarily large 32-bit floating point 44 kHz format to a space and memory saving 16-bit integer 22 kHz format. This basically cut the size of the files to less than half, which is pretty fantastic when you’re dealing with a hand-held device with memory constraints like the iPhone. Hell, it will also improve loading times!

Anyway someone asked me to share the script I made, which is a fairly simple Bash script. Just create a file somewhere, call it something like convertwavs.sh, and paste the following into it:

#!/bin/sh
mkdir oldwavs
for f in *.wav
do
   cp $f oldwavs/$f
   afconvert -f WAVE -d LEI16@22050 $f $f
done

Run chmod +x convertwavs.sh from the terminal to make it executable, then change to the folder containing the WAV files you want to convert and run the script like so:

/path/to/convertwavs.sh

It will make a sub-folder called oldwavs and copy the originals there in case anything goes wrong and then convert the files in place. That’s it!

Quickly Convert Your Game Music to AAC on OSX

This is just a quick post aimed at iOS developers covering the incredibly easy command-line method to convert your music files to AAC format. The reason you might want to do this is because MP3 is encumbered with a patent which covers the distribution of MP3’s commercially, even as part of a game (see here). It should also be noted that Apple’s license for their hardware MP3 decoder does not in any way cover your distribution of MP3’s in your game.

You could convert to OGG Vorbis, which is of course free and clear to distribute as you please, however many devices (including iOS devices) do not support hardware accelerated decoding of OGG Vorbis files so you are losing some of your CPU cycles for your music decoding. Luckily, there is a third option: The Advanced Audio Coding or AAC format, which of course is supported in hardware by all of Apple’s portable devices. There are patents surrounding AAC but none of them restrict the distribution or streaming of files encoded in AAC.

Anyway now that I’ve spent all that time leading up to a single command, here it is…

afconvert -f m4af infile.mp3 outfile.m4a

And that’s it! As far as I’m aware you can use any of the iOS SDK methods for music playback with this new file.

A More Robust Game Center Availability Check

I just wanted to share the small addition I made to the isGameCenterAvailable() function Apple provides for checking to see if Game Center is available/supported by a particular device.

The reason this is necessary is because the iPhone 3G supports iOS 4.1+ however it does not support Game Center, therefore the Apple-provided isGameCenterAvailable() will say GC is supported, when it is in fact, not.

Enjoy!

Edit: Some people have questioned why I should do this, especially when Apple themselves recommend against it. This is because the current Game Center login dialog as presented in-game when calling authenticateWithCompletionHandler has absolutely no information as to the purpose of the login. While most people will rightfully assume it’s for Game Center, there are still a number of reports of users getting angry at developers thinking that they are trying to steal their login information. So the idea here is to use this code in conjunction with a friendly dialog explaining the impending Game Center login and how awesome it is, thus reducing the potential for user confusion. The reason you want to check for the 3G is so you don’t present your “I’m about to log in to Game Center” dialog and then… not log in to Game Center.

If the situation with the dialog improves, or the 3G is ever graced with Game Center support, it is easy enough to update your game to take out the check for the device.

#import <GameKit/GameKit.h>
#import <sys/utsname.h>
 
bool isGameCenterAvailable()
{
	// Check for presence of GKLocalPlayer API.
	Class gcClass = (NSClassFromString(@"GKLocalPlayer"));
	// The device must be running running iOS 4.1 or later.
	NSString *reqSysVer = @"4.1";
	NSString *currSysVer = [[UIDevice currentDevice] systemVersion];
	bool osVersionSupported = ([currSysVer compare:reqSysVer options:NSNumericSearch] != NSOrderedAscending);
 
	if(gcClass && osVersionSupported)
	{
		struct utsname systemInfo;
		uname(&systemInfo);
		//iPhone 3G can run iOS 4.1 but does not support Game Center
		if(strcmp(systemInfo.machine, "iPhone1,2") == 0)
		{
			return false;
		}else{
			return true;
		}
	}else{
		return false;
	}
}

Blender Export Scripts

Inspired by the idea behind iDevBlogADay I have decided to continue to blog more, as I enjoy writing and sharing useful (and not so useful) information.

Today I’m going to talk about adapting Blender for use in game development, specifically for exporting textured 3D models from Blender for use in our games.

I am assuming you know how to make Blender work and have created a mesh with a UV texture map. The problem you’re having specifically is getting that mesh out of Blender. You could of course use one of the built in exporters, but this way is more educational, also sometimes it is good to have control over the format your mesh data is stored in. The file described here is pretty basic, but hopefully this gives you enough working knowledge of Blender’s guts to use this as a springboard to create awesomer things. Another thing to take into consideration is that Blender and OpenGL use slightly different coordinate spaces, but it is not hard to work around.

Anyway, the language of choice for Blender is Python. If you like tabs, you will like Python. Much like how LISP was invented by parenthesis fetishists, I suspect that Guido van Rossum has a thing for tabs.

So, let’s get crackin’! Fire up your favorite text editor and do the following:

#!BPY
"""
Name: 'MyMeshExport'
Blender: 248
Group: 'Export'
Tooltip: 'Export a MyMesh File'
"""
 
import Blender
import bpy

What this does is tells Blender that it’s a Blender Python script named “MyMeshExport”, runs on at least Blender 2.48 (you can change this as you see fit), and goes in the “Export” group. The imports hook into a bunch of Blender specific stuff including the scene.

Next, we’re going to specify the “write” function for the script. This is what is run automatically when you choose this script to export it.

def write(filename):
	out = file(filename, "w")
	sce = bpy.data.scenes.active
	ob = sce.objects.active
	mesh = ob.getData(mesh=1)

What this does is opens a file for writing, and hooks it to out, takes the currently active scene assigning it to sce, the currently active object and assigns it to ob, and then assigns the first mesh in ob to mesh. This assumes you have selected your object before you exported, and that object only has one mesh.

Next we’ll put in how many vertexes and faces there are in our mesh into the file. This will make life easier for our file loader:

	out.write('%i Vertexes\n' % (len(mesh.verts)))
	out.write('%i Faces\n' % (len(mesh.faces)))

Next we insert vertex co-ordinates:

	for vert in mesh.verts:
		out.write('v %f %f %f\n' % (vert.co.x, vert.co.y, vert.co.z))

This goes through each vertex in the mesh and inserts “v x y z” where x, y, and z represent the co-ordinates of the vertex.

Finally we write in information for each face in the mesh, including what vertexes make up the face, the vertex normals for that face, and the UV coordinates.

	for face in mesh.faces:
		out.write('f')
		for vert in face.v:
			out.write(' %i' % (vert.index))
		out.write('\n')
		out.write('n %f %f %f\n' %(face.no[0], face.no[1], face.no[2])
		out.write('n %f %f %f\n' %(face.no[0], face.no[1], face.no[2])
		out.write('n %f %f %f\n' %(face.no[0], face.no[1], face.no[2])
		for uv in face.uv:
			out.write('uv %f %f\n' % (uv[0], uv[1])
	out.close()
Blender.Window.FileSelector(write, "Export")

This is where the per-polygon information is spat out into your file. For each face it outputs “f v1 v2 v3” where v1, v2, and v3 are the indexes of the vertexes we exported previously.

Next we output the normals. In this simple example we’re going to assign the face normals to each of the vertex normals. This is because whatever Blender thinks the “smooth” per-vertex normals are has no basis in reality what-so-ever. If you want to get smooth normals, you will have to compute them yourselves. The normals are encoded as “n fn1 fn2 fn3” on 3-separate lines (one per vertex) where fn1, fn2, and fn3 is the face normal.

Finally we output the UV coordinates of the texture map. For each vertex in the face we get “uv uv1 uv2” where uv1 and uv2 are the UV coordinates of that vertex.

The last line in the file tells Blender to open it’s File Selector window and call ‘write’.

Once you save your file with an imaginative name like ‘myfileexport.py’ you can copy it to wherever Python keeps its scripts. This is different under different platforms obviously, though you can get that information here, which incidentally I discovered after writing all this is practically identical to my post, except I cover exporting UV coordinates. Possibly because this is where I learned this over a year ago and subsequently forgot. Mea Culpa.

Anyway, let’s finish this up. So you’ve put your script into your scripts folder. Now you need to update the menus in Blender to tell it that it’s there. So you go to the Python pane and go to Scripts > Update Menus. Then you can go to your scene, select your object then go to File > Export > MyMeshExport to save your new mesh for inclusion in your game.

GameFontMaker

GameFontMaker Icon

GameFontMaker

July 9th Update: GamefontMaker is now at 1.0.0 beta 2 and it’s also been released under the GPLv2. You can find the latest version and source over here!

It’s been a while since I’ve posted anything to the blog, so I figured I’d do something a bit special to try and get into the swing of things. So, I present to you what I think may be the first native Cocoa bitmap font creation tool for games, GameFontMaker!

At least, I think it is… Maybe… I didn’t do a lot of research, but I have seen a lot of fellow iOS devs wishing something like this existed for OS X, as the only other alternative runs under Windows.

Even if it isn’t, I was getting sick and tired of my really awful bitmap font creation tool that used FTGL, SDL and duct tape and generally produced hideous bitmaps without a lot of fudging of numbers. This is much, much better than that.

Anyway, GameFontMaker is currently in “beta” so don’t come crying to me if your computer explodes or anything. Though in my defense it hasn’t caused my MacBook to explode, and it was way less stable when I started it about 12 hours ago!

This is also my first Cocoa app, so forgive me if it’s a bit rough around the edges.

That being said, if you do find a bug or have a suggestion you could always drop me an email at: colin[at]celsiusgs[dot]com.

So, you’re itching to create some decent bitmap fonts for your game? Well, GameFontMaker is pretty easy to use. From the main window:

GameFontMaker Main Window

GameFontMaker Main Window

You can select the font by clicking on the “Fonts” toolbar button, doing so updates the preview. Once you’re satisfied with your selection, click “Export Font” which opens a file dialog. Choose the file name here, it will automatically choose a .png extension. Once you make sure you’re not overwriting an important system file or your taxes or what have you, click “Save”. This will invoke an ancient spell designed to end the world (and generate fonts) and will cause GFM to spit out a PNG file with all the printable ASCII characters in a line, also it will produce <filename>.png.xml which is an XML file that describes all the character dimensions. It has the following format:

<?xml version="1.0"?>
<fontdata>
	<glyph>
		<character> </character>
		<width>7</width>
		<height>25</height>
		<offset>0</offset>
	</glyph>
...
</fontdata>

Right now the output isn’t ideal for using directly as a texture atlas, but hopefully the PNG plus the XML file can be put to some good use. Once I get some more time I will add support for defining the PNG size and altering the XML output.

Anyway, GameFontMaker is free to use for all sorts of purposes, however if you do find it useful you could always have a look at my games or maybe follow me on The Twitters. Enjoy!

Chromodyne… HD!

Well, the iPad is out and Chromodyne was successfully ported after a marathon session of epic proportions. Amusingly, Chromodyne HD was submitted after Chromodyne v1.1 and was approved before. Some may say I amuse easily, but I was amused.

The Port

Thanks to some experience writing game engines for other platforms before, about 90-95% of Chromodyne’s graphics code was already resolution independent. After updating my XCode to the 3.2 Gold Master, I clicked the handy little “Convert this project to iPad” menu option and was playing Chromodyne in the simulator in mere minutes! Though everything else was really horrible looking because none of the 2D assets were scaled properly and some of the menus looked like crap on the huge screen.

So really, most of my time was spent creating high-res 2D graphics (even though the cutscenes are pixel art, for the most part, those are seriously high-def pixels!) and fiddling with the perspective/view on the gamefield because it was way too freaking big keeping the same perspective as the iPhone version.

I don’t know about the final build yet, but the simulator in the GM release of the SDK didn’t have 3D acceleration! I can understand why some devs were reluctant to release their apps sight-unseen to the App Store.

The iPad Only Version

If anyone actually wonders why I went with a stand-alone iPad version of Chromodyne, the biggest motivator is that the app bundle for the HD version with its 1024×768 graphics assets is larger than the 20 MB OTA limit. Basically I still want people to be able to get the iPhone version over 3G.

The Price

I’m also selling Chromodyne HD for $1.99 instead of 99 cents. I figure the larger, higher resolution game experience warrants a slightly higher price point. We’ll see how that plays out in the days to come anyway… at least I can have a sale at some point without going directly to free. Definitely something I regret when I priced Chromodyne originally.

The Numbers

I’m half-tempted to post sales numbers for Chromodyne HD as time wears on. If anything to see how things are going. I’ve seen that the game lists for the iPad don’t have any top lists for subcategories yet, which is pretty bad news for small devs such as myself. Sales for Chromodyne have not been anything to write home about, but they’ve been steady at least.

Anyway it’s been a fairly exciting few days, and at least I can say I was here from the start. Whatever that actually means, only time will tell.