Beginnings of a generic bullet library

[HazeAI]

Hey Guys,

I've been programming in python full time for about a year now and decided about a week ago to get into love game development after seeing mari0. It seemed much more polished and fun than anything I've seen out of PyGame so it made me really interested in checking out love. I decided to start on a shmup first due to the simple physics, but got hung up on bullets and ended up devoting all my time to making a generic bullet library because I was having fun working on patterns and things like that. It needs more polish, and I'd really like to figure out curved bullet paths and a few other things, but at some point I will incorporate this into a full game, but I'd like to distribute the bullet library as open source.

I decided to put this up as is because it's my first shot at game programming and I'd like some critique as to whether or not my general structure makes sense, and if you have any optimization tips for me that would be greatly appreciated. The game performance hits whenever I am holding the fire button and spawning lots of bullets at once, but as soon as the key is let off they all move smoothly. So it's not the sheer number of bullets, just something about the way they are getting created.

Thanks for any input, sorry for the crazy long first post.

Oh yeah, and there are no instructions in the game, keys are:

Space - Fire
Arrows - Movement
Tab - Change bullet pattern

[Lexsym]

I love the "explodey" bullets =p.

Also, in your player.lua file, why not just use love.keypressed() for detecting if the tab key was pressed or not?

Incoming Bullet Hell Shooter!

[HazeAI]

Thanks Lexsym! I had wondered about what the functional difference between between love.keypressed() and love.keyboard.isDown(), now it makes sense, I'll definitely switch that out this afternoon. I thought it was weird to have all that extra code just to make it so that I could cycle through shot types at a reasonable rate.

[Lexsym]

You're welcome, glad my input was useful

Personally, I use love.keypressed() and love.keyreleased() for everything, even moving players. I do something like this:

Code: Select all

function love.keypressed(k, u)
if k == "w" then
player.isuppressed = true
elseif k == "s" then
player.isdownpressed = true
end
end

function love.keyreleased(k, u)
if k == "w" then
player.isuppressed = false
elseif k == "s" then
player.isdownpressed = false
end
end

Not sure how efficient it is to do that, however, having multiple players it sure does make it a lot easier for me.

[nkorth]

Cool! Combined with bezier paths, this could make an awesome bullet hell game.

Personally, I use love.keypressed() and love.keyreleased() for everything, even moving players.

I prefer using isDown in love.update for player movement, because the movement is only going to be applied in love.update anyway. It seems like code duplication to set all those key variables.
love.keypressed is very useful for anything that doesn't involve holding down a button, though.

[Taehl]

I decided to put this up as is because it's my first shot at game programming and I'd like some critique as to whether or not my general structure makes sense, and if you have any optimization tips for me that would be greatly appreciated. The game performance hits whenever I am holding the fire button and spawning lots of bullets at once, but as soon as the key is let off they all move smoothly. So it's not the sheer number of bullets, just something about the way they are getting created.

I haven't looked at your code, but I would guess that your slowdown is probably coming from one or more of these potential sources:

1) Global lookups. They're quite fast, yes, but they're considered one of the more "costly" operations in Lua. So if you look up stuff in tables a lot in your inner loops (that is, you say things like "bulletTypes.wavey.movement.speed", for example), you'd slow down some. You can usually fix this pretty easily by making local variables for anything you use more than a few times (locals are faster than globals).
2) Creating new tables. This is also relatively slow. This basically happens whenever your code has curly brackets ( "{ }" ). This is harder to improve, usually requiring different programming techniques to be used (or some kind of restructuring).
3) Function calls. They aren't terribly slow, but like the others I've pointed out, doing thousands of these every frame can add up. These happen pretty much whenever you use parenthesis.

These can often happen together. For instance, the rather simple code "local bullet = {img=bulletTypes[type].image, x=x, y=y, time=love.timer.getTime()}" includes all three of the above!

[HazeAI]

Thanks Taehl, I have a question about general structure and if you think there is a way that I could make this more efficient. At load I make a table called bullets that is empty and a table containing functions to update every bullet contained in bullets. Then everytime I create a bullet I create a table for the bullet and again a table containing it's functions as well. Is there anything super inefficient going on there? I haven't used local variables yet so I will see where I can use those and maybe that will help performance.

[Taehl]

Doesn't seem terribly inefficient to me, no. The one part that makes me wonder, though: "Then everytime I create a bullet I create a table for the bullet and again a table containing it's functions as well.". Why do you create individual function tables for each bullet? Couldn't you just have one set of functions which works over every bullet?

[HazeAI]

Brilliant, thanks Taehl! I'm not accustomed to having to make metatables so that didn't even occur to me, I'll restructure so that the metatable only get's created once.

[Taehl]

You don't even have to use metatables if you don't want to. You could do something like:

Code: Select all

-- you could have a different function for each style of movement. Let's make this one for bullets going straight in one direction
function bulletUpdate(self, dt)		-- using a "self" parameter for OO-style calling
	self.x, self.y = self.x + self.xv*dt, self.y + self.yv*dt
end

-- make a table with some random bullets
function love.load()
	bullets = {}
	for i=1,20 do
		bullets[i] = {
			x=math.random(200,600), y=math.random(200,400),
			xv=math.random(-50,50), yv=math.random(-50,50),
			update = bulletUpdate,	-- reference that bullet's movement function
		}
	end
end

-- update all the bullets using the same function
function love.update(dt)
	for k,v in ipairs(bullets) do
		v:update(dt)	-- call each bullet's update function (note the colon, that's important - it sends the "self" parameter)
	end
end

I'm not saying you /have/ to do it like this, but it's an option.