Software should be simple.
Tin Man and I just finished making the teaser trailer for the upcoming Gamebook Adventure release: An Assassin in Orlandes. It is pretty cool, check it out:
Assassin in Orlandes is nearly finished, we are planning for an early January submission to the App Store, so look for it in mid to late January!
Cheers!
-B
(Note: this is cross posted from Escape Factory)
Chris and I just got back from the Global Connect Asia Pacific game dev conference here in Melbourne. We entered Mole into the GDAA Independent Games Awards 2009 and got selected as one of the finalists.
As a GDAA finalist we were invited to put up a table and show off our game at the conference. Chris whipped up a few posters and I grabbed a couple of the stray laptops that I have laying around and we hit the expo.
GCAP is not a gamer expo, it is a game developer expo, so all the people there are somehow involved in the creation of games. Over the two day expo, we spoke to a zillion talented and creative people and they all played Mole, and let us know what they think.
The response was overwhelmingly positive. We had people coming back two and three times to just sit and play Mole during the downtimes. We had people who just sat down to have a quick look end up staying for 30 minutes trying to dig deeper and deeper.
Best of all however was the ability to watch people play the game. We spent a huge amount of time before the conference making sure that the core game play was solid and that the game was fun, and we were richly rewarded for that effort. However, watching people play the game highlighted the areas of the user interface that were lacking. It made apparent the places where we need to change the words on the menus or add new buttons. For instance, when you go to the upgrade shop from the end-of-dig scorecard, it is not at all obvious how to get back. Similarly, when people play it for the very first time, they run out of air and get back to the surface and don't realize that they need to hit the 'finish digging' button to end the dig so they can start a new one. We even found a few gameplay bugs that we will iron out.
We are currently going through and tweaking all these little bits and pieces to try to hone the user experience before we release it to the app store. But we want people to play the game so I have put up the GCAP version online so that anyone can play it for free.
If you are into it: head over to the Mole page and hit the 'play now' link. You will need the Unity3d player, and you can get it from the game page.
We are planning on keeping the online version free to use, and we will be updating it alongside the iPhone version, so if you come back and notice some new tweaks here and there, that is why.
We love to hear what you have to say about the game, so send me an email, or leave a comment here!
Just recently, like, very recently (maybe a few hours ago) Unity released their base-level product, Unity Indie for free.
This is pretty huge news for the game development community. It is, as they say (and forgive the pun) a Game Changer.
If you don't already know, Unity is a very powerful tool for rapidly building games. (it is billed as a 3d game engine, but it also works quite well for 2d games) One of the many features of Unity is the ability to take the game project you have built, and with the click of the mouse, build a version for the mac, a version for the pc and a version that runs in a web browser. This is excellent for distributing your game but it has other side benefits as well. I collaborate with people all over the world, and we use the in browser games to share our ideas quickly and easily, not to mention it is much easier to get your testers to test out your prototypes if all they have to do is open a browser window.
Before now, the indie version was not very expensive, less than $200 or so, but now that it is free, I think we will see a flood of new and interesting games come out in the coming months.
What does this mean for indie game development?
Well, the obvious thing is that we will see a ton more web based titles, probably lots of crap, but there will always be a few gems in there.
I think that Flash development will start to see a big challenge from the Unity guys. I know a ton of flash guys who have been eyeing unity for awhile now and this will most likely push them over the edge. dont get me wrong, flash is a great tool, and it is great for making games, but it is not a game-building-tool. Unity is designed from the ground up to make games. Here is a good post to read if you a flash dev who is on the fence: http://diamondtearz.org/2009/01/14/10-reasons-for-flash-developers-to-learn-unity-3d/
The even bigger news for me as an iPhone developer is that I think many many more people will start to use unity to build games for the iPhone.
Now, Unity iPhone Basic (the cheapest iPhone license) is still about $400. And some of the zero budget indie developers might have to think twice about that kind of money (it is totally worth it, trust me) But now you can download the Unity Free and prototype your game, or release a web version or just get to know unity and then be ready to port it over to the iPhone version. We are doing that right now with 'Mole' and I will be blogging about what it takes to move a prototype level game from the desktop version of unity into a working iPhone version.
I will also be interested to see how this effects the other iPhone game-focused APIs like cocoas2d. Cocoas2d and the like are still free (so still $400 cheaper than using unity to develop your game) and if you are building a 2d game it makes a lot of sense to start with cocoas2d, but I can tell you from my personal experience that building a 2d game with unity is very easy and if your time is worth anything to you then the $400 investment to upgrade to iPhone Basic is well worth the money. Also, I cant stress this enough, you can now prototype your game in Unity for free. Even if you then decide to use cocoas2d to build the deployment version (a few reasons you might want to do this, more on that in a second) you can still do a rapid prototype with Unity to figure out all your gameplay mechanics and decide if the game is fun or not.
So, Unity is great, but what are the downsides?
Well, in terms of desktop or web development, there aren't any real downsides. Go get a copy and start making games.
In terms of iPhone development there are a few caveats.
First off, as i have mentioned, it is not free. But $400 is very cheap for what you get.
The biggest issue with using Unity Basic (and to some extent this applies to the pro version as well) to develop iPhone games is that your app size will not be under 10M (which is the size limit for apps to be able to be downloaded over the cell network). For the most part this is not a big deal, most games with any amount of depth tend to be bigger than 10M no matter the development tools used.
However, the casual games that you are trying to sell for $0.99 and you want to be an impulse buy, and so you want them to be less than 10M, these are nigh impossible to make with Unity. Why is that? Well, the unity engine is very capable, comes with all sorts of great things like built in physics, scripting, shaders, and lots of other goodies, but all that comes at the cost of size. If you spring for iPhone Advanced then you can strip out parts of the engine you are not using, and possibly get under the 10M mark, but this is a very hard thing to do.
My advice: even if you are looking to build small casual games for the iPhone, I would still suggest you get the now free Unity and prototype with it. Then once your game is working fall back on one of the other frameworks like cocoas2d to build it. However, if you have even an inkling that your game will exceed the 10M limit, then just get the iPhone version.
Cheers!
-B
I just wrote a big post about how to open up a UIWebView overtop of the unity game engine. This is a good way to add Playhaven integration to your app, as we are doing with Snowferno. Anyway, I posted it on the Snowferno development blog:
http://www.snowferno.com/2009/09/23/playhaven-unity-and-snowferno/
Check it out if that sounds like something you might want to do.
Cheers!
-B
OK, So, I just got an email from Ken, a dude who surfed across this OpenAL stuff on my blog, had some troubles, and asked me for help. He is having trouble unloading buffers and then re-using them again without getting some esoteric OpenAL errors.
So I went through the snippets he sent me very quickly and threw out some advice. Ken came back with a few more questions and I went over the code again and noticed this:
// use the static buffer data API
alBufferDataStaticProc(buffer, format, data, size, freq);
Ah-HA! I said, that is probably your problem right there! alBufferDataStatic should be avoided unless you need it. When do you know if you will need it? Here is a rule of thumb: If you dont know the answer to that question then you dont need it.
(I don't want to seem to be picking on Ken, this problem is so common that I decided I needed to do a post about it (similar to my rant about never using the sample code from Apple in a shipping app))
OK, so why do I think you should avoid it? I am sure you have heard that if you want the best performance then you should be using alBufferDataStatic() right?! No.
Well, what is alBufferDataStatic() anyway? alBufferDataStatic puts the onus of memory management for all your buffer data onto your code.
Let me repeat that: When using alBufferDataStatic() YOU are responsible for all the memory management.
That is it. That is your big performance boost.
Wait! Really? that is all it does?
Yes.
The iPhone's shared memory space and the way it handles memory and the way your app gets jettisoned if you use too much is a very unique situation. A situation that requires that you often have to really closely handle your memory. So! That means that if you are trying to squeeze every single last byte of memory out of the iPhone so that your fully immersive 3d first-person-shooter can keep a consistent 30FPS then you will probably want to spend a few weeks tweaking your sound code so that you have very close control of your memory at all times.
For the other %99.9999 percent of apps that might want to use OpenAL (even if you are using lots of sounds) you are just adding extra headaches to your code by using alBufferDataStatic(). Here is another rule of thumb: If you are not employing a developer whose sole job is to handle the sound code in your app, then you don't need alBufferDataStatic().
Have a quick read of the technote that mentions alBufferDataStatic().
What does this really mean?
It means this: when you use alBufferData() you load your sound data into a local buffer (one that you have to malloc) then when you call alBufferData(), OpenAL copies all those bytes into it's own buffer that it deals with. Then you free your local storage and OpenAL now owns that buffer. The downside: for a brief moment, you have 2 copies of your sound in memory. The upside: very very easy memory management.
If you are getting jettisoned right here, during this buffer copy, then you may need alBufferDataStatic(). But more likely you have done a crap job of handling your memory elsewhere. (also it is good to note that if you are loading big sounds into memory you are doing it wrong anyway, those big sounds should be streamed).
Ok, you are absolutely, positively sure that you need to manage your own sound memory? Maybe you should be using alBufferDataStatic(), but first: here is yet another rule of thumb: if you are reading this blog post to see if you need to use it; you don't. go to your code right now and take it out. Just take it out.
Obviously I am being a bit hyperbolic in an attempt to make a point. I dont know about your code, but here is a small list of the most common bugs I find in my code:
The list goes on. But can you see a common thread? Memory. Why would I want to add yet more memory management responsibilities when I dont need it? Why do developers always insist on making their own lives so much more difficult than they have to?
Here are a few platitudes:
So, by using alBufferDataStatic() you are breaking all three of my lovely platitudes.
Dont do it.
You are only causing yourself grief and making your code buggy and shitty. Use alBufferData(). It works. It is easy. The highly experienced engineers who work on OpenAL have made sure that there are no memory issues with alBufferData(). If you decide to port your code, alBufferData() will still work! alBufferData() makes your breath smell minty! alBufferData() will totally pull chicks.
I have put OpenAL code into about 6 apps now. A few games and a few utilities. And one 'sound board' style app that played 32 sounds simultaneously (which was the max at the time, probably still is) and was able to handle gigantic sounds files (via streaming) without ever using alBufferDataStatic(). Was this some herculean task of super-awesome mad coding skillzzzz?
No. Just the opposite actually. I keep all my code as absolutely bare-minimum simple as I can.
Keep your code simple, don't use stuff you don't need.
Cheers!
-B
My full name is Ben Britten Smith.
I go by Ben Britten because Ben Smith is a bit too common and using my full name is a mouthful.
I live in Melbourne, Australia and service clients all over the globe.
© 2010 benbritten.com 