supervision of my first game(pong)

[hokuto]

When I've seen a love tutorial, the first thing it teaches you is the love.load, love.update and love.draw functions that you have to place them in order and then you create your tables as objects and place them appropriately in each function.

Do they explain why? Dont write anything that you do not exactly know why you write it. If you cant make sense of it, leave it out.

Lets take love.load for example. This can be used to restart the game, pass command line arguments or to calculate local values without polluting the name space.
So it can be useful. If you need any of the above. But if you dont, there is simply no reason to use it other than that tutorial telling you to do it.

Finally, you create the kepressed function with the parameters (_,a) that I don't know what it refers to and then you use a conditional that I don't know what you're doing there.

This simply means that whenever a key is pressed it will use the argument _a_, which is the name of the key as string, to look in table _B_ if it has an entry of the same name, and if it does, call it.
This just binds functions to keys.

In this example you are saving functions in love.update as if it were an empty table and I did not know that this could be done and I also did not know that love.update was a table and I do not understand that it is allowed to use an internal table or function to save data. These are things that are not explained in any tutorial and they confuse me.

Everything is a table in lua and everything is empty. And these functions are made up anyway.

Löves strengths are also its weaknesses. By providing sensible defaults it also hides away whats going on in the background and makes it hard for beginners to follow what is going on.
See https://love2d.org/wiki/love.run, but the TL:DR version is that at the end of your main.lua file löve appends something like this pseudo code:

Code: Select all

if love.load then love.load() end
while true do
 for event, values in listevents() do
  love[event](values)
 end
 love.update(timepassed)
 love.draw()
 sleep(1/60)
end

So if love.load exists, run it.
Start an infinitive loop.
For all keyboard/mouse events call functions that have that name.
Run love.update and love.draw
Sleep and repeat next frame.

This code is normally invisible to the user.
Thats it. Thats the game loop. There is no higher reason behind draw and update, it simply happens that whatever has that name gets called each frame.
And that is purely because it is written like that at this spot.

In addition to the fact that you call love.update three times and I didn't know what could be done either, so I wonder what tutorials you followed to learn that this could be done.

In this example love.update is NEVER called. It is assigned, HUGE difference.
I never used any tutorial, there is documentation for that purpose.
But you on the other hand have the problem that you are trying to use löve without the knowledge of how to use lua.
And our own wiki notes to read PIL at the beginning. https://www.lua.org/pil/contents.html
This is where you should start.

Thank you very much for the detailed information. This lua book is in English and that will make it difficult for me to learn, I know that the reference manual has a Spanish version but you don't know any book in Spanish about lua.

Before starting to study the book, I'm going to finish the pong example because I don't like to leave things half done, although you probably won't like the code that it shows, although I will try to minimize the oop as much as possible.

[hokuto]

BrotSagtMist is using some technics that are very useful but when starting out, they are too confusing.
All "tricks" of the Lua language are documentated, afterall programming always follows strict rules.
But you will not find it in beginner tutorials. Tutorials often write stuff that is not 100% technically correct but simplified to the necessary basics.
When learning how to do drive a car, the instructor does not explain how the engine works, what a piston is and what the valves do.
He just says: "Press that pedal to go faster."

Brot gives good background information on how Löve2D works but it is getting a bit too far into details.
Maybe ignore it for now, bookmark it and read it again at a later stage.
For now, maybe ask yourself:
What parts of Lua and Löve2D do you already know?

If you have read around a bit then you should know..:
1) how to print text on screen and simple drawing.
2) How to declare functions and how to call those functions.
3) How variables work.
5) How branching via if works.

That is enough to write the program you want. No OOP needed. No re-defining functions needed, no tables needed.

Functional example:

Code: Select all

local gameStatus = "title"
local paddleX = 400

--function love.load()
	--this function is currently empty.
	--we can simply remove it if we do not need it.
--end

function love.update(dt)
	if gameStatus == "title" then updateTitle(dt) end
	if gameStatus == "ingame" then updateIngame(dt) end
end

function love.draw()
	love.graphics.print("gameStatus="..gameStatus,10,10, 0,2,2)
	if gameStatus == "title" then drawTitle(dt) end
	if gameStatus == "ingame" then drawIngame(dt) end
end

---ingame gameplay---
function updateIngame(dt)
	if love.keyboard.isDown("escape") then gameStatus = "title" end
	if love.keyboard.isDown("left") then paddleX=paddleX-(dt*100) end
	if love.keyboard.isDown("right") then paddleX=paddleX+(dt*100) end
end

function drawIngame()
	love.graphics.print("press left & right arrow keys to move <-  ->",100,400, 0,2,2)
	love.graphics.print("press ESC to return to title.",100,420, 0,2,2)
  --draw the player's paddle:
	love.graphics.rectangle("fill", paddleX-50, 500, 100, 50) 
end

---title/menu screen---
function updateTitle(dt)
	if love.keyboard.isDown("return") then gameStatus = "ingame" end
end

function drawTitle()
	love.graphics.print("PONG!",100,100, 0,5,5)
	love.graphics.print("press RETURN key to begin playing",100,200, 0,2,2)
end

That is very crude code - not very elegant. But it is very simple and readable.
You can make a complete Pong in that style.

Thanks for the example, I'll study it to get ideas.

[hokuto]

Here is the updated pong code, I have tried to follow BrotSagtMist's advice and not use oop and be faithful to the example that happened to me, but I have a problem.

The functions handled by the player and the cpu have a love.draw and when they are painted on the screen only one appears, so how can this problem be solved. I would also like to know if the code is more appropriate or if something needs to be changed.

[BrotSagtMist]

This is the same code. You havent changed anything.
All you did was cosmetics but the code flow is the same.

[hokuto]

This is the same code. You havent changed anything.
All you did was cosmetics but the code flow is the same.

Hehehe, I laugh so as not to cry.
During these days the only thing you have shown me is a very messy little example, with a horrible and confusing syntax and your comments are even more confusing and not clear at all.

I have tried to get something out of that and the only thing I have achieved is to show a new example that does not work well and that you tell me that it is the same thing that I did at the beginning, of course it is. With the little information that I have been able to get, it is what The only thing that I have been able to do because you do not show me a complete example of how you would do it and with a clear explanation.

But you don't do that because it gives the feeling that you don't want to teach anything, it's as if you were hiding valuable information that makes you think you're different from others and that you don't want to share or that you really don't have anything to teach and that's why so much criticism and unclear comments that teach nothing.

The only thing you have achieved is that it is more lost and confused than at the beginning, so what I am going to do is study the book on the lua page and continue with my oop style, because you have not shown me anything that improves it and is better and clearer, but as I said, you don't really show it because you have nothing, neither valuable information nor your own style.

[knorke]

You have multiple declarations of love.update() and love.draw()

This is your first project and you are still learning the basics of Lua language and Löve2D.
At this point OOP is too advanced. (That is not really oop anyway.) In the "Programming in Lua" documentation it is chapter 16, quite far back.
Try writing simpler code, for example without functions declared inside other functions. That will make it easier to find logic mistakes.

[pgimeno]

Brot's excuse is that he's German (even though he's the only German I've know with so much bile to spread). Anyway...

There are several approaches to gamestates. But first let's define what we're talking about. When you're in the menu screen, you want to handle the menu; when you are in the game screen, you want to handle the game, etc. We then say that the game is in the menu screen, or in the game screen. Since the word "screen" is used for more things, a unique word that has been used for that purpose is "gamestate", so in this case there would be the "menu gamestate" and the "game gamestate".

I've seen some people call that "scenes", but a scene library is typically a different thing that implements a kind of graph, so it's not a very good word either.

The bottom line of gamestates is that they need to receive the Löve callbacks in order to handle them for their purpose: the menu needs to handle events in a way that makes the menu work, and same thing for the game. And of course there are several ways to implement them.

I've seen some people do it like this:

Code: Select all

local state = "menu"

function love.update(dt)
  if state == "menu" then
    menu:update(dt) -- call the update for menu
  elseif state == "game" then
    game:update(dt) -- call the update for game
  end
end
...

I consider that hard to maintain and inelegant, though, because every event needs to know about all states it supports, preventing modularization. A simpler and (IMO) better solution is to have the state be a variable that holds an object, and that object may or may not have the event:

Code: Select all

local state = menu

function love.update(dt)
  if state.update then -- check if the current state has an update method
    state:update(dt) -- call it if so
  end
end
...

That's the way I prefer to implement them. I also have a function to switch states; that function has the additional feature that it calls a method deactivate() in the gamestate you're leaving and a method activate() in the gamestate you're entering (again, if they exist), which allows initialization of the state, stopping sound when the state is finished, etc.

That's also pretty much what RNavega was trying to explain, except that I added the check that the method exists, because not all gamestates need all methods, and my convention for naming the enter/exit events is different.

[BrotSagtMist]

Rude

I was trying to help in best faith.
But i have once again proven why i choose to put OOP users on ignore.

[darkfrei]

My opinion: OOP is good only when you know how it works AND when you think that it's a best solution to make your code simpler/readable/supportable.

Yes, as any other ways to use code abstractions.

[hokuto]

You have multiple declarations of love.update() and love.draw()

This is your first project and you are still learning the basics of Lua language and Löve2D.
At this point OOP is too advanced. (That is not really oop anyway.) In the "Programming in Lua" documentation it is chapter 16, quite far back.
Try writing simpler code, for example without functions declared inside other functions. That will make it easier to find logic mistakes.

Thanks for the advice. I was clear about what I had to do from the beginning and I just wanted guidance from the community, but by listening to this individual and following his advice I have only managed to make ugly and useless code.

I will focus on studying the lua book and then I will return with love2d.