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!

Unity’s lighting quirks and design of weapons/skills.

Hello all! I hope everyone had a productive, fantastic week. I actually went on a vacation to Lake Tahoe/San Francisco over this past weekend, so apologies for this post being a few days late. There will be another blog post regarding playtest results in the next day or two, so keep an eye out for that!

However, lets get started on what THIS post is about: lighting and design changes.

So I’ve struggling for a while as to why we weren’t getting any live lighting on our game. In the engine, it was working fine. However, when I pushed the build to our devices, only the lightmaps transferred (there was no live lighting, only static shadows from the environment).


I found this issue fairly quickly, and it was a simple check box that either got overlooked or somehow unchecked. Everything EXCEPT the floor was marked as “Lightmap Static”. If an object isn’t marked as “Lightmap Static”, it won’t accept shadows from lightmaps or live lighting.

The second issue, however, was more in-depth and took longer to solve: there were no shadows on the floor from the static environmental props.


Quality Settings (located under Edit -> Project Settings -> Quality). By default, Unity chooses the “Fastest” quality setting for all publishing platforms. This is great for getting things working smoothly, but not great for making things look good and aesthetically pleasing. By going into the settings and allowing shadows, changing shadow distance, and deciding what kind of shadows from which lights that we wanted, we now have a first pass at live lighting! (Also, protip: the arrows on the bottom of the check box matrix is how you move the green selection. Fantastically bad UX!)

However, the first time I pushed the build onto my iPad, a noticed that, even though I put “Soft and Hard Shadows” on the quality settings, only hard shadows were visible, and they were super jagged. I did some research and changed Shadow Cascades from “Zero” to “Two”, and changed the Shadow Projection from “Stable” to “Close”, and the jaggedness went away immediately. However, I was still having an issue with only seeing Hard Shadows, and zero soft shadows.

One of my biggest, BIGGEST gripes about Unity is how they have the same options tucked away in multiple places, and they have really important notes about their system hidden away. Case and point:


Quality Settings


Directional Light: Inspector Menu


Area Light: Lightmapping Menu

Now, theoretically, any options that overlap with each other should be condensed into one menu option. However, since they weren’t, I went through and made all the options the same for each light. I ASSUME that the quality settings is the lowest common denominator, as in all other settings filter through the Quality Settings (if something is a higher resolution than the quality, then it’ll be knocked down to what the quality says). It appears that’s not the case, though. I’m unsure what exactly happens in the black box behind Unity for lighting.

And finally, after many hours of troubleshooting, I came across this gem on Unity’s documentation site:

ImageNot only was this tucked away into a small corner page (not shadows, not lights, not directional lights, but directional lighting shadow details), but why give us an option if we’re not allowed to use it? The quality settings for Mobile were marked as “Hard and Soft Shadows”, but soft weren’t showing up because mobile doesn’t support soft shadows.


The other side of this post is about design, so let’s discuss that really quickly.

As I mentioned previously, we are moving our weapon designs from “give 3 unique skills” to “give 2 unique skills + each unit has a base skill they keep regardless of weapon choice”. I’m calling this the 2+1 skill system. There were a few reasons behind the change. One was so that each unit could keep a skill that represents their role in the game, and with that, we can have weapons give added bonuses, effects, or skills that only trigger when the base skill activates. This allows for a lot of interesting multi-layered mechanics. Also, this allows me to avoid the possibility of a class accidentally falling out of it’s intended role.

My first pass at the base skills are as follows:

  • Knuckleduster: Lasso (bring enemy into melee range, then punch them in the face)
  • Gunslinger: Rapidfire (unload many attacks – great for blitzing down a unit)
  • Prospector: Family Bourbon (heal over time – a necessity for our healer)
  • Techwitch: Barrier (TW is our nullifier class, and I have many interesting effects for our barrier skill)

In addition, this allows us to trim off 4 new icons that we would have otherwise needed, and since the art team is currently well overloaded, I’m sure Keren appreciates that!

With this, I’ve devised a simple framework for me to follow for our new weapons. For example, the Knuckleduster will have a tank weapon and a DPS weapon. The Prospector will have a healer staff and a mage/DPS staff, and so on.

This quarter is quickly coming to an end, and our beta build is going to be fantastic! I’m incredibly excited about it.

Again, expect a short post about playtest results soon. Hope you all have a fantastic Sunday and a great week.

More playtests!

Everyone! Look under your chair! You get a playtest! You get a playtest! Everyone gets a playtest!


Seriously, though, this past Friday was another SCAD playtest day. Pizza, soda, and game feedback all around.

This time, we actually got double the amount of playtester feedback as last time, which was incredible. This allows us to look at a much more reliable data set, and see what has changed from two weeks ago, as well as seeing the results of a few new questions regarding recent additions to the game. Lets take a look at the data, shall we?


So this is interesting. To refresh your memory: last week, the results were Prospector (5), Gunslinger (2), Knuckleduster (0). This week, the results were completely flipped from the previous results. Here’s a list of things that we did between the last playtest and this one, that may have influenced this shift:

  1. Knuckleduster’s animations were revised: his punches are more violent, and his walk is heavier and tougher.
  2. Gunslinger now has the correct textures, and more exaggerated attack animations.
  3. Prospector heals faster, for less. Knuckleduster attacks faster.

And the commentary seems to reflect this: people thought the knuckleduster “looked strong”, was “big and menacing”. And people liked the gunslinger because his “range was… useful”, and how he could “blitz… someone at low health quickly”. All of these are fantastic to hear, because that’s what we were going for. People still liked how the Prospector was a healer that also had damaging abilities, though.


So obviously, there are going to be certain classes that people simply don’t like, and that’s okay. However, there were some good concerns that people listed off.

  1. Prospector: Didn’t read as a healer from his character model and texture.
  2. Knuckleduster: Looked out of place in comparison to the rest of the game.
  3. Gunslinger: Looks to generic, doesn’t read as an awesome damage dealer.
  4. Overall: Outlines on the character shaders need tweaking.

Most of these can be fixed with some simple texture tweaks, which is nice. We’ll give those a shot and see what people say at the next playtest (two Fridays from now).


There’s still a pretty even distribution on who would spend money on our game, and who wouldn’t, which, again, is to be expected. In terms of what people would spend money on, weapons and characters are now jumping ahead of new maps, which was last playtest’s preference.

At the last minute (the night before the playtest), we added some particle effects to the game, which caused some weird behavior, but also allowed for some interesting feedback.


We’ve been debating for a while whether the Borderlands-esk scrolling combat numbers added or detracted from the gameplay experience. My personal thought was that, once we added particles, people would not care as much for the combat numbers. Before particles, the combat numbers were our ONLY feedback for letting you know that your units are dealing damage. However, now that we have the particles, theres enough feedback to let you know how much butt you’re kicking.

The feedback was generally negative for the combat numbers, while generally indifferent, leaning towards positive for the particles. Now, it’s import to understand that the particles in this playtest were still glitchy and not perfect, in addition to being overlayed on top of the combat numbers. However, judging from the feedback, I think that once we perfect the particles, we can get rid of the combat numbers.

Since we didn’t have descriptions for the skills in the game, sheets were printed out that described what each skill did.

Screen Shot 2013-02-11 at 12.46.41 PM

I tried to make these descriptions as short and understandable as possible, and also used the playtest as a testing opportunity for the actual strings that would appear in game.

ImageAnd as you can see, everyone thought the strings, although succinct, were perfectly understandable, which is fantastic.

And now, design feedback.

No one mentioned anything being “underpowered” or “overpowered” this time, which was good. We’re still seeing 2-5 minute matches, and getting closer to the shorter side of that range once people understand how to play the game. This is exactly what I designed for, and it’s great to see things panning out how I planned.

Three big pieces of feedback that I’ve been meditating on are as follows:

1. The Knuckleduster doesn’t really have a special attack, which makes him feel less satisfying to fight with. Both other classes have these awesome special attacks, and the KD just has a lasso. Doesn’t feel good.

I’ve been thinking about this even before I heard this feedback. But now that someone has said it, I have some ground to make a decision. The lasso probably belongs as a buff, or maybe if I make the effect a lasso + damage, it would be more satisfying. However, we’ve been having issues making the lasso work correctly in script, so I may change the narrative flavor of it.

2. A few people said they really, really, REALLY wanted to rotate the camera.

Rotating the camera is doable, but easier said than done. Right now, we don’t have any design decisions that REQUIRE a rotating camera, but that’s definitely a feature that’s now on our before-launch wishlist.

3. Pausing the game while selecting the skills makes strategizing way, way too easy.

The idea of pausing the game while strategizing is an idea we inherited from Mass Effect. However, maybe that design choice was better when the game’s design was more third-person shooter, rather than the real-time strategy route that we’re taking now. In addition, we’ve been having some bugs regarding the pause. So it may just be time to bury that feature.

So we have plenty of things to work on in between now and our next playtest, in addition to all the features we have planned (character customization interface, a new class, and new weapons, anyone?), so until next time! Hope everyone has a happy Monday and a great rest of the week.

Interface design and the end-game of Napkin Western.

Welcome back! I hope everyone has had a productive week and weekend.

So! Lets talk about interfaces. Specifically, our character customization interface.


Interfaces and Copic Markers go together like pretzels and Nutella for me.

This is very heavily influenced by Frima’s Nun Attack‘s squad selection interface, in addition to Popcap’s Plants vs. Zombie‘s plant selection interface at the beginning of their levels. By combining both of these, we allow for a preview of the enemies the player will be facing (on the right), a preview of the character and their weapon, and what all of those mean, without causing the player to go through multiple levels or “modes” of the customization screen.

In addition, this interface allows for an easy purchase flow. If a player decides they want to look at a unit or weapon they haven’t bought yet, they are able to preview it and see what benefits (such as skills) that they receive from it. The button that normally allows them to add that unit+weapon combination into their squad turns into a “Buy” button, which triggers the IAP flow from the App Store / Google Play. Very elegant and smooth, while still providing all necessary information. Essentially window shopping while playing the game.

And now for something completely different. Since the beginning of the quarter, I’ve been trying to figure out where I see the end game of Napkin Western. Our original design spec described 3v3 squad matches. However, since we’re only having (an estimated) 4 classes when we launch the game, having only 3v3 will get repetitive rather quickly.

So what’s the solution? What’s the end-game, the logical conclusion? Is it a multiplayer game? What about squads vs waves of enemies, a la Plants vs Zombies? Big baddie bosses? Maybe super-charged versions of the units? A little of column A with a little of column B?

The answer may be a combination of a few of these (or maybe all of them). However, keeping in mind that we’re a group of 5 people, I believe the most feasible of these, while still fostering a fun game, is local multiplayer over Bluetooth and Wi-Fi (a la Spaceteam). This allows us to focus on gameplay and balancing moreso than complex level crafting, unit creation, and AI design. As such, Robert has been looking into Unity’s networking APIs to see what we can accomplish.

We still plan to have a campaign of some sort, in addition to having quick-matches for practice and/or achievements. Depending on the amount of time we have “left over”, we can see if we can implement some more interesting game modes. However, our primary goal and focus is shifting to local multiplayer.

Playtest feedback.

Hello all! I hope everyone had a great weekend. It’s been a very eventful week for me on both the production manager and designer fronts.

First things first, the playtest from last week! We got a lot of really, really good feedback, and a lot of what I’ll be talking about in the next post is as a result of the playtest responses. So, without further ado… let’s begin!


So when asked what the player’s favorite part of the game was, there was a resounding positive response for the core mechanics that have been implemented: the use of actions/abilities, and squad positioning (which admittedly still needs some work). The other core mechanic that has not been implemented yet (but will be in the next few days) is character customization, meaning choosing which members you want in your squad, as well as which weapons those members will equip for the battle.


 This was arguably the most eye opening piece of feedback for us. When asked who was the favorite character to play with 70% of our playtesters said that the Prospector (healer) is their favorite, and ZERO people said they enjoyed the Knuckle Duster (melee) most (the Techwitch isn’t currently in the game, so that’s a moot point). So, I’ve been spending some time tinkering and pondering how I can make the KD more fun/enjoyable/worthwhile to have in your squad.

For me, that was an unexpected piece of feedback, since I typically view the healer class as “boring” and the big brutish barbarian as the most exciting.


 And one last piece of exciting feedback: while there’s a decent chunk of people who would not spend any money on our game (which is expected, payers are rarer than free-to-players), a significant amount of people would gladly spend some money for upgrades to the game. This means two things: 1) Monetizing on this game is very feasible, and 2) People care about the game and are having enough fun with it to be willing to spend money. Both of which are incredibly good things to hear!

A lot of the less positive responses came from the same realm of problems:


1) Lack of feedback of who’s attacking who. To help remedy this, we’re going to be getting rid of the scrolling combat text numbers and replacing them with particles. We already have a health bar, so the numbers were reiterating already visible information. Also, this allows for us to have a clearer, less cluttered combat window, while still giving meaningful feedback. And finally, we’ll be adding arrows to point to who the character is attacking.


2) Problems with textures. We’re doing an update on all of the textures currently in game, as well as implementing normal maps for our characters to make them feel more realistic. Also, this complaint was also mentioned with the Gunslinger, who has an incorrect UV map. This will be remedied once we fix all the skinning and animation issues we have on the Gunslinger, and we can put him in the game. Which leads us to…

3) Animations. These issues are essentially originating from the fact that the animations aren’t playing at the correct speeds, so it looks like the characters are sliding on the floor when they walk, and the attack animations aren’t exaggerated enough. However, these will both be fixed (or at least made better) before the playtest session this Friday thanks to Miranda and Robert! There’s also some weird popping with the Gunslinger animation, which will also be fixed by Miranda.

4) Difficulty. This was honestly expected. The level is completely open, the enemy squad units are a direct copy of your squad units, and the AI is ruthless, where you can’t run out of range or get out of line of sight or anything without the enemies chasing after you. This will be remedied by dumbing down the AI a bit for the first levels, in addition to having a small countdown before the beginning of a match, so people aren’t immediately thrown into a literal barfight.

On top of all of these, by watching the playtesters actually play the game, we were able to get some unspoken feedback. There were some bugs that people didn’t realize were bugs, as well as a few instances of design quirks that needed to be remedied.

So that about covers our playtest feedback! The next post will focus on the design changes that will come as a result of this feedback.

Thanks for reading!