LÖVE

Not necessarily. I can't repeatedly tap a direction and have it work. Which is what you need to aim for. Also, use the arrow keys too on top of the WSAD. I hate WSAD. As people here already know.

But, arrow keys open the door!

The use of arrow keys as directional activation is due to lack of orientation.
Should I use Goo for menus?

Jasoco wrote:Man. That's so slow. Why is it so slow? It's a smaller grid then what my own game creates. It takes a few seconds to load the array. (Mine loads in less than a quarter second.) How big is this grid? It looks small. Much smaller than what I create but takes longer? And it's taking too long for each frame. I'm getting 15FPS. What exactly is it doing each frame? The code is so confusing and spread out it's impossible to figure out.

Ok, the engine is slow and have some strange start slowdown that yet I didn't figure out since my Lua/Love,array/table or pseudo-classe knowledge is yet awful. But sorry to say this Jasoco, you are being a bit unfair about telling the code is confuse and spread out etc etc. I'm a code noob and even without comments or good variable naming I understood generally things and noticed that the code was well organized and splitted like all you serious coders do (like you saw in my roguelike project I'm too casual and sloppy to let all in same lua main file so I'm not a serious/organized coder). Matter of fact his organization seems just like any other C++ rogue project. However I'm not too good in Lua (or coding in general) to understand things right. Yes I'm a noob on this, but let me try to help.

So let's try with the help of all the community find the flaw the best we can, right? This project/engine seems interesting enough to deserve some attention.

What I find bizarre is that ingame updates are quick enough but in start we have a huge slowdown. Problem don't seem to be in games updates like love.update(dt) right or in the draw routine. As it seem we can speed up things by altering the value in nm = os.clock() + .2 . If we alter to 0 game turns realtime and loses the turn-style roguelike way. Seems fast enough comparing with the start right?

So, in that way my initial guess seems to be in some vague map limitation/declaration on initial world creation or in the calculation light method. Also could be some flaw in the entities first declaration?

Also I notice a problem after seeing that player don't mess with light (it should affect/block light when close the source area but it don't). So ZenX2 do you forgot to declare player as a solid that counts for light calculation or you did and you have a real problem in lights updates?

I agree with everybody that WASD isn't a good choice. Try assign instead the classic arrow movement. You can try do interaction by movement + another key like shift. Or like old roguelikes do the classic "open"/"shoot"/whatever in two steps by selecting after the direction wanted.

Also you really better check as I said Bartoleo's calc routines for perhaps some hints to speed up things. It don't have light calculations there but have LOS and FOV routines that can help you. Even with a more elaborate pseudo-map with wall/player/mob configuration things seems to work fast enough at start.

Sorry I can't help much more since the way I declare maps in my roguelike engine is a classic one with map spaces declared in a table. You in another way do a smart on-the-fly entity declaration and for sure the problem is I guess there. :/

Should I use Goo for menus?

Wow, go easy, try to fix first the basic implemented features. Think that later

I use an extremely useful and powerful class library, for nearly everything. It removes the need to think about metatables and constructors.

As to the matter of slow startup: this is entirely due to calculating lights, which are in all actuality just for visual effect.

The nm variable controls the time the next tick, the basic unit of time in the engine. If you add a :Tick() method to an entity, you can hook into this. (same with :Use().)

Light is only calculated at the start. It uses a reeeeeeeeeeeeeeeeeeally slow flood fill to find every pixel inside the radius of the light. This is something I need to fix.

For movement/keys, you can change it easily. I'll add multi-key support for keypressed binds.

I'll work on the startup speed and try to get fast, constant light calculation.

EDIT: I dumped the circle and flood fill stuff and just iterated through every pixel. Starts up in less than a second.
Also, is there a way to find the name and path of every file in a directory with LOVE? I want to clean up the main.lua.

GridCraft!

No, it's just a level with doors everywhere. (only a bit slower than normal, too!) EDIT: Chillin' on my sofa.

The tick movement feels off. If i press immediately after a tick, I have to wait for the next one to move. It needs to move right when i hit a key, and then start ticking.
It can actually be pretty easily implemented with love.keyboard.setKeyRepeat.

Thanks, I'll see about adding that and different tick speeds for different entities.
Problem: This piece of code for the menu system I'm making (an extension to the side of the screen, keyboard control for ease of programming ) drops my FPS from 40 to 4. EDIT: In game level loading works, but the menu system is still incredibly laggy despite how non-graphics intensive it is..

Well yes, you create 2 fonts every frame using that code... I quote from the wiki:

This variant creates a new font using the default font and the size specified, and sets it as the current font. Do not use this function in love.update or love.draw. That would create a new font every frame, eating up memory very quickly.

That's about setFont(size), so yeah...

I guess that's what I get for not reading carefully.
EDIT: Menus! And more keys to memorize!

TFGH are the menu control keys. And there's still IJKL when you're ready for more!