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

Vector Graphics in Photoshop - "Free Mouse" Drawing

The History
Over the past 15 years or so, I've used Photoshop almost daily. You'd think I would know alot about the software, saying such, but I generally only learn what I need to for my projects, so I'm no "Master". However, as of the past few years, I've increasingly drifted away from my usual process of starting an illustration as a sketch on paper, using pencil, and have instead started my works directly in Photoshop, using it's Pen tool.

This post is to share what I've learned so far from doing this over the course of a few (or maybe more) illustrations, as well as my method of doing it.

The Benefits
If you can cut a step out of your overall production process - especially if you are doing multiple pieces which need to be coherent in style - you'll save alot of time in the end and improve the consistency of your work. An example of this, for myself, can be found in a set of Line Stamps I had created, which can be found here... Line Store

To submit stamps to Line, you have to have 40 (yes, 40!) images which share a general theme and convey a range of emotions (since they are glorified emoticons, essentially). I was hesitant to try this at the beginning. First of all, it would be the first project of mine which would require such consistency in style and characters that I've ever attempted. Second, I'm not an animator for such reasons as "I hate repetition". To think I have to draw the same things 40 or so times frightens me, to say the very least. One such boring task, even if not having to maintain a certain style, would also be having to sketch something 40 times and scan each into my computer (some may can just sketch directly into a PC now, given tablets, but I've yet to make myself comfortable in doing so). So I needed to think of the fastest way to get these characters out of my head and into a finished illustration.

I had drawn some of my Avatars for Sony by using only the Pen tool in Photoshop before (see here... Sony Avatars - some include "The Masked Flame" and "Dream a Little"), but not so heavily, or for such details as found in my Line Stamps.

So to sum this part up quickly, here are some of the benefits I've found in working directly with vector graphics using the Pen tool...

1. Speed (it's always good to get things done quicker)

2. Consistency (you can easily tweak things, like outlines or colors - more on this in "The Methods" below)

3. Inspiration (for some reason, I can get clearer ideas - especially when it comes to cartoon characters - when using the Pen tool rather than sketching by hand. Exaggerations and proportions of shapes seem to come more naturally, for something cartoonish, when you can adjust the lines so easily; or shape them in the ways the Pen tool allows)

The Methods
Here is a quick breakdown of the steps I take when creating completely vector graphics in Photoshop using the Pen tool...

1. Based on the colors and sections of a character/object, and how they overlap, I create separate folders/layers for each. Usually I start with the most focused on part of the character (usually the body section) which all other parts align to. This doesn't always have to be the center most piece, but generally tends to be for human like characters. Basically, the most eye catching part of the illustration should be positioned, scaled, outlined first (this can always be adjusted easily later, if need be, though).

2. Give every single "piece" its own folder, where you then apply the "Layer > Vector Mask" to. Then, on a Photoshop layer inside that folder, fill it with the base color for that object. If the object has sub parts which are different colors, or requires major differences in shading, then create another folder inside it. It's common to have such nesting like this, but may start decreasing Photoshop's performance depending on how deep the nesting is or how fast your PC is. Use your discretion as to what needs it's own folder, or can share space in a folder and/or on a layer. However, keep in mind the more separate the better - especially for tweaking or needed revisions.

3. Depending on the style of your illustration, shading may or may not be required. If needed, shading can alot of times be carried out just as the base colors can, as described earlier, but for shadows and lighting. This is particularly fast and efficient when dealing with shadows/lighting because you can easily disregard staying in the outline of the object, since you are creating all these shadow/light layers in folders WITHIN the base object's folder. If your illustration requires more of a smooth gradient effect for its shading, you can still use the same methods described, but instead of using a Vector Mask on a folder, instead use a regular Layer Mask. If your shading style doesn't require crisp lines, it's okay (from my experience) to use these regular masks for raster graphics. Even if you were to want to increase the size of your picture later, seeing as they are smooth gradients, you generally cannot tell a loss in quality.

4. As for the Pen tool itself - it's efficiency really comes down to practice. I might create another post in the future (if there's enough interest) going in much more detail on the subject, but the previous methods are the most important for production. I could probably give a few pointers, but the quality part; really I think that depends on your own skill, of which I consider the Pen tool requiring more than a method in itself. And to get such skills (as for myself atleast), I would say to simply use it often.

The Final Results
Below are a few samples showing graphics which I'd created using the method I've described.

Thanks for reading. If you have any questions, please leave a comment.

Are there VR "Sweet Spots"?

There has been talk of how the time is now for VR. Many have expressed (from the coverage I've seen) how the current VR systems really do allow for immersion. Since so many have been expressing this opinion, I thought it was fair to say it was something to be impressed by (even if a little).

When I got my chance to try VR for the first time, though, I (as much as I hate to say it) felt very differently from most people. The only immersion I could really sense was that there had been a small screen strapped extremely close to my eyes...

However, even with myself feeling this way, I could still see where VR had possibilities, some of which I wanted to try finding myself. So with that interest, and the ability/opportunity to develop for a VR headset, I started on a project.

During this current project (which I've tested in VR) I continued to feel less than "immersed". But there was a change recently - a surprise - I felt something! This feeling I had, I believe, is what people are touting as "immersion".

I still don't believe what I felt was that grand, but it was a lot more than what I had been feeling. This was gotten only through visuals - no sounds. It was in one small area of a level I had created for a game. I was looking in a specific direction. If I happened to be located and facing in such a way, I would get this feeling. It would quickly break if I moved out of such a location and orientation.

So what does this mean? Personally I take it as meaning VR is like anything in the "real" world of ours - it's just not as "real" to us. We all have different perceptions of reality. Some moments in life (due to different cues to our senses and how we think or perceive things already) stick out or hit us harder intellectually or emotionally. Some people can get "immersed" into different mediums and presentations within those mediums easier than others. A fair amount of people can get motion sick from things which others don't. It's all the same thing - whether we're buying into what are senses are telling us, or not. However, that doesn't mean I'm saying there are just two states to be had in VR - "immersed" and "not immersed". It's a scale, but if you were to then have to decide on which side this degree of "realism" you are feeling falls on, you'd either "buy into it", or "not buy into it".

So the bottom line I see; just like in our own "real" lives - some people have a harder time in believing that something is "real/true" than others. And what makes us think something is "real/true", and in what area, is different for everyone.

I could probably ramble on further about this (and maybe will in the future). But, for now, I'll sum up by saying... I found a "sweet spot" in VR. I was just looking at some stairs, a few chairs and tables, with a wall at the opposite end...

(it's not even finished, too - look, there are textures which were placed on models that don't match the UVs!) but something about that particular view made me believe what I saw was apparently more "real" than any other view I've happened upon in VR. For others, maybe the life-sized bread man in the middle of the room would have made them feel more "immersed" (but that's another story for the future).