2026-09-09 11:54 UTC
Replies (2)
-
@ZanaGB@lgbtqia.space 2026-09-09 13:36
@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.
-
@ZanaGB@critter.cafe 2026-09-20 19:24
@Ross_@mastodon.gamedev.place @penaz@mastodon.gamedev.place Pinging here from the new account to give you two some very big thanks. We finally were able to implement a proper "real" scene switcher. it was indeed a case of overthinking, overplanning and overengineering. Everything now latches onto draw/update and parsing the init function (could not get rid of that somehow, but it is now simply a 2D table with the name of the file as it's index, and the drawable) just takes cares of the initialization. with this, this project is one step closer to being a real game, but for now perhaps it's best to scale back on the project and think back to our demoscene-artist days and just make a non-interactive thing to try and build other systems rather than trying to tackle needs we don't know what could possibly look like. Again, thanks for the nudge on the right direction!