The Animal Farm

September 25th, 2014

Robots Need Love Too

The newest dope game from Elephant Mouse, Robots Need Love Too, is now available for iOS devices. Here, have a link.

I was the Client Engineer on this title. ’cause that’s my job and stuff.

April 6th, 2014

More Thoughts on Unity

This is the follow-up to this post. It’s a bit more nitpicky.

For 2D games, the Mecanim animation controllers are not great. They tend to be just big webs where every state can go to every other state, which gets unmanageable when every animation has 4 directional variants. You can work around this though by playing states manually. In the cases where you need long chains of animations, the transition system is quite useful.

It’s weird how you setup animation events - not in that the editor design is bad, but that before you create an event you also have to have the method written out that will receive the event. Fine if you’re just one guy. But if your artist is working independently from your programmer, you either have to collaborate closely, your artist needs to learn rudimentary coding, or your programmer needs to edit animations. For some cases this is unavoidable - like when the events are complex - but most of the time you just want to fire off a named event and have code listen for that, and the artist should be able to handle the animation editing on his own.

There’s no good way to listen for when an animation ends. There really ought to be a clean way to do this, but there really isn’t.

Sprite Packing
Unity’s Sprite Packer does some things well and does some things very poorly.

One cool thing that it does is create a mesh out of the sprite instead of using a naive rectangle. This saves on fill-rate, requiring the pixel shader to run less often. It does increase raw triangle count and makes the vertex processor work a bit more, but that usually isn’t an issue.

One bad thing that it does is pack poorly! TexturePacker outperforms it pretty solidly. At first I attributed this to the complexities introduced by trying to fit together complicated meshes in a sheet rather than rectangles, but even if you turn off the Unity mesh generation, its packing is still worse.

I mentioned this in the first post, but there’s more:

Once you start downloading plugins from the Asset Store, your workspace gets really cluttered really fast. There’s absolutely no standardization on directory hierarchies or asset placement. Some plugins like to throw things in your root folder. Some plugins nest things 5 folders deep. Sometimes plugins use the same directories for the same ideas, sometimes they don’t. Sometimes a plugin will introduce direct conflicts with other plugins - especially hazardous on Android builds.

It rapidly escalates into a Huge Mess.

It boggles my mind that Unity couldn’t provide one serialization option that works on iOS with the binary stripping level at its maximum setting. Both the XML & Binary serialization choke. You have no choice but to roll your own. A lot of people recommend Google Protocol Buffers, but that has some weirdness associated that I didn’t want to drudge into.

Some clever usage of ISerializable and IDeserializationCallback can make binary serialization available if you’re willing to roll up your sleeves.

Curiosities & Miscellaneous
Screen.width and Screen.height return the wrong values in the editor. How crazy is that? They’re consistently half the actual pixel dimensions of the game view.

January 31st, 2014

Thoughts on NGUI

NGUI is regarded as one of the best UI frameworks for Unity. It’s constantly on the front page of the Asset Store, it has high reviews, and everyone I talk to swears by it. It’s good, but it has some serious failings. Let’s chat about it:

I put this first, because it’s a really glaring black mark on NGUI. It’s just not very well documented. Most ‘how to’ guides are in video form, which is not great if you want to get at information quickly. The small bit of text there is is… poorly written and confusing. The guide on UIGrid is a crazy mismash of information that leaves you more confused than enlightened. And 85% of the documentation is woefully out of date - they use the wrong class names, legacy workflows, or have just become plain wrong. It’s almost impossible to suss out exactly what your’e doing without painstakingly combing through examples or wildly guessing until you strike gold.

NGUI actually has a lot of stuff. It’s trivially easy (once you know how) to setup a table, make it scrollable, and rig it in such a way that it works across all resolutions. Complex widgets & interesting interactions are never terribly hard. In fact, I can’t think of a single widget I’d want that I can’t hook up in NGUI with a little effort.

I can’t speak a lot here - I haven’t dived too much into the localization system. But I do know at least one good thing and one bad thing. First the good: NGUI supports dynamic fonts as opposed to being exclusively bitmap font oriented, which is practically a requirement when you’re localizing to Asian languages. And the bad: the word wrapping for Asian languages is just wrong. They use a naive algorithm based exclusively on white space separation, and that’s just not good enough for most Asian languages. It’s a shame, since this is a pretty hard problem.

Unity 4.3 Integration
Unity 4.3 introduced 2D workflows as a first class citizen of Unity. NGUI quickly integrated it, but not in a particularly robust way - it’s impossible to use a Unity Sprite as a 9-slice. Which means if you want 9-slices, you’re forced to juggle NGUIs atlasing system & Unity’s. Not impossible, but not ideal. There’s nothing stopping them from doing this. I’ve dug into the code and seen how they render Unity Sprites, and the system could be extended to support 9-slices, but it’s not entirely trivial (NGUI has a system of complicated editors where setting up the right information is a little tricky).

That’s all I can talk about right now. I’d like to speak on performance, but I don’t know yet - I haven’t created a UI significantly complex enough to tax the system, and I’m unversed in Unity performance in general. So… let’s hope that doesn’t explode for me.

As of this writing, Daikon Forge looked like a decent competitor, but I couldn’t get the trial running on my system. There are certainly a few other solutions, and some of them might be good, I encourage you to explore them and let me know.

January 30th, 2014

Thoughts on Unity

I’ve been looking heavily at Unity these days, so much so that when I participated in Ludum Dare a couple months ago, I opted to make a jam entry with the engine.

There are some good things about Unity, some great things, some obnoxious things, and some little quirks. I’d like to discuss them here in no particular order.

Oh, how I’ve missed you C#. I’ve spent the last three years of my life coding exclusively in Objective-C. I’ve come to terms with Obj-C, much of my initial vitriol toward it has dulled, but I never grew to like it. I like C# though, and I’m constantly amazed at how much more comprehensive the C# standard library is; when I was porting over a lot of useful code, more often than not I found there was no porting required because C# already had an equivalent method in its library. I don’t know yet how well garbage collection performs on mobile - that worries me a bit given my experience on other platforms, but we’ll see.

Multiplatform Support
Unity touts itself as being completely multiplatform, and that’s true and it isn’t. It can certainly build to every platform, but there are gaping holes. There’s no such thing as a per-platform asset - there are *settings* on a per-platform basis, but you can’t, for instance, use one texture on Platform A and a different texture on Platform B without either loading both textures or sacrificing usability within the editor. This gets worse on mobile, where you certainly don’t want to load iPad Retina images on an SD iPhone, but getting around that is especially hard.

The current UI system is pretty laughable for a large project. The only real options are in the Asset Store. Unity has been working on a new UI system, but I have it on good authority that they’ve been working on that UI system for forever and that I probably shouldn’t hold my breath.

This falls under one of those ‘great’ categories. Physics systems are hard; I’ve coded a few and never really got a good handle on the area. With Unity, though, it’s really just setting up some colliders and tweaking parameters. It’s not a solution to everything - good platformer or car physics is still hard - but it’s a really nice starting point.

The Unity editor is pretty good. It’s intuitive, powerful, and easy. It’s also incredibly extensible, allowing you to easily create custom editors & functionality when necessary. Conversely, MonoDevelop is not that great - the Intellisense is horrid, the autoformatting is obnoxious and hard to configure properly, and the debugging can feel wonky. Plus it doesn’t interface very well with the main editor: half the time I double click to open a file, I get the wrong file or the wrong project entirely. It’s not unusable, but I probably liked Xcode more, and that’s… unfortunate.

External Plugins
I’ve had to interface with Obj-C land for a few custom plugins, and it was really, really pleasant. Just wrote some code, and Unity pulled it into the Xcode project seamlessly. It’s not perfect though - there’s no proper way to add frameworks or change the Xcode project’s linked libraries without modifying the Xcode project manually. That’s Apple’s fault though. They just didn’t provide a way to modify Xcode project files outside of Xcode. A few clever people have reverse engineered the Xcode format for doing this, but it’s a brittle and dangerous solution.

Asset Store
The Asset Store is awesome. There’s a ton of stuff in there, and it’s mostly reasonably priced. Not a lot to say here though - it’s just full of good stuff.

That’s enough for now. It’s just a small look at the toolset, and I’ll probably have more to say in the future. There have been some hiccups, some larger than others, but you’ll have those with pretty much any system. Overall, it’s been a perfectly pleasant experience.

May 1st, 2013

Old Game Ideas, v1: High Noon

Thought I’d take some time to re-explore some of my older game ideas. They may have already been presented in this space, but many of them are so old that even I barely remember them.

We’ll start with High Noon, a project I started up in college and restarted at various points to little success.

At its core, it’s a turn-based strategy game set in the Wild West. Before each battle, the player picks a team of thusly stylized units. Each unit has base stats (weapon, range, damage, etc) and a couple special powers. Each turn you have action points you can spend to move your characters around and attack.

Pretty simple setup. This was designed to be relatively small - no real player progression aside from acquiring new units, no story to speak of, just quick battles.

Back when I first thought of it, asynchronous play didn’t exist as a widespread concept, but I think it’s a pretty natural fit.

Might make a good Unity learning project? I’m already tinkering in my off-time (side note: I’ve ported a sizable portion of my procedural building generation, and it’s looking pretty snazzy). Asynchronous is hard/costly to do cross-platform, but Game Center is a viable option for iOS-only.

March 13th, 2013

Fun With Chess

A week ago I sat down and programmed a basic chess implementation with full support for hot-seat play. It includes most of the rules except for conditions where you can force a draw.

It even includes en passant, which hardly anyone knows. For those unversed: if an opponent moves a pawn two spaces for its first move and it ends up side by side with one of your pawns, you can take the opponent’s pawn by moving your pawn into the space that was skipped over.

And for those not sure about how castling works: if you have an unmoved king and an unmoved rook, and the king is not in check, and there is a clear path between the two pieces, and the king would not move into or through a space that puts him in check, you can move the king two spaces toward the rook. You then move the rook to the other side of the king (jumping the king, essentially). This generally puts the king in a more defensible location and puts the rook in a more active role in the game.

The rules I haven’t implemented: the fifty move draw rule states that if there are no captures and no pawn moves in fifty consecutive turns by each player, a player can claim a draw. The threefold repetition rule states that if the board is in the same state three times with the same player to move, a draw can be claimed (I probably won’t implement that one). Pawn promotion is when a pawn makes it to the other side of the board and can be exchanged for any piece.

So yea. I guess RPG Chess is happening.

When I get some free time again, my next step is to setup the Game Center rig and see if I can’t get asynchronous play going. After that, i want to add a framework for using character powers.

And after that, the world.

March 3rd, 2013

RPG Chess Art & Technology & Love

I’ve been putting a lot of mental investment into RPG Chess. Thinking about technology and resources and time.

Technology was a decision practically made up for me. I want to support asynchronous play, and the only (free) system that supports this is Game Center for iOS. There are other systems, but they’re expensive or complicated or involve writing a lot of the back-end tech myself. There’s a limit to how much time I want to spend treading that kind of water. My knowledge of web development is already pretty minimal, and if I manage to get through life never touching JavaScript or PHP again I’ll consider myself a success.

Art is still a wide open question. I’m conflicted on a lot of things: do I want classes or not? If I have classes, it makes sense that every class would have unique pieces, but that’s visually confusing. I don’t want players to be uncertain about what image correlates to what piece. Do I want animations? That bumps up my art requirement considerably, but it could add a lot of panache to the game. Can I get away with just using stock art on the internet? There are some good sets out there, though less than I’d like. Is it morally reprehensible to take that stock art and sell it as IAP? It adds to the game, but it’s not something I myself created.

Monetization has been at the back of my mind. I came up with the idea for the game without considering how to make money off it, but I’ve made no money off enough games that it’d be nice to, y’know, recoup some of my investment. (Side note: Cuddle Bears actually lost me money, even if you don’t count the time we invested). I can sell: new piece sets, new boards, new board layouts, premium powers, premium classes if I introduce classes, avatars, artificial advancement. “Pay to Win” leaves a horrible taste in my mouth, but I hope to balance the powers in the game such that higher level players don’t have a distinct advantage as much as they have a wider selection on how they’d like to play. Do I include ads for non-paying players? That’s pretty common in freemium games, but I dunno.

Scheduling is a constant concern. I’m not horribly busy at the moment, but I’m busy enough to make a side project hard to manage. This thing will have to be scoped carefully - big enough to make it an interesting game but small enough that I can actually finish it. I’m already foregoing a single player mode entirely (no complicated Chess AI here!), so the ‘RPG’ title won’t be as descriptive as I’d like. I think once I sit down and start devoting my energies, things will come together, but it’s impossible to predict how long this will take or whether it will become another unfulfilled project.

Design wise, I’ve locked down a lot. I’ve got 20 different powers thought out. If I don’t have classes, that may be good enough for a first release. If I do have classes, I’ll need a lot more to support positive, constant player progression; at least 10-13 per class. The general flow and UI feel is coming together on paper. Communicating new concepts to the player has been streamlined, largely because the new concepts themselves have been streamlined.

During the course of writing this post, I think I’ve resolved on including classes. The major reason is that they provide a larger deviation on standard Chess and fit nicely into the RPG framework. I was starting to worry that simply ‘Chess + Progression + Powers’ was not enough of a difference to make this an interesting product. Allowing the player to have different characters that can each grow independently adds a whole new dimension. Balancing will be tough, and there are art decisions that come along with it, and it also slows down the new user flow if I’m not careful. But I think it’s the right call.

So now I guess all that’s left to do is, well, get started. Very little tech work has gone in so far, but hopefully over the coming weeks we’ll see that change. First playable by the end of March? I’m not going to commit to that, but it’s a nice idea.

March 1st, 2013

The Evolution of RPG Chess

Recall this post about RPG Chess - a deviation on Chess that introduced piece leveling and a new piece that leveled between matches.

As I tried to flesh out the game, I became increasingly dissatisfied with how hard it was to communicate all the information. First, every piece having different abilities depending on its level leads to a lot of information players need to manage. Of course there would be heads up displays, but as a player you don’t want to constantly reference a help section to determine if a pawn at level 2 can counter-attack your every move. Second, the inconsistency between an individual piece (which would not level between matches) and the new War Mage (which would) creates a disconnect between expectations and reality. Third, the new mechanics could not be conveyed without lots of tutorials and notifications and popups.

Everything was feeling unwieldy.

My first move to rectify this was to cut the War Mage. A new piece with disjoint mechanics lost its appeal. However, I didn’t want to lose the sense of progression, so instead I decided the player should level. Upon leveling, players would be rewarded with different abilities that can turn the tide of the battle.

The notion of abilities was a natural fit - it’s a more manageable chunk of information that’s easier to convey to the user. It also has parallels in other games which adds familiarity. Finally, there are more balancing options. Ability cooldowns can be introduced and tweaked based on level discrepancies between players. Bonus: it adds monetization possibilities in the form of premium abilities.

Once abilities entered the picture, individual piece leveling seemed less relevant. Instead of a piece gradually becoming more empowered, there could simply be abilities that did what those levels would do. So now instead of a pawn gaining the ability to move backward, we’d have an ability that moved a pawn backward.

It leads to a much more streamlined system. Most of the complications in terms of UI and messaging melt away without losing the crux of the idea.

The major open question that still remains: should all players have the same bank of abilities available, or should players bind themselves to a “class” where certain classes only gain certain abilities? The former seems the easier to balance - if players all have the same options available to them, there’s no possibility of one player being at a severe disadvantage. It’s also less work. The latter seems more personal, allowing players to choose a play style and bond with a certain class type as they would in any other RPG. The latter also has monetization options in the form of selling premium classes.

I’m not sold either way here yet. I lean toward giving players the same bank of abilities, but I remain very open to the idea of separate classes. There’s still some thought and opinion gathering to be done there.

February 27th, 2013

Clashing Cards

Here’s a game idea that primarily uses a standard deck of cards & a board. Loosely described, because I’m not out to write the rule book in a blog post, but I think you’ll get the idea.

Divide a deck into two halves - each half as a complete red & black suit. These halves form each player’s personal decks.

On the board, each player has a certain number of ‘card stacks’ - a combination of red & black cards that are face up such that only the top card is visible. Red cards are attack cards, black cards are defense cards. At no point can a player rummage through his opponent’s card stacks to see what cards are there.

Every round, players draw some number of cards from their deck. They then place those cards face up on any stack that they choose. If they have less than 5 stacks, they can place a card on an empty space to form a new stack.

Once players have placed all their cards, they start taking turns activating stacks. A stack can only be activated once per round. When a stack is activated, it can perform 2 actions out of the following list:
* Move - move a single space
* Attack - attack an adjacent opponent card stack
* Combine - place the stack on top of an adjacent stack, forming a larger new stack
* Divide - take any number of cards from the stack and form a new stack in an adjacent space

Those are mostly self-explanatory except for attacking: when a player chooses to attack another stack, both players reveal the cards in their stacks. The person with the most attack (red) cards is the winner. For each attack card in excess, the loser must give the winner a defense card. If the loser has no defense cards to give, he must give the winner all the attack cards. In the event of a tie, nothing happens.

The cards provide victory points equal to the face value of the card. The winner is the person with the most victory points at the end of the game. ‘End of the game’ conditions have yet to be determined - either once a player hits a certain number of victory points or a fixed number of rounds I think.

That’s basically it. Exact numbers for things (board size, max # of stacks, victory points to win, # of actions per turn) are subject to iteration and actual playtesting. There’s also room for special rules like making face cards do something special when in a deck. I see this as a potential mobile asynchronous multiplayer game as well, but it’s worth roughing out a prototype to try it out.

February 20th, 2013

Third Game Idea of 2013

This blog may just turn into assorted game ideas/executions for the foreseeable future. That wouldn’t be its worst use.

Slots SLAM!

It’s a cross between a slot machine game & a match three game. You spin the machine, and symbols come up. When they do, you can then move them Bejeweled style to form matches. You can’t make a move unless it forms a match. New pieces do not fall in from the top.

When you’re satisfied that you’ve made all the matches you can, you spin again to get new symbols.

You’re awarded based on the number of matches and any combos. If you manage to match all the symbols without hitting the spin button, you’re awarded a ‘Jackpot.’

You’re penalized based on how many symbols are left on the screen when you hit the spin button. If you hit a certain threshold, the game ends. Alternatively, there’s a timer that your’e racing against to get the highest score. Alternatively alternatively, you have a set number of ‘coins’ you can use to spin & you gain coins with certain matches & the game ends when you run out. I’m sure there are other game modes that can be mined here, but those are just the two blatantly obvious ones.

It’s a more casual game than what I generally focus my time on, but I think there’s an idea here. Maybe something for a Game Jam?