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?

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

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.

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.

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.

Technical Design - Document

This my preliminary break down of the technical features of the game. I'm new to using Unity, and my game programming experience is limited to a little bit of AS3, so I will need to research all of these features and workflows to see if they're going to work for me. There might already be simple ways of doing what I want to do, or I might find major roadblocks; totally beyond my ability. I'll adjust this document as necessary, right now it seems do-able given time.

I'll also document all of the sources I use for my research. Comment if you know any good ones!

Slow Blade – Preliminary Technical Design

Basic Game Systems

2D Game 

Art created in Photoshop and animated with the Spriter animation tool (a bone animation tool similar to Spine).

Physics-based Platforming

Use Unity's built in physics system for movement. I've done a little bit of research into examples of how to do this, and it's pretty straight forward.

Needs:

• Basic walking, running and jumping.
• Figure out how to do wall jumping.
• Figure out how to control fall speed. 
• Figure out how to throw and catch the Blade,
• Figure out how to make the Blade bounce indefinitely of of walls with correct rebounding.
• I may not be able to use  the built in physics for the blade itself, since it needs to by unaffected by gravity and bounce at consistent angles. 
• Right now I'm planing to restrict the throw angles to Horizontal, Vertical, and 45º, because I'm assuming it will make things easier, but that may not prove to be the case.

Dynamic Camera 

 Camera will automatically pull out/zoom in to keep the player and the Blade on screen at the same time. Hopefully there's good examples out there of how to do this. I only have a vague notion of how I would try to do it.

Plan B: Just have the camera automatically zoom out to a particular level whenever the Slow Blade is thrown.

Plan C: Just be fully zoomed out all the time.

Level Designs

Each level designs will be a specially designed puzzle. I'll start with simple proof of concept levels to demonstrate core mechanics. 

I'll use a tile based system to build the levels. This will have the added benefit of making measuring easier, to get the timing of the Slow Blade.

Needs:

• Create a set of appropriate prefab tiles. 
• Investigate ways of easily working with tile-based systems in Unity. Might benefit from external tools like TuDee: http://www.diorgo.com/v1/?p=366
• Animated prefabs of all the hazards.

I need to find out how to make prefabs with the correct properties already assigned to the appropriate surfaces and triggers. Once I figure out what those properties and triggers should be of course.

Character Animation

I want to make a fairly elaborate animation system so that I can challenge my self using Unity's Mecanim.

Needs:

-I've identified the the following animations that I want so far:

• Idle
• Walk
• Run
• Jump
• Throw - Horizontal, Up, Down, 45° up and down, (Could be complicated if player is able to throw while jumping)
• Catch -probably just one will work
• Fall
• Fast Fall
• Wall slide
• Wall Jump
• Land
• Die

-I need to study the workflow for importing animation from Spriter to Unity.

-I need to investigate how to incorporate the Slow Blade itself into these animations dynamically. I'm hoping there's an easy way to hide or swap the asset in the animation, if I import it with the Spriter2Unity package.

-I also want to try using ray casting to give the player an animation that anticipates landing on the ground. This is totally unnecessary but I think it would be cool, and hopefully it won't be hard to figure out.

Time Slowing Mechanic

No idea how I'm going to do this. I'm hoping there some fairly simple built in. I'm sure this mechanic had been done a lot.

Plan B: Make slowed down versions of all the moving elements and fake it.

Replay Mode

Ideally after each level, there would be a feature that replays what you did, but at full speed so you can see how cool you looked to an outsider. Whether this can be done is dependent on how I do the time-slowing in the first place.

Slow Blade - Concept Document

Slow Blade – Concept Doc

Premise

You are a ninja who at long last has discovered the resting place of the legendary Slow Blade, a large shuriken-style weapon that allows it's wielder to manipulate time. You've successfully made your way to the deep dark depths of the dungeon where it has lain for eons, but only by harnessing it's power can you make your way out again.

Gameplay

The player must move through a series rooms with traps, impassable to even one with a ninja's speed and agility.

Fortunately by throwing the Slow Blade, the player is able to slow time and evade the traps. However, the player must also out-maneuver the Slow Blade itself, making sure to recover it before moving to the next room. The player does this by banking the blade off of walls, and timing their movements to be in position to catch it after safely traversing the level.

Primary Game Features

• Ninja Style Platforming - The player can run, jump, wall-jump, and control their speed while falling. 
• Throwing and Bouncing the Slow Blade -  The player can throw the Slowblade horizontally, vertically or at 45 degrees. It will bounce off all hard surfaces, continuing to bounce indefinitely until it is caught by the player, or exits the level through one of the doors. (Level design might also incorporate wooden surfaces that the Slow Blade can get stuck in.) 
• Time Slowing - The speed of objects other than the player (including the Slow Blade itself) is slowed as long as the slow blade is in motion.

Release Platforms

• Web