Adding weapon types

[lilfinn]

Hello, I'm working on a top down shooter to learn more about love and lua. I have the basic game in place with collision, health, ammo, and enemies. I would like to continue upgrading but have run into a few snags.

1) first off I would like to add new weapon types, things such as a "shotgun" where 5 bullets shoot in a 45 degree angle, a "flamethrower" where many bullets are shot in a small angle at close range, a "machine gun" when many bullets shoot out in a line. I know the code would vary for each new type but with the way I have the bullet system set up I am lost.

2) If you try the game the is immediately obvious. As the zombies follow you they group up and form one small dot. You can still shoot at and kill this mega zombie dot but i would like it if they didn't bunch up. I tried to follow some path finding tutorials (http://gamedev.tutsplus.com/tutorials/i ... iors-seek/) but got completely lost.

I know the code is not very good or tidy but I just wanted to jump in a see what I could do, any criticism would be very helpful.

thank,
lilfinn

[micha]

1) Sorry, haven't looked into your code. I suggest you split this up into two steps. First step is to make different weapons. The second step is to manage the various weapons in the game and to keep track which weapon is equipped. I suggest you go for the first one: overwrite your current code and implement a shotgun instead of a normal gun. After that you can think about how to switch between guns in game.

2) Flocking behaviour is the right way to go. Try this very simple approach: At the moment each enemy has one velocity pointing towards the player. Modify this velocity vector by an "avoicance" velocity. To get this iterate over all other enemies and add a vector "away" from them. It should be bigger, if the distance is smaller.
After you modified all velocity vector you will probably want to normalize them such that no enemy can get faster than his maximum velocity.
The modification could look something like this:

Code: Select all

local dx,dy = enemy1.x-enemy2.x, enemy1.y-enemy2.y
local dist2 = dx*dx+dy*dy
dvx ,dvy = dx/dist,dy/dist

dvx and dvy would then be the additional velocity that you add the enemy1.vx and enemy1.vy. It will probably not work out of the box, but you have to calibrate it.

[CaptainMaelstrom]

In my opinion, you're reaching the size project that would benefit from Object-Oriented Programming (OOP) principles.

Right now, you have everything stuffed into one big "main.lua" file. It's possible to make games and programs like this, but eventually most programmers adopt at least *some* OOP tendencies.

Check out kikito's OOP library for LOVE, it's called middleclass:
http://www.love2d.org/wiki/MiddleClass

My advice would be to put player code in a "player.lua" file, your collision code in a "collision.lua" file, etc... and then at the beginning of your "main.lua" type:

Code: Select all

require "player.lua"
require "collision.lua"

etc...

This allows you to find bugs more easily and be a little more adventurous in adding things you're not sure will work.

For advice on your specific question, as to how I would add more weapon types.. I would make a Weapon class, and then have pistol, shotgun, laser, etc.. be instances of that class that could then be put in the player table.

Just my $0.02.

[raidho36]

Actually, no. As it is now, OOP is a bunch of syntax sugar on top of plain imperative programming, so there's nothing benefitical in having it other than having to type in a different way. And provided Lua's implementation, in terms of Löve2d, it's a plain bunch of syntax sugar on top of plain tables and no more than that, in practice the whole difference is having to use colon syntax, which one and only effect is implicit pass of function container table as first argument to a said called function: instead of table.function ( table, value ) you type table:function ( value ), exactly one word less than normal. That's with tables approach, closures approach would have period syntax and theoretically they might be faster for using private fields as locals, but in practice it takes a lot of time to create anything and memory consumption grows a lot, other than that there's no difference.

What you really do mean is modularizing, a completely different story. Programmers have been doing that long before first OOP languages were actually created. The general guideline here is don't just cut-paste your code to a different module unless you're 100% positive it's atomic, i.e. works on it's own. It's not a bad thing to keep everyting in a single file, it's just may be harder to havigate it if it grows too big and is not organized on the inside.

[Robin]

Stop! Nitpick time!

Code: Select all

require "player"
require "collision"

require "hodor.lua" looks for a file called lua.lua in the directory hodor; require "hodor" looks for a file called hodor.lua. Module syntax, bitches!

Thank you, Captain Nitpick!

[CaptainMaelstrom]

raidho: Ah, modular, yeah, that's what I meant. I don't have a formal education in computer science, so sometimes the terminology escapes me. But yeah, it's incredibly helpful for *me* to modularize my programming when it grows beyond a certain scope.

Robin: Thank you! I have gotten that error many times, an easy fix, but good to have the correction for reference.

[Bobbias]

Modularization is probably a good idea. I actually prefer to keep my stuff modular from the very beginning, that way I never have the 1k line long main.lua that's full of random bits and pieces of code that don't belong there.

It wouldn't be hard to split this code into a few files. Maybe something like:

main.lua
enemy.lua
graphics.lua
collision.lua

Though since the source is only 263 lines long at the last end statement, it's not really necessary yet. Still, it helps keep things organized.