Bombercan

One of the main things I took away from the Game Developer's Conference in March of 2015 was that I should learn Unity. It was much touted there, and for reasons that resonated with me. A free and relatively simple game development environment that can handle both three-dimensional and two-dimensional games and ports easily to a wide variety of platforms, including web browsers and Nintendo systems? Yes please. :)

So a little while after I got home I downloaded Unity and started going through the tutorials on their website. They included a simple roll-a-ball game, a top-down space shooter, an arena shooter, and a 2D tile-based crawler. I started to get a feel for how things could be done in Unity.

Around that time I also started getting a little restless with the tutorials. Most of the tutorials on the Unity website are in video format, which is great for showing how things are done in a GUI-based editor...but it has the distinct disadvantage of conveying information much more slowly than text, and if there's a particular part you want to reference, whether for refreshing something you went over before or learning something new for which you specifically know what you're looking for, it's hard to find that information without sitting through the rest. I'd also found out amidst the tutorials about Unity's online reference manual, which isn't intended for teaching per se, but does a much better job for, well, reference. So I decided to try starting up an unguided project of my own.

One of the primary factors that guided me to the project I did was that I wanted to create the graphical assets from within Unity, rather than using random premade assets or learning a separate 3D modeling program to make assets for importing. Unity's built-in modeling capabilities are actually just a collection of fairly simple shapes, probably intended for use as stand-ins; they expect you to import your assets from programs that are already much better at modeling, which is obviously smart for professional development, but inconvenient for me wanting to do a quick practice project using just Unity.

Thus, I had to choose a graphical style that could be mocked up with the simple 3D shapes available, something cartoonish probably...oh hey, Bomberman would do nicely. :) I could do colored cylinders to construct the players' bodies, and call it BomberCAN! X) And Bomberman is a relatively simple game, right? It takes place in a one-screen arena, it involves well-defined spaces and elementary mechanics, and I could use Unity's collision detection to implement the interactions between the various game objects. I could knock out the basic gameplay in a weekend if I was focused and lucky, and probably have a completed game in less than a month.

Well, here we are a little over a year later, and I finally have something I'm willing to call the finished build of Bombercan. X) I wasn't working on it anywhere near non-stop, of course; I have a full-time job, and even when I'm at home there are things I like to spend some free time on besides game dev (like, hey, playing games!). There were also times when I regarded other projects, like the DynRPG plugins I made, as higher-priority than Bombercan, and then there was about a month when I couldn't do anything involving 3D because the fan on my graphics card quit working. To be honest, there were also times when I got demotivated due to being stuck on something, whether it was a bug I couldn't squash or a thing that I couldn't figure out how to do in the editor. In the end, though, I learned a lot, which was ultimately what I wanted from the project. To solidify that learning, here is my post-mortem of Bombercan.

What Went Right

Using an Existing Design

The fact that I didn't have to do much in the way of design work in this project was a big help. I had a tried-and-true design to follow, I just had to figure out how to implement it in Unity. In future projects I may want to bring my own visions to realization of course, but trying to design my own game in an unfamiliar environment would've been like trying to learn a foreign language by writing poetry in it.

Simplistic Graphical Style

Graphics aren't my strong suit to begin with, and when learning a system it helps not to get bogged down in too many facets of game development. Limiting myself to models constructed from Unity's built-in 3D capabilities made asset development quick and easy for me, maybe even easier than making 2D sprite animations would've been. I think I managed to achieve a certain charm and coolness anyway, especially with the Fire power-ups and the fizzling bombs. Yay for particle effects and glows. :)

Learning Unity

As I said, my primary purpose in this project was to get experience with Unity, and I certainly did accomplish that. Of course, most of that learning came from struggling with the things that went wrong. X) In some sense that means the What Went Wrong section is really stuff that went right for my long-term career, but some of it was probably avoidable.

What Went Wrong

Striking Off Solo Too Soon?

It's possible I could've saved some time in the long run if I'd been more patient about thoroughly going through the tutorials on Unity's website. Some stuff I managed to figure out on my own pretty quickly, but other things held me up for days. Especially in regard to...

GUI Hassles

Turns out there's a fair bit more to creating a GUI in Unity than making empty GameObjects and adding UI-related components to them. There needs to be a Canvas, and an Event System, and lots of other details for it to work right. It's straight-forward enough if you approach it from the right angle, but I spent way too much time struggling to figure it out from just poking around. Anybody wanting to implement a GUI in Unity, definitely take the time to follow their tutorials about it.

Also, Unity's Layout Groups for automatically arranging and sizing UI elements work in bizarre ways. X) After a titanic struggle to get something decently close to what I wanted in Bombercan's setup menu, I gave up on Layouts and just positioned everything manually for all the other menus. I'm not saying that's a good policy; menus are fairly ubiquitous in video games, and Layouts are probably a time-saving tool once you learn to use them properly, especially if you want your menus to adjust automatically to different platforms (like tiny smart phone screens). I'm just saying that's what I did to get the game out the door in this case, and since most of the menus weren't that complicated, it worked okay.

Multiplayer Game

This isn't something that went wrong with the development per se. It just occurs to me now that a game that requires multiple people to play is hard to use as a showcase for development skills. Potential employers will start up the game and move player 1 around, maybe even try moving the other players if they're perceptive enough to find their controls. Unless they happen to have a friend/coworker nearby willing to give it a try with them, though, they're not going to have much fun. They'll at least see that I implemented something, sure, and if they're experienced gamers themselves they'll understand intellectually why it's not much fun playing it solo, but never underestimate the power of feelings over people's decisions.

The obvious solution to this is to have computer-controlled opponents, but that's practically a project in itself. X) Even in a relatively simple game, creating an AI to fill in for a human is a huge endeavor. The next option would be to have enemies that aren't stand-ins for human opponents, but mooks with totally different abilities and behaviors than the player. That would be much simpler, but still a lot of work, and would require designing levels to go with the game. Finally, it did occur to me to try an original arcade-style single-player mode in which destructible blocks drop continuously into the arena, and the player's goal is to clear them out for as long as they can before being boxed in. I may yet try that, but I'm dubious of how much fun it would be, and I wanted to go ahead and release the essential game.

Don't Use Instantiate/Destroy

On a technical note, Unity's Instantiate and Destroy methods for generating and erasing GameObjects are big performance drains. You can get away with using them sparsely, and I did things that way because the tutorials taught me to, but if you overuse them you'll pay a cost. In Bombercan they caused a big lag whenever a chain explosion of bombs happened, because a large number of "explosion segments" were being created all at once. It was so bad that the explosions would last longer than they were supposed to and end up destroying power-ups dropped from the same blocks that were just blasted away. Ironically, I read a Gamasutra article on Unity optimization which mentioned this problem shortly after I figured out what was going wrong from doing Google searches. X) The general solution is to keep a collection of GameObjects handy, teleporting them into place when needed and hiding them from the player when they're supposed to be destroyed.

Web Deployment

This isn't something I had control over, although I might have known it was coming if I kept closer watch over game industry news. The Unity Web Player has been abandoned by the major Internet browsers due to security risks. Fortunately Unity has responded by releasing a WebGL build, which works by translating Unity projects into a JavaScript-based application in a system the browsers do support. It's not a perfect solution, though; Bombercan looks noticably shoddier in WebGL than it does in the PC standalone version, mainly for lacking shadows and if I'm not mistaken having a point light source rather than the directional one specified in the project. Perhaps it'll improve with time, they did just release this very recently.