State of the Gooberz Address

Howdy all,

Sam from the Time Gooberz here.  This blog post is a bit bittersweet at its our last, and will encompass a rundown of the state of the game right now and what we're planning to do before our Gold presentation. 

As it stands right now Time Janitor has a tutorial "level" and 4 real levels.

The Tutorial Level

In the next week we'll be tweaking these levels quite a bit as we incorporate feedback from the playtests and from forcing our friends to play the game.  Part of our effort here is adding a few more secret rooms but a lot of our focus is going to be trying to more naturally incorporate our Rewind system into the level design.  Rooms like the one below become very interesting when the player moves through them a second time and is forced into their own line of fire.

Imagine walking into bullets coming down the center of this room being shot by your past self

In addition to room tweaks we'll also be adding in new enemies.  We currently have enemies that chase the player, enemies that shoot at the player and enemies that fire simple bullet patterns.  This week we added enemies that dash at the player, standing still for a while before moving in quick bursts, and next week we're looking to add enemies that can only be stunned, not killed, and enemies that can only be damaged when shot in the back.

We're also going to be adding a final boss, because what self respecting game doesn't have a final boss?  This boss will include a fun use of our time travel mechanic, but we're not going to reveal what just yet ;)

As we add a few more features we'll also be polishing everything as we go.  This will include small polishes, like adding in death animations for any of the enemies that are still missing death animations, but also some bigger changes.  Part of what we've been working on this week is adding in lighting to our game.  To complement this we've added in new assets such as torches that will add some nice lighting to spice up our rooms.

As always we welcome your comments!

Playtest Feedback

Howdy all,

Sam from the Time Gooberz here.  After our play test last week we got a lot of useful feedback and we wanted to show some of the progress we've made working on it.

One of the largest complaints we got was that the game was too hard.  This complaint on its own is not something we were terribly concerned about, as we know our game isn't well suited for casual consumption.  However one thing we did notice during the play testing was that all of these difficulty complaints came right at the beginning of our second level, which was often where people died for the first time.  In response to this we're moving level 2 to be level 3 and designing a new a level 2 to help smooth out the difficulty curve.

Another thing we saw was some players checking for hidden rooms and, after not finding any in a few rooms in a row, giving up and missing hidden rooms later on.  We're going to be moving some hidden rooms from the later stages to the earlier part of the game, in order to reward people for checking for hidden rooms early.

Additionally we'll be adding in some new enemy types to liven up some of the later rooms, and reworking some of the earlier levels.  We're hoping that by the next play test a lot of our rooms will look a bit different and present a more interesting experience for the player, especially after they have to backtrack through them.

Stay tuned next week, when I'll be talking about some of the polish we'll be doing before our gold presentation!

Gooberz Art Process, Part 2

Howdy all,

Sam from the Time Gooberz here.  After the art related blog post from 2 weeks ago I wanted to give a follow up and talk about the next step of our artist process.  Once we have a sprite sheet with all of the its animations in it its time to actually animate it.  The first step of this is getting the sprite sheet out of Piskel (our sprite editor of choise) and importing it into Unity.  Fortunately this step is trivial, as both Piskel and Unity use standard file formats to export/import images.

Once we have the image in Unity we need to slice the sheet up into individual sprites.  Unity also makes this process easy using its built-in sprite editor.

Slime Sprite Sheet open in the Unity Sprite Editor being sliced

Unity's sprite editor gives us a slice tool that lets us convert a sheet into a series of individual sprites.  Above you can see a picture of the slice tool begin applied to the sheet, with the results displayed below.

Slime Sprite Sheet after being sliced into individual sprites

Once we have the sheet turned into a series of individual sprites we need to turn those individual sprites into animations.  Fortunately Unity makes this simple for us as well, letting us easily drag multiple sprites together to make an animation. After we have all of the animation objects made its time to put them into the actual controller.  As I talked about in the last Art Process post we have one animation controller state machine that we use for all of the enemies.  This lets us reuse as much as possible, and enforces a consistent pattern for all of our assets.

The Attack Animation State Machine

The image above is a submachine within our state machine that handles the attack animation for an enemy.  The attack animation is broken into two segments, the front swing and the back swing.  The front swing is every part of the animation that occurs before the actual projectiles are fired, and the back swing everything that happens after the projectiles are fired.  Breaking it up like this lets us easily control, to a frame perfect level, exactly when in an animation projectiles are fired, which we do using the intermediate state you can see above, the AttackScript state.

The AttackScript state is an example of how we use animation controller to control entity behavior.  This state has a script attached to it that causes the entity to spawn projectiles, or damage the player, or whatever that specific enemy type does when it attacks.  After that has finished it passes control back to the animator controller by moving from the AttackScript state to the AttackBackSwing state.

This back and forth gives us complete control over when in an animation different effects trigger, and when the animation resumes after those effects have resolved.  We can also use it to override the normal transitions in the state machine by having the script take us to an entirely different state instead of just passing control back to the state machine.  As an example this is useful in the case of an enemy that tries to run at the player and then explode, where after the explosion we want the enemy to die instead of resuming its normal animation loop.

Second Play Test!

Howdy all,

Sam from the Time Gooberz here.  This week we're going to be doing a play test on the JHU campus! We'll be presenting a short slide deck on our game followed by doing an open play test.  This time our presentation this time will be focused on shining a light on what happens week to week inside Time Gooberz. We'll be going over our weekly process and highlighting what we've changed in that process.  We'll also be talking about how we use Unity, what we love about Unity, and what we view some of Unity's greatest failings to be.

If you can't make it but what to try the game out anyway we encourage you to visit the link below and download the game.  Please feel free to leave your thoughts in the comments below.  We appreciate any and all feedback :)
https://bitbucket.org/601355/gooberz/downloads/

Gooberz Art Process (Not Patent Pending)

Howdy all,

Sam from Time Gooberz Zudios here with a new update.  This week is my week to work on art, and so I thought I'd bring you an update focused on how our art process works.  Our game uses 16x16 pixel sprites for most entities, though the "tile size" of our game is 64x64.  What this means is that we draw our sprites in a 16x16 grid and then render them at 4 times their size in the game.

We do our drawing using the online app piskel.  Its free, open source and awesome.  It isn't as powerful as some other tools are, but the fact that its free and in-browser makes it convenient for us, and it has all the tools we need.  As we posted about earlier, we're using a free-to-use dungeon spritesheet that we pull our base sprites from.

Slime Base Sprite in PiskelApp

Once we have the base sprite imported into Piskel we then begin making all of the animations that we need.  What I've been working with this week are a set of new enemies, all of which follow a similar layout.  Every enemy needs an idle/move animation (idle for enemies that don't move, move for enemies that do) that acts as its default animation.  Every enemy also needs a stunned animation, for when the player hits them.  After this things get more specific.

Enemies that simply run at the player and try to "hug" them only need a move and stunned animation, but more complicated enemies need more animations, or even other supporting assets.  An enemy that shoots bullets at the player needs an attack animation, as well as a bullet animation.  For now all of our enemies share the same bullet in order to keep things clearer for the player, but in the future that might change.

The slime enemy pictured above is an immobile turret that shoots bullets blindly in patterns or shoots bullets aimed at the player.  So it needs an idle animation, a stunned animation, an attack animation and a projectile.

The attack animation is customized to the enemy.  Our bat enemy "spits" bullets at the player, but since our slime lacks a mouth we're having it fall into a puddle as it launches bullets at the enemy.

Sprite Sheet for the Slime Attack Animation

In order to help preserve the visual clarity of our game every enemy has a very similar stunned animation.  This allows the player to instantly understand what the animation means, allowing them to spend more time focused on dodging, shooting and regretting their previous decisions.

Spire Sheet for the Slime Stunned Animation

And thats our process! Next time I'll be talking about how we string all these animations together in a nice generic way that lets us re-use logic from one entity to another.

The Goobers' Development Process (Patent Pending)

Howdy all,

Sam from Time Goobers Zudios here with an update on how we make the magic happen.  Each week on Wednesday the Goobers have an official status/planning meeting, its almost never our only meeting for that week, but its when we sit down and do our major planning.  We first figure out what we want to accomplish that week, and then we divide tasks up among our members.  No one has an official speciality, and everyone does a little of everything, so who does what often depends on the team member's availability and mood.  Once we've got tasks assigned everyone goes their own way to work.

We'll normally then have smaller meetings throughout the week as team members coordinate their work, or want to ask questions of the person who was working on something last week.  Eventually the week ends, and the time to merge all of our work comes.  We use Git for version controlling, and all during the week each team member has been working in their own branch.  Our software lead is in charge of merging all of these branches together and working with the developers to fix merge conflicts and make sure at the end of each week we have a single stable build that has everyone's work from that week in it.

And thats our process! If you have any questions feel free to post in the comments section below :)

Playtest Results

Howdy all,

Sam from Time Gooberz Zudios here.  As our avid readers know, last week we gave a presentation and play test session at Johns Hopkins' undergraduate campus.  To everyone who came by, thank you! We got a lot of really awesome feedback, and we can't wait to roll it back into the game for our next play test.  The next few weeks will feature us working on implementing the feedback we got, cleaning up the first few levels, and adding additional levels.

A lot of the feedback and clean up overlap, and we're looking forward to implementing features like transitions between rooms and smoother controls.  One of my personal favorite suggestions we've already implemented is switching our control scheme from WASD shoot, arrow keys move to WASD move, arrow keys shoot.  This is the control scheme that Binding of Isaac uses, and a lot of players felt off because of the difference.  As for the rest of the feedback, you'll be seeing it roll out soon!