Tag Archives: Development

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

How to Finish a Game

I posted a tweet yesterday which offered some advice concerning finishing games:

How to finish a game: get part way through a project, get an awesome idea for another game, ignore it and finish the one you’re working on.

It ended up getting retweeted quite a few times, so I guess it kind of struck a chord with people. With that in mind I got to thinking about other barriers to completing games I’ve encountered over the years and figured it would make a good blog post.

Having tried to start this whole game development thing once before in the late 90′s, I’ve done quite a few things that have derailed me from actually completing a game. When I started again in 2009, I knew I had to avoid all of these pitfalls in order to actually get a game out the door, so that was my biggest priority, actually finishing a game. I’ve finished 2 games since then, and I’m on my way to completing my 3rd, so hopefully this advice may prove useful to you as well.

Continue reading

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.

Chromodyne: A Successful Failure

I’ve been thinking for a while about writing up a postmortem of my first crack at making a Real Game, Chromodyne, for a while now. The worry is, of course, that someone may look at this as some sort of horrific waste of time and tell me I’m mad for trying to break into the App Store when… oh my god it has how many apps? However in all honesty, despite the less than stellar sales leading to what one might declare a failure on the App Store, for a number of other reasons, I feel Chromodyne has been incredibly successful and I wouldn’t have it any other way (well, except maybe the whole not selling well part).

What the hell are you talking about?

What I mean when I say “successful” I mean that on the whole, even considering the time I spent working on it only to have it sell a few hundred copies so far, I still learned a lot of valuable lessons, met a lot of awesome other developers, and it helped prove to me that I had what it takes to develop an entire video game from start to finish and to kick myself in the ass and finally decide that I should follow my dream of becoming a game developer.

What went wrong?

There were a few key things that I feel went wrong that, hindsight being 20/20, I would have done differently. Here they are in no particular order:

  • Not enough exposure – I didn’t enter into this whole App Store dealio completely blind to the fact that in order to become successful people need to know about your app. I definitely made a decent stab at it, but my relative newness to the whole scene plus working a full-time job at the time hampered my ability to really get the word out.
  • Poor branding - I fretted a long while over trying to give the game a neat and catchy title, as you should try to do, however I really didn’t think this whole “Chromodyne” thing through. After trying to explain the game to others in person, it’s definitely a clumsy name when spoken and makes it difficult for that whole “word of mouth” thing to work when people don’t know how to spell it to look it up online. Also, in retrospect, the icon could probably have used a bit more work to make it pop more on device and on the app store.
  • Fiddly controls – One problem you can not ignore in game design is how your players interact with the game. If the player is constantly fighting with the controls they will never truly get to enjoy the game and you run the risk of them abandoning it for something else. In the case of Chromodyne, I was well aware of the issues with the controls and tried to minimize their impact as much as possible, but by the very nature of the game field layout it meant that the inner-most rings were difficult to touch accurately. As well, I felt that with practice people would become better at the game and that’s what many of the reviews revealed. However, as the cliche goes, the first impression is the best impression.
  • Choosing an over-represented genre – Approximately 105% (or so) of the games on the App Store are match-3 games. Even though one cynical critic (the only bad web review I received, I might add) accused me of trying to jump on the App Store Gold Rush Bandwagon(tm) the reason I decided to try my hand at a match-3 game for my first game was because I felt it would be much easier for me to complete a game with a smaller scope in a reasonable amount of time. Speaking from experience, I have a tendency to come up with grand designs which would take a large team a couple of years to complete, so I had to learn to work within my own ability to actually make something.

What went right?

  • Learned a lot about game development – If anything I took away from this whole experience, it was a lot of experience about the game development process, including learning things about the iOS platform, the App Store, and various new programming techniques that helped make it a lot easier when I started work on my second game, Red Nova.
  • Made something I’m proud of - Despite all I’ve said about Chromodyne so far, it’s my creation and I’m really happy that I made it. It may not be perfect, but it has gotten some good reviews and on balance it may not be the best game in the world but it’s still pretty darn good. As well, I think the thing I’m most proud of are the story and characters I created for the game and maybe some day in the future Gary and Zarlax will ride again :)
  • I’m following my dream – As I’ve mentioned in an earlier post, I’ve struggled over the years trying to figure out what direction I was going to take in my life. Games and game development have definitely been a passion of mine, and it’s something that I’ve always wanted to do professionally, but ultimately I had to make Chromodyne first to prove to myself that I had the ability. So Chromodyne was the catalyst of this at times scary but entirely exciting new path I’ve taken in my life. Also, it helped to show the people at the Genesis Centre, the startup incubator I’ve been accepted into, that I have what it takes to, as they say, do this thang.
  • Met a lot of amazing people – Through all of this I’ve met and connected with some really great people in the game development community on the internet at large and it’s really helping me feel like I’m a part of the industry now, however small my part is at the moment.

What’s next?

After six months in development, I’m on the verge of submitting my new game Red Nova to the App Store, and from all I’ve learned and all I’ve worked towards I’m confident it will be more successful than Chromodyne. How successful, I have no idea, but hopefully enough that it will allow me to keep working on adding updates to Red Nova and to start making other even more complicated games in the future. That being said, I’m currently working on getting into a position where I’ll be able to hire a 3D artist early in the new year. In addition to taking Celsius Game Studios from “one guy hacking on games in his living room” status into “if you squint hard enough, it looks like a real company” territory, it’ll help me focus solely on game design and development and allow for the creation of a larger variety of and even better looking art assets than I can eke out with my meagre art ability.

Finally, in celebration of Chromodyne being on the App Store for a little over a year (since October!) I am going to, tongue firmly in cheek, declare Chromodyne and Chromodyne HD Celsius Game Studios Not-Quite-Greatest-Hits and drop the price permanently to $0.99. You can learn more about them at the game’s page.

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;
	}
}

Red Nova Beta Testing

Edit: Just wanted to say thank you for such an amazing response and beta testing is now nearing completion! Thanks for your interest, and hopefully Red Nova will be out soon!

I have a few more device slots that I’m able to set aside for beta testing of Red Nova, so I’m wondering if there’s anyone else out there who wants to help me make the game as awesome as I possibly can.

I can’t offer much in compensation right now except for a “Beta Tester” credit in the credits for the game and the satisfaction that you’ll gain in knowing you helped me make sure Red Nova doesn’t cause people’s iPhones to explode violently when adjusting the in-game volume (I promise I’ll try really hard not to explode your iPhone, violently or otherwise, during the beta). Also, you get to be among the first people ever to play Red Nova which I think, despite my obvious bias, is pretty damn cool.

Anyway, that being said what I’m looking for is both feedback on the game itself as well as help in finding any bugs in the code.

If you’re interested you can email me at colin[at]celsiusgs.com (after replacing the [at] with the appropriate symbol :)) or @reply me on Twitter with whatever devices you have and when I’m done compiling the list of potential beta testers I’ll get back to you if I’m able to add you to the beta or not!

As for the beta itself, I’m planning on making a pre-beta build available sometime this week for those that are interested in trying out the gameplay. I’m still in the polishing stage, so there are some rough edges and things that are just plain missing. I’m pretty excited though and I really want to share the game with others to see if they feel the same way.

The plan after that is to seed the first full beta in a week or two, once everyone has had a chance to play around with the pre-beta build and I’ve had a chance to take a grinding wheel to the rest of the code ;)

Retina Display, Open GL, and You!

Over the long weekend, I took some time to code support for the iPad and iPhone 4′s Retina Display into Red Nova. It was a fairly painless process, after Paul Pridham pointed me in the right direction.

If you are using OpenGL for your app on the iPhone and are using an Orthographic projection for your 2D bits, you shouldn’t have to change much of your code to get it “Retina Ready”.

Setting the View Scale Factor

First, your Open GL View class if you add the following in your init code it will tell the OS that you want to display your graphics at 960×640:

if([[UIScreen mainScreen] respondsToSelector: NSSelectorFromString(@"scale")])
{
	if([self respondsToSelector: NSSelectorFromString(@"contentScaleFactor")])
	{
		self.contentScaleFactor = [[UIScreen mainScreen] scale];
	}
}

If you run your app at this point you should see the content running in the corner of the screen because your GL viewport is still running at 480×320. So that brings us to…

Setting up the Open GL Viewport

Note: If you haven’t already you may want to make a wrapper function that returns the current device scale factor. I did and it’s very useful in code that needs to properly deal with displaying your graphics at the right size.

Anyway, this is the next and pretty much final step.

Find your call to glViewport, and modify it thusly:

glViewport(0,0,usefulGetScreenWidthHelper()*usefulGetScreenScaleHelper(),
	usefulGetScreenHeightHelper()*usefulGetScreenScaleHelper());

Obviously change the width and the height to correspond to your app’s layout.

If the rest of your code sets up your projections (2D and 3D) based on 480×320, when you compile and run your app you should get glorious retina display goodness! You will of course have to adjust your 2D bitmapped assets (fonts and images) to reflect the higher resolution of the display, but the end result is that your app thinks in 480×320 (this is how Apple manages it with Cocoa Touch, as far as I can tell, amusingly enough) but displays at 960×640!

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.