Scrolling Game Development Kit Forum
SGDK Version 2 => General Discussion => Topic started by: bluemonkmn on 2011-07-24, 10:38:49 AM
-
I have been lazily playing games instead of coding in my free time :-[, but this morning, after seeing that durnurd (my brother) is working on cool new games with 2D physics, I decided to look into physics engines myself. With a little difficulty (due to my 64-bit environment) and effort, I managed to get Physics2D.Net to compile and run its demos on my system. It looks very cool. I think I will start investigating how this might be integrated with SGDK2 somehow.
Physics2D Homepage (https://sites.google.com/site/physics2d/)
Demo Video (http://www.youtube.com/watch?v=Oecv7Cg9lCc)
-
Heh, I've been slacking off too! :p
I think that a physics engine is going to be a great upgrade to SGDK2! I can't wait to see if it's possible. :)
Good luck!
-
If things go well, I can integrate it simply as a new project template -- no new SGDK2 version/release necessary. That would be pretty neat.
-
You don't plan to wrap the classes of the physics engine? We would simply use the physics engine's library or something like that?
-
I'm not sure yet. I might import the code directly into the SGDK2 project, or I might refer to the DLL from the SGDK2 project (like I did with FMODEx). I might create a parallel set of classes to represent the sprites and possibly the tiles in the physics engine, or I might create physics objects directly based on the sprites and tiles present in the project, or I might try to make the physics engine operate directly on the sprite instances. I think all of these can be done without altering SGDK2 code.
-
Well it's not entirely clean, but it works! Can anybody get this project to work for them too?
SGDK2PhysicsDemo.zip (http://sgdk2.enigmadream.com/ben/SGDK2PhysicsDemo.zip) (213 KB)
Just load it and run it, I think. If you want to edit sprite rules you may have to put the included DLL's into the SGDK2IDE.exe directory.
I just gotta say -- riding platforms in the real world is much harder than in typical platform games!
-
Hi bluemonkmn!
I tried it yesterday, for about 5 minutes. It works well for me but it crashed when I went into the moveable sprite to see it's rules. I didn't put the Dll in the SGDK2 IDE folder like you pointed out. Anyway, it's great! Hard to put the box on the platform, but I succeeded after a while. It's nice to see the impact it has on the platform: it absords the force of the impact and then goes back to where it should be. It's pretty solid!
Did you have to use the "pusher" and "pushed" sprite categories, or does the physics engine takes care of that?
-
There are actually very few sprite rules -- the physics engine is handling almost everything. I think the only rules I have are to push the platform toward the next point on the path, to move the player according to the player inputs, and to move the player toward the mouse when the mouse button is pressed. 3 Rules. But the project code *is* heavily customized -- for example, I hard-coded the addition of gravity into the project source code rather than putting it in a rule.
-
Interesting! How do you tell the physics engine that a particular sprite is part of the simulation? Or is it the other way around: you must tell the physics engine to ignore a specific sprite? :)
Oh... I guess there's still some work to do until the physics engine is easily available to everyone if a lot was hard coded. But as a POC, this test game is great!
-
Right now, every sprite in a layer is being added to the physics engine (as are all the tiles). The ProcessSprites function in LayerBase checks to see if the physics engine and sprites have been fully initialized, and if not, initializes them.
-
You could use prismatic joints for moving platforms along their paths. You just have to create a joint between the ground body and the platform and set the motorEnabled=true, maxMotorSpeed=(speed), motorTorque=(variable based on platform's weight), limitEnabled=true, lowerLimit=0, *breath* and upperLimit=(distance between current point and next point), and give it an axis pointing from its current location toward its next location with a magnitude of 1. And then every frame, you just check the joint's limitState to see if it's AtUpper (or something like that), at which point you destroy that joint and create another for the next point. At least, if you're using the Box2D physics engine. I don't know how any others work.
It's as simple as that!
-
Physics2D.Net has AngleJoint, HingeJoint, FixedAngleJoint and FixedHingeJoint. Yeah, I thought of using joints, but I think it would end up being a lot more complicated, especially considering I would need something to anchor the other end of the joint to.
-
Well, the requirement of anchoring it to another body isn't really the problem. Using Box2D terminology, there's just a default "ground" body that's static and doesn't have any fixtures attached to it. Once you have that body, you can use it for every joint that really only needs one body. The real problem is how much work it takes to set up joints.
-
What would be gained by managing platform movement through the physics engine? The usual platform seems to work pretty well.
-
For particularly heavy objects, it might make the platform go more slowly, straining under pressure. Or for very heavy objects, it may just not move at all, which you could change by perhaps upgrading the platform's motor with some object you have to get before you can bring the big block up the platform to push the button to continue, for example. All of this could be done with rules, but with physics, it works more or less automatically.
-
1. I'm using Physics2D.Net, not Box2D, and as far as I know, Physics2D.Net doesn't have a ground object. However, I might be able to create a dummy object with infinite mass that ignores collisions and anchor the joint to that.
2. The problem is, I kind of had to choose between SGDK2 physics and 3rd-party physics. I don't think mixing them works well. I guess I didn't try, but if I leave the platforms out of the physics engine's model, then I have to figure out how to tell sprites that are in the model to position and move themselves like they are still using SGDK2 physics. I need to develop new logic to decide what happens, for example, when a sprite hits another sprite that is riding the platform. I have to merge the SGDK2 physics that was telling the sprite's inertia to follow that of the platform with the 3rd party physics that is telling the sprite to move away (and probably even rotate!) as a result of being hit. It's too hard to use 2 physics engines, I think, so I just throw everything into the physics engine and it all takes care of itself for the most part. I just need to figure out how to manipulate things via the physics engine instead of directly. I have toyed with the thought, though, of limiting which sprites are represented in the physics engine. I think I just talked myself out of it :), but it's still in the back of my mind -- having participation in realistic physics be implemented more like an additional rule instead of intrinsic to the project's "engine".
-
whoa I came back from vacation and saw this... this is AMAZING. lol I guess this comment is more of a complimenting comment than anything else- really cool project!
-
Did you get it to run, Pizzaman?
-
The SGDK2PhysicsDemo.zip (http://sgdk2.enigmadream.com/ben/SGDK2PhysicsDemo.zip) file has been updated. Now you can see how arbitrary shapes can be used. Platforms are easier to ride now too.
-
Oooh!!! Very nice! I like the fact that the ship can get a start stuck between the wing and the cockpit. Well, that would be a problem in a game, but for a technical demo, it's great! :)
-
It runs GREAT. The Platform thing was an issue, but then again, that is a more realistic interpretation of a floating platform. This is an amazing addition!
-
Perhaps the most amazing part is I didn't have to deliver a new SGDK2 IDE; it's just a new template/project.
-
Starting to work on what might become a real game. I had an idea involving spiders, flies and webs. It's not very developed yet though. Use the arrow keys and the right Ctrl key (hold it down when near a fly)... you'll see what happens.
http://sgdk2.enigmadream.com/ben/Spider.zip (http://sgdk2.enigmadream.com/ben/Spider.zip)
-
Hahaha! I like it a lot! Very cute. Although the flying spider is a little weird. (Yeah, Iknow, that's not the point of this demo.) It's pretty impressive! Very simple too! Although I guess you developped the custom rules AttachTo and ReleaseWeb...
-
Nice demo. The only concern I have with it is whenever you run into the wall, you "magnetize" to it. I is there a way that you can reduce/eliminate this effect?
-
Yeah the spider will not fly in a real game. It will probably swing from webs or something. Flying was just left over from the space ship physics demo on which this demo was based, and I haven't decided how the spider should move yet. The magnetizing effect will probably go away when that goes away. I assume you're talking about the way the spider aligns (like a box) to the wall when it hits the wall. That's because the thrust that you apply to the spider is like gravity and the legs act like the corners of a box causing it to "land" on the floor, ceiling or walls that you're pushing toward. But when the spider gives up its flying engines, I think that effect will go away :). If not, I can always make the spider use a circular shape instead of its actual shape. But I thought it would be cool to use the actual shape for the spiders and flies where so many games just use squares and circles.