Bomb Sworders Updates (5-23-18)

Figured that it’s about time for another update post. In short: These past few months we’ve been going around showing Bomb Sworders a fair bit. It’s been fun and we’ve used the opportunity to refine the game.

Anyway, read on for a timeline of sorts.
(click on imgur links to see animation)

 

— Before Madison’s Indie Arcade —

In prep for Indie Arcade, we worried that rounds might last super long if we got a group of defense-favoring players. That’s not necessarily a problem if everyone is playing and having fun but could be annoying for those who were eliminated early in a round. So we instituted “crunch” — lava (well, an orange rectangle (though if we’re really being picky well then ceci n’est pas une lava or something like that I suppose)) which would slowly fill the level starting about 40 seconds after the first player died.

View post on imgur.com

Made a multiplayer tutorial.

 

— Indie Arcade —

Tested the multiplayer tutorial. As an overall thing it definitely didn’t work but, later when I watched the gameplay footage, I was pleasantly surprised with a couple bits of it — mainly concerning the order that people figured things out. So not a success overall but I like to think a useful signpost.

View post on imgur.com

One thing that caught me by surprise was how much trouble we ran into on the menus. Multiple people would try navigating in the exact same moment which inevitably led to every person’s attempt failing. It initially surprised me that Indie Arcade was the first time that we encountered this but I think it was also the first time where a lot of the playgroups included people who didn’t know each other. That is, our earlier playtests before Indie Arcade were usually with groups where there was already a sort of preselected “leader” — for example, if one of us devs was playing, then the group would expect us to take over menu control. In other instances, very often the playtesters would be a group of friends who presumably had some already-formed expectation about which of them would be taking menu control.
Especially since we knew that we’d be going to more events, it seemed worthwhile (and kinda interesting) to try to address the issue so I wrote what I call a SharedInterfaceInputManager. It’s not complex at all and the main part is just the idea that if you successfully execute a menu action, then the input of other players will be ignored for 0.3 seconds — an arbitrary value that’s my guess for how long it takes another player to have some recognition/ability-to-react-to an updated menu state (muddied, of course, by things like the duration of animation that indicates the change of menu state). There’s a bit more to it but that’s 90% of the way there and so far has seemed to work nicely though it can be hard to evaluate. For things like this I don’t expect people to be super aware of it so the best I have is that I’ve heard no complaints and the recorded footage seems to show much more fluent navigation of the menus.
Extending this slightly — if the SharedInterfaceInputManager is working well, then to be honest, I don’t know the exact process that is at play– I suspect the manager doesn’t encourage players to delicately shuffle their inputs into the menu in some beautiful egalitarian way so much as subtly discourages some players from attempting to provide input (“ah, I tried before and it didn’t seem to work”), which then leads towards a de facto leader. And perhaps trying to encourage one player to take over menu control is a good strategy anyway — whether that encouragement happens in game or leaving it to the discussion space, I can see pros and cons to both. Anyway, it seems to be working so far.. but will be interesting to keep track of.

View post on imgur.com

Bomb Sworders came from a time when I was messing around with prototypes about territory control. The original idea was kinda about attrition — where the player slowly fills in the level with blast-zones, limiting the other players’ movement options until the player with the advantage can easily finish them off with a dynamite. In actual practice though, people tended to play very recklessly probably because sometimes the ideal strategy isn’t the most fun strategy by a long shot. Eventually, some time after we decided to make the game more than a prototype, we added the ability to hit bombs with swords and propel them across the level at farther-away players. As we’ve playtested the game, that hit strength is something I’ve messed around with a lot. If I put it too high, then the game loses much of its territory control aspect and the more highly skilled players can win almost purely on perfectly timed sniper-shots with bombs. If I put the hit strength too low then the game becomes much more about attrition but also it loses some amount of excitement as the general speed of the game wanes along with the hope of “just one lucky bomb hit and I could win.”
At Indie Arcade I tried the hit strength at the lower range of what I thought might work. I’ve since increased the value about 30%.

Also at Indie Arcade there were a couple 15 second chunks of time where the game didn’t offer any attractive goals to the players — no items that were anywhere near reachable for their skill level, no one to flee from, nor any clear advantage to be found by moving to a different location.  One solution could be, of course, just generating lots lots more items so there’s always something nearby to interact with.. but then we lose the opportunity to have the players experience scarcity — which has value in itself and can also be used as a tool to encourage players to interact directly with each other. So we made a few changes to address the problem.

Added the Split level (seen below).

Since the game has horizontal wrap-around, we added preview edges. I’ve heard strong reactions both positive and negative to this — and I can understand both sides. Though, that being said, a decent percentage of people who initially didn’t like it have switched sides. Still, we’ll have an option to turn it off if desired.

View post on imgur.com

Characters are now fully their team color. Prior to this, the characters themselves were red and only the color of the sword represented their team color. But then the game changed and the red color of the character no longer signified anything. And then the game changed and you could throw your sword — which made it possible to have a sword-less unidentifiable character running around which was fairly confusing to everyone. And then another 4 months passed and we were like, yeah, we should probably get around to fixing that..

Wasn’t a huge fan of “crunch” (the lava that came up to force the end of a round) — not that it didn’t accomplish its goal effectively. Instead now after the first character dies, the average number of items will slowly increase which leads to more and more chaos — naturally weighted in favor of the player who was winning at that moment.

Added an interesting feature.
Removed interesting feature.

Added another interesting feature.
Removed this interesting feature too.
(But hoping to bring this one back in some form)

Refined various things in the movement system especially around climbing behavior near the top and bottom edges of walls to make it more predictable and also “latching” — the ability to redirect fast horizontal speed up a wall while in ghost mode (see below). Quashed a couple minor bugs too.

View post on imgur.com

Occasionally people wouldn’t notice the moment that their character died — especially during very chaotic times. So now, in addition to the other indicators, the character undergoes a short death animation where it spins away.

View post on imgur.com

Added more music, including a great main theme from Releaux and also finally added proper looping and fade-in/out controls to the audio manager.

Cannon shows timing information in the death-beam warning graphic

View post on imgur.com

 

— PAX East —

Like I mentioned before, we had a blast at PAX East and met a bunch of great people. Overall it went really well. We were pleased with how much people seemed to like the game, how many people returned to play it again and again, and also with how the different mechanics were learned and progressed. Honestly, I even picked up a couple tricks/strategies from watching people play.

On the flip side, having the game played a ton over 4 days is a great way to spot some rare bugs. Which, of course, is ultra helpful but can be a bit deflating in that exact moment. Thankfully most of the bugs were minor and fairly easy to address.
e.g. if 2 characters touched dynamite on the same physics update — then it led to both characters getting the dynamite powerup.

Didn’t spot any further occurrences of the “goals” problem — that rare but annoying ~15 seconds of nothing-to-do that we first noticed at Indie Arcade. So it appears that our changes mostly resolved that.

More than any other group of people we’ve played with — the PAX attendees loved throwing swords.

Noticed that new players would often hit cannons multiple times — taking their experience with bombs (where multiple hits is a valid action) and applying it to cannons where that action is ineffectual. So we changed the cannon graphic subtly to dissuade multiple hits. We tested the change at Anime Central and so far it seems to be much better.

Then returned to Milwaukee, got a cold, and basically slept until..

— Midwest Gaming Classic —

Presented the PAX version of the game at MGC and it went well. It was especially fun to meet some devs that we had heard about but not yet had the opportunity to meet.. and also to reconnect and hang out with those that we did know.

The following couple weeks were taken up with bug fixing — which was not fun at all. In fact, it has really put me off the idea of inserting bugs into the game in the first place.

Began testing 3 new levels: Redwood, Roam (shown below), and xMarksTheSpot.

View post on imgur.com

Made a bunch of quality of life changes on the start menu.

Expanded functionality of the pause menu.

Added a dynamite drop assist — if a player presses the dropDynamite button a split second before actually picking up a dynamite, then can safely assume that they intended to drop the dynamite as soon as they got it. (Just in case anyone thinks this through more completely — this isn’t actually a full description of how the assist works)
Someday I’m hoping to write a blog post about this type of thing — about attempting to respond as best as possible to player intention rather than just the input directly.

Finally, after receiving frequent feedback about it over several months, we added the jump action to Right Bumper to allow both jump and swordSwing to be easily used at the same time.  I had resisted it for a long while because early in the development process I had actually tried it out and didn’t like the feel at all of pressing the Right Bumper so often… But after practicing with it for a few days, I finally felt comfortable offering it as an option for the Anime Central build.

Began prepping for Anime Central and, with room for 2 gameplay stations, we wanted to be able to provide a viable single player experience so we spruced up Exploder mode a bit (shown below and previously called “Targets mode”) and then had a little sign above the TV which kept track of that day’s high score.

View post on imgur.com

 

 

 

 

— Anime Central —

Was surprised at how well (and quickly) the jump action on Right Bumper worked for the people who tried it.

The station set up for Exploder mode worked well (and the nonDev record during the event was 28, which is pretty impressive). As more people gathered it was easy to switch that TV over to the multiplayer Battle mode too.

We tested 2 new levels: Redwoods, which is especially good for the dynamite-only Chase mode, and DynamiteInTheAttic which is directed at intermediate-level players. Still need to make some graphics for those..

Anyway, at Anime Central we also had a lot fun meeting people both new and old. Thanks to Raffy for organizing the event!

— Upcoming —

At this point, I’m really pleased with how the core mechanics of the game are working so now we’re beginning to shift towards thinking about what the game will actually look like as an end product.

Currently we’re doing more levels, more music, and creating a tutorial and a reference guide. (An interactive tutorial for quickly teaching people just enough to start playing the game. And the reference guide will contain video/text describing the more advanced maneuvers and mechanics of the game)

After that, there are a few more game modes to explore — built mostly on top of the mechanics that already exist — as well as at least one more item to try out and, of course, a fair amount of polish to spread around.

Then we’ll be moving into fairly unfamiliar territory — it’ll be interesting to see how it all goes.

 

Leave a Reply

Your email address will not be published. Required fields are marked *