Developer Interview: Imminent Games release of Drip Drip!

Developer Interview: Imminent Games release of Drip Drip!

We got a chance to do a virtual Q/A with Imminent Games on their new title Drip Drip, which was made with Torque 2D. It is available on Windows and the Mac, and they are currently porting it to iOS. There is also a Steam Greenlight page available for it. If you're curious about what goes into making an extremely polished and fun indie game with fluid dynamics, then this is the interview for you!



Please describe Drip Drip in your own words.
Thomas & Blake: Drip Drip is a strategy indie video game with RTS inspired controls for the PC and Mac that provides a unique water simulation twist to the time management genre. The player takes on a management role of the Disaster Response Team and has to save buildings from all the water pouring in. The player creates and manages a team of containers and tools in order to save the buildings from extreme flooding and destructive water damage. The player will travel across the USA and visit 24 cities on their mission to ensure the safety of each building from severe storms and their devastating weather conditions. From inside small houses to towering skyscrapers, containers like pans, buckets, and barrels will have to be moved around the floors to catch the dripping water and then be emptied to save the buildings. The water dumped out of windows will earn money so other containers and tools can be bought to keep the buildings standing while withstanding a constant barrage of pouring rain and never-ending threats.

What was your role on Drip Drip?
Thomas: My name is Thomas Konkol and I am the Founder/Owner of Imminent Games. My role in the development of Drip Drip is a big one since there are only two people working on the game. I am responsible for all the art, animation, game design, level design, sounds, play testing, quality assurance, advertising, and taking care of all the business aspects. It's a huge list when you are a small indie developer and have to wear just about every hat in the industry.

Blake: My name is Blake Drolson, and I handled all of the programming for Drip Drip. In addition I have also contributed to the design of Drip Drip as it has evolved from an initial game concept to the point of being a finished shipping product.



What makes Drip Drip unique?
Thomas: The concept of the game where the player has to move animated containers around the buildings to catch dripping water and then unload them when they get too full so the growing amount of water does not destroy the buildings.

Blake: Drip Drip is unique because of its water simulation based gameplay, and the game concept relating to how the water moves thru the level or building, creating new gameplay dynamics and strategies never seen before in another video game.

What was your inspiration to create Drip Drip?
Thomas: I got inspired to create Drip Drip when I was driving across country from Chicago to Southern California to relocate for a new job. While going through Texas it started to rain and I was watching the drops hit the windshield. I then started to wonder if there was a way to make a game out of water dropping. The idea stuck with me for the rest of the trip as I went over many game possibilities in my mind while driving down the expressways. The falling of the rain turned into the idea of dripping water, which then lead to water leaking from ceilings in buildings and the damage that could be done to such buildings. From there it evolved to ways the water could be collected and deposited outside of the buildings so the basements wouldn't get flooded and the floors wouldn't collapse. And since I was on a cross country trip when I got the idea it inspired me to make the game so it takes place across many cities in the USA.



What was your development process like?
Thomas: After coming up with the idea I created a design document to lay out everything I thought was going to be in the game. Then I began to work on characters for the game. Drip Drip was actually going to have people moving around the buildings to place and empty the containers. I got rid of the people because I wanted to simplify the game play and decided to give life to the containers and other tools. This helped to give the game a more cartoon feel, which is what I wanted from the start. I then sketched out all of the containers and tools. After knowing what characters and objects were going to be in the game, I made an animation list for each of them for all of the moves they would need. I started working on the animations and in the meantime also researched buildings and cities.

I wanted to stick with well-known cities and give them a building that sort of represented their location. So I decided to use buildings like a farmhouse in Topeka and tall skyscrapers in Chicago and New York. I also had to decide on how to create the textures that would be best for creating the buildings. I decided on a 256x256 tile system that allowed me to reuse some tiles throughout the buildings. To keep things simple I made sure all of the windows were the same height from the floors so that all of the container “unload” animations could be used for all of the windows. During all of this I created simple no detail textures that we then used for quick testing purposes to make sure we were on the right track. It helped in nailing down quickly the format in how the textures should be made for the final product. For example: the floors of the buildings are actually at the top of each tile texture.

I then created the Drip Drip logo and the art for the menu system. We created a flowchart of what the menu system did. It allowed us to quickly see where each button would take the player next, and also if we were missing anything.

We started putting sounds into the game about half way through the project. After going through many sound libraries and scouring the Internet for the best sounds to represent each action, I took them into Audacity and adjusted all sorts of settings. I also combined sounds to create new ones. For example: the rubble crashing to the floor is made from three sounds combined together.

After we got the main game play system in and most of the final art in, I started to create particles using the particle system in Torque. I would create the textures in Photoshop and then import them into Torque. Once I got a handle on all of the abilities the particle system offers it was easy to create many of the effects that are seen in the game. These particles give the game even more life and add another layer of polish to the game. It was very nice to be able to add the rain particle to the menus to carry across our rain theme throughout the entire game.

Along the road of our development, we had people play test the game to see what they thought, if they would have problems playing it, and other bugs that could be found. This proved very beneficial right from the start. During our first play test I found out that no one wants to read and so I had to scrap our tutorial. This motivated us to create the current playable tutorial, which people like much better. We also got rid of the zoom in and out feature because as soon as people would start playing they would zoom out as far as possible and leave the camera there. We found many bugs because people play the game very differently than we do so it helped in catching those bugs we may never have found. The testing also helped in seeing how the game ran on different computer configurations.

Blake: To make Drip Drip come to life, we started out by taking the buildings created by Thomas, and laying the levels out in TGB’s design tool, into building tilemaps and very simple level files. We then spent a good amount of time getting containers to walk around the building, getting our custom A* pathfinding code up and running. After this we created our water drop and puddle system to handle the water simulation that is constantly running inside of the game. From there we added the interaction of puddles to make floor holes, and added new water threats and threats to your containers such as the ghost and UFO. We also spent a good deal of time working on the interactive tutorial and the game menu screens, including doing 3 revisions on the games menus. We also worked on optimizations for a while, writing custom script timing code that resulted in a critical speed pickup for the games frame rate. I think we spent a lot more time than we expected working on debugging and polish, but in the end it was worth it ?.



How many people worked on the dev team? How did you work together?
Thomas: There were two of us, Blake and myself that worked on Drip Drip. Since we live in different states, we used Skype to talk to each other and also the screen-sharing feature. We used Scriblink for a white board that we could draw and write ideas on to show what we were thinking. Both of those programs worked great for our needs to make the production of Drip Drip move along.

Blake: Yeah Skype was critical for us of course as remote workers, and the whiteboarding of Scriblink really helped us understand each other in design discussions. We used dropbox as a simple way to share builds or new art. I am very thankful for modern tools making remote working feasible, its gotten much easier to do in the last 5 or 10 years.

How long did it take to create Drip Drip?
Thomas: I had the idea for Drip Drip for many years before production started and just slowly added to it as time went on. After we started working on Drip Drip together it has taken us about 3 years to complete the PC and Mac versions.

Blake: We thought we were just about done after about 1.5 or 2 years, its amazing how far the game has come along with further polish and refinement that we had time to do because we were an indie controlling the development schedule. We were working on our game not only as a business but also as a creative work that we were very attached to, and wanted to create and release it to the world with as high a quality as we could.

How did you accomplish QA and beta testing?
Thomas: Blake and myself did all of the QA and beta testing along with family and friends. We got a lot of great feedback each time we would have a new build played and tested. It was just a matter of either using Dropbox or a USB drive to give a new build to someone to test. It was very beneficial to sit down and watch how people played the game.

Blake: One thing that was critical for us in raising the quality of the game was catching the bugs that would happen very intermittently. We had recurring problems of things that would happen once every 10 times you might play, containers walking out of the building, or hanging in the air. It always turned out to be a rare combination of game states happening at the same time. To solve these issues, what I had to do was write up a system to create debug logs, one per game object. Because the logs would be sorted by game object, such as for one bucket or one water drop, I could trace the state of the object over time and get a trace on all function calls that involved the object, and its current data state. Then I could receive a screenshot of an intermittent bug, with a graphic label being displayed for the objects ID that was in an error state, and link that to the correct debug log using the object ID. Once I was in one debug logfile, I knew that all the logging there was about that one object only. The logs were all made with high-resolution timestamps, and sometimes I was a detective tracing back thru a few objects logs that were involved with the current bug. This system of debug logs was critical to help rewind events once they happened so I could figure out what went wrong in my game logic. I am not sure if anyone else has created such a system, its fairly low tech, but I am willing to share it with the community here, if it’s desired.



What software/tools did you use to create the game? Why did you use those particular tools?
Thomas: For the engine we used Torque 2d for the PC and Mac. And we are currently using iTorque 2D for the iOS development, which we are in the middle of production for. I used Photoshop for all of the art and design creation. For the music and sounds I used Audacity along with many sound libraries.

Blake: As far as tech tools go, we used a bit of Visual Studio to modify the core engine as needed, and basically I lived inside of Torsion. I can’t say enough about Torsion because the same game wouldn’t have gotten made without it, a critical Torque tool.

Describe 2-3 of your biggest technical hurdles and how you overcame them. Give as much detail as possible, to the point of getting extremely technical.
Blake: Well, I would say the two biggest technical hurdles were related to wanting to raise the games level of polish, and to raise the games performance. In terms of polish, it was necessary to squash all bugs and that lead to the debug logging system I created and described earlier.

The other issue we had was getting the performance of the game raised to a playable level on an average player’s PC or Mac. In terms of optimization we had to first look at what was happening when the frame rate was dipping and dig into it. For instance we realized we were over rendering the changes to the player score, more than was needed. When we pruned that rate back to a more reasonable level, our performance was much smoother. This was optimizing at the macro level of game events, and we did this in a few areas.

I then did some profiling using quickly written script code and a high res timer added to the engine, and this allowed me to get a rough sense of where we were spending our simulation time. It turned out that the time sink was figuring out what happens to water drops when they land. This led us to two things, first I optimized the most critical pieces of code in the function of water drops moving and landing. This led to significant gains in game performance. The other thing that came out of that discovery was the creation of a variable rate water drop system. On an older system, when some game events would happen that would lower the frame rate enough, the game would get in a death spiral trying to calculate a backlog of water drop events, trying but unable to catch up. By variably lowering the rate of water drops being emitted when the frame rate got low, it allowed the game to escape these death spirals of performance.



Would you look at IndieGoGo or Kickstarter for future projects?
Thomas: Yes, I would consider IndieGoGo and Kickstarter for future projects. I think it is great that those types of opportunities are available for indie developers. Not everyone has the funds or resources to self fund their projects. They are also a great way to get public reaction on if the idea will be something the public might want to play.

Blake: Kickstarter and IndieGoGo were not really big when we got started on Drip Drip, but we are certainly excited by the future possibilities that those funding platforms bring in terms of reaching out to a potential player base. Funding development efforts on your terms by reaching out directly to your future players, freeing you from overly restrictive publisher schedules, and making the game that you and your fans want to get made is a great change for indie game development.

Give us a good synopsis of what you want players to experience when they start up Drip Drip.
Thomas: I want players to have a fun and unique game play experience with Drip Drip. I also want them to have a good first impression on the quality of the game during the menus they navigate all the way into the first few levels where they will learn how to play Drip Drip. I think the players will like the look of the art and levels along with the feel of the game play. We worked hard at making the controls for Drip Drip as simple and spot on as possible. The entire game can be played with the mouse alone, but we also give the player the choice to use a keyboard if they desire. The controls are very tight, in that, the containers go exactly where the player puts them and without any lag.

Blake: I hope they feel like they can quickly slip in and play a quick level or two. Drip Drip loads fast, and hopefully we have imparted some classic arcade quick play fun. The rain effects are cool, and its nice to play a non-violent game centered on challenges from the weather.



Tell us why players will keep coming back to Drip Drip again and again.
Thomas: I think players will want to come back to playing Drip Drip since it is a unique game with a fun game play system that is easy to control.

There is a five star rating system for each level that players can try to get a perfect score on. Each star is given for performing certain tasks within each level. Drip Drip has 44 achievements to unlock and one of them is getting five stars on every level, so there is a lot for players to do if they want to complete every part of the game.

Drip Drip has three difficulty settings so if a player finishes the easy or medium setting there is still more of a challenge to complete with the hard setting. And the hard setting can be brutal in the later levels with a lot going on to keep the player very busy.

Blake: As the game gets harder and harder, mainly thru difficulty, but also thru the level progression, new strategies emerge to try and beat what the game is throwing at you. I think its fun to discover those on your own?.

Help support the Steam Greenlight for Drip Drip!

And don't forget to buy your copy of Drip Drip now!