Archive for category Unity Game Development

Refactoring Part 1

I’ve started writing about this because it’s better than talking to myself and that’s how I work out problems in code.

For a little background, I started coding on RisingStorm,which is a remake of an old game from the 90’s called Netstorm,  back in late June (I actually started looking at it earlier, but then I had to travel to France for work, and who can work when you’re sitting in Paris?!  I mean come on!)  Since then it’s been coming together nicely:

Here’s a video someone put together play testing (he even used a cheat to give himself extra money): Rising Storm play test build The music is from Netstorm not from RisingStorm.

It’s funny, that was build 9.  Of course, that was build 9 after I started performing a build release cycle.  Before I would just make a few changes and upload them.  Occasionally I still do, but there are advantages to doing a cycle… if your testers pay attention to build numbers when submitting bug reports anyway :)  Perhaps I’ll talk more about that some other time.

This post is going to be about refactoring.  I just uploaded build 20 which contains some basic multiplayer and uses levels constructed in the in-game level editor I put in around build 17, I think.   Now I’m taking a moment (more like a day or two) to think through the code and do some reoganization.

There have been some elements I’ve been thinking about fixing, but not necessarily doing so.  The thing that’s been working really well for me and especially in a diverse, internet-only group is rapid deployment. When everyone can see and comment very early on it keeps progress smooth. This is a sort of agile formalism, but treating agile formally always strikes me as silly.  The idea is that you get something that works, but probably isn’t quite the solution you want, but it’s better to push it through and come back to it later when there’s a driver.  Despite what people think, coding very often isn’t engineering.  It’s more like crafting, like chipping away at a raw element (an idea) and shaping it.

I once heard that when Michelangelo was crafting his David out of a single block of marble, he did so by chipping away at the block.  He said the block gave him his sculpture that he was just pulling it out (sorry wikipedians, no reference, this is just hearsay).  And in the course of chipping away at the block he discovered a fault in the stone around where David’s hip was.  In order to work around the fault, Michelangelo gave David that bend he has in the upper body which starts at the hip.  In the same way, coding a raw formed idea can’t be forced, it has to be moulded.  Coding new ideas requires crafting them.  You can’t put the Requirements or Specification before the horse.  Horses eat hay. (RisingStorm is a remake, but making an RTS like Netstorm is new to me, so the ideas are new to me… otherwise it wouldn’t be nearly as interesting for me to do in my spare time :)

One of the first, simpler, cases of refactoring I did was in how the build system works.  In Netstorm and Risingstorm, there is a build panel where you can select either units or bridges to place.  These operate very differently after they’ve been placed, but placing them isn’t all that different with one exception.  After a bridge is placed it just appears there, but when a unit is placed this little sparkly thing needs to pathfind over to it and teleport it in.  Well, originally I started with the bridges (they are the most important element in the game) and just got something working with a simple function call.  But when I added in this little sparkly thing I decided to make use of Unity’s message passing interface first to notify on various states, like “OnDraggablePlaced” or “OnConstructionStarted” (draggable is the name of some element which can be placed from the build panel)  There’s also a message that gets sent by the sparkly thing when it arrives and a publish-subscribe mechanism that lets it send to only the objects that care about it arriving.  I’ll probably open source this sometime soon.  Look for the “RTS Source Code Components” at the top here.

One major refactoring I started recently was with the level editor.  I decided to try to reuse the code for the build panel and draggable stuff to allow the user to place objects in a level design similarly to how they would in game.

I discovered along the way that there were very many assumptions I had made about building that weren’t very abstracted.  They worked for in-game building, but there was quite a bit of spaghetti calling back and forth between objects.  Draggables talking back to the build panel in a way that seems to violate controller continuity.  I’m not sure that’s a thing, but it’s related to a real thing :)  I just can’t remember the real name.  The idea is that say when you construct something in a piece of code, that code should also be responsible for removing it.  It’s of course possible to code where you destroy an object into any place and why not?  It turns out if you decide to change something later trying to track down all the weird places you could have possible called that destruction can be a real pain.  Having the Draggables call back to the build panel isn’t necessarily wrong, but right now it’s just ugly.

Every great performer does something which is incredibly difficult, but it looks really easy when they do it.  I think the same should go for code.  It should be very simple to follow the logic.  It should even look so easy someone can look at it and go “Oh I could totally have done that in a weekend.” and yet the crafter behind it went through a painstaking thought process to carefully lay out the code and refactor the code so that it would lay so beautifully well.  Everyone can appreciate David, but not everyone can make a statue of similar caliber.  In the same way, everyone can code, it’s not really that hard.  But not everyone can make really good code.

It’s amazing how much refactoring like this can beautify your code.  It’s like proofreading text.  By the time I’m publishing this, I’ll have read through it a few different times.  When I’m writing through the first time there’s no way I can clearly see what I’ve written after this line until I write it.  I have an idea where I want it to go, but the actual word structure change and veer from my intention.  In fiction writing this is how you create those really great repeating themes or strong foreshadowing.  You may have had an idea on the first pass of how the story would go, but as you were writing it, it shifted slightly or formed in a way you didn’t really expect.  When you go back through the moon needed to be  full for the hero to look into the heroins eyes.  But it turns out that he’s a werewolf.  You can slip a little piece of text about the state of  moon earlier on and then it looks like you’re a really great planner.  “It looks so easy, I could totally write that book in a weekend.”

Enough of the diversions, I wanted to work on the actual problem.  But this post is getting long, so I’m going to think about the writing and save the problem solving for the next post.

Btw, have you ever noticed how the foreshadowing just isn’t as good in a serial like a tv series.  You get vague prophecies, but nothing perfectly clear (except maybe Joss Whedon.  I just don’t know how he does it, except that he doesn’t because nobody lets him finish it… sigh).  Nobody can predict the future, even though they may want to, so the TV series shifts from those original intentions and it may be hard to pull it back in line with consistency to the first season.  Oh, Lost with your islands and hatches, I miss your potential.

No Comments

Blender’s Phantom Meshes

While working on an collaborative AI project, I came across a very interesting issue with some Blender models.

Since AI was the focus, we decided not to worry much about the graphics, and imported some models off of a Blender community site. We found a house that didn’t have too many polygons which looked pretty good. Upon importing this asset and placing a few instances around the scene, we found that the graphics performance decreased dramatically.

At first, we thought it was just because the house had too many pieces, so we used the Combine Children script to try to bring them all into one mesh. This helped a little, but the draw calls were still way too high.

After further investigation, we discovered that there was some funky bit of disconnected triangles floating around each house. Each of these triangles had something like 30 individual materials attached to it. That was the root of our problem. The only question was, where did this come from?

It turned out that the .blend file had some extra objects in it that the artist had used to store materials that he/she may have wanted to reuse later. Well, this object didn’t show up in the 3D window, so it wasn’t apparent to the casual Blender user that it even existed. However, Unity imported it as if it were any other object, which caused the problem.

What’s the solution? Well, if you don’t care about maintaining connections with your mesh objects, just delete the offending mesh object from the scene hierarchy or prefab and all is well. If you do care, there’s an easy workaround.

Finding the Outliner

The last item in the View menu lets you switch modes

Open the file in Blender, and open the “Outliner” window. In here, there are two nice views. One is an object-oriented look at all your objects and their connections, this is called the Oops Schematic. The other, shows a list of everything in the scene, simply called the “Outliner“. The latter is the one you want.

If you are not in the Outliner, click on the View menu and choose “Show Outliner”. Now you should see every object in the file, even those that aren’t visible in the 3D window. All you have to do is click on the offending object and delete it. If your artist sends you a new copy of the file, just repeat the process.

No Comments

Another Game and Facebook Woes (er… Tutorial)

Guillotine Image

Who Cut the Deck - A Facebook card game.

First, I’ll cut to the chase and announce the alpha release of a card game I’ve been working on called Who Cut The Deck.

The idea for the game  was born of a necessity.  A friend of mine is leaving town, but we regularly get together to play cards or board games.  We considered the idea of using some kind of Skype arrangement to handle the games, but a basic problem exists for any game which uses cards… we can’t network the arrangement of shuffling.  So, I decided to make a network card shuffler.

It’s expanded, as these things do.  And the goal for me has now become to as closely match as possible the feel of being in the same room sitting around a table playing these games.  Thus it’s in 3d, it has physics simulation, and hopefully at some point I can get sound and video achieve the verisimilitude.

Finally, I’ll admit the point wasn’t to use a standard deck, but some of the more interesting card and board games that are out there.  Of course, these won’t be released as I’m keeping them for our personal use, but I may approach the copyright owners at some point and see if something can be arranged.  Until then, I hope people outside our group of friends will enjoy playing any game possible with a normal deck of cards.  There are, after all, quite a few of them.

Now, to maintain some of the technical quality of this site, I’ll talk about some of the trials and tribulations of integrating Facebook and Unity.  It’s not as bad as trying to network from scratch (the worst possible programming hell you’ll ever face, thank you Unity/Raknet for taking that out of my hands), but it’s not as easy as you might expect from some of the tutorials around the web.

One thing is that Facebook has very recently changed the API.  You can still use existing methods, but they are probably going to be deprecated.  I continue to use them (specifically the original PHP api) myself, because I just wanted to get it working, but it’s good to know where things break down.

I won’t list them here because it’s easy enough to search the web for “Unity3d Facebook Tutorial”, but a good one I used to setup is here.  As of this writing, it is not yet complete.  I’ll expand on it a little bit here.

The last entry ends with a query to the image FQL.  This is a nice start, but one of the most important things you’ll run into is that using PHP you’ll need to do a large portion of your queries on the front end.  This is because PHP processes on the server, but Unity runs on the client.  Now, you can also setup some PHP helpers callable from Unity using it’s WWW class, but none of these can use authorization directly.  I believe it is possible to establish the authorization with Unity in the initial load and pass this into unity to forward back to these helper queries, but I haven’t made that work yet.

In the meantime, you can only get basic information available without access to the login (in my case I query name and profile image).  The following code is how I pull out the name and image you see when you first load up the game.

$user_id = $_REQUEST["id"];
require_once 'facebook-platform/php/facebook.php';
$apikey = XXXXXX;
$secret = YYYYYY;
$facebook = new Facebook ($apikey, $secret);
$info = $facebook->api_client->users_getInfo ($user_id, array ('first_name'));
$query = "SELECT pic_big FROM profile WHERE id = $user_id;";
$result = $facebook->api_client->fql_query($query);
print $info[0]['first_name'].",".$result[0]["pic_big"];

The Unity code that accesses this is:

var url = correctURL+"getFBProfile.php?id="+userId;
var www = new WWW (url);
yield www;
var data =","[0]);
playerName = data[0];
if (imageCache.Contains(userId)) {
  playerImage = imageCache[userId];
} else {
  www  = new WWW (data[1]);
  yield www;
  playerImage = www.texture;
  imageCache.Add (userId, playerImage);

Finally, the note I need to explain is how to get the userId into Unity. Following the tutorial above, you’ll see how to get to that point. To get it into Unity is not nearly as trivial as I expected it would be. First you don’t know when unity is loaded from the webpage so you can’t call it immediately, instead you need some javascript function in the webpage that calls back into unity. I have:

<script type="text/javascript">
function initializeUnity () {
  GetUnity().SendMessage("Main Menu", "SetGameType", "Facebook");
  GetUnity().SendMessage("Main Menu", "SetUserId", <? print "\"$user_id\"" ?>);
  GetUnity().SendMessage("Main Menu", "SetFriends", <? print "\"$friends\"" ?>);
  GetUnity().SendMessage("Main Menu", "InitializationComplete", "");

That final InitializationComplete is the most important missing piece from documentation I could find.  It sets a variable “loaded” to true inside Unity so that I can do the following before doing anything else using userId.

Application.ExternalCall ("initializeUnity", "");
while (!loaded)
  yield WaitForSeconds(0.1);

This is because those calls in the webpage are Message and those will be passed asynchronously (for all intents and purposes) to your javascript. So you need to wait until they all come through before assuming they have completed.

However, by this point in your application you’ll have everything you need (and if you ever pass through authorization keys that’ll also work beyond this point…) to proceed as expected.  Good luck.

One of these days I’ll talk about latency issues with Unity’s master server from the states.  And why it’s probably much better to keep it somewhere close to your users :)

In the meantime, let me know if you try Who Cut the Deck and feel free to offer suggestions or bugs in the comments.