Hey, I'm looking for help with a wall climbing code, e.g. If you've watched the anime Naruto, as soon as they focus chakra to their feet the characters can run up walls, so I need the mob to be able to run up dense turfs after activating the i.e. "Focus Chakra to Feet" Verb. But as soon as the mob starts running up the vertical surface Id also like their animation to change to the wall climbing state.
Sorry if its a little hard to understand, I'm new to programming xD.
#1 Feb 13 2012, 1:21 pm
|
|
Have a look at Enter() and icon_state in the reference.
| |
#2 Feb 20 2012, 10:07 pm
|
|
i could help you with this if you want, if you haven't already figured it out.
| |
#3 Dec 16 2012, 5:40 am
|
|
Sorry that I didnt reply a while back, havent been on here for a while as a result of studies and university stuff =S
| |
#4 Dec 17 2012, 4:26 pm (Edited on Dec 18 2012, 10:25 pm)
|
|||||
Take this all with a grain of salt, its not the best way to do any of this. It's a basic demonstration of how it could work. I gave you a simple solution instead of giving you a long answer because we're all not very sure how important the climbing mechanic is going to be in your game. Also, since you specified you wanted it to work "via a verb" and you're new to programming, you probably don't need or even want a climbing system that is too hard for you to understand at your current level. Ideally, you'd want to define what can and can't be climbed either via type path (ie: /turf/climbable/wall_a) or via property value (ie: turf/var/climbable). Next, you need a system that keeps track of player "focus", and how focus is "shifted". You could do this with a list (if player can have multiple focuses), a variable (player can only focus on one thing at a time), or with a proc that can be overridden (ie: mob.CanFocus(focus)). Here's an example of the latter:
From there, you can implement ways for atoms to get the status of a mob's focus...
Next, you need an animation / icon_state changing system that will keep track of when icon_states are allowed to occur. You could just "inline check" them, but that will make code really hard to manage in future. An inline check would be like:
You can avoid this by having an icon_state manager of some sort... At any rate, this reply is getting long, and you're probably realizing the scope of your question is quite vague and the answer could be anywhere from a simple 5 - 10 lines of code all the way to 4 - 5 game mechanic cores that would be robust to handle the growth of your game's code. I'm mostly just defending my post because a comment was made about how the code is "probably one of the worst ways you can make a climbing code". Unfortunately, the answer isn't short unless you want a really bad method. | |||||
#5 Dec 18 2012, 1:54 pm
|
|
You probably want to put a "climbing" area over every thing you deem climbable instead of making those checks and changing your icon state twice after every time you move, and have another variable set to check whether or not you're climbing. That code above is probably one of the worst ways you can make a climbing code.
| |
Galactic Soldier wrote:
You probably want to put a "climbing" area over every thing you deem climbable instead of making those checks and changing your icon state twice after every time you move, and have another variable set to check whether or not you're climbing. That code above is probably one of the worst ways you can make a climbing code. Yeah, because its usually pretty impossible to help these people do something proper because of how many places you'd need to inject code to make it work properly. Then again, maybe that's why the byond community has a lot of bad programmers... they learn on the forum, and forum people give them quick 10 - 20 line solutions for everything rather than a proper implementation. | |