Project Blue: Full version news thread

I figured it might be time for a proper thread for the continued, full version of Project Blue.

Where we are at the moment as of December 2018:
-Most assets are done. Maybe missing a song, definitely missing a boss, perhaps a few other objects.
-The final area is being designed. The 3rd needs a bit of work.
-Lots and lots of difficulty tweaks left to do.
-Final wrapping, polish and programming tidbits to be done.

On a playthrough there's 8 boss fights spread across 4 areas. Each area is up to 64 rooms, although not every area is exactly 64 screens. But basically, there's some ~250 rooms to beat. I guess you could say there's 8 stages, separated by bosses, music, and subtle theme differences, though the tileset is shared between each pair.

We hope to launch the game on kickstarter in Q1 2019. By then, the game is meant to be fully playable, maybe even finalized, so we can go for a quick physical release.

Here's some screenshots from the background art and animation guides. Taken from various stages in development.

Looks very nice! Will be interesting to see the final product in action.

Thanks for the update! It looks great, I'm looking forward to seeing the finished product.

The water looks a bit dangerous to epileptics.

Thanks, guys! And thanks for the warning, calima. The palette was changed after the GIF was made to a brighter (less contrasted) one that felt less straining to me. Hopefully that's better. The booklet should probably include an appropriate health and safety page.

looking fantastic btw. Will you consider to have an famicom (japanese) version of your game once you launch kickstarter campaign?

Looks great!

@calima

I don't know about epileptic sensitivity but in the case of another game that I was testing, Trophy, there was a scene where the complete screen was covered with a fall and even though I'm not, I was feeling dizzy after watching for a few screen so the speed of the animation and how much it cover the screen may affect normal people too.

In that screen only, it only cover a little bit so it may be fine.

That artwork looks great. The backgrounds make me think of a TMNT game done with Metroid mechanics.

It's beautiful. Definitely up there with the likes of Shatterhand and Batman. You've outdone yourself again, FrankenGraphics.

As for the water animation, maybe slow it down just a fraction? Or maybe make the bands wider/noisier, but there's only so much you can do with a 3-step palette cycle.

Making it slower improved the issue in the affected screen we had.

Thanks everybody for the encouragement! It means much.

I've slowed down water to take 5x3 frames for a full cycle, as opposed to 4x3 as before. That still looks like flowing but is less nauseating. 6x3 looked too staggered. So at least for this tileset, 5x3 felt like the goldilocks rate.

In other news, Toggle Switch is done with all the programming. We're just polishing the levels and preparing for the campaign at this point.

At the most general level, features include three game modes:
-Normal (you probably want to play this the first time)
-Hard (changes the actual layout a bit and will assume a bit more pre-knowledge of how the game works).
-Custom (allows players to load up and play to 4 areas/256 screens' worth of user created content, with the help of a level editor/patcher we'll provide).

My next update will include release date etc for sure!

Some screens i'm currently working on:


Blue thin line indicates inWater bounding box.

Posted a few more sneak peeks on my blog and over at nintendoAge.


I don't think we've talked much about it up to this point. My understanding is that appropriate homebrew cartridges/pcb:s are a bit troublesome to find, but i'll do a bit of research. Else, i'd suggest getting the ROM and putting it on a famicom everdrive as a makeshift solution.

Updating the first map from the compo. Some sample rooms:


idk if any of you saw the PRGE demo version but a major difference between it and the compo entry is that the map format changed. Before it was:
256 tiles
256 2x2 metas
256 2x2(2x2) meta-metas

Then it was:
256 tiles
256 2x2 metas
up to 1024(!) 2x2(2x2) meta-metas

shared between up to 64 rooms on a map.

Which helped bring more individual nuance to each room. Though, after completing most of the looks for all the later areas in the game, i was a bit shocked to look back at how monotonous the first area suddenly felt in comparison. Although i had filled in some of the new meta-tile space available for the first map at an earlier point, i hadn't seized the opportunity to make more out of the hardware tilespace and 2x2 meta-tile space to reflect this increased possibility for variation. And, admittedly, when i drew the first version of the that tileset, i had no experience working with dictionary compression like this.

So, i went back and replaced any unused, underused or uninteresting tiles on the tile plane, and threw out a bunch of stuff from the 2x2 array that didn't do enough difference. I was able to get a little bit more out of the room palette sets. More importantly I had mostly relied on a soft property bit that lets the game assume that if something is using palettes 0 and 1, it is solid, and if 2 and 3, it is "air". With the inlcusion of a few new material types, i made the new ones either always solid or always air. The result is a more colourful and varied. So there's a balance between being able to reuse the same tiles as both far background and solid foreground, and being able to use palettes more freely.

Are you generating all the metatiles by hand or do you extract them from completed levels?

I'm curious what your thoughts are. They're done by hand - so levels are mostly* built from metatiles, rather than metatiles built from free-form drawn levels. Though this has been done with the visual aid of a map editor that toggle switch wrote specifically for this game - we've also split the underlying challenge design beneath the graphics half and half, for the record.


*My process is basically drawing 4 screens' worth of mockups or so in NESST, then rebuild those on the map. That's a bit painful, but then i have a foundation to base the rest off, and add meta tiles as i discover that i need them. Usually they (the original mockups) end up in the area in some form or shape, but with some details changed or compromised once the tile usage is compared to the amount of detail or unicity. It's not necessarily so that a metatile is a good metatile if it is reused a lot. I often find that the lesser used metas are the ones that give rooms character.

Also, the intial mockups aren't necessarily great level designs, so they often need to be altered to get interesting. I guess they become ingrained with the intent to demonstrate and try out the tileset, which can be in conflict with actual challenge design.

Near the end of each map design, i find myself pushed against the 2x2 meta limit a lot (stretching 256 2x2 metas across 64 rooms is something i found a though job). It then becomes a day or two of negotiating what metas i can remove without too much compromise, and how i can justify it by making more use of the new additions instead.

If i'd do that differently, i'd make maps either shorter (so i get more headroom per "stage" which would allow me to work a bit quicker and more creatively/less technically) and increase the number of maps. --or, expand the 2x2 meta array. But for Project Blue, we have 2 diffuclty settings, each containing 4 maps, up to 64 rooms each (the 3 first maps are *precisely* 64 rooms. The 4th is not quite done). Music changes on certain checkpoint as if you've entered a new stage, and the visual composition changes a bit as well as you progress through each map, but each map/area still shares the same set internally. The hard difficulty is mostly derived from the normal one, but with changes done to the general layout, placement of objects and sometimes also path-taking between rooms.

Stop making everyone else look bad, it's not allowed.

Jokes aside, great work as always. As a programmer I'm curious about how you encode the 32x32 pixel metatiles, since it now allows more than 256 of them. Are they just bit-packed into an array, or are you using some form of room-level compression (other than metatiles)?

to be perfectly honest, it's achieved by being quite wasteful with ROM.

once we were done with the compo version we moved to a BNROM board, which has 16 times as much data.... so each 4x4 on the screen has a 'high' value (0-3), and a 'low value' (0-255). obviously these could be bit-packed, but since there's more ROM space than we need to use, i didn't bother.

i also got to devote an entire bank to sound, and have around 20 minutes of music written.

in addition we also devoted 8 banks to a 'hard' mode and a 'custom' mode so that players can make their own levels using the level editor and overwrite the relevant data on a ROM file to make their own game.

Nice! Cool stuff man!! Keep posting stuff on Instagram!

-Mat

Hmm. As a programmer. I would have made tools to take the finished levels and build the metatile sets, then find out that it causes more problems than it solves. I'd still have no idea what to make or how to make it. Not sure I would recommend it as a design strategy... :p

Those graphics are gorgeous!

High quality stuff all around! Very inspirational work!

At first I was a bit bothered by the acceleration/deceleration but after a while I got used to it and quite liked how the running speed influenced the height of jumps. Like super mario with a little bit of sonic the hedgehog.

Btw, did you solve the graphics issue you had with the demo on PAL machines? The one where all graphics were black? If so, what caused the issue?

thanks!

The running/jumping physics have actually been tightened up a bit for the coming kickstarter version. Same SMB-style rules apply, but the acceleration is a bit snappier. Leads to fewer missed high platform reaches and is a bit friendlier to first-time players of the game.

do you mean the black and white ripple on a particular line i posted about in the graphics subforum? Turned out it was the luma filters' fault on my particular tv set, but i avoided the trigging condition (vertical chroma bleed resulting in a mid-bright gray.. or what should be a gray on a more robust tv set).

If you mean something else, toggle_switch might be able to chime in on that... our test builds have worked with PAL units for as long as i can remember now. I seem to remember we had a funny mishap when the game was converted to BNROM where an empty block was loaded into chr-ram at some point.

the BNROM issue was caused by a mapper issue... whatever device you were putting it on was only giving 4 BNROM banks instead of 16.

it made the screen go black instead of loading graphics, IIRC. fixed by updating the mapper.

I was refering to the issue that toggle switch described here https://forums.nesdev.com/viewtopic.php?f=33&t=16785&start=60

I guess that was the BNROM issue you described now, toggle switch. Glad you got it sorted!

our kickstarter is launching very soon.

full soundtrack available for listening here:

https://toggleswitch.bandcamp.com/

Awesome! I love the triangle instruments and the little pitch slides in the theme. Very cool!

Will there be an NSF file available at some point?

Thanks for listening!

I'm not planning on doing an NSF release but if it's easy to compile I'd consider it.

In other news we are planning on going live with our Kickstarter tomorrow (10/17) at 10 AM EST.

https://www.kickstarter.com/projects/ne ... oject-blue