"The Bread Pub Brawlers" - Postmortem

History

  "The Bread Pub Brawlers" is NiKo MaKi's first big game, but the founder's fourth. NiKo MaKi LLC itself consists of just one employee right now - that being the founder, CEO, artist, programmer, and designer - me, Nick Busby.
  Over the past 8 or so years I've worked under my own name as well as another company name where I created themes and avatars for game consoles including the Xbox 360 (where I started initially), PS3, PSP, and now PS4 and PS Vita.
  The theme and avatar market is something I've looked to get out of for a while, as it was never stable. Again and again I see the same cycle happen to it for each and every game system. At the beginning there is quick money to be made, but soon after (mostly because of the lack of quality control, I believe) things spiral downwards, which results in the profit you can make from this content not worth the time spent in making it - even if it were very little time invested.
  This always bothered me about this market, as well as how shallow it was in appeal. Since there is no gameplay (like a game has) usually the market's tastes devolve into wanting sex and violence (which I don't care to cater to).
  Knowing all of this for a while, I had been continuing trying to develop games (besides the 3 games I created for Xbox Indie Games). I tried out mobile but found out unless you already have a presence you will not have one at all in the mobile space. I was then able to sign up as a developer with Sony almost 2 years ago and have since completed this first game under NiKo MaKi LLC (and is what I'm here to really talk about), which is entitled "The Bread Pub Brawlers".
  As of the past weeks I have had communication with Nintendo and have had the opportunity for NiKo MaKi to become a developer for their platforms as well. If things go well enough on PS4 with TBPB (I'll refer to "The Bread Pub Brawlers" as this from now on), I hope to bring the game to the WiiU as well.
  So without further details, please find what following things went "right" during TBPB development and what went "wrong". And to sum things up, you can also find some lessons I personally learned.

What Went Right

Use of Unity

  When first starting work in developing for PS4, I had began by using Sony's Phyre Engine. Besides Unity, Sony offers this engine to developers for free. The support offered with this engine is also great, which is given by it's development team. Many times I would have an answer to a question very quickly, and even had one member remote connect to my computer to see exactly what might have been the cause to a problem I was experiencing!
  Although Unity doesn't offer this level of hands on support, it did allow me - as one person - to make progress in a project which would otherwise have taken me years to make myself in another engine such as Phyre. This reminds me of what one of the lead developers on Phyre told me when I got a chance to meet a few Sony Europe Devs in London - he said you could think of Phyre as a fast sports car. Without going into full context of the conversation, I'll just say I eventually found out I did not have the time to invest in utilizing such a machine, so I instead opted for something more standard - that being Unity.
  For a long while, however, I never considered Unity since I took it to be a tool for those who like using editors for creating games. I thought this would mean I'd have far less control over what I wanted to create. But, after giving it some time, I came to see this is not true. As one friend once put it - I finally "came to see the light of Unity".
  I'm still finding my way through it's design and structure (as you'll read about more in what went wrong), but overall Unity has made it possible for me to create TBPB, whereas without it, it could have taken many years (instead of just the 8 months it did).

Heavy Reuse of Art Assets

  With the past games I'd worked on ("The Perfect Match", "Red Box Reality: Fading Memories", and "Eye-Ball") I'd been told how my "presentation" had stood out. That was about it, though, as none of my previous titles had been very fun to play. All were either limited by experience, time, and/or money. With TBPB - my largest game yet, both in scope and production time - I've hoped to change this. In fact, it seems like I may have flipped things! This game seems fun and entertaining (atleast to myself and friends at this point - hopefully to others soon, too!), but it is also... lacking in polish, or in other words presentation. One of the major reasons for this was, even though I have Unity, it still would take much more time (and investment) to add to the mechanics of the game, which was the real focus and where all the development time went into.
  So, although the game's presentation and graphics are not up to my standard of liking, it atleast made way for producing a fun and enjoyable game - which, from my past experiences, I'd much rather than something simply visually appealing. This is a game after all, and not a theme or avatar (heh). It's meant to be played. So, I consider the heavy reuse of art assets as something that went right in the project. It made it possible for me to focus on the gameplay and make it into something enjoyable with the still limited time I had.
  I had purchased Maya LT for one month and created all models the game has in it in only a few weeks. I had determined early on I wanted something very flexible for me to use, when constructing the levels, so that even if I did not have access to a modeling program later in production I could still finish the game. What this meant is that I created very basic looking shapes, which could then be cobbled together to create more recognizable objects. This even went so far that the character themselves are made up of the same models the levels are! I had originally not planned for this, but found the need for it once I had to move on from modeling in that one month to later fleshing the character mechanics out more. It worked out better than I had thought it would though (although not ideal), and was a surprise for me during production which helped speed things up a lot.
  Another thing to note - About half way during production I had tried getting Kickstarter support to help increase the amount of time I had, to then improve the game in certain areas such as graphics and presentation. However, this was unsuccessful (mostly due to the continued lack of exposure). Thankfully the Kickstarter was not needed to start or finish the project, but it's unfortunate I did not have the means to do better in the areas of graphics and presentation. With that being said, I still believe this heading belongs in what went right.

Getting the Right Music

  For most of the project the game did not have any final music in it. I knew, though, that getting the music right would really effect the feel and energy of the game when playing it. During tests we could certainly feel a difference with and without music. And what became even more clear was that the music really needed to have vocals with it, too.
  Since this project is very low budget (consisting of myself as the only main worker on it) I was really worried how the game would turn out if I could only afford very simple and generic music for use in it. What it really needed was drinking songs found in Irish pubs. From the searches and contacts I'd made, this didn't seem possible to get for what could be given. However, late in development, a friend was able to produce something very fitting for the theme of the game using original music and public domain song lyrics (which were slightly altered to include references to the title).
  Having the right sort of music, especially for the theme I was going for, really either made or broke the experience. I'm happy to see this worked out as it did, and am very thankful to have a friend who could produce such! Perhaps the heading for this "what went right" should be "having friends".

What Went Wrong

Overuse of the Unity Inspector/Editor

  As mentioned earlier, Unity really made it possible for me to release TBPB at this point in time, or even at all. However, it seemed to make some things more difficult than I was use to. This may be partly due to Unity and glitches within it, but I believe most was due to my inexperience of using it to the right degree.
  Once coming to know more about Unity's inspector and editor I thought it would be useful to try and create very basic components to then do most of my work and tweaking in. However, I soon came to realize that it's very difficult to get a good overall view of what you're creating through the inspector alone. I'm thinking if I had time to create custom editors, it could have helped this, but instead I was using default views, having to remember the connection of references between objects and components for very minute parts of my game's scenes. Especially in the case of menus, this become an intricate web (and mess) which (I feel) took more time to make changes to and debug than if I were to have just kept it all pieced together in code.
  There were also times where references and values in the inspector would behave very... irrational. I still have not found out if this is because of my misunderstanding or misuse of them (as some times I would slightly customize the use of an inspector), or if these occurrences were bugs - not meant to happen. These cases included properties or references changing their values when the game began to run and having this happen on top of not returning the values after pressing stop. There seems to be no rhyme or reason for why some references and values would do this and some wouldn't, but I do know alot of these problems stemmed from the use of prefabs, and so, since then, I have stopped using them (atleast until I figure out what is causing these unexpected changes and reverts between playing and stopping the game). Or rather I should say I will use them, but then break the prefab connection once it's placed in the scene. In so doing it this way, it seems to prevent these changes of references and values.
  At any rate, these occurrences were the causes of most bugs found in the game, and I fear may result in more. What makes it really bad is that it is really hard to find these when they happen. You pretty much have to go through and watch every value found on a component to see whether it changes at play and if it then doesn't revert back after stopping - either being something that was not intended, and very likely will produce some sort of bug.

Not Abstracting Enough Code Away from Unity

  Pretty much everything made for TBPB cannot be reused for any other project. Not only that, but if the title needs to be upgraded to use Unity 5, there could be an untold amount of time needed in order to get it properly working again, and even if it does, it may not work the same way it did for Unity 4 (which is what it was created with).
  Why is this? One major reason is the differences in physics engines, which TBPB extensively uses in it's mechanics. Upgrading the game's project to Unity 5, without much of any changes, results in anything not static violently exploding. It's quite funny, and something I may put on YouTube eventually, but it's also sad to see. I haven't gone into too much inspection, but I'd say it would take more time than I'd like to take to get things properly working AND be balanced to mimic the way the game is working in Unity 4.
  Another reason for a not so easy upgrade is I've tied too much of the game directly into what Unity 4 uses, which may have changed in Unity 5. This is mostly the result from going from a prototype directly into production with the same code. Given I had little time, I was pushed to get up and running quickly, and continue this pace to a finished product. I never wanted to do such. I never have (as I always built some sort of my own framework along side whatever other SDK I was using). I knew it was going to bite me at some point, specifically at the end, down the road. But because of conditions beyond my control, I had to make rapid progress.
  In my next project (which has already started) I'm building my own sort of "engine" which will interface with Unity. This interface layer could also be easily expanded to include other engines or SDKs (like Unreal) but would protect my engine from needing to be updated or changed. The only problem I'm foreseeing with this method is the physics. Output such as graphics, sound, etc, do not necessarily need to be fed back into my engine. However, physics, which would be something I'd like to delegate to Unity, would need to be considered as output but then still fed back into my engine as input. That means translating the differences in data between the two systems to work correctly. Most of what I would be writing code for in a game, as an example, would be using my engine. This would then, in effect, make it much easier if I face changes or updates in SDKs or engines such as Unity.

Localizing Before the Proper Time

  I figured TBPB would be simple to localize, and it was such. Not much text is needed to translate and was purposely kept to a minimum to make this job easy. However, because of some changes toward the end of production (even during Sony's QA), there was the need for added or changed translations. These were few and important, but hardly justifiable to try and contact all the translators I'd hired before to translate such a little bit more. This would waste time and money (mostly time, which was important to negate in needing so close to the end).
  What was the result in having translations done before everything was locked down as content complete? It meant I had to go to Google Translate for help. Besides this I also tried reconstructing what translations were already made (while still, hopefully, keeping things correct).
  Instead of saying the problem was not localizing at the right time, one might could say not locking the content down at the right time was the true problem. At any rate, it makes it stick out in my mind that before translating, I need to know everything is certainly final - otherwise it will just mean added work for myself and potentially less accuracy and quality in the final product.

Lessons Learned

Knowing Everything Possible Prevents Surprises

  I've already known I'm a control freak in certain ways, but I think having as much control over what you are making (atleast mechanically and if you are working by yourself) you will have less problems arise. The system (or engine) I'm trying to make now will hopefully allow me to see every state my program is in AND explicitly make known what is in the realm of possibility for a state to be in.

Project Projection

  If I have a deadline I need to determine up front how much time I plan to dedicate to what portions of the development cycle. Do I want to stress and show off mechanics? Or do I want it to simply be beautiful? Most likely the results/quality in each area will be relative to the percentage taken from the whole project's duration, and not determined by actual time. So like I'm seeing the need for everything to be in - I want to consider percentages and not real numbers. Real numbers can be hard to meet, but percentages are always there.

About the Author

  Nick Busby is a self taught content creator with more than a decade worth of experience in art, programming, and design. To find out more about him, his company, and "The Bread Pub Brawlers", you can visit his personal website at www.nickbusby.com and his company's website at www.nikomaki.com.