Wolfholm Development Blog

IMBrendan

Member
Hey All,
in an attempt to keep myself motivated on this journey I have decided that I will be maintaining a WIP dev blog for my first NES playable game. The title of this game is Wolfholm and will feature a transforming player that will interact with the world differently depending on if they are a wolf or a human. I'm excited by the storytelling possibilities that come from having NPC's and monsters interact with each player object differently.
Based on a web comic world I developed many years ago - there are many characters and monsters I will be looking forward to putting into my game. That being said - with the limitations of the NES I may need to pick and choose a few characters that might not make the cut.
I've started basic development - level design for some of the spaces that I know will be in the final game - but a lot of the next few days will be spent thinking about what mechanics will make the final cut of the game before I start fresh at implementing them in the game.

Below are some screen shots from the art testing phase (ONGOING) -

* The first two images showcase Miss Molly and Jack - who are returning characters from the comic. Known for running "Molly's House for Wayward Toys" these two are always up to no good and can only cause trouble for the human player.
showcase3.png
index.php


* The third image shows off grandpa's cave - as well as a test of a slightly smaller sprite configuration (24px) for the player character - after some quick testing the player characters height returned to 32 pixels as it looked a little silly and takes away from the complexity available to the player character sprite.

showcase1.png

* The final image is ripped from a potential story screen and features art that has been downscaled from original art used in the web comic. expect many other examples of this technique used to tell the story of Wolfholm.

Mesen_2viROw57D4.png


KNOWN BUGS AND ISSUES:
* Player transformation only works on first screen after warp
* Text tiles and NPC text not set up correctly yet
 

Attachments

  • showcase2.png
    showcase2.png
    70.7 KB · Views: 69

IMBrendan

Member
In creating the world of Wolfholm, the biggest consideration is being put into the mechanics of how we tell the story. Because this idea is based on a webcomic - the development of some of the characters for the world was fairly easy. Certain monsters from the comic translate very quickly into the world of a game and needed very little consideration. That being said, the NES is not a storytelling platform - its designed for games. Many games have deep lore that is only expressed in owners manuals and guidebooks. I want to avoid that in the development of Wolfholm and put as much of the story and world on display as possible for the NES. The known limitations of both NESMaker and the NES in general mean that I have to use the NPCs actions to tell the story as much as their speech bubbles.
1641491258889.png
Which brings us to the above screen shot - a very basic level in the game featuring one of the more functionally complex characters - the Homunculi. These small creatures - taking up only a 2by2 tile - are the work horses of the universe and there for are all over the game. The biggest thing is that when they see the player as a werewolf - they need to run away.

The first test was - unsuccessful. I figured I could easily take the point towards player script and reverse the bits to get them to move away from the player. The test script technically did that - but it first did it by ignoring gravity and sending the Homunculi jumping across the screen before acting more normally. Removing the pointer to the Y value had a limited effect - but in the end I scrapped that test script and came up with something a little different.

The below script is not complete - and doesn't quite do what I am hoping it will do. The Homunculi do move away from the player on proximity - however - instead of a run they shift over a few pixels and reset their actions. The script does seem to otherwise do what I want it do - more digging will be required to fix this issue.


;;; this behavior will wait until there is proximity between the object and the player in the x position,
;;; and then jump to the next behavior when the condition is true.
;;; Currently I am using a random sound (sfx_slash) to debug and make sure that the code is active.
;;; Future updates will include a longer run for the effected monster_object

TXA
PHA
LDX player1_object
LDA Object_x_hi,x
STA tempA
LDA Object_screen,x
STA tempB

PLA
TAX

LDA tempB
CMP Object_screen,x
BEQ +activateMOVE

JMP +skip

+activateMOVE
;When Proximity - Activate

TXA
STA temp
GetActionStep temp
CMP #$07 ;; we will use action step 7 for hurt.
BNE +notHurt ; not equal - JUMP TO ACTION


; ACTION
+notHurt
;Change direction


TYA
PHA
LDA Object_direction,x
AND #%00000111
CLC
ADC #$04
AND #%00000111
TAY ;; this is the "direction", where
;; 0 = down, counterclockwise, 7=down-left
LDA DirectionTableOrdered,y
ORA FacingTableOrdered,y
STA Object_direction,x
PLA
TAY



; CODE STOLEN WHOLE SALE FROM MOVE TOWARDS PLAYER
; With the switch direction (ABOVE) it seems to give us a small move away from player.
; Further testing required.

TYA
PHA
TXA
PHA
STA tempx

LDA Object_x_hi,x
STA tempA
LDA Object_y_hi,x
STA tempB
LDX player1_object
LDA Object_x_hi,x
STA tempC
LDA Object_y_hi,x
STA tempD

LDX tempx

MoveTowardsPoint tempA, tempC, tempB, tempD
LDA Object_direction,x
AND #%00000111
ORA #%00001000
STA Object_direction,x


;Play sound for DEBUG
PlaySound #sfx_slash

PLA
TAX
PLA
TAY


;END MOVE



; Set next action step


+updateActionStep:
;; jump to next action state.
TXA
STA temp
GetActionStep temp
CLC
ADC #$01
AND #%00000111
STA temp1
ChangeActionStep temp, temp1
;Otherwise - skip action

+skip

KNOWN BUGS AND ISSUES:
* Player transformation only works on first screen after warp
* Text tiles and NPC text not set up correctly yet
* UDLR Movement only activates after a jump
* Script MoveAwayPlayer doesn't function as expected
 

IMBrendan

Member
More digging in the above code yielded no new results - the Homunculi don't function as required at this moment, so I have moved on from programing their AI into something that proved to be a lot more productive.

As stated previosly, the biggest goal of the game is to have the NPC's interact with you differently based on your player1_object sprite. A lot of trial and error later I was able to set up a code that allows you to choose what the NPC on any fresh warp will say to the werewolf and human versions of your player1_object. Once I set up user screen bytes this finally became a simple task to program.

LDA npcTrigger
ORA #%00000001
STA npcTrigger

LDX player1_object
LDA Object_type,x
CMP #15 ; Object_type #00 = Werewolf
; Object_type #15 = Human
BEQ +Human ; is human
JMP +Werewolf
+Human
LDA userScreenByte2
TAX
LDA screenText,x
STA npc_text
LDA userScreenByte2
INC $01
STA userScreenByte2

JMP +NPCTEXTTEST
+Werewolf
LDA userScreenByte3
STA npc_text
JMP +NPCTEXTTEST


DrawBox #BOX_1_ORIGIN_X, #BOX_1_ORIGIN_Y, #BOX_1_WIDTH , #BOX_1_HEIGHT, #TEXT_NPC, npc_text


DEV NOTES - JAN 06

*Added fall mechanic to one way platform.
- Press down to fall
*Added warp tile based on userScreenByte
- NOTE: Must be set on warp in screen - IE may not be effective for
a scrolling metroidviania style game.
* Implemented limited text based reactions for NPCs based on player1_object
type (Either #00 or #15) using userScreenByte03 to control independent
reactions to werewolf.
- NOTE: Pending bug fix for player1_object disappearing on transformation
(SEE KNOWN BUGS)
Pending more robust script.
* Considered implementation of day/night cycle.
- NOTE: This consideration allows for more monster configurations among
many other things, however it may have wider gameplay
implementation implications that will change the course of
development slightly. Careful consideration required before time
and resource expenditure.

* KNOWN BUGS:
- Player movement only active after Jump action
- Player doesn't animate on movement
- No states for animation set.
- MoveFromPlayer script fundamentally broken
- Currently, the action activates on proximity (DISTANCE UNKNOWN)
and moves the object a few pixels. This movement seems to be
exclusively to the right currently. Debugging sound plays as
intended.

-Currently patched out for redevelopment at later date.
- Player only transforms on first screen after warp
- NPC dialauge does not advance per code expectations.
 

IMBrendan

Member
DEV NOTES - JAN 8

* Relabled project lables for ease of use.
* Fixed player movement bug
- UNKNOWN CAUSE
* Fixed player transformation bug
- Set variables for current scren to warp into.
* Coded unique triggerabled interations with texttiles
- Further exploration required for full functionality.

* KNOWN BUGS:
- Player doesn't animate on movement
- No states for animation set.
- MoveFromPlayer script fundamentally broken
- Currently, the action activates on proximity (DISTANCE UNKNOWN)
and moves the object a few pixels. This movement seems to be
exclusively to the right currently. Debugging sound plays as
intended.
- NPC dialauge does not advance per code expectations.
 

IMBrendan

Member
Hey All,
For those of you who are in the discord - most of this update will not be new.

For starters - I had bumped into an issue with test build 2, in which I had filled my static bank and was no longer able to add new scripts with out removing old ones. This issue has A) not been solved and B) will crop up again - however it is currently being ignored as I stumbled into something of interest that distracted me. While digging in the source for completely redundant code - something I am not truly qualified to do - I once again looked at the init.ini file that gets complied with each new rom file.

This code has been something of an enigma to me for a while - but in learning SOME assembly language and some of the underlying principals of the NESMaker IDE, I noticed something that seemed to point towards the ability to open up Relics and Songs. I ranted and raved in the Discord - "is there any functional difference between calling BOSSES_DEFEATED and SONGS_LEARNED at initialization, if you change the code appropriately?"

A few hours later - I had tested the idea. Changing the call in code to SONGS_LEARNED and ticking the matching tick boxes under Initialization unlocked the appropriate ability. This would have kicked off a days or weeks long wild goose chase - as I have previously mentioned I am barely qualified to read code. However - a miracle happened - the VERY SAME DAY TurtleRescueNES posted in the forms the holy grail. WORKING RELICS AND SONGS.

In order to test new features opened up by TutrleRescueNES in this post about opening up Relics and Songs we have since moved onto test build 3. All issues with implementing the solution in the attached post have been noted in the follow up posts (Direct further questions about implementation there). The development of Test Build 3 has brought with it some changes. For starters - myself and my writing partner have had a few brainstorming meetings and talks about limitations to NES games that may effect our ability to tell the murder mystery story we have planned. Opening up both songs and relics - while increasing the potential complexity of the project overall - also gives us some options on a gameplay level on how to progress the game along side the story.

While the story is not set in stone - in point of fact its barely existent beyond the idea that there is a mystery - there are some things that we know to be true for the game and the world. We are writing a story with a female protagonist. There is a transformation mechanic in the game. The game will be bookended by an intro and outro that allows the player choice and agency in the game while ensuring that it fits into established lore and potential future stories with in this world.

Finally - making choices on graphics optimization.

With the hopes of creating more dynamic environments - I have made certain changes to the environment meta tiles from test build 1 and 2. Originally I had considered using Double main for all city related sections of the game. By moving required or generally used tiles to a single main sheet - and then using screen tiles (NO PATH) allows for more dynamic screens in a way I hadn't considered before.

DEV NOTES - JAN 25

* REBUILDING FROM FRESH INSTALL - IMPLIMENTING BUG FIXES AS PER PREVIOUS POSTS.
* RESEARCH AND IMPLIMENT BANK SWITCHING FOR INPUT CONTROLS
* CONTINUED STORY AND ENVIRONMENT DEVELOPMENT
* NEW: MUSIC COMPOSITION OUTSOURCED TO FRIEND SEAN.
 
Top Bottom