Cowlitz Gamers' 2nd Adventure

I've been meaning to move this out of my graphics thread and into the projects thread for a while, but have been waiting until we had a demo ready, so we could get proper feedback.

This is a 2-player co-op, arcade style, all-ages platformer.

Łukasz Kur and I have been working on it for quite a number of months now, and the music and SFX are done in famitracker from Robert "Robi" Janota and Chip Jockey.

Received some great feedback from dustmop and others via email, and we've tried to take that into consideration before posting a demo online.

Would love more feedback regarding demo so we can improve as much as possible before releasing the full game.

Demo Download (zip containing ROM, readme, and cover art)

It's really good and the art is lovely, as always, but it has a few rough spots:

• The first life I played I immediately walked to the right and died in player two's entrance. I thought that was the exit!
• The second life I played I hit the jump button on the starting rope and died in my own entrance. It's kinda lousy to allow players, especially stupid ones, to die in the spawn points.
• There's 3 frames of latency between pressing a button and having the character react. I don't know if this was intentional or not, but I don't like it.
• I did not realize it was possible to duck and jump down platforms until late into the game. It would be a good idea to "teach" players how to do this in an early level by including a segment where the only way to progress is to jump down. Preferably a section without enemies.
• I kept thinking the stalactites were part of the background and not sprites because of how dark they were. I died several times because of this. Brown may look good, but a lighter color would benefit players more.
• It was not clear how much progress I was making and how close I was to beating the game. I ended up quitting about halfway through, I think. Ideally, there would be more feedback to players regarding their progress. For example, have a bonus section every 10 levels to act as a milestone and reward the player for their actions.
• I wonder if the game is too hard for some children to play. Keep in mind that a lot of children, especially young ones, are flat-out terrible at video games. Even something as simple as grabbing a robe mid-air can be a challenge for them. Maybe you should include an "easy" mode that includes levels that don't require any skill to beat.

Keep up the good work

Pretty cool game. I enjoyed playing through the demo.

I agree with pubby's critique though. I, too, died a few times by dropping down from the entrance rope by accident.

Also, I got this glitch in the Game Over screen (in the "Continue Used?" section):

(I had used one continue at this point.)

Thanks for sharing the demo, I like it.

Here are some bugs and oddities:

Like thefox, I often had the CONTINUE USED? item on the GAME OVER screen show three strange characters instead of a normal YES or NO.

Sometimes the GAME OVER screen has strange changes to the music. I have encountered: 1. A few soft high-pitch beats before the normal music. 2. The normal music with weird pitches. 3. Very fast tempo.

One time when I ran out of lives, the game froze on a black screen and didn't show the GAME OVER screen at all. I'm not sure what I did to trigger that.

If you enter a valid password and press START, then back out to the main menu using B and choose NEW GAME, it will still skip the intro text and start on the level for the password you entered. (For example, on my first start up, I looked in the CONTINUE menu, entered password 0000 and pressed START, but then backed out using B and started a NEW GAME. I didn't get the intro text. At the GAME OVER screen, CONTINUE USED? was "YES", even though I chose NEW GAME.)

Thank you all for your feedback.

Continue Used Glitch
This error wasn't occurring in earlier builds. We'll fix that.

Dying in the Spawn Points
This is an issue we've struggled with. Currently, if the player is climbing, they will not die (only not be allowed to climb further down). In later stages, it will be important that the player die if they fall past the bottom of the screen. But, I also notice a lot of players starting the game by dying accidentally, and that's obviously something we should prevent.

Would having the players automatically grab their ropes if they're falling be the best solution?

Dropping from Platforms
There is an earlier stage where it can be forced upon the player in a safe location. Level design is something I'm particularly looking for feedback on, as this was my first time doing level design, and I did all 54 for the game. Similar responses of making something easier / more apparent the first time it is presented have already led to earlier revisions (making the diamond easier to trigger in the first stage and providing an area where the player can jump from rope-to-rope before needing to do so over spikes)

Displaying Progress to the Players
This is what we have so far, I don't know what more we could do:

• The displayed "depth" begins at 384 m. and decreases by 16 m. each time the player ascends to a new screen. In this way, we're using depth to label the stages, and by having it decrease, I had imagined that reaching 0 m. would be seen as the goal.
• Every 6 screens, there's a palette and BGM change.
• There's a bonus stage triggered after collecting 8 diamonds. (One hidden on each stage, so could occur as frequently as every 8 stages)

In the full game:
After 24 stages, there's a mid-game cutscene (a fake ending, since the player has reached ground level), and then the location changes from mines to a tower, "depth" changes to "height" and the game continues (palette and BGM change every 6 screens as the player works toward the top of the tower, which is as exactly tall as the mines are deep.

Other Feedback and Bugs
Will pass them on to the programmer. Keep them coming.

Cool demo!

The music gave me some Atari ST nostalgia, especially since the game reminded me a lot of Rick Dangerous, and Yolanda.

I got stuck here, because the two spinners at the bottom left move in sync and I can't get past them to grab the last nugget:


Edit: Oh, I got it. I can duck. I thought I'd tried that but I guess not! Onward!

Just as a point of reference, when I played first time, completely naïve, I did discover crouching. Wasn't clear on why I was collecting diamonds or what made them appear, but the number that I collected by accident weren't enough to get to the bonus room. Didn't use up all the lives (about half? no continues).

Only thing I find a little odd is that you can jump to catch a rope that you can just barely reach, but you can't similarly jump to catch a platform at the same height.

We've now prevented players from being able to fall past spawn points, have corrected the error affecting the continue status of the game over screen, and have corrected what was causing the black screens on certain game overs.

Will update demo in near future.

More updates (not yet uploaded):

Have added new behavior and animation for yellow slug.

Some map edits: removed a location where yellow slug could land on a platform small enough that the player can't cause it to jump away. Also added an area where the player's forced to drop from a platform earlier in game, and in a safe location. I agree that each gameplay mechanic should be introduced in the safest way possible first, and didn't originally keep that in mind while designing stages.

As for difficulty differences, they are minimal now (score, lives, extra life renewal rate)... But I've been brainstorming some ways to make the "easy" setting on the full version of the game easier without too much extra effort.

We should have this build ready to upload this weekend, if there's any more feedback we can work into it, would love to hear it.

Quick Edit: also added some platforms to decrease difficult in tenth screen (the one with the two beetles in the chamber on the top of the screen).

Sorry for the triple post, but new ROM release, download updated.

On top of addressing many of the issues brought up earlier, we also added notification of low time remaining. If you play ed the earlier version, be warned that the hwang komori (yellow leech enemies) have been given new behavior.

Thanks for the update.
New bug in Demo v 1.1: After a game over, if you go to the credits screen, some enemies/gold/objects from the last level you were on are loaded under the credits text.

I gave the revised version another playthrough, this time getting every gem (though I didn't make it through in a single continue... not sure if that matters, the stats only seem to show when I die, not at the end of the demo). A couple of tiny points:

• 256m once skeleton and yellow slime get together in that same groove at the top middle they seem extremely difficult to cross (need to wait a while until they overlap with good timing, but even then the yellow slime jumping makes that iffy.)
  
• 224m if you just wait all the skeletons will destroy themselves on the spiked floor, is this intentional? The level seems very plain once they're all gone.
  
• I notice you set the Y scroll (second $2005) to 255. I'm guessing you did this just because sprites are more convenient if you don't have to think about the Y+1? On NTSC TVs it shouldn't make a difference, but on systems where you can see the whole picture, there's one line of "garbage" at the top of the screen. (Not necessarily something that's worth changing, just wondering if that's the intent.)

On PAL TVs it shouldn't make a difference either. The PAL NES and Dendy PPU also blank the first line of picture and the first and last 2 pixels of the rest of the picture, with actual black instead of the backdrop color. Only (2, 1) through (253, 239) are visible.

Hunh, I didn't realize the PAL PPU had additional blanking not in the NTSC one. Is hblank black or does it use the palette background on the PAL PPU? (This says "the border" is black, but doesn't seem to explicitly talk about stuff outside the 256x240 picture?)

"and it covers the top scanline and the left and right 2 pixels of each remaining scanline."

By this I meant the following: The border is black. The first scanline after prerender, the one where sprites never appear in the NTSC PPU, is black. The left two pixels of all scanlines are black. The right two pixels of all scanlines are black.

That doesn't answer my question.

I want to know what colour appears to the left and right of the 256-pixel picture. (This is what I meant by "hblank".) Is this what you mean by "border", or does it refer to a 1-2 pixel border on the picture? The word is ambiguous to me in this context.

I'm a little confused because the way you use "scanline" because it sounds like it does not include hblank, but only the 256 pixels of the picture?

The side borders are also black in PAL.

The word I was specifically having trouble understanding was "border", so I am having an increasingly tautological frustration with this dialogue. :S

I will presume that the answer to my question is "yes, the area outside the 256x240 picture is black", and thank you for clarifying this (unless my presumption is incorrect).

Y=0 and Y=240-311 is black. X=0, X=1, and X=254-340 are black.

Thanks.

Actually, a better way to handle that section is to wait until the leech is in front of the ghoul, jump down into the pit and crouch... causing the leech to jump over you and out of the pit. (The main gameplay mechanic for the yellow leech is to crouch and cause it to jump places. Leading them into spikes and under stalactites helps boost score.

The reason we added its vertical jump capability in the latest build is to restrict the player from being able to jump over it, forcing the player to crouch was the original design intention, but it had been lost when we modified collision boxes, hence the vertical jump.)



Yeah, this is intentional, but I don't think we're communicating the intention to the player successfully....

Actually, enemies dying grants a notable score increase.

I had designed it hoping a player may lose a life or two trying to evade the ghouls until they realize they could wait and get a bonus score, like an award for the progress.

We have a concrete score cap based on:

• Amount of time remaining at the end of each stage (limited by fastest possible playthrough speed, although we haven't calculated that.)
• Amount of gold collected (not variable unless player can access bonus stages... which have a lot of gold in them.)
• Number of exits (higher if playing 2-player)
• Number of lives remaining at game over (again, possibly higher if playing 2-player)
• Amount of diamonds collected (maximum of 48)
• Number of enemies eliminated (since there is no combat in the game, this is limited to level design. There are x amount of potentially killable enemies due to falling objects or spikes in the game.

I was really hoping to make the game a strong contender for high score competitions, maybe on the AVS scoreboard, or old-school, send in screen captures (hence the little camera icon).



That's on Łukasz's end. I was wondering why screenshots were a pixel vertically off grid, but never inquired about them. I would assume intentional.

EDIT: I tried to add this reply earlier by phone, but it didn't take:



Collecting 8 diamonds grants access to a Hidden Chamber (bonus stage). Diamonds are shown at the top of the screen during gameplay. Getting a Game Over does empty out your diamonds (and all other stats other than level progression).

The diamonds basically play the role of EXTEND balloons in Bubble Bobble. There are 6 bonus stages and 48 diamonds in the game, so in order to access each bonus stage, a perfect playthrough (not without deaths, just without continues) would be necessary.

In the demo, there is only one bonus stage and 12 diamonds (one per stage, which is a constant throughout the game. Each stage has one hidden switch and one diamond.) Only finding 8 is necessary to access the stage. Considering x amount of gold collected grants an extra life, the bonus stage almost always guarantees 1-2 extra lives.

Finally got around to playing the demo. (Gameover at 7 diamonds ) Really, really good music. Track 2 sounds like Tim Follin did it. (It also syncs nicely with the walk animation.)

The backgrounds for the final 24 stages of the game (minus gameplay elements), each frame of the animation shows one screen of the game. Intended effect is that after a few stages, a player would notice that the sky is intentionally showing the ascent.

That feature is so cool. The only thing (and this is super nitpicky) i would perhaps want to change is that while you maintain a linear relationship between movement of perspective and the "jump" of 1 screen up, this only looks natural for the distant background but not for the black ground/chains. They would move faster. I'd let them start high up and let them move all the way down over the first two, three or four frames, letting the more distant background 'appear' or stretch out from a narrow band to what you have in your current slide, which would go well in hand with the expectancy of a changed perspective. Since you don't need to animate or display the motion from point a to b, this would be easier to do than otherwise.

Note that it's already really good as it is.

Okay, so 18 months after my first mockup, we finally have a final copy ready and sent to INL for production. As far as I can recall, everything planned from the beginning and more is in the game: 54 stages, 4 difficulties, 14 BGM tracks (11 of which are full-length for gameplay, 3 of which are shorter for things like gameover, etc.), and 4 sets of "guest stars" (unlockable player skins).

It's hard to judge how much time went directly into development, but it's pretty high up there. I made the mockup and pitch in March of last year. We started middle to end of last summer. Game was pretty playable early this spring, then *a bunch* of polish, testing, bugfixing, and level design balancing (for difficulty ramping, fair play, etc.) Am fairly excited.

@Frankengraphics
I can't believe I forgot to respond to your post. I thought I typed one up ages ago. I actually initially took that into consideration, and my first drafts had the midground of the chains and fence posts move more quickly. The problem was that I either had to start with them too high (which threw off the ground-view of the midgame cutscene preceding the tower) or the chains and fence disappeared so quickly that the player probably wouldn't even notice them, so I just dropped it altogether and kept them together.

One thing I will say is that I don't like filenames with spaces; filenames with spaces are annoying to work with, and so would rather to avoid them.

This is going to be an excellent release!

Two bits of news:

First, we've recently released the full game digitally on itch.io.

Second, the game will be run at Games Done Quick Express this weekend. Schedule available (in your local time) here.

Apparently there's an incentive that if enough money gets donated toward it, the runner will need to retrieve all 48 diamonds on his run through the game.

That's great!

Anyway, this is all new to me, but if you could help us spread the word and maybe toss a little charity money toward our incentive, we'd really appreciate it.

To watch, tune in to https://www.twitch.tv/gamesdonequick at the game's scheduled time.

To donate,
1. Visit http://gamesdonequick.com/donate and fill out your basic info.
2. Click Yes under Donation Incentives
3. Scroll down the list and click on The Cowlitz Gamers' 2nd Adventure.
4. Click Add to apply your donation to the incentive.
5. Finally, click finish.

Hopefully if it pulls in a reasonable amount of donations, the organizers may be more open to the inclusion of homebrew games in future events.

Really great,level design is excellent and well thought out for gameplay.