(omg, I forgot to login and posted like mr. ?, I post this again and report my previous post, sorry for the inconvenience)
I'm interested in doing a 2D platform game using Ruby and Gosu, and I have already written this code.
I'm quite a noob, using gosu, using ruby and even writing object-oriented code so I'm posting here this early code and reading every comment, correction or suggestion that you post.
This is just a simple platform game like test, a character and three platforms.
Nice! I didn't get to write a game that has "jump-through platforms" until earlier this year. From a player's POV, you should widen the collision box of the player from a point to a rectangle or so :) But it plays nice already.
One function that I found while skimming through the code and which I found confusing:
@x_character_position = character.get_x
@y_character_position = character.get_y
@x_platform_position = platform.get_x
@y_platform_position = platform.get_y
if ((@x_character_position>=@x_platform_position) && (@x_character_position<=@x_platform_position+291)) then
if ((@y_character_position<=@y_platform_position-61) && (@y_character_position>=@y_platform_position-69)) then
if character.get_v_accel<0 then character.set_y(@y_platform_position-61) end
return 1 end
else return 0 end
• Why do you store the positions into instance variables (@)? Are these used outside of this function?
• In any case, this method sounds like it would detect something, but it actually changes something (the player's y coordinate). The naming makes it harder to understand the code.
• There are a lot of magic numbers in there.
• Weird nesting of if/&& :) I think the first two ifs could be merged?
• Why 0 and 1 instead of true and false?
• You should use getters and setters which match Ruby's convention of "foo.x" and "foo.x = ..." instead of "get_x" and "set_x" :) attr_accessor can be used to generate these with one line of code.
Thank you for the quick reply. I read what you wrote and made the following changes:
- I have deleted the @ from the method variables, I really didn't know exactly how this works, but I will read some manuals to learn.
- The two if's are now merged
- Changed the 0 and 1 with true or false
- And now I'm using the attr_reader and attr_accessor (those are great! :D) I didn't know there was something like this, I'm a noob xD
- About magic numbers: sorry but I really don't understand what are you talking about
- And yes, the weird method:
This method is the core of the platform example, but I am not very happy with it. I will explain, basically, what it does is:
First, gets the platform's and character's positions to compare, then checks if the character its in a little area 8 pixel over the platform. If it's there returns true, and sets the character's position on the first pixel above the platform. This last step is to unify the position where the character is standing on the platform. Because it would stick sometimes 5 pixel above, and sometimes 2, or maybe 3. If I reduced this collision rectangle to a single line, sometimes the character passed through the platform floor, so I had to make it a little wider.
Yeah, I know this is a little sketchy.
Also, this function checks collision between the character and a platform, and the game has to call it with every platform in the screen, the platform is an object, and I have coded every single platform. But this could not be done in bigger levels so I must think another alternative.
I have changed the name too, to something like standing_on_platform or something like this.
Anyway, as said before, thank you for replying and for your suggestions.
I'm still looking for any kind of advice to get this thing the best and cleanest as possible.
> - About magic numbers: sorry but I really don't understand what are you talking about
Magic numbers are all numbers that aren't trivial (like 0 or 1) and should be moved out of the computation if possible. By introducing constants for PLAYER_WIDTH or whatever else is involved, the code becomes easier to understand and less of a hell if you ever need to change the size of the player (for example).
Not that I *always* follow this practice, but the quoted function is probably a place where you should :)
> But this could not be done in bigger levels so I must think another alternative.
In my current game I have used a 2D tile map similar to the one in Cptn Ruby, with some added math so it doesn't draw unneeded tiles. To introduce jump-through platforms, I added a method platform_at?(x, y) that checks if there is a platform at the given position. (It will return true only for platform tiles and when y % TILE_SIZE == 0, i.e. only the first pixel line of the platform tile counts.) I then test for that whenever I move objects downwards. That way, I only have to look for a platform in one single place while I move the player. (Everything except the platform part is oversimplified, actually, but you get the idea :) )
In any case, I would seperate the logic for testing for a platform (which doesn't change anything) from the code that meddles with variables.
If you just keep on working and growing this game, you will inevitably find out what kind of way you should organize your code to keep it maintainable :)
I have made some improvements this afternoon, if someone wants to take a look here is the new version.
Now the map is loaded from a file, and the platforms have borders
Edit: No friends at night on IM, programming night.
Now I've added tiled background and scroll. It's cool because the game could be resolution independent. It only changes the field of view.
Note that it only weights a few kbs, I will try to keep it as simple as possible.
I've also recoded many things, like, the platform or backgroud stuff, are more "dynamic", if you change the platform tile size externally with an image editor, the collision and drawing on screen will keep that on mind, the same for the tiled background, no matter what the size of the image or the screen is, it fills the background properly.
I still got many thinks on mind, I will post more advances.
PD: The code is starting to get a little messy
Nice improvements,Keep up the good work!
I haven't taken a look at the source again, but gameplay-wise, I think you should work on the player's physical width next. Basically, all you have to turn the check into two 'and'-ed checks at the sides of the player. This will also make it look more realistic if you ever add fully solid walls.
I like the look of the platforms :)
Another new feature, moving platforms, and as I implemented it I'm going to make some conveyor belt (it's really named like that?) and stuff like that.
The first thing I have to recode is the collision and standing on platform stuff, as jlnr said, the player's physical width is not very well done, and also there is a new problem with the vertical moving platforms (if you don't see it try jumping a few times on them).
But I'm quite happy, because I'm doing this as fast as I thought, and I hope I can finish it before my exams.
I thinks it's also ready to start thinking on the game concept, art stuff, level design and that. So if you people know some kind of community where can I ask for recruiting some free artists ,level designers or just people that want to help It would be cool.
I was thinking on some original concept for a platform game, not another mario clone, and I really like the Lucasart's Night Shift oldie concept (gameplay video available on youtube), which presents another point of view for a platform game, I dunno, I haven't decided yet.
Anyway, thanks for the replies and support given here. I will come back with new stuff!
This thing about the collision and platform standing stuff is giving me more problems than I thought, so lets see if someone can give me a clue about this.
So far, I've already solved all problems with static platforms and almost with the moving, but I have not tested everything, so new problems can appear. The problem I have already encountered is the vertical moving platforms which are moving FAST. The character always pass through them, this could be a minor problem, the easy way to solve this is not to place fast moving platforms, but anyway, it would be cool if I could solve this.
Now here it is, the collision mess explained, I have attached an image with the colored code an some numbers referring to highlighted blocks.
1.- These are the function character's data, it uses the X and Y position and width and height as-well, the X and Y I'm not sure what part of the image are, but I suppose that are placed in a corner. The Width and Height are the current character's image width and height.
2.- These are the function platform's data, X and Y position and the tile width, which is the current image's width.
3.- This line right here calculates the total platform size, it multiplies the size (number of tiles) by the tile width
4.- Now, this line, it's supposed to get the tile's height, it is multiplied by 1.5, that's because, if not, the character would stand in the middle of the platform. This product could be done after while placing the character in 8.-, but I placed it there.
5.- That's for none existing platforms size 0 = no colliding with them
6.- Another problematic part, this calculates if the character is on the platform, referring to it's X position, this causes the player's physical width that jlnr posted, I have tried to fix this but I always get strange results.
7.- This is the main problem for me, it calculates if the character and the platform are colliding referring to their Y position. The character is just a point (x and y position), and the platform too. So the chances to get those two points at the same time colliding are too low, so the character used to pass through the platform. That's why I introduced the +12 at the end. This makes the platform collision rectangle 12 pixels tall, so now the character don't pass through. This value it's arbitrary, I have tried different numbers, if it's too low the character pass through the platform some times, if it's too high the character sticks too the platform too fast creating an awful effect.
8.- And finally (sigh), the last part. This sets the character's position on top of the platform if it's v_accel is negative, that means that makes the character stand on this if it's going down and returns true to indicate that there is a collision.
As you can see there is some shitty code here, I will try to fix this or at least search for some general platform game programming info to deal with the platform issue.
I also attach the last code version.
Greetings and sorry for this huge post xD
Something I don't understand is why you subtract the platform's height in (7). Does the height matter? Isn't the platform, physically, just a 1px wide line from its (left, y) to its (right, y), and the player's height should be subtracted?
Also, you should be clear at all times what character_x/_y means (top left corner/middle center/bottom center, …) :) Or maybe add methods for character.bottom, character.top etc...
For moving platforms, I have never implemented them, but I think I would give in and give the player a link to the platform he's standing on and vice versa, so the platform can adjust the player when it moves, and the player can "unregister" himself when he jumps off it. Uglier (IMHO), but I'd guess that most games actually do it like that ;)
Keep a list of moving tiles separate from the list of other tiles. Keep an instance of a moving tile in the character object. check to see if the character is on a tile or moving platform. If it is on a platform, set a flag onMovingPlatform to true and store the reference of it in the character and then use that reference to base your calculations on whether or not to move up with the platform or left and right with the platform. This does not mean disregard the other tiles in the game. In fact, you'll need to do two updates for collision: the tiles and moving tiles.
hope that helped. :)
Thank you all, I have solved the width problem quite convincingly I think, and almost all passing through problems, but not 100%.
Now I am trying to recruit some graphical artist through deviantart and I have created a free forum (http://monsterfactory.freeforums.org
) to get the game development stuff tidy.
I also have another question, for the game menu and that, I would like to get the code split in some files, like a C or a Java program, is this possible? Cause I can't find anything about googling o_O
>I also have another question, for the game menu and that, I would like to get the code split in some files, like a C or a Java program, is this possible? Cause I can't find >anything about googling o_O
Yup. I posted a small game/tutorial which uses one file (actually one class) for each screen: http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=509
Thanks! I will remember that!
I asked for graphic artists on deviantart and pixeljoint, but I had no much luck. So I have done many graphics myself (some of them stink).
I have also added more stuff like a background wall or an animated background, if you play for enough time you will see how the night ends. Thats because I want the levels to take place at night and the player should finish the level before the sun rises.
Anyway, not big changes and the collision stuff is broken again due to new player's sprite size but I will fix later.
Powered by mwForum 2.29.0 © 1999-2013 Markus Wichitill