Help with a black screen when exiting out of my lobby [closed]

[bobbymcbobface]

Ah, i see thank you - i shall try this when i get a chance

[bobbymcbobface]

ok i just tried this and it just stays the same, all collisions are stored and the new world doesn't seem to be doing anything - am i missing something i.e clearing all instances of previous code using a command or something?

game.love

(7.16 MiB) Downloaded 200 times

[pgimeno]

I think that your main problem is the organization of the code.

sprite.lua is creating its own world.
map.lua is creating its own world that is not used.
lobby.lua is creating a global world that is not used anywhere.

What are the responsibilities of sprite.lua? Judging by the name, one would think that it deals with sprites (graphics), but when looking at the code, one can see that it also deals with player movement and collisions, i.e. with game entities. The name is a bit misleading (for me at least).

You call sprite:add_collision in lobby.lua to add its collisions, therefore the only world that is used is the one in sprite.lua, and the others are unused. I don't know if that makes sense, but it sounds messy to me to have the collision world in a file that handles the entities and that is called sprite.lua.

I don't much understand what the responsibilities of map.lua and lobby.lua are, and how you're supposed to swap maps, or how your game is planned for the matter. Stop and think about it, from an organizational point of view at least, because it seems to me that you're drowning in mixed competences.

"map.lua" sounds like a generic file that can handle any map, including the lobby. If you don't want to separate world handling into another file, it's a reasonable choice for holding the world. "lobby.lua" sounds like the file that handles things that are specific to the lobby. Yet for some reason, "map.lua" does not require "lobby.lua", and I find that confusing. It also requires "sprite", which I find even more confusing, because in my mind a map is lower-level than game entities, and shouldn't require then. You can see it the opposite way (entities as lower-level than maps), which is why I don't usually give advice about organization of the code, because that's a personal thing and what is clear in one's mind may be the opposite of what is clear in someone else's mind. In this particular case, however, you seem to be running into issues of organization, which is why I've decided to break my rule and give you some advice.

One trick you can use is to draw a diagram of how you think each part of the program should depend on each other. If your code is well organized, this should have no circular dependencies, i.e. the diagram should be drawable with all "requires" arrows pointing in the same direction. Think of it as a hierarchy: high-level modules are like managers, in that they handle strategic decisions and handle the functions of other modules; low-level modules are like interns, in that they do the ground work. Here's how I see a possible organization of your project; note how all arrows point down:

bitmap.png (12.49 KiB) Viewed 3419 times

It's possible that some dependency is missing, and then you need to add arrows, but if it's well organized, the arrows would always point down. If you have no globals, the possible "sneaking" of hidden circular dependencies is reduced. When you need a circular dependency between two modules, you can usually solve it by adding a common module which implements the functionality that prompted you to add that dependency, and make both modules depend on it.

I have to say that currently, there is a bit of sneaking of circular dependencies, via the shared states, because each state that activates another state, indirectly depends on it; e.g. menu depends on game and game depends on menu, in order for the menu to be able to activate the game and for the game to be able to go back to the menu, but I don't think that's a problem. It would be possible to break the circularity using coroutines, but that's a bit overkill, therefore having that hidden circular dependency is OK in this case, but it should be the exception, not the rule.

It's also possible that I have misinterpreted, and that "lobby.lua" is an introductory map, and "map.lua" is the main map where 100% of the rest of the game will happen and then you can't return to the lobby. In that case it's also somewhat reasonable to treat them as separate states, where lobby.lua is a complete "mini-game", so to say, and map.lua is the "real game". That would immediately provide a mechanism to switch from the lobby to the main map, keeping each isolated, but that could mean a bit of code repetition.

I see you haven't really cleaned up anything since the separation of states. The old state handling stuff is still around, clobbering the code. There are many globals still used in map.lua, sprite.lua and lobby.lua. main.lua is using a global by mistake, because I forgot the args parameter to love.load; it should be declared as 'function love.load(args)'. introhandler.lua is using 'splash' as a global also by mistake because I forgot to declare it as a local in the variables section.

Getting rid of the globals should be a priority, as they can cause surprises like values changing for no apparent reason (if you inadvertently use two globals with the same name in different files), and they make dependencies more confusing, making the code unmaintainable. Unmaintainable code is also hard to read, and since you're asking for help, the more readable your code is, the more likely you are to get help. No one likes to read unmaintainable code; it's too much effort just for helping some guy in a forum.

Next would be to decide responsibilities of each file and give proper names to the files, especially since you're asking others for help.

Next would be to clearly separate the responsibilities, deciding what each file must do and not mixing unrelated code there. When you run into something new that your code needs to do, stop and think whether there's a suitable place in the existing code or if you must create a new file for it. Sometimes it happens that it's not worth separating the functionality at first, and when the code grows, it starts being a necessity to avoid having unrelated code for a common functionality all over the place. If that's the case, invest some time in refactoring your code, don't let the snowball grow until it's too big to manage.

After all that cleaning-up and reorganization, and when you have decided on a suitable place to hold the bump world, we can talk about how to clear it. One easy way would be to just provide a function that clears it (by setting the variable to a new world) from the file that handles it.

[bobbymcbobface]

Ah thanks pgimeno (sorry for the long response ) for now i will take a break and work on a smaller project (snake if you'd like to know) and aim for more realistic goals due to the fact I've finally realized making a game isn't as easy as i thought so i will close this topic but thanks a lot for all the help you and the community has given to this game because it means i can fall back onto my previous game for help.

again thanks all