LÖVE

bartbes wrote:The overall structure seems to be pretty chaotic.

By specific I mean, can you explain what's chaotic about it? What things are useless? What doesn't make sense about where things are and about the structure? So I can know how to fix it. Or, you have commit access to. You are welcome to make any changes you want. You won't hurt my feelings But I may come back and try to explain why I did things the way I did. Or I'll see it your way. But I need details.

Heh, it appears you have missed my edit.
Anyway, it's more than just file structure, what about this, in main.lua all callbacks are calls to game:<callback>, so if you go look for game you see that you need to go to the states, which then implements the FSM, which then has two children (or so it appears, anyway): map and mapeditor. Not only is this route pretty long and unclear, I can't see this improving performance either.

EDIT: And IIRC the calls aren't tail calls, which would be the best way to do those kind of calls.

bartbes wrote:EDIT: Example: why is the draw function in src/states/mapeditor.lua?

Good question. I implemented the game as a FSM. Doing that makes it very easy to go between single states in the game like loading screen, main screen, world map, city, etc. It's also makes it very easy to separate the logic for these different game states, which I think is its most important quality. So it's not that the game's draw function is in mapeditor.lua, it's that the draw function for the MapEditorState is in mapeditor.lua.

Making prototype1 a FSM is not really necessary, but I figure why change the core game structure for every prototype and the game itself unless we find that that structure doesn't work?

In any case I made it a FSM because I intended to have the regular map in one state and the editor in another (as you'll see if you look in main.lua). I didn't go through with that because it was easier to have them both in the same state (read: took me less time). Just one more thing I fear has been complicated by my adding functionality to the prototype.

I know how states work, but this is an overly complicated and chaotic way of implementing them, this can be done in a much cleaner way.
And you seem to have missed my edit again...

bartbes wrote:Heh, it appears you have missed my edit.
Anyway, it's more than just file structure, what about this, in main.lua all callbacks are calls to game:<callback>, so if you go look for game you see that you need to go to the states, which then implements the FSM, which then has two children (or so it appears, anyway): map and mapeditor. Not only is this route pretty long and unclear, I can't see this improving performance either.

EDIT: And IIRC the calls aren't tail calls, which would be the best way to do those kind of calls.

Yea, I replied before the edit. I agree with you there. I think there's an extra step in there that can be taken out completely without effecting anything and that is the Game class. I just made that change.

After that though, I think everything is necessary (not for this prototype, but for a game with multiple states, yes, for my reasons stated previously about separating logic and ease of changing game/actor state). It's just an fsm and states. Well, state actually, I removed the MapState as well because it wasn't being used.

As for the tail call issue, I only have a cursory understanding of those. After removing Game from the equation, what function calls in the prototype need to be made tail calls?

bartbes wrote:I know how states work, but this is an overly complicated and chaotic way of implementing them, this can be done in a much cleaner way.
And you seem to have missed my edit again...

OK. Then let's remove that stuff from this prototype and explore more FSM options for the future.

Just fmyi though, I'm interested to know how it's complicated and chaotic?

willurd wrote:On the topic of closing out prototype1, I only added all that editing/zooming stuff for fun. If it's holding up the milestone or confusing people I will remove it asap.

Well, easy - good it's there, it showed potential issue if we would want to add zooming and it can stay if it will be not too hard to fix - editing is nice btw - and zooming - it allowed to simulate how much map will be visible on different resolutions

giniu wrote:

willurd wrote:On the topic of closing out prototype1, I only added all that editing/zooming stuff for fun. If it's holding up the milestone or confusing people I will remove it asap.

Well, easy - good it's there, it showed potential issue if we would want to add zooming and it can stay if it will be not too hard to fix - editing is nice btw - and zooming - it allowed to simulate how much map will be visible on different resolutions

Ok, well then until it starts holding up the milestone for real I'll leave it in there.

FYI, I made a version of the prototype that doesn't have a FSM and where everything exists in main.lua. It's in the proto1-remove-fsm branch. Do you guys like that better?

willurd wrote:FYI, I made a version of the prototype that doesn't have a FSM and where everything exists in main.lua. It's in the proto1-remove-fsm branch. Do you guys like that better?

looks good to me, but I'm no as skilled coder as bardbes, let's wait for his opinion - I'd say that if he lights green light, as only engine coder in team for now, we will close ticket 1 and officially say iteration 1 is finished

Meanwhile, I assigned ticket 1 to you as you worked a lot on it, and already created ticket 2 describing second iteration. It's description still might change, so wait with biting it before we finish first one, but if someone have nice assets for grass, road sign and temporary character, even if it's "Mr. Cone" or "Mr. Cyl" - it can be already prepared as they for sure will be needed, that's calling for new contributors to not disturb those who are finishing first iteration, anyone?