However, I thought I would try to maybe post a few more things now and again, just to keep my writing chops a bit less rusty.

I have spent the last three months porting the Gamebook Adventures engine to Android via Unity3D. Once that is all done and on the various Android app stores I will have more to say on the journey from iOS to Android, and will probably do a few blogs posts about how I got the engine to work well in just about any resolution.

But for now, I just wanted to say that the latest book is out: Infinite Universe. It is a pretty fantastic scifi romp and is our longest and most replay-able book yet. It is also free for the first 300 sections. (which is half as long as our first book, An Assassin in Orlandes, which is still one of the best gamebooks around and eminently replay-able.)

Since it is free, everyone who reads this blog should go and download it! It is a great book and if you like RPGs or tabletop gaming, you will really enjoy the gamebooks. Even if you never plan to read it, the downloads help our ranking and it is free, so why not? :-)

Thanks again!
-B

People were sitting on the floor and the room was about 35 degrees (that is 35 degrees C, for those of you in the states, that is approximately a million degrees fahrenheit). But all in all it was pretty awesome.

For anyone just tuning in, the talk started out with a quick tour of the unity interface, then I basically dove right into building a game prototype from scratch, trying to get it done in just over an hour. It was a bit of a frenzy of code and components and general Unity awesomeness. Well, I ended up only getting through the creation of a plane that you could fly around and shoot stuff and crash into things and exploding. That is as far as I got :-) I did not make ti to enemy turrets, or procedural city generation. However, as I mentioned earlier, there were so many good questions that I probably covered more actual material than I had originally planned.

(This is the prototype game using the frogames buildings, roads, textures and the plane)

Anyhow. Since the talk was all about prototyping, I was using the totally fantastic and incredably inexpensive protopack from frogames. These guys have a handful of unity compatible content packs that are absolutely worth every cent in terms of time saved and making it so easy to just grab a few prefabs, throw them into a scene attach a few scripts and you have your game idea outlined and ready to tweak.

However, I want to be able to give away the project, but I cannot give away the protopack… sooo I went in and stripped out the proto pack stuff and replaced it with primitives. It doesnt look as nice, but it still does the job, and you can get to the scripts and have a play with all the stuff I talked about today.

(this is the non-awesome looking primitives-only version of the project, which you can download)

So anyway, here is the Freeplay project sans protopack stuff.

SO: here is my advice: go and buy the protopack, it is only like $15 or something stupidly cheap. Then go and build your prototype game.

Let me know if you have questions or whatever!

Cheers!
-B

Thanks to anyone who stopped by the Unity3d booth at GDC and said howdy to Sandor and I and checked out the multi-touch table: the FishTish.

As promised, the updated uniTUIO scripts have been made available on the xtuio.com site!

They have actually been up for quite some time now, but I ahve been (as usual) either too busy or too lazy to get a post up, so here it is:

Note: they have been pretty much fully redesigned to take advantage of the ‘iPhone Input’ style of touch detection.

What does this mean? Well, the older scripts used a more centralized raycasting and distribution method. There was one main event handler that took each touch point and checked to see if it collided with any registered ‘touchable’ objects. This is a perfectly good design, and it works very well when you have lots and lots of points (in other words, you are only raycasting once per touch per frame)

However, we decided to go away from that and create a fake iPhoneInput class that you can access from the desktop version of Unity.

Why?

Well, the most compelling reason was so that we could quickly and easily port iPhone apps to the touch table. Once I had the faux iPhoneInput class that was being populated with TUIO generated touch information, then it was trivial to take a few of the iPhone apps (and most all of the Unity iPhone tutorial projects) and simply drop them in and have them ‘just work’.

In fact, funny story: On the first day of the GDC expo, I had another Unity/iPhone dev come up and he was excited about the FishTish and thought that his app: iPottery would work really well on it. I grabbed the code from him with the intention of dropping in our scripts and installing it as one of the demo apps on the FishTish. Well, that day was quite a long one and I did not have the energy to actually do anything with the script until the next morning. I spent approximates 15 minutes with a totally unfamiliar code base (iPottery scripts are all in JS and the uniTUIO stuff is all in C#, so that also speaks to how simple it is to use them :-) and I had it working no problems. I spent most of my time deleting the onGUI stuff (onGUI doesnt work with uniTUIO, soory!) and adding some guiText/guiTexture based buttons instead.

For the next two days of the expo we showed off iPottery along with all the other demo apps and it worked great!

Ok, enough of my tangent, how does this actually work?

Well, grab the sample project from the link above, there are two scenes, one called ‘basic touch’ and one called ‘buttons’. Buttons actually contains the entirety of ‘basic touch’. (it just has more buttons in it)

Effectively what the new scripts provide is am iPhoneInput class that you can use in your TUIO enabled MT apps just like you would if you were writing an app for your iPhone or iPad. I have provided a dozen or so scripts that show some examples of how to use the iPhoneInput to do things like basic drag/scale/rotate and build buttons using either GUIText/GUITextures or 3d objects.

I havent had time to put together a video yet, but the code is pretty easy. The only thing that you will need is to make sure that you have an active BBiPhoneInputManager script running somewhere in your scene.

I use the BBTouchManagerStarter script to check to see if there is already an input manager and if not then make one. This is good because if you switch scenes, the input manager does not get destroyed. In an actual deployment, you can just instantiate one in your opening scene and be done with i, but during testing when you want to be able to just look at the scene you are in, this can become cumbersome, so I use the BBTouchManagerStarter in all my scenes instead.

Cheers!
-Ben

In any case, I managed to stay up very very late a few nights ago and went through the Molecules codebase and extracted the essence into what we are calling the uniTUIO community edition.

If you have not heard of this before, the basic idea behind uniTUIO is to have a nice set of scripts to allow you to easily implement TUIO based multi touch input into any Unity3d application.

If you dont have Unity3d or dont know what it is, then you really should go to www.unity3d.com and get a copy. It is crossplatform and the basic version is free (and it really isn’t very basic, I built a couple complete games using that version (back when it was called the indie version)).

Anyhow, the home of uniTUIO is at the xTUIO.com website. Ultimately I will be publishing posts like this one up there, but for now, since it is still early days and not that many people know about xTUIO.com I will post this here and have sandor crosspost it there.

Currently the uniTUIO CE is comprised of a unity project which has a couple basic scenes and a couple dozen scripts. Also, I made a couple videos showing how to use the various scenes.

There are two basic methods to get at the TUIO event information.

The first one, which is used by the BBCrosshairController and BB3dCrosshairController scripts, is a simple polling method. These scripts have access to all of the touch information for the entire surface and can act accordingly.

These scripts call up to a singleton script: BBTouchEventManager. It is the touch event manager that actually takes the TUIO information and converts it into a BBEvent object, which basically means that it converts the information from TUIO form into a Unity friendly format.

If you are building a ‘traditional’ sort of unity game where you have a central character that you are controlling, then using this polling method makes sense. This is basically the same thing as using the Input class in unity or the iPhoneInput class in Unity iPhone.

One example of this is the particles scene which uses a script called the BB3dCrosshairController which polls for all available events and spawns a particle system under any touch events. using this method you can replicate all the fun ‘fire from the fingertips’ sort of MT demos in about 3 minutes. (or longer if you are like me and love to just tweak the particle systems for ever and ever to get them ‘just right’. Note: the particle system that I did for the examples is not ‘just right’, i just threw some values at it so that you would have an idea of how to do it yourself)

However, in many multi-touch applications you tend to have dozens and dozens of objects in the scene that all need to be aware of any touch events that are interacting with them. In this case it does not make good design sense to have each and every object grab a copy of all the events and try to figure out if any of them apply to that specific object. Instead we have a central distribution point that checks the incoming events against the scene full of objects and sends out event messages as appropriate.

This is where the BBTouchable scripts come in. The BBTouchEventManager takes the raw TUIO events and raycasts through the scene looking for any objects that are both in a special ‘touchableObjects’ layer and have a BBTouchable script attached to them.

The BBTouchable script provides some overrideable abstract touch input handling methods. For the most part, when doing MT apps that deal with lots and lots of different objects that need touch inputs, you will be subclassing BBTouchable to get your custom functionality.

In the uniTUIO scripts I have made a few example subclasses of BBTouchable. one is called BBBasicTouchManipulation, and it provides any object with the basic single touch to drag/double touch to scale and rotate gestures that are very common in MT apps.

The second one, BBTouchableButton shows how you can make a button that lives in 3d space and reacts to touch events.

You should have everything you need to get started with Unity and TUIO now. If you have questions, dont hesitate to comment here or on the xtuio site, or email me directly, or pm me at the unity forums, or whatever.

Cheers!
-b

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!

Since we announced uniTUIO a few months ago, and entered a uniTUIO-enabled app into the Unite09 contest, there has been a flood of emails coming in asking me if we are releasing the uniTUIO source.

So! Here is the answer:

Yes!

But I have to find a few free hours to rub together to get the code into a useable and clean form. We set out with the goal of having a nice framework of scripts to make using TUIO inputs in UNity3d trivially simple. I think we succeeded.

uniTUIO was built during (and for) the Molecules project (which was really a half-dozen different media presentation applications). As the project deadline began to loom, making the Molecules apps became a bigger priority than preserving the purity and re-usability of the uniTUIO framework. As a result, I had to cut many corners in order to meet the deadline (which pretty much always happens) so the uniTUIO stuff is riddled with Molecules specific code which is neither generically useful, or particularly re-usable in any easy way.

So, I need to go back in and refactor the uniTUIO stuff to make it not suck basically.

However, I will explain to you what the uniTUIO stuff includes, so that you can at least not get your hopes up too much :-)

First off, at the low level, it starts with the c# TUIO/OSC implementation by Martin Kaltenbrunner, which everyone can get ahold of here: http://reactivision.sourceforge.net/.

On top of that is pretty much where uniTUIO starts. It is a collection of about a dozen scripts. There are a few static singleton ‘manager’ style objects that start up the TUIO scripts and listen to the events as they come in. These convert the TUIO data stream into some portable ‘event’ objects that include the local Unity environment information. (in other words they convert from TUIO screen-space to Unity viewport space).

Also there is an event manager that does raycasting into the unity scene and picks out any objects that are in the right layer (a ‘touchable’ layer) and passes the events onto those objects.

There are a few more scripts that are meant to be attached to touchable objects.
One is a high level touch event handler that accepts touch events from the event manager and applies them to it’s gameObject in a generic fashion.
Inherited from that object is a basic touch manipulation script that provides simple gesture support to handle the basics like dragging, rotating and scaling a gameObject.

That is what uniTUIO includes. It is meant to be a simple starting place for you to be able to build on for your own MT projects in unity.

So anyway, we will announce it when we release it (hopefully sometime this month) so keep an eye on the RSS feeds. Cheers!
-B

ps: for those of you who are very impatient, have a look at this thread on the unity forums. User Jorgen posted a simple unity TUIO implementation project, which is a good place to get started.

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

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

One of these days I will figure out how to cross-post to all the various blogs and things I am currently contributing to, but for now I will just throw some links out there:

There is the link above, that goes to the initial blog post.

http://xtuio.com/blog/2009/09/06/more-sneak-peeks/ is a post about the two layout managers that are ‘done’ so far.

http://xtuio.com/blog/2009/09/07/unittuiomolecules-project-now-with-more-movies/ shows the newly added movie support and the content switching buttons.

In any case if you are into the multi-touch surface thing, then go check them out. Otherwise, you can safely ignore them.

Cheers!
-B’

BBNotificationServer.cs.zip

Just attach this script to a Game Object ( I usually have at least one empty object that is just my holder for all the scene manager scripts.) and you can utilize the notification services.

Here is a quick rundown of how it works:

First off, we have a BBNotificationList class at the top of the file.

public class BBNotificationList {

	private ArrayList objectList =  new ArrayList();

	public string notificationMessage = "";

	public void addObserver(GameObject obj)
	{
		if (!objectList.Contains(obj)) objectList.Add(obj);
	}

	public void removeObserver(GameObject obj)
	{
		if (!objectList.Contains(obj)) objectList.Remove(obj);
	}

	public void sendNotice()
	{
		if (notificationMessage == "") return;
		foreach ( GameObject obj in objectList ) {
			obj.SendMessage(notificationMessage,SendMessageOptions.DontRequireReceiver);
		}
	}
}

Just a very simple container object that holds a list of GameObjects and a ‘message’. When the sendNotice() method is called, then each object in the list gets sent the message. Simple.

Next we have the ‘server’ which is roughly analogous to the NSNotificationCenter.

public class BBNotificationServer : MonoBehaviour {

	private static BBNotificationServer sharedInstance = null;
	private ArrayList notifications = new ArrayList();

	// This defines a static instance property that attempts to find the manager object in the scene and
    // returns it to the caller.
    public static BBNotificationServer instance {
        get {
            if (sharedInstance == null) {
                // This is where the magic happens.
                //  FindObjectOfType(...) returns the first AManager object in the scene.
                sharedInstance = FindObjectOfType(typeof (BBNotificationServer)) as BBNotificationServer;
                if (sharedInstance == null)
                    Debug.Log ("Could not locate a BBNotificationServer object. You have to have exactly one BBNotificationServer in the scene.");
            }
            return sharedInstance;
        }
    }

We are using a singleton pattern here, so you will need to have the script attached to something in your scene. Once you have that then you can get a ref to the server from any other script in the scene like so:

BBNotificationServer  theServer = BBNotificationServer.instance;

or just make calls on it directly like so:

BBNotificationServer.instance.postNotification("DoSomethingNotification");

OK, so the first thing we need to do is be able to add and remove ‘observers’. If you are unfamiliar with the notification center from the cocoa API, then an ‘observer’ is simply an object that wants to be notified by a specific notification.

	public void addObserver(GameObject obj, string notificationMessage)
	{
		BBNotificationList theList = this.listForNotification(notificationMessage);
		theList.addObserver(obj);
	}

	public void removeObserver(GameObject obj, string notificationMessage)
	{
		BBNotificationList theList = this.listForNotification(notificationMessage);
		theList.removeObserver(obj);
	}

Again, fairly simple, we have a private method that returns the list for a specific message (and makes a new one if there is not already one) and then we just call the add/remove methods on that list.

Here is that private method:

	private BBNotificationList listForNotification(string message) {
		foreach (BBNotificationList list in notifications) {
			if (list.notificationMessage == message) return list;
		}
		// we got here so there was no list, so make a new one
		BBNotificationList newList = new BBNotificationList();
		newList.notificationMessage = message;
		notifications.Add(newList);
		return newList;
	}

Right now I just implemented it as an arraylist and we just do a linear search through it. Not super duper fast, but if you only have a handful of notification messages, then it will be plenty fast. If you feel the need for more speed, then just replace this method with something that uses a hashtable and you are all set.

finally, we need to be able to post messages. We already had a look at the actual message posting code in the NotificationList object, and the post notification in the server object is pretty damn simple:

	public void postNotification(string notificationMessage)
	{
		BBNotificationList theList = this.listForNotification(notificationMessage);
		theList.sendNotice();
	}

yep, that is it.

So how do we use this? If we have a gameobject that we want to react in some way to a notification then we simply have to register as an observer and implement the method that we are observing.

	void Start() {
		BBNotificationServer.instance.addObserver(gameObject,"FooAllWidgets");
	}

	public void FooAllWidgets()
	{
		this.widget.foo();
	}

And that is it. Very simple!

Note: right after I finished this, I decided to check the one place I forgot to check in my earlier searches, and lo and behold, the Unity community has in fact beaten me to the punch (as usual :-) You can find a javascript implementation of a nice notification center at the Unify Community Wiki. It is a bit different than my implementation, it offers a bit more functionailty, and some extra data handling. Stuff that could be added to this one fairly easily if you needed a c# version.

Cheers!
-B