Progress Thread - Twin Dragons

Hi everyone,

the NESdev Compo deadline is tomorrow and I just sent my entry today.
I attached the final ROM in this post (Twin-Dragons-20170131-0.074.nes).
I really had a blast coding it and I hope you guys will enjoy this short game.
Please give me your feedback as I'm planning to expand the game with more levels / features and release a cartridge for it later.

Have fun !

Antoine




___________________________________________

Original posts :

Finally writing a post to introduce my entry to the compo : Twin Dragons.

Using some of Surt's graphics and MadMarcel extra graphics, I'm making an horizontal side-scrolling platformer. I've been working on it for two weeks now, re-using some code from other projects or test roms.

The test level is very simple and mainly used to check every feature. By the way I'm looking for some advice or articles on level design, if someone can help me on this it would be greatly appreciated !

What's working for now :
- horizontal scrolling
- actors animations
- basic physics
- one-way platforms
- dragon's fireballs
- simple enemy AI
- background collisions
- actor / item collisions
- items / power-ups
- moving platforms (horizontal and vertical)
- basic sound effects
- 45° slopes
- flying enemies
- first boss
- freezing power-up
- mega-fireball power-up

What's left to do :
- add flying enemies
- add at least a boss
- handle game over
- try again to add slopes (was a failure last time I tried ...)
- adjust physics
- any ideas ?!

Here are some screenshots, I'll try to add a video this week.




That's it for now, I'll keep you posted !

2016-12-06 update :

Clouds have been flipped, and I introduce you Minky which will have to rescue Dinky.



2016-12-22 update :

I attached a test ROM so you can test the game and maybe give me some feedbacks.
The level is not a loop, but I copy/pasted the same portion multiple times.
There's not ending and you can't die.
Water is not implemented for now, so you're wrapping vertically.
It should be PAL/NTSC compatible .

Enjoy !

2016-12-24 update :

Dinky can finally die, it brings you back to the title screen for now.
New ROM version attached

2016-12-30 update :

Quick update :

- a lot of bugs have been fixed
- 45° slopes are completely implemented
- player can jump down from one-way platforms / moving platforms by pressing down+jump
- background CHR is now full, and contains tiles for 2 worlds







2017-01-05 update :

Item collect and enemy death animations, and a lot of bugs fixed !
Next step : flying enemies !



2017-01-07 update :

Transition screens added ! The game flow is now completely working !



2017-01-09 update :

Today I finally started to work on boss battle / entrance. Still a lot of work to do though ...



2017-01-13 update :

And here's the first power-up in action !
You can now freeze enemies by pressing UP+B after picking up an ice cream.



2017-01-14 update :

Finally, the second power-up will help you to kill tougher enemies by pressing UP+B, after picking up a red pepper !



2017-01-15 update :

Hey folks ! Will you be able to defeat Cactus Clay, the first boss of the game ?

It sounds and looks good.

My only issue issue, is, the clouds look upside down. If you study cloud science, there's something called a 'ceiling', below it, the temperature and pressure aren't right for cloud formation. So, the bottom of clouds tend to have a flat appearance.

This game looks charming as hell!

Note: (I clicked on the wrong option before, and accidentally posted a huge block of sample code here in your thread, check your inbox, instead.)

Lovely use of colour, lovely artwork!

On ideas, i think the boxes are better looking if they are sparce. Could there be another graphic element in addition to them for over-ground solid blockades? Could the boxes be interactable?

Twin... double... The dragons aren't named Billy and Jimmy, are they? Or Alex, like the Allegro library mascot?

Would interactive boxes look anything like this tech demo that I made a few years ago?

Just as long as they don't blow bubbles

Thanks !

Since the graphics have not been made by myself and are free, I can't complain on things like this. But I can definietly try to do something about it !



Thanks too ! I'll check my inbox.



Kudos to Surt for the graphics.
This is a test level, real ones won't be so crowded with boxes.
They won't be interactable though, I have another graphic element for this (or maybe I'll switch the two).



According to the graphics' author, they're named Dinky (green one - the boy) and Minky (pinkish one - the girl).
I guess that Dinky will have to rescue Minky
And no the boxes won't be interative like your (impressive) demo.



For now he only blows fireballs

Why not be progressive and have the girl rescue the guy?

That's actually a good idea, I'll do this.

First post updated by the way !

That looks nice!

I just realized, those 'cracks' or panel overlaps (i don't know what to call them) at the bottom of the purple/magenta ground might not be visible to everybody due to overscan. You may want to move and/or copypaste some of them one or two 8px cells upwards so you're guaranteed to show those nice details.

Thanks !

This is still my test level. 'Cracks' will be more randomly placed but visible, avoiding overscan 'zones'.
The screenshots are in NTSC though, so there's already overscans on it.

Hi everyone !

OP updated :

I attached a test ROM so you can test the game and maybe give me some feedbacks.
The level is not a loop, but I copy/pasted the same portion multiple times.
There's not ending and you can't die.
Water is not implemented for now, so you're wrapping vertically.
It should be PAL/NTSC compatible .

Enjoy !

Nestopia refuses to open the file claming it uses an unsupported or malformed mapper. Tried in Fceux and it plays great. Really beautiful and very promising, really fun and easy to control. I quite like it. It took a while until I got used to the jumping (a tad fast, vertically), but the learning curve is not steep. It's fine, got it after a short while.

It seems that you are using horizontal mirroring. Wouldn't vertical mirroring be more suited for a horizontal scrolling game, or are you planning 8 way scrolling or vertical stages?

I could only get it to work with 1 emulator, FCEUX, (out of 4 that I tested)...I guess because it is mapper 28.

It's kind of hard to jump onto a small platform (box)...or rather, too easy to jump completely over it.

The music crashed after a minute or two.

Otherwise, looks good. Hope you finish it soon.

It's using mapper 28, which is relatively new.

Though nes2edit.exe complains it has inconsistent/malformed data in the header? (Not sure why, though, the header looks OK?) Maybe it's the use of byte 9 to suggest PAL, which most emulators ignore?

(If you want FCEUX to automatically use PAL mode for it, you can put "(E)" on the end of the filename.)


I find the game feels a lot better in PAL mode, and a bit too fast in NTSC.

I had a 4-way scrolling engine that I used for 1-screen mode. I wanted to use it quickly for the compo, so I disabled the vertical scrolling feature to do a horizontal side scrolling game, using horizontal mirroring. Not the ideal solution because of the attribute glitches on the right, but it's not that bad.



The ROM works fine with FCEUX, Mesen, and puNES as far as I can tell. Also works ok on the AVS+Everdrive.
Maybe I got used to it, but I found jumping on a small platform was ok. Are you testing with keyboard or controller ?
However I can tweak the physics a bit to help.
I used a famitracker song from a friend for the music. It initially uses VRC6 expansion so that's why it may feels "empty" sometimes.
The song ends weirdly, but it's not a crash. There's no loop.



Yes I tried to use the byte 9 for PAL but I guess I should set it back to $00.
I figured out that using "(E)" on the filename switch automatically the region in FCEUX (at least).

Thanks for the feedback so far !

Very cool.

Only issues I've found is the PCs walk animation seems to play a frame or two too long when coming to a stop and possibly related changing direction while walking has a jarring delay.

The idea I had in my head was that the Dinky Drakes: Dinky and Minky (basically Mario and Luigi) are rescuing their absent-minded professor of archaeology father (their Peach/Henry Jones Sr.).

They were originally intended to be used as platforms.

Dinky can finally die, it brings you back to the title screen for now.
New ROM version attached

See OP for latest ROM.



I think I can adjust that.



If you have any detailed idea of what you expect the game to be or look like, feel free to share your thoughts.

Quick update :

- a lot of bugs have been fixed
- 45° slopes are completely implemented
- player can jump down from one-way platforms / moving platforms by pressing down+jump
- background CHR is now full, and contains tiles for 2 worlds

Beautiful, this is beautiful. Congrats.

This looks really nice! It looks a little strange how the mushroom simply disappears when it dies though... Maybe you could add a little explosion or something? The moving platform suddenly appearing and disappearing at the edge of the screen instead of smoothly scrolling in and out is a little distracting too.

The mushroom will definitely have a death animation.

I struggled a bit with the moving platform for a smooth apparition but haven't found a good / clean solution for now ...
I'll have a deeper look at it if I have enough time.

Cool!


This isn't the most terrible thing ever, and even some games from back in the day had objects "popping" near the edges of the screen. But your game looks very good, better than the average commercial NES game, so it'd be nice if all the action was as smooth as possible to top it off.

I don't know how your meta-sprite system works, but as long as you work with 16-bit coordinates when generating the OAM entries, it should be easy to tell when individual sprites are off screen so you can skip them. You also need the "active area" to be a bit wider than the screen, so objects are activated a little ahead of time, and deactivated after they're entirely off screen.

Very adorable graphics! And the gameplay looks very polished, too.
How do you handle these 45 degree slanted blocks and these moving platforms, collision-wise? (platforms are sprites, right?)

Then these posts/threads might interest you:

viewtopic.php?p=102614#p102614
viewtopic.php?f=10&t=7844

I swear I saw a post from Bregalad (I think it was him, could be wrong -- edit: ah yes, it's here) with a demonstration of this in effect; basically the "glitching" is seen on both sides of the screen (vs. entirely on the right), and visually it's a lot more tolerable (less noticeable). But then again, the "glitching" in question is something that does have a kind of "NES feel" to it, that is to say, it has a nostalgia associated with it.

My "active area" is 64px wide on each side. Objects are only spawn in those zones, and deactivated/destroyed if too far. As long as they're on screen or in the active zones, they're processed (still moving, colliding, etc).



I'm using height map for slopes.
Here's how I dit it :





Yes, I read those threads before, and thought about doing something like this. However, like you said, it has a "NES feel" so I won't change it for now. But I'll definitely try something if I've got spare time before deadline !

Sorry I forgot to answer the second part of your question about moving platforms.

Yes platforms are sprites.
Before updating actors, I update platforms first (2 max on screen at the same time in my engine for now but can be more).
This way, their position is updated, and if there are actors on platforms, their position is updated too.
After that I update actors, and check for actor/platform collision if needed.

I don't know if it's the best way to do it, but it works for me.
Tell me if you need more details.

Item collect and enemy death animations, and a lot of bugs fixed !
Next step : flying enemies !

Nice! The button press widget is a nice touch, too. I wonder if it would feel a little more natural if the powerup/red chili would move to the north-east corner instead of the north-west? Not that i think either is right or wrong; it's just something i reflected on.

Will there be a sound effect when taking out enemy objects? The plucking sound in SMB always felt satisfying.

I think that particular "button press widget" is part of the emulator. I remember seeing it in FCEUX.

Oh, my bad. Found it!

Yeah I was thinking about changing the direction of the red pepper for the collect animation.
And yes there will be sound effects !

And as tepples explained, the widget is an FCEUX functionality.

Seems great!!
Will you be selling copies of your game?

I'm trying to finish it in time for the compo for now

Transition screens added ! The game flow is now completely working !

Using 1px weight on letters can look sufficient on emulators, and opens up for differently feeling typefaces than the ones commonly shown in nes games. However sadly, they often get illegible on real hardware, especially if it's not pure white on black. The parts that typically get scrambled the worst on hardware are the the arms of the letters (the | | in N, | in R, and so on).

If you want them hardware-proof but don't want to ruin their lightweight nature by making them bold or art-decofied, you can try drop shadowing with any available darker colour within the palette used. It can also help make the 'select' lines appear symmetrical in relation to tilesize and the options.

This is just an example; there are other ways to shade (less or more weight, direction).

I haven't checked how these were implemented, but i do remember the typeface for Willow was white on black, which was easy to read. However, as soon as the contrast drops, you're in the risk zone. Better try it on a few hardware setups before publishing in that case (rca,RF).

Rule of thumb: Each pixel is only two-thirds of a color subcarrier cycle wide. So when you're using 1px-wide details, try to guarantee contrast by having the maximum of the dark waveform less than the minimum of the light waveform. (See NTSC video for how waveforms are generated.)

The following color combinations are known to keep 1-pixel-wide details distinct:

• White ($20) with dark backgrounds ($0x, $11-$1C).
  A lot of my low-level NES tests, such as the FME-7 big WRAM test and the overclock test before I folded it into 240p Test Suite, use white text on medium brown ($18).
• Black ($0F) with light backgrounds ($10, $20-$2C, $3x).
  Action 53 menu uses black text on light gray ($20), and RHDE uses black text on pale yellow ($38).
• In a pinch, $31-$3C and $01-$0C can be paired.
  A few controls in 240p Test Suite pair pale yellow ($38) with dark blue ($02).
• If two colors have the same or adjacent hues, you can pair $0x with $2y or $1x with $3y, such as $27 with $06 or $38 with $18.
  This violates sets max(dark) and min(light) near equal, but because the chroma doesn't change phase, edges won't be quite as distorted as if a different hue were paired with these.

EDIT: Assertion fixed

Assert failed: A ≮ A

Thanks for all these informations/advices.
I'll try different fonts on real hardware to see what's the more readable.

Today I finally started to work on boss battle / entrance. Still a lot of work to do though ...

Impressive appearance! I love it!

That's cool! I like that you make the extra effort to mark the importance of the event via a special sequence.

Here's me nitpicking some more

It's easy to miss the dragons' expression if it starts and stops exactly at the same time as the boss appearance sequence. How would it feel either the camera shaking and face expression started second or a half prior to the boss showing up / dragon moving backwards, or, alternately the dragon's expression froze half a second after the boss sequence is complete, as to solidify the fact? Just timing details you might not want to prioritize, but anyway.

Another thing to consider: It might be better to have the camera show more of what's before the dragon than what's behind. Being too close to the right end of the screen is a common cause for frustration.

Makes sense. As you said it may not be a priority but I'll add it to my 'things-to-do-if-I-ve-got-the-time-before-deadline' list !



Don't know if I'll change this for the compo, but that's actually on my TODO list

And here's more on the first boss !

Wow, your game is looking great! Looks like it's fun, too.

And here's the first power-up in action !
You can now freeze enemies by pressing UP+B after picking up an ice cream.

Finally, the second power-up will help you to kill tougher enemies by pressing UP+B, after picking up a red pepper !

What does 376 designate?

The fceux widget telling how many frames the controller was not polled since power-on.

Hey folks ! Will you be able to defeat Cactus Clay, the first boss of the game ?

That looks really nice.

Hi everyone,

the NESdev Compo deadline is tomorrow and I just sent my entry today.
I attached the final ROM in the first post (Twin-Dragons-20170131-0.074.nes).
I really had a blast coding it and I hope you guys will enjoy this short game.
Please give me your feedback as I'm planning to expand the game with more levels / features and release a cartridge for it later.

Have fun !

Antoine

I'm a little confused about what to do at this wall. Is there a manual or instructions that might explain?

Sorry I forgot some information ...

This is highly polished!

A few notes to consider:
The wall rainwarrior had trouble with is a "sharp" tutorial element. It is there to teach you that you can drop through certain floor types, which comes in handy later on. A sharp tutorial is however having the characteristic that in order to pass, you must succeed. I think it is generally good practice to provide the player with a "soft" tutorial element before a sharp one. Think of how SMB1 world 1-1 teaches the player to jump over obstacles in a safe environment, then jump over deadly pits. A soft tutorial in this case could be something like this (excuse the sloppy ms paint work):

Notice that nothing else is there, just the few collectables, so you won't misdirect focus towards a wall or other obstructing structure of interest. Enemies or hills or other decor would be fine, of course. This helps ease the reliance on manuals, readmes, etc, so the game can be played the first time without the risk of interruption or necessity of preparation.

EDIT: Alternatively or additionally, you could place a jalapeno at the bottom of rainwarriors' screen to direct attention of the player away from walking to the right.

There's another place which could benefit from a softening, too. In the (spoiler) underground passage where you find your first 1up, it is hard to calculate how the low ceiling affects the jump the first time(s). The first pit could be narrower, or there could be some jumping excercise prior to that, or something.

The castle music was a good fit for the scenes and pretty cool sounding! The graphics are about the cutest thing in a while.
I think everything in the game felt very good, from jumping mechanics to enemy placement to progression of difficulty to change of scenes. Except for the moving platforms. It's always a personal grief when moving platforms don't ease in and out of their turning points in platformer games. Somewhere between SMB1 and a sharp turn could be just right, maybe?

The castle could *maybe* benefit from the first narrow platform jump to be one 16x16 tile wider, also to ease in the difficulty of the narrower ones.

Otherwise, this feels very well produced. Congratulations!

It doesn't really come up after this, though. There's one "big heart" that you need it to get (slightly past this point), but other than that, for the rest of the game it doesn't seem to be important?


I notice very often a single line of pixels disappears from sprites, and it seems that it's because when the head bobs down you now overlap by one pixel, putting 4 sprites on a scanline. I realize it conserves CHR, but since so much stuff happens on the plane of action with the dragon, it might be worth dedicating a few tiles to the head-down sprite?

Hmm, seems like the problem is compounded by the fireball sprite also overlapping the lower half by one pixel too, guess that'd be harder to deal with.

Actually, if you moved the "tail" part of the lower half of the sprite as high as it can go within the CHR tile (and then lower its sprite tile position) you could move one tile out of this critical line of overlap, at least?


Anyhow, very nice game. Thanks for sharing!

I'd say that depends on what boss fight strategy you develop. It also sees some use in the castle.

On sprite priority, i wonder whether the status bar objects should have the current priority (high) - this is mainly a cosmetic problem in one specific area in the castle.

If it is intended to be a tutorial, I was thinking if there was just a little sign with a down arrow (and maybe an A), I would think of it as a tutorial; without something to explain it, it's more of just a test to see if you already know what to do.

...or can figure it out (but that's not a very fun puzzle)-- I mean, down+jump is a common control, I just didn't think of it this time. I figured out up+fire without help... though it could probably benefit from a similar tutorial. Maybe a sign with an up arrow+B next to a red pepper and a tough enemy blocking your path?


I liked the boss name "Cactus Clay", though I dunno how many people remember the name Cassius Clay these days.

Just an opinion, but i think in-game tutorials are more elegant when they're implied, rather than stated. If the level design manages to silently guide you on your way without explicitly/openly telling you instructions, i think that's perfect. But arrows and button instructions are decidedly the more sureproof way.

I can't begin to express how much I admire games that teach players their mechanics through clever level layouts rather than through a manual (on or off screen). SMB, Mega Man and Sonic were pretty good at this, IMO.

Sure I do too, but this is a specific suggestion for this specific case. I can't really think of an elegant way to imply that "holding down changes the behaviour of the A button but only in certain contexts", especially when pressing down normally does nothing in this game.

Thanks for the feedback so far !

First of all, this was my very first attempt at level designing, so I knew that it wouldn't be perfect, especially that 'drop down' part ...
I wanted to add an arrow, or a sign to read with instructions, but I ran out of space and time. So I guess I just done it the lazy way...

Sprite flickering is clearly noticeable in the game.
I could test what rainwarrior said to lighten the effect, but as a lot of stuff happens aligned with the dragon, there will always be glitches somehow.

@FrankenGraphics : I really like your example for the DOWN+A action, and your advice for the jumps over the spikes with the low ceiling. I sure will update this after the compo results.

I currently have Mednafen installed (from the Ubuntu package manager), and the version I have does not implement mapper 28.

I think the best way to do it goes something like this:

[ ] (at least) first time around, present an environment (screen) that's mostly or absolutely safe.
[ ] Present an incentive to reach a spot that's only possible with that maneuver.
[ ] See to that the incentive is strong enough (powerup, collectable item, easier path comes to mind), but still optional and not obligatory for reaching the main goal of the scene/level.
[ ] The more intricate the maneuver, the more you should scatter repeats of the same concept for the player to catch up on, eventually.

There's need of judgment to balance the last checkbox. When is the right time to present a scene where the maneuver is mandatory, if ever?

As said, down+jump follows a fairly established convention, so for the main segment of the user group, i suspect the difficulty arising is simply becoming aware that the game includes such a maneuver. Visual cues like hard-to-reach bonuses is one way; it guides the player towards being experimental/creative with the control pad. Adding a duck feature/animation is another, because that shows the game is aware of downward d-pad presses. That doesn't do it on itself, but is enabling the player do discover the control scheme in minute portions that's easy to bite.

The game shovel knight doesn't do the former. While it repeats opportunities to try both the shoveling and pogo jump mechanic, it has a sharp tutorial element requiring the pogo interaction in one place in order to progress on the second board of the first level. Instead they call for the player to induct that there's soft earth + player character is using a shovel = ???, which works about as well. That's a third approach. All three can be combined in a best case scenario.

(shovel knight also has a second approach to moving platforms: instead of easing in and out of turning poins, they have the background tiles telegraph how far the platform will go).

Very cool game!!
My kids loved it, congratulations!!
Any chance to add a 2p mode later?
Thanks for sharing!

I've noticed several gestures for jumping down in platformers.

Games using Down (any): Kirby Super Star
Games using Down Down: The Curse of Possum Hollow
Games using Down+A: Chip 'n Dale's Rescue Rangers, Contra
Games using Down tap:* Super Smash Bros. Brawl


* In Super Smash Bros. series, "tap" refers to quickly moving the analog Control Stick from center to edge, or (in the case of the sideways Wii Remote in Brawl and For) quickly pressing and releasing Down on the Control Pad before the transition to crouch finishes animating.

Gesture #2 and #3 share having a security latch so you don't do it by mistake (dropping down on a bullet, enemy, or deadly pit by mistake). Maybe #4 is partly in this category, too. Though, in super smash, speed is more important than full platforming security, so that makes sense. I haven't tested kirby super star. But i think scheme #1 and #4 is fine in games without one- or even two-hit deaths.

For the second boss in twin dragons, i think #1 and #4 would mean potential trouble.

Another simple idea that might help a little; it seems that the dragon's fireballs are always drawn before other things, so they get higher priority.

I presume it would probably be a big change to put the fireballs into the flicker rotation with other enemies/objects, but as an easier alternative, what if you put the fireballs last on every second frame? Then they would start to take part in the rotation a little and maybe soften the impact, instead of just the objects having missing bits?

(This same suggestion could probably apply to the status sprites at the top too, so they don't block stuff up at the top as thoroughly.)


I notice that on Nintendulator the game has a blank screen. I think for this mapper it is forcing CHR-RAM maybe? Kinda strange. It runs fine on the Everdrive N8 though. (Can't test on PowerPak because I don't have a mapper 28 for it.) So... not really a bug report for you, just noticing that I think Nintendulator doesn't support this mapper fully.

Thanks. Works fine on PowerPak too, then.

Super impressed!

I wasn't so keen on the physics in the earlier version, but this version is excellent.

I see you've switched to horizontal scrolling too - Can I ask why you've disables the left 8 pixels? I'm presuming you don't get artifacts anymore as it's horizontal.

Anyway, congratulations! The level intros are also really nicely put together.

Thanks Fisher ! Happy that your kids had a good time
What kind of 2p mode would you like ? A turn by turn like in mario or 2p at the same time ?



I could easily move the fireballs in the flicker rotation. I was so focused on the idea that the dragon and his fireballs should be always visible that I didn't even test it ... my bad.



That was my fault ... My ROM wasn't correct, I updated the ROM attached in the first post, it should be ok.


Thanks for the feedback.
It was always scrolling horizontally, but I'm using horizontal mirroring, that's why I disabled the left 8 pixels, to hide attribute glitches (you can see those on the right edge though).

Great game, I really enjoyed it!


I'm of the opinion that everything should flicker, even the player sprite.


Why would you choose to have glitches at all if you have an empty name table just sitting there? Do you plan to do anything with it at some point?

Time constraints.



Presumably so, in another game using the same engine.

Thanks !


I should also try this solution and see if it's that bad.


When I started the project, I had an 8-way scrolling engine that used 1-screen mirroring.
It was easier and quicker to use it as is with horizontal mirroring, and eventually change it later to support vertical mirroring.

Oh yeah, I remember that now.

A 2 player simultaneous would be awesome!
But a turn based 2 players would be a nice addition too.
The kids usually like to play with me simultaneous action games.
Would this game run o a UxROM board?

Simultaneous 2-player would kick ass! It can be somewhat difficult to implement though, since it affects the behavior of the camera, and the object system must be able to handle a second player (i.e. no hardcoded state variables if you don't want to duplicate all the logic). Another concern is the low number of palettes, if each player uses a different palette.

Yes!!
That would be the true "Double Dragon"!

Absolutely love this game

Definitely looking forward to having a longer version.
Would be an instant classic in my book

This was actually the last of the entries I played, and I quite enjoyed it. The graphics were nice (especially the level intros, as others have mentioned) and the game's engine felt pretty solid.

I did notice some of the flickering everyone's talking about, but I didn't find it all that disruptive. Thanks for a fun game.

The Kickstarter campaign for Twin Dragons is finally on !
You can support the project and help us here : https://www.kickstarter.com/projects/1454702417/twin-dragons-a-brand-new-game-for-the-nes

This is good stuff!

Good luck with your campaign and finishing the project!

Thanks, I'll do my best

Very exciting to see something like this come about as a result of the compo. Congrats on taking things to the next level and what looks to be an Kickstarter success!

Since you're going the full Kickstarter route with this, I guess I should address some design issues I had with the competition entry. I didn't see this covered while skimming the thread, so I figured it was worth pointing out. Sorry in advance if it's stuff that's already in your pipeline. Apart from these two points I think the game is very solid, and definitely deserved winning.

1. The special weapons weren't really obvious. It takes a while before you get the ice pepper, and fire for the red one looks similar to the regular attack, so when I was playing around to see what it did after picking it up, I couldn't figure it out, as I didn't notice the difference, so I wasn't sure if it were a passive effect, or maybe something I had to use later.
Sure this stuff could be solved in the documentation, but it wouldn't hurt to have it implemented in a more intuitive manner. For example, a mini-puzzle that requires you to use the special item right after picking it up, and a more obvious difference in how the special fire looks from the regular fire.
EDIT: After replaying to confirm my statement, I have to admit that the red pepper special attack does differ quite a lot, but at the time it still had me confused. I'm not sure exactly what else you can do with it, but maybe introducing the ice effect before the fire one, for a more obvious effect, rather than just assuming you are getting increased damage?

Also, my second playthrough raised aanother issue. There's no downside to using the special attack (when you have the red one, anyway), unlike games with similar attacks like Castlevania and Ninja Gaiden which use up ammunition. While I'm generally not a fan of having limited resources for stuff like this, it feels weird that the more powerful attack doesn't just replace the regular attack while you have it. What's the purpose of even getting the choice? I would add either an obvious downside to the fire attack (it could be really slow or have limited range?), or have both weapons replace the standard attack (to keep it consistent), with added power to the ice attacks (eg. a second attack to a frozen enemy kills it)

2. I didn't like the bosses much. The presentation is great, and the general design ideas are definitely nice, but dodging their fire felt clumsy and unprecise due to how fast the attacks were. In both fights the only thing that worked for me was finding a safespot that I knew could never hit me, which made the fight both trivial and repetitive, especially for the one in the castle.
If I were to design this, I would go for slightly more randomized attack patterns (eg. slight offsets in timing or direction, or just shuffled set patterns) that always forces the player to react to what's coming, but at the same time I would make them slower and easier to dodge, so that the game remains manageable while the player still feels like he/she is doing a good job.

Thanks for the feedback Sumez.



Powerups will be introduce differently in the full game.
They could replace the regular attack, but the ice cream doesn't do any damage, so it would be weird.
The regular shot is quicker than the red-pepper-shot. However, we can imagine something like having two powerups. The red peppers would replace the regular shot, and the ice cream would be another power up to use with UP+B.

By the way, in the demo, when you froze an enemie and you shoot at it, it unfreezes instantly which is not a good idea for me. Ideally, you should be able to shoot at it as many time as you want during its freezing state.



Sorry about that, boss patterns will be tweaked indeed. But hey, this was my first time designing/programming a game
Good advice though, I'll definitely remember those !

Thanks !

Glad to hear. Definitely a good job for a first attempt, so no excuses necessary. Just trying to give feedback.