Having *unique* objects on screen

[Smooth203]

okay, I'm making a game (really?) yeah. It's a survival game (it's in very ealry development though) I wouldn't say I'm a beginner, nor am I an expert but I've come across a problem as I'm trying to implement a foraging system and I want bushes that spawn and be completely independant without writing code for each and every one (there could be up to hundreds in the map at once for example) I've found code that works when one is spawned and I 'harvest' it, it gets set to harvested and the image changes then I spawn a new one, it works prefectly again (execpt the image is still changed). But if there are more then one spawned at once, if I harvest one of them, they all get set to harvested. I you have completely no idea what I mean because of my ineptness of explanation then please ask questions and I may be more of use

I have a .love file for you too, WASD = move, middle click to spawn a bush at mouse co-ords, space to 'harvest'

gameFiles.love

(315.66 KiB) Downloaded 125 times

PS. My code is probably horrendous so I apologise beforehand.

[airstruck]

PS. My code is probably horrendous so I apologise beforehand.

Instead of apologizing, you could take the time to clean it up. I took a quick look, but the code is very difficult to follow. Since nearly everything is global and there's absolutely no encapsulation it's very hard to determine where anything is defined or what effect any particular function has without reading every single file in the project. Maybe someone who has more time can take a closer look, but my personal assessment would be that this only "works" by coincidence and the overall organization of the project should be reconsidered.

[Smooth203]

Instead of apologizing, you could take the time to clean it up. I took a quick look, but the code is very difficult to follow. Since nearly everything is global and there's absolutely no encapsulation it's very hard to determine where anything is defined or what effect any particular function has without reading every single file in the project. Maybe someone who has more time can take a closer look, but my personal assessment would be that this only "works" by coincidence and the overall organization of the project should be reconsidered.

Thanks for the heads up, I'll revise my organisation

[airstruck]

Take a look at how modules are defined in these two examples. This pattern will make it much easier to see how different modules relate to one another (especially for someone else reading your code).

http://lua-users.org/wiki/ModuleDefinition

http://lua-users.org/wiki/ModulesTutorial (skip "the old way" part)

[pgimeno]

See also this thread, which may be related to your problem: https://www.love2d.org/forums/viewtopic.php?f=4&t=82597

[Smooth203]

Thanks guys, I'll have a look at what you've given me and see if I can fix my problem. Also, would it be better if I just use the main.lua file and not have the many other files unless neccesary?

[Positive07]

NO! Then you would have a HUGE main.lua file with so many lines I WOULD NEVER READ!

The best way to do stuff is organizing things, player code and monster code is different, the main menu is not part of the game mecahnics... and so on. Of course there would be some files that would interact with others, for example you could have a main.lua file that requires menu.lua and game.lua, game.lua would require monster.lua and player.lua and so on

If your player is not going in the right direction, the only file I should look to fix it should be player.lua since no other file should modify the player direction, if the problem is not there I would go up a level to game.lua which handles the actual game mechanics and updates my player.lua, if the error is not there I should go up a level and check that my main.lua file is sending the rights events to game.lua.

If you read that I never had to check my monster.lua file or menu.lua file, since they don't have anything to do with the code I wrote for the player, they do their own stuff. This is encapsulation.

Files should handle only one thing (monster, player, game, menu, options, levels), in those files there should be module tables or classes, the first one is just a table with many functions it may have some internal state but keep it as little as possible if you can (since this is hard to debug), the second one is a class generated with a class library which I can use to replicate an object, for example I could have a monster class to spawn multiple instances of the monster object around the level.

Functions should do one thing and one thing only, the idea is that a function shouldn't be doing too much, if a function does too much you can't reuse it, say if I have a function that checks collisions, it should not handle collisions itself, it should instead call other functions that handle the collision (in the first case the player is colliding with a monster so I run check collisions and I get that the player is colliding with a monster and substract 5 from the health, what would happen if its colliding with a wall? I would have to write another function that checks collisions and then instead move the player so that it stops colliding, in the second case check collisions would only check what the player is colliding with, then I would see if I need to move it or substract 5 from his health)

Use locals!, If you use global variables you can't use the same name, say I have a configuration table which is global and handles global configuration say sound and graphics, players.lua also has got a configuration table which is global and has the very same name, but this one is only used to configure the player speed and some internal stuff, the first table would be overriden with this one and that is NEVER what you want, it's really hard to debug this problems since the code is totally valid, but it won't be doing what you want!

I must recommend this series of blog posts that was written by a developer (Kikito) that made some really nice modules for LÖVE and Lua (Bump, Middleclass, Gamera, Love-loader and so on) I must say that he doesn't always follow his own advice but doing so would result in far better libraries nonetheless (love-loader!!!)

[Smooth203]

NO! Then you would have a HUGE main.lua file with so many lines I WOULD NEVER READ!

The best way to do stuff is organizing things, player code and monster code is different, the main menu is not part of the game mecahnics... and so on. Of course there would be some files that would interact with others, for example you could have a main.lua file that requires menu.lua and game.lua, game.lua would require monster.lua and player.lua and so on

If your player is not going in the right direction, the only file I should look to fix it should be player.lua since no other file should modify the player direction, if the problem is not there I would go up a level to game.lua which handles the actual game mechanics and updates my player.lua, if the error is not there I should go up a level and check that my main.lua file is sending the rights events to game.lua.

If you read that I never had to check my monster.lua file or menu.lua file, since they don't have anything to do with the code I wrote for the player, they do their own stuff. This is encapsulation.

Files should handle only one thing (monster, player, game, menu, options, levels), in those files there should be module tables or classes, the first one is just a table with many functions it may have some internal state but keep it as little as possible if you can (since this is hard to debug), the second one is a class generated with a class library which I can use to replicate an object, for example I could have a monster class to spawn multiple instances of the monster object around the level.

Functions should do one thing and one thing only, the idea is that a function shouldn't be doing too much, if a function does too much you can't reuse it, say if I have a function that checks collisions, it should not handle collisions itself, it should instead call other functions that handle the collision (in the first case the player is colliding with a monster so I run check collisions and I get that the player is colliding with a monster and substract 5 from the health, what would happen if its colliding with a wall? I would have to write another function that checks collisions and then instead move the player so that it stops colliding, in the second case check collisions would only check what the player is colliding with, then I would see if I need to move it or substract 5 from his health)

Use locals!, If you use global variables you can't use the same name, say I have a configuration table which is global and handles global configuration say sound and graphics, players.lua also has got a configuration table which is global and has the very same name, but this one is only used to configure the player speed and some internal stuff, the first table would be overriden with this one and that is NEVER what you want, it's really hard to debug this problems since the code is totally valid, but it won't be doing what you want!

I must recommend this series of blog posts that was written by a developer (Kikito) that made some really nice modules for LÖVE and Lua (Bump, Middleclass, Gamera, Love-loader and so on) I must say that he doesn't always follow his own advice but doing so would result in far better libraries nonetheless (love-loader!!!)

wow, thanks a lot, that's really helpful!

[Positive07]

wow, thanks a lot, that's really helpful!

I'm glad this helped! I found this stuff all by myself after trial and error, but I have found this is how most developers do it and recommend to do it. I must note that you should try the style that suits yours need, maybe for a small prototype putting everything in main.lua is not a bad idea. Try until your feel confortable with your tools, your setup, LÖVE APIs and your style, when you get there you will develop WAY faster, find your errors ASAP and get things done! Have fun and ask whatever you need

[Sulunia]

One small, personal recommendation: use assert in functions, either for values you received or values you will return. This will make sure the game is not receiving nil values when it shouldn't, and makes debugging easier! Well, at least for me it does.