Get it from our team page here. Let me know if you have trouble with it!

Our initial concept was a goldfish swimming against the current down a sewer tunnel, with the option of whether to swim upstream or downstream.

Early prototypes showed this mostly worked, but I couldn't figure out an intuitive damage system. If you're swimming upstream, colliding with something coming downstream feels dangerous, so it makes sense to take damage. But when you turn around, you have very little motion relative to objects in the flow, so it feels more like you're bumping into them than colliding, and that feels unfair to take damage for. We wanted downstream (farther into the game) to be more challenging than upstream, so this felt backward. Maybe something really dangerous to touch like acid barrels would have made sense, but they're still coming at you faster when you're swimming against the current. Anyway it was a design challenge I never worked out.

This mechanic is still in the game, but obstacles only appear in stretches where you're forced to go downstream, and you're going fast enough that it feels fair to take damage from a hit. However, I was finding it to be more fun to smash into obstacles than to avoid them, and the game was long enough that I didn't want you to have to replay many sections. So I took out the health meter altogether and just hoped players would still have fun with it even if there's no threat of dying.

Meanwhile, it became clear we could do more interesting layouts than just back and forth. We also wanted ways to manipulate the current rather than just riding it, to integrate with the "Flow" theme better.

Here we took a lot of inspiration from The Legend of Zelda series, which has a few well-known sewer sequences and water dungeons that involve changing the flow of water. (In fact I was pleasantly surprised that the mechanic we wound up using isn't just a copy of something I've seen in a Zelda game before.)

From there I focused a lot more on the exploration than the action, and the game came to focus more on the rooms than the tunnels connecting them. One thing I worried about was players mixing up different areas or just having trouble finding their way around. I tried to imagine how we could give different feels to different sections by changing up simple things like room size and flow rate. By Sunday night I had this sketch.

The idea was that you would unlock abilities after beating the various challenges, that would let you gain access to new areas, but it still wasn't clear how you were supposed to manipulate the flow. On Monday I decided to sketch a concept for the final boss sequence, trying to think of how you could possibly use flow rates to escape a confined area.

This sketch turned out to be really useful. I was still trying to imagine what would go in the various sections of the game. One game design idea I've heard is that the final boss should be a "final exam" of everything you've learned to do over the course of the game. I took that to heart here for the first time, and worked backward from the final boss by considering what you should know before you get there. That's why there's one section with whirlpools, one section with a semi-fixed camera view, etc. I definitely plan to try this approach again.

It took a while for EnigmaticArcher and me to settle on the flow mechanics we actually have. We were originally planning a couple ways of raising or lowering the water pressure in a room, switches to open pathways and close others, changing the water height, etc. But we were having trouble making any really interesting challenges out of it. Finally we got one that just involved a "fish food" powerup to let you swim up, along with the draining from the boss battle. This is way simpler than what I thinking, and I think that's mostly good. I'm a little worried players will be able to beat the challenges without really understanding the mechanics, just by taking available options and getting lucky sometimes, but that's better than being completely stuck. Anyway I was able to fill in the areas with layouts that felt different enough for my taste.

Once I knew what we needed I spent a couple days just on the level editor, but it was definitely worth it. By the time I got to actually making the layout, I'd imagined it so much that it only took about an hour for each of the six main areas of the game. (In fact I never implemented a way to remove a room or tunnel once it's added, and somehow I managed not to make any mistakes.)

One thing I like about the draining mechanic is how it naturally works to track your progress in the central room. The action of returning after a challenge is the same thing that gets you closer to opening the final boss area, and the waterfalls in the room are a handy way to know which challenges remain. And it's a lot better than keys or something, thematically speaking.

I'm proud of the camera system. I wanted a good automatic camera for people who didn't want to bother with controlling it, but mit-mit wisely requested a manual camera too, because it's so easy to mess up the camera in a 3d game like this. I was able to get both in, including a few different modes for the automatic camera depending on the feel I wanted, and I think they all integrate pretty smoothly.

My biggest regret is that I never figured out how to make the action sequences very fun. The one at the very end in particular was way too long and narrow, and I was running low on time so I just cranked up the speed. Now it's basically impossible and even less fun, but at least it's over quickly.

It was pretty frustrating when the save/load feature stopped working on the last day (especially since the same method would allow you to reset the puzzle). For a game this long with this much in the way of graphical demands, you can count on a few players getting crashes or glitches before the end. So the cheat codes were an essential last-minute design hack. I just hope players are okay using them.

There are a definitely a few rough spots I wish I'd had more time for, and it certainly could be tweaked to improve the challenge and fun level, but there's also a lot of details I really like about this game, and I don't think there are any horrible design flaws, unfair challenges, or excess filler content. Overall I'm happy with the result.

Thanks for trying it out!

Playthrough video for the game is now available at:

https://youtu.be/Vi7i3Ji4ZW8

Just wanted to write down a few notes and interesting points about the development of the visuals and 3D modelling for our game:

Game Visuals:

Cosmologicon and EnigmaticArcher had the game concept sketched out very quickly with a basic prototype up and running on the first day, which made doing the visuals fairly straight forward. Part of the challenge of the visuals was to try and make environments that were dark and claustrophobic (inside a sewer) but still using a third-person view, so the camera is always outside of the room/pipe you are in. I started of with various designs of enclosed spaces, while using semi-transparency for all rooms, but it was pretty messy looking, so I compromised on keeping transparency only for pipes you are currently travelling in, while rendering the rest of the scene normally. The "pools" use low wall heights that are designed to give the impression that there is a dark ceiling above you while not getting in the road of the camera during gameplay. Rending of sections is limited to only those within a single "hop" (travel through a pipe/pool) to also keep a claustrophobic feeling. I had originally tried to blend in sections past this point, but ran into technical limitations trying to do this.

3D modelling and environments using OpenSCAD:

One thing I wanted to share which I think worked really well for us in this game was a pipeline we setup for automatically generating the 3D environment models. During the start of the week I was working on a bit of python code to generate sections of 3D surface models for the different sections of pipe (different shapes) and interconnecting rooms. I quickly found that working with all the complex geometries for nice looking environments was very challenging and time consuming so I changed tack. I ended up using OpenSCAD (http://www.openscad.org/) an open-source programmatic/parametric CAD package in which you can "program" complex geometries from a series of simple(ish) shapes. I ended up creating an OpenSCAD module (see tools/generated_section_models/build_environments.scad in the code) that has a series of functions that can generate the geometric models for each type of environment in the world using input parameters such as the length of the pipe, diameter other connecting sections etc. Our pipeline then for generating all of the 3D models for the world went something like this:

1. Use the flag "--build" when running the game to internally pull all of the level data (layout of the whole world) and generate a series of OpenSCAD scripts for building each section of the world and a single master shell script to run all of these (placed into tools/generated_section_models/scad).
2. Run the master script to use OpenSCAD to export STL model files for each section (placed in tools/generated_section_models/stl)
3. Run a final post-processing script (tools/generated_section_models/finalisemodels.py) to convert STLs to OBJ add in surface materials and texture the models (for the pools).

The final model files are then imported into the game next time is run. The process wasn't lightning fast, but it did allow the level designers (Cosmologicon and EnigmaticArcher) to quickly and automatically re-generate all of the environment models whenever they made changes to the world, right up until the final hours of the competition. This is something that I think I would definitely do again for 3D games with lots of environment like this.

Hope you enjoy our game!

Thanks for the feedback, everyone! I think there are some lessons learned here. First, a couple things I think there are quick fixes for:

• Out of bounds bugs.
• Performance.
• "When swimming against current it's kind of random what direction key you must use" and "the controls sometimes seem to steer in the opposite direction" - I strongly suspect these players were using the manual camera mode, where the direction an arrow key takes you depends on which direction you're pointing the camera. I can easily imagine controlling both at the same time is hard for many players. It might be best to force automatic camera mode for some parts.
• "The whirlpool part was frustrating, especially because I didn't realize that you could get the fish food by swimming closer instead of trying to jump above the hole." - In this case putting the fish food around the first whirlpool instead of the last one would have let you experiment faster.
• "that puzzle level... I think you needed something that could be done and undone to make it more puzzly" - absolutely, this was planned, we just ran out of time here. I suspect most people had to skip this section, so maybe it should have been cut entirely.

"The boss level... was not challenging" vs "I couldn't figure out the octopus". I agree the boss could use some tweaking. Right now the tentacles are just there for decoration, but they could be actual hazards. There's no health meter or way to die, and this was done as a stopgap to deal with the lack of save function, but I kind of like it. I wonder if there's a good way to add a challenge without requiring a lose condition. Perhaps  have a timer that closes drains you've opened after a time. Any other ideas are welcome.

It seems like most people didn't find a need to bother with the core water pressure mechanic, which I understand (although I'm surprised if you managed to beat the puzzle without paying attention to the pressure). I was worried this would happen and I tried hard to force players to watch the pressure level in the tutorial, but I didn't really succeed. There may be a way to salvage it, but ultimately I think this mechanic doesn't work 100%, and I would replace it with something slightly different. I don't have any great ideas, though.

I don't think we really made any mistakes in choosing this mechanic, it just never quite came together despite several iterations. It happens sometimes in PyWeek!

Now, about navigation. This is a very important topic for me. There were mixed responses in how difficult the game was when it came to finding your way. Ranging from "playing the game properly would require lots of notes and graph paper to plot out where you are", to "the game just solved itself". Overall, though, it does seem like a little more help not getting lost would have improved things.

To review, the game has six sections: a tutorial, four challenges that can be completed in any order, and a final boss challenge. They're all connected by a large room in the center of the map. I wonder whether people were having more trouble finding their way through each section, or finding their way between sections (e.g. knowing where to go next). But each section is fairly linear so I tend to suspect the latter. I'm glad I spent time getting the minimap and main map working, because I think they both help keeping track of how the different sections connect, but what more could be done? Two ideas I have are closing off paths to challenges that have been completed, and putting a label on the minimap showing what area you're currently in.

My big question is whether having one large connected world contributed to the disorientation. We could easily have made the game six separate levels that you select from a menu, but I really like making a single seamlessly-connected world whenever I can. It makes the game feel more complete somehow. None of the judges mentioned this aspect negatively or positively, so maybe it's just me. But I'm interested in what I can do to make it work.

What about appearance? One comment references Colossal Cave Adventure with "it's a maze of twisty little passages that all look alike". I'm guessing was meant negatively, so I wonder whether making the different sections have somewhat different appearances, say with different textures, would have helped. My first thought is that limited graphical range shouldn't necessarily be a problem for PyWeek. Nobody gets "lost" playing a game like Dynamite Valley or Deep Breath, even though every level has pretty much the same graphical assets. But maybe making a game where navigation is involved means also committing to more graphics.

I'd be happy to hear any further thoughts people had about this!

Big thanks to mauve for putting this on, and congratulations to the winners and everyone who entered!