I'd just check all mobs in obounds() and figure out which one is closest and most directly in front of the player. Letting the players target NPCs would be the most precise, that way they can press tab and be sure of who/what they're targeting.
If switch is faster, why are you using if else in front()?
The difference is insignificant. Typically, a large portion of a program's CPU time is spent in just a few functions (those functions are called the bottlenecks). front() isn't that function. You'd have to call front() tens of thousands of times per second to increase the program's CPU usage by 1%. If you caused front() to be called thousands more times, you'd also be causing the bottlenecks to be called more often and their increased CPU time would overshadow whatever difference front() makes.
Also, switch can only improve performance when you have many conditions. With only one or two conditions, a switch statement can't be faster than an if or if/else. With four conditions, there won't be much of a difference. For this code it doesn't really matter, but if/else if/else statements are usually more readable.
If switch is faster, why are you using if else in front()?
The difference is insignificant. Typically, a large portion of a program's CPU time is spent in just a few functions (those functions are called the bottlenecks). front() isn't that function. You'd have to call front() tens of thousands of times per second to increase the program's CPU usage by 1%. If you caused front() to be called thousands more times, you'd also be causing the bottlenecks to be called more often and their increased CPU time would overshadow whatever difference front() makes.
Also, switch can only improve performance when you have many conditions. With only one or two conditions, a switch statement can't be faster than an if or if/else. With four conditions, there won't be much of a difference. For this code it doesn't really matter, but if/else if/else statements are usually more readable.
I prefer Spacebar to not open the inventory if no other interactions occur. Accidentally being positioned wrongly when attempting to talk to an NPC or something similar will end up opening my inventory and unequipping my sword or something.
Edit -
It's an extremely simple tweak that requires a few lines commented out in player-interaction.dm.
Also, there doesn't appear to be an option to clear an ability slot. Or drop/sell items... There seems to be a number of things left out, so I'm not sure whether to bother adding them myself or wait for a future version. Or maybe I'm just expecting F_a to do everything. Hmm...
I prefer Spacebar to not open the inventory if no other interactions occur. Accidentally being positioned wrongly when attempting to talk to an NPC or something similar will end up opening my inventory and unequipping my sword or something.
I like having the option of using the space bar to open your inventory. I could put that stuff in its own proc so you can override it to change the behavior. Also, increasing the interaction range and slowing the npc's movement could help.
As for the things that are missing, I'll probably add those things eventually. I'm trying to focus on the framework so hopefully the missing features are things that would belong in the demo.
Also, there doesn't appear to be an option to clear an ability slot. Or drop/sell items... There seems to be a number of things left out, so I'm not sure whether to bother adding them myself or wait for a future version. Or maybe I'm just expecting F_a to do everything. Hmm...
To elaborate on this... (since I was posting from my phone earlier)
Clearing abilities is something the framework should provide.
Selling items is something it should provide but I'm not sure about dropping items. There are different things you may want to happen when a player drops an item. You might want it to be destroyed or you might want it to appear on the ground for other players to be able to pick up.
Inventory key_down(k) ..()
if(k == "d") var/item/item = current_item()
if(item) owner.drop_item(item)
I suppose I could add this to the framework, then leave it to the player to define what happens in owner.drop_item - currently it deletes the item but you can override it to change that. Maybe you want it to spawn an /obj/chest at the player's location and move the item to the chest, then make the chest's interact proc show a loot window so you can pick up the item.
There aren't many things I've deliberately left out - there's just a lot to add and I knew this library would be far from complete no matter when I posted it, so I figured it's best to post it early. If there's something else you think is missing it's probably because I haven't thought to add it or haven't had the time. Either way, be sure to let me know... or just add it yourself! =)
when the Action RPG Framework library is enabled and the above code is added to a .dm file within the demo game, when the "g" key is pressed nothing happens.
when the library is disabled, the above code works great. somewhere within the library is a code that is interfering with the above code. can someone verify this.
You need the latest version of the pixel movement library. If you don't have the PM library at all, BYOND will automatically download it when you download the framework. But, for some reason, if you have an old version of the PM library it won't automatically download the latest one.
when the Action RPG Framework library is enabled and the above code is added to a .dm file within the demo game, when the "g" key is pressed nothing happens.
when the library is disabled, the above code works great. somewhere within the library is a code that is interfering with the above code. can someone verify this.
The Keyboard library calls the key_down proc of whatever object has focus (as determined by the client.focus var). The Pixel Movement library and this framework both expect the focus to be your mob. If you override mob/key_down, that code will work (assuming you don't have any on-screen menus open).
It would be nice to have an included character creation system. Preferably something that could be included exclusively into any project that uses the pixel movement library(keyboard is required because of the input bar, and pixel movement is required because of freezing the player but the latter of those isnt really as necessary). I'd like something like a procedure that freezes the player and brings up a window asking for name input and a couple different options for a class which the player can click on with descriptions for the selected class. A finalize button would allow the player to close the window and then have the selected name and class.
It would be nice to have an included character creation system. Preferably something that could be included exclusively into any project that uses the pixel movement library(keyboard is required because of the input bar, and pixel movement is required because of freezing the player but the latter of those isnt really as necessary). I'd like something like a procedure that freezes the player and brings up a window asking for name input and a couple different options for a class which the player can click on with descriptions for the selected class. A finalize button would allow the player to close the window and then have the selected name and class.
You should be able to put the character creation stuff in the mob.new_character() proc. I'm not sure how much I can provide. The properties of the character are determined by the game, so the character creation form has to be part of the game too.
Most people would want a big fancy form, but if you're fine with something simple you can do this:
mob new_character() class = prompt("What class would you like to be?", "Warrior", "Ranger", "Mage")
I can add procs for different types of prompts. I was thinking about making a generic on-screen menu that looks like the game menu, game options page, or character selection menu. That way I can provide a sample character creation process without going out of my way to make some huge form and still get generic input prompts that can be used for other things.
I'll try to get an on-screen text input prompt in the next version. For now, I've just been using the client's key in the chat log so you don't even see mob names and don't need text input =)
front(d, w = 0)if(dir == NORTH)
return top(d, w)
else if(dir == SOUTH)
return bottom(d, w)
else if(dir == EAST)
return right(d, w)
else
return left(d, w)