Sunday, March 22, 2015

Rogue Based Immitation Baseball: 7drl Game Jam Postmortem

Rogue Based Immitation Baseball: 7drl Game Jam Postmortem

Jon Trainor, Anthony Duggan, and I had a lot of fun participating in the 7-Day Rogue-like Challenge last week. Unfortunately both Jon and Anthony experience debilitating illnesses over the week so we weren't able to finish our admittedly ambitious goal in time for the Sunday deadline. So instead, we're planning to continue working on the game and make it available elsewhere. On the bright-side,  this means we will have a much more balanced game for you to play. In the meantime, here's a minor postmortem on how the game jam went and where we stand now.

Here's the summary from the design doc we're using:

Summary

Rogue Based Imitation Baseball, takes the great American past-time and gives it an RPG twist with turn based decision making and Rogue-like randomization. The player must make it through an entire simulated season against a procedurally generated league without losing a single series.

Gameplay

The player alternates between Manager Mode, where they analyze players stats, equip items, and set their rosters, and Player Mode where they play as pitchers or batters in a turn-based battle of wits. They must leverage their strengths and out-smart their opponent.

Mindset

 The player is focused and analytical. They are trying to glean clues about players on the opposing team from anywhere they can (behavior, flavor text, etc), and make decision that maximize their chance of making successful plays. They should also be thinking long term

Target Audience

The target audience is nerdy fans of the Rouge-like genre and fans of ultra-retro text-parser graphical action adventure games. It should be especially appealing to fans of baseball since the game is designed to incorporate legitimate real world baseball strategies.
We had a couple long pre-jam meetings to discuss the game design. Jon had a very robust concept going in, so our meeting consisted mainly of fleshing out the feature he had imagined, and pairing down to what features would offer the kind of game play we were looking for and offer the best return on investment. Some examples of features we decided to exclude:

1) Fielding Phase: Originally after each hit we would switch to fielding view, and a simulation of all the fielders would be depicted. When one of the fielders got the ball, the player would then have to decide who to throw it to. This was taken out because of bad ROI, and because there really weren't meaningful decisions to make. There is generally only one, fairly obvious, correct person to throw the ball to in a baseball play.
Instead, player behavior will still be simulated in the background based on those fielder's stats and the trajectory of the ball, but not depicted. Instead, the results of the play and hints about the fielders stats will be conveyed in text. We though this would fit the rogue-like genre better anyway.

2) Multi-Turn Pitching: The Batting phase lets a pitch play out over several turns, allowing the batter to adjust their aim based on their perception and reaction stats. Originally the pitching phase also took place over several turns with the player getting to adjust the balls trajectory. We decided this was inappropriate for the theme (because it that's not how throwing things works), would be complicated to present to the player, and only gave an illusion of gameplay. If you could control the trajectory midair, the optimal strategy would always be to be as erratic as possible to confuse the be batter.
Instead, pitchers will now choose a pitch type and and aim their pitch. They'll have corresponding stats for each pitch type. This emphasizes understanding the stats and matching pitchers to batters, which is more of the kind of game-play we were going for.

Once the jam started, Anthony and Jon got to work getting the core backend systems working. It was slower than expected (which is always expected). Anthony spent some time learning the Haxe toolkit and Flixel game library, while Jon spent a lot of time setting up the data for things like items, events, seeds name generation.

I went to work making the concepts and assets for the visual presentation, as well as designing the flow of the game phases. Here is some of the art we have.




We also already have some great retro sounds and music from Graham Southern. I especially like his minor-key rendition of "Take Me Out to the Ballgame" for the enemy teams.


Were do we go now?

From here on out, our work will be getting the presentation right and doing lots and lots of play testing to balance all these stats. Anthony and Jon are working hard to get a prototype working and I'm making more concepts to help guide them. We expect to have something to share soon.

Anyone interested in play testing?





Sunday, March 8, 2015

7DRL Challenge

Another Game Jam


This week I'll be participating win the 7 Day Roguelike Challenge over at 7DRL.org.
This game-jam is very different than most others. First of all, you have 7 days to complete the game instead of a normal 24 or 48 hours. Also, you're encouraged to have a concept planned out ahead of time.

I've been working on the game design with my team mates Anthony Duggan and Jon Trainor. During the week, I'll be doing art, interface, and helping make any game design changes that come up along the way.

I've never worked on a roguelike, or even played them much, so this will be a very interesting experience. Just making the game design doc and planning all the stats and interactions has been super fun so far. My team is super passionate, especially Jon :) and I'll be sure to post the finished result in 7 days.

Our concept (Jon's idea) is a turn-based version of baseball, where you have to play through an entire season against a procedurally generated league. Not your traditional roguelike.

You can check out our messy, but evolving design doc that we'll be updating as we go.
RogueBasedImitation Baseball Design Doc

Saturday, March 7, 2015

Global Game Jam 2015

Progress on Slow Blade has been, well . . . slow. Direct progress anyway. I've been working on a lot of projects with other people lately to grow my Unity skills. I'd like to talk about one of those other games, and how it will be relevant to Slow Blade.


GGJ 2015: 2 Rats, 1 Cage, a Post Mortem:

Jan 23-25 was the 48-hour Global Game Jam. I got to participate with an amazing team from the @PETAL et al  meet up group. You can check out the game at our GGJ page. Or if you prefer, you can watch a speed run of the game Here.

The Game:
Two Rats-One Cage is a 2D Action puzzler built in Unity 4.6. The core premise is that you are navigating two rats through 2 separate mazes, simultaneously with the same key inputs.

Lead Programmer: Mark Goetz
Art Assets: David Schuttnehlem and Dan Heit
Level Design: Marty Wagner
Level Implementation: Samuel Beatty
Sound/Music: Elliot Nelson Callighan

What went right?
What I was most happy with was how well we worked together during the design phase. Considering most of us hadn't met before the event, we were very in-sync. Our vision for the core concept came together with in the first hour or so and never deviated far. We were also all very scope-minded and agreed on what limitations we were willing to work within.

As soon as we had a concept I started preparing the design doc, and kept it updated as the process progressed. I was also quick to start noting specifically what art assets would need to be needed for each feature, to keep the scope clear to all of us. I also noted all the sound assets we would need so that Elliot, our sound designer could get to work as soon as possible.

Because we had a good plan in place, Marty was able to start designing levels immediately and basically spent the whole time doing that. This proved to be a major contributor to our success. We were able to tailor the mechanics to the level design needs and vise versa.

Near the end of the 48-hours, we convened to revisit the design doc and agree on what features we could realistically finish in time. Again, we were all quick to agree on what we were willing to leave out in favor of refining existing features.

What went wrong?
There were a few minor reworkings of functionality, and subsequent reworking of art assets that cropped up along the way.  In a normal game development process, they wouldn't have been a big deal, but in a Game Jam scenario they were somewhat frustrating.

The biggest time-sink that probably could have been avoided was all of the animations for the rats that I did, which didn't end up in the game. The game ended up being more fast paced that I was originally anticipated. I agreed with the decision and it makes the game more fun, but it means the walk cycles and jumps animations I made for the rats can't be seen at all. If I had know how fast the movement would be at the beginning, I would have been able to make appropriate animations.

What were some disappointments?
The biggest disappointments to me are some of the hazard animations that didn't get implemented. The primary one being the hammer-swing animation. The hammer hazards still function and kill your rats, but you don't actually see them swing. As we've done play tests of the game with other people, we've found that the hammer hazard is the most confusing thing to them, because it's not apparent how it works or even what it is.

Some other disappointments were the features we weren't able to implement, like switches that change the level obstacles. The theme of the Global Game Jam this year was "What do we do now?".
Being able to alter the puzzle, or the circumstances mid level, would have gone a long way toward fitting that theme better, in my opinion.

What were some successes?
The shining success of our game is definitely Marty's level design. By the end we had 17 levels! There are some things we could refine about the difficulty curve, but for the most part, the level progression is quite well thought out, and the levels them selves provide some very interesting challenges, both in terms of planning ahead and twitch gameplay.

For me personally, what I got the most out of was learning more about how to handle art assets in Unity. I made the animations in Spriter which is the 2D bone animation tool I'm planning to use on Slow Blade. Getting experience with a Spriter/Unity workflow is going to be very valuable.

Where do we go from here?
The team has agreed that we'd like to make some revisions to the game and put it out in some larger capacity. We want to finish getting in the hazard animations that are missing, and I would like to reimplement the character animations using the Spriter2Unity plug-in rather than using sprite sheets. I've done some experiments already, and they look much better.

We also want to do a mobile build as an experiment. The controls are simple enough, and we feel like they would translate well to swipe gestures.

Mark wants to continue working to finish the game, but we are all very busy. Mark and I are actually both in the middle of a larger game project with the PETAL group that we'd like to get finished first.

I'll be sure to post when all these projects finish, as well as keeping the blog updated with progress on Slow-Blade.

Wednesday, January 14, 2015

Camer Experiment 1



I've been experimenting with my camera system and now I actually have a build!

You can play it here: http://dschutten.github.io/slow-blade/

It's a definitely not perfect, but it's definitely something I can build on for the final camera.

My goal was to make the camera do  two things:

  1. Keep the Slow Blade and the Play visible onscreen at all times. (Use "T" to enable or disable this feature.)
  2. Lead the player in the direction they're moving, so they always see what they're moving towards.

           I might end up needing to make the camera leading customized to each level, based on the obstacles, but I'm hoping this generic leading will work as a one size fits all solution. I'll need to smooth it out for the final build, and as always, any tips would be appreciated.

All files are available on GitHub: https://github.com/dschutten/slow-blade
The script being used is "ZoomController.cs".

For this experiment, I'm using Prime31's sample character controller available HERE. I'll develop my own as my next experiment.

Obviously the artwork is placeholder art.

Monday, January 5, 2015

Character Concept

It's been a while since my last post, but don't think that means I haven't been working.

Here's my preliminary sketches for the main character. I've also started his animations, but I don't want to post those until I can get them in game.
I've also had some good results with the dynamic cameral, so look for a build of my experiments in my next post.