Status of the Game Engine - 1.20.08
1 view
Skip to first unread message
dantef...@gmail.com
Jan 20, 2008, 6:00:11 PM1/20/08
to The Other Plane - Game Project
3rd Person Camera System and Character Movement:
30% -
Have: Character movement, Mouse look w/ Character rotation, Character
collision with level
Need: Camera collision with level, Velocity physics/programming
formula for progressive build up in player speed/momentum, set up
animations (When we have a real character)
Targeting system:
50% -
Have: Collision based targeter (acts like a laser pointer),
Placeholder targeter image, adjusted to not overlap over character
(billboard based, overlaps everything on screen)
Need: An original targeter image, interactable object handling,
brightening objects/npcs that are interactable
Level loading system / Scene Manager:
30% -
Have: irrEdit scene loading, basic structure for smart asset loading,
sets up level for collision detection with character
Need: Define a naming scheme, make custom entity nodes for assets,
implement custom asset loading functions
Collision with non-base level meshes:
0%
Audio Integration:
0%
Optimization
30% - In the process of optimizing C++ code, and object orienting all
systems in a game engine ready way.
Framerate Lockdown:
0% - Need to limit the framerate to a steady 60 FPS for smooth
visibility. At the moment the engine is running at fastest FPS
possible (super fast! Damn!).
Please reply to this thread with any engine tech needs you think we
might need to put on the radar.
30% -
Have: Character movement, Mouse look w/ Character rotation, Character
collision with level
Need: Camera collision with level, Velocity physics/programming
formula for progressive build up in player speed/momentum, set up
animations (When we have a real character)
Targeting system:
50% -
Have: Collision based targeter (acts like a laser pointer),
Placeholder targeter image, adjusted to not overlap over character
(billboard based, overlaps everything on screen)
Need: An original targeter image, interactable object handling,
brightening objects/npcs that are interactable
Level loading system / Scene Manager:
30% -
Have: irrEdit scene loading, basic structure for smart asset loading,
sets up level for collision detection with character
Need: Define a naming scheme, make custom entity nodes for assets,
implement custom asset loading functions
Collision with non-base level meshes:
0%
Audio Integration:
0%
Optimization
30% - In the process of optimizing C++ code, and object orienting all
systems in a game engine ready way.
Framerate Lockdown:
0% - Need to limit the framerate to a steady 60 FPS for smooth
visibility. At the moment the engine is running at fastest FPS
possible (super fast! Damn!).
Please reply to this thread with any engine tech needs you think we
might need to put on the radar.
dantef...@gmail.com
Jan 20, 2008, 6:01:04 PM1/20/08
to The Other Plane - Game Project
Gera Gundorov to me, Chris, Tyler
* Collisions with non-level based meshes:
In Neverwinter Nights, they have a system that turns objects semi
transparent when they obstruct the view (columns, merchant tents,
etc.). On the other hand, if you bordered a wall of the hundreds of
narrow hallways, you would see the skybox. Granted it was solid
black, but it kind of pulled you out of the immersion. If the
character is bordering the level perimeter the camera will have
collision with the editor built mesh. But the smaller object in the
scene would require no collision setup, and would probably eliminate
quite a bit of work on the tech end.
Thoughts?
Gera
* Collisions with non-level based meshes:
In Neverwinter Nights, they have a system that turns objects semi
transparent when they obstruct the view (columns, merchant tents,
etc.). On the other hand, if you bordered a wall of the hundreds of
narrow hallways, you would see the skybox. Granted it was solid
black, but it kind of pulled you out of the immersion. If the
character is bordering the level perimeter the camera will have
collision with the editor built mesh. But the smaller object in the
scene would require no collision setup, and would probably eliminate
quite a bit of work on the tech end.
Thoughts?
Gera
dantef...@gmail.com
Jan 20, 2008, 6:02:31 PM1/20/08
to The Other Plane - Game Project
On the tech end, I'm using Irrlicht's built in collision. This is a
triangle selector collision. So it takes the occtree opimized level
mesh and then takes your entity node's magnitude vector and takes the
intersection of that with the level mesh polygons (triangles).
When I set up collision detection, it is set up once with the loading
of the level and the character and camera. So, think of it as a switch
you turn on that stays on. I can't really disable character or camera
collision while enabling the other. If I disable character collision,
the character model will fall through the level into the nothingless
pit of nothing. The movement of the camera node is dependent on the
position of the character. So what would happen is that the character
would fall forever under the level while the camera got stuck on
ground level, lol.
Maybe that helps understand collision a little more? Don't worry about
performance yet guys. Everyone seems rather worried about system
slowdown. I'm completely relaxed and not even worried about it at all.
Collision detection against the level mesh isn't very taxing on
performance at all. I estimate our game will be able to run on older
systems without a state of the art graphics card. Maybe we should aim
for the current state of most laptops with integrated graphics?
I don't think I'm planning on making objects semi-transparent. That
seems a bit weird to me, thoughts? I don't think anything should
obstruct view, since the camera is very close to the character. Think
Assasin's Creed, Hitman, Fable, Max Payne. The reason we should have
collision on the camera is so it doesn't go through a wall and show
the user the funkyness of outer-level space, etc... I still need to
investigate more on how to do this right so that we don't get stopped
from moving the character near walls.
Collision with regular meshes, like rocks and so on, is the next thing
on collision that is important before we start level making. I need to
read into Irrlicht a bit about bounding boxes and relate that to the
character for collision. I believe all entity nodes should
automatically have a bounding-box, so hopefully it won't be too hard.
Collision-wise, I think that's all we will need for this project
unless anyone has other concerns.
Small objects I agree, no collision there (like plants and pebbles
etc...). Also keep in mind, that there is a threshold for the
character standing on top of things in front of him. Think of stairs.
We can easily do stairs. But, if you made a plant part of the base
level mesh, the character will treat it like a stair and walk on top
of the plant (funny thought). So... small things that should not hold
a character's weight need to be placed as an entity in irrEdit.
triangle selector collision. So it takes the occtree opimized level
mesh and then takes your entity node's magnitude vector and takes the
intersection of that with the level mesh polygons (triangles).
When I set up collision detection, it is set up once with the loading
of the level and the character and camera. So, think of it as a switch
you turn on that stays on. I can't really disable character or camera
collision while enabling the other. If I disable character collision,
the character model will fall through the level into the nothingless
pit of nothing. The movement of the camera node is dependent on the
position of the character. So what would happen is that the character
would fall forever under the level while the camera got stuck on
ground level, lol.
Maybe that helps understand collision a little more? Don't worry about
performance yet guys. Everyone seems rather worried about system
slowdown. I'm completely relaxed and not even worried about it at all.
Collision detection against the level mesh isn't very taxing on
performance at all. I estimate our game will be able to run on older
systems without a state of the art graphics card. Maybe we should aim
for the current state of most laptops with integrated graphics?
I don't think I'm planning on making objects semi-transparent. That
seems a bit weird to me, thoughts? I don't think anything should
obstruct view, since the camera is very close to the character. Think
Assasin's Creed, Hitman, Fable, Max Payne. The reason we should have
collision on the camera is so it doesn't go through a wall and show
the user the funkyness of outer-level space, etc... I still need to
investigate more on how to do this right so that we don't get stopped
from moving the character near walls.
Collision with regular meshes, like rocks and so on, is the next thing
on collision that is important before we start level making. I need to
read into Irrlicht a bit about bounding boxes and relate that to the
character for collision. I believe all entity nodes should
automatically have a bounding-box, so hopefully it won't be too hard.
Collision-wise, I think that's all we will need for this project
unless anyone has other concerns.
Small objects I agree, no collision there (like plants and pebbles
etc...). Also keep in mind, that there is a threshold for the
character standing on top of things in front of him. Think of stairs.
We can easily do stairs. But, if you made a plant part of the base
level mesh, the character will treat it like a stair and walk on top
of the plant (funny thought). So... small things that should not hold
a character's weight need to be placed as an entity in irrEdit.
Gera Gundorov
Jan 21, 2008, 12:49:31 AM1/21/08
to The Other Plane - Game Project
Got it.
dantef...@gmail.com
Jan 21, 2008, 11:28:41 AM1/21/08
to The Other Plane - Game Project
Optimization
50% - Cleaned up a lot of code to make it memory efficient and faster.
Moved Targeter to be loaded inside the Scene Loading System. In the
process of moving player movement control to its own class.
50% - Cleaned up a lot of code to make it memory efficient and faster.
Moved Targeter to be loaded inside the Scene Loading System. In the
process of moving player movement control to its own class.
dantef...@gmail.com
Jan 28, 2008, 1:49:27 AM1/28/08
to The Other Plane - Game Project
Current Engine Optimization
100% - Complete
Collision with non-base Meshes
100% - Complete - FAILS
Big Problem: I did some scalability testing for this type of
collision, and it isn't good. We can get away with bounding-box
collisions alright, but definitely not any per-polygonal collisions
that aren't occTree Static Meshes. I'm looking into assessing the
Ageia PhysX Engine and the Newton Game Dynamics Engine. There are many
tutorials/forum posts on integrating these with irrLicht. As of now,
everything works with collision, it just has performance issues.
Switching to a physics library should clear this up, as irrLicht is a
Graphics Engine and is not meant to be relied on for physics. Sorry
for the mis-assessment guys.
To-Do:
Integrate Physics Library.
Integrate FMOD Audio Library.
Note:
Even though performance won't hold up wonderfully, I'm giving the
thumbs up for level designing to begin. It would be good to start
modeling and getting some out-door environments done. The only thing
that will be left out at this stage is audio nodes. Collision stuff is
purely Engine tech, so it doesn't affect any other work.
100% - Complete
Collision with non-base Meshes
100% - Complete - FAILS
Big Problem: I did some scalability testing for this type of
collision, and it isn't good. We can get away with bounding-box
collisions alright, but definitely not any per-polygonal collisions
that aren't occTree Static Meshes. I'm looking into assessing the
Ageia PhysX Engine and the Newton Game Dynamics Engine. There are many
tutorials/forum posts on integrating these with irrLicht. As of now,
everything works with collision, it just has performance issues.
Switching to a physics library should clear this up, as irrLicht is a
Graphics Engine and is not meant to be relied on for physics. Sorry
for the mis-assessment guys.
To-Do:
Integrate Physics Library.
Integrate FMOD Audio Library.
Note:
Even though performance won't hold up wonderfully, I'm giving the
thumbs up for level designing to begin. It would be good to start
modeling and getting some out-door environments done. The only thing
that will be left out at this stage is audio nodes. Collision stuff is
purely Engine tech, so it doesn't affect any other work.
dantef...@gmail.com
Jan 28, 2008, 3:18:00 AM1/28/08
to The Other Plane - Game Project
Another update on Collision:
Vitek, from the IrrLicht forums has been discussing this collision
issue with me. He found a method to improve the performance by only
running calculations on meshes that are near the player, detected by
an enlarged bounding box placed at the player's position. I will try
this technique out, and post my results.
Another thing that I found is poor design for the collision
performance is that it is calculated within the draw code for
rendering the scene. If I'm able to decipher the core engine code a
bit better, I may be able to implement a timer on calling the
collision code, so that it updates less often, tweaking to a good
level. This should be a balance between performance vs accuracy.
-Regardless, we should use bounding box collision for most meshes.
-Per-polygon collision on the occTree level (already in place).
-If the model includes stairs or things that would require complex
collision, if they are a static mesh, import them as an occTree mesh
in irrEdit. OccTree has better collision performance, but worse
graphical rendering performance for small objects (much better graphic
rendering performance for large meshes such as the level).
-If the model is an animated mesh, and requires per-polygon collision,
this will be what has the worst performance. If possible, maybe we can
avoid this.
I'll be reviewing Ageia PhysX SDK. Stephan told me it is a pain in the
ass, so if I think so too, we're dropping it and sticking to the
methods above. If collision ends up causing performance issues, we can
always switch after and the work of the game will not be affected.
Vitek, from the IrrLicht forums has been discussing this collision
issue with me. He found a method to improve the performance by only
running calculations on meshes that are near the player, detected by
an enlarged bounding box placed at the player's position. I will try
this technique out, and post my results.
Another thing that I found is poor design for the collision
performance is that it is calculated within the draw code for
rendering the scene. If I'm able to decipher the core engine code a
bit better, I may be able to implement a timer on calling the
collision code, so that it updates less often, tweaking to a good
level. This should be a balance between performance vs accuracy.
-Regardless, we should use bounding box collision for most meshes.
-Per-polygon collision on the occTree level (already in place).
-If the model includes stairs or things that would require complex
collision, if they are a static mesh, import them as an occTree mesh
in irrEdit. OccTree has better collision performance, but worse
graphical rendering performance for small objects (much better graphic
rendering performance for large meshes such as the level).
-If the model is an animated mesh, and requires per-polygon collision,
this will be what has the worst performance. If possible, maybe we can
avoid this.
I'll be reviewing Ageia PhysX SDK. Stephan told me it is a pain in the
ass, so if I think so too, we're dropping it and sticking to the
methods above. If collision ends up causing performance issues, we can
always switch after and the work of the game will not be affected.
Dante
Feb 14, 2008, 3:00:25 AM2/14/08
to FLASHOVER - Game Project
3rd Person Camera System and Character Movement:
30% -
Have: Character movement, Mouse look w/ Character rotation, Character
collision with level
Need: Camera collision with level, Velocity physics/programming
formula for progressive build up in player speed/momentum, set up
animations (When we have a real character)
Targeting system:
50% -
Have: Collision based targeter (acts like a laser pointer),
Placeholder targeter image, adjusted to not overlap over character
(billboard based, overlaps everything on screen)
Need: An original targeter image, interactable object handling,
brightening objects/npcs that are interactable
Level loading system / Scene Manager:
30% -
Have: irrEdit scene loading, basic structure for smart asset loading,
sets up level for collision detection with character
Need: Define a naming scheme, make custom entity nodes for assets,
implement custom asset loading functions
Collision with non-base level meshes:
100% - Fixed framerate issues. Mostly using bounding-box except with
30% -
Have: Character movement, Mouse look w/ Character rotation, Character
collision with level
Need: Camera collision with level, Velocity physics/programming
formula for progressive build up in player speed/momentum, set up
animations (When we have a real character)
Targeting system:
50% -
Have: Collision based targeter (acts like a laser pointer),
Placeholder targeter image, adjusted to not overlap over character
(billboard based, overlaps everything on screen)
Need: An original targeter image, interactable object handling,
brightening objects/npcs that are interactable
Level loading system / Scene Manager:
30% -
Have: irrEdit scene loading, basic structure for smart asset loading,
sets up level for collision detection with character
Need: Define a naming scheme, make custom entity nodes for assets,
implement custom asset loading functions
Collision with non-base level meshes:
level (per-polygon). Can customly hook up per-polygon for anything if
needed.
Audio Integration:
0% - Need to integrate FMOD
Optimization
100% - Engine currently optimized
Framerate Lockdown:
100% - Framerate currently steady at 60 Frames per Second.
Lighting:
0% - Included in irrLicht, Lighting and Lighting effects not yet
implemented
Particle Effects:
0% - Included in irrLicht, particle effects not yet implemented
Dante
Feb 18, 2008, 6:20:55 AM2/18/08
to FLASHOVER - Game Project
Audio Integration:
20% - FMod in the project, SoundSystem class made, able to play
streaming music and fade in and out.
20% - FMod in the project, SoundSystem class made, able to play
streaming music and fade in and out.
Dante
Feb 27, 2008, 2:50:54 AM2/27/08
to FLASHOVER - Game Project
Good news! As some of you know, I have painstakingly been up all hours
trying to implement a working model for Parallax Mapping (Offset
Mapping) in our game. IrrLicht claimed this feature, but I ran into a
lot of problems, and some bugs in the engine. Since it is such a new
feature in games, I am actually only one of few using this feature of
the engine. I was pleasantly surprised how quickly the community
responded to my questions, and one of the Engine Programmers has been
fixing each issue I bring up on the fly, even customizing this part of
the engine to work for me at the moment.
I will start a new thread to define the status of the game engine, as
I am marking this the current status as a sort of 1.0 to base off of,
since a lot has been done so far.
trying to implement a working model for Parallax Mapping (Offset
Mapping) in our game. IrrLicht claimed this feature, but I ran into a
lot of problems, and some bugs in the engine. Since it is such a new
feature in games, I am actually only one of few using this feature of
the engine. I was pleasantly surprised how quickly the community
responded to my questions, and one of the Engine Programmers has been
fixing each issue I bring up on the fly, even customizing this part of
the engine to work for me at the moment.
I will start a new thread to define the status of the game engine, as
I am marking this the current status as a sort of 1.0 to base off of,
since a lot has been done so far.
Reply all
Reply to author
Forward
0 new messages