Nominated for a Technical Excellence award at the 2013 Independent Games Festival later this month, LiquidSketch is a unique iPad puzzle game employing impressive liquid physics that developer Tobias Neukom tells us was a beast to get right.
As part of our Road to the IGF series, Gamasutra is speaking to each of the finalists in the 2013 Independent Games Festival to find out the story behind the games. Today we speak to Tobias Neukom, whose iPad game LiquidSketch is nominated for the Techncial Excellence award thanks to its impressive liquid physics.
I don't have any professional game development experience, but I tried to write games in my teenage years. Of course to make a game you first need an engine, so that's what I worked on. I never got to the stage of actually writing a game with it. In fact, I have a 6,000-line project from that time that displays an empty window and doesn't do much more; it's all just framework stuff. I wasted months thinking about arcane problems on how to make some kind of plugin architecture. At that time it seemed like everyone wanted to write an extremely extensive engine where you could configure everything to make every possible game. It's pretty hilarious in retrospect. It was still a lot of fun and led me to study mathematics. So the one thing I learned was to get things done instead of trying to make everything perfect. I do have programming experience though, and I'm studying math and physics as a minor. Both were extremely useful. James Primate, who made the music and sound effects for my game, already had experience with making music for other games. For example, he made the music for Junk Jack and Tangled.
I didn't use any tools specific to game development. The code on the device is nearly all C++ and a little bit of Objective-C and my IDE was Xcode. I used some small libraries to parse JSON but not much more. For graphics stuff I used Gimp and Inkscape. I also made an editor for the puzzles in C#. If I would start again I probably would try to find a library to make the game interface and handle sound. Something like Cocos2d would have been perfect for my project. But I tried to keep everything as portable as possible, which meant making as much as possible with OpenGL and OpenAL only. I now think that this was a mistake. In my opinion it's better to get something done first and then try to make it portable. I also thought making a GUI system from scratch would be easy; after all it's just a bunch of buttons and text. But it was a lot of work, and it's difficult to expand on it now. Font rendering alone is a challenge. I could have saved a lot of time by using Cocos2d or something similar for the interface and it would be easier to add new features now.
I always wanted to simulate water on a computer so I tried different methods in the last few years, with the thought of using it to make a game only in the background. The first few attempts didn't really work that well. Then I found a method that finally looked promising. It still had some problems, but with some improvements to the simulation method it was already quite fun to play around. So I decided to make a game with it. At first I wanted to make a game where you have to bring color back to a painting that has been rendered black and white, by guiding the liquid to the correct locations. But then I remembered that I don't have any artistic talent, so I decided to make it more abstract. One of the cool things about my simulation is that it can simulate low viscosity liquids quite well, so you can really see the intricate motions inside the water. I found it difficult to display this motion in a beautiful and natural way. So I added the colored water idea from the original art concept to the game without the images, but with the gameplay possibilities.
I have been experimenting with water simulations for a long time. About one and a half years ago I had something usable that was fun to play around with. I chose the iPad as my target platforms because controlling the water by touching it and throwing it around and changing gravity using the accelerometer sounded really immersive compared to just using a mouse. So I ported the simulation code to iOS. It didn't take me long to get it running on the iPad but it still required a lot of optimization to work smoothly. After about six months it worked really well (I didn't work on the game full time at that time). Then I started working on the actual game full-time, which meant implementing the color mixing mechanic and the rendering, making levels, and the sandbox mode. This took another six months. After that it still took until September to get the trailer ready, write the App Store description, get it accepted on the App Store, write emails to the press, and so on.Have you played any of the other IGF finalists? Any standouts?I played Bad Hotel, Super Hexagon, Little Inferno and Perspective. Obviously I liked Little Inferno a lot because it's also based on a fluid simulation, it looks very cool. But my favorite is Perspective, a really fantastic puzzle game. In most puzzle games you have to make some kind of plan. What to do first so something else works, what you can't do first because something else will fail... You make a plan, try it out and if it fails you find the problem and improve your plan. Most puzzles games work like this, mine included. So I appreciate something different. Perspective is more about understanding the geometry of the level and how the projected level changes when you change the position in 3d space.
I never thought about that, when you have a specific example it's usually not very difficult to decide if it's indie or not. It's difficult to find a good general definition though. I would say if the concept is something someone wants to make not for money but for some internal reason. That doesn't mean I would exclude people who hope to make a lot of money; of course, I hoped for that too. But there should be an initial spark to make the game different from making money. In my case that was simply that I like fluid simulations. I would say that having few resources is required too. If you have a big stash of money lying around and you are creating your dream game with it, it shouldn't be called an indie game.
I wrote all the code myself. But the method itself is of course not only by me. I started with a paper by Robert Bridson and Yongning Zhu called "Animating Sand as a Fluid." Using the exact technique in the paper already yielded good results. It had some problems though for which I tried to find solutions. The biggest problem was that the volume of the water didn't stay constant. It kept getting smaller and smaller. For my puzzles it's quite important that the volume stays the same. I added a correction to fix this problem. Another addition from me was a nice way to add pumps to the simulation. That might sound easy, but there are a lot of situations where you have to make sure nothing strange happens, for example when you are pumping water in a closed container. But most of the development was finding lots of small changes and "hacks" that make the simulation run fast and stable for my game.
The water is slightly compressible. I did this because it makes implementing pumps easier and it makes it easier to make the simulation crash-proof. But you won't notice it if you're not looking for it. The water picks up paint from the background. Realistically the water should get darker when it picks up more paint. If you add enough paint it will go to black and stay that way forever. From a gameplay perspective this sucks. So I don't do this, and instead it behaves more like it would if you mixed the two colors on a palette. If you have black water you can let it flow over red paint for some time and it will turn dark red. Doesn't make a lot of sense but it's more fun!
Well most real liquids don't suddenly explode or vanish, that's enough for me!
Read more about:
event-gdcYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
