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.

Mecanim
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.

Plugins
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.

Serialization
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.

February 1st, 2014

Neptune’s Pride

Though I’ve been playing a small bit of Guild Wars 2, most of my gaming thoughts have been focused on the vicious warfare happening between me and my coworkers in Neptune’s Pride 2.

NP2 is a space warfare game, a 4X game focused on research, exploration, and destruction. The basic gameplay mechanics are simple - you amass armies and lunge them at your opponents, trying to conquer half the galaxy.

The primary “hook” is that games take place over a long, long time period, but you only need to spend a few minutes a day playing. Traveling between two close locations can easily take 5 hours. Researching technology takes days. A game can easily last multiple weeks.

It gives rise to a number of interesting strategies. If you’re up at 3AM, can you launch a sneak attack that catches your opponent unaware and ruins his morning? If your ships are attacking a planet 6 hours away, will they make it there before the opponent realizes and brings in reinforcements or upgrades their weapon technology?

It also gives rise to novel diplomacy. Alliances and mischief are always part of any good war game, but they feel different when they’re evolving over the course of multiple days as opposed to multiple hours. You can research a tech for days, share it with an ally, and then be caught by surprise when you wake up at 6AM to find that ally just used that tech to invade your home world. You can play several sides against each other, comfortable that they won’t be able to reach you from the other side of the galaxy until they’re knocking at your door the next week.

And you’re doing this through private messages, so unlike a board game, you can plot out in secret and really hurt someone’s feelings.

This is all, of course, in addition to the normal stress of a space warfare game - deciding how to allocate your resources and what upgrades to focus on and where to send your armies.

My eastern front. Which is secure - don't get any ideas.

My eastern front. Which is secure - don't get any ideas.

It’s a really fun game. I strongly encourage giving it a try with some friends.

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:

Documentation
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.

Functionality
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.

Localization
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.

C#
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.

UI
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.

Physics
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.

Editor/Tools
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.

April 7th, 2013

A Brief Discussion on Bioshock Infinite

Spoilers Ahead. Deal with it.

Bioshock Infinite was a good game, though somewhat lacking in the gravitas of the original Bioshock.

A lot was made of this big floating city in the sky, and beautiful as it was, generally it just felt like a normal city. A normal hard to navigate city, since I could never keep track of which skyline would take me where. There was a sky and some ground, and most of the time I forgot I was perpetually in the air. I tend to prefer bright and accessible games, but it’s undeniable that Rapture set a mood that made it a character unto itself.

Columbia sets a mood more with what fills the environment. Much like Rapture is a picture of Objectivism gone wrong, Columbia is a comment on Exceptionalism and Nationalism taken to their nasty extremes. Here it does an excellent job. My favorite portion was when they introduce Fink and his establishment, focusing on labor exploits that are very much rooted in American history. His talk seems almost satirical - like the heightened rhetoric of Ryan - but it’s a reflection of a reality that still partially exists. It’s masterfully done.

The narrative had some pacing issues. Near the middle there is a series of fetch quests, cheapened by the fact that every time you get near the thing you’re fetching you simply jump to another world where the thing you were fetching had already been fetched. Time starts to (seem to) skip around erratically, and without actually accomplishing anything you’re in the middle of a bloody revolution.

Near the end there’s the classic “giant information dump” to reveal things they couldn’t fit naturally into the narrative but needed to reveal for a full conclusion to make sense. It’s something Eternal Sonata did, though Eternal Sonata did it much worse. It’s not terrible - they provide subtle hints throughout the game where you could possibly piece bits of it together, and once it all fits there are even subtler clues in the game that seem a lot more clever. Still, there could have been more organic revelations.

Comstock, for all his importance, didn’t measure up. Andrew Ryan was a fantastic antagonist, constantly menacing you through the dreary Rapture. Comstock tries, and he has a few shining moments near the end of the game, but he’s mostly of little consequence while you tear down his army. Fitzpatrick is equally unimpressive - you don’t have a lot of time to warm to her before Elizabeth gets all stabby.

Gameplay didn’t really bring anything new to the table. Guns were guns, Vigors were (mostly rehashed) Plasmids, the end. The skylines added a little twist, and it’s clear they wanted me to use those by how much Gear they gave that was skyline-centric, but I never found much success there outside of hurriedly running away from a Handyman. It was good gameplay - a solid FPS - but nothing we didn’t see in 2007.

I found myself missing the Big Daddies, the terrifying battles that left me within an inch of my life and completely out of ammo. Even though I always knew when they were coming and had time to plan and lay traps. The closest equivalent we had here were the Handymen. They were good - seeing one of those hulks tear an airship in half before charging you was certainly harrowing - but I think there were three of them in the entire game? Maybe I should crank the difficulty up.

I know most of this discussion has focused on the negative, and it sounds like I don’t appreciate the game when set beside its predecessor, but understand that if it were half of the original Bioshock it’s still miles ahead of every shooter and the vast majority of games. When I’m thinking about games as art, wondering whether I could make a strong argument for any mainstream releases, Bioshock 1 & Infinite are the games I reach for first.

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.