*ahem*

My last post is about crafting. Pretty much the same thing.

Crafting would be pretty cool. What you said, NPC crafting is probably easier, then we won't have to add another "Crafting" skill/stat. Should it cost though?

Maybe some could require payment but most should only ask for items. If we do it like this then we can have money as one of the "items " for the craft.

Sounds good.

And you should be able to make some yourself, if they're simple. (for example, you could make a torch out of something flammable and a branch, but you couldn't make an axe or anything like that)

The idea was that you would have to visit certain towns to get certain npcs to craft you items.

Crafting = cool. As long as you know up-front what you can craft into what. The lack of knowing what you could make out of what makes some games (like some of the Final Fantasy games) not as fun for me. And while some diehards think that the fun in Minecraft is figuring out everything for yourself, I beg to differ.

Any current ideas for physics or a physics engine? I'm implementing Box2D right now in my game, which is why I'm asking.

I was thinking of doing the formulas on my own. It seems like I could just use timers, adjusting the timers according to how long the key was pressed, and from those timers dictate the speed of the jump/fall. I know that knowing the theory is not the same as implementing it, so I'll have to see how it goes. If it gets too difficult, I may use Box2d.

Box2d is great. The test exe they have for download gave me a fun 15 minutes.

crafting would be cool. then you can customize gear and stuff.

Like in Minecraft or Maplestory.

This is so gonna be compared with Maplestory once it's released

I don't know if you're gonna need Box2D for any real physics-y stuff. Maybe you'll need it for occasional particle effects or something like that, but I think most of the gameplay is gonna be pretty simple.

That's what I thought too. Maybe for effects or particles. Who knows? Let's wait a little.

it would be cool if we could contact ron or kyle and ask if we can use a variation of the World Of Goo music.
If we could, then we could do this:
do you know how old super mario games used beeps and boops to make the catchy music?

(good player, by the way.)
we could make WOG music with beeps and boops, too!!!

I don't think WoG music would really fit with our game. What's more, this should be in the music thread.

Some parts of it would. The piece Years of Work, for example, in certain parts of the cave. Maybe an underground ocean, because parts of the song sound like waves hitting the shore.

Possibly. But not stuff like My Virtual World of Goo Corporation, Tumbler, or Another Mysterious Pipe Appeared.

Well, that last one might be good if we have a carnival or something

C'mon guys, stick stuff to specific threads. This is getting off-topic.

Agreed. Sorry for continuing the discussion

Oh, man, the Box2D example program gave me fun for hours.

For particles, you could use something like 2DBoy did, with velocities, fading out, that sorta thing. I don't think they used physics for their particles. Physics on so many objects probably would bog the game down pretty hard.

And also, off topic. Eh, who cares? At this point, I say we're good enough friends that we should be able to babble on about whatever we like.

Sweet. Babble babble babble!

That sounds like a good idea. Particles like WoG would be fine. Depending on where else we use physics, it wouldn't matter too much though. I'll avoid using Box2D until we have a definite need for an upgrade.

Agreed.

If necessary we could add some physics by having the particles detect forces just like dynamic objects do.

Heh, maybe...
I think Box2D may be easier for that kind of thing. Otherwise I'll manually have to have loads of frame-timers.

Doesn't SDL usually use a do{}while(true) loop every frame? Add it in there.

Or make an object class with an everyFrame() function.

Games are typically done in while loops. The main one of my engine keeps going until a boolean is set to false. This can currently be done by x-ing out the window or by pushing escape. SDL doesn't have that internally. Only the drawing and receiving functions were defined. I draw the images on the screen every round in the while loop. Once I get to it, I'm going to cap the framerate and wait until the next frame before the loop continues each round.

So call the force check functions in there.

Force check? No. I'm going to be doing only 5 or so functions in that main loop. Within those functions, I can do other functions, with functions going down even further!

That's fine. But you just said you would need lots of frame timers to be able to do touch checks.

Touch checks with SDL_collide are as simple as if statements. All I said was I would have to write timers and set those timers according to placement, key presses, etc. Those timers would start and be activated by touch checks as well.

Box2D shouldn't be used for large numbers of objects, like particles. It can turn into a CPU hog if too many objects are in a scene. It's best to do something like that using your own physics code.

I know, I'm really leaning toward just writing something simple. But first we NEED to decide on final player dimensions. CUCUMBER, someone just suggest some numbers.