Everyone that knows me well, probably knows how I feel about narratives in games.  Keep it simple, keep it out of the way, and don’t depend on your narrative to drive gameplay decisions.  My rule is to develop the game first, and then wrap everything, characters, story, even art around the limitations already imposed by the game.  Trying to add story as a limiting factor first can lead you to make rather odd gameplay choices.

And your story and scenario may need to change depending on the direction the game takes.  Star Saver, as you may know, started out as traveling around the galaxy and visiting other planets.  Does this still happen?  Well… we don’t know.  But now that more of the game is in place, I’m starting to lean in the direction that it may take place on the same planet.  And truth be told, does it even matter? Maybe?

Of course, we have some odd story choices because we’re making it up as we go along.

Here’s the story of Star Saver so far.  Most of it revised several times over the course of development (which has taken WAY, WAY, WAY too long).  It is still evolving, and we may end up telling more or less of it depending on what happens over time.

The game starts out in Squid Village, where all of the Squid are starving because the stars have been vanishing from the sky.  Squid eat starberries after all, which only grow in starlight.  Well, they eat their babies too, but let’s not get into the cannibalistic side of things.

When Squidly goes out searching for starberries, he soon learns that the Prince of the (Galaxy? Planet? Kingdom?) needs an urgent message delivered.  The message being that the Prince has been cursed, and the first person he contacts also becomes cursed.  And so Squidly and the Prince are attached together by the cursed chain.

Luckily this works out well for the Prince, who isn’t the brightest bulb in the knife drawer.  And it works out well for Squidly who soon learns he can use the Prince as somewhat of a bodyguard. 

It is soon discovered that Squidly’s evil uncles are behind his curse and the disposition of the King.  And possibly his transformation into… something funny.   They find that the Uncles are hoarding the Stars in the Sky, possibly to do something evil, and probably to give Squidly and the Prince something to collect in each level.

Luckily, the uncles have been fighting amongst themselves and have been cursed as well.  Since they are evil and they don’t have any friends (like Squidly) to help them, they mostly hang out cursed in their castles and waiting to be beat up.

… and we don’t know what happens next.  

As we finish the game, we’ll solidify the story.  Possibly simplify it a little more.  And we desperately need a reason behind the Stars being collected.  Or maybe we don’t .

Hope you enjoyed!

In any case, Star Saver is making slow and steady progress. Seven Yo and Super Mad Matador are doing well!  I haven’t talked much about Seven Yo! because it was broken for a short time (when played on ios 5).  But it’s working now, and it’s really fun!

If you haven’t checked them out, you really should!

Super Mad Matador

Seven Yo!

And we’re working on some really cool projects for some cool people!

Can’t say too much more — but I’ll at least put up some new Star Saver Screens!

Woah, you’re still working on this?

Never mind the debug art.  Never mind the fact that sound isn’t hooked up yet.  Never mind the occasional camera logic failure (we have new camera logic, ripped straight out of Mario World.  I’ll go over that some time).  We have made literally tons of progress.

Tons?

If you weighed the diff, I’m sure there’s at least a ton of changes.  It’s been a few months since we posted an update.  And that’s really too bad.  We’ve been working on some contracts that got priority.  Also, since Bull’s Hit (now Mad Matador) could get finished quicker, we pushed that out first.  It’s a simpler game, though still a lot of fun.  If you want Star Saver quicker, you should buy Mad Matador …. as soon as Apple approves it.

How about that update?

Oh yeah, that!

AWESOME!  When will it be done?

We didn’t think it would take as long as it has.  But we’ve made several design changes over time, based on feedback we’ve gathered over the time we’ve been working on it.  Heck, you should see the earliest versions.  It’s a lot more fun to play now, though I’ve been working on it so long it’s hard to tell anymore.

That would be a good short article to write actually.

Tell me if there’s anything you want to know about development, and I’ll cover it!

To do this, I would need to put my character on a layer that both doesn’t receive clicks, and can ignore other layers. 

Unity Collision Masks

So, I’m still relatively new to Unity, and the workflow it uses, so every now and then I encounter one of Unity’s (to me) weird features.  The newest one that I struggled the last couple days with was how to deal with Unity’s Collision Masks.

I have been using Raycasting to determine the position of the click in world space, so I can move the character to the correct position.  This is quite obvious, and pretty easy to work with.  On your Camera you would just attach something like:

RaycastHit hit;
 
 if (Physics.Raycast(ray, out hit, Mathf.Infinity)) { 
 Vector3 pt = hit.point;
 }

This will return the pt in world coordinates so you can act on it.  If you set the objects you don’t want to test on the layer “Ignore Raycast” you can only test the objects that are ON that layer.

What’s wrong with this?

This is a little cumbersome, because you may want to set objects to other layers to ignore collisions, for instance. Which is what I wanted to do here and struggled with:

A Solution?

It took longer than I would have liked to come up with a solution for this.  The Physics.Raycast method has a third parameter that takes a Vector3 position, a raycast, the vector length, and a Layer Mask.

The layer Mask seems a little convoluted at first, until you realize what it’s doing.  When you set a layer mask, the ray will only return the objects on the mask you define.

The code would look something like this:

RaycastHit hit;
int layerMask = 1 << LayerMask.NameToLayer("ClickTest");
 
if (Physics.Raycast(ray, out hit, Mathf.Infinity, layerMask)) { 
     Vector3 pt = hit.point;
}

The difference here being the addition of the layerMask.  The easiest way to produce a layermask is by using the bit shift operator ‘<<’, and the NameToLayer method just returns the int value of the layer named “ClickTest” (in this case).

If I needed to add additional layers, you only need to use the bitwise OR operator |.

An example would be:

layerMask=int layerMask = (1 << LayerMask.NameToLayer("ClickTest")) | (1 << LayerMask.NameToLayer("AnotherClickLayer"));

This frees you up to use other layers, other than the “Ignore Raycast” layer to test for things like collision

So, to walk though walls?

I finally figured it out here: 

I created two layers, one called “IgnorePlayer” and the other called “PlayerLayer”.  All I had to do, was call a method on Physics at the beginning of the game:

Physics.IgnoreLayerCollision(LayerMask.NameToLayer("IgnorePlayer"), LayerMask.NameToLayer("PlayerLayer"));

And just like magic, I wasn’t receiving clicks from anything but ClickLayer, and objects on the layer PlayerLayer were not colliding with the objects IgnorePlayer.

As I just finally get my head around how Box2D physics work (for Star Saver), I start trying to finagle around Unity’s.

Well, I hope this helps someone!

Super Bull’s Hit is a Fast endless runner with a Brutal Twist!  

You play as a Matador in the running of the Bull’s where you can taunt the bull to cause endless havoc!  El Toro has a chip on his rather large shoulder and will not hesitate to take revenge on you though.

Simple Control

Just touch the screen and your Matador will follow.  Touch the bull to taunt him, and he’s come charging after you.  Quick and simple to pick up, but difficult to master.  Even a baby could play it.  But you wouldn’t want him too.  I mean, look at all that Blood!

UPGRADES!  Who doesn’t love ‘em?

There are over 20 levels of achievements and goals, from splattering other runners, to making the Bull catch sick air on convenient ramps.  You can also collect coins and upgrade your stats to collect points quicker, or chain longer, funnier combos!  There are 100 different combos.  I can’t even remember all of them!

Leaderboards!

Compete with your friends for high scores over Game Center, and take advantage of the extended display on the iPhone 5!  It’s a perfect fun game for your new iPad Mini, and has hours super addictive entertainment value!

Show your Mad Matador skills with the punniest named app ever!  Super Bull’s Hit!

…

Seriously, it’s a lot of fun.  I’d buy it, if I were you.

I’ve tried to like it.  I built a few levels with it.  But I just can’t wrap my head around how to effectively build levels in Unity’s Editor.

This doesn’t all necessarily apply to this project, but I’m thinking about it now that I’m planning out how to load levels.  Let me explain:  I am a big fan of rapid iterations in level building, and the way Unity is focused around art assets makes it very difficult for me to effectively plan levels.

Now, I could build all of my greyworld level geometry in Maya and import it.  Then build assets to scale inside of Maya and import them individually… but to me breaking out a 3D program to make some minor geometry changes kind of defeats the purpose of a real-time editor in the first place.

I’ve gotten somewhat used to using unity cubes and spheres to quickly prototype, but then when it comes time to import actual assets the scale is all borked. I can’t be the only one having this problem.  And Maybe I’m missing something, but it’s extremely frustrating to me.

Why am I complaining about this?  Because I am trying to figure out how I want to manage room loading.  I was initially thinking about using the unity editor to set up rooms and move between them, but I don’t think that’s going to work correctly for me.

I know there are solutions for this.

like Probuilder (which looks awesome, by the way). My first thought was to build levels in Probuilder, then export the mesh data and use that for beautification.  But that may be a little bit intense for the type of project I’m building.

Keep it Simple Stupid, right?

I decided to use my own level format, and it simple XML containing all of the info about the current room.  That would include decorations, enemies, scale, collision data, etc.  That can’t be too difficult, right?

Which brings me to what I worked on today:

I’ve been thinking on how I want to actually build the levels, and get the rooms populated.  I’m thinking it should be absolutely the most simple solution.

Right now, I’m just using text files.  High Tech!  But that’s not going to last long.  Especially when I start having to lay down actual game play.

I saw this project:

but it looks like it may be a little too robust for my needs.   I personally love Tiled, but I don’t think I need actual “tiles” for this one.

It looks like it may be useful to some people, so I’ll post the link:  http://karnakgames.com/wp/tag/unity3d/

In Game Editor?

So, this is all Pie-in-the-sky, but I think I’m going to go with an in-game editor.  This way I can scale objects, place them in individual rooms, and save out the XML to recreate it on the fly.  In the end, I’d like to not have to stop the game and restart it to see or save the changes.

The good thing, is that I’m picturing a VERY limited amount of art resources in this game. So maybe I’m over thinking this.  I think the best answer is to stub out all of the art resources as cubes to get scale correct, and start substituting them as I complete art.  Or maybe dynamically building basic object geometry for export in the editor would be worth the time to build.

Just thoughts.  No firm plans yet.  In the end, would this be any different from just using the Unity Editor?  In my mind being able to customize the work flow may be worth it.

Someone has to have done this in Unity already, and it would be nice to get some insight into how smoothly I could expect it to go.

Anyway, this is going long and is a bit ranty:

Everything is starting to be hooked together, which is exciting.  It’s still not much but It’s coming along.  There’s a lot of pain on the horizon, I can tell.  I’m going to have to make some actual game design decisions soon.  Especially regarding how to keep the game from becoming a scope nightmare.

Anyway, thanks for reading and watching!  I’ll be back tomorrow!

Yeah, that’s really what the game used to look like. I mean, this is quite obviously a testing phase, but… look at it! This is a hard game for people (me included) to get excited over.

Here’s what it looks like now, for reference:

I don’t think it looks half bad! Was just doing a full run though, trying to see if I could complete all of the goals (I had to change some because they were way too hard). It seems to take quite a few hours to really complete everything. Maybe I’m just a bad player though.

Anyway, it’s late and I need to wrap up my testing. Just thought someone out there may be interested in seeing before and after images.

Here’s my setup on the baddies:

Controller + Base Collision >
Facing Object >
Art Object
Attack Object
Attack Collider

I did it like this, so I could have the base object locked on it’s rotation axis, and the facing object indicate the direction and spin the all of the other elements. I think this is an OK setup. If anyone has any additional insight, I’d appreciate it.

I ran into some problems getting the characters to “knock back” correctly.

The first problem is the obvious one. I’m not sure how much force to apply to make a difference. Really, does anyone know what units these are measuring? Is 20 units of force going to move something? I just had to keep guessing until I got something that felt right.

The second is something I’ve already screwed up in Unity once, and I will probably continue to struggle with. I keep forgetting that I’m in a 3D world, and Y is up. Well, in this case, I put the attack offset on X instead, but it’s a similar mistake. I must remember to check this first!

I also screwed up my visual indication that the player is getting hit and is invincible (the blinking). I linked it to the base object, and not the art object. Yeah. Oops.

So It took me some time to figure out what was going on when I attacked a character.

No big deal overall, but I was planning on getting to level loading today. I’ll have to tackle that tomorrow.

That’s right. The inexplicable popular Flash Game Bull’s Hit is getting an iOS release! Super Bull’s Hit in fact.

I worked on this game for the Global Game Jam a couple years ago, and put on Mochi on a whim. A couple million plays later, and I think… I should really port this game.

So I did!

It’s wrapping up very shortly (Not Star Saver short, I mean like literally aiming for an Apple Submission today). It’s a shockingly addictive game. Try to avoid the bull, and mow down as many other runners and obstacles as you can.

It’s got an achievement system with multiple levels, 100 different combos, 4 upgradable stats with 6 upgrade levels each.

I mean, it’s actually a complete game. Yeah, no kidding! And it’s totally worth what ever I’m going to charge for it, right? Come on, you guys are all my friends – you can drop me a couple bucks .

Yeah, me too.

It took a lot longer to figure this out than I’d really like – but apparently rigid bodies in Unity that have their constraints locked still have a small amount of wiggle to them.

This causes some weird physics behavior, that I 100% thought was totally my fault. Well, it could actually BE my fault. But I’m not sure how to fix it. Here’s the setup.

I need to move my character to a target position, so every frame I look at the difference between the current and target positions and apply a Normalized Vector scaled by a Walk Speed. This gives a very nice, smooth transition between the positions and will apply my physics correctly.

I don’t know if this is driving the physics engine crazy (changing the velocity all the time) or if there’s another bug involved, but when I did this, my character started drifting slightly. Never consistently.

So I tried doing everything I knew how to do. Reseting the rotation, manually setting the position when you complete your move. Things like that. No effect.

Now, I’m not a Unity Pro by any means. There are a lot of little switches and buttons that I’m not really clear on yet. And that “is Kinematic” button was one of them.

To finish the story – it’s important. Use it. The ground object kept “wiggling” slightly. I guess the constraints just push it back to it’s origin, or something, so the player would pick up on that and move around slightly. I would guess it has to do with using a sphere collider as his base, too. Or the fact that he’s also rotation constrained.

Don’t know. Anyone have any further info about this?