When game projects die.

Welcome to another installment from one of those crazy indie game dev guys.  Today, I'd like to talk about when a project goes awry, and ends up being nixed.

About a year ago, around September of 2012, I began designing a tower defense game.  I figured it was going to be "easy enough" to design and develop.  Now remember, I'm basically working by myself and on top of the proposed game itself, I also make my own game engine, which is, of course, a never ending task.  Anyone with a decent amount of game industry experience (indie or otherwise) already knows that these are red flags, but hey, I'm stubborn and persistent.

The design seemingly went ok, the theme is to take control of plastic soldiers and defend human living spaces from pesky animals and things like that.  Once I sat down and wrote down everything about the game that I could think of; stuff like the player's pieces, the enemies, the general gameplay, etc, I decided I needed an artist to make the project come to life.  My lacklustre art talent was several years lacking to be "good enough" to do it myself.  So offloading the art would free me up to actively start programming the logic and game system, while still working on core game engine features in the background.  Now mind you, my game engine had already been in development for around 9 months at this time and had quite a bit of features "ready-made" (and published products using it), so I wasn't starting from scratch, but at the same time also put a technical limit as to what the game could be designed to handle.

Knowing that the budget is tight, the only real options I could consider was working with local college students that needed portfolio work, or outsource to Asia.  I generally like to try to keep things local and to support our own citizens, so I opted for the earlier option.  This turned out to be quite problematic, as with all things, apparently.

I may sound like a terrible person, but the people I met had some combination of no motivation to get anything done, couldn't follow directions, simply disappeared off the face of the planet, or just didn't have the required talent to make it happen.  The people I met and talked to just simply were not qualified.  Now, what did I expect, I was scalping college students.  Eventually I did meet up with 2 or 3 potentially qualified people.  After going over the plan, we drafted up a monetary agreement -- any "good" talent is worth money.  The amount of money offered, of course, couldn't be much, relatively speaking as compared to, say, established art houses, or even asian production companies, but hey, what do these guys expect, I'm an indie game dev with barely enough cash to survive with.  This conundrum is worthy of its own blog or even book so I'll leave it at this for now.

While there are other arrangements, like profit sharing, etc, that I have entertained in the past, I wasn't at that point with this project and tried to emphasize a cash payment, *on release of the product* to potential artists.  Some of the earlier failures with contracting ended up with some work being done and having the artist disappear, leaving me high and dry, so to protect myself, I insisted heavily on "no payment until release".  The game project wasn't something that could be done in a week or two, I understood that, so it definitely warranted some cash.

The amount of cash, of course, becomes the problem.  However, an agreement had been made between myself and an artist that seemed to have the right skillset.

The first couple of months went by with an acceptable amount of artwork production (definitely better than earlier contacts), and development proceeded in a fairly smooth manner -- but artwork production soon tapered off after about a month and a half.  I understand people have other commitments, but this was starting to get a little alarming.  I try to give people slack and not push *too* hard, but hey, things can only go so long, and plus, I'm not offering a huge cash payout, so I could see how and why my project would lose priority.

However, things got more complicated.  I had been in contact with Kongregate (a publisher) over the project.  This could have been the money infusion I'd been looking for, but this has its own ups and downs, dealing with publishers that is.  If we were to go this route, I'd have to increase game production, and art, several times over... something I don't think went over very well with the artist.

So, I ended up losing a bit of credibility here, and told Kongregate that we wouldn't be capable of producing something for them in any reasonable amount of time.  At the time, I was also pushing to release a demo of the product, or gameplay videos, but they told me not to as that could jeopardize our potential arrangement.

Time for alternative plans. An indie dev competition thing that was happening a couple months away came to my attention.  The dev builds of the game were going pretty well, but I'd need to get the game to an almost releaseable status to really be able to compete; the development was fine, but the art was slacking quite far behind.

I asked the artist for a status and estimate for how long it would be before I'd get "the rest of it".  He mentioned a time, but I almost laughed.  I had been tracking rough production time and my number was *vastly* different than his for artwork.  He mentioned something like a month, whereas my numbers suggested potentially 6 months.  Apparently, he didn't appreciate the discrepancy notice.

I think I got one additional piece of art from him since, and that was almost 6 months ago.  So, rewind the clock to that time, I pretty much knew his number was never going to happen.  Knowing that, I went ahead and did what any programmer would do, bury himself with more coding to "get it done".  I kept plowing away at the core game and the engine itself when a potential tech change occurred to me.

The entire game, at this point, is using 2d technology.  Yet, there was a lot of convoluted zooming in and out, with complex scaling, floating point stuff, strange math, things like this to produce a mock 3d-esque type player experience, using a core 2d tech system.  In the background, I was already toiling with 2.5d tech in the game engine and thought, hmm, this could be the perfect chance for me to incorporate this 2.5d stuff in to the game since I'm not going to be getting art anytime real soon anyways.

"It would be so much easier if I changed over everything to this new stuff".  This line alone could probably sink entire projects, and it certainly didn't do ours well either.   3 months later, most of the game had been transitioned over to the "new" 2.5d system, utilizing more of the game engine, which was also under heavy development, especially in this area.  There now exists a mostly broken game using new tech, old art, tattered nerves, little meaningful communication, and little funds.  I'd say time was short also, but there's never enough time, so that's a constant problem.

At this point, I had to sit down and ask myself where I was at with the project.  I had gotten so far to see over the peak of the mountain to realize I've gotten myself in to a bit of a pickle.  I had to reflect on myself where did things start going wrong.

Ultimately, failure rests on the project leadership, which lucky for me, was me.  The only way to grow was to reflect.

I personally believe that it all started back at the design of the project.  I described the game with words, not with concept art.  I didn't DRAW what the game would look like, I described it.  I used reference artwork, sure, but I didn't give explicit visual direction to what the artist was to create.  I didn't understand what the difference between what a game artist did versus what a game designer did.  I (wrongly) thought I could pass descriptions over to an artist and they would make the game come to life.  I was wrong.  When questions came up over intention and meaning of things, I'd answer with words, not drawings.  Visuals speak more clearly than words, especially in the media, and artists apparently are no different.

It wasn't really until I was working on other projects during this mess that I had realized that working with designers is what I was missing here right from the get go.  Two designers (unrelated to this project and each other) had sent me conceptual art for their own projects to develop and what they sent to me was visuals.  Artwork mock ups.  I could envision exactly what things would look like on a screen.  We had a hard, set, requirement for what displays and aspect ratios we would target.  I had basically no questions about what to do or how to go about doing it, and this, became quite apparent that this is where I was so sorely weak in my own project.

In fact, I don't even really blame the artist I was working with; sure, there might have been a bit of his own motivation issue at hand, but as a project lead, that's also my problem.  I think it probably didn't help that there wasn't a solid plan and design he could follow to find his own success, and again, this was my fault.  It would have been easy to just say "he sucks" and call it good, but it is more complicated than that, and there's no way I would grow from here if I did that anyways.

So, here we are about a year later from the very beginning with almost nothing to show for it. It is quite the sobering experience.  I'd like to get this project out the door one of these days, but I think I need to send it back to the drawing board and redesign it from essentially scratch, this time with a proper design.  It's hard to let something like this go; especially after "wasting" almost an entire year on it, but I guess this is one of those things that you have to love enough to let go when need be.

Game User Interfaces

In my last blog post, I talked about the anatomy of a simple game.  The list should be fairly comprehensive for things that all games have in common.

It was pointed out to me that there, of course, are more nuances to games than just identifying what's IN them.  The user interface (UI) is sort of an important thing if people want to be able to see all that hard work you put in to making a game!

Technically, the user interface is part of the output of any software product, but the user interface is so involved, I figured it would be best to have its own post (after I left it out last time!) - phsaw, users don't need that!

Ok, let's break UI down in to a couple of components.

User Interface Design is the craft of ratios, colors, layout, math, graphs, art, shades, and all that other stuff that artsy people do.  Those people design what the user ends up seeing, where it is, how big it is, to what scale, what perspective, and what the programmer ultimately wants to reconstruct during deployment of the product.  Design is responsible for a coherent interface (similar color schemes for example), ease of navigation, and stuff like this.

Standard UI things would be usage of color themes, using familiar user navigation mechanisms (buttons), common layout themes (close button in the upper right or upper left corner), acceptable colors for things (purple for pause button?), but really this gets even more involved.  Deeper topics would be stuff like evoking mood by shapes and colors, designing intuitive user interfaces without having someone need external help and tutorials... yea all this stuff is behind UI design.

What about UX?  When I first heard about UX, I thought it was some new technology rage and I'd have to get certified and trained in it... apparently UX just means User EXperience.  I'm still going to chalk this up to buzzword-worthy, but it essentially comes down to figuring out if the user enjoys the experience that is your product.

As a programmer, I suppose this "user experience test" doesn't really fall nicely in to one of many other kinds of tests, so sure, why not, let's have it be its own thing.  I mean, how can I really test the design of the product itself from the software level.

Usually, UI and UX can be clumped together for that nasty UI/UX combo acronym.  Basically, how "nice" can a user experience your product without being turned off by it.  Did someone need developer assistance to actually play the product?  If someone is lost trying to use the product, they probably don't want to hear programmer technical jargon on top of them trying to figure out what they are already doing wrong anyways.

As part of Game Design, the UI should be heavily considered and thought out.  Again, as a programmer, when I hear UI, I think, "meh, just put some buttons around and the user will figure it out"... while that may be true, there is some actual science behind this.  Look in to the Golden Ratio and Rule of Thirds if you don't believe me.  Combining math and art/presentation; what a scary idea.

But really, it's a lot of stuff we take for granted and "know about" without really thinking about.  Like for example, we like stuff centered -- but why?  And, centered on what, in relation to what else?  What if all my buttons were different sizes and put in different places even if they did the same thing, but it can be ok because the buttons are on different screens?

Now for the catch, if the "theme" of the product is craziness, can any and all of these rules be thrown out?  Yes.

In fact, I was told in one of my art classes that "if even the smallest thing is off, people will notice and you'll get poor reviews"... as opposed to "however, if everything on the canvas looks intentional, it is lauded for its creativity".  So the short of it, if you screw up, it better be on purpose, otherwise you'll have angry people UX'ing all over your game, then probably with the mad reviews also.

Alright, next post should get back to graphics programming stuff and texture atlases.

Design to Product on Android - Game Design (7 / 17)

Finally, we can start making a game!!! Let's crack open our favorite Integrated Development Environment (Eclipse in this case) and start forging all that hot code all over the place... err wait, what am I going to make?!  Oh who cares, I can make a game/product on the spot!

Whoah easy there code vigilante!  Let's take a moment to actually design what we're doing first.  Again, in software engineering, lots of people assume that programmers just make code.  Well, that's nice, but there probably should be at least some documentation in terms of what are the features needed in a project to make. Programmers use this as a roadmap (and even a task list) of what they need to make.  Once made, it serves doubly useful as a checklist of what to test to make sure the product was made correctly.  Remember, at this point, we're not even talking about software design, just the content of the product itself -- not even code yet!

Of course, testing the product is a fairly large topic in itself as well and will likely get its own article.  Suffice to say, an acceptance test looks at a design, looks at a software product and then validates and verifies that the product is what was desired in the first place -- thus it is accepted as the product.

We will come back to game design on and off throughout the series.

*** Updated section ***
Originally, we did not post the game design here because it wasn't finalized, plus we didn't want the "spoilers" of the actual game getting out before we really thought the whole game through.  Since the product was posted, the finalized game design can be found here:
BubbleZing game design

This game design document was first linked when we released the product at the end of this series, but is now retroactively linked here for convenience.
*** End new section ***

Next up, let's start analyzing what kind of art specifications and styles we want to incorporate in the game.  Once our design was completed, we started toying with ideas of what it should look like, the theme, how to go about generating/acquiring the art assets.  So, next up is the design of the art itself.

Next - Art Design