Ahoy!

What did the pirate say when he was asked why there was a steering wheel in his pants?

“Arrrrr! It’s drivin’ me nuts!”

Anywhoo, here’s a bit of an update on Beat Pirates:

Design

Objective Mode

This week, me and Billy sat down and worked out the first 10 levels of Objective Mode, which will serve as the 10 levels you get in the free version of the game. Each of these levels has 3 objectives each, that we’ve tried to scale and vary appropriately. Hopefully this will be a good introduction to how Beat Pirates works, and provide a good taste of how much is in store if you choose to pick up the full version. There’s some pretty dang cool stuff in there, and it’s been a lot of fun coming up with names and descriptions for all of the objectives.

Beat Week

Billy asked me not to call it that, but oh well. Beat Week is something that me, Larry and Billy have tossed around for a month or so, as a way to make a big push towards getting Beat Pirates done. The plan is to try to get as much done on the programming/development side, and use that week to take off from our other projects as much as possible and focus on what we need to get done for Beat Pirates. We all have some pretty big ideas, along with a hefty list of things that need to be fixed, so I’ve been working on coming up with lists of everything we want to get done. There’s a good chunk of GUI stuff in there, but we also want to focus on getting even more characters in the game, and raise our total by a good margin. Billy also has some big plans for the actual beats in the game, and I’ve worked on getting some of that code in there, but I won’t talk about it until we’re FUR SHURE doing it. I’ve got a nice big wall of bits of paper and post-its for all of the ideas and plans, and we’ll see how much we can churn out, so we don’t take up too much of anybody’s time.

Coding/Programming

Syncing

I mentioned in the last update that I’ve had some problems regarding syncing the music on our mobile builds. Thankfully, a few hours after I posted that whole rant, those problems were pretty well rectified. I’ve developed a new system to manage the beat of all of our characters without having to rely on an update call at all. The solution came about by modifying how we sync each beat with the core track. Instead of working to sync them all at once, I developed a system that calculates the beat’s frequency and creates a value to offset the clip being added to the audio pool so it instantly begins playing and syncs with all the other tracks. I had to learn a bit more about ulongs, frequency, timescale, and whatnot to get it all working, but now that I can leave all the music playing to Unity’s own looping system, it’s much easier.

Saving/Menu Beginnings

One of the things that I’ve strived for most in coding Beat Pirates is in making everything as accessible as possible. Basically, this allows me to modify anything about the Beat Pirates world at runtime, from the size and shape of the map, to how many islands and objectives to spawn, to what specific characters to spawn. I can even control things like where the Pirate Base is located on the map, and what assets to load. After working through a few different options, I chose to use Unity’s PlayerPrefs system in order to set all these variables f rom the menu. This lets me load different gametypes and difficulties all in the same scene. My goal is to be able to provide you guys with three options for gametypes straight from the get-go, which is a bit different than what I discussed last time. Objective Mode is our bread and butter (i’ll get to that later), Score Arrrrtack is our difficulty-scaled quickplay mode, and then we’ll have Custom. In custom, think about creating custom gametypes for multiplayer games like Halo or Unreal Tournament. We’re going to try to come up with a lot of cool playstyles for the game, and then make them available in a big ol’ list of things for you to try. We’ve already discussed Lost at Sea, but I’ve also worked out a fun little auto-runner-esque mode that has you trying to pick up as many people and reach the end of the world before the time runs out.

Objective Mode

So this is the big one. I’ve been tooling with this stupid “of course this’ll work” strategy of how to do Objective Mode for about 6 months now. Now, i’m going to have to do a bit of a ‘choose your own adventure’ thing here to cover my tracks a bit regarding prototyping and integrating my strategy:

TO ALL (CURRENT AND FUTURE) EMPLOYERS: I totally prototyped it. Tested it, knew it was going to work, and then laid the groundwork to incorporate into the game. That’s what a responsible and professional developer does, of which of course I am one of course of course I am.

TO EVERYBODY ELSE:  I totally didn’t do any of that. Here’s a note of advice to anybody working on a coding project. NEVER DO THIS. TEST IT. DON’T ASSUME. IT’S A STUPID THING TO DO. Now with that said, I got amazingly lucky that everything turned out pretty dang well. The plan has always been (in my head) to write all of my objectives out in an XML document, and have Unity take that in and perform all the necessary doohickies to track them. And it actually works, for the most part. I have a document that creates each level, and lists the objectives in that level. Each objective then has a number of variables, including a name, description, it’s state (whether it’s tracked instantly, on a per-round basis, or overall), and the values to track (of which there are about 17). I can even have one objective track multiple variables so I can do stupid things like “Go off 8 jumps with 5 people in your boat.” That’s a bad example, but you get the gist.

Screenshot of Objective Mode in Action

My only setback was when it came to the mobile arena. When releasing updates to the game on Android or iOS, it’s more than likely that I’d just re-build the whole thing and push it out, considering that it’s not that big of a file (currently hovering around 50MB). Of course, the problem is that if I track the completion of objectives/levels in the XML document, everything goes kablooey when it’s updated, and you lose your savedata. The good news is that PlayerPrefs doesn’t reset if you update a game, so all that means I just have to track the current level and the number of objectives completed in that level in PlayerPrefs. Long story short, it reads everything from the XML, and writes anything it needs to PlayerPrefs (level, objectives left, any ‘overall’ variables). I’ve also set it up like the rest of the game, that very little data is hard-coded, so I only have to add a very small amount of code in order to track additional variables.

GUI

After getting all of the optimization and control issues out of the way on the mobile platform, I’ve turned to working on the game’s GUI. Now this is a problem, and you know what I mean if you’re a mobile Unity developer, as Unity’s current GUI system for mobile platform is… well… this. OnGUI runs like crazy, takes up a lot of your CPU, and then subsequently redraws itself EVERY SINGLE TIME, sending your draw calls through the roof. There’s an awesome looking solution on the way, but it doesn’t look like we’ll be seeing it right away in Unity 4. So I went hunting for options. Let me clarify a bit, I went hunting for FREE options. This game has been entirely out-of-pocket for me so far, and money’s not flowing out of my butt quite yet (GAME IDEA). The tl;dr is, if you’ve got the cash, buy NGUI or EZGUI off the asset store. They’re freaking AMAZING. I’ve worked with both of them at my job, and it’s great software. Now for you cheapskates out there who don’t mind a bit of a challenge, I’ll point you towards UI Toolkit. UI Toolkit basically runs a UI like you handle a spritesheet, by having you take all of your images into one file, and then showing what you need where. It does text in the same way too! The positive thing for us mobile folk is that we can get a full GUI with all sorts of different things going on using only 1 draw call (per spritesheet). ONE. BAM. Tasty stuff. So there’s only two Unity-controlled GUI objects in the game, and that’s the initial objective mode display (since nothing’s running at that point anyways) and the compass. The compass needs to rotate and pivot and such, and Unity’s GUI handles that stuff better. Everything else, from the menu, to the in-game HUD, to the concert text is all handled by UI Toolkit. The downside is as it’s a crowd-sourced Github project, the documentation is very minimal, so prepare to Google your heart out. Check the Github wiki/documentation, YouTube, or the Unity Forum page for some help, but you’ll be doing a lot of stuff yourself to figure out how to get everything working. I’ll also point you to Tim Shaya’s blog, which has a lot of great UI Toolkit code resources.

So yeah! That’s about it for now! I’m really excited to show some of this stuff off to you folks, and I’m really happy with how things are working out so far. The list of things on my wall keeps shrinking, and hopefully that means that we’ll be able to add in even more stuff if we get what we need done!

Cheers,

Brice

Good day to you all, and welcome to the new Beat Pirates site!

As we’re getting closer to release, I figured that it would be good to keep you all a bit more updated on everything that’s going on. As our lives have settled down post-graduation, we’ve all worked on finding what’s next for us as a team. We’ve all moved to more steady projects, but have maintained our desire to get Beat Pirates out the door and available to you all! So here’s the plan:

Over the next few months, we’ll be working on getting everything that we want in for the Beat Pirates iOS and Android release. I’ve been working daily on taking our most recent release and modifying it to be a bit more mobile compatible. We’ve optimized all of the code to work on mobile, changed up the visuals, and added mobile control options (touch and acceleration) and it’s been working pretty darn well. In addition, we’ve been doing some light playtesting on our new control schemes, to make sure that we can overcome some of our initial reactions regarding controls to pick up civilians.

Hopefully I’ll be able to wrangle the rest of the team to give some comprehensive updates to the art and sound, but for now, you’ll be stuck with me. So let’s get down to bARRRRRass tax.

Design:

Modes:

Over the past week or so,we’ve taken a look at what we have and the time we have to finish everything, so we’re narrowing down what we want to do for the games design. We’re hoping to ship with at least 3 modes which are:

Objective Mode:

Objective Mode is much like you see in other mobile games like Tiny Wings or Jetpack Joyride. The player starts at level 1, and is given three objectives. These objectives will vary from actions like “Jump 25 times in a match” to “Fill your boat with all Monster characters.” When the player completes those three objectives, they advance to level 2 and are given three more. As the levels progress, the objectives get harder, and map grows bigger with more obstacles in the way.

Score Attack:

Score Attack is much like the mode that is currently available, where the goal is to rack up as many points within the time allotted. We’ll have different difficulty modes that allow for players worldwide to compete with each other.

Lost at Sea:

When I was working on some of the new code, I realized how easy it is to customize a great deal of our spawning conditions, so Billy came up with a sadistic idea. Lost at Sea places your boat in the middle of nowhere, in a vast ocean, with no idea on how to get home. The objective is to find all 6 citizens on the map, and get them to home base as fast as possible. Hopefully with time and updates, we can put more clever modes like this in.

Controls:

I recently got back in touch with Erin Robinson, our instructor for the course in which Beat Pirates was originally designed, and she gave me some great notes on the most recent version that we’ve released online. Me and Billy had a good talk about what makes our game fun, and part of that comes with the satisfaction of picking somebody up on your boat. The problem is, for many people that experience was frustrating and too much of a challenge, so I’ve worked hard to find different ways to approach that problem.

We started with a new move, called the “drift.” A press of the button would tilt your boat diagonally, giving a much bigger pick-up range while going over an island, at the disadvantage of losing all steering abilities. This was in there for a while, and is still in the version online now. But after implementing the touch controls, it became clear that having an additional button on the screen reduces the simplicity that is the core of Beat Pirates fun. So we cut it. Instead, I’ve enhanced your steering abilities on the island, as well as have made the characters themselves larger, in order for the player to have a greater chance of picking them up. It’s more fun for sure, and works great with touch controls.

Code and Optimization:

I put a version of Beat Pirates on my phone around February of last year, and it ran like… well, it ran bad. It became very clear that a large portion of the code and implementation created during the Game Sprint would not be usable, so I went back and rewrote the entire game. Well, after more testing, I kind of did it again. It became clear that there were numerous problems that we just couldn’t solve for our mobile experience, so I went about trying to recreate the Beat Pirates style with better optimization. The first thing to go was the water. As you can see from some of the screenshots around, I’ve added a very poorly-drawn water texture to serve as temp0rary art, until we’re able to get a final piece ready.  While I was very attached to the idea of realistic water in a pixel world, it really wasn’t working, and upon seeing it with even just my crappy waves, it became clear that it had to go.

Second was our syncing issue. Beat Pirates currently has 41 different characters, each with their own unique rhythm. The problem has been syncing that with the main beat track. This is still an issue I’m dealing with on the mobile side, as the game likes to skip over my Update script occasionally, but in order to prevent us from having to have 50 different constantly looping tracks, I’ve worked on  a system that enables/disables them at will. Hopefully this will assist with our problem, as it is all tied to the main beat’s frequency, which provides us with a hyper-accurate timeframe in which to start playing the other tracks.

I’ve made other tweaks along the way as well, removing any sort of rigidbody collision from the game (which was a particularly difficult issue with our islands that used compound colliders), and writing mobile transparent shaders. In addition, all lights have been removed from the game, save for our single directional light, everything else is handled by Vertex shaders and clever trickery (eg, the shadows beneath the island moving from left to right over the course of the day.)

Anyways, for those of you who like the inside baseball of it all, that’s our most recent update. Once I include our new GUI system, I’ll be putting a new demo version on the website. But look for us to release our iOS/Android version around January/Feburary of 2013!

Cheers,

Brice