This week was exciting. We debuted our BSC Twitch Interface this week! As we are students at the Entertainment Technology Center grad school program, it was only fitting that we hold an ETC Faculty vs. Students Match.
JD and Mike Christel, a professor at ETC, were on camera running the match, with King Kong and I leading the students.
I am happy to say it was a success! The game was fun to play and challenging, the broadcast was entertaining, and we found out about our professor’s latent abilities for trolling and trash talking. It wasa win for everyone – except, maybe, JD, who, as a result of the students losing the match, had to eat spicy pickled okra. Bleh!
We did receive some feedback about adjustments to make, particularly in the values of some of the assets during Input Phase (as it was hard to tell rocks from barrels). We also have some technical Cross Domain issues in safari. But overall, it was a resounding success.
This is exciting, because we are going to be going into our marketing campaign here soon. More on that soon!
After our last Twitch Playlets and work on polishing the main game experience, we returned this week to the Twitch experience.
We’ve done a few tweaks already: we doubled the Input phase time to reduce conflicting input / output phases, and made the in chat messages clearer.
Another thing we noticed is that the game was fun – when we were on the chat directing players. When players wandered into the chat to play, they would leave quickly. So while we have decided to keep our Twitch v. Twitch model, we are moving to a more event based, broadcaster hosted game.
Finally, after much discussion, we’ve decided to pursue a new avenue for allowing users to play: a web App that provides Real Time Feedback, similar to what Streamline is doing.
We are building the App in NodeJS. The page embeds the Twitch Video and Chat. The app connects to IRC and uses messages to determine the state of the game. Then using the Twitch API’s latency property, we can calculate the amount of delay the video has, and update text in the app accordingly.
In addition, the web app will allow users to input the commands into the app according to
Admittingly, this is an ambitious piece to take on this late, but we realized how important improving the usability of the Twitch gameplay is.
I talked before about the problems we needed to solve with Game UI. We’ve come a long way since then!
One of the biggest things we did was add an Input Now signal during Input Phase. When players miss an input, it flashes to them the next round to input. This way novice players learn when input takes place, and more advanced players will never see the cue.
Other things we did:
Added a blinking cursor during input phase – similar to a word application
Remove the frame during output phase, to take away the feeling that the input is something to be modified.
Animated the commands to disappear as they are played.
So how did these changes work? Great! This week we ran a playtest with people from different background. We had them play the game, and gave no instructions on how to play. Everyone – from young kids, to experience gamers, to moms – could eventually figure out how to play the game, and had a great time doing it.
The one thing we still need to address is giving indication as to how long input phase lasts. Many people – presumably those with musical experience – can tell just by the music, but many cannot. Since playing to the beat is actually not a necessary skill, but more of an aesthetic, we want to give a bit of a visual indicator as well.
We are halfway through our work on this game! We’ve officially hit feature lock for the main game, and are now focusing on polishing and play testing. The game we are going to have going into green light will consist of:
2 playable classes and four characters
five levels with different pieces of music
Twitch Play integration
That’s not to say that we don’t have more we want to accomplish with the game, but we feel very proud of the base game we have created.
Our next major milestone is submitting to Indiecade. More on that next week!
Last week we had our game on display at GDC. What an amazing experience!
We prepped for the experience by making these cute cards with our characters on them to hand out to people.
We had people come by from places like Rockstar, Harmonix, and Hasbro. It was amazing to have these professionals play and give positive feedback for our game!
In addition we spent a lot of time meeting and making contact with other developers. One in particular, Soma Games, will be running a Beatstep Cowboys tournament soon on Twitch! Go check out their stuff and watch them play!
As mentioned, Twitch extremely tricky to design for, due to the syncing of feedback. How do you design a game that feels responsive when players have to wait 12-20 seconds to see any feedback?
I can’t say we’ve solved this problem yet.
We ran a Twitch playtest earlier this week. Before I get into this I will say it was fun, and there’s a lot of potential here. I could talk about things that are fun about this style of play (trolling!) and designing a solid voting mechanic. But it’s hard to discuss these things with the eight hundred pound gorilla named latency looming over.
The biggest problem is now not even the lack of feedback, but conflicting feedback. The game may look like it’s in output phase, but asking for my input in the chat.
The second biggest problem: even if the game is funner for players, it is much less fun for spectators. Which, in a medium devoted to spectatorship, is a problem.
Twitch Play is very much in a Wild West state right now (more puns!), and to create something with the technology as it is right now, we need to find a way to harness the chaotic fun of Twitch plays Pokemon style play…
So for the time being we will be iterating on our Twitch play model
So I mentioned before we’d done some Rapid Prototyping in the Tiled Editor to start experimenting in level layout. Now is the time for refinement.
In the process of running the tournament I’ve spent a lot of time analyzing the current level and what makes it work (as well as potential problems. I found that like most good levels, the original level has
Several “choke points’ areas where battle takes place, and
Multiple paths for each player towards those point, allowing a player to either be more aggressive or defensive.
There were patterns that lent themselves to a great choke point. Generally speaking a choke point ends up being a circular area centered around cacti. This is due to the fact that cacti gives a player a tactical advantage to fire on another player, but enough separation that a player can escape.
Basically, it fosters Close Calls.
Much like most strategy games, I saw that the matches could be broken down into stages.
Players have an opening move, where they decide what how they will start the match. This is especially critical moment because time pressure hasn’t started yet. Players should have multiple paths to move into that lead somewhere potentially strategic. The player Should also not be able to kill each other in this first move.
On move two the players should start to move in range, trying to get the upper hand. It may be possible now to kill the other player, however there are still multiple ways for each player to move.
By move three players should be locked in combat.
After the prototypes, I took five potential levels (sadly, none of which was Death Bridge) and ran playtests with them with the Tournament Finalists. I came away with two that felt the strongest: Quicksand and Graveyard.
Quicksand is built around a mechanic of a tile that traps a player for a short time. This tile creates nice suspense and has synergy with bombers. Graveyard is a bit similar to the original level. It has a few different intentions. The biggest is to create balance. The current level, while currently very nice is not evenly distributed and favors the player on the right – something we attempted to alleviate with a coin toss during the tournament.
The next is to make sure explodable rocks (a feature we are considering implementing) affect the game positively. A blown rock should still lead to strategic gameplay. And if a player cannot blow rocks they should still have a strategic ways to move. This level is designed with explode-ability in mind. As all good things should be.
So there has been a bit of a disruption on here due to a fun experience. I decided right after the tournament to fall and tear a ligament in my ankle. Yay! But back in the saddle (cowboy pun!)
The Beat, The Step, and The Cowboys Tournament was an awesome success! First we must give recognition to our finalists
1st: Larry Chang
2nd: Abhishek Singh
3rd: Shantanu Daas
4th: Ariel Kuo
And thanks to all of the participants. So the most important this: What did we learn?
There is a big difference between how a skilled and less skilled player plays. In fact, as a developer of the game, I can’t beat Larry, ever.
Likewise, there’s a big difference between play styles. In post tournament interviews, we found some players described aggressive, defensive strategies, as well as strategies that relied on making themselves unpredictable
The way advanced players use bombs is different. Players used bombs not to kill, but to force movements and control the board.
Level Balance. It may seem obvious, but balancing a level so neither player has an advantage is extremely important.
Level Flow. Players tend to want to make opening movements to position themselves,
Finally, Awesome announcement: Beatstep Cowboys will be showing at GDC!
Beatstep Cowboys is a Pitch Project at Carnegie Mellon’s Entertainment Technology Studio, and we will be showing our project on their booth. More info soon on that.