Problems with ATL and stuff

[Eamonn]

I'm having 2 problems:

1) The player isn't moving correctly on the Y axis
2) The player isn't colliding properly

I have a few questions as well, but I'll address them later on.

I've been trying for about a day to get this problem fixed, but fixed a different problem whist doing so! Now I'm down to 2 issues! Here are my problems in more detail:

Problem 1
-------------

I'll be playing my game, and I'll hit a wall. The player goes about half way into the wall, then his X get's reset. This keeps happening, but he clips into the wall. What am I doing wrong?

Problem 2
------------

The character moves fine along the X axis, but when I try to move him down he does REALLY SLOW. How can I fix this?



I've put almost 2 weeks of effort into this, and have had so many issues with it. But thanks to the people on this forum helping me(and a thread ages ago encouraging me(it was the jumping thread)), I haven't lost faith and have had the motivation to march on!




Now, I have some other questions:

If you've ever looked into the code of Mr. BallGuy, you'll know that I had lots of different ball classes and a few different coin classes. I think I would know how to prevent it, but I'm not sure if it would work and there might be a better way of doing it. What I was thinking of doing was having the Lua class system with metatables and having the path to the coin image as an argument to the constructor. That way, I can make new instances of the coin class and have it use different coin images. I could probably also setup a for loop to generate different ball objects, since the ball image would have been the same. This is a question that I was going to ask when I started my other project as it won't be used in this one.



This game that I will have attached is going to have different level packs. Each level pack is going to introduce a new concept. Say I wanted to add a new object that if you walk over you die, would I just have to check the tiles the same way I did for the wall? Here's the code for it:

Code: Select all

function player:isColliding(map, x, y)
	local layer = map.tl["Collision"]
	local tileX, tileY = math.floor(object.x / map.tileWidth), math.floor(object.y / map.tileHeight)
	local wall = layer.tileData(tileX, tileY)
	return not(wall == nil)

        local deadlyObj = map.tl["deadlyObj"]
        local doX, doY = math.floor(object.x / map.tileWidth), math.floor(object.y / map.tileHeight)
        local deadlyObj = layer.tileData(tileX, tileY)
	return not(deadlyObj == nil)
end

I assume that'd be right, but of couse I might be wrong.





Finally, I didn't know how to use the Tiled map editor and ATL together in LÖVE, so I watched Goatures tutorials on it. He did the following piece of code, but he didn't explain it. Maybe someone could explain it? I kind of half understand it, but I'd like someone to assure me

code:

Code: Select all

function player:update(dt)
	local halfX = object.w / 2
	local halfY = object.h / 2
	
	object.x_vel = math.clamp(object.x_vel, -object.speed, object.speed)
	object.y_vel = math.clamp(object.y_vel, -object.flySpeed, object.flySpeed)
	
	local nextY = object.y + (object.y_vel*dt)

	if object.y_vel < 0 then
		if not (object:isColliding(lvl1, object.x - halfX, nextY - halfY))
			and not (object:isColliding(lvl1, object.x + halfX - 1, nextY - halfY)) then
			object.y = nextY
		else
			object.y = nextY + lvl1.tileHeight - ((nextY - halfY) % lvl1.tileHeight)
			--object:collide("collideX")
		end
	end

	if object.y_vel > 0 then
		if not (object:isColliding(lvl1, object.x-halfX, nextY + halfY))
			and not(object:isColliding(lvl1, object.x + halfX - 1, nextY + halfY)) then
				object.y = nextY
		else
			object.y = nextY - ((nextY + halfY) % lvl1.tileHeight)
			--object:collide("collideY")
		end
	end

	local nextX = object.x + (object.x_vel * dt)
	if object.x_vel > 0 then
		if not(object:isColliding(lvl1, nextX + halfX, object.y - halfY))
			and not(object:isColliding(lvl1, nextX + halfX, object.y + halfY - 1)) then
			object.x = nextX
		else
			object.x = nextX - ((nextX + halfX) % lvl1.tileWidth)
		end
	elseif object.x_vel < 0 then
		if not(object:isColliding(lvl1, nextX - halfX, object.y - halfY)) and not(object:isColliding(lvl1, nextX - halfX, object.y + halfY - 1)) then
			object.x = nextX
		else
			object.x = nextX + lvl1.tileWidth - ((nextX - halfX) % lvl1.tileWidth)
		end
	end

	object.state = object:getState()
end

-- The object is the player metatable, so in theroy it is the ACTUAL player!

I think it basically just checks for the player's X and Y position VS the tiles X and Y position, sees if they're colliding and if not just continue to move, if not then we're colliding with the wall tile! If someone could maybe go more in depth so I actually can properly understand what it does I'd like that.




After spending about 3 months or so with LÖVE, I feel like I'm not learning as much as I should have. People have said that Mr. BallGuy was a good first project, but I've seen some other peoples first projects and they're incredible! I know for a fact some have only spent a week with LÖVE. But I don't know. I'm learning and that's why I'm making games: So I have something to do, because I can't find a good game I enjoy, to learn and the odd time show off to some people in my class. I remember showing some people in my class my game and they didn't believe me when I told them I made it


So yeah, any help is appreciated! Thanks!

Game: https://www.dropbox.com/s/06j0eh4mnwonbb7/NOM.love

P.S. This is a version that I've released for HELP. This isn't what the game is going to look like, there will be changes as I'm sure you've guessed. I've gotten so frustrated with this game at times, but I will finish it. I expect it to take me until the end of the summer to get a working copy of it out(with a level pack, some better looking maps and a more creative background). If you think the game is a bad idea I don't mind because it isn't a release, you don't know the concept and it's really only for me to learn(that's what MBG was, a learning experience!).

EDIT: After writing this I noticed that sometimes there's a weird no-cliping issue that traps you in the wall. Maybe some help with that too please?

[raidho36]

After spending about 3 months or so with LÖVE, I feel like I'm not learning as much as I should have.

The biggest reasons to such things is because you learn to program games first and learn to program second, thus you have little to no idea what you're actually doing, and you can't really do great stuff without knowledge basis.

I'll be playing my game, and I'll hit a wall. The player goes about half way into the wall, then his X get's reset. This keeps happening, but he clips into the wall. What am I doing wrong?

My guess is collision coordinates, wall lets player through further than it actually displaces the player.

The character moves fine along the X axis, but when I try to move him down he does REALLY SLOW. How can I fix this?

Adjust Y-velocity values, obviously. If that didn't helped, check through your functions line by line in order of execution (this is really important) to see if Y-velocity gets unexpectedly changed to small value.

hat I was thinking of doing was having the Lua class system with metatables and having the path to the coin image as an argument to the constructor. That way, I can make new instances of the coin class and have it use different coin images.

Yes, this is basically how you do it. It's called "abstraction". You define your basic structures to be less specific and more vague. But keep in mind that going too far is a bad thing, too. After all, the whole OO thing is merely for the sake of your own convenience, once it feels overcomplicated and hard to actually use it's a big call to cut it out.

Say I wanted to add a new object that if you walk over you die, would I just have to check the tiles the same way I did for the wall?

Yes. Just that other "killer" tile would have different collision response code.

Maybe someone could explain it?

It computes middlepoint of an object and it's velocities, then for negative Y-velocity it checks for collision and if there's none it just advances position by computed velocity and otherwise it would place the player on top of collided object via simple math, then it does about the same for positive Y-velocity just flipped, then the same thing for X-axis. Your outline was pretty much right.

[Eamonn]

After spending about 3 months or so with LÖVE, I feel like I'm not learning as much as I should have.

The biggest reasons to such things is because you learn to program games first and learn to program second, thus you have little to no idea what you're actually doing, and you can't really do great stuff without knowledge basis.

I'll be playing my game, and I'll hit a wall. The player goes about half way into the wall, then his X get's reset. This keeps happening, but he clips into the wall. What am I doing wrong?

My guess is collision coordinates, wall lets player through further than it actually displaces the player.

The character moves fine along the X axis, but when I try to move him down he does REALLY SLOW. How can I fix this?

Adjust Y-velocity values, obviously. If that didn't helped, check through your functions line by line in order of execution (this is really important) to see if Y-velocity gets unexpectedly changed to small value.

hat I was thinking of doing was having the Lua class system with metatables and having the path to the coin image as an argument to the constructor. That way, I can make new instances of the coin class and have it use different coin images.

Yes, this is basically how you do it. It's called "abstraction". You define your basic structures to be less specific and more vague. But keep in mind that going too far is a bad thing, too. After all, the whole OO thing is merely for the sake of your own convenience, once it feels overcomplicated and hard to actually use it's a big call to cut it out.

Say I wanted to add a new object that if you walk over you die, would I just have to check the tiles the same way I did for the wall?

Yes. Just that other "killer" tile would have different collision response code.

Maybe someone could explain it?

It computes middlepoint of an object and it's velocities, then for negative Y-velocity it checks for collision and if there's none it just advances position by computed velocity and otherwise it would place the player on top of collided object via simple math, then it does about the same for positive Y-velocity just flipped, then the same thing for X-axis. Your outline was pretty much right.

Kind of helped. Though I don't really understand what you mean by:

The biggest reasons to such things is because you learn to program games first and learn to program second, thus you have little to no idea what you're actually doing, and you can't really do great stuff without knowledge basis.

Do you mean I shouldn't be learning to make games? Am I a bad programmer? Really what I do is start work on a game, something I don't understand I Google, search on the forums, look at the wiki, and if all of those fail I ask here. What should I be doing...? I was advised(I can't remember where, but it wasn't here), to learn the basics, look at docs, research and ask questions. I'm trying my best, really, but I do need help along the way!

[raidho36]

I mean that you starting your whole programming with hardest programming discipline ever existed so far, that would demand having a lot of skill and knowledge before you even get to it. You should've started with programming, with learning algorithms, etc., not with something that requires you to apply all of that in order to work adequately. If wanting to make games was the reason to get to programming in the first place, it's okay, but now that you started to actually do it, you should switch the rails to go the right way. Go learn some good programming and then come back later. Since you already started with Lua, I suggest you reading PIL book through. Then The Knuth's Book may come handy, but it's really large and may get very advanced sometimes, but you will learn about algorithms and effeciency.

[Eamonn]

I mean that you starting your whole programming with hardest programming discipline ever existed so far, that would demand having a lot of skill and knowledge before you even get to it. You should've started with programming, with learning algorithms, etc., not with something that requires you to apply all of that in order to work adequately. If wanting to make games was the reason to get to programming in the first place, it's okay, but now that you started to actually do it, you should switch the rails to go the right way. Go learn some good programming and then come back later. Since you already started with Lua, I suggest you reading PIL book through. Then The Knuth's Book may come handy, but it's really large and may get very advanced sometimes, but you will learn about algorithms and effeciency.

So you're saying stop making games? Ok then... I guess I wasted 3 years of my life

EDIT: I did start with Programming. I didn't start with LÖVE. I started with HTML, CSS, JS, Python, Ruby, Java and C++.

[raidho36]

Then how comes you didn't get any advanced skill and programming understanding.

[Eamonn]

Then how comes you didn't get any advanced skill and programming understanding.

Again,

Maybe my old thread was right. Maybe I shouldn't have started...

[raidho36]

Well okay, just how far did you get with, say, C++ and Python, with any of them? Just trying doesn't count.

Maybe my old thread was right. Maybe I shouldn't have started...

Maybe you shouldn't've. I've seen some statistics claimed that only 30% of people have what it takes to be a programmer. Idon't honestly beleive it, but it makes sense to me, most people can't draw or sculpt, programming is just the same thing.

[Eamonn]

Well okay, just how far did you get with, say, C++ and Python, with any of them? Just trying doesn't count.

I finished all of TheNewBostons C++ tutorials, I know quite a LOT of Python(working on porting Mr. BallGuy using Cocos2d, PyGame and Cocos2d), I'm working on porting Mr. BallGuy into a Java Applet, I made a website that I was quite proud of(on my local harddrive, not published) using JavaScript/jQuery and the obvious. I finished TheNewBostons Ruby tutorials, and thats about it. I didn't really just 'try', I also tried to make a game in C++, but I never liked C++ so that died in like 3 months. Too low level for my liking. I plan to go back to it when I'm older because I'm only 13 now.

[raidho36]

So okay, you tried all of these languages and so far you have biggest experience with Lua, but you never actually learned to program.

Also, now that you mentioned your age, I can simply say that IT is the biggest reason why you can't get your things done well. Just get older and it'll get better on it's own. Until then you should concentrate on learning algorithms and language-specific caveats, on methods to debugging and optimizing, on game design, on graphics, on making music, etc. Or maybe you should simply play video games or football, or ride a bike or skate, you know.

Ever seen a toddler draws Mona Lisa tier painting? Exactly.