jPCT - a 3d engine for Java > Projects
Raven's projects
Raven:
Hello everyone.
For the past week I've been experimenting with jPCT (very happy with it, actually, I'm very amazed that there aren't more people using it! Why is that??). I wanted to share with you some of my concerns regarding a system architecture for an FP(S) platform (I'd like it to be more than just a shooter (hence the parenthesis).
My end-goal is to create a first-person game, but since I haven't quite decided the game's nature/theme I'd like to begin with creating a general platform for it (that I could perhapse release under GPL for others to experiment with).
Currently I'm wondering about the following things:
1. Levels
My current architecture introduces levels as classes, for each level there is a class with the same name. The level class would store vital information like the players starting position in that level, lighting positions, etc... However, the problem is that that's a lot of information to hand sort, object positions, decorations, etc..
A partial solution to this problem would be having a certain type of signal in the level designs as pointers for a "LevelManager" which would place objects.
For example: a sphere with the texture named "PlayerPos" is actually a pointer for where the Player Starting Position should be. Levelmanager would read these pointers, and use their position to automatically instantiate and place the right types of objects, etc.. (then delete them from the world)
Theoretically, this would be possible with jPCT, yes?
2. Segmented character/player bodies
Multi-part humanoids. For an FPS game, it'd be really nice to have arms, torso, head and feet all separate objects capable of being damaged independently. However that would pose many problems: Animations for each part would have to be animated seperately and initiated at the same time when something happens to the humanoid. So it would be very hard to animate these parts independantly from eachother while the end result is supposed to act as a whole.
Can anyone think of a good way to implement a segmented-body ? There's also the question of computation, will segmented humanoids be too much for jPCT to handle?
I also noticed in another thread that Egon/Helge has been questioned before about skeletal-character physics like Half-Life uses. At the time there was no plan to implement that kind of feature. That hasn't by any chance changed, has it? :)
3. Saving
My current thoughts on saving are by simply making the Level class, Stats class (Contains historical info about the gameplay) and Player class serializable. When continued you would simply load the classes.
Sounds a bit brute to me, but that's all I can think of.
---
Thanks for reading.
Hope you're having as much fun as I am.
Cheers,
- Raven
EgonOlsen:
--- Quote from: "Raven" ---A partial solution to this problem would be having a certain type of signal in the level designs as pointers for a "LevelManager" which would place objects....
Theoretically, this would be possible with jPCT, yes?
--- End quote ---
Yes. But i would use the name of the object, not it's texture. jPCT creates names for objects loaded from 3ds that start with the name the object has in 3ds. You may check for this name and don't merge the placeholder object to the level but replace it with the item instead.
--- Quote from: "Raven" ---
Can anyone think of a good way to implement a segmented-body ? There's also the question of computation, will segmented humanoids be too much for jPCT to handle?
--- End quote ---
Not too much to handle, but difficult to implement. It should be possible to code such a thing using IVertexControllers....but it sounds quite hard to do to me.
--- Quote from: "Raven" ---
I also noticed in another thread that Egon/Helge has been questioned before about skeletal-character physics like Half-Life uses. At the time there was no plan to implement that kind of feature. That hasn't by any chance changed, has it? :)
--- End quote ---
The point is, that i can only do so much. Doing a good skeletal animation system is a little project of its own. To be honest, i hoped for somebody to write one on top of jPCT, releasing it to the public and letting me integrate it into the engine's core to squeeze out some additional performance...but that didn''t happen until now :wink:
To be honest, i don't recommend starting with a goal as high as this animation system because chances are that you'll never finish it. But that's just me.
--- Quote from: "Raven" ---
My current thoughts on saving are by simply making the Level class, Stats class (Contains historical info about the gameplay) and Player class serializable. When continued you would simply load the classes.
Sounds a bit brute to me, but that's all I can think of.
--- End quote ---
Don't know, should work well enough if space and/or loading times aren't important.
Raven:
--- Quote from: "EgonOlsen" --- Yes. But i would use the name of the object, not it's texture. jPCT creates names for objects loaded from 3ds that start with the name the object has in 3ds. You may check for this name and don't merge the placeholder object to the level but replace it with the item instead.
--- End quote ---
Ah, I didn't know that. That's great! It'll make mapmaking a lot easier. Yeah, replacing the object is what I had envisioned.
--- Quote from: "EgonOlsen" ---
Not too much to handle, but difficult to implement. It should be possible to code such a thing using IVertexControllers....but it sounds quite hard to do to me.
--- End quote ---
Ach, that's too bad. At this point I don't think I dare venture into IVertexControllers. I'd rather get a working demo first. But thanks for clarifying this for me.
--- Quote from: "EgonOlsen" ---
The point is, that i can only do so much. Doing a good skeletal animation system is a little project of its own. To be honest, i hoped for somebody to write one on top of jPCT, releasing it to the public and letting me integrate it into the engine's core to squeeze out some additional performance...but that didn''t happen until now :wink:
To be honest, i don't recommend starting with a goal as high as this animation system because chances are that you'll never finish it. But that's just me.
--- End quote ---
I usually try and set my goals high to begin with and then tone them down as time progresses. Thanks for being honest - I was hoping someone would have a "magic solution" for accomplishing this, but given the options I won't attempt create it (Well, not yet at least :wink: ).
I have an idea though of how to accomplish "damage" to different bodyparts; simply creating invisible 3x3x3 cube around the characters. When a character would receive damage, the cubes register where the "inflictor" came from. For example, if a projectile hits a character in the chest, it must have passed through the middle cube -- this way we know a bit more than just that the character was hit. However, I'm unsure what kind of invisibility would be required, since I gather that invisible objects aren't processed? Maybe a dummy object cube?
EDIT: Actually, just a simple row of invisible cubes would be an improvement. One cube around the legs, one in the middle and one for the head. At least a lot simpler to implement.
Thanks for the feedback.
-Raven
EgonOlsen:
It should be possible to get what you want easier IMHO. I think that you can use polygon IDs for this. For each model in question, you may determine which polygons belong to which body part. Using the PolygonManager on an untransformed/-translated object you can get the vertex coordinates in object space...and it may be possible to say that (for example) everything below y=-10 is the head, between 10 and -10 is the chest etc...that may work on most models well enough. Store this list and use a CollisionListener to get the ID of the polygon that has been hit by the collision, search your list for it and voila, you have your body part. Just an idea...
If you follow the "boxes"-approach, they don't have to be invisible all the time, just during rendering. That's what Paradroidz does to calculate collisions against a sphere even if the droids are usually none. When rendering, the droids are visible and the spheres are invisible. When doing the collision check, the spheres will become visible and invisible again after collision detection has finished. But i would head for the polygon ID way instead...should be easier and works better if you manage to assign polygons to body parts in some way.
Raven:
The polygon ID plan sounds better. Thanks for the advice. This could also prove a very useful discussion for future jPCT-FPS gamemakers.
-Hrafn "Raven"
Navigation
[0] Message Index
[#] Next page
Go to full version