I've just realised that I can only get comments if I have diary entries!  Would love some feedback on my little creation. 

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!

Sorry to anyone who played Time Chicken and was frustrated that the "Kukareku" spell didn't work.

In the last 10 minutes before submission (as all good game-breaking stories start) I changed the image "Assets\Images\spell3.png" to be a 1x1px image so it would be invisible.

Foolish. It's too small for the spell to successfully hit anything.

Simply change the image to anything bigger than 1x1px and it will work (e.g. copy "Assets\Images\rock.png" and rename it "Assets\Images\spell3.png" or ideally replace "Assets\Images\spell3.png" with a 100x100px transparent image)

Doesn't ruin the whole game but kukareku (a high-damage, close range attack) is useless without a patch.

Thanks all!

Playthrough video for the game is now available at:

https://youtu.be/Vi7i3Ji4ZW8

I just noticed that you can only comment on entries that have diary entries, and I did not have any diary entries. I know of some of the problems this game has, but I am open to criticism from the rest of you. I have made a couple of tries in previous pyweeks and the feedback I received was overwhelmingly helpful and supportive. I am looking forward to playing all of this week's games.

Haven't been able to test the game on macOS, Linux, or different machines so I can only hope the experience has been smooth.

I updated the description with some vague clues for running, please let me know if there are any issues.

We've rewritten the README.md for Dynamite Valley.  I've pasted it in below in the hope that PyWeek participants will see it and have a better time playing Dynamite Valley as a result.

The Player's Guide To Dynamite Valley

It's fall, and that means it's blasting season!

The beavers here in Dynamite Valley Park have been working overtime, making dams! If I've told you once, Ranger Jim, I've told you a thousand times--we need you to blast those consarned dams!

Guide Ranger Jim around a series of levels infested with beaver dams damming up the waters of Dynamite Valley Park.

"Dynamite Valley" is an exciting action game written by Daniel Pope and Larry Hastings for the "PyWeek 26" programming competition in October 2018. This guide will explain to you everything you need to know to play Dynamite Valley.

We sincerely hope you have fun playing! Now get out there and wipe out those dams!

The Basics

You play as Ranger Jim, a park ranger at Dynamite Valley Park. Your job: remove the dams infesting the park's beautiful waterways! With explosives!

Every level has a number of "dams" floating in the water. Ranger Jim has to destroy all the dams to advance to the next level. If you complete all the levels, you win!

The "Dynamite Valley" Guarantee

Both Dan and I played through the final version of the game, version 1.0.2. Every level is winnable! We guarantee it!

Note that on some levels you can put yourself into a situation where the level is no longer winnable. For example, on some levels you only have a limited supply of bombs, and if you misuse them the level may no longer be winnable. If you think that's happened, you should start the level over.

Also, the first zip file release of "Dynamite Valley" had a game-breaking bug. We guarantee that version *isn't* winnable! 1.0.1 had a minor bug that could be worked around. 1.0.2 and anything newer should work great!

Starting The Game

Dynamite Valley requires Python 3.6 or higher.

Check the requirements.txt for what you'll need.

Dynamite Valley needs both PyGame and Pyglet.

You might be able to install all Dynamite Valley's requirements automatically by running this:

    % sudo pip3 install -r requirements.txt

Your mileage may vary!

We recommend running Dynamite Valley with "python3 -O". Pyglet's Open GL support occasionally, if rarely, throws assertion failures. If you use the provided launcher `run_game.py` we do this for you.

Once you start the game, at any time during the title sequence you can press one of three keys to start your game:

T - Start the tutorial (recommended!).

N - Start a new game.

Space - Play the game starting at the last level you played.

Every time you start playing a level, the game remembers that, and if you exit the game and restart, pressing Space will take you straight to that level. (It won't remember where you were, though--it'll just reload the level from scratch.)

Keyboard Controls

In the game, you control Ranger Jim, a park ranger working in "Dynamite Valley".

"Dynamite Valley" supports the following keyboard commands in-game:

Up Down Left Right - move Ranger Jim, or change which direction he is facing

W A S D - redundant movement controls

E - interact with the object Ranger Jim is facing, like take a bomb from a dispenser, or pick up an inert bomb from the ground

B - drop a bomb, onto the spot where Ranger Jim is facing

T - trigger a Remote Control Bomb

Escape - pause game, bringing up the Pause Menu

F5 - restart level

F12 - take screenshot

Ranger Jim can pick up up to two bombs at a time. When he drops a bomb, he drops the bottom bomb from the stack. That's always the most recent bomb he picked up.

Dynamite Valley doesn't support joysticks or the mouse.

Bombs And Explosions

Ranger Jim does his work with bombs. As we all know, bombs "detonate", turning them into explosions which "blast" nearby objects. Specifically, exploding bombs in Dynamite Valley "blast" their four nearest neighbors (up/down/left/right). Bombs on land can still blast objects floating in the water, and bombs in the water can still blast objects on land.

Bombs that Ranger Jim drops are automatically armed. Ranger Jim can't pick up a bomb that's been armed.

There are four types of bombs in the game:

• Timed Bombs are the most frequently-seen type of bomb. They look like the classic movie bomb: a black circle with a small black cylinder near the top, and a fuse. They detonate 5 seconds after being dropped. When "blasted", Timed Bombs are "flung" one space away.
  
• Contact Bombs look like black spheres with little round nubs poking out in all directions. They're very sensitive! Contact Bombs automatically detonate when they're pushed into something, or when they're blasted by another bomb.
  
• Remote Control Bombs look like Timed Bombs but with a red ring around the small cylinder at the top. You detonate an RC Bomb with the "T"rigger key. RC Bombs detonate one at a time, in the order you dropped them--if you drop five bombs, you have to press "T" five times to trigger them all. Remote Control Bombs that are blasted are "flung" like Timed Bombs.
  
• Freeze Bombs look like Timed Bombs, except they're white and they have light blue snowflakes drawn on the side. They detonate 2 seconds after being dropped. Freeze Bombs that get "blasted" are "flung" like Timed Bombs. However! Instead of "blasting" their neighbors, Freeze Bombs "freeze" their neighbors:
  
• Frozen Timed Bombs and Frozen Freeze Bombs pause their countdown for 5 seconds.
  
• Frozen Contact Bombs are desensitized to impacts for 5 seconds.
  
• Freezing doesn't affect Remote Control bombs.
  

There are a lot of decorative objects that are immune to blasting and freezing: trees, rocks, and--strangely enough--beavers and bullrushes. However, you can destroy bushes by blasting them.

If Ranger Jim gets blasted or frozen, the level is over and you have to restart.

Water and Floating Objects

Most water is still water. However, some water is flowing in a particular direction. You can tell what water is flowing water by paying attention to the ripples in the water: when the ripples are moving, that shows you what direction that patch of water is flowing in.

Flowing water will push objects along, like floating logs or bombs dropped into water. Objects in flowing water move at the rate of one screen tile per second.

Objects in flowing water that get pushed up against something get stuck. (Unless the object is a Contact Bomb--in which case, it explodes!) Once the obstacle is removed the object will resume floating along.

Ranger Jim can step on most floating objects. There are only a few he can't, like beavers and bullrushes. If Ranger Jim steps on a floating object that's in flowing water, he can ride on top!

Ranger Jim can't pick up any object that's floating in water.

If Ranger Jim falls in the water, the level is over and you have to restart. But don't worry, Ranger Jim won't walk into water--he stops at the shore automatically.

Flinging

Objects can occasionally move very quickly. This is called being "flung".

Objects can get flung two different ways:

• Timed Bombs that get "detonated" are flung one square away from the explosion.
  
• When Ranger Jim drops a bomb on top of a floating object, the bomb is "flung" over the object, heading away from Ranger Jim. If there is a series of floating objects all in a row, the bomb will "skip" along all of them until it lands in open water... or on a distant shore!
  

Making Your Own Levels

You can make your own Dynamite Valley levels!

First, open up the "src/levels" directory. Dynamite Valley levels are individual text files in this directory. The easiest way to make a new level is to copy an existing level, then edit it however you like. Edit the level in your favorite text editor, then save your new text file in "src/levels" with the ".txt" file extension. You can play your own levels with "run_game.py <name of level>". For example, if you name your level "fred.txt", you can play it with "run_game.py fred".

Here's a quick description of the level format. Levels are text files, using simple ASCII files. Each level text file has three sections: the "tile map", followed by the "legend", and finally the "metadata".

Tile map

The first section is the "tile map" for the level. This must be exactly be 12 characters across and 13 characters tall. The "tile map" is a sort of ASCII art drawing of the level, where one character maps to one tile on the screen.

After the "tile map" there should be one or more blank lines, and after those blank lines should be the "legend".

Legend

The "legend" establishes what the characters of the tile map represent. A "legend" line is a single character, followed by a space, followed by a definition of what that character represents in the "tile map". There's also a default "legend.txt" shared by all levels containing all the most commonly-used tiles.

(What are the possible legal "definitions" for a legend line? It's hard to describe. Just find a tile in the game that does what you want, and look in the level where it was used to se what the relevant "legend line" was.)

After the "legend" there should be one or more blank lines, followed by the "metadata".

Metadata

The "metadata" establishes various other facts about the level. The format of a "metadata" line is: a noun with a colon at either end, followed by one or more spaces, followed by the value for that metadata.

Here are all the valid nouns for metadata lines:

• :title: The name of the level, displayed at the loading screen.
  
• :hint: The "hint" for the level, displayed at the loading screen.
  
• :author: The "author" for the level, displayed at the loading screen.
  
• :next: The name of the next level. When the player finishes this level, the game will automatically switch to this level.
  

The only required metadata is "next". All the others are optional and have sensible default values.

Stuff We Didn't Get To

Some ideas we didn't have time to explore during PyWeek 26:

• Giant Bombs, which blast all squares within a "Manhattan distance" of 2.
  
• Moving beavers, which would swim back and forth in a predictable pattern. Swimming beavers would push any floating object (including a Contact Bomb, which it would not set off). Blasting a beaver would be an automatic level failure--you can't hurt the wildlife, you're a park ranger!
  

Thought id' share the link to Gameplay Video

You can also read about the game in detail on the game's page

If you are a fan of cocos library you should definitely try to look at the way i've used the "Cocos Creator" editor for setting up the scene to render in-game. I've leveraged the same workflow i used in my previous pyweek entry.  

Libraries:

• Cpp-Lua plugin for Cocos Creator [https://github.com/cocos2d/creator_to_cocos2dx]
• FlatBuffers for python
• cocos (python version) [https://github.com/los-cocos/cocos]
• pyglet 

Tools Used:

• Cocos Creator 1.9
• Dragon Bones Pro [Animation]

I'm not sure how popular cocos still is but i've been used to cocos because of cocos2d-x and cocos-creator so tried to leverage that experience by using the same on python side. I would love to see cocos-creator editor support get added to cocos library project but thats a discussion i should still start and see. 

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!

Hi everyone,

I have had some log in issues that have now been fixed so I could not upload the final version of the game.

Now it is uploaded so if you have downloaded it before now, please redownload it to get the real deal.

Thank You!