Search

[Quoise Games]

I should be able to do all of those things on the list EXCEPT, I can't promise the cooridor lock randomization.  I don't know how optomon did it, and the locking process would have to be worth the randomization. For example, although how you open the corridor may be different, if the overall locking mechanics are the same, all the user has to do is guess which technique opens a particular door, and try each one until they are right.  I'm more in favor of coming up with new ways to lock doors, and I welcome suggestions.

Also there will be quite a few of other things randomized in the next release. These changes will prompt you to pay more attention during the entirety of the game, and some randomizations will be more asthetic....

You'll have to wait until the next build to see what they are (sometime late Nov early Dec)

[Mattrick_]

Interesting... now are you actually decompiling the game using assembly to find the data for your randomizer??
I am curious as to how it works.

[Quoise Games]

I'm using FCEUX to observe RAM data, looking for changing values that match what I'm expecting to happen.  For example, I look at any RAM values that may be counting down to zero. WHen it reaches zero, if it triggers the event I'm observing, I then move on to the Debugger.

The Debugger is like a decompiled version of the game's code. It shows the code in assembly. All of this is done within FCEUX while the game is loaded, so I don't have to export or create decompiled files. I'd look to see what assembly instruction is responsible for reading and writing that RAM value. Once I find that instruction, I then go to the ROM file


Once at the ROM file, I just change the target value to something different.  If it changes and takes effect (in this case, if the timer is longer/shorter) then I found the right ROM address. I make a note of it, and will add it to the list of things to randomize. 

Finally, I open up my script, add a random range to that value (new value = origional value + randomNumber), when the user saves it to the rom, the game has a different value for that particular variable.   

For this particular game, this process is not that difficult because how the game data is stored in the rom.  Most of the data, like maps, enemy information, weapon information, scoring, etc is set up in a table format.  This means, all of the information for a particular category is grouped together in one area in the rom.  The only tricky part about this game, as well as other nes games, is the graphic data.  Unless the sprite information has been loaded for a particular object, it won't show up.  This means that only certain enemy types will appear together, because their sprite table is lumped together.

[Mattrick_]

Interesting, so then how would you randomize bosses? do you just see what value gets pulled when the boss spawns, and modify that value within a range? and then once that value has been met, it removes it from happening in multiple instances? or is it possible that multiple bosses of the same type will show up when randomized?

[Quoise Games]

Yeah, bosses have their own id number like any other enemy. I've found out the id number of each cooridor boss, and I can shuffle them (not randomize them) to make sure that each boss appears only once. The challenge is making sure that the graphical data is also added to the corridor loading process when necessary as well as the graphic data of what the boss shoots out. This info would have to be loaded at the end of each corridor, while keeping the corridor's data intact.  In a rom file, you can't add extra space, so you have to be mindful of what and how you overrite existing data.

[Mattrick_]

so stupid question, if you were say, move a grimgrin to a non organic corridor, and also move the eyes, would eyes just then overwrite a different enemy sprite, thereby causing eyes in appear in place of something that would normally show up.

Example, corridor 6 volcanos shooting eyes instead of shooting crystals?

[Quoise Games]

That would happen, if I copied the eye sprite information and pasted it over the volcanic crystal information. But that is now how I would reassign sprites anyway. I'll be reassigning the table header (also known as a pointer). This pointer is a number that points to where the sprite data is located. At the beginning of each corridor, there is a pointer that says which spirte information to load. For water worlds, this sprite info is the fish, startfish, seahorses, shrimp, etc.  So I would be changing pointers around in order to pull off changing spirtes around. The actual sprite data is too large and mixed up together in the ROM to move around. Even if I did copy one spirte data over another, the enemies behavior would still be in its origonal form--the volcano crystals would still behave the same, even though they look like eyeballs. Not to mention that the animation sequence and the dimensions would be off, causing it to look glitchy and distorted

Normally, the boss graphical pointers are set at the end of the corridor information. I'd just need to overwrite a command or two and change it to a graphical pointer that corresponds to the enemy projectiles. The command that I will be overwriting will probably be an enemy generation command (so the last bit of enemies may not get generated in some cases)

[Quoise Games]

Just finished the research phase.  So in a couple of months, there will be really diverse worlds to explore. I can guarantee that each world will be completeable, but whether or not you complete it will be up to you. You will have to rely on new strategies every time throughout each session. The cheats and strategies you all are so familiar with will be of no use in this next iteration.  So get your practice in now. Once I'm done scripting this and release the demo (and once the bugs are cleaned out) there will be no turning back.

[arseniy]

Just finished the research phase.  So in a couple of months, there will be really diverse worlds to explore. I can guarantee that each world will be completeable, but whether or not you complete it will be up to you. You will have to rely on new strategies every time throughout each session. The cheats and strategies you all are so familiar with will be of no use in this next iteration.  So get your practice in now. Once I'm done scripting this and release the demo (and once the bugs are cleaned out) there will be no turning back.

It's like you going to fix those things like slashing the boss inside it?

[Mattrick_]

i dont believe that can be changed..... HOWEVER, if he were to randomize the skills so that say, a multibullet were changes to have the effects of the saber, i.e. it does damage per frame, and the saber becomes an on use ability with a short window (totally useless mind you). that would be a way to force the player to relearn the game and how to deal with things.

In fact i would think that would be amazing, but wow would it be a change in gameplay

[Mattrick_]

soemthing just came to mind....

Can you randomize the keys that come from bosses in corridors?

[Quoise Games]

without giving too much away, I'll say: yes.

[Mattrick_]

Something was brought up during our big 6 man race today.
Is it possible to give each area a unique color on the map?
Not everyone is a speedrunner who can crush a randomizer seed in less than 2 hours, and people are asking if its a possibility to identify each area with a unique color for ease of identification.

[Blob2779]

Another option mentioned in the race was if you could somehow make the map identify rooms you have been in vs rooms you haven't... but that'd be an interesting bit of assembly modification. 

[arseniy]

Another option mentioned in the race was if you could somehow make the map identify rooms you have been in vs rooms you haven't... but that'd be an interesting bit of assembly modification.

Sounds like hard hack and programming. Of course that'd be awesome. Have you seen the LUA script the guy made for the map be shown this way? Link in my sig. Unfortunatelly he stopped to develope it and recent updates are not as good as some build there was before.