## crowd sourced game - organizing files and objects

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
sanjiv
Citizen
Posts: 85
Joined: Mon Feb 27, 2012 5:11 am

### crowd sourced game - organizing files and objects

I'm part of a small group of newbies who want to create a Mega Man style game. Or rather, we want to create lots and lots of MM-style games to cultivate the skill in the community, and put into practice a lot of the stuff the community, until now, have only talked about. The idea was to implement an 'interchangeable parts' style system where different members could focus on and take responsibility for small aspects of the game--Eventually. Now I'm just learning how to use LOVE, and creating a framework for the group to eventually use. Lots of pressure. I understand we don't have do everything all at once, but I've found that organizing the code and creating our own libraries was just as hard as figuring out how to make the mechanics in the game work.

I need advise on how to compartmentalize the project; what objects to create, and what should own what. The ultimate goal would be to create something along the lines of MegaMan ZX, which features

- simplified, weird physics.
- changing between various forms that each have unique player characteristics and abilities.
- player controls and button inputs that do different things for different forms.
- various enemy units
- various levels with different sub parts
- different types of collision zones and areas (ie. zones in which pressing 'up' will trigger a conversation with a near by NPC)

In addition to the basic structure, I'll take any advise I can get on using 'require' across various folders, or calling images from various folders.

My first thoughts

I believe one file should be about key-mapping.

Another folder should contain images and information for each menu screen

I believe each form should have its own folder that contains (1) sprites for it (2) information on how it will behave and be controlled. So it will contain information on detecting user inputs, as well as directing how those inputs impact the game world. I've done this for single forms, however, and this gets quiet cumbersome.

Enemies, NPCs, and other interactive game elements should have their own images and information so that

(continued) Levels can spawn them within it. I don't expect that each level needs its own folder, but maybe doing that would be smart.

Party member
Posts: 100
Joined: Mon Dec 12, 2011 8:44 pm

### Re: crowd sourced game - organizing files and objects

Well let's see...

The individual character.luas could be like

Code: Select all

function guy_load()
end
function guy_update(dt)
end
function guy_draw()
end
then you just add a lil

Code: Select all

require'path/to/guy.lua'
end
function love.update(dt)
function guy_update(dt)
end
function love.draw()
function guy_draw()
end

For the different folder thing, a character's lua could be like:

Code: Select all

function guy_load()
player=love.graphics.newImage('path/to/player.png')
end

Just make sure that each guy has his own variables. Hope that helps.
Losing a friend's trust is the fastest way to lose a friend, forever. FOREVER!

tsturzl
Party member
Posts: 161
Joined: Fri Apr 08, 2011 3:24 am

### Re: crowd sourced game - organizing files and objects

The individual character.luas could be like

Code: Select all

function guy_load()
end
function guy_update(dt)
end
function guy_draw()
end
then you just add a lil

Code: Select all

require'path/to/guy.lua'
end
function love.update(dt)
function guy_update(dt)
end
function love.draw()
function guy_draw()
end

For the different folder thing, a character's lua could be like:

Code: Select all

function guy_load()
player=love.graphics.newImage('path/to/player.png')
end

Just make sure that each guy has his own variables. Hope that helps.
I agree somewhat with this. However I think its better to just do it objectively with tables, this way you could make an array full on different characters that you could swap between in real time, not to mention its good practice. This way you can keep your players health, x/y coords, image object, and other relative variables inside your player object.

If you want to be able to edit the player objects, save the objects, and reload them later. You could serialize the object, then dump it to a file.

So something more like this:

Code: Select all

actor={}
self.img=love.graphics.newImage(img)
self.x,self.y=0
self.hp=health
end
function actor:update(dt)
end
function actor:draw()
love.graphics.draw(self.img,self.x,self.y)
end

This would then be the base object you can create new character's with, or even enemies.

It would work especially well with enemies you could make a inherent object of actor for the enemies, then add them to an array. In the love.update() function just iterate the list and call each update function, same for love.draw() only calling each objects draw() function instead.

The way I see it, you should create objects that other objects can inherit, this way objects are some how relative and you can do simple iterations to draw everything to the screen. Or say every map object in the game has a collision callback function, this way you don't have to be careful with which objects you can and can't call, and you don't have to worry about other objects having differently named callback functions. It saves you a lot of frustration later on. Its also easier to read, since you'll know objects that inherit another object probably have a similar purpose.

sanjiv
Citizen
Posts: 85
Joined: Mon Feb 27, 2012 5:11 am

### Re: crowd sourced game - organizing files and objects

I absolutely agree.

At the moment, I have player.currentState={} which contains stats like health, move speeds, images, etc. I expect to change this as the player takes on different forms that have different abilities. How would I alter player.currentState to take on certain (but not all) values of player.IceForm? My current inclination is to simply put the following equations in a function: player.currentState.image=player.iceForm.image etc. Is it as simple as that?

But different forms will also respond differently to button inputs. Would I replace player.currentState.update() with player.iceForm.update() in the same style, and have all the button and movement functions in that single function ()? I guess this isn't all so bad as long as I can eventually build a single swapPlayerForm() that will carry out all these changes.

The resulting issue then is of file organization. Would the best practice be to have each form contain its own folder, and then require 'iceform/draw.lua' in order to get the images and animation sequences for the form, and then have 'iceform/somethingElse.lua' to describe other aspects? I guess it'll just take some experimentation to figure out the best way to divide up the forms abilities.

kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Contact:

### Re: crowd sourced game - organizing files and objects

sanjiv wrote:But different forms will also respond differently to button inputs. Would I replace player.currentState.update() with player.iceForm.update() in the same style, and have all the button and movement functions in that single function ()? I guess this isn't all so bad as long as I can eventually build a single swapPlayerForm() that will carry out all these changes.
This is the scenario for which I created stateful.lua. Well, this and Game state management. Give it a look!
sanjiv wrote:The resulting issue then is of file organization. Would the best practice be to have each form contain its own folder, and then require 'iceform/draw.lua'
I think that might be a bit too much. Probably having player/iceform.lua and player/sandform.lua will be enough.
When I write def I mean function.

tsturzl
Party member
Posts: 161
Joined: Fri Apr 08, 2011 3:24 am

### Re: crowd sourced game - organizing files and objects

I don't think sanjiv needs a state manager, at least not for what he's doing here. He's creating different states/forms that the player can take in gameplay.

I'm assuming player is a table full of all the different characters? I'd give them all the same methods(update, draw, init, takedmg, attack,etc) this way they can be called the same way later on. I also assume player.currentState is your current object, so you can reference like so player.currentState=player.iceForm and then the rest of your program only needs to call player.currentState?

If so it seems you've got a pretty good handle on what you're doing.

You don't need to override player.currentState's update method once you replace the player.currentState object with player.iceForm, because player.currentState then takes on all the methods(and the entire object) of iceForm. And yes you can do "player.currentState.image=player.iceForm.image" that will work fine. If you have different key bindings for each of these you can check the keypress in the update function or you can make a method to put in your keypress call back function.

For example in each object you can make a method called "keypress(key)" and do this in your call back:

Code: Select all

function love.keypressed(key)
player.currentState.keypress(key)
end

Sometimes you'll need to use callback keypress instead of love.keyboard.isDown() because love.keyboard.isDown() is often placed in your update method, therefore checking every frame and taking action every frame(often creating odd bugs).

Then each player object can react to the keypresses differently using there own method. Its a pretty niffty way to go about things.

As kikito was saying, you are managing states of a game object, but not the entire game state. I think its simple enough to create your own table to handle states of a single object rather than including a library that is more focused on game states not player states.

I'd say you should consider serializing your player table to a single file. Then all your players are saved in a single file. If you want separate files you could iterate through the player table and serialize each form into its own file. I guess you could create separate lua files for each player state, however you won't be able to save any changes, to that lua file, that you make in game to your character(perhaps you don't need that?). There are ways to serialize image data, therefore all your needed data is in a single file, no need for folders.

kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Contact:

### Re: crowd sourced game - organizing files and objects

tsturzl wrote:As kikito was saying, you are managing states of a game object, but not the entire game state. I think its simple enough to create your own table to handle states of a single object rather than including a library that is more focused on game states not player states.
You got it wrong.

The library is called "Stateful" - not "GameStateManager" - for a reason.

Its main objective is managing states of any kind of object. I think you got that idea because lots of people use it just for game management, because it is very convenient for doing just that. But the library can (and is designed to) manage states in general.

It doesn't have any code dedicated specifically to handling Game classes. It can handle players, enemies, gui elements or bullets just as well as it handles Game states.

IMHO it will help sanjiv do some of the things he wants to do with the player more easily than doing it manually. You can find an example for an Enemy class with different states on its readme.
When I write def I mean function.

tsturzl
Party member
Posts: 161
Joined: Fri Apr 08, 2011 3:24 am

### Re: crowd sourced game - organizing files and objects

kikito wrote:
tsturzl wrote:As kikito was saying, you are managing states of a game object, but not the entire game state. I think its simple enough to create your own table to handle states of a single object rather than including a library that is more focused on game states not player states.
You got it wrong.

The library is called "Stateful" - not "GameStateManager" - for a reason.

Its main objective is managing states of any kind of object. I think you got that idea because lots of people use it just for game management, because it is very convenient for doing just that. But the library can (and is designed to) manage states in general.

It doesn't have any code dedicated specifically to handling Game classes. It can handle players, enemies, gui elements or bullets just as well as it handles Game states.

IMHO it will help sanjiv do some of the things he wants to do with the player more easily than doing it manually. You can find an example for an Enemy class with different states on its readme.
It really seems like what he's doing is actually easier, IMO. Really the concept isn't that hard to grasp... Using stateful.lua just seems like another library to learn.

kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Contact:

### Re: crowd sourced game - organizing files and objects

tsturzl wrote:It really seems like what he's doing is actually easier, IMO. Really the concept isn't that hard to grasp...
I was under the impression that he was not yet *doing* anything, but thinking about ways of doing things, and asking questions.

Even if megaman only had one kind of state (wood, fire, etc), I thing using Stateful would help.

But it gets better; he has several states. Not only he is "using wood power", but he can also be "jumping", "sliding" at the same time. In some cases he's also getting hit. So you would need not one, but 3 or more variables to control megaman: currentPower, currentAction, and gettingHit. Code using those variables will grow hairy really fast once you have enough - even if you make it as clean as possible, you will end up with difficult to debug - mainly because of nested ifs.

Stateful provides a couple tools to deal with this complexity: first, states are stackable (so megaman can be "jumping" and "wood-powered" at the same time), but the code has no "ifs": instead, methods are overriden in certain order.

Second, one state can "inherit" from another, so if two states are "mostly the same except from one bit" the code isn't duplicated; when you change the parent, you don't have to remember changing the child.

Finally, there are callbacks that are automatically called every time a state is entered/exited (or pushed/popped from the state stack). If you need some initialization code to be called every time that megaman changes from one other power to "IcePower", Stateful makes sure that that method is called; you don't have to remember it.

I'm not saying it is the ideal solution, but I'm certain it's worth considering.
tsturzl wrote:Using stateful.lua just seems like another library to learn.
I don't know what to make of that phrase. You seem to be implying that using libraries, or learning to use them, is a bad thing.
When I write def I mean function.

teh8bits
Citizen
Posts: 52
Joined: Fri Mar 09, 2012 9:18 pm
Location: The Matrix
Contact:

### Re: crowd sourced game - organizing files and objects

I know I'm new here and to Lua in general, but wouldn't it just be easiest to have a few booleans and avoid nested ifs? I know from Java experience it wouldn't be hard to make some cut off boolean so if he gets hit the next tick he would stop firing and start getting hurt.
Better yet just have in the firing animation method if ~= hurting

### Who is online

Users browsing this forum: No registered users and 6 guests