2026-09-09 13:36 UTC
@Ross_@mastodon.gamedev.place
Thanks for the response!
A or C would work.
We have found a solution, which we think is the worst implementation. Where we store, for example, a table with scenes and requires for each lua file, and another table with function mames and other parameters. So we fetxh feom one table, and call a function with the indices of the other table.
This effectively lets us change whats drawn on screen and even change the BGM at will, but we feel it is ill suited for actually building a game on top of that (can edit to add a screenshot of the code later). So having an idea on how one would properly transition from level to level, or from gameplay to a map screen, or from main title to gameplay would be appreciated. Of course the specifics of what "a menu" entails are up to interpretation (a series of functions leeching off love.draw() [what we are doing] or an object that builds the UI), same with "a level". But yeah you get the idea.
So getting an idea of what a implementation is like would be worth it.
Replies (1)
-
@Ross_@mastodon.gamedev.place 2026-09-09 15:14
@ZanaGB@lgbtqia.space OK, I'll start working on an example. It may take a week or something, but hopefully less. To me all games boil down to a tree structure of objects. It doesn't have to be complicated or deep; you have a list of things that exist, and items in that list may have their own list of sub-items (or "children"). I fire the main callbacks (load, update, draw) on a root object, which passes on those calls to its children, and so on. 1/4...