Music and solid ground

By jlnr (dev) Date 2014-01-03 09:14

Does the first issue happen with all music files? What file type is it?

Jumping: See how the CptnRuby.rb example chooses which frame to draw for the characters. (Have you found the examples? They're hidden inside the gem folder…)

By Jeytas Date 2014-01-03 11:53

Hello,
thanks for the answer.
1.) It happens to all Music files. They have the suffix .wav because .mp3 doesn't seem to work!

2.) I meant that a bit different. I meant how I can detect whether the player is stading on a solid ground or if he is in the air.

By jlnr (dev) Date 2014-01-03 12:25

1) You can use the free "Audacity" tool to convert the .wav files to .ogg - it's like .mp3, but without the licensing trouble :)

2) Oops, you are right, the draw method does not do this. However, the would_fit method can check for this. What it does is to see if the top (head) and bottom (feet) of the CptnRuby player collide with the map. You can add this line to the Window's update method to see it in action:

self.caption = "On floor? #{not @cptn.would_fit(0, 1)}"

By Jeytas Date 2014-01-04 22:50

Thanks for the answer. But I still didn't get how to use the .solid? Thing. When I tried to do the same thing in my test game, it says update': undefined method solid?' for #<Block:0x27eb0e0> (NoMethodError)7

Marvin

By lol_o2 Date 2014-01-05 10:26

solid? is a method you define on your own. Basically, solid? is a method that returns true or false, depending if map is passable in given point (true if there's obstacle).

If you want to check if block is solid in some point, you have to add solid? method to Block class in your game.
Example (for 32*32 tiles):

def solid(x, y)
  x.between?(@x, @x+31) and y.between?(@y, @y+31)
end

Will return true if given x and y is 'inside' the block.
Note that checking each tile this way isn't efficient for bigger maps.

By RavensKrag Date 2014-01-09 07:55

I'll try to answer your second question. Not just in terms of giving you a path to the solution, but walking you through the process of developing your own solution.

What does it mean to be on the ground? What qualities would make that state different from flying?
The most obvious one is that if you're on the ground.
Another way of saying this is that you are colliding with the ground.
How do you know you're colliding with something?
That happens when you're pressed up right next to it.

In games there's two main ways of solving this problem:
You can figure out what "right next to you" means.
This generally means figuring out your position, and then the position of the thing you're possibly colliding with.
When the distance between the two is small, then they are adjacent.
Tile-based games make this concept easier, because you can simplify this into just checking the adjacent tiles.

The other way is the way physics engines work. It's more complicated, but much more powerful. You don't necessarily need to know how to implement a system like this, just understand how it works, and find a physics library to use.
You need to realize that every game is a series of discrete states, much like the separate frames in an animation. This means all objects must have a definitive position on each frame. Most of these positions are good, but you never want to display a frame where one object is inside of another. So, you move the objects in your game a little bit each frame. Then, if your logic generates a frame where two objects would overlap, you move them apart BEFORE you go to actually render that frame. Thus, the player never sees the misstep. It is only something momentarily stored in the game's internal state.
The first part is called collision detection (fairly easy) and the second is collision resolution (a little trickier).

A bit long, but I hope that helps.

By Jeytas Date 2014-01-09 14:33

Hey,
thanks for the answer. Sorry, I couldn't answer because I had school. So I tried your first method (The one where I detect whether I'm near the solid object) I spent the last hours to create a little game that does exactly (or at least it's similar). I made it with TexPlay, so if you want to test it, it would be better if you install texplay. Here's the link to the GitHub Repository: GitHub Repo
There probaly still some errors left, but this is just a prototype and I would really appreciate it, if you would take a look at it and tell me if the method is ok.

Marvin

By jlnr (dev) Date 2014-01-09 23:04

I am not sure if this line is always true or always false, but it is certainly not doing what it's supposed to :)

if @y >= @y -= 20 then

I wish I had time to explain the CptnRuby example, I think it's a pretty good example of simple collision detection. I have written a whole unpublished game with a friend in its style :)

By RunnerPack Date 2014-01-10 00:11

Not exactly collision related, but somewhat on-topic...

If you ever want to graduate to proper gravity simulation (for jumping) without learning a physics engine (like Chipmunk), you can't beat Hugo Elias' page about modeling physical phenomena: http://freespace.virgin.net/hugo.elias/models/m_main.htm

It's not much more involved than your method, but the results are far more realistic. Here's a quick'n'dirty implementation to get you started: https://gist.github.com/runnerpack/8344513

Note the @maxjumps variable. Set it to something greater than one to allow jumping in mid-air (once you collect the right power-up, of course ;)

@jlnr: it's always true, and it always subtracts 20 from @y :)

By RavensKrag Date 2014-01-10 08:34

Ok, I'm gonna give you some tips on code organization and style. I'll try to come back to the actual content of your code tomorrow, as it's pretty late where I am right now, and I should be getting to bed soon. Just some stuff I wish I had learned sooner. Maybe you already know this stuff, and you're just rushing the code a bit to prototype fast.

As an organizational tip, I personally recommend copying Gosu's convention and giving each object you create #update and #draw methods. This will make it clear what phase of the game calculation you are in. I recommend never getting mixed up between what is rendering / display logic and what is world state logic. You seem to be confusing the two a lot in your code, which can be dangerous if you're not careful.

In a similar train of thought, separate files for separate classes can be helpful, as you can easily jump to different classes by switching files.
Keeping everything in one file is sometimes really great for prototyping though.

You're creating a bunch of variables in Window#initialize that all start with @star. That's a pretty good indication that you should be creating a new class called Star.

For one-liners with if statements, I think that
run_this if condition
makes for cleaner code, as opposed to the
if condition then run_this
style you're currently using. It's just a matter of taste though, as both do the same thing.
But the style I propose only works for one-liners, while the style you're currently using works for multi-liners as well, so it's more versatile.

You don't seem to understand what attr_reader / attr_accessor does, as you used it in one place, and not in others. I think that's a question that has already been answered better in other places on the internet, so I'll let you figure that out yourself.

One last note:
Don't be afraid to run your code after each small step of implementing something new. That will allow you to see what works and what doesn't. It looks like you wrote this code all in one go, without running it. I say this because you've defined a method #button_down(id) inside of Window#update. I'm not sure if that's even valid ruby syntax.

By Jeytas Date 2014-01-10 12:19

Hey,
thank you very much for your answers :) They are very detailed and I really appreciate it, that you really take your time to write that ;)
What do you mean by giving each object update and draw methods? Do you mean

class Player
def initialize
end
def draw
end
def update
end

Do you have any good Tutorial or example that I can find how I can use rendering / display logic and world state logic better?

I will try to use more files, but the problem is, that I recently found out how to do so (because load 'script.rb' doesen't really work).

Yea, I got very confused. I mixed up some variables, because I meant to make some Stars but I decided to stop that and I started making Traps ... But I forgot to rename the variables

In my oppinion using if condition then run_this is good. But I will try to make one line if statements in the format run_this if condition (Because I didn't know that that works) ;)

I know what they are used for but I think I didn't really get what they do... I will try to learn that ;)

I always run my code to assure that it runs correctly. I know that a method within a method isn't really good, but where should I put the def button_down(id); end method then? I thought that it has to get updated all the time?

Misc:
The problem with my programs is, that I always to things much harder than they should be and that often ends up in a wrong syntax. I also don't always have the time to learn Ruby / Gosu and that's why I often try things out. The problem about that is, that I may get a working program but it probably is really complicated and has wrong syntax. But I cannot learn all the time, because I have to go to school. But I'm going to search some ruby programs and take a look at them so that I know how to use the syntax etc :)

Marvin

By lol_o2 Date 2014-01-10 20:35

Your Player class structure is good, but maybe update should be before draw as it is called before.
Put the def button_down(id) into your Window class.
You can learn some Ruby/Gosu by looking at the games on Showcase forum. But their syntax isn't always perfect.
I'm making some 'framework', which manages game logic in Gosu and provides various useful features. You can find it <here>. But it lacks some things, like examples and I'm going to make a major update soon.