If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource
Arkwright, inventor of the world famous Fluro (mechanized-fluid automaton) is on a quest to finish his next great invention - The Device - that will alter existence in unfathomable ways.
Travel to different industrial sites that use Arkwright’s Fluro invention to run their machinery. The Fluros, thought to be lifeless machines, seem to be developing minds of their own,mutating into new forms and running amok. It is up to Arkwright to understand (and exploit) these strange evolutions, and apply what has emerged in the field back to his lab work at home. Gather these evolved Fluros and machinery and bring them back to Arkwright’s lab to finish his ‘Device’, pushing the frontiers of science in this steam-punk universe.
‘Vessel’ is built on a physics and fluid simulation engine featuring the unique ability to simulate characters composed entirely of fluid. Explore physically modeled worlds, solve puzzles by controlling fluid and machines, and harness the power of the mysterious ‘Fluro’ creatures that populate the land. [From IGF info page]
Interview with John Krajewski
Who are you and how are you involved with Vessel?
My name is John Krajewski, I'm project lead on Vessel. I work on the simulation and gameplay programming, and manage design and production.
How did you become interested in game development?
It all started back on the commodore 64, typing in programs in the BASIC programming language. Games were my life as a kid then and making my own was kind of the natural extension of that.
How and when did the concept for Vessel originate?
Vessel started life as a physics engine I was writing, starting with basic stuff like objects moving and colliding, and as I kept adding things it got more and more interesting. By the time I started to get fluid working and fluid characters I saw the potential for Vessel. The concept and the story kind of grew out of that - I feel its important for the mechanics of a game and what it's about to be intimately linked and intertwined, to give it a natural and meaningful feeling, and that's what we've tried to do with Vessel.
Over the course of development, what was Vessel’s most serious issue and how was it resolved?
That would probably be the speed of the simulation. At first I made a regular object simulator and that worked pretty well, and then I added fluid and that worked well too, but together they were enormously slow - fluid interacting with objects created a lot of difficult collision problems that brought even top of the line machines to their knees. The solution was a lot of research, finding algorithms already out there and adapting them to our purposes, as well as inventing new techniques for the specifics of our engine. Things are much faster now, but we still want to continue improving it, and that's what I'm working on now, using multi-threaded hardware to get the maximum fluid volumes we can without sacrificing interactivity.
Were there any sites/books that you would routinely visit in your research efforts, or did you mainly pull information from a wide variety of sources?
The GameDev.net forums were a huge help, it was surprising the quality and depth of advice I could get and get quickly (and not just because GameDev is doing this interview A lot of the white papers and things I used I found on recommendations from the forums. I've also got a lot of use out of the book Real Time Collision Detection by Christer Ericson. CodeProject.com has been a big help for tools code.
Did you experiment at all with 3D? Is the 2D a design choice, an engineering choice or maybe a bit of both?
Definitely both, fluid can be a performance hog and removing the z-dimension gives us the ability to get a lot more fluid in the game space. 2D was also more appropriate for the type of game we want to make, a puzzle platformer, so it was an easy choice. That said, we do plan to use 3d techniques in rendering that should be interesting – normal and specular maps on the objects for example.
What’s one thing you did wrong (individually or as a team) that you feel could have been avoided? How?
There were some design issues we found out were glaringly obvious to people but were completely invisible to us. Being so close to the project for so long it's easy to forget things that someone just approaching will notice immediately, and we missed a few of those we shouldn’t have. We could have avoided this by doing more playtesting, and doing it more frequently, before things were finalized. This can really help set our direction and it’s something we plan to do a lot more of.
Speaking of design issues, what were some of the methods you employed to mitigate/control the simulation during playtesting so you could re-create situations that evolved out of the fluid dynamics?
That’s one of the biggest design challenges, finding a way to setup events and get a desired outcome when the game is run by a simulation. That doesn't mean it's out of our control though,we have to design a layer back, setting up the environment to produce the desired game result through the simulation. This gives up some control but there's still a lot you can do, and we try to embrace the emergent nature of the system by making goals more abstract, and achievable in different ways.
You also have to consider contingencies, what can go wrong since its all simulated, and one of the ways we handle that is to make the puzzles self-healing. So for example if you have a creature that you need to do something with and he gets splattered, another one will be naturally generated somehow that makes sense in the environment. Rather than kill the player and set the simulation back to start, we try to make levels automatically renew themselves as much as we can.
If there was one thing you could look back on during development and say “that was really cool” – what was it and why?
The first time I got fluid working was a huge moment. Opening a flood gate and seeing a mass of water flow and splash and churn, pushing objects away, forming waves naturally that crash and recede, all these beautiful things you expect from real fluid that were now taking place from the equations I'd written. When writing code for dynamic fluid, you basically control a single drop, tell it how to move given its situation, and macro-level effects like crashing waves appear naturally from the interaction of the drops, there is no 'CrashWave' function. So seeing that was a great moment. It was out of my hands a little bit at that point, these effects were happening emergently from the system.
How long has Vessel been in development? How much development time remains?
Our team has been working on the game for about a year now. Before that I worked on it part time now and then for a few years. There's a lot we'd still like to add to the game before we officially release it, so it'll probably be awhile before we ship it.
What was used to make the game and what tools aided in development?
It was written in C++ with Microsoft Visual Studio, and uses Direct X for rendering. Art side, we used Photoshop, 3dsmax, and Z-Brush. We're still experimenting with the art style but we think we can get some really interesting effects by combining 2d graphics with 3d techniques like normal mapping.
In regards to the engine, were there any 3rd party libraries that you used to help piece it together or is it completely home brew?
The tools, simulation, and rendering are home brew. We used FMod for audio and boost libraries internally in the physics engine code, for calculating graphs and things.
Have you considered whether or not you will be licensing this technology for other developers to make use of?
That's something we'd like to do. We'll have to see what kind of demand there is for engines like ours and if it represents a need not being covered. We'll have to finish Vessel first though.
What's the main thing you think makes your game fun?
The interactivity. Everything in the game exists in a physics simulation and is maximally interactive. The fluid characters especially - they are characters whose form is made of simulated fluid,and every particle they contain is simulated and interactive with the rest of the environment. I believe when game mechanics behave naturally following rules, like our physics simulation, you get a lot more meaningful interaction because the player can understand the workings of the world and make predictions for the results of their actions. That's the source of a lot of the puzzles and fun in our game and any game I think - exploring these deep simulations and trying out actions based on your understanding of it.
Besides the IGF, what else have you done to get your game before players? What’s worked the best?
We're not quite ready to send our game out into the ether yet, so IGF will be a first look!
How did you feel about the judge’s feedback for your game? (this year compared to ones past, if returning finalist)
The feedback was extremely helpful. As I said earlier, being so close to a project can make obvious problems invisible. We got paragraphs of feedback from some judges and it was really useful to hear it, both good and bad.
Seattle has a really great development community. How has your location helped you and your studio?
I went to school here at University of Washington, and started in the game business here, so I know a lot of other game devs in the area and that's been a big help. Some of them have left their companies to begin startup studios as well, and hearing their experiences is extremely useful, since otherwise I have no point of comparison. Having Microsoft in the area too is also definitely convenient, depending on the platform(s) we end up on.
What’s next for you?
Finishing Vessel! We're going to be making a lot of additions and changes and hopefully get it on a console.