A Pre- & Post-mortem: SoulFront back in pre-production

Long time, no talk. Since my last post, I moved out to San Francisco and started a job as an Associate Game Designer at Zynga, where I did a lot of Systems design, content design, engineering, and Unity prototyping. Unfortunately, I got hit with the layoffs back in January.

Since then, I’ve been spending a lot of time on side projects. One of them is a prototype game that I’ll write about more later. For now, it’s still very early in development and we’re still figuring out how the game should play. The other two, Marshmallow Mayhem and SoulFront, were senior projects at SCAD. Marshmallow Mayhem is nearing completion: I need to add analytics, and then it will be released on iOS and Android for free.


Coming to a phone and tablet near you, Fall 2014.

SoulFront has recently resurfaced with part of the original team. Since we had about a year to spend away from the game, we’re coming back with fresh eyes and realizing a lot of the errors we made with the game. In one way or another, we can pretty much improve upon every aspect of the game.


Back to basics.

As lead designer on the project, I’ve been focusing on redesigning the core gameplay, and trying to make the game more enjoyable. Coming back to the game after a while definitely opened my eyes to a few of the key issues we dug ourselves into.

One of the most common comments we received during playtesting was this:

“The game feels too slow.”

Everything effects the “game speed”. Movement speed and health of the characters, damage dealt, how long matches last. As a result of this comment we tried to tune as many things as possible that wouldn’t require us to redo tons of work. For example, the character animations would need to be redone if we wanted to change their movement speed. We got trapped in what, as some of my peers and colleagues have called, the “Fuck it, ship it” tunnelvision.

Now that we have the ability to go back and fix these things, it’s become abundantly clear what some of the key issues were, and what needs to change to make the game feel faster.

1. Overall Speed


It’s like molasses with legs.

Some All of our classes just move way too slow. The Knuckle Duster is our slowest class, and the speed of that character alone moves the game to a grinding halt. Even then, you have to wait for the character to rotate before they start moving. Oh, and there’s upwards of a 3 second delay between selecting a skill and having that skill activate. All of these are way, way too slow for a RTS-style game.

2. Class Archetypes

We originally based a lot of our character archetypes on some of the historic MMO classes, and took heavy inspiration from Team Fortress 2‘s class system. Two of our archetype choices just don’t make a whole lot of sense: the tank and healer.

Our Knuckle Duster played the role of the slow, but strong, tank and melee DPS class (similar to the Heavy in TF2, but only with his boxing gloves). Our Prospector was somewhere between a mage and a priest: Heavy AoE damage mixed with buffs/debuffs and heals.

In a mobile game where matches are 1v1 and need to be quick (read: 1-3 minutes) to hold player attention, it doesn’t make a whole lot of sense to have a tank/aggro-management class, nor does it make sense to have a dedicated healer. When the dynamics of gameplay boils down to “tank gets aggro on all enemies, healer heals the tank, third character deals damage”, it never yields a match that ends quickly, which makes the game drag on and stops being fun.

Numbers, numbers everywhere.

Numbers, numbers everywhere.

Of course, there’s much more to be improved upon, including simplifying the core mechanics and getting rid of a lot of the overly complicated stats and environments. For now, though, the biggest design improvement to the game will come from redesigning the base classes and making the game quicker, more unique, and more enjoyable.

Thoughts on Bioshock Infinite

Last week, after finishing up my final quarter, I graduated from SCAD. I have a whole slew of blog posts I still need to write to catch everyone up to speed on SoulFront‘s development, and I promise I’ll get to them very soon.

In the meantime, it’s time for something completely different! As is typical for me when starting a SCAD winter/summer break, I took a week after finishing up to do nothing but hang out with friends, relax, and play a AAA title, start to finish.

The AAA title I chose this time was Bioshock Infinite, the latest game in the narrative-heavy FPS series, created by Irrational Games.

Now, to avoid posting too many spoilers (or any at all), I won’t go too far in-depth with the narrative. I will, however, say that the narrative was incredibly well conceived. It had me thinking about the game well after I was done. I was on wiki’s, looking up charts and diagrams, reading other people’s explanations… and then I was still thinking about it and making connections while I was trying to fall asleep. It’s rare for me that I find a story that has been so intriguing, that I want to replay a game for narrative sake.



I thoroughly enjoyed the little bits of narrative scattered around, particularly with the Voxophones. I also really, truly loved the radios and kinetoscopes. Those two things really kept me immersed throughout the entirety of the game.


Welcome to Columbia

The art for the game is gorgeous. The characters are well conceived, the overall feel for the city is fantastic, and the artistic transformation during the game is wonderfully done.

My only real complaint on the art side of things is that I wish Irrational didn’t compress the hell out of textures with text on them. For example, in the cemetery, there were a lot of gravestones I wanted to read, but I couldn’t due to how compressed the textures were. It’s a small thing, but it really broke me out of the experience, to be honest.

My major problems start to come in when it comes to gameplay. I feel like Irrational dropped the ball on design pretty hard in a few spots.


While I know the game is an FPS, and is marketed as such, I have to say that the violence was a little much for my tastes. Yes, going into it, I expected blood and gore and bullet wounds and painful ways to die. But Bioshock goes above and beyond the standard FPS gore.


Melee Combat

First, let’s talk about the melee executions. From a design perspective, they’re worthless. In order to execute, you have to get enemies down to such a low health percentage, you could kill them with normal gun fire at any range. So not only did you have to be in hand-to-hand combat range with them (which, after the first half in the game, is a terribly bad idea especially with any of the armored enemies or heavies), but you also had to have them at a really low health point.

The only thing melee executions achieve are giving the player incredibly gruesome ways to kill an enemy. Shredding their face off, breaking their neck, scrambling their guts together… it never is really satisfying from any perspective. It was fun to do maybe the first time, and after that it became too much. It was completely not enjoyable to only have my melee weapon during the first bit of fighting, and being forced to execute the guards that were attacking me.


In terms of guns, there was nothing new. All of the guns were pretty much standard FPS fare: shotguns, machine guns, pistols, snipers, RPGs. I typically play the sniper class in FPS-RPG games, and Bioshock was no different. I ended up playing most of the game with the Sniper and the Hand Cannon (which essentially is just a glorified, powerful pistol).

However, an interesting design decision that Irrational made was the enforcement of a two-gun limit. Instead of having all guns accessible at all times, you were forced to choose between your favorite two, and dropping the rest. At first I thought it was an annoying decision, but I ended up appreciating it, and I can definitely see how it could add to the desire to replay, and also how strategizing in combat would have been deteriorated if I had access to everything always. During one fight in particular, I realized how attached I got to my sniper and hand cannon, and I really didn’t want to swap my hand cannon for an RPG, even for a small section of time.


Vigors concept art

Vigors is where combat starts to get interesting for me. Compared to Plasmids from previous Bioshocks, Vigors made me feel more like I was orchestrating combinations with my guns to have combat more dynamic. I felt like I had an incredible amount of control over the battlefield with things like Possession, Undertow, Bucking Bronco, and Return to Sender. And with Vigors like Devil’s Kiss, and Murder of Crows, I was constantly switching which two Vigors I had equipped.

That said, I wish there was more Vigors, or at least more interesting ones, or combinations that could create interesting effects. Devil’s Kiss, Shock Jockey, and (sometimes) Murder of Crows felt like more of the same, and I rarely ended up using the trap elements for any of the Vigors.



Combat on sky-lines was something I was really looking forward to, and ended up being disappointed on. According to Steam achievements, I ended up killing 0 people while on sky-lines, and killed 5 people by jumping on them while dismounting from the sky-line. There was no reason for me to try to fight people while on a sky-line, because it was so hard to aim and I didn’t gain anything from it (besides achievements). The AI of the enemies didn’t encourage me to stay on the sky-lines, either. Why fire (nearly) aimlessly at people while going 20 MPH on a metal rail, when you could just dismount and get the job done quicker and safer?



Boy of Silence

I feel like there was a serious regression in the enemies in this Bioshock. Every enemy had one “spot” they were weak, which, for all intents and purposes, was the head on everyone except the Handyman, which you pretty much could only damage by hitting their heart. Point being, there were no enemies that caused me to play the game in a different fashion. Everything was “shoot until dead”, and nothing else, which got incredibly repetitive fast.

The Boys of Silence had this incredibly interesting story and design, and I was really looking forward to fighting them after seeing them in whatever trailer it was that showed them off. Needless to say, I was quite disappointed. The combat design for these guys completely contradict the character design: they’re supposed to have increased hearing senses with no sight due to those helmets, but in-game, they can’t hear you at all, they can only see you with a spotlight? Not sure what happened there, but a really interesting character pretty much got turned into a creepy, human security camera. And instead of fighting the actual Boy of Silence, you just fight their slaves, which is more of the same point-and-shoot-till-dead.

I think this issue was further exacerbated by Elizabeth. While playing the game, it was handy to have her constantly give you ammo, salts, health, whatever you need. But the fact that she gave me stuff anytime I needed it really hindered my overall experience in the strategy department. The problem of “shoot till dead” was only made worse by Elizabeth essentially sitting the background screaming, “Hey, shoot them more! Here! Go get ’em.”


While I wouldn’t say Bioshock Infinite is an interactive movie, it definitely felt like an on rails experience. Cutscenes were blended really well into gameplay, which I like. However, the game had very few optional quests (I think I ran into a total of 3) and all of which were “get the key for this treasure” or “get the cipher to open this treasure”. I tried to make it a point to go into every room and unlock every treasure before I went into the next area, but it still felt like I was being guided from room to room, with only one real solution to any one problem. I wish there was more variation, or at least the ability to solve problems in more than one way.
However, I must say that Irrational did a great job with reusing levels multiple times, and making it not feel repetitive.

There was a dialogue in the game that said, (paraphrasing) “Not everything needs to end in a fight.” I laughed, because up until that point, the only thing I could do was fight enemies. And after that, I gave people the chance to not attack me, but they did anyways. The concept of “some enemies may not attack you because they have no ill will towards you” is interesting and something I wish Irrational explored more, but it falls flat when literally every person in the game is either dead or shoots at you.


Pipe dream hacking

That being said, THANK YOU for getting rid of that god awful Pipe Dream mini-game that was hacking. Trimming it out and just having Lockpicking from Elizabeth was a fantastic decision.



I really enjoyed being able to build my character how I wanted to play him with the use of various pieces of gear. The Overkill gear piece in combination with my sniper really made things a lot of fun (though for a while, things were really easy). I’m also a huge fan of the “not a straight upgrade, just a variance in playstyle” gear economy. I mean, just look at SoulFront!


Carnival Game tutorials

Also, A+ for integrating the tutorial into (optional) carnival games. Not only did you not force the player to deal with unwanted tutorial sequences, but you disguised them in such a way that learning the game was enjoyable. Honestly one of the best FTUE’s I’ve seen. Well done.

With all of that being said, I definitely did enjoy the game, even if it was primarily from the narrative (and I am not typically a narrative game kind of guy). Even though the first few DLC will supposedly be focused on narrative, I hope they will fix some of the design problems that are in the game’s current state.

Getting caught up part 2: Second Weapons

So the second thing that has been implemented for a while, but I didn’t post about was the secondary weapons.

Since the beginning of the game, the team really wanted to focus on something similar to Team Fortress 2’s weapon economy: where a weapon isn’t a straight upgrade, but rather, a change in playstyle. As such, this has been a key design philosophy that we’ve stuck to.


Gunslinger: Weapon 1


Gunslinger: Weapon 2

So as of right now, each unit now has two different weapons they’re able to choose from, but we’d like to increase that number (though it was suggested that instead of characters and weapons, we just focus on more characters… but that’s a different blog post). I’ve talked about our 1-to-2 skill system before, where each unit has a “core skill” that sticks with them, and the other two change out with their weapons.

As mentioned above, the weapons are balanced with each other, and cater to a different playstyle. For example, the Gunslinger has a weapon where he can buff his allies up with safe abilities, or play a little bit riskier and utilize his glass cannon archetype with his second weapon.

Some of the classes are more obviously different with their weapons. For instance, the prospector has two very specific weapons right now: a healer staff, and a caster DPS staff. Again, we’d like to add more weapons later to try to dilute that differentiation a little bit more, to cater to more interesting playstyles.

As expected, the feedback we’ve gotten since the implementation of the second weapons has been incredibly positive. The customization aspect of the game is much stronger now, and players seem to have a pretty even distribution of which weapon they choose for their units.

Getting caught up: New squad textures.

So this post is regarding a few things that we’ve had in the game for a while, but due to other, more prevalent topics that I needed to write about, these got pushed to the sidelines and forgotten a little bit.

First things first, we’ve changed our squad textures around! Originally, we had a basic set of textures for our characters, but due to limited time and limited resources (two artists), we didn’t want to create a second, special set of textures for our enemies. As such, we had a temporary placeholder, so there was at least something to visually distinguish between your squad and the enemy’s.



This was fine as a placeholder, but as we got closer and closer to our “ship” date for our gold build, it’s another task that needs to be handled. As such, we picked an easy solution that, both still easily distinguishes teams from one another and was easy on the artists, as well as being more aesthetically pleasing as the red texture. As such, we picked a red and blue team coloring that was simple enough that I could do it in an hour or so.

So this is where we are today:



Since we had red and blue naturally in the character textures, we decided to break them up into red and blue teams, and then simply change the color of the items that were red and blue. As mentioned above, this gives us a very nice looking texture, while still visually differentiating the two teams from one another (not to mention, in a very obvious manner).

When you focus on one thing, you forget about another…

So. I feel like a broken record anytime I talk about Draw Calls on here, because it seems like I mention them at least once per blog post. So let’s talk about something a little different: polygons.

Now, while draw calls may be a little more on the abstracted side of things, polygons are something that most people have their head wrapped around, and game designers are trained to make the poly count as low as possible, without sacrificing too many details. However, on mobile, there’s a weird balance that we need to master: quality of models vs art that is too heavy for the tablet or phone to handle.

For a while now, we’ve been so focused on draw calls, and we thought that lowering the draw calls was our only concern in terms of optimization to make the game playable. However, we’ve come to realize that it’s more than just draw calls: it’s also the poly count. Between our higher-poly-than-needed models, how many models are visible at once, lack of using Unity’s LOD feature (which means we’re keeping high-poly models on screen at all times), and our shader which requires multiple copies of each models in the scene, we’ve run into a performance wall. During playtests, the game runs at as low as 8 FPS, and the game frequently hard-crashes after any extended play.

To figure out where things are going wrong, I went through and disabled folders of game objects to see where all the polys were coming from.


Whole Scene

 To start things off, let’s look at the whole scene, which clocks in at 367.6k Tris and 248 draw calls. Both of these numbers are obscenely high.


Without characters

Next up, the scene without the characters. This dramatically brings the stats down to 73.9k Tris and 39 draw calls. This means ~80% of the entire scene’s poly and draw call counts come solely from the characters.


Without bars, pipes, table

Next, removing one of our prop sprite sheets, which includes the bar, pipes, and table. This drops it to 64.7k Tris and 25 draw calls. Not a huge difference in comparison to the characters, but still quite significant.


Without beams, shelves, piano, poker machine, stools

Another prop sheet, including one of the most used props used throughout our scenes: the stool. This brings things down to 52.3k Tris, and 22 draw calls.


Without crates, barrels, slot machine, half the bottles, mugs

This is the highest poly count prop sheet, dropping things to 21.2k Tris and 19 draw calls. We also use the bottles and mugs quite religiously in every scene we have.


Without decals, liquor cabinet

This is the most minor of the prop sheet poly counts, bringing things down to 20.3k Tris and 16 draw calls.


Without TV, other bottles, dart board

Another mid-range poly count sheet, bringing things down to 9.1k Tris and 13 draw calls.


Without vents

And finally, the vents. 1.4k Tris and 9 draw calls. Not a huge difference when compared to other prop sheets, but since it is JUST the vents, it’s definitely a lot.

So wait. Wait. Wait… Why is there 1.4k Tris when only the floor is visible?


Without floor

With the floor hidden, we’re reduced to Unity’s most basic form, with 2 Tris and 1 draw call. So that means the floor is using 1.4k Tris and 8 draw calls? The floor is a basic plane, the hell is up with that? Well, I found that we had an extra copy of the floor we didn’t need anymore, but that still left 700 unaccounted-for Triangles.

Through this exercise, I discovered something I didn’t expect: Unity’s primitive plane has 700 triangles. Upon discovering this, I turned around, opened Maya, and immediately exported a 2 Triangle plane to use on all my scenes.

Why you would ever need a 700 Tri plane is beyond me.

So, after all is said and done, what does this all mean? What did we find out from this? And where do we go from here?

  1. Character mesh polys need come down. WAY DOWN. And they need to be merged meshes to put the nail in the metaphorical draw call coffin. Tre just completed the new meshes for the characters, and brought them down by 90%. He also went ahead and redid the rig, and used the same rig between all characters. This will reduce the CPU power needed to render the animations, since he got rid of a lot of controls and joints we didn’t need, on top of reducing the amount of influences on each joint. However, this also means that all animations need to be done from (pretty much) scratch, since the old rigs are not being used anymore.
  2. Props in general need to come down in poly count, but most importantly the props we use most: bottles, stools, tables, etc. All of the props are getting a poly-reduction pass now, and Keren has given me some lower poly models to start plugging in.
  3. Never use a primitive Unity plane unless you, for some reason, want the most detailed floor plane ever.
  4. Live lights (aka, lights that aren’t just baked into your scene) use one draw call PER MESH they’re affecting. As such, they increase in an exponentially increasing rate. Less draw calls to begin with, the fewer draw calls will be created from lights in the scene.

So hopefully this post was helpful to people who are looking to optimize their games. Since my role of producer is beginning to require my time to create game websites, online presences, etc., I’ll probably begin posting about the other projects I’ve been working on, not just SoulFront.

But until next time, stay classy.

Level creation and light map optimization.

After being sick for a week, lots of SCAD events, and dealing with many optimization pitfalls, I’ve been falling a little bit behind with my target blog activity. Let’s fix that! This post is from a few weeks ago:

First things first, we’ve been making more levels to experiment with. Our level designer, Adam Powell, has come up with a lot of more complex, interesting designs and we’ve been giving him a lot of feedback on them. While he’s been cranking them out, I went ahead and rebuilt one of the more simple examples that he gave me in Maya, because it struck us as interesting.


Diagonal symmetry is something that is pretty common in the level designs of other RTS games, such as Starcraft. This is something we haven’t experimented with in any of our other levels, so I decided to throw it together in Unity and give it a whirl.


We need to begin playtesting this level ASAP because I do believe it will lead to very interesting combat, between the bottlenecks and the non-linear pathways to get to the opponent. However, our priority has recently been focused on optimization… more on that in a future (much longer) blog post.

In addition to level creation, I revisited something I kind of set the values on and forgot about optimizing: light maps.


Settings: Before


Settings: After

After reading about how to properly utilize light maps, as well as researching how Shadowgun went about light mapping their mobile scenes, I significantly tweaked the light map settings.


Performance: Before


Performance: After

As you can see, the performance change wasn’t especially huge. However, it’s still an improvement, and any bit helps! The physical memory the light maps occupy went down quite nicely, as well. Because of that, our load time when switching platforms went down by a huge amount: a few seconds compared to upwards of 20-30 minutes. That definitely made the tweaks well worth my time and effort.

And yeah, about that Tri count in those Performance screenshots… consider that foreshadowing to one of my next posts.

A quick optimization test: Investigating Draw Calls.

So lets discuss our draw call issue.

Draw Calls are called when Unity needs to paint a texture onto a mesh. The issue that we were having was that each piece of each character was separated, so we were getting over 150 draw calls for each character.

Through a simple test, we were able to find out a few things.


We took a single cube in Maya, and imported it into Unity, and placed it in an empty scene. Unity, by default, uses 1 Draw Call to paint the background, and then THREE (not 1) for each mesh that has a texture.


Then, we took that same cube and duplicated it in Maya, created two separate meshes. We then reimported it into Unity and the blank scene. This resulted in 7 draw calls: 1 for the background, and 3 for each cube; this was the expected result, so no surprises here.


Then, we wanted to see if a simple Maya “Mesh -> Combine” would be enough to make Maya things play nice while reducing draw calls. After combining the two cubes in Maya and reimporting, the draw calls went back down to 4. Therefore, we were able to conclude that combining our character meshes will reduce draw calls and fix a lot of our performance issues.

Last, but certainly not least.

I am back from the dead! A single week for Spring break followed by two incredibly intense first weeks back leads to a very inactive blog. My apologies.

This quarter will be my final quarter at SCAD, after four long years of personal growth, both as a designer/developer, and as a person. This quarter will also mark the end of another successful Senior Studio cycle (if I do say so myself). Project Prisma is looking better and better each day with the guidance of their incredibly talented team, and Stephen’s Biobits project is definitely going to amazing places.

As such, for this quarter, the Napkin Western (name soon to change) team is focusing on finishing up the game, making things super polished, and getting the game some well-deserved attention on the web and with some gamers. The name of the game this quarter is Senior Studio Postproduction.

We have a few major focuses this quarter, and some features that slipped out of our hands before our beta build was due:

1. Techwitch Implementation


Keren’s Concept Art for the Techwitch

Last quarter, the character was concepted, modeled, and her skills were designed, but we ran out of time before we were able to rig, skin, animate, and implement her. One of the first tasks for this quarter is to remedy this, and that actually should be completed within the next week or so.

2. Second weapon

The second weapons for everyone have already been designed (by yours truly), however we ran out of time to actually implement them into Unity. This is in the process of being resolved, and should be completely fixed by the end of the week. However, the artists are working hard to concept and model out the weapons themselves, and those will be implemented somewhere closer towards the middle to end of the quarter.

3. Networking

Robert has been slaving away at scripts since the game began, and this quarter doesn’t look to be much different. One of his first tasks for this quarter is figuring out Networking, and the first pass of this should be done in the very near future. Obviously, this is also something that will require a moderate amount of tweaking to get perfect.

4. More Levels

Adam has given us some great concepts for levels that I’ve been putting together (a blog post with all that is soon to come!). He’s going to continue to work on level designs, and Tre will be creating a few more environment props (mainly outdoor props) to open up some possibilities for different environments. The various saloons may get a little bit boring and stuffy after a few hours of play.

5. Tutorial

We definitely need some form of a tutorial. We’re looking at an on-rails experience, guiding the player through the ins and outs of the game. The controls should be rather intuitive, but still could be intimidating, especially to someone new to mobile games. As such, this tutorial is our next task to conquer.

6. Animations

With a new character, comes new animations. The Techwitch is going to need come to life! In addition, our three existing characters will need a Dazed and Victory animation, which is a pretty hefty workload. And finally, some of our current animations need a little bit more work and polish to make them really become amazing. To make sure this task is possible, we’ve obtained the assistance of two fantastic SCAD animators to help us out.

7. UI Art

Most of our UI is really nice, but after some playtesting, we’ve come to the conclusion that our Customization UI could really use a redesign. We got some fantastic feedback and will look into making it more intuitive (see future blog post). In addition, we need to create a Networking and Settings UI, as well as a credits screen.

8. Sound Effects

Our sound designer/composer from Berklee, Miles Flanagan, has done a fantastic job with the music track, sound effects, and voiceovers currently in the game. However, we simply need some more! He’s going to continue his work on all the various sound effects and voice overs that we need for the game.

9. Texture/Lighting polish

Some of our environment textures need some tender love and care. Keren will be working on those a few weeks from now. Also, the lighting for our scenes is really not well done. That’s what happens when the designer creates the lighting! 🙂
As such, we’ll be going back and making the lighting much better, first by getting someone who actually knows what they’re doing (probably Robert, possibly someone else).

10. Optimization

As mentioned previously, we ran into a serious issue with Draw Calls towards the end of the quarter. I am happy to report that we have resolved this rather big issue, through the power of scripts! (see future blog post on this topic)

11. Promotional Material / Web Presence

One of my main tasks for this quarter is to create more of a web presence for the game, and create promotional materials. This includes a twitter page, a facebook page, a website, linkedin project, business cards, etc. and linking them all together.

While this list does look rather long and daunting, I believe we have the willpower and the capabilities to blast through it all and successfully deliver a quality product at the end of the quarter. Don’t believe me? Well, you’ll just have to stay tuned to find out!

Playtest results and finding a huge performance problem.


Another week, another successful playtest.

Hello everyone! This is finals week here at SCAD, so I’ll try to keep this post short and sweet. Today I’ll be talking about the results from the playtest a few days ago, as well as a serious performance issue I discovered a few nights ago.

First things first: playtest. We had the best turn out we’ve ever had for our playtests, and got a lot of really fantastic feedback.

ImageI believe this was the biggest “mobile gamer” group we’ve gotten, so this is definitely a bigger sample of our target audience than previous playtests have given us.

The main things we playtested in this build were as follows: Realtime combat (instead of pausing when selecting a character), squad customization (how many of each unit in your 3-unit squad) and the UI for that, and a second, larger level.

ImageOverall, people seemed to enjoy the game. They thought with realtime combat, things didn’t last long enough, and the game got harder. However, I believe the 3’s and 2’s were a result of the bugs that we had (also the performance issues, see the bottom of this post)…


… and the character customization menu. People didn’t think the menu was intuitive enough, and most people couldn’t get through the menu without some assistance. Since the playtest, I’ve implemented many changes to the feedback and general flow of the interface, so I’ll test that out and get some feedback.

ImageOur art continues to be a pretty successful crowd pleaser. People really like the characters, the environment props, and the cel-shader that Robert created.

Now, let’s see what people said about the squad customization!

ImageThere’s a significant amount of variance, but there’s also an overwhelming amount of “3x Gunslinger” squads. Is this an issue? Well, yes and no, and here’s why. It IS an issue because the Gunslinger is slightly overpowered as of right now. I’m definitely going to go back and do another balancing pass over spring break and the beginning of next quarter.

However, it’s also NOT an issue because of how our new second level is designed.

ImageAs you can see, this level is specifically ACCOMIDATING to the Gunslinger class, or ranged classes in general. There’s a significant walking distance before getting into combat (both squads start on the top corners), and the ranged classes have the advantage of being able to start attacking once they get to the top of the bar, rather than having to walk all the way past the bars to start throwing punches.

Speaking of levels…

ImageThe main thing people said was that the levels seemed visually boring, and there wasn’t enough of a story or visual interest. This is a fair point, and I’m working with Adam Powell, our level designer, to make these levels more interesting. The other thing people said was that there wasn’t enough incentive to move around and use the environment to their advantage. This is definitely something we need to fix, and we’ll work on more iterations of levels next quarter.

And now, let’s talk about skill icons.

ImageThis is actually incredibly interesting, because the last few playtests, it’s been almost unanimous that the skill icons WERE intuitive. Obviously, it will help to have the descriptions for each skill displayed in game, but we still want the skill icons to be pretty easy to understand. Most people had issues understanding that the Bourbon was a heal and the Pocket Sand dealt with lowering accuracy. To fix these, we’ll be adding a red cross to the Bourbon, and coming up with a new name and icon for the Pocket Sand.

Now, for those of you that have been following this blog, you’ll realize that the next thing I’m about to talk about is a continuing issue: the Knuckleduster.


Not enough people like to play with the Knuckleduster.


People don’t think the Knuckleduster looks cool.


And people just flat-out don’t like the Knuckleduster. They say he looks generic, he’s hard to control, and he’s not appealing to play with. While there’s not much we can do about his mesh with our remaining time, we can try to make his texture more appealing, and making him more powerful. We’ve been talking about the ability to make his autoattacks have a chance stun his enemies, so that may be something we fiddle around with. Also, in general, making his autoattack hit for more. In addition, the weapon he had equipped for this playtest was primarily a “tank” weapon. People may find his DPS weapon to be more enjoyable to play with.

Also, there were a few comments about the Prospector. I think his issues of “not healing well enough” can be fixed by making the healing particles more obvious (and also giving him more particles in general), and possibly making the Family Bourbon a straight heal instead of a HoT (or giving it a nice heal burst at the start, and then having a residual HoT afterwards).

And now, finally, let’s discuss a serious issue that’s plaguing the mobile games community:
Draw Calls.

For those unfamiliar with draw calls, here’s a quick overview. Every mesh that gets a texture calls 1 draw call. The newest iPad handles about 800 draw calls before it starts crashing, and obviously older devices handle much less (the lowest device we’re looking to support is probably iPhone 4-era). I know this doesn’t sound like it should be an issue, but draw calls quickly stack up, and you they can sneak up on you. Especially when you’re inefficient without knowing it.

In previous posts, I’ve written about how I’ve been dealing with compressing textures and working with our lighting to try and fix. I was under the assumption that these were the sources of our issues. However, while working the other night, I discovered something very interesting.


Draw Calls w/ Prospector: 349


Draw Calls w/o Prospector: 216

Our characters take up over 100 draw calls. EACH. That means when all 6 are on screen at once, it’s calling over 600 draw calls, just for the characters. Combine that with our environment and particles, and you have yourself our performance issue.

The reason all these draw calls are being created is because our character meshes don’t have their geometry combined. So, Unity imports these pieces of geometry as separate, and then treats each separate mesh that receives a texture as 1 draw call.

The fix for this, obviously easier said than done, is to Combine the character meshes together. To do this, however, we have to go back, Combine the meshes, reconnect the rig, and transfer the skin to the new, unified character mesh. Definitely our first task for next quarter.

More skill design and character customization.

Hello everyone! Time for another Napkin Western update post from yours truly.

Let’s get started! So, one of the first big things I focused on this week was finalizing our first weapon set skills, and doing the first pass at balancing all of the new skills for our new set of character weapons. Unfortunately, through this I realized the formula I was using for balancing is not quite accurate anymore, as we added a few new status effects that can be applied, as well as the simple gut feeling things aren’t making as much sense as they should when going from spreadsheet to implementation in the engine.


Spreadsheet screenshot.

Over spring break, or the first week of next quarter, I’ll go back and fix my formula, and I’ll do a deconstruction on it via blog post when I complete it.

With these new skills, I put placeholder icons and prefabs into the engine. This allows us to save lots of time when we’re more stressed out next week: as Keren completes the icons for these new skills, all I have to do is overwrite the icon outside of Unity, and everything will magically work; the spritesheets will be repacked, and will update everything that branches from it.

The next big project I completed this week was the implementation of the Character Customization stuff. This included plugging in Keren’s art, connecting the buttons, and making the script to handle user interaction.

This started by creating a sketch for Keren to go off of when creating the interface art.


My love for using copic markers for UX/UI stuff is outlandish.

Keren then used this to frame his interface art, and created something really, really nice looking.

I then took all of those layers in Photoshop, exported them out separately, and reassembled things in Unity. I also created placeholder icons (again, so new icons and just be plugged in as created and simply work) and selection indicators. The thinking for the indicators came out of playing with the interface as I was plugging things in; I hadn’t originally thought about it.


What it looks like when you first get into the menu.

After making your selection.

So, it’s coming along really well. I made it pretty robust so you can’t do much to crash it (well, at least anything I tried didn’t break it). I also left very simple and obvious hooks for Robert to plug his scripts into (for networking and squad instantiation), so things can move along very smoothly. I still need to add some of the polish factors, but I’d say it’s about 85% complete.

So that about concludes it for this update, I believe. We’re on week 9 right now, with out Beta build being due next Thursday (March 14). We’ve got a lot of things to do before then, but hopefully with enough blood, sweat, tears, and maybe some luck, we’ll be able to get things rolling and have a fantastic build to show off. Once character customization is completed, I’ll be focusing my energy on getting our game ready for the playtest session this Thursday evening. Afterwards, I’ll be creating a (first pass of the) demo video/trailer for the game, as well as updating our Powerpoint.

See you next week!