We will have more information about this game and continued development soon!

There are a large number of bridge units built in a game of RisingStorm

RisingStorm has an additional challenge: one of the principle “units” a player will place is a bridge.  This is free (although limited to how many you can place every few seconds) and is used to maneuver.  It is in the player’s best interest to place bridges as fast as possible.  In an average game there are hundreds of bridge pieces being built.

The bridges have Tetris-like shapes

Each bridge piece is a Tetris-like shape that is made up of smaller atomic pieces, e.g., a straight, a corner and a tee.  Each of these under normal circumstances will be a separate draw call.  However, thanks to the Mesh Combiner script provided with Unity, these are very easily combined into the Tetris-like shapes.  However, there are still hundreds of Tetris-like shapes to deal with.

Small diversion:  A few years ago, a friend of mine and I worked on a game engine ourselves.  For better or worse, I pushed us into using threads aggressively.  One cool benefit was that since systems acted in independent threads, we could avoid the situation where the may game loop has to run as fast as possible to service any possible need.  Thus the CPU would only be used as much as it was needed, which for many situations was hardly at all.

In order to deal with these many independent systems we set up a publish/subscribe mechanism to decouple dependencies between the systems.  We also had several systems which would only run based on certain events happening, rather than running in a loop.  We created a central dispatch and scheduler which we called the Hub to manage the execution of these systems and dispatch messages to them.

Recently, I saw a way of bringing back some aspects of the Hub into Unity.  Specifically the dispatcher and the scheduler.  The dispatcher uses Unity’s SendMessage interface, but instead of needing to know which game object you want to send to, you just send the message to the dispatcher.  Any gameobject that wants to see that message simply needs to register for it.  One of the ways I use this inside RisingStorm is to turn shadows on and off when the FPS are too low or safely high enough.  When the FPS drops below 15, a message is sent to the dispatcher saying “LowFPS” and the shadows disable.  Once the FPS goes back above 60 another message is sent and shadows are turned back on.  Because the FPS checker doesn’t know who is getting the message other effects could also register for the low and high FPS to decide when to turn off.  I could also use this for Level of Detail changes.

But, going back to the bridges, there’s an even cooler trick.  Running the mesh combiner is expensive and Unity’s dynamic batching is limited to 300 polygon object.  It would be nice to have something in between that we can choose to run as needed.  This is where the scheduler comes in.

It works as follows, when a bridge is placed it checks to see if it has been connected to another bridge or if it is independent.  If it’s independent it creates a parent object that contains a scheduled mesh combiner.  This mesh combiner will run 3 seconds after it has started.  However, if another bridge is placed connected it’ll child itself with that existing bridge’s parent and the scheduler will be pushed back by 3 seconds.  Once the player stops building a particule bridge path for 3 seconds the combiner will finally run and combine all the bridges.

Here’s what the code looks like:

public class MeshRecombiner : MonoBehaviour {
    public float recombineDelay = 10.0f;

    private bool dirty;
    void CheckRecombine () {
        if (dirty) {
            Recombine ();
            dirty = false;
        }
    }
    void MarkDirty () {
        foreach (Transform child in transform) {
            if (child.name == "Combined mesh") {
                child.parent = null;
                Destroy (child.gameObject);
            } else {
                child.gameObject.SendMessage ("MarkDirty", null,
                    SendMessageOptions.DontRequireReceiver);
            }
        }
        if (!dirty) {
            Scheduler.GetInstance().AddSchedule (recombineDelay, "CheckRecombine", false, gameObject);
            dirty = true;
        } else {
            Scheduler.GetInstance().AddSchedule (recombineDelay, "CheckRecombine", gameObject);
        }
    }

Notice a few things.  First off, there is a function called “Recombine” which is called by “CheckRecombine”.  ”CheckRecombine” is what will be called by the scheduler.  ”Recombine” is essentially the “Start” routine from the “MeshCombiner” class that comes default in Unity.  One change is that a child object “Combined mesh” is always created regardless of whether there’s only one material.  This is to simplify the “MarkDirty” code.  The “MarkDirty” function is called when a child is added or removed or modified in some way that requires recombining (e.g., a material has changed on the child).  This “MarkDirty” then disables all the current combinations sends message to all the children who should enable their individual renderers again.  It then sets up the scheduler to call it.

Here’s an example of a simple child which can be combined:

function Start () {
    transform.parent.gameObject.SendMessage ("MarkDirty");
    enabled = false;
}

function MarkDirty () {
    var renderers;
    renderers = GetComponentsInChildren (Renderer);
    for (var r in renderers) {
        r.enabled = true;
    }
}

The final piece to this code is of course the Dispatcher and Scheduler.  However, they are much to large to copy and paste here.  Instead, they exist on github here: https://github.com/tosos/Geewhiz under the project Geewhiz which is the name of the previous game engine I worked on.

Using this method in a situation like the screenshot shown above with all the bridges the draw calls can be taken from something like 700 in that image (with all effects added including shadows) and reduced to on the order of 200, which if it had been enabled at the time the screen shot was taken would have likely taken the frame rate from 3 to something more like 15, at least.  These days it is possibly to get much higher frame rates during multiplayer games of RisingStorm.  (If you’d like to follow the progress of RisingStorm itself find it here:  http://risingstormhq.com/news.php)

Hopefully you will be able to get similar speed ups with dynamically created objects using a combination of these techniques.  Drop a line in the comments here if you are able to find some use with these.

In the last post I mentioned attempting to refactor the build panel into both an in-game construction device and a level editor device.  It turns out one of the issues that had been bothering me for a while was in the bridge display.  Every time you place a bridge a new random one takes it’s place.  I put this in the build panel, because it was the obvious place to do so, but it bugged me that there was so much code in the build panel for just displaying icons and now it also had to be responsible for managing bridge replacement when all the other icons for other units and structures just stayed there (for the most part).

The level editor didn’t need this whole bridge mechanism, it just needed a panel that would show icons and allow you to drag them onto the field.  I finally had a reason to split out the bridge code.  It was beautiful.  At least mostly, I still haven’t entirely pulled out old assumptions.  I tore all the code that handled bridges into a separate file.  Because it was well separated I could remove a number of if checks and actually shrink the code somewhat because now I could assume that I was only dealing with bridges in that code.

I’ve been talking about assumptions a lot.  Back in school, it would have been called “invariants”.  Invariants are great, it means you *know* a certain thing is going to be true (or false) at a given time and so there’s no need to check.  Good coding practice will tell you to check anyway, and that’s true, but now you replace an “if this do this” to “assume this or throw an exception” and if your code never throws that exception during testing you did well.

So assumptions aren’t bad, they’ll make the code more efficient in the long run, but may also make it less general.  There’s a choice to make.  I could have written the level editor without reusing the build panel, but I was predicting when I made the choice that there would be a lot of repeated code and not much efficiency to be had.  As I said, it really was the same thing.  But in general, if there’s that choice to be made, I’ll usually pick the one with the smaller code, because smaller code looks like it was easier to do.

It turns out there are another couple bonuses which might be had from refactoring, but which I haven’t yet attained.  I’ll get to the bonuses in a few paragraphs (see that foreshadowing). The stumbling block I’m sitting on is that the bridge piece when placed notifies the build panel that it has been placed so that the build panel knows to randomly select a new piece of bridge to put in there.  Once I split out that bridge control code, the bridge piece was notifying the wrong system.

My assumption, for efficiency was to have the bridge piece just grab the build panel, because every draggable grabs the build panel.  In fact, it’s in the base class.  The build panel is supposed to know enough about all construction to darken the icon while any of its objects is being placed and not allow you to click a new one until you either place or cancel the last one.  So each object which is in the build panel needs to tell it when it’s placed so that the build panel knows it can relinquish the lock on the display.

I could use a publish subscribe model as I mentioned previously for the pathfinder, notifying any subscribers when the bridge is placed.  This would allow both the build panel and the bridge controller to get notifications and each do the appropriate thing with a good split. But this is a larger chunk of code that I’d have to write and in reality, it’s only this one case.  So having a full publish/subscribe is a bit over the top and a little to much architecting.  At least it feels that way…

I mentioned bonuses that I haven’t yet attained.  I haven’t attained them because currently the build panel still assumes there are icons for bridges at the top and still in the build panel.   The build panel then has to call into functions in the bridge controller to let it know when it gets notification from a bridge piece.  There’s a level of pointless indirection in that call.  The first bonus then would be that the level editor uses that space to place icons like “save/load” and “quit” as well as other editor specific icons like the player’s priest (his avatar in the game) which sets his starting location.  But because the build panel currently assumes bridges in those locations, the save/load button becomes “bridge slot 1″ (by a function call, SetBridgeIcon (1, “Save Icon”) normally used by the bridge controller when a new bridge is ready to replace the icon) and the priest icon is “bridge slot 6″.  Just arbitrary bridge locations instead of arbitrary icon locations.  And it looks silly.

The other bonus I would receive by fixing this is that there is a bug in Unity with the gui elements.  Because I’m changing the icons, on these buttons it redraws them.  For some reason, Unity’s gui doesn’t remove old draw elements, so as you place bridges, the draw calls goes steadily upwards.  Likely it’s drawing nothing, but a draw call is a call out to the graphics card and bridging is a very common thing so much that thousands of bridges will be placed during a game.  1000′s of draw calls will cripple the graphics performance.

By just establishing a graphical placeholder in the build panel and letting either the editor or the bridge controller actually draw in the icons they  need I can remove the sillyness in the editor of setting “Bridge Icons” and in the bridge controller I can optimize out the GUI bug.

So I still haven’t arrived at a solution.  I may just go ahead and write a publish/subscribe mechanism with as many assumptions as I can put in to keep the code as small as possible.  And maybe I’ll figure out a way to refactor it into something smaller later.

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.

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.

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.

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.

<?php
$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 = www.data.Split(","[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", "");
};
</script>

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.

Maid of Dishonor. Global Game Jam 2010 (click to play in browser).

This year we attended the Global Game Jam with the Albuquerque chapter of the IGDA.  It was the second game jam we’ve attended but the first global one.  Last summer our local IGDA held a game jam in the same format as the global one, but just locals.  I’ll talk a little bit about the differences I felt between the smaller venue and the larger one.  But I want to spend more time talking about some of the lessons we learned about the process of building a game in 48 hours between the two sessions, and what we learned about this particular game as we were developing it.

One of the things that stuck out to me doing the global version was that it doesn’t feel all that much different than the local version.  We really only interact with the people at our location.  It’s too bad because there were ustreams set up, apparently, but people only really watched some streaming dogs (from what I knew).  I’m not sure how to achieve a more global feel.  There was one point where we heard a weird horn coming in through the speakers and went to investigate and discovered that we were watching Iceland.  More of that would have been pretty entertaining, but also distracting from the task at hand, no doubt!  I wonder if it would make any sense to allow people to work across country borders?  The time limits would be strange, but the open source community does it often enough it might not be impossible to consider.

Despite all the differences I didn’t notice there was one I did notice a great deal.  That is that in both cases the global and local version, our ideas (from each group) were well contained, and by the end familiar.  This is great because even though people are working on different projects, we can feed off each other for ideas and there’s a lot of similarity that comes out in the various projects (but also different perspectives on the concept).

When there’s a global group to look at you suddenly discover other cells which have come up with a completely different sort of convergence.  It’s a bit of the best of both worlds, you get used to seeing and thinking about what the people around you are working on, but when you go look at the global submissions it’s more than a little surprising what other directions are discovered.  I imagine for the organizers looking for great ideas coming out (and I’d love to see a summarization of some of the best, most original) it is a well-spring of thought.

The more interesting differences between the two sessions for us were in the game itself.  For the two of us, there was no difference in how the 48 hours played out: Friday mostly planning, Saturday work to death, Sunday cleanup race to the finish.  Except this time we had the experience of hind sight.  We came in with two very important personal constraints.  The first was that we were going to use Unity instead of Pygame which we did last time.  We both know XNA and other systems (like Ogre and Crystalspace) but Unity’s editor is simply one of the best.  It makes things very simple to get working quickly, and we wanted to spend time thinking about the game and not how to make some code work (I’ve got a day job for that :).

SnakeCrush. Written in Pygame for the NM Game Jam 2009 (click to download source)

When we were doing pygame, we spent most of Saturday building an engine.  The 3-layer parallax motion system I was trying to develop did not work out (and probably wouldn’t have the way I was thinking of it) and we ended up going with a more “Double Dragon” style system on Sunday.  Compared with Unity, we had the basic game working on Saturday morning.  In fact, we had the basic game, walking around the room, working on Friday night after we spent a few hours throwing the models together.  We finished up the Eye, the first camera (in the lamp) and the mechanism for clicking on the lamp and the picture to determine whether you’d win or not, but more on the design (and subsequent evolution) later.

The other constraint that we went in with was to not do physics.  Despite that Unity makes it fairly easy to get physics working, there is still so much tweaking that’s involved in getting the numbers to work out, especially in terms of friction and collision response that it either requires being too careful with measuring to “act right” or spending too much time twiddling numbers until it “looks to act right”.  Although I was personally tempted several times to just turn on physics (let you move the furniture around, bump into the desk, etc) it made proving out the mechanism much easier.  Instead of having to detect some complicated motion which is “bad” we simply defined moving using the right mouse button as “bad” and there was no question.

But for a more advanced design, perhaps having such subtle movement in the presence of the Eye would be an interesting twist.  What if instead of having to explicitly turn the lamp away from the portrait, a player could instead vacuum up against the desk and bump it cause the lamp to fall.  This sort of complexity may be an interesting take in the future, but first to discuss the evolution from the start.  The game we finished on Saturday morning (and uploaded to the site) was the simplest possible concept:  Either turn the lamp before moving the portrait and win, or turn the portrait without first turning the lamp and lose.  The point of the game was to use the eye to learn that the camera was in the lamp and thus realize that you must turn the lamp first to clear the portait.

While this was useful, it’s really not an interesting game.  So we went to lunch to discuss what it would take to make it better.  We had a few thoughts.  One was to install multiple cameras, so that we would have cameras watching cameras and more of a puzzle to determine how to move objects while off camera so as to clear the space.  To make it interesting (and because we skipped physics) we made it so that when you moved one object with a camera in it, it might point at another object with a camera, thus increasing the challenge.  You’d have to move object A (which is pointing at B), move object B (which is pointing at C), move object A back (since it is currently also pointing at C), and finally move object C to clear the goal.  This is what we ended up with (although there’s a D).

We were very pleased with the hand gesture for opening. It's like Fonzi meets the Force.

One of the other thoughts we decided to discard was requiring that you close the door.  We thought perhaps that while the door was open the eye should be fully on.  You’d have to first close the door before you could start moving stuff.  However, once you closed the door you had 5 minutes (chosen based on one of the achievements) to solve the puzzle.  In the end we decided the puzzle was hard enough as is.

There was one other decision which seemed somewhat minor, but ended up, I think, becoming fundamental to the possible future of this game.  That is that originally before you could win the game by finding the safe behind the picture you had to clean the room of every stain.  However, due to the mechanism for moving some stains couldn’t be reached until you solved the puzzle with the Eye.  It doesn’t really line up with the motif, but it makes the business of finding the stains much more interesting.  It’s safe to clean them (after all that is your cover story) but to get to some stains you have to move furniture which sets off the alarm.  Silly, but effective.

Can't leave a spot untouched. Even if you risk the alarm to do it!

Well at some point, I thought that it didn’t make sense to have to find every stain because the main point was to get the treasure from the safe  (also I couldn’t find some of the spots that John put in and got annoyed and disabled the condition check so that I could test the win condition :).  We thought it would be a nice bonus to see who while finding the treasure could also clean the most spots.  However, after seeing the way people played, nobody really cared much about the treasure, they only cared about finding all the spots to clean and cleaning the room.  Our organizer said it was like “OCD”, he *had* to find all the spots.

After talking some, we thought really the whole concept of Extreme Maid Cleaning service was much more entertaining than just stealing while cleaning.  Forget the treasure altogether.  Instead you’re supposed to clean the place without setting off alarms or traps (we’d always pictured having traps at some point.. .like trying to break into the Pentagon, Mission Impossible style).  But what kind of insane place would require the maid service to work around traps?  Well a super villain hideout of course!  They need janitorial staff too don’t they?  They can’t really risk turning off all the alarms and traps just to clean things.  That’s exactly when that jerk James Bond would come in dressed like a maid and pretend to clean everything with all the traps disabled (perish the thought… someone pretending to be a maid).  So better for the super villain to be safe and leave the traps and alarms on, requiring the maid to have to work her way around them.

Who do you call when your average maid service just doesn’t cut it (and keeps getting killed by your Robot Sentry’s)?  You call Extreme Maid Services (or Ninja Maids… or … something)!

For the Win

This came to mind recently because I was thinking about hard-points to place on the ships.  The idea is similar to that handled in Galactic Civilization 2.  Each component you add can be joined against a hard-point in the existing set.  You start with a chassis which has a certain number and then you add a wing

Constructing space vehicles from hard points.

which has it’s own hard-points.  The wing attaches to one, but contains many more itself.  This allows you to build very customizable ships, and I plan to use this concept to allow the players to build their ship for space combat.  Such a feature provides a number of great game benefits, like finding (in-game) particular or rare pieces (especially those that give certain abilities when attached to the ship) and allowing them to be specifically targeted, damaged and destroyed during combat.  But the basic point is that it allows individuality and customization.

So the question was:  Who is responsible for the hard-points?  Is it the artist who places them when he designs the chassis in order to place them in the most aesthetically pleasing way?  Or is it the game designer who needs to set them up based on number of properties necessary for game balance?  Most likely for game balance the designer would only need to specify the number of hard points to allow, but it’s also possible for perhaps physical reasons, and in my case that certain specialized hard points would be needed on top and bottom since they’d rarely be seen in this pseudo 2d game.

In some way’s the answer is both, but that’s not an answer easily addressable in Blender.  The easiest way I could imagine to do this would be to have the artist generate empties (which are objects that contain only one vertex).   The game designer could also modify these directly in the blend file, which would allow, for instance, the artist to place initial hard points where he likes them and the designer could delete or move them to fit some balance notion.

However, model files as they are treated in Unity are read only.  And when considering the work-flow of a designer doing a rapid test cycle within Unity, pulling up blender to modify the location of those hard points seems like more effort than necessary.  So the next direction to take is to use an element in Unity itself.

The good news is that Unity already has a visual editing capabilities similar to those in Blender which an artist would be familiar with using.  One of the things I’ve learned over the years of programming is that the shorter the test cycle is between making a change and trying out the effects of that change means the better you can work.  In Unity it is actually possible to modify within the editor while the game is running.   When I first started testing the physics restoration on the ships, I ran the editor and pulled them out of alignment using the model editing tools while the physics was running.  The physics  would then work to fix the alignment back to the 2d plane.  This was an amazingly tight loop to fudge numbers which are not based on any physical reality in the first place.

So there is one final decision which I haven’t nailed down a direction to take.  On the one hand, I might use Unity’s empties to attach to the object and position for hard points.  These would be children in the prefab, and I’d use the script to find them when it came time to attach parts.  However, the other option would be to store them as variables in scripts.  It turns out using the GUI extension scripting in Unity you can setup widgets to modify even variables graphically.  The easiest way to handle this is to add each variable to the script for each hard point.  The script would then be attached to the object and each of the hard points would have the small edit widgets to allow the artist to change them.  If the designer really does only need to worry about the number of hard points he can decide this by attaching the appropriate script and let the artist set the actual position for each.

In the next post on this topic, I’ll address the decisions made on which methods to take for implementing hard points and post links to the prototype in-game editor.

Asteroid being destroyed

Background

The idea originated with John (also on this site) and where it came from is probably best left to a post from him.  For several years we worked on Crystalspace.  When we decided to quit, Shooter (later to be named Longshot as you’d see in the web player) was our foray into designing our own game engine (also another story…)  At the same time I was working my way through a Masters degree and taking a course in machine learning.  At about that same time I agreed to develop the AI for the game.  I realized I didn’t really feel like generating a long tree of if-then rules and had just learned about behavior cloning in class.  So I pushed John into helping me round it out for the class.  We added another ship and spent some time with networking and left it there to see whether this behavior cloning thing would work… but this behavior cloning thing is also going to be another story. :)

Original Design

I’ve seen so many of these games now that it’s hard to decide if anything in particular was innovative about what we were doing.  Perhaps some of it was at the time.  It’s a top down space shooter that includes asteroids.  Much has been written on the rite of passage that is cloning asteroids… everyone should do it at least once.  Of course, we couldn’t seem to get the asteroids physics to work as well as we liked so we dropped them.  But really there’s nothing new there.  For the sake of curiosity, I’ve uploaded the windows installer for the original here.

Where there was a sense of newness was in the design of the engine itself.  This design, it turns out, is described pretty handily as “System of Systems”.  It is an idea employed by the military for many simulation games and uses High Level Architecture (HLA) as the formalism.  The idea there is that each of these systems is developed by separate entities, but they can be brought together and easily coupled into large, more complex systems.  Our thinking at the time wasn’t quite so complex.  I simply wanted to see whether or not we could thread one loop of physics at a reasonable simulation rate and thread another loop of graphics at a separate rate and yet another loop for gameplay without strongly coupling any of them.  My thought was that graphics could run just fine at 30 frames per second and the only reason to run it higher was because if it were strongly coupled with the physics you’d want that at a higher rate.   We did run the physics at a higher rate of 100 hz (along with the input so it felt responsive).  Interestingly the gameplay was entirely event driven responding only to collision events.  This is where Unity’s design is so nice because in the same way all of the gameplay exists now in the collision code.

function OnTriggerStay (other : Collider) {
if (other.name != "Bullets" && GetComponent(FireBullet).remoteFire) {
if (other.GetComponent(LifeCycle) != null) {
other.GetComponent(LifeCycle).hitpoints -= 1;
}
var closestPoint = other.ClosestPointOnBounds(transform.position);
var sparkPos = (other.rigidbody.position + closestPoint) / 2;
var spark = Instantiate (prefab, sparkPos, Quaternion.identity);
var sparkForce = transform.position - sparkPos;
spark.GetComponent(ParticleAnimator).force = sparkForce;
Destroy (spark.GetComponent(ParticleRenderer),0.5);
Destroy (spark.GetComponent(ParticleAnimator),0.5);
Destroy (spark.GetComponent(ParticleEmitter),0.5);
Destroy (spark,0.5);
}


It’s not entirely true that it’s all in that script, but that is a majority of it.  Two of my favorite results to come out of that design were the fact that the game ran with almost no CPU usage despite maintaining responsiveness and that I could lower the graphics to 8 fps and still play the game just fine.  It was painfully strobed, but it was possible to see what was going on.  Due to this it would have been easy to scale the graphics however necessary to fit into whatever capability the system had while allowing the physics to operate however needed.  However, this innovation wasn’t really much related to how the game played.

What may have been most interesting to me was the “hovercraft” design.  Although the motif is ships flying out in space, I thought it would be more interesting to see them rock as though on water.  We had already decided on forcing the 3d physics engine to fit to the 2d plane, but since we were using 3d models and a fully 3d engine, I thought we might as well show it off.  In order to do so we’d have the ship lean forward when moving forward and lean further forward when going really fast.  When stopping it would rear back (almost like a horse).  And best of all, when an explosion would go off it should rock the ship.  It wasn’t until using Unity’s Detontation engine that the rocking effect came into it’s own.  You can see this when you blow up an asteroid and get close.

The way this rocking effect was modeled was to virtually attach a spring to the front, back, and sides and have this pull the ship back into the plane.  Then we could apply forces from thrusters or explosions which would offset the springs and ultimately either pull or balance them out.

function FixedUpdate () {
if (rigidbody.position.y != 0) {
rigidbody.AddForce (0, rigidbody.position.y * -restore.y, 0);
}
yoff = transform.localRotation * Vector3(1, 0, 0);
xoff = transform.localRotation * Vector3(0, 1, 0);
rigidbody.AddRelativeTorque(xoff.y * -restore.x, -yoff.y * -restore.z, 0);
}

One of the really amusing side effects that came out of this was that by timing a forward and reverse thrust, one could cause the ship to rock to higher and higher degrees until ultimately flipping over.

New Design

Enter Unity.  For some reason Unity is designed with me in mind.  I don’t know who read my mind and made everything I could have possibly wanted out of a game editor, but someone did.  Thanks! :)  The result you see here was built in 2 weekends taking all the assets from the old project and porting all the code necessary (not very much) into javascript.  All told, I think  I spent about 20 hours on it and most of that was on learning how to do the networking (something I never did get right for internet latency on the old version).

Although I haven’t yet brought back the behavior cloning, even with a second ship the game was pretty boring.   But I really like the idea of modifying ships and customizing.  I’m not a very good artist, and I don’t feel like making hundreds of ship models.  So instead, I plan to make a bunch of ship pieces and allow the user to put them together into different pieces.  Of course some of the obvious choices would be chassis size and style, engine power, weapon type etc.  But one of the more fun ones due to this wobbly control scheme is to allow various levels of restoration power based on the types of items added to the ship.  If you don’t mind wobbling a great deal perhaps you can load your ship with more weapons.  Or perhaps you want a tight control and will exchange that for less fire power.  I’m giddy with the options :)

Another gameplay element I’m toying with is one that used to come up when playing Magic the Gathering.  When you’d duel another player you were supposed to put a card out on the line.   Whoever won would get the other player’s card (as well as their own back, of course).  Well I haven’t quite decided how players get cards (or really ship components) yet, but I thought it would make for an interesting gambit that when you do duel somebody you can take a component from their collection if you beat them.

More interesting however is to bring the behavior cloning back into it.  Because the idea behind BC is to create a model of how you play, one could imagine building a fleet of ships and playing with each in order to build up a clone which plays a particular way.  This allows one player to virtually control an entire armada when fighting another player, not just one ship.  But the downside is that if a ship gets captured that clone could be taken (or maybe just copied).  If you’ve made a particularly effective opponent someone may be able to steal that and use it in their own fleet.  Reminds me again of Magic the Gathering.  I used to play exclusively blue.  I don’t remember the names of the spells exactly, but I think they were “Steal Creature” and “Clone Creature”.  I remember playing one guy who was quite proud when he brought out some very rare, very powerful monster onto the playing field to take me out.  I had a steal creature sitting in my hand waiting for just that to happen.  On my next turn before he was able to attack, I stole it to use on my side.  And on the turn after that I cloned it.  Now instead of him having one very rare and powerful creature he had none.  I had two.  He was very, very angry.  I beat him quickly and left just as quickly :)

Anyway, hopefully people won’t be nearly as upset at losing a clone in the wages of war.  It is after all just a clone, but it creates some very frightening possibilities for components!   Keep an eye on this space, I’ll  talk more about advances in the game as well as give some background on behavior cloning and how to make it work.