It is currently Mon Aug 20, 2018 2:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 88 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
PostPosted: Wed Mar 14, 2018 2:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7398
Location: Seattle
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Wed Mar 14, 2018 2:27 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1719
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 3:18 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 779
It doesn't tick in battles or inventory.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 12:09 am 
Offline
User avatar

Joined: Sat Mar 30, 2013 12:24 am
Posts: 349
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).

_________________
www.mteegfx.com


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 3:34 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 779
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.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 4:04 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1719
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 6:08 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20421
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 10:26 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 11:16 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 779
CHR-RAM decompression would take too much time.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 11:52 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1719
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 12:22 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 1:26 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20421
Location: NE Indiana, USA (NTSC)
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:
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


Top
 Profile  
 
PostPosted: Mon Mar 19, 2018 2:59 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 779
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 88 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group