Project Phoenix - Dynamic Weapon Changing Video

Posted by tahnok100 on Oct. 8, 2008, 11:41 p.m.

So, since my website has gone down, along with my blog, I figure I will post a few progress updates of my current project here.

Project Phoenix is going to be an online platform shooting game, pitting player against player. It's been in development on and off for quite a while now. Here's a screenshot from a while ago showing off a level:

http://i16.photobucket.com/albums/b9/tahnok100/PhoenixScreenshot_6_25_08.png

Recently I've really been stepping up the dev speed and have come up with some nice new features. The video below shows the new arm system, which utilizes inverse kinematics. The arms are being calculated and created on the fly, depending on the user input (which is "change gun" in the video). So enjoy this quick vid of the player changing between the pistol and shotgun.

http://www.64digits.com/download.php?name=Phoenix_ArmDemo_6-10-08.zip&id=27108

BTW, yes, the player is floating at this point. The legs will also be dynamically created eventually, but I've not started work on that system yet.

Enjoy,

Tahnok

Comments

Evilish 16 years, 1 month ago

That arm movement looks pretty goddamn fluid.

As for those levels, are they just sprites, or GM primitives? I could always give you a nice little GM .dll that lets you use primitives for collisions (and a level editor to create everything too!)

tahnok100 16 years, 1 month ago

Thanks Evilish.

The levels are textured primitives. And I actually already have collisions and a level editor all worked out. Thanks for the offer though!

Evilish 16 years, 1 month ago

Wow, thats pretty cool. I made mine a .dll because I couldn't get vertex collisions running fast enough in GM, I'd love to know how you did it.

tahnok100 16 years, 1 month ago

Well I took a bit of a cheater way out. I render all the ground primitives to surfaces and then convert them to sprites. This means it takes a few seconds (literally) to load the level, but once it's going its extremely fast and reliable. I've found that as long as the surfaces are freed, memory isn't really an issue (the sprites seem to take up less memory than the surfaces, if that makes any sense). It also runs faster because I'm able to use GM's built-in collision detection then.

For primitives that don't have to be interacted with (like the background and mountains) I save them into D3D models. I may eventually put an option in also to render those to sprites (to trade off some more memory for performance).

Evilish 16 years, 1 month ago

Awh, I thought it was some miracle cure that I could put in my C++ game/dll, shame.

So is it going to use 39dll for online? Any news on features it might have? online ranking? achievements? destructible terrain? ironic catfish? ^_^

tahnok100 16 years, 1 month ago

Well it's a real shame my other blog was lost because I had some pretty in-depth posts about how exactly it will work. For now I will say yes, it will be using 39dll, no, there will be no destructible terrain. As for everything else you'll just have to wait for future updates to find out, hehe.

Juju 16 years, 1 month ago

Interesting. I experimented with IK in my project ZG. When combined with other graphical techniques I was using, I found it to be far too slow due to the liberal use of inverse trignometrical functions. Tell me, how did you go about coding the IK solver?

In terms of deformable terrain, it should be possible to use polygons for that purpose. It is a matter of fitting the shape of a polygon to the shape of an explosion… However, the next problem comes when the shape is self-intersecting or you use complex (read: concave) explosion shapes. Here is a related topic I found on a website to do with some library called Box2D, it may or may not be useful.

I've got a triangulation algorithm sorted. If we can manage to create polygonal deformation, this will improve the capabilities of Game Maker no end.

marbs 16 years, 1 month ago

When I was making a polygon based engine I used the same approach as both of you. First I did the method where you save the polygons to sprites, but this has the disadvantage of a long loading time, then I went on to make my own DLL, however it was much simpler than yours Evilish, but it did dramatically speed up the collision checking and triangulation. It'd be great to mush this together with destructable terrain somehow,

TDOT 16 years, 1 month ago

I have to say your environment looks sexy. Your arm movement is absofreakinglutely awesome.I can't wait to play this.

Evilish 16 years, 1 month ago

Quote:
It'd be great to mush this together with destructable terrain somehow,
Subdivide, subdivide, subdivide, don't know how you'll 'add' terrain to it though. Wait my .dll was like 4 functions, how could yours be simpler?

@Juju, I moved on from GM when it still hit bumps, even when the dll handled all the collisions, even when it had all the data so no data type conversion was needed, even when GM was sped up by only drawing onscreen vertexs, GM just still hit a limit and became too slow.

And ontop of all that I think destructible terrain is still a bit far away for anything online game, the chances to screw up and see different results on each machine can be a bit high.