Progress Thread - Wolfling

Hi, I am happily announcing a Zolionline-Lazycow cooperation for the 2017-compo.

planned features:
- It should be a 64k-UNROM with CHR-RAM. (it's ok to use CHR-RAM, isn't it?)
- horizontal scrolling
- 16x16 pixel tiles, but collision detection for 8x8-pixel blocks (8x6, 8x4, 8x2 blocks are possible, too)
- heroine is a werewolf (or is she a wolfwere?)

screenshots:


The 1st test animtion:

First off, nice wolf animation! It's also good to see something out of the ordinarie on the nes regarding hit detection / slope elevation.

Secondly, this.

Impressive camera movement. I look forward to more updates!

The scrolling looks great - but be advised of the potential frustration when a player character is closer to the end of screen it is walking towards than the other. Generally, you want the camera to catch up quick enough to prevent unfair hits.

Loving the animations! Really solid work.

Cool! Looking forward to seeing more.


The character literally runs offscreen, I'd assume this GIF isn't supposed to be representative of a gameplay camera.

Yeah, the gif canvas is 192x88 pixels so it's not representing the full screen width.

Classically, changelings are children swapped out by the Fair Folk. I suppose multiple recentish pop-culture things have used them as shapeshifters instead, though (Star Trek: DS9, MLP:FiM).

Lovely, smooth animation- except for the transformation. Reminds me of a much-better-rendered Milon.

"There wolf! There castle!" Will there be a castle in Changeling? I don't know...

Yes, the start of the scrolling has been a bit late. (good point) I think I could improve it a bit. But when it reacts too fast, it will lose its smooth movements. (it's a balance act)

Yes, the morph-anim could be improved. Currently, the morph just recycles animation frames from other movements. Anyway, ALL graphics are test-graphics only to check out the gameplay!


Testing charged attacks for Ling as wolf. (test-dummy-enemies only)
Should it be possible for Ling in human form to attack?

Try this: instead of scrolling toward the player, scroll toward a point in front of the player. Either a fixed distance in the direction they're facing, or position + velocity*N for some fixed value of N. The smoothing you already have should take care of the rest.

@Rahsennor: Hm... I think my formula for prescrolling does not consider the velocity... Nice hint, I might give it a try!


update: As only moonlight turns a wolfwere into a werewolf (?!?), the gameplay's a bit too boring when Ling is unable to fight. So I gave her some kickboxing abilities.
I also made some tests with throwing daggers, but that somehow felt wrong. (also, silver daggers are dangerous, aren't they?)

Looks really cool.

Awesome animation.
I wonder how many patterns are currently in use. It's so smooth!

There're 19 animation frames for the girl (8 frames for running). She's 16x20 pixel -> 114 sprite images (or a little bit less, because some sprites can be reused)
There're 12 animation frames for the wolf (6 frames for running). Wolf's 24x14 pixel -> 72 sprite images

New working title for the game: "Wolfling"

First test with stais.
When she's running downstairs, she does not look as elegant as Simon Belmont... (needs some tweaking)

Simon Belmont knows you shouldn't run down stairs - maybe stairs could affect the running speed by some small amount?

I really like the way the camera has to follow the player.

It looks "modern"

In handling going down the stairs (in reality, bouncing from edge to edge) you might want to add a bit of a grade period to allow a jump after the player has left the ground. Donkey Kong country has an absurdly long jump timeout in this style, but you can probably get away with ten frames or so. That way there isn't a frustration point where the player finds themselves unable to jump while going down the stairs sometimes.

Battletoads has this problem somewhat. On the ice level, if you run down a slope (instead of just walk) you will likely be unable to jump.

Haunted: Halloween '85 had a problem with jumping from stairs or ramps. It was solved in the sequel by buffering an A press while descending and no more than 8 pixels above the floor. If an A press is buffered, the character jumps the moment he lands.

Zolionline requested a door; here we go. So yes, you will face indoor-action and outdoor-action in the game.
What's the usual procedure to enter a door? Pushing up? (should be Cave Story compatible)
Also, the stair handling should be ok now. (jumping while climbing the stairs works as well)

"up" and "contextual action" buttons both have a chunk; up is more common on NES.

Just don't use the down button like Blaster Master did. I remember as a kid it literally took us hours to figure that out.

Yeah, up is conventional. It's rarely used for much else in a platformer where you don't fire projectiles upwards (castlevania comes to mind as a counterexample, but even simon's quest used up for doors, iirc). It's also geometrically self-explaining. Looking at your controller, 'up' is pointing away from you/towards the distance.

I actually really liked Cave Story's use of Down to enter doors, but that was only made obvious because I read the README before playing. No matter what you use, there's no harm in a little 8x8 arrow sprite appearing above the character in front of a door to clear up some ambiguity.

Button reminder thought bubble (five 8x8 tiles)

Not sure why you tapered the bubble. The bottom portion works well enough mirrored. I'd do 3 tiles, over 6 8x8 sprites; then you can easily replace the content of the thought balloon, which enables a wealth of options. ! ? Z X

Yes, "up" to enter a doors seems to work fine.

I've managed to setup CHRRAM and bank-switching. (using the codeseg and rodataseg pragmas of cc65)
Here's an example of calling a function from another bank:

This works... (at least if I call Bank1Test(); from bank 3, the fixed bank)
It looks a bit complicated, though. Is there an easier way? How do you handle the banks?

The latest cc65 version includes support for trampolines, added by me, which make for transparent bankswitching.



It stacks and even allows for code in a switchable bank to call code in another switchable bank, returning to where things were afterwards (if you write your trampoline to do so, of course).

Ok, I've managed to put famitone and test-music into bank #1 and the exomizer decruncher with crunched data into bank #2. Hopefully, I won't need any trampoline-functions for the remaining 32k. But it might be handy for bigger games.


Finally, I've discovered the reason why my DPCM-split code failed: It does not like famitone. Continuing with a standard SPR0 split. Also working: Slow status display update.

By the way, did anyone modify the exomizer decruncher to depack to CHRRAM directly? Currently, I am using RAM as a intermediate buffer and copying the data to CHRRAM in a 2nd step.

It figures, as Some of Shiru's games have DPCM drums. Pently doesn't touch the DPCM regs. Have you considered using it?


Any decompressor for a codec using back-references, such as LZSS or interleaved PB53 or Bagel, will need to use an intermediate buffer. But that means you can also pack things that will be streamed to CHR RAM while the game is running.

You can use VRAM directly, it's just that you'll be doing a lot of $2006 writes. I think I coded an LZSS decompressor like that.

But why have separate versions of the decompressor for updates during forced blank using $2006 reads and updates during vblank using a temporary buffer? Or do you plan on not having updates during vblank at all?

@tokumaru: For exomizer, just using $2006-writes is not enough, I tried... The algorithm would sometimes need to "read" from CHRRAM and sometimes from ROM. I don't understand the algorithm good enough to know when the input has to be switched. But I think it would be possible.

@tepples: Yes, modifying CHRRAM on the fly is a nice-to-have. Anyway, optional direct decompression to CHRRAM would be nice, too. The compression ratio degrades with small intermediate buffers and splitting data into small chunks is complicated...

The drums? Hm... Ok, maybe I will give the DPCM-split a 2nd try when I have some time left before the deadline.

There's one like that for apLib: http://jiggawatt.org/badc0de/decrunch/a ... 2_vram.asm

The overall compression ratio (data plus decompression code) also degrades with multiple versions of the compressor in the ROM. I guess it's a tradeoff of one type of degradation against the other.

The reason I was reading from VRAM directly was because the LZSS variant I was using supported very distant references, so the stock 2KB of RAM couldn't possibly cache all the needed data.

If you're working with short packets of data, then I agree it makes sense to use a buffer in RAM, but with only 2KB of total RAM, much of which might not even be available for this purpose, it may be mandatory to work directly in VRAM when decompressing pattern table data, which can be as big as 8KB.

For my use (lz4 direct to vram), the runtime updates have different compression, lz4 is only used for entire screens, uploaded during black screens.

Ok, I ram out of memory.
I wonder how much memory famitone2 uses at FT_BASE_ADR=$0100 ?
Can I check this somehow?

IIRC the documentation mentions it.

Ah, ok. This one?

I was hoping for something in the code, but ok... No risk, no fun...

FamiTracker 0.4.2:
245 BSS, 20 zero page, 5547 ROM
FamiTone2:
186 BSS, 3 zero page, 1636 ROM
Pently, all features on:
104 BSS, 41 zero page, 1918 ROM
Pently, subset comparable to FamiTone2:
104 BSS, 41 zero page, 1283 ROM

Pently has a configuration file that disables features at assembly time to save ROM, though it's not yet smart enough to save RAM. Disabling vibrato, arpeggio, portamento, attack track, square pooling, channel volume, and notes higher than D-6 approximates the feature set of FamiTone2.

Would you consider using Pently? Or would I first need to add RAM compaction when features are turned off?

There are some conditional statements in famitone2, it will use less RAM and ROM space if you reduce the number of sound fx channels.

Plus, you can remove the PAL note table, if you are very short on space.

Dunno if this is helpful or not, but my music engine uses 12 bytes ZP and 86 bytes in the stack. It can play most Famitone2 songs.

Thanks for the hints, I wasn't aware that there're so many music players out there.
I wanted to try another player anyway because of my failed attempts to do a DPCM-split.
But I'm not brave enough to select a music player before talking to "the" musician. (there's no musician for Wolfling, yet)
I'm keeping the 186-byte-famitone2 for now: Let's hope the documentation is correct...

Remember that's the stack. Not many bytes after famitone2 available.

Don't wait till January to find one. It takes time to write songs.

Maybe you could ask the musician from Nebs & Debs. I heard him on the latest assembly line podcast, he didn't sound like he was working on a project currently.

Can't remember his name. He also did Alter Ego.

It's Richard “Kulor” Armijo.

I have written a private draft of a wiki article comparing them.

Well tepples, release the article to the public and I'll read it...

Yes, I have to watch the stack when using memory at $01xx, but I have to watch the stack also in standard memory. (the cc65 stack...) That's one of the thing you are "fond of" when programming the NES, isn't it? It's a bit like programming the Atari VCS.

Another thing, can you define the SEGMENT for a linked lib in the cc65 config file somehow? Here, I've linked the standard cc65 runtime library and it appeared in the CODE segment.
Not a big deal, but it would be nice to know - just in case I'll run out of ROM. (that will happen sooner or later, I'll suppose)

I don't think you can, without recompiling the library. (And even then, you have to modify the source code, I believe.)

If you want to separate those by segment it'd probably be easier to just use a different segments for your own code (#pragma code-name, etc.) and let the libraries use CODE/DATA/RODATA.

Yes, that's what I'm doing right now: Using these pragmas for the main code. That works.
Additionally, I have tweaked the setup of the banks, to get 28k for the main C code (BANK2X) by reducing the size of the common bank. That works well, as long as I only switch banks with code from the common bank.

ROM-space seems to be sufficient for now, but I'm still fighting with the limited amount of RAM:
- changed the map format: 148 additional bytes
- disabling music while decrunching: 186 additional bytes
- moving tables into zeropage: 96 additional bytes

Hm... Can I use the RAM at $02xx temporarily if I disable sprites in PPUMASK?

As far as I know, the runtime library is a must if you code in C, and you shouldn't place it somewhere you can page out, as it will render common tasks such as calling functions impossible. The runtime should be always present, in the fixed bank (if you are aiming for UNROM, that is). Why would you want to move it out of the CODE segment, anyways?

You don't have to disable sprites. The sprites are copied into internal OAM RAM and retained there as long as sprites are rendering.

The RAM at $0200 is just used as a temporary holding place for the data before it is sent to the OAM RAM by DMA (write to $4014). If you don't do a DMA nothing in regular RAM will affect the sprites currently displayed.

@rainwarrior: Oh! Nice. I was thinking the OAM will decay, but obviously I misinterpreted the wiki...

@na_th_an: Hm... Yes, you're right, the runtime lib should be placed in the common bank and it doesn't make sense to place it somewhere else. Nevertheless, if I could rename the runtime lib's segment, I could get rid of the pragmas in the main code. But it's not a big deal and currently, I'm too lazy to change that...

There's an open feature request on using some other bank for the runtime.

Re: putting the runtime in a different bank

I managed to do this on a project, but then later switched the entire thing to ASM, thus not needing a runtime.

The solution was (AxROM mapper) to compile each bank (of $8000) separately, and then concatenating everything as the last step in making the final ROM. That way, the entire runtime would be available in every bank.

That's what I do with GNROM like mappers. Work on separate NROMs, then concatenate everything together. Use a small area in RAM which is not zeroed on startup for communication, place your bankswitching code in a fixed segment at the end of ROM space (for instance) so the very same chunk of bytes is in every NROM at the same place, and you are set.

update: a boulder test...
There're still no tilesets or anims from Zolionline, so I guess it's questionable that we finish the game before the deadline.

You could submit it with wireframe graphics like you're posting here... Just pretend like it's a stylistic choice. It looks awesome from that mind set.

Yeah, the wireframe is minimalist enough to come across as stylism. You could still get great scores. And there's usually time between the compo deadline and the cart realisation.

And there's also time between the volume 4 cart and the planned remix compo, which is about taking an existing entry and improving it.

Funny idea to use grey wireframes only... But then I don't have an excuse anymore if I cannot finish it in time... Uh oh...

Or some other free BG tiles on here, like what Twin Dragons did.


And, well, you just need something playable; the compo carts are in some ways the equivalent of software sampler/shareware disks…can always create a fuller game later.

Yes, using free graphics would be an option, but I don't like this idea very much. It would make the game less unique...

Update:

items are working now:
- daggers. again. (only useable for Ling in human form)
- three keys for three different doors
- a heart refills some health
- a moonstone: unknown
- a potion: unknown
- heart container: increases the maximum health

Also, the game can now update sprites in VRAM on the fly when the player morphes. This was needed, because Ling in human form needs 112 sprite images and the wolf and morph images need 112 images, too. Too many to be stored simultanously in VRAM, if you want to have enemies... This is really tricky:
- music is disabled: to free temp ram for exomizer
- OAM updates are disabled: to free ram for 16 sprite images (thanks for the hint, rainwarrior)
- now 16 sprites are decrunched the OAM buffer
- then the NMI code copies 8 sprite images from OAM buffer to VRAM (2 times)
- the last 2 steps are repeated 7 times (7*16=112)
- OAM updates and music are enabled again
There is s short freeze (ca. 0.5 s) when morphing, but it is almost not noticable, because you cannot move while morphing anyway.

And the project has a 3rd member: Cyborgjeff is doing the music
cyborgjeff bandcamp page

Feature freeze! No more new game elements, I'm trying to make the game playable now...

I have build a basic tileset and two testrooms out of Zolionline's mockups: NOW WE'RE TALKING! This feels like a totally different game now.
The project has been renamed to "Wolfling Zero", because I'm to busy to include enough content, except for some kind of "mini-game-prequel".

Also, I have realized, that my "super-smart" idea to stop music to get enough ram for decrunching is GARBAGE, because like this the music stops on every roomchange.
So I had to reprogram the whole decrunching mechanism to allow non-stop music. Much better, but everything's delayed...

So pretty! Really great work, both of you. The theme does a lot here, there's no denying it.

A really good job. The game looks great in the screenshots.

Lookin' good.

At least with all the features colored in on the sprite, it doesn't look like a different character anymore. The hair reads as hair, not a cap.

Can the player shapeshift freely? I somehow got the notion when you wrote "moonstone" and "potion" that these would be the transformation and reformation items, sort of like how you're restricted in changing abilities in smb 3, which could potentially be a bit of a platforming puzzle sometimes... though, i don't know if that is what you intend to - just a wild guess on my side.

Yes, indeed. I had the same impression with the grey "hair-hat". My placeholder graphics cannot compete with Zolionline's art... Of course not

Currently, the only way to morph to a werewolf is touching moonrays, which can be found here and there.
And SELECT morphs back. (anytime)
The Idea: Werewolf form is stronger, but cannot go everywhere. (cannot jump as high, cannot use items)
- most enemies are easier to defeat as wolf
- some walls are too high for wolf
- stone doors can only be opened by wolf-attack
- a potion could manually morph to wolf (n.i. yet)

Yes, that's it. I haven't found many puzzles that need human or wolf form so far and I would be happy if you have some additional ideas!

That sounds like a solid plan.


Some initial thoughts:
-I suppose a moon ray could potentially force ling to transform to wolf. That can serve as both puzzle and lock towards another area. These functional restrictions are for naught if the retroformation is always an option. On the plus side, always being able to morph back grants the level designer some leeway to be able to not take care to trap the player in wolf form. Another approach somewhere in between might be to let wolf acquire the skill (moon crystal?) to morph back at will at some point in the game, thus making previous moonbeam locks/puzzles a blast to pass through (if there's even retracing, that is).

-Likewise, daggers might be an acquired skill. I wouldn't recommend economizing them as ammo, though.

-Is wolf faster than ling and/or has a different acceleration curve? If so, it seems ling can reach higher, but wolf can bridge platforms farther apart on the horizontal plane.

-Is wolfs' hit box lower than lings'? If so, wolf might be able to pass narrow passages ling can't.

-Do both have the same ability to steer (or not steer) trajectory while jumping? Not sure how i would do such a variation useful in terms of platforming, but i thought i'd mention this aspect anyway. EDIT: Well, if she goes off a cliff and is falling, would she be able to reach an alcove in the same direction she came from? How quick might she be able to do that? Same goes for the prospect of scaling an upright wall with little ledges - here wolf is out of question because wolf can't jump high enough.

-Daggers can reach places the player character can't. Thus, daggers may be able to manipulate off-reach interaction points/switches. A variant of this is a special gate that only opens if all enemies have been zapped - just make sure those enemies aren't frustrating to dispose of. You said feature freeze though, so this point is out of scope.

It's beatiful

Sound effects are working now. But I have the feeling that every effect shows up a bit late.
Is that the expected behaviour with famitone2-effects?

Sound effects should begin immediately.

In an emulator, sound latency of ~100ms or more is normal.

If you want to verify, you could try using FCEUX and step frame by frame (use the backslash \ key to step) you can hear each frame's sound as it steps.

Make sure you main song volume isn't overpowering the sound fx. Sound effects should be as loud, or louder than the music (in famitone2) or they won't play.

I modified my vrsion of famitone, to avoid this.

weekly update: 7 weeks to go


Zolionline has finished the 1st enemy, there's a mini end sequence and the NES low level code seems to be stable: The game is fully playable now!!
(but there're only two rooms - lot's of work ahead...)

@FrankenGraphics: Nice ideas... I guess there's not enough time to improve the gameplay significytly, though.
@rainwarrior: Hm... ok, after examining everything, I think only a few effects are a bit late. The problem should be the effect itself, I guess.

update: 6 wees to go...
There're 18 new rooms! (and 20 new bugs)
And I just recognised that my code is too slow to move more than 2 enemies at the same time. How could that happen? It's time for optimizations!

describe "too slow".

are you getting dropped frames? (lag)

try moving to a 30 frames per second animation change system.

that would be, like, do all ppu changes (buffering) in even frames, do all game logic and sprite changes on odd frames.

music should be tied to NMI to stay consistent.

Similarly, but maybe less drastic, you can also often get away with updating different enemies on alternating frames. Half the enemies one frame, half the next.

Also *if* the problem is mainly moving them (maybe i'm reading it to literally?) as opposed to updating them in general, it seems to suggest they have a bit more complex movement code than needed be. Some enemies might not even need hit detection routines, and else, they can sometimes be kept simple; unlike the player character.

Enemies can often be given simpler physics and collision detection than the player. It's not uncommon to see enemies using a single point of contact with the floor, ignoring ceilings, lacking slope physics, and so on. Some enemies may even not require any interactions with the level map at all if all they do is fly or patrol a plain surface.

Update: 5 weeks to go...

@dougeff: Ok, that should work. But as I would like to retain the 60 fps movements, the movement code will still be called in 60 fps and I only lowered the call frequency of the control code to 30 fps. Now the program code is fast enough to move whopping 3 enemies at a time, but only if there's no scrolling.

@gauauu: Yes, that's an old C64 trick. I tried to call the player control in all odd frames, and the enemy control in all even frames. Now 3 enemies can be moved even with scrolling. Seems like querying the joypad with 30 fps is fast enough. hopefully...

@frankengraphics: Ok, I can skip the gravity and BG collision calculations on some enemies if they only walk left and right. If I only use these simple enemies, then I can handle 4 enemies instead of 3.

@tokumaru: I cannot skip the collision detetion, but I converted the collision routine to assembler and now I can move 5 simple enemies or 3 sophisticated enemies.

That's enough for now. Thanks for the hints!

I have also recognised that the NMI code waits ca. 24 scanlines for the SPR0-hit, doing nothing. Any ideas how I could use this time? (I'm already calling the famitone2 handling there)

more on enemies: Some of them can be BG based and stationary (if you have bits for ”hurting” and ”destructible” in your map system, maybe represented as ”structures” placed on top of the more mundane map) which would more or less be ”for free” as they’re part of the player characters’ bg detection. Enemies like castlevania’s twin dragon skulls would be possible this way, for example.

nmi: any timers you’d like to tick, maybe, can go there

Clearing the OAM buffer, maybe? You really only need to set the Y coordinates, but still. Reading the controller(s) and calculating the newly pressed and released buttons is another thing you can do.

3 is not as bad as you think (for the NES).

My Honey game was only fast enough to handle 5 enemies without slowdown. (Also 4 enemy projectiles, and 2 hero projectiles).

Other games I'm aware of had a max of about 5. 3 is close.

@tokumaru: Hm... Yes, resetting Y pos OAM entries in NMI would result in a small speed boost. Didn't think of that one.

Another thing: After switching to PAL, the game runs with 50 fps... But there seems to be less CPU time available for the main code (outside the NMI).
Shouldn't there be more CPU time available on PAL? Where's that lost time? Maybe in the busy-wait for the SPR0 hit?

PAL should have more CPU time.
It may be your sprite 0 waiting loop indeed.

The PAL NES CPU has 6% fewer cycles per scanline, but there are 50 more lines between NMI and start of next frame. So if you detect PAL NES, run more things before the sprite 0 wait.

Dendy also has 50 more lines, but they're all placed before NMI, and its CPU speed is the same (relative to the PPU) as NTSC. So you can use the same operation ordering as NTSC.

PAL has indeed more cycles per frame than NTSC, but a lot of that time is in vblank. If you're waiting for a sprite 0 hit after finishing your PPU updates, you're basically throwing all that time away, and what's left is less than what's in the NTSC visible picture:

NTSC: (240 * 341) / 3 = 27280 cycles
PAL: (240 * 341) / 3.2 = 25575 cycles

PAL only wins if you take the whole frame, including vblank, into account:

NTSC: (262 * 341) / 3 = 29780.666
PAL: (312 * 341) / 3.2 = 33247.5

D'oh!

Maybe it's obvious, but I'd like to share: When short of frame time, I usually measure (visually, via toggling the grayscale bit) individual, short tasks, and make a list of them and the max amount of scanlines they take, so I can move some of them before the sprite 0 hit wait. That will earn you some precious time after it, and you will be throwing away less cycles just waiting. If your hud is, for example, 32 scanlines tall, I'm sure you can stuff some minor tasks right after VBLANK and before the sprite 0 hit wait.

There are some other things you can do to save time. For example, when checking bullets vs enemies collisions, I tend to run the checks in the enemies processing loop, right after I move them, 'cause I tend to cut short the checks - there are more bullets than enemies, and if a collision is registered, you can cut the loop short by discarding every other possible bullet<->enemy collision after you register one for the current enemy. The total amount of checks seems to be shorter this way (looping all the bullets for every enemy) than the way around (looping all the enemies for every bullet). Or maybe I'm talking nonsense. Also, check first for the condition which is more prone to fail, so you can discard subsequent checks: the screen is wider than taller, so checking for X first is a better idea than checking for Y first. There are more chances that the X check fails so you can move to the next entity.

PS - I'm sure there's a better way to measure the amount of scanlines individual tasks take, but I'm still learning

Update: 4 weeks to go...


The characters... Hunter, tooth and firewolf are not implemented, yet. Uh oh, it's about time!

@na_th_an: Toggling the grayscale bits is my favourite way of visualizing the required CPU time, too. Unfortunately, my code is not modular enough to be moved to the NMI, without a lot of adjustments and there's not enough time left. But after some optimizations, it should be fast enough now. Even for PAL.

Another thing... the guidelines say: "UNROM (2): $FFD0-$FFF9 must be unused."
How do I setup this in the ca65 nes.cfg? Is it ok to define a special section and to fill it with $00?

I just put my DMC sample in the last part of the ROM before the vectors, and made sure it wasn't too long to spill into this area.

so, yes, special segment. auto fill. "fill = yes"

update: 3 weeks left... (uh oh)


Ingame music and a lot of background graphics are still missing, but we have a miniboss...

Is that a web browser mascot I see?

The smoothness of animation and movements is impressive O_o

Yeah, even with wireframe background, it's a looker!

update: 2 weeks left

We have more background tiles now. And they're even better than the previous ones. YEAH!
But can we finish the map in time? (drumroll)

@tepples: almost... but then it was called fireWOLF.

update: 1 week left


The new graphics from Zolionline are halfway included, but I have found a lot of additional bugs...
Nevertheless, the game should be finished in the next few days. But only one level.

That's a pity, because there's easily enough ROM space left for two additional levels.

At least you have the time between judgement- and cart inclusion if you want to push it further up the hill

Looking forward to see how it plays!

That's the good thing. Once the compo is finished, you still have time to add whatever you want so the game in the cart is the best possible rendition.

Personally, I consider that cheating if it goes beyond game-breaking bug fixes.

I don't think it's cheating as the version you have to consider when voting is the one available on deadline. Further work is just enhancing the game for the cart, so cart buyers get the best product possible.

But I think we should discuss this issue elsewhere and stop polluting this thread.

Ok, "Wolfling" has been submitted. (eh, will I get an acknowledgement of receipt?)


I had enough time to add new rooms, so there's only ca. 1k ROM left. That's probably not enough to add more levels, but anyway, it might be interesting to know if it's ok to add another level after the voting or if this is discouraged.

Thanks for all the support, especially to Zolionline for the graphics and Cyborgjeff for the music!

i'm just repeating myself here, but it looks good (and fun)!

Confirmation is probably manual?

We continued the discussion for a bit in the rules thread (maybe you saw it?) As far as i'm concerned, nothings' to stop you from updating it, especially after voting has concluded. I mean, it's up to you how you want to represent the game on cartridge.

Brad (NESHomebrew) emailed me about 12 hours after I submitted. I suspect it will be whenever he gets a free moment.

If you describe how level compression works, someone might be able to help you pack things tighter.


So long as you don't release the improvements until voting closes, of course you could add more levels.

Yes, it might be possible to free some bytes, but it would be a lot of work. I think it depends on the feedback: If the game isn't well received, then another level makes no sense.

Uh oh, both test players found an annoying bug after I have submitted the game. I resubmitted the game with a fix...

I don't think you have to worry about the game being poorly received... I'm pretty sure there's a ton of us who can't wait to play it.

And congratulations on submitting on time!

Here're the links to Cyborgjeff's "Work in Progress" of the two main songs of Wolfling:

https://soundcloud.com/cyborg-jeff/sets/nightmares-wolf
https://soundcloud.com/cyborg-jeff/sets/from-my-mind-to-famitracker

have fun!

Here's a softlock:

Small one, since you'd lose all progress here anyway.

If you die as a human in permanent moonlight (maybe any moonlight) you can no longer get back to the title screen.

i just played for the first time and it's quite impressive! nice setting, mood, music, art, and gameplay.

i like to try to give constructive critiques and obviously you can feel free to ignore, but i felt like there was one thing that was holding back the flow of the game: you appear to lose all momentum when you either finish a roll or land a jump.

for example, right here:



my instinct is to land the first jump and to immediately jump again. however, when i land the first jump and lose all velocity, then the second jump just winds me up in the pit (happened to me my first 4 games...). similarly, in wolf form, i instinctively want to use the 'momentum' from a roll to leap forward (which i think would be a LOT of fun to get a nice big leap at the tail end of a roll), but it doesn't work like that!

just my two cents! very nice entry.

@Katsumi: Yes, you're right, I could reproduce it. Thanks! (5650 points? Hui!)

@toggle switch: Yes, the momentum vanishes on each touchdown. Obviously, Ling isn't a good triple jumper.
Anyway, I think you're right, the ability to do multiple jumps without losing the momentum could be a nice tweak to the controls. And you're not the first one telling me this, I'll think about it.
With this feature, it would be possible to add some kind of jump challenge where you can only pass when you're doing multiple jumps with full momentum. Interesting.

It might not be a good idea, however, to make inertia after landing quite as slippery as some builds of Lizard. Consider preserving momentum if the player is holding forward.

Things i really like with this game:
-Great style!
-If you ignore the the characteristics of nes graphics in general, it feels a bit like a commodore or DOS game. It's in the philosophy of the controls, the status text printout, the split HUD, little things like that. It feels refreshing!
-the ambition and fine granularity of the collisions makes a richly varied platforming experience possible.
-the "modern" camera
-level + graphical assets makes me want to explore, and that's great fun!

Critique:
-I had the about the same problem as toggle switch with the controls. It takes some time getting used to (which is fine), but the control scheme feels just a bit like a translator between me and the game (i guess all control schemes have this role, but it's less transparent here), and i need to think a bit more carefully how i phrase things to the translator in order for it to translate my intentions to the game as intended. Maybe a study case, although it's quite different in its aims and designs, would be metroid (nes). It also has two jumping modes. Perfectly controlling which one to use takes a bit of learning, but the consequences for failing isn't as harsh.

-I find it maybe a little too easy to trig the (re)transformation by mistake - but maybe better habits would settle when playing this game on repeated occasions. In any case, i would've prefered select, i think (it's usually the goto character selection button), which also would mean transformations can happen at the exact time i press the button

-There's frequently little collision bugs here and there. You probably already know about these? Nothing too serious as it is mostly cosmetic, or else just a hickup in the flow of the game. I haven't gotten stuck or anything because of it.

Wolfling fails to start in Action 53 volume 4 page 1. I investigated further, and I got the solo ROM to fail as well.

Reset vector is $D300

1. Open wolfling.nes in FCEUX for Windows
2. Wait past Lazycow for title screen
3. Pause execution using Pause key, frame step, or Step Into
4. In debugger, set PC to $D300, the value at the reset vector. This simulates pressing Reset on the Control Deck.
5. Optionally start the Trace Logger.
6. In debugger, click Run to continue.
7. Execution gets hung up on a STP ($02) at $9313.

Trace log shows that it goes off into the weeds with an RTS at $F735, returning to incompletely initialized code in zero page.

Happens on a PowerPak as well:

1. Select wolfling.nes and start it.
2. Wait past Lazycow for title screen
3. After the third note of the intro is pressed, press Reset on the Control Deck.
4. The screen stays blank

Hitting 'reset' during gameplay, in several emulators, crashes the game.

Not sure if it's relevant, but gameplay has bank #2 in the $8000-bfff slot rather than bank #0. Perhaps this is the problem. (ie. the reset code might expect bank #0 to be in place).

Finally I had the time to test this.

Well done, I like the level design. It feels non linear, and incredibly moody. The animations are quite good too, specially the main character's in wolf form. I loved how the camera follows the action, too.

I didn't like the way you lose momentum, though. With time I learned how to deal with it, but somehow it didn't feel natural. Or maybe it is not that the player loses momentum completely, but the time it takes to gain it again.

Another thing that IMHO should be polished is vertical screen transitions. There are many times when you don't jump with enough strength and you get several transitions in a row, which detracts from the experience. While it's not a perfect solution, I tend to solve such situations in my games by means of boosting vertical velocity artificially when changing screens upwards. That way 1.- it gives the player extra time to look for a landing platform and 2.- prevents such situations where you just didn't jump high enough from the screen below.

Great job, nonetheless. The music is superb and the mood and athmosphere is great.

@frankengraphics: Yes, SELECT might be the better key to morph. (why did I change that? I cannot remember)
If you're refering to not pixel perfect background collision handling, then you're right. That's done on purpose to save valueable CPU time. Nevertheless, a slowdown might occur if you avoid killing enemies everyone is following you. But it should be rare - it's "calculated risk by design"...

@tepples: Yes, I could reproduce the crash. There's a stupid bug in the startup code. Well, actually, the bug is very smart, but the programmer was stupid. Do you want to have a hotfix?

@dougeff: No, but almost. It's a bankswitching problem, indeed.

@na_th_an: Yes, you should not lose momentum when you continue to press the joypad in one direction. I'm definitely considering a fix, in case I am creating an updated version. Additionally, I tried to design the rooms that you don't have to jump vertically into another room. So hey, DON'T DO THAT! Listen to your mother, walk on the stairs carefully, don't jump on them...

Phew, this NES project is challenging. Thank you all for the feedback!!

Hmm, unless i misunderstand you, it's not that its not pixel perfect in definition. It's that sometimes it's off by 8px blocks which means you can stand half inside a grid-bound 16x16 block. I mean to play this again soon (and this time be able to beat it, hopefully!). Would it help if i PM:ed you screenshots and descriptions any such occurrences i may come across?


It's quite an impressive scope this game has - and still, you managed to do it! This game is a great addition to the NES library.

Cool game.

Minor quibble: The red projectiles shot by the skeletony stone heads are way too dark, IMO. I can hardly see them against the black background with the palette I'm using. I would be worried that this might be an issue on some displays when playing on hardware. I think Haunted Halloween 86 had a similar problem with a deep red used in its backgrounds.

What version of the FCEUX emulator have you used to test both "Action 53 volume 4" and "Wolfing"?

this?: newer FCEUX build from AppVeyor

My copy of FCEUX (SDL) is r3392.


Which is based on having done this in the past week:


My build of the Windows version (used for debugging) from AppVeyor is also r3392.

But the reset button bug also happens on hardware. I haven't opened my NES-001 Control Deck, but I'd be surprised if the CPU and PPU were anything but revision G.

I saw FrankenGraphics post, I recorded these GIFs, my internet went out for a whole day before I could even upload them to post.

Here is some collision quirkiness in wolfling:
Standing on air as the worst offender.

Ride the wave.

Quite far into a wall.

The behavior itself could probably be fixed without much hit to CPU time (it may even use LESS CPU time depending on what you're doing), but actually a lot of the level design appears to rely on it.

When I first played I noticed the collision stuff as well, but I never found any zips or anything. But I also didn't find the stand on air thing.

The situation in the bottom screenshot is pretty easy to reproduce as it happens to me every time. No big deal, tho'.

Ok, I have uploaded the patched Wolfling ROM with includes the reset-crash hotfix... (at the 1st post)
I could reproduce the crash bug in FCEUX, but not with Nestopia. (unfortunately)
Does it work now with "Action 53 volume 4" (or powerpack?) Tepples?

@thefox: fair enough

@Kasumi: Yes, I know these 3 glitches. That's what I call "not pixel perfect background collision"
(no fix planned, sorry)

The crash bug appears to be fixed in FCEUX debugger. I will include the fix in the build I post to page 2.

I couldn't work around the way you lose momentum, and kept dying in the first outdoor part, where you go left as wolf and fall to spikes if not perfectly timed. After five deaths I said screw it and closed it.

The idea and the art were quite nice, but the gameplay has some issues.

At last, I had some time to work on the improved version a bit:


Bullet color had been changed from dark-red to orange. (thanks to thefox for reporting)


Wolf's background collision frame is centered now. (thanks to Kasumi for reporting)

to be continued...

Ling keeps most of her momentum after landing. You're right, this makes the controls more intuitive.

Zolionline is improving the rooms a bit and then it should be finished. Is there a deadline for the improved version?

My guesstimate for when volume 4 updates are due is when Paul at INL actually gets around to releasing volume 3.

Update: I have improved the compression scheme of the game map to add 20-30 new rooms. Here's a preview of a 2nd castle (left) and a new subterranean area (right).
It's very hard to create new rooms with new ideas for this game, I don't know why. The tilesets are not the problem, they're very flexible. Either the game mechanics are not very elegant, or I am getting old... (or both)

What kind of compression scheme are you using? The maps seem to be fairly free-form, so I'm curious.

@Rahsennor: I'm using exomizer to compress the map data. (and the graphics)
Exomizer's compression ratio is pretty good, but it adds a 30 bytes header to each file, while the new modified exomizer decruncher allows to use the same header for all rooms.

This doesn't sound much, but the formula is: 45 rooms * 30 saved bytes = enough space for more rooms.

Thanks and congratulations for making this game! I was deeply impressed after reading this thread, the graphics & animations & colors & game engine are looking fantastic. Hmmm, well, and after playing the game... I wasn't soo impressed about the game flow.

For example, this simple task beats me, I've tried maybe 30 times, but passed through only 5-6 times, and everytime else I had to walk back towards right to climb up for retry (and re-fail) another time.

The new keep-momentum-after-jumps feature does probably improve some of it (though I couldn't find that new version being released anywhere yet).
The slippy (or descending) floor is making things also difficult - I drop from the platform even after successfully landing on it. Using dpad-right to stop slipping doesn't seem to help either.
There seem to be various possible jump distances, depending on if or how long dpad was held before jump. That's kinda cool, but hard to control. For cases like very-short-jumps and vertical-up-down jumps... are there even cases where one needs that jumps for solving the game?
After some hours of not so successful jumps with wrong distance, I've figured out that one can also jump at different height depending on holding/tapping the jump button. I don't know yet if that's making things easier - or if it just offers me more ways to fail ; )

Difficulty
As you might have imagined, I think the jumps are difficult to manage. Maybe it's getting easier after learning the game controls, but for beginners it's a bit frustating. For the scene pictured above it, it's also a bit uncomfortable to learn by retries (walking all the way back right, don't get hurt by the spikes, and then climb back up does kinda delay the learning process).
Then in the next scene, there are those skulls throwing fire-balls. They aren't too challenging, but passing them does slow down the game flow. I would disable the fire-balls in most cases, to make the game faster, and add fire-balls more sparsingly, or only later in the game.

The nice thing about wolfling is the animation and scrolling that invites to run freely. After all, a wolf can run faster and farther than the guinea pig in Gruniożerca 2 - or I would have thought so. In practice, the obstacles in wolfling do require some careful planning & training on how to pass them, without allowing too much free running. Maybe you could make the game start with less obstacles, or insert some easy passages between obstacles. Maybe just insert a long corridor without obstacles here and there, if it's compressed then long corridor vs short corridor won't even take up more memory.
EDIT: I've meanwhile figured out that the game gets easier after the first some obstacles, not so much because of more training (I still fail on the above jumps), but because there are longer stretches that permit running, and options to explore different passages. Having such options more at the beginning would be nice: Ie. offer passages with difficult and easy tasks, and allow users to chose which one they want to solve first.

Attacks
Using different buttons for attacking as human or as wolf is a bit bewildering, can't you use the same button in both cases?
Is there much of a reason to delay human attack until releasing the buttton? And if it's done that way: It would be nice if one could still change direction before releasing the button.
Attack during human jump seems to do some air-kick, which is nice. But the side effect is that one can't attack after landing. If the attack button is still held down at landing time, then I would make it to invoke the attack-on-ground (as if the button would have been newly pressed at that time).
Attack during wolf jump seems to cause the wolf to shoot forwards a few steps after landing. I haven't figured out what that's good for yet. If there's no purpose for that feature: I would also change it go to the invoke the normal attack pattern when landing with attack button held down.

Music
I don't know how to say it, other than saying that I don't like it that much. To me, it's pretty chaotic (in my emulator at least). It sounds like slow paced middle-age bagpipes, that might match game theme, except I don't really like bagpipes (they are often too loud, and they lack rhythm). The music in the game does have some rhythm, but it feels as if it would randomly start and stop after a few beats. And then there are all those sound sweep effects, that sound more like collecting bonus items in super mario, but not so much like music intruments. It's unique, but I am a bit troubled to get familar with it.
On the nice part, there are different songs in different scenes, only the fade-over from one song to another is a bit abrupt. Maybe it would sound better when doing some fade-out on the old song before starting the new one.

Hearts
I can't make sense of the heart-symbols during the wolf-scenes. For a long time I've believed that it's a software glitch with vram corruption - but now I think that it's an intended feature for the wolf-scenes. But I could only guess if it's showing bleeding hearts? Or wolf claws? Or nine small hearts representing the cat's nine lifes?

Water
Do you have water in the game already? It might fit in nicely both outsides aund undergrounds. It could also act as one-way passage if the player gets carried away by the stream, and if you add a waterfall then one could chose to get carried to a basin downstreams, or to jump to a platform from the top of the waterfull.

Slopes
Since you have those nice stairs in there (without obeying to 16x16 pixel steps), couldn't you also add slopes that go up, or up and down? That could look nice outdoors. And castles could even have it indoors, I think back then there've been no strict legal requirements for having modern staircases in all rooms. On the oppsite: They might have avoided stairs on the main ways if they wanted them to be open for ox carts and the like.

PS. Holding button for morphing is fine to me. Somebody suggested using SELECT for it, but I don't like that idea (I would use SELECT for things like entering in-game options, but preferably not for actual game controls).

I guess I already commented on it before but will mention again after retrying the latest build.

The graphics and animation are great. The camera movement is excellent. The music, I have no issue with it. The gameplay is fine except for the jump which is unnatural compared to other platformer. Losing velocity after jumping makes it hard and I always forget that I cannot jump again, which makes you fall or make you fail you jump. If it was part of the game play then it slows it down too. If you could continue jumping without losing velocity it would big improvement.

Hey, thanks for the feedback! Yes, the improved version of Wolfling will have refined controls. (the new controls have been tested by the lemon64 forum and by forum64.de people only) It's currently in beta test and should be finished this year. (I hope the Action 53 Vol 4 will be delayed long enough??)

@nocash:
- Your comments about the level design make sense. The new rooms might address some of your concerns. (but only some) I gave everything for the new map, but I guess it's still not on the same level as maps from commecial NES games. (I'm a padawan in level design)
- Yes, you're right, it would be much easier when Ling would punch immediately! But I didn't remove the haul delay completely, because I think it would be too easy. (I tested it and I never died)
- Wolf's health bar are wolf paws

I've somehow got selected as beta tester for the Wolfling - I hope there are more testers for the NES version?
Maybe also including more motivated and experienced gamers with hardware at hand for testing on real consoles.
I haven't been that much into playing games since 1992, and I am probably not the right one to do a full walkthrough.

Anyways, here some comments on the new beta version...

Controls
In everynes.htm, I've this description for the joypad (but no idea if other people agree on that):
The old Wolfling version did actually use A=Jump and B=Attack/Morph. The new version has swapped that around, and it's now using B=Jump and A=Attack/Morph?
That's somehow unfamilar to me, with the new controls I tend to forget which button was what after about 1-2 seconds, my best solution is to do button tests every time before trying to use the right buttons in more critical situations.
If you could get back to the old controls would be nice. Or if you want to stay with the new controls: Then don't forget to update the in-game hints (they are still saying "Press B to morph").

Jumps
Momentum after wolf jumps is kept, but not the full momentum. When doing continous jumps you are getting slower and slower. And for human jumps, the momentum isn't kept at all?
If the DPAD is kept pressed for running, why not keeping the FULL momentum after jumps? Or, even INCREASE the speed (until max speed) after jumps as long is DPAD is kept pressed?
I don't know which is more realistic, but it would be more fun if you could run & jump fast.

Also, continous jumps work only if release the jump button for a moment and then press it again (while in mid air). It might be more fun if you could just keep the jump button held down.

Morphing flicker glitch
The new version is having some bad flicker/scrolling glitch upon morphing (or my emulator isn't working).
Either the status bar, or whole screen are flickering wildly (with wrong scroll offsets) about everytime when morphing.
For morph-to-wolf it's flickering shortly before morphing, and for morph-to-human it's flickering shortly after morphing.
This seems to happen in NTSC mode (PAL works without that glitch).

I am still missing some training ground where one could just run and jump freely. Both for fun, and for getting familar with the controls.
One minor change would be removing/raising the ceiling in the first room, so you won't bang your head everytime when trying to do some jumps:


For the jumps, I have just learned that one can push DPAD in opposite direction mid-air to set the momentum to zero. I doubt that it's too realistic, but I know feature from other games, and I guess it can make controls a good bit easier... although when pusing DPAD too early... I've just discovered a new way how to fail jumping ; )
I know, other people don't have problems there, but they are probably doing more sports and less smoking.
How are chances that you could add a safety platform underneath of the two holes? Then I could still fail, but I would have a chance to continue towards left (or have an easier way to go back right, for doing another try).


Here comes a nasty new detail. In the old version I was thinking that the blocks with gaps were looking difficult. Then I just tried to run across that passage and thought "wow, that wasn't so difficult". That was my first "success" experience in the game : )
Now the new version has a new enemy added right at the end of the passage - so I stopped running and droped through the gaps ; (


The room below, that is where I had the feeling that it's where the actual game starts because it allowed to explore different paths. And the way up leading to a longer passage where you could (finally) run freely - even if it was dead-end when not having collected some key in advance. To my dismay, I found that it's now blocked by a blue door : (
I've recently read somebody praising Metroid for being the first game with non-linear gameplay, where one could explore different paths and never needed to follow the same linear path to solve the game (which actually, I think Sorcery or Zork had such features before Metroid).
Anyways, nonlinear options wouldn't look bad in a game like Wolfling. Allow people to collect the yellow key and open the yellow door. Or allow them to go for the purple key first. It's more interesting when having that options, and motivating to be able to try something else if one part feels too difficult.


And the game start sequence. In old version (red) Ling appeared mid-air and got thrown deep into the room. In new version (orange) it looks more as if she were politely waiting for door to open and then hopping into the room.
I liked the old version a bit better (apart from the mid-air approach). I think best would be to start with the door already open, and then show her getting thrown into the room (cyan) from offscreens. If you can't throw her that wide, maybe move the door 16pixels closer to the screen border.


Well, I hope that heven't been too many new suggestions. Feel free to ignore them if you disagree, or if they take too much time. I know you just want to bugfix & finish the game at the moment, without adding more and more new details : )

PS. if you could still consider disabling the first six fireballs - that would make it easier to get started, I still think they are mostly boring and distracting (in terms of slowing down reaching more interesting areas) (and boring especially when you restart the game a bunch of times, and have to pass those fireballs over and over again) (whilst later on in the game they may be a nice addition).

@nocash:
- Yes, (A) and (B) are swapped by accident in the BETA. (oops)
- Yes, Wolf should keep her moving momentum after jumping. It's a bug.
- Yes, the girl doesn't keep her moving momentum after jumping, I didn't like that. But she has more control in the air now!
- Yes, the girl starts at the wrong pos at game start! (oops) Nice find!
- map design: Good point, I will try to do some adjustments, but I'm definitely too lazy to change the complete map, sorry

If someone is interested in BETA-testing the final version of Wolfling, please write me a message. (It's a closed beta test, but the final version will be available for free download of course)

Ok, Wolfling V1.3 is finished now.
It fixes some bugs, features improved player controls and there's a bigger map.

Ooops, there's an evil bug in V1.3! Sloppy, sloppy...
I have attached the fixed V1.4 to the 1st post.

Awesome, I highly recommend people giving this game another shot if you were put off by some of the control/momentum issues in the earlier version, as I initially was. Everything feels so much smoother and quite a lot of content has been added, so definitely try it out if you haven't or if you gave up the first time around.

Hello, i've just finished a map of Wolfling. If anybody is interested, then it's available here: http://oscomp.hu/?details/Wolfling_V1.4_Map_NES_1532

Nice to see the whole map! I am still stuck earlier in the game. Btw. if somebody wants to see how I dealt with the new safety platform: It's a hopeless case:
First, I slipped off the safety platform (it was yet too short for me). And then, I intentionally dropped through the first hole, figuring that it would be easier to jump-back-up rather than trying to jump over the second hole. But, having spilled coffee into my last working PS/2 keyboard some months ago... cheap USB hardware took control, and, barely trusting my eyes, I ended up watching Ling shouting "Moonlight!" somewhere in the next room.

@TCH: Nice map!
@nocash: No, I don't add a 2nd safety platform under the safety platform

I think I got a softlock here:won't let me go back right, don't have the key to go left.

Nestopia's rewinding support sometimes breaks things, so this might be a bug due to that instead, but I'm hoping it's easier for you to test then for me to repro in a different emulator... I do have a nestopia save state in the broken state, but nestopia lacks a debugger.

You can leave the lower floor in the room to the right, otherwise you're trapped.
But why is it impossible to go right? Does the game refuse to switch the room?

Yeah, from where the player is it won't let me go right, through the gap there.

As I said, this might be a bug in Nestopia corrupting memory instead, but I hoped you might have the ability to make a special build that changed how the game started to reproduce that situation more easily than I could replay all the way to there.

Hello, i've found a very amusing bug at the end of Wolfling. Evidently, it is possible to overjump the final cliff and thus fall into the chasm, but suprisingly land at the leftmost door of the castle.



To see it for yourselves, try this puNES savestate: http://oscomp.hu/depot/wolfling14.p02

Here is the method to repeat it:



Little explanation: take a momentum on the first platform, jump, but land on the second platform at a distance from the third, to be able to jump again and jump over the third platform, but right before you exit at the rightmost point of the screen, press fire to bark and gain some extra momentum.

And here is another savestate which is right before the ending, for trying purposes: http://oscomp.hu/depot/wolfling14.p03