About roaringcatgames (twitter: @roaringcatgames)

In early 2014 the game development community in Louisville, KY really began to grow thanks to GameDevLou and Global Game Jam 2014. With this influx of energy into the community, Mike and Barry decided to take their game development efforts beyond just hobbying around on the weekends. While putting more effort into refining their skillsets, they participated in game jams to practice and push those new skills. During Ludum Dare 30 they collaborated with local artist and designer Loi LeMix. This collaboration worked out wonderfully, and Roaring Cat Games was officially formed. Now the team is focused on creating new games with a little feeling, a little humor, and a lot of fun.

Entries

 
Ludum Dare 37
 
Ludum Dare 35
 
Ludum Dare 34
 
Ludum Dare 33

roaringcatgames's Trophies

roaringcatgames's Archive

Timelapse of Junk in the Bunk Programming

Posted by (twitter: @roaringcatgames)
Tuesday, December 20th, 2016 9:55 pm

Checkout a short time-lapse of the development of our game “Junk in the Bunk” for #LD37. Play and Rate Here Junk in the Bunk

Mount FuJ Post Mortem – LD34

Posted by (twitter: @roaringcatgames)
Sunday, December 20th, 2015 6:31 pm

 

The Game

http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=58120

Mount FuJ is a take on tower defense, or defend the castle style games. You play as an active volcano trying to protect the village that has popped up just below at your base. The village is under siege from an unknown enemy that is sending wave after wave of pikemen and horsemen units. The village will fight back, but it is no match for the army. You must use your volcanic ways to rain down lava balls on the enemy before all of the buildings are destroyed.

[Features that didn’t make it: If you are successful, the village will flourish and grow. However, as the village grows, it begins to spread into the range of your lava, so you have to be very careful to do more protecting than damaging.]

mountfj

Background

Zoe Blackwell – Music and SFX
Loi LeMix – Art
Barry Rowe – Programming

The Team

Left to Right: Loi, Barry, Zoe

This was Zoe’s first game jam, and first game related project. Loi and Myself have been working together since Ludum Dare 30, and have formed Roaring Cat Games under which we publish our work. Our team formed as we were brainstorming at the live Ludum Dare meetup with GameDevLou. This was the first time that Loi and I have worked with a dedicated musician and sound designer (which was awesome).

Tooling

Zoe used Logic Pro to record, mix, and compose music. She user her Casio Privia PX-160 keyboard as a midi controller to write the segments needed for composition.

Loi used his usual package of Adobe products but heavily worked in Photoshop to generate the art assets. However, this jam, he added a new tool into the mix with Spriter2D. Spriter really let him focus on the art and fluidity of the animations when during previous jams he was having to worry more about manually framing animation sizes and pivot points.

I chose to go with libGDX for this game jam as it is the framework I have the most experience with for games. While I’ve been doing some 3D work and learning unity since Ludum Dare 33, we knew we wanted to go with a 2D game for this jam, and I wanted to eliminate engine knowledge as a possible roadblock. We always like to challenge ourselves in some way with our projects though, so I did decide to throw Ashley ECS into the mix. I had used it for LD33, but only sort of embraced the ECS approach. For tooling I used: IntelliJ as an IDE, GIMP for placeholder art, and Git for version control.

Location

We worked the entire Jam at the Game Dev Lou “real-world gathering” working alongside at least 8 other teams. (See all of the GameDevLou games here: http://gamedevlou.org/our-ludum-dare-34-games/)

real-world-meetup

We presented a less finished version of the game as the real-world Jam wound down on Sunday about 7PM:

Brainstorming

Our brainstorm session was a bit longer than usual this time around. The existence of two possible themes really seemed to throw a wrench in our creative process. We kept falling into the trap of trying to force both themes into the game rather than focusing on one theme and discarding the other. Loi and I had also discussed trying our best to find a hack’n’slash to fit the theme, so I think that had us always coming back to “is this better than just building a hack’n’slash?” In no particular order, and with no further explanation, here is a list of some of our ideas:

  • Auto-run with Attack, Duck, and Jump all in two buttons
  • Snake/Centipede style game
  • Save the iceberg
  • Ninja absorbing souls into an ever-growing sword
  • Volcano Game
  • One-punch man training simulator (w/ boss fight)
  • Planet Building
  • Tree vs. Lumberjacks Survival game
  • Avoid the expanding Objects
  • Dark Maze Puzzler
  • Grow and Shrink objects to get out Puzzler
  • TRex growing up
  • Lion hunt and roar

When we got to the end, our top 3 ideas were between a Growing Sword hack’n’slash, One-Punch Main Training Sim, and a combo of Volcano and Protect the Iceberg.

brainstorming-sketch

As a whole we were most interested in the One-Punch Man game, as it had the opportunity for lots of humor, and working with a story/world we all enjoyed. However, as we started designing out how the game would play, we realized that the mini-games were fun as a concept, but boring in actual gameplay. We came to the conclusion that we couldn’t make the game fun enough to move forward on.

Next in line was the Hack’n’Slash with a growing sword. We discussed it, and the game play was going to be pretty simple and fun, and the environment had a lot of potential for interesting visuals and sound. Unfortunately, once we started looking at some of the features that would need to be implemented and the number of animations and art assets required to match our vision, we realized that the scope was just a bit too much. I personally had some major concerns that I wouldn’t be able to figure out how to implement the sword mechanics we wanted in code. I kind of regret giving into that fear looking back, but it was probably the right call. Loi can blame me for dashing his Hack’n’Slash dreams until the next jam.

As we began finalizing our third choice, the volcano game, we all kind of realized it might fit our strengths really well. Zoe seemed confident that she could produce the tense, dramatic soundscape we were designing toward. Loi found the concept might lend itself to a painted style he’d been wanting to try out. I felt there were some interesting challenges in the code, especially with only my second project using Ashley ECS, but was all doable in a Jam time-frame. On top of this, once we all got on board, we began expanding some of the possible mechanics, and the game was sounding pretty fun.

Process

Our process for building out the game was straightforward.

  1. Work up a list of all the known assets (art and sound) we would need
  2. Work up a list of all the programming features we need
  3. Task out the features in order
  4. Build each feature to implementation
  5. Repeat 3 and 4 until the Jam ends

Check out this timelapse of the programming effort over 3 days:

While there was no intention this jam of keeping Loi and Zoe from playing the game until the end of the jam…it still happened. Due to the development tools, having the game up and running where we can all play it isn’t as simple as I’d like it to be. This means that unless everyone on the team sets up their machine for development, the only way to play is to jump on my machine.

I think we should have done more small 5 to 15 minute breaks where we all get together to test a mechanic, listen to a piece of music, or analyze an animation or set of art assets as a group. This is something that was missing from our process this Jam, and I think it did limit what we accomplished.

What Went Well

The art and music for the game turned out fantastic. Zoe and Loi nailed it, and I love the feel of the game with them in combination. The soundtrack is nice and tense, with a subtle yet still noticeable buildup of urgency. Combined with the SFX and the lava animations, it makes for a very cacophonous battlefield scene. Yet, somehow with all the explosions and battlefield tension, there is a soothing calm to the experience as well. About halfway through the jam I could see that the music and art were going to need to take the main focus of the game.

The collaboration between the team went smoothly. We were each able to spend the majority of our time in our own tasks but were able to stop and discuss next steps/changes as needed without any issues. I think being in the same location really helped with that, and I can’t recommend enough that you try to join a real-world meetup if possible.

Coming together on Monday after our day jobs, we were able to pull off a lot of work right at the end. Sunday at the end of our day, we barely had a game. The wave system didn’t work, there were no sound effects, there was no balance to the enemies, and worst of all the game didn’t do anything to highlight the great soundtrack. On Monday we were able to take a step back, prioritize the features to make it a game, and knock them out with just a few minutes to spare for submission. This final crunch period went really well, and it was very satisfying to see how quickly we could get things accomplished under pressure.

What Didn’t Go Well

Coming up with a damn name for the game… This is the first jam I feel like we never had a clue what to call the game. If anyone has any great ideas for what this game should be called leave it in the comments below. We were just drawing blanks the whole time.

I feel like I was the weak link in this jam. I’m not sure what happened, but between saturday about lunch all the way through sunday about 10am, I just couldn’t get anything going. I was writing code, but it was all non-essential background placement or environment building code that I could have (and should have) knocked out towards the last few hours. I think I was dealing with a rough combination of:

  • Exhaustion (I had not been sleeping enough all week prior to the Jam)
  • Doubting my abilities to implement features
  • Lack of clarity on how some of the mechanics needed to work
  • Worry that I may have talked the team into a game that just isn’t fun

I definitely should have started working on having the lava destroy enemies much sooner as that is the key mechanic of the game. I had the lava-firing and charging really quick, and it then just didn’t do anything with it for almost 24 hours. I made the mistake of not building the basic mechanic up front so we have time to tweak and make it fun. On the plus side, I’ve learned that lesson (for at least the second time now! :)) and will be able to remember this instance to hopefully keep it in my mind going forward.

What’s Next

In the end, we feel our game has a pretty fun mechanic hidden inside of it. We’d like to tweak some of the known issues (spamming lava is an auto-win, no visual indicator to know how charged up your lava is) and add touch controls. This would allow us to release the game out for mobile devices as a little time sink. We’ll definitely need a scoring system, and a way to indicate that fun you’ve lost. The win sequence needs some work as well.

Team Thoughts

Barry:

“I was very excited for this Jam and challenging myself with Ashley ECS. While I’m disappointed in my output for the Jam, I was able to build out some pretty generic Systems and Components that will be useful for games in the future, and I plan to clean them up so I can open source them as an additional library for other libGDX developers. I’m very proud of the work our team produced, and I hope the shift in focus on Art and Sound comes across for those playing our game. It was an exhausting, humbling, stressful jam for me, but as always I’ve learned a ton and am even more ready to jump into our next projects.”

Loi:

“So, the whole week leading up to Ludum Dare 34, I was filled with excitement! Excited to create something new! Excited to take a break from RCG’s personal 3D project and get back into designing 2D characters and environments again. In the days leading up to the Jam, I started playing around in Spriter 2D (an animation creation and management program that I had been wanting to learn since the last Ludum Dare), because I was looking forward to making a hack and slash. Spriter 2D would have been perfect for animating action frames, as one of its unique features is bone-rigging and attaching them body parts and objects. Spriter 2D was very productive; it saved me a lot of time with image file management, ease of exporting animated frames, and having a simpler, yet more extensive, animating options that were non-existent in Photoshop. It allowed me to focus more on content creation rather than spending a lot of time on filename and manual frames export, which can be tedious and time-consuming when you trying to create a smooth animation sequence.

As always, I wanted to challenge myself to a new art style every Jam. This time, it was watercoloring in Photoshop. I haven’t used watercolor paint since I was a wee-lad, and picking it back up again felt a bit strange, especially now that I am doing it digitally and my paint brush is my tablet pen. The hardest part in the beginning for me was getting the brush settings just right to give it that wet outer-edge water-effect look. Below is my custom brush settings that I used throughout the Jam (works best with a drawing tablet, as it emulates brush pressure and strokes). It was nice to use watercolor inside of photoshop without the mess to clean up afterwards”.

BrushSettings

 

Thanks for reading, Thanks for playing,

–Barry, Roaring Cat Games

 

[cache: storing page]