From project designing to code implementation

[Doki Doki]

Heeeeeey lövers!.

This thread has been written by two brothers, so that's why it is in third person. Let's go:

We are really, really, really new to lua and löve.

Let's say we wanted to make a «metroidish» platformer with the following actions:

Hang somewhere:


Hit enemies (direct physical contact):


Use a grapling hook:


Shoot projectiles:


Pick up things and throw them:


Break the world or some world elements:


The images are «mockups» to explain the actions.

Also, we have to consider, the characters movement and their collisions.

Once said that, we wanted to ask for advices, hints and/or tips to start with it,

we mean, choosing the most suitable physics/collision-detection system, how to organize the whole project (files, classes, etc), setting it up for network multiplayer and so on.

We've read, that people make their own physics and collision system but we just don't know how to handle that amount of cases in the code (in a polite way).

We've read and implemented the wiki tutorials but, they feel «simple» comparing to the idea of the game we would like to do, although they are really good for starting.

After reading about several libraries like ATL, STI, BUMP and looking at some .love examples around the forums, we still don't get the general concept and the other things mentioned above.

Another thing, for example, is that we've read some people saying if the game is simple, you have to code your own collision system, but after checking what people say is simple, is not as simple as we thought, it confuses us.

We are at the IRC as well, but the questions we have, cannot be answered in one line and it's a good thing (at least from our point of view) to have a thread like this on the forums.


We want to make it for learning, but we want to make it well, that's why we want to make a project with this «features».

We are not asking for other people to make our game, we need some guidelines to do it (after all, we can bother on the IRC for code issiues ).

So if someone has the time, the patience and the will, we'll going to be very glad and thankful!

[OttoRobba]

Hey there.

I'll try to break it down as best as I can.

Simpler physics systems (AABB for example) tend to use less system resources and, in a few ways, are less complicated than more full featured alternatives if for no other reason that they can pretty much be done in a single function.

Code: Select all

--We check to see if box1 and box2 are overlapping. If they are, we return true so that we can choose what happens accordingly.
if box1.x >= box2.x and box1.x <= box2.x+box2.width and
box1.y >= box2.y and box1.y <= box2.y + box2.height then
    return true
end

Really simple and works great for many kinds of game. When you want objects to bounce around and react in a realistic way, however, it is probably best to go with a more full featured solution, like box2d (which is the engine implemented in LÖVE). It works great and is not necessarily hard but it takes a bit more time to get used than the simple block of code I showed above.

we mean, choosing the most suitable physics/collision-detection system, how to organize the whole project (files, classes, etc) and so on.

Box2D, as explained above. For the organization of the project, I personally like having the following structure inside my game folder:

art/ --further subdivided according in UI, character or what is needed by the game
sound/
libs/ --I use it for external libraries/modules, this way I can keep them separate from things I've developed and avoid clutter
modules/ --Here I put the game modules for my game. I have a module for generating buttons, a timer, etc...
states/ --Different screens/game states go here. Victory screen, defeat screen, credits, start, game, etc...
main.lua
conf.lua

Mine is a bit more complex because of MoonScript but this is essentially it, if I were using vanilla Lua.

We've read and implemented the wiki tutorials but, they feel «simple» comparing to the idea of the game we would like to do, although they are really good for starting.

Try to see the ideas for the simplicity that they have. Breaking scenario, for instance, could easily be done with a tile system. You store a variable in each tile saying how much health it has left. Depending on how damaged a tile is, it changes the image to correspond to the damage. When it takes enough damage, it changes into an empty tile. If you want a more detailed breakage of the scenario, it does get more complex - you could calculate polygons to hide parts of the geometry or some other technique that I don't know. If you google it, you are bound to find more information.

hang from edge

When the character bumps into a wall, you can have the tile she is bumping into check to see if there is a tile above it. If there isn't, it is an edge tile and then you momentarily remove gravity from the character and change to a "holding the ledge" sprite.

After reading about several libraries like ATL, STI, BUMP and looking at some .love examples around the forums, we still don't get the general concept and the other things mentioned above.

Think of libraries as shortcuts to a goal. Suppose you need a timer but don't know how to create one (or you simply don't have the time). You download someone's library and acquire that functionality.
"But if feels to simple".
In a way, it is. But it is a good kind of simple.
For example, this is how I use my timer:

local timer = require "timer"
timerFight = timer.new(99) --I'm starting a new timer, I'm naming it timerFight and setting it to 99 seconds because Street Fighter.

function startFight()
timerFight.start()
allowMovement()
playSound("Fight!")
end

function updateFight(dt)
if timerFight.isZero == true then stopFight() end
end

My advice with libraries: go slow. There is a big temptation to just grab everything that seems useful and tack it on a project. Don't. Try to visualize what you need, when you need it and if you need it. The ones that you do get, take a bit of time to familiarize and learn. For instance, I'll at some point need help with tweening and I know there are at least two great libraries for that - but I'm not gonna install them right now because I'm not at that point yet.

hitting the enemy (physical contact)

Just check the distance between the two characters. If it is less than the reach of the attack, queue the damage resolution functions.

shooting an enemy

Using Box2D for resolving the part of physics, the rest is easier. Simplest way I can think off is just have them added to a table when the player does the action and destroyed when they hit something or get off screen. Ideally, you would reuse the same bullets but one step a time.

Grappling hook

There is likely a better answer by someone more proficient in Box2D but you simply have it spawn and move in an angle.
Set a variable for reach. If it collides with something within that reach, change it's physical properties so that it acts as a fixture.

I hope this helps!

[bdjnk]

We've read, that people make their own physics and collision system but we just don't know how to handle that amount of cases in the code (in a polite way).

It's mostly the math that trips people up. They instinctively avoid it and try and do things with code instead (that doesn't even make sense, but it's true). Your best friends for this type of code, are pencil, paper, and a basic calculator.

After reading about several libraries like ATL, STI, BUMP and looking at some .love examples around the forums, we still don't get the general concept and the other things mentioned above.

I definitely recommend STI. It is, as the name states, simple.

Another thing, for example, is that we've read some people saying if the game is simple, you have to code your own collision system, but after checking what people say is simple, is not as simple as we thought, it confuses us.

There are trade-offs.

With box2d (or the like) things often will not work as you expect them to, and you will curse the day realistic physics was invented. On the other hand, you will have the power of a realistic physics engine behind you, and if you like guess and check style coding and searching the Internet over thinking deeply, this is probably a better choice.

Your own system will be buggy and each fix will just lead to more bugs, and you will curse the day math and conditional statements were invented. On the other hand, you will learn a huge amount, and if you like getting into the nitty gritty and having things work exactly as you intend, this is probably a better choice.

[T-Bone]

Make your own physics. You'll learn a ton and you will eventually be able to tweak it to work exactly like you want it to. It's going to take a while to get something that works well but it'll be worth it. My best advice is to just start and do what you can, and the figure stuff out as you go along. We at the forums here will be more than happy to help you with any specific questions you may have. And don't be afraid to throw out code and start over if you feel it gets too complicated, in that case there's probably a simpler way to solve the problem.

Some general tips:
Try to structure the code in such a way that each script solves a specific problem. That way, it's easy to know what part to rewrite when something goes wrong. One script might handle character movement, one might handle input (from various sources), one might handle rendering of the world, etc. It's a very basic idea, but it's very easy to forget once you actually start coding, and that leads to spaghetti code very quickly.

[Doki Doki]

Thanks to all, sorry for the delay but we have been outside all the weekend.

@OttoRobba, thank you so much for all that tips, now we can figure out how the game will be structured and how to implement mostly all the things. We liked your approach of how to divide the sections of the game and how to accomplish the actions we required/wanted to do so much .

@bdjnk thanks for your reply, we were dubting on whether use ATL or STI, but as long as ATL is no longer maintained and STI is quite pretty, we will follow your advice and make a good use of it

@OttoRobba, @bdjnk, @T-Bone we will start making our own physics to get in touch with lua and LÖVE<3, but we do not discard to use some of the great physics libraries available for LÖVE, such as, BUMP 2.0, HC, or love.physics in the near future.

Finally, thanks to all of you -again-, that encourage us to continue learning game developement and, when we are much more confindent with lua, write some great libraries for LÖVE too, who knows!