Grid Engine

[arquivista]

It's nice that things got speed up. However, yeah, still impraticable so you can't yet use realtime lightning, you still need to rework this. :/

Don't know the way your game/engine will turn out but I still have some doubts the way you declare and keep basic map. For objects and other stuff it's ok but if you need to do complex maps you probably will need a more conventional/plain way of keep data for map. Imagine how confuse and vast it will be declare in level map savefile a complex map. When you add terrains will be even complex for irregular areas.

Nice to see the screens with upgrades but unfortunly you didn't upload the 0.40 version.

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

I don't think the wich keys are a issue, but have a full set of dedicated oriented keys to interact is probably awkward (and it will even stranger if you add later also NW,NE, SW, SE interaction/movement).

Keep the good work, all seem promising!

[ZenX2]

I don't understand what's bad about the entity storage, but saving should be as simple as serializing the ents table, and putting it in a text file. To load, just unserialize and make that the ents table. Everything would essentially be identical to how it was when you saved.

And I doubt I'll add NE, NW, etc. interaction.

[kikito]

I don't understand what's bad about the entity storage, but saving should be as simple as serializing the ents table, and putting it in a text file. To load, just unserialize and make that the ents table. Everything would essentially be identical to how it was when you saved.

And I doubt I'll add NE, NW, etc. interaction.

For serialization, I believe using direct lua is the easiest approach. I mean, if you normally create an Enemy using a function

Code: Select all

createEnemy(x,y,strength)

, like this:

Code: Select all

createEnemy(100,100,10)

Then the serialized code can be exactly that:

Code: Select all

createEnemy(100,100,10)

You just have to load the file and bam! your enemies are created.

[ZenX2]

That may be true, but if you look at the latest version (When I upload it), all entities are solely stored in the ents table, so setting it to a blank table will deleted every entity, and it is not much of a leap to hypothesis that setting it to a previously saved ents table will bring everything (extra fields and all) back.

EDIT: I've got little messages that pop up at the bottom of the menu, and a timer library. (if you can call it that.)

I'm also working letting maps be larger than the view, for if you need a long map or a very large map.

[Jasoco]

What do you mean "lack of orientation"?

If you want diagonals, you just need to check for both left and up or left and down or right and down or right and up. It's not that hard. WSAD is meant for people who play FPS games and use a mouse in their right hand. The arrow keys are on the keyboard for a reason.

[ZenX2]

Your player is a square, a perfectly symmetrical square. Diagonals are cheaty, because technically, you are moving more than a single tile. As for the WASD topic, why not have a unique control scheme? It makes the game memorable! And If you don't like the controls, why not change them yourself? I don't see it as all that difficult.

Weeeeeeeeell, it's update time again! For the third time today!

[ishkabible]

why is this so slow? is it mapping the lighting every frame and using an table to store the values? another method might be to use a frame buffer with setpoint and enlarge that frame buffer , that would you have fast 3d accelerated pixels that take up less memroy. the lights should only be remapped as there moved or changed. other than that this is super nice, very nice effect for more retro style games. you should add in transparent walls that change the color of light passing though them so that when it hits the ground the color is changed accordingly. dose this render the sene for every light? i read about a method that Oger3D used that got around this somehow, might want to look into it

[ZenX2]

Currently, the light is only generated when a level is loaded, and is purely there to look cool. Sadly, each light drops the FPS by around 15. I'll look into the OGRE3D thing.

[arquivista]

ZenX2, we know that game is yours, we are only here to help and suggest good things and to feedback, but you starting to look to me not very open-minded and a bit "stubborn". If lots of people talks or suggest about something perhaps you should stop and think that probably "I'm not doing it in the right way". Unless the game is not for afterall for public and only for your pleasure of course

And I doubt I'll add NE, NW, etc. interaction.

Your player is a square, a perfectly symmetrical square. Diagonals are cheaty, because technically, you are moving more than a single tile.

Unless your player is some kind of robot that only do 90º rotations, yes, it should face/move/interact in diagonal just like real life. It could be seem cheaty move diagonally with one space but is also a bit absurd that with 2 spaces wide the player will need to zig-zag like a drunken since it can't for some strange reason do diagonals.

In grid map style of game never made much sense walk or interact only in 4 directions. So that's why for example usually all roguelikes use 8 directions.

If you feel that is cheaty "moving more than a single tile" you could try one day a more "honest" hexed map style approach.

As for the WASD topic, why not have a unique control scheme? It makes the game memorable!

Well, I don't know if that comment was irony, if you have true desire of confuse the player or if was only the need of sleep. What I can say is that your game as controls concern start don't seem memorable, friendly or pratical to user till now. Let me see, you done 3 different sets of keys for directional things. One for move, other for interact, and other for menus. Well congratulations, usually roguelikes aren't not very memorable key friendly but they don't seem to like to confuse player or "waste" keys like have 3 diffent sets of keys for navegating when you could help player having only one.

And If you don't like the controls, why not change them yourself? I don't see it as all that difficult.

That response to Jasoco, was sorry, a bit unpolite. He, and all of us only want to help and we don't really need that kind of sacarsm. Yes, we can change ourselves. But it would be nice us starting to fork your game instead of you trying to put it better for all the people? Since we are all polite we prefer to suggest than start to mess with your code, we like common benefit and it's more honest that you deal with changes in your original code.

And it can be more complex than changing keys itself but change the structure of game. I can be wrong but I didn't saw you using a kind of gamestates that would help a lot of redirect without afraid of use same key in keybinding file for different actions/states.

Also can mean change some playability of the game. Let's see for example your interaction method. Instead of use dedicated keys you could use in option use two other better methods: 1- "other key"+"directional key", 2- Two steps "iteraction key" then directional key. That would make more hardcore changes to code and it's fair that you decide or not do it.

And well I had a lot more to talk about the ents, the serealizing and all that stuff related map (NOT other level stuff like enemies, objects etc) but run out of time and I will talk about my concerns and reasons another time maybe if I feel that you somehow is a bit more receptive.

[ZenX2]

Well, you made some great points, and so I have thought it through.
I will conform, and will change the controls to allow both arrow keys and WASD.
In the next version, If you hold down one of four keys (Z, X, C and V) while moving it will change what you do.
If you say, hold V and right, you will use whatever is to your right.
I have been reluctant to do this simply because it makes it difficult to program.
I'm sorry for any rude comments, Americans can be stubborn. Am I right, Jasoco?