Witch City

dale_coop said:

Oh nice result, yeah <3
How did you do that?
his arm is not the "weapon player"?

Click to expand...

It is a player weapon, but I found that simply removing the DeactivateCurrentObject that normally removes a player weapon when it hits a monster will result in an infinite loop that will freeze the game. The problem is that when the object doesn't get activated, it ends up getting checked for collision again, then again, and then forever. I tried many ideas for dealing with this, but a most of them failed because I didn't complete understand everything that was happening yet. What I ended up doing is instead of deactivating the object, I turned off the flag that marks the object as a player weapon. I found out that the data that says what flags should be applied to which type of object is protected in a look up table under ObjectFlags,(Object_type). When the object gets created, the that value gets copied over to Object_flags,(object's reference). So in other words, I can turn off the flag in Object_flags for the current instance of the arm object, then the arm object will die on its own, then when a new arm is created it will get the propper flag settings from ObjectFlags. That first arm will never hit again, but it doesn't live long enough to get the chance anyway. I hope that all made sense. My brain is now mush.

EDIT: Oh, one thing I forgot to mention. The object collision routine uses ObjectFlags for some reason to check the collision, so I had to changed that to Object_flags.

Very nice trick! And I didn't know there was "ObjectFlags" AND "Object_flags"!? Thanks for the lesson... I will take a better look at that.

You're welcome!

I'll write up something more coherent for the Tips and Tricks section when my brain has had time to heal. I wasn't sure if it was too specific to my game or not, but I think after writing what I did to answer your question, I think I could generally apply to other games as well. Particularly for melee attacks. It would need tweaking if you wanted projectiles that could go through multiple enemies.

Yeah, you right, it should have been the normal behavior for the melee attack!

Question for you, since your character has the same dimensions as mine:

When you duck, are you able to roll over to the right and down a crouch slide across the screen? This is a bug I'm encountering on my game, wondering if you've done anything to solve for it yet? I have ideas, but they seem convoluted if there's a simpler "Input script" answer. (Setting up a variable for Duck, and don't let Right/Left to work if Duck is set to 1, sort of solution)

Convoy_Avenger said:

Question for you, since your character has the same dimensions as mine:

When you duck, are you able to roll over to the right and down a crouch slide across the screen? This is a bug I'm encountering on my game, wondering if you've done anything to solve for it yet? I have ideas, but they seem convoluted if there's a simpler "Input script" answer. (Setting up a variable for Duck, and don't let Right/Left to work if Duck is set to 1, sort of solution)

Click to expand...

I have it so that the player changes to the walking state when you are pressing down and a lateral direction. I could just as easily go the other way, but I can't know which is best for my game right now till I have more mechanics implemented. I'm not sure if I can give you the answer your looking for because I'm going pretty off script with how I am handing crouching in NESmaker. I do have a variable for crouching (or rather I made a variable to hold extra flags and on bit of that is for crouching), but creating that had less to do with solving this issue and more to do with other aspects of how I am accomplishing crouching. That said, I do use that bit to solve this issue for me in the ChangeToWalkingAnimation script by checking if that crouching bit is on and if so, do the appropriate commands to get the player the way it needs to be. Also maybe relevant, I have crouching achieved by an on Pressed script for crouching down, and an on Release script for standing up. For the Crouching script, I check to see the player's state, and if the player is in the running (or jumping state, too), then the routine skips the crouching code. Is that helpful?

Just a minor update. I'm feeling pretty confident that I'll have a demo out within the week. Hoping to get something out before 4.1.0 releases. Just a bunch on minor stuff to do (and enemy AI, I've been putting that off). Anyway, while taking a deep dive into the code, I stumbled across where the damage flicker is handled and decided to change it to be a palette swap instead of a flicker on and off. Also I made some boomerangs.

Absolutely fantastic! Those boomerangs are a great new feature!

By the way, I'm curious how your Object Parenting system works, I've never figured out how to set one up.

CutterCross said:

Absolutely fantastic! Those boomerangs are a great new feature!

By the way, I'm curious how your Object Parenting system works, I've never figured out how to set one up.

Click to expand...

Thanks!

Basically what I did was added a variable to the objectBytesRAM file to hold the "reference" (not technical a reference) to the parent. I then modified the CreateObject macro to take in a fifth parameter to define the parent. NESmaker is set up to only have up to 12 objects on screen at a time so object references only go from 0 to B. That means that if I store that value in a byte, then values from 0C to FF will have no meaning. With that in mind, I encoded FF to be the value for no parent. I had to go through the code for each instance of CreateObject to add in a fifth parameter with a value of #$FF for things to continue to run normally. Finally, when the object updates happen (or maybe it was when the physics happen), if that parent value is set to FF, then updates happen as they normally do. Otherwise, it does an alternate update where the position of the object is set to the position of the parent plus an offset.

Because the child in not in control of its own physics, that means that the speed variables and the lo position variables are now irrelevant, so I use a pair of those to store the offset data. I also created a macro for setting that offset. Someday I might have to rethink this because i want to add an alternate parenting mode to that may make use of the speed and lo position variables to move the child relative to the parent. I would love to get a child to orbit a parent, but I think that would involve having to make a sin look up table, and that's not a priority at the moment.

Hope that made sense, I plan to make a full tutorial if and when I adapted it to 4.1.0. I don't want to do it now because it touches many different spots in the code, so I suspect that it'll break with the upcoming update.

Looks great, I love the boomerang. Would really like to know how that woeks.

Pauldalyjr said:

Looks great, I love the boomerang. Would really like to know how that woeks.

Click to expand...

Thanks. Like with the parenting, I don't want to consider putting a full tutorial until after 4.1.0, but even then this one is a pretty deep dive into the code, so I don't know right now. That said, I'm ok with explaining how it works in general for now.

I had to write an alternate physics branch for that object. I checked ignore main physics, but at that part of the physics code, I put in a check to see if it a boomerang type object and then proceed with my boomerang code if it is. I added an extra timer to the game objects and set it when the boomerang is created. When the timer is counting down, that means it's moving away from the player and will not update its y position. When the timer ends, that means it's time for the boomerang to return and it will switch its horizontal speed and continually update it vertical speed to try to keep up with the player unless its y position is within a window near the center of the player.

Additionally, I'm not making it a secret that I am very much influenced by Sunsoft's Batman with my game and there was a glitch with the Batarangs that I want to try to make into a mechanic:

In that game when you are moving left at full speed, a Batarang that is returning to Batman will pass through him and basically start its cycle over again. To mimic this, when my boomerangs collide with the player, if the player is not moving left or right, the boomerang will get destroyed. If the player is moving left or right, then the timer will get reset and the boomerang will move past the player to repeat the cycle. I'm not 100% if I will keep this. My main concern is that players might think the boomerangs are just being buggy even though that is the behavior I am going for. We'll see what happens when I get some combat situation going. Enemy behavior is being a pain right now.

I guess while I'm here, I might as well make this a small update on the happenings and whatnot. Have a GIF:


So yeah, one of the things that I am noticing is that the boss isn't very menacing if it freezes up when it gets hit, but that is the behavior I want with regular enemies. As far as I can tell, the Hurt Reactions in NESmaker are not hooked up yet, so that means I need to figure out a way to identify whether a monster is a boss or not and then have it react when hurt accordingly. I also want to refine the boss' movements so that they aren't so haphazard.

Nice batarangs! ... I mean... Very nice boomerangs! I like them like that, too.
It would be useful, if there were more flags on monster objects to have more objects types (isMonsterType1, isMonsterTypeN, isBoss, isSpecificBehaviourTypeOfObject, ...)

Love this topic. Thank you, jorotroid, keep sharing your updates

dale_coop said:

Nice batarangs! ... I mean... Very nice boomerangs! I like them like that, too.
It would be useful, if there were more flags on monster objects to have more objects types (isMonsterType1, isMonsterTypeN, isBoss, isSpecificBehaviourTypeOfObject, ...)

Love this topic. Thank you, jorotroid, keep sharing your updates

Click to expand...

Thanks again, coop!

It's pretty easy to just add an additional variable to an object to hold additional flags, but the challenge is figuring out a way to set those flags through the NESmaker tool, but I do have some ideas. The experience and jump settings in a object's settings are currently unused (technically also the strength and defense, but I have plans for those). For me, I won't need need experience because I don't plan to have points, an experience system, or even currency in my game. And the jump slider could be useful for enemies that jump, but for enemies that don't jump, that value could be interpreted for something else. Or a range of values could be encoded to mean jump values, and other ranges could mean something else.

The problem is accessing those values. I can't for the life of me figure out where that Jump slider's value gets piped into the code if it does at all. As for the experience field. That goes to a lut called ObjectWorth, but like other object luts it's on a different bank, so you would have to bank switch to access it. If you make an additional object variable like I said before, then you could initialize it when the object get activated with the value from the lut.

This is all in my head at the moment, so I haven't tried anything yet. I probably won't need to do it in this case because I pretty sure I have a regular Object flag still available, but I have a feeling I will have to try it sooner or later.

Dang, I missed Halloween, but I didn't want to show off things until I felt they were ready to be shown. I still don't feel it's quite ready for a playable demo, but it's getting there. For now I put together this video that conveniently avoids some (not all) of the game's rougher edges. I hope you all like it

https://youtu.be/oAKAKRFKhPc

Also here are some features that I have been working on:

• Wall Jumping! This does some collision checks in front of the player and if there is a solid there, you get to wall jump!
• Collectible permanent power-ups. I really went about this in a crazy way. Rather than making a different Game Object for each power up, I just have one permanent power-up object and it uses the screen type to determine which power-up it should be, then uses the predraw to display which item it should look like.
• Quick Dashes. I wasn't completely sure if I was going to get this one in, but it made it! It sore of works like rolling in Smash Bros. While holding B, you can press to the side to do a discrete dash.
• Demon Claw Boss AI. This has been a bit of a pain. To get the behavior I wanted, I eventually decided to stop trying to work with the built in action step systems and instead do some hard coding based on which Object_type this is.
• Smaller Power Ups (Health and Magic refills). Again, why have multiple game objects when one can do the job. When one of these is created, I make it face a different direction to change which graphic/type it should be. Still have some bugs to work out, but it's coming along.

Oh wow, that are really awesome additions! Great job! I love it!

Definitely love the Wall Jumping.
You should really make a small tutorial about that great feature!

That wall jump looks really tight!

That wall-jump is one of the coolest things I've seen yet!

I wanted to have a wall-jumping mechanic in The Tower of Turmoil, but besides the fact that I don't know how to code something like that, I ran out of Action States for my player! So I couldn't put it in anyway without sacrificing something!

Thanks everyone! I am humbled by you support for this thing that I am making.

My plan now is to take a bit of a break to focus on making some tutorial content on what I have learned so far (wall-jumps will definitely be part of that). I'll probably still work on Witch City during this break. I'll just be in a little less of a rush as I feel I have been. That said, I sent my rom to Joe to use at RetroGameCon, and if all goes well with that, I will probably share that rom here.

jorotroid said:

Thanks everyone! I am humbled by you support for this thing that I am making.

My plan now is to take a bit of a break to focus on making some tutorial content on what I have learned so far (wall-jumps will definitely be part of that). I'll probably still work on Witch City during this break. I'll just be in a little less of a rush as I feel I have been. That said, I sent my rom to Joe to use at RetroGameCon, and if all goes well with that, I will probably share that rom here.

Click to expand...

<3 Can't wait to try your rom, jorotroid!
Thank you for sharing your awesome WIP, I think your ideas and your tutorials will help a lot of nesmakers in their (our) future projects.