Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411508 Posts in 69374 Topics- by 58429 Members - Latest Member: Alternalo

April 26, 2024, 09:16:36 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsyp (working title for a Ruby platformer)
Pages: [1]
Print
Author Topic: yp (working title for a Ruby platformer)  (Read 2302 times)
alltom
Level 0
**



View Profile WWW
« on: November 15, 2010, 01:08:33 AM »

The "Ruby(game) or Python (pygame) devs?" thread inspired me to actually try making a game for once. I'm an okay programmer and a terrible artist, but we'll see.

yp is going to be platformer where you slice the enemies in your path with a cool sword, or something equally great. But for now you are just a Mario sprite in space.

I'm making this in Ruby using the gosu library. I'm developing on OS X and I have no idea about Windows compatibility yet (and I'm not even sure if I have a Windows install anywhere right now), but I'm pretty sure all the libraries I'm using are supposed to be cross-platform. Smiley I'm imagining I won't get many playtesters for anything that doesn't run on Windows, if not a browser.



I have a bunch of sketches of various levels and things, but first I'm interested in getting some good controls. In anticipation of some of the mechanics I'd like to use later, I'm mapping keyboard presses to forces applied to the player in a Chipmunk physics sim.

I associate physics simulations with really floaty/disconnected controls, but since I'd like something pretty fast-paced, I've spent a lot of time trying to make sure this game isn't like that. That's pretty much meant having a bunch of physics constants that are really high. Concerned I didn't think that'd work, and several iterations ago I was convinced it wouldn't, but I seem to have layered enough hacks that it actually feels pretty nice (walk/run speeds, less air control in the direction opposite your initial direction, fine control of jump height, etc). And thankfully, it seems that none of the hacks so far prevent Chipmunk from letting the player interact with movable objects in a reasonable manner.

Video 1:


Video 2:



Just some notes for other people who want to try mapping controls this way:

  • For running it boils down to applying massive acceleration to the player but capping horizontal velocity to their current run/walk state. I just change from "walking" to "running" after they hold a run key for long enough.
  • After holding jump for ~0.4 seconds I stop applying any upward force. If they let go before then, I immediately cut their velocity by 60%; otherwise I don't alter their natural trajectory at all.
  • I dampen the player's horizontal velocity whenever they're not pressing any movement controls. (Manually, by just scaling their velocity in-between physics steps.) For some reason this felt more natural and I blame video games.
  • When I'm trying to land on a platform in most games, I typically overshoot, then briefly tap the opposite direction to slow my speed to zero while I'm directly above. With the ridiculously high forces I have mapped to the arrow keys, I would immediately reverse direction instead of slowing down. So now I remember which direction you were moving when you jumped and if you move the other way, I use a much weaker force.

That's it for now.
« Last Edit: November 15, 2010, 10:57:41 AM by alltom » Logged

deactivating lurk mode
alltom
Level 0
**



View Profile WWW
« Reply #1 on: November 16, 2010, 01:44:33 AM »

I couldn't help it. I couldn't stand messing around in that big, black empty. So I threw together some terribly stupid SVG parsing hacks (nokogiri with a handful of xpaths and regular expressions) so that I could use Inkscape as a level editor. If anyone has an SVG parsing library for Ruby they like, I'd appreciate the tip...

Video 3:



To get the friction right I'll need to tag the shapes to distinguish floors from walls from slopes, but given how every time I tweaked the file Inkscape discovered a new way of specifying polygons in SVG, maybe I'll keep it simple for now.

Now that I can create a frame of reference for his motion, however abstract, I can tweak the controls some more and work on camera motion. I think I'm going to have to make him a lot slower or a lot smaller.
Logged

deactivating lurk mode
deathtotheweird
Guest
« Reply #2 on: November 16, 2010, 02:15:49 AM »

That's cool. Alex Vostrov(working on a game called Infested Planet) recently posted about using inkscape as a level editor in his dev blog: http://www.indiebird.com/blog/?p=928

He used inkscape's ability to input custom xml tags to store level data right in the art.
Logged
santaragione
Level 1
*



View Profile WWW
« Reply #3 on: November 16, 2010, 06:03:53 PM »

I have to say that I'm really fascinated by this project...keep it up, I'm really interested to see where it ends!
Logged

alltom
Level 0
**



View Profile WWW
« Reply #4 on: November 20, 2010, 09:53:15 PM »

That's cool. Alex Vostrov(working on a game called Infested Planet) recently posted about using inkscape as a level editor in his dev blog: http://www.indiebird.com/blog/?p=928

He used inkscape's ability to input custom xml tags to store level data right in the art.

I saw that post! I don't remember how I got there, but that was the inspiration for trying to use Inkscape.

I have to say that I'm really fascinated by this project...keep it up, I'm really interested to see where it ends!

Thanks. Smiley Me too...
Logged

deactivating lurk mode
alltom
Level 0
**



View Profile WWW
« Reply #5 on: November 20, 2010, 10:15:13 PM »

I ported the project from gosu to chingu to offload some of the game state management onto a framework. I also split the code from a single massive Ruby script into many tiny ones with useful names. It was getting a little hard to navigate, though it's only ~600 lines...

Video 4:



The biggest problem with the controls right now is that one of my physics hacks is back-firing. I figured out why you slide down slopes but stick to walls: in order to prevent the player from falling on his face I manually set the player's rotation to upright after every physics step, but on slopes this means they're rotated out of contact with the floor, so they fall a little every frame. I need to figure out a better way to constrain rotation, but I haven't figured out how to do that with Chipmunk's constraint framework yet. It seems simpler in Box2D, so I may make the switch.

Other than that, I added rudimentary camera control that tries to center on the player's predicted position with some damping. It's extremely finicky in a way that makes it feel like you're in an intense action sequence filmed with shaky-cam. But it'll do for now. I just wanted to be able to play with levels that are larger than the screen.

The only thing preventing Ruby 1.9.2 compatibility seems to be Chipmunk, which I haven't been able to build properly yet. It segfaults on launch, though I haven't looked into why. I was able to get the ruby-opengl gem working with this hack. (The fix isn't a hack; just the way it's applied.)
Logged

deactivating lurk mode
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic