I have a question.

[com_1]

Wow, your code is... dense. I really, really encourage you to start indenting more. And put statements on their own lines. It's next to impossible for me to read code that is 90% this:

I'm curious to understand how something works from the ground up.
" I thought that my code will understand even a child "

I can't see the walls of the game. I looked at the image of the game to imagine where walls were. I also can't figure out how to get to the big circle on the other side. Is there a button to press?

I have everything working properly and no brakes. (pack (.zip) just do not normally get)
I likewise can not download properly or run other demos from the forum.

Now clear to me that the problem in "Love2D". (very sorry)

[tentus]

I thought that my code will understand even a child

Um... i think you meant the opposite of what you said. A child can understand your code?
No, absolutely not. Your code is a mess of indecipherable indexes and the Lua equivalent of run-on sentences.

I have everything working properly and no brakes

Brakes? Like on a car?

I likewise can not download properly or run other demos from the forum.

Are you saying that other .love files won't run on your copy of Love?

Now clear to me that the problem in "Love2D".

If it was a Love problem, it would be universal. Because you and I didn't have the same problem, it means the bug is somewhere in your code, drawn out by his hardware. Just because something acts right on your machine does not mean that it's bug-free.

[kikito]

Wow, your code is... dense. I really, really encourage you to start indenting more. And put statements on their own lines. It's next to impossible for me to read code that is 90% this:

Code: Select all

if td_sabito == 1 then
td_py3[d][0] = td_py3[d][0] - td_sk; td_py3[d][1] = td_py3[d][1] - td_sk; td_py3[d][2] = td_py3[d][2] - td_sk; td_py3[d][3] = td_py3[d][3] - td_sk; td_py3[d][4] = td_py3[d][4] - td_sk; td_py3[d][5] = td_py3[d][5] - td_sk; td_py3[d][6] = td_py3[d][6] - td_sk; td_py3[d][7] = td_py3[d][7] - td_sk; 
td_ny[d][0] = td_ny[d][0] + td_nakl; td_ny[d][1] = td_ny[d][1] + td_nakl; td_ny[d][2] = td_ny[d][2] + td_nakl; td_ny[d][3] = td_ny[d][3] + td_nakl; td_ny[d][4] = td_ny[d][4] + td_nakl; td_ny[d][5] = td_ny[d][5] + td_nakl; td_ny[d][6] = td_ny[d][6] + td_nakl; td_ny[d][7] = td_ny[d][7] + td_nakl; 
end;

The demo worked fine on my computer, but that code breaks my heart and hurts my soul.

It must be breaking some law.

... Actually, it breaks two (that I can think of).

• "You shall give proper names to your variables"
• "Don't repeat yourself" (a.k.a. don't copy-paste code)

Regarding the first, there should be something more humanly intelligible than td_py3, td_sk, td_nakl, td_ny and d

Regarding the second, please have a look at my (still unfinished) LÖVE tile tutorial, specially the parts called tables and loops and more tables.

[tentus]

... Actually, it breaks two (that I can think of).

• "You shall give proper names to your variables"
• "Don't repeat yourself" (a.k.a. don't copy-paste code)

I used to have a coworker that repeatedly stated that once you finished some code, you should be able to retype it from memory in a matter of minutes. Your variables might be different and the functions might be rearranged, but once you figure it out once it should be like riding a bike. It's still one of the best DRY arguments I've ever seen in action.

com_1, an approach you may want to take is something referred to as "code transparency" where I'm from. The idea is that all of your code should be self-apparent: when you define a variable, the name should tell anyone reading it what it's used for. All of your comments then become reasons rather than references: because the code is transparent (the reader can intuit what it does) the comments serve to illustrate why the code is that way.

I'm not a prime example of this approach, but here's a bit of code from my game that shows what I'm talking about:

Code: Select all

for i=1, multiplayer do
	local headX = (screenWidth / (multiplayer + 1)) * i		-- player heads are equidistant from each other and the screen edges
	local headY = (screenHeight / 2) - 64
	love.graphics.draw(headImg, headX, headY)
end

Note that the variables are pretty clear: headX is the x coordinate of the head image, which is stored in a variable called headImg outside the loop. The comment tells us why the code is there: we want the player heads at specific coordinates for a reason. This code isn't terribly complex, but it illustrates what I'm talking about: clarity for the sake of clarity. And future sanity, I suppose.

[kikito]

I'm not a prime example of this approach, but here's a bit of code from my game that shows what I'm talking about:

Code: Select all

for i=1, multiplayer do
	local headX = (screenWidth / (multiplayer + 1)) * i		-- player heads are equidistant from each other and the screen edges
	local headY = (screenHeight / 2) - 64
	love.graphics.draw(headImg, headX, headY)
end

Two comments on that:

• multiplayer is a number representing the number of players, right? On that case, I'd name it something a bit more descriptive than multiplayer. Perhaps playerCount
• I'd also put the 'head calculation' inside a function somewhere

Code: Select all

...
-- Calculates the head position for a player (equidistant from each other and the screen edge)
function getHeadCoordinates(playerCount, playerIndex)
  return (screenWidth / (playerCount + 1)) * playerIndex, (screenHeight / 2) - 64
end
...
for i=1, playerCount do
	love.graphics.draw(headImg, getHeadCoordinates(playerCount, i))
end

Some people will also say that i should be named playerIndex on the loop. I'm not that extremist.

[com_1]

From what I read I realized that I have zero programming.
Well, as everyone has his own opinion.

Thanks for comments.

[kikito]

Don't be sad. Everyone has to start somewhere. You have accomplished more than the majority of people out there. What you have is impressive.

But it's also a bit unmaintainable; the graphical glitch on Technocat's computer is going to be very difficult to debug with your current code. Not only for the forum people, but for your future self. In two months, it is unlikely that you will remember the difference between td_py3 and td_ny.

Variable names that differ in 1 or 2 letters, as well as code repetition, are objectively bad - this is not just a personal opinion; it has been demonstrated and tested.

They are also a common problem for new programmers. You get better at it with time.