A sprite sheet won't take long

i've been cramped with deadlines for school so don't expect anything big until late november or early december

to make sprite sheets and graphics for an entire level would probably take about 2-3 days but I don't even have time to mess around with my tablet for an hour

I mean actually mapping out the physics in code. I just haven't got to it, but I had imagined it would look something like that.

If you guys think it would be a good idea, I could just implement Box2D to get better physics simulations. There would probably be less bugs, too.

Use Box2D if its reliable and suits our needs

I mean we are not making a physics based puzzle game, right?

If so, use Box2D

if we are basing a lot of things on physics (like WoG does), then don't use Box2D.

I don't know.

Anyway, just use Box2D it's easy, we don't need a lot of physics, and it's our first game so we shouldn't get into making a whole physics engine just yet.

nvm lol

No, you guys don't seem to get it. Box2D is what we would use if we NEEDED physics.
Writing a quick engine on my own wouldn't be nearly as good.

Agreeing with Red here ^^. You'll only need Box2D if you want complex, realistic physics simulations (Something WOG-esque). Being an RPG, you may not need anything that complicated, and Red can just write some simple physics code (like AP's pseudocode; that's what the game engine I'm using was like before I ripped it all out and stuck Box2D in there) and use that instead. Depends if you want physics puzzles and stuff like that or not.

Wait, does Box2D have collisions already written-in? I had SDL_collide linked in before, but I would use whatever's best.

lol, talking about the same thing on two threads is not a good idea.

I assume that all this is concluded with the agreement on the other thread.

SDL_collide is good. I don't think Box2D has a better one.

Then again, Box2D IS for physics. It likely has its own collisions already written. Something like setting a SDL_Surface for an "object" or something like that. I haven't looked at it though. MOM?

Box2D is a really fully-developed physics engine. So you get collisions for rotated rectangles, circles, and polygons as well as impulses, friction, and the whole slew of physics. So not only can you check for collisions, when objects collide, they bounce off each other realistically (with friction and restitution that you can set). This sort of thing is REALLY hard to do by yourself (I haven't even had enough physics courses to be able to figure out rotational collisions, myself- I've only ever covered nonrotating rigid bodies), so it's really great for realistic physics. It can be a pain, however, to NOT have the physics simulations if you don't want them, since everything automatically collides and such.

As for the setup of rigid bodies in Box2D, you have a "body" that represents an object that has a void* pointer that you can set to anything you like (like an SDL_Surface* or your own object class), so that part is fairly easy; you'll just have to draw it yourself, rotated correctly, with normalized coordinates (For Box2D, positive y is up). The "body" has different "fixtures" you attach to it for collision geometry -- sort of like how you can have a compositegeom in World of Goo with one image and a bunch of different rectangles on it. Same basic idea. And then of course, you can have all kinds of joints, pulleys, chains, levers, hinges, and stuff to connect two actual "bodies" together for different types of physics simulations. You can also set objects to not rotate, in case you don't want a particular object (like the character) flopping over. And of course you get static geometry like in World of Goo for walls and floors and such.

That help? I really like physics, don't get me wrong, but my own physics that I coded wasn't terribly realistic when it came to collisions, and was fairly limited without rotated rectangles. If you're just after something easy just for simple collisions, SDL_collide should do fine (I haven't worked with it any myself, but I imagine it pretty much does what it says). But if you want to model a giant tower of bricks that you can knock over, Box2D is incredibly simple and easy to use.

If I lost anyone here with technical jargon, just nod your head mechanically and say "yes master."

I know the capabilities of Box2D, but I didn't know it would be hard to NOT have physics enabled for some cases.

I'll look into it more before deciding. SDL_collide is basically a series of if statements that let you check if pixels are overlapping, adjacent, and all that jazz. There's also a check function that checks if they're overlapping in motion and will bring them back next to each other as if they're solid objects.

Well, it's not hard per se, I just haven't figured out the collision filtering stuff yet, and just had a Sprite class already, so I have a setting for the Sprite to not collide, and if it's set, I don't even make the Box2D body or fixtures, so it has no physics or collision at all. Works for me for now.

Sounds good. I love intuitive physics in puzzles.

Hmm, maybe. What kind of puzzles? Give examples. I really don't know where it would fit. All the moving game objects I thought we would have might be the player, npcs, monsters, and animations. I didn't think we would ever need "physics" per say.

Strategic, destructable, motile terrain.

Oh, like Maplestory's quest: Umi's Lost Coin. You go in the subway and make all these strategic jumps, and since there's blowback, little lazers move across everything and do 1dmg to you, causing you to fall down to the bottom and having to start again.

options:
like telltale's games?
or like maple story?

Maplestory so far, but I think we'll be a little more creative with the graphics and sound schemes. Also jumping in Maplestory sucks.

they should make it space, not alt.

It's just the default, and all the old old players (like me) like it being alt..

but old old old players (like my ol' dad) prefer space, because of old old old arcade games, where jump was the really big red button. space is the biggest button of the keyboard, so therefore they are inclined to press it for jump.

In the end of Portal 2, someone got stuck with the controls (switching from PS3 or whatever to PC) with the blue gel. In the video...

"How do I jump on the gel? HOW DO I JUMP?!"
"SPAAAAACE!"
"Actually, let me try that...it works! Thanks, sphere!"

Off topic, but th spacebar discussion made me remember it. Sory.

Haha, that's so random!

i never finished portal, 1 and 2. portal 2 is an epic game, but it is too high-res for this old computer i'm borrowing.

Yeah, in Portal 2 they have dynamic shadowmapping and moving light and blob rendering and all sorts of other expensive stuff.

But it's done in SOURCE! So doing native res (1440x900) on my old 2GB ram PC will run without lag!

Well, you can set the graphics settings to be lower. I set it to 800x600 with everything else on as low settings as possible on my computer here, and guess what? It looked terrible.

Also, Ctrl = best key for jump. Then you can have Alt for fire and arrow keys for moving. Though Terraria's spacebar jump and WASD + mouse is a great idea for omnidirectional firing, and Cave Story's ZXC + arrow keys works great too. Just don't do anything stupid like Tab for bombs and Shift for missiles like this one dumb game I played.