supervision of my first game(pong)

[Hugues Ross]

Flamebait my ass, he asked for opinion, no?
And my opinion is that you should not waste your time trying to make code running that should not be in you game at the first place.

The opinion that OOP is a bad approach here (and in most contexts outside of massive corporate monoliths) is fine! The problem is the approach you took in conveying that. You could've opened with a comment like the one you wrote later, where you provide examples that OP could look at to learn and understand why they should change approach, but you instead decided to do it by just telling them they don't deserve help because of that.

When you do stuff like that--no matter how good a point you may have--you're making it actively harder for the recipient to accept and learn from your feedback, putting the onus of dealing with that on the recipient instead of taking an extra minute to rephrase your post constructively. That doesn't mean people can't learn from it (I get this kind of feedback sometimes and I've learned to roll with it), but it makes it much less likely they will. If you care about helping others I recommend giving your critiques a second pass before hitting 'Submit'.

Anyway, back on topic: While as I said above I agree that OOP doesn't do you any good here, I also agree with the other main response that it doesn't really matter how you succeed as long as you get there without breaking anything. Many shipped games, including multi-million dollar franchises, have very crusty code running underneath that you never see because you only see the results of the code. That's not to say that there aren't lessons to be learned about code architecture and best practices, but it's hard to convey those lessons on very small 'just starting out' projects. Much of software design is concerned with ensuring code 'grows' cleanly, either in terms of complexity or workload, and very minimal projects don't really run into such barriers.

Personally, if your goal is to try and figure out the 'best way' to do things I'd recommend looking to the community for examples of projects they feel are well-written (and why, if they're in the mood to explain!) and studying those.

[_JM_]

You could try the approach on this topic for implementing game states

https://love2d.org/forums/viewtopic.php?f=3&t=94157

And if you're looking for some simple examples of games with löve (with code), check this link

https://simplegametutorials.github.io/love/

[hokuto]

You could try the approach on this topic for implementing game states

https://love2d.org/forums/viewtopic.php?f=3&t=94157

And if you're looking for some simple examples of games with löve (with code), check this link

https://simplegametutorials.github.io/love/

Thanks for the links, although the one with the states seems confusing to me and I don't understand it very well.

[hokuto]

Personally, if your goal is to try and figure out the 'best way' to do things I'd recommend looking to the community for examples of projects they feel are well-written (and why, if they're in the mood to explain!) and studying those.

Tell me where I can find these projects to download and study them.

[hokuto]

I wouldn't pay much attention to that kind of flamebait.

Flamebait my ass, he asked for opinion, no?
And my opinion is that you should not waste your time trying to make code running that should not be in you game at the first place.

If i had to replicate the file above i would end up with something like this: main.lua.zip
Not saying this is the sate of art, dont let anyone tell you how it has to look in the end as long as it works.
But you just dropped

I would also like to know how to make pressing enter go from the title screen to the game screen because I don't know how to do it.

And this problem would not even exist if you would not try to wrap your gamestates into a weird object list.
You can just change where a name is pointing to at any point.
Lets say you want to implement pause in the future, what you are preparing up to here is writing a ton of lines for a new gamestate as opposed to just deleting love.update. So why do all this work?

The example is appreciated and it works well, but the code is confusing and unclear to me and I don't understand it in part. It would be appreciated if you could explain it step by step how you did it and why.

As I said I write with oop because it is how I have learned and therefore I don't know how to do it any other way, to know how to do it in another way they have to teach me or see examples of how to change the style, I am open to any style and it helps I don't mind using object-oriented or procedural programming or whatever because what I like the most is learning from everyone and applying any style. Greetings

[BrotSagtMist]

You could've opened with a comment like the one you wrote later, where you provide examples that OP could look at to learn and understand why they should change approach, but you instead decided to do it by just telling them they don't deserve help because of that.

The reason was simply that it wasnt directed at OP. I meant it in general, OOP users will be ignored because its a lost case most of the time.

The example is appreciated and it works well, but the code is confusing and unclear to me and I don't understand it in part. It would be appreciated if you could explain it step by step how you did it and why.

Lacking the ability to see the confusion here so you have to ask very specific about the parts you dont get.

The general idea of that code is simply renaming stuff.
The main loop calls _something_ with the name love.update and love.draw IF it exists for every frame.
Nothing stops you from throwing that name around as you like:

Code: Select all

game=function(dt)
--gamestuff
end
title=function(dt)
-- titlestuff
end

--turn the title on by making love.update IDENTICAL to the function title
--and thus have it running every rame
love.update=title 

--switch to the game screen using the same method
love.update=game 

--pause the game by removing love.update and by that removing any passing of 
--the time value _dt_ to the game function
love.update=nil

--resume game
love.update=game 

[hokuto]

I am going to try to explain myself well because it is not easy to write in my language and then translate it with the translator and tweak until something understandable remains.

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.

Code: Select all

function love.load()
end
function love.update(dt)
end
function love.draw()
end

Your first example:

Code: Select all

love.window.setMode(640,480)
love.graphics.setDefaultFilter("nearest","nearest",0)
B={}

function totitle()
 B["return"] = togame
 B.escape = love.event.quit
 love.graphics.setColor(200,200,200)
 
 function love.draw()
  love.graphics.print("PONG",200,200,0,6,6)
  love.graphics.print("Start",200,400,0,3,3)
 end
end

function togame()
 B["return"] = nil
 B.escape = totitle
 love.graphics.setColor(200,200,0)
 
 function love.draw()
  love.graphics.print("Gameplay",200,200,0,5,5)
 end 
end

love.keypressed = function(_,a) 
 if B[a] then B[a]() end
end

totitle()

In this example, the load, update and draw functions are not there, which I did not know could be done, then you introduce the draw function in the totitle togame functions, and I did not know that this could be done either.

Then you create a table and introduce the functions and the quit event, which is something I didn't know I could do either.

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.

Code: Select all

game=function(dt)
--gamestuff
end
title=function(dt)
-- titlestuff
end

--turn the title on by making love.update IDENTICAL to the function title
--and thus have it running every rame
love.update=title 

--switch to the game screen using the same method
love.update=game 

--pause the game by removing love.update and by that removing any passing of 
--the time value _dt_ to the game function
love.update=nil

--resume game
love.update=game 

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.

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.

It seems that love2d allows you to program without any set rules and that is quite confusing,

[BrotSagtMist]

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.

[knorke]

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.

[BrotSagtMist]

And just when i was trying to save people from making unnecessary if checks in their loops....

But here a mental tip: Code has a flow, at any given time we are exactly at one spot in the code. Make sure that you can always tell where it is, how we got there and where its going to be next.