Progress thread: Inherent Smile

Moderator: Moderators

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Progress thread: Inherent Smile

Post by lidnariq »

FrankenGraphics wrote:That frame there looks off because the weapon is missing. It wasn't planned like that but in the end there was too little ROM/too much content to fit everything, not least animations and features tied to them... most notably the boss which is on strike. There are quite some quite rough cuts.
I was trying to point out that the weapon was present before the attack, but what's shown after the attack is the leek leaves instead. My original phrasing was not sufficiently specific.
Tips on playing: Go fast, try not to wait around too much. There's a timer increasing the difficulty.
Ahhh. Got it. My normal penchant for exhaustively searching a dungeon backfires.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Progress thread: Inherent Smile

Post by FrankenGraphics »

I'm actually unsure if the timer ticks in battles too or if it is exploration mode only. If the former, it might make sense to flee stalemate-y fights until you get stronger equipment to mitigate difficulty ramp/progress ratio.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress thread: Inherent Smile

Post by calima »

It doesn't tick in battles or inventory.
M_Tee
Posts: 430
Joined: Sat Mar 30, 2013 12:24 am
Contact:

Re: Progress thread: Inherent Smile

Post by M_Tee »

I would love to see what the game could look like if the exploration mode were more visually in-line with the combat and title screens.

Unfortunately, the difficulty curve was just too steep for me to justify playing any further (also there were some strong nametable errors while playing on an Everdrive and a Famicom.) Moreover, the size of the blue bar that represents items changing based on distance could help with visual orientation a whole lot.

The decision to increase difficulty for longer wait times seems... unusual, at best? It seems like all it does is punish less experienced players and/or exploration (which seems like it'd be the personal objective of most players - even if exiting the maze is the official objective) Moreover, why not communicate this information to the player? (This could be done with as little as some text about increased danger at night and palette changes while in map view to indicate time of day).

Ultimately, it was an ambitious title, and I respect that. In the end though, it felt like two partially complete ideas put together and not a cohesive product. Although its difficulty curve and aesthetic inconsistency definitely held back my enjoyment of the title, I'm curious as to see what it might grow into (or what else could be done with the first person mode).
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress thread: Inherent Smile

Post by calima »

The vsync bugs were fixed in later ROMs in this thread; the treasure indicator does change with distance, but only in 8px blocks due to limited space.

The usual enemy variety is based on where you are, which would have taken too much space.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Progress thread: Inherent Smile

Post by FrankenGraphics »

I basically agree on all design points made by m-tee.

Ultimately i think a dungeon crawler /maze rpg is pretty challenging to pull off on CNROM as it is dependent on a lot of data tables, but what we have here is three subgames competing for that same prg space:

-realtime 3d game
-crawling rpg with stats, a basic level system, treasure hunt & monster fights
-clipdoll dressing game (try on different equipment, see them displayed in battles, and discover useful combos. Not unlike Diablo in that sense)

the third didn't exactly compete as most of that is chr data which there was plenty of, but also some space-related choices made this subgame largely unavailable to the player (ie need to hurry through the labyrinth because of timer based difficulty, no stash/store, limited space for all the data needed to fully realize it).

if ROM size would be brought up to the scope of the design, i think it has a really good potential. As it stands it is kind of more of a technical demonstration.

For cart inclusion, i think it'd make sense to nerf all enemies or buff the player in whatever way possible since the difficulty makes it forbidding, which counteracts the demonstration. I don't think we can achieve good balance as-is, but it could be made easier to experience. Maybe simply the player base stats could be brought higher to give a headstart.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress thread: Inherent Smile

Post by tepples »

Conversion from CNROM to UNROM, as was done for Solar Wars in volume 2, would allow compression of CHR data. Would that be enough to free up some space for enhancements?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Progress thread: Inherent Smile

Post by infiniteneslives »

Unless the abundance of CNROM projects this year permits significant compression, it doesn't look like we'll easily fit in 512KB for all entries. The raw total is around 750KByte. So there's quite a bit of space before we hit 1MB if you want more space for the published version.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress thread: Inherent Smile

Post by calima »

CHR-RAM decompression would take too much time.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Progress thread: Inherent Smile

Post by FrankenGraphics »

i think what INL meant is there's no need for compression in the first place? Lots of available space. I'm always up for prepping the last omitted assets and test/hex edit some balance points if you're up for implementing the corners that had to be cut/algorithm-ified. I suppose that'd make the game "category 2" but speaking strictly for myself i don't have a problem with that.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Progress thread: Inherent Smile

Post by infiniteneslives »

FrankenGraphics wrote:i think what INL meant is there's no need for compression in the first place? Lots of available space. I'm always up for prepping the last omitted assets and test/hex edit some balance points if you're up for implementing the corners that had to be cut/algorithm-ified. I suppose that'd make the game "category 2" but speaking strictly for myself i don't have a problem with that.
Correct, now that the compo is over there really aren't much for rules provided we can make everything fit on the cartridge. Any improvements based on feedback from the compo are more than welcome. We're all for making the cartridge better. Looks like we will probably have decent amount of rom to spare, so if you're interested in expanding the entry a little to improve things the cartridge should be able to afford that. How you do that may get a little complicated though as you're likely setup for 32KB fixed PRG-ROM currently..

I wouldn't recommend spending large amounts of development time on entires post-compo. Last year I think we requested people have their roms ready for publishing by the end of March, results were a little delayed this year so maybe the better rule is 1 month after results are posted (mid-April). That way Tepples can start finalizing the rom, we have a general idea of what all games will be on the cart so we can start the artwork process. Beyond that, for the entrants it's time to start thinking about next year's compo.

If you have significant improvements/expansion you'd like to apply to an entry it's more than welcome for submission in a future compo as well.

Since the compo is over now, the idea of changing categories post compo doesn't really apply so long as we can still get it in the cart.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress thread: Inherent Smile

Post by tepples »

Perhaps compression is assumed necessary because the next binary step up from 64 KiB (entry size limit) is 128 KiB. If only a few more kilobytes are needed to turn the tech demo into a finished game, the rest is wasted unless it's used (say) to soak up other games' compressed CHR data.

But you still have 32 KiB of CHR RAM. If the CHR data compresses from 32 KiB to (say) 22 KiB, you can decompress all the CHR data into RAM at the start and then use the extra 10 KiB for self-contained or less frequently accessed things, such as the music engine.

Code: Select all

A53_REG        = $5000
A53_CHRBANK    = $00
A53_PRGBANK    = $01
A53_MODE       = $80
A53_OUTERBANK  = $81
A53_VALUE      = $8000

MMC1MIRROR_V   = $02
MMC1MIRROR_H   = $03
MMC1PRG_32K    = $00
MMC1PRG_FIX80  = $08
MMC1PRG_FIXC0  = $0C
A53PRG_256KBIT = $00
A53PRG_512KBIT = $10
A53PRG_1MBIT   = $20
A53PRG_2MBIT   = $30

a53_init:
  ldy #A53_OUTERBANK
  sty A53_REG    ; reg $81: outer bank
  lda #$FF
  sta A53_VALUE  ; needed for standalone A53 use, patched to BIT in multicart
  dey
  sty A53_REG    ; reg $80: mode (similar to MMC1)
  lda #A53PRG_512KBIT|MMC1PRG_FIXC0|MMC1MIRROR_V
  sta A53_VALUE
  rts

set_chr_bank_y:
  lda #$00
  sta A53_REG
  sty A53_VALUE
  rts

set_prg_bank_y:
  lda #$01
  sta A53_REG
  sty A53_VALUE
  rts
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress thread: Inherent Smile

Post by calima »

Using the a53 mapper directly would allow instant CNROM-like CHR switching with more PRG, yes.

However, I'm not going to spend a lot of time on this, which rules out any mapper changes and the like. It's full, PRG almost to the last byte (it was full to the last byte before the vsync optimization saved some...). Lowering the difficulty curve might be possible, when I have time later.
Post Reply